Facing a Cold Audience

This pattern is about making sure you don’t go in to present to a cold audience. By “cold audience,” I don’t mean necessarily one that’s adversarial or defensive, but rather one that you have not prepped, and does not have at least some idea of what you’re going to say.

The naïve approach is to come to the meeting and unveil your work to a cold audience. You’ve scheduled the meeting, people show up wondering what you’re going to show them, you present your strategy, and you ask if there are any questions. In such a forum, with a cold audience, you will be lucky to get past the third slide.

What is most likely to happen is that the managers, directors, VPs, senior executives, or whatever level of folks are in this audience will completely reroute the conversation away from what you’re presenting. It won’t be on purpose, they won’t mean to, and the origins of where you lost them will be hard to trace. But an argument over some tangential matter will ignite, or you will get tremendous focus of a very aggressive nature. People will launch damning questions, puzzle out loud, or otherwise attack the work.

You will be left standing there, having presented a small portion of your ideas, with no one seeming to care about it or a palpable sense of confusion about what you’re trying to do and why. Because the presentation erupted into a bunch of side conversations with people not paying attention or performing an outright mutiny on the ideas, it gets rejected either explicitly or implicitly, with people not wanting to hurt your feelings or be the shark at the meeting, but ultimately you’ve not moved them or changed their minds or gotten them on board with your plans.

This is a failure, and you don’t usually get another shot at it. This can be incredibly frustrating for you, and prevent the organization from moving ahead with your great ideas. Why would this happen? There are a few, marginally related reasons.

Anytime you’re presenting in a work forum like this, people have only one question in their minds: What’s in it for me? They immediately start calculating. How does this message affect me, my teams, and my chances for success; encroach on my territory; or signal the coming of some change that I might find incredibly disturbing or rife with opportunity?

There’s a cliché we often hear in business: people do not like change. We’ve all heard this. But it’s not quite true. What it really means, or should mean, is that people don’t like change that is imposed on them. We might be perfectly happy to change jobs, get a new haircut, or move to the Smoky Mountains. People are fine with change and they do it all the time. But we would not be happy changing in any of those ways if someone else forced us to do it without asking us, without consulting us, or without recognizing that we have some vested interest. We can make all kinds of changes all the time, with great enthusiasm, even as a work force within a big software company. But not if we aren’t included.

Here’s the mistake we made in our meeting: we didn’t include the audience in our process, or at the least given them a heads up and taken some input. When you go to a meeting and some director unveils her new “strategy” and you’re not sure why you’re at that meeting, what the outcome is supposed to be, who she thinks she’s talking to, what’s going to be decided, and worse, those proposals tend to get undermined explicitly or politely disregarded.

The Meeting Before

What you need is a fait accompli. Put simply, you have the meeting before the meeting, in a bunch of little meetings, to line everyone up. Then the big meeting where everyone is ostensibly there to hear your message and accept it is more or less over before it starts, with people by and large on board, because their buy-in happened already: it’s a fait accompli.

You need to have the meeting with each of the key stakeholders, individually, before the meeting, to get them on board separately. Then, when the big day comes, it’s just a show about nothing, which is perfect, because you’ve already made everyone the ally of your proposal. The best outcome at the big meeting is that nothing much happens. No one is caught off guard, no one is challenged and gets defensive, no one is confused about what’s happening, there are no hecklers taking everyone down a rabbit hole with their one weird line of reasoning, everyone nods in agreement, and you get a yes because you’ve already gotten one from everyone privately beforehand. With each audience member feeling separately in concert with your proposal, there’s nothing to discuss, your stuff gets approved with little fanfare, and you get your bag of money to go change the world.

In essence, you need to suck the drama out of your own meeting, before it happens, so no one else can add their drama and undermine your work. If you don’t do this, some person who is the most threatened, or whose perspective you have least considered or cared for, will act like a heckler at a comedy show. And if that person has any power or respect from the others in the room, human animal nature will be to spot the weakness, see that things are going south, and pile on. And then you’re sunk.

So instead of relishing the drama of such a meeting, you have several little informal meetings with the key stakeholders. These can be short.

It is very hard work to put together a smart strategy for a changing and complex business. It can take many weeks. After toiling away, alone in a room, thinking, reading, and working hard, you might find it incredibly tempting to come to the reveal meeting in the manner of an artist or a showman, excited about your ideas. That’s natural. But it’s not strategic. We see Steve Jobs and his attendant deification, and it’s tempting to want to emulate these kinds of dramatic unveilings. But unless you’re Steve Jobs, this is probably not a great approach. As the business cliché goes, you want to be positioned not as the “sage on the stage,” but the “guide at their side." When you’re the genius who went to the mountaintop, did a yoga pose, and had the gods reveal unto you the One True Light and the Way about what your technology strategy should be, and now you’ve come back to the commoners to spread your gospel, don’t expect much support.

So here’s how to implement the Fait Accompli pattern, in a few easy steps:

1. Look at your Stakeholder Matrix (see “Stakeholder Matrix”) and RACI (see “RACI”) and make the list of whom to invite to the big proposal meeting.

2. Determine the list of who the key stakeholders are—the people with the most clout. Determine who is most affected by your proposal, who has the most to lose by it, and whose daily lives your proposal would disrupt the most. Carefully consider on this list the people who don’t like you, aren’t automatically on board with your ideas, grumble no matter what, showboat at meetings, and make everything about them. Try to see yourself as they would, as that external imposer. If you show up to announce that everyone’s getting a new haircut and moving to Milan, expect a violent and quick uprising. This will happen even if everyone in the room wants to move to Milan.

3. Interview these people individually, tell them what you’re thinking, and ask if it makes sense to them, what you’re not considering, how it can be improved, and what ideas they are working on that might be incorporated. Take the notes with gratitude and make places for them in your work.

4. Then, like a salesperson, ask them bluntly, “If we incorporate these changes, does this direction make sense to you? Is this something you can support?” Recognizing later that they already have signaled their clear approval to you, they’ll be loath to reverse that publicly at the big meeting.

5. Go to your big meeting with the clearly stated agenda that you’re making your proposal or stating your new direction. Once there, make sure that you reference the stakeholders’ work, credit their ideas, and thank them for their contribution. This is not only honest and proper, but has the pleasant side effect of creating an echo chamber of support in the room. You’re implicitly telling the other bosses in the room: “Betty Boss contributed this idea, so this proposal is partly hers too. So you can’t attack this without also attacking Betty Boss,” which they will be much more hesitant to do.

Your strategy will get approved, and you will have made a fait accompli of the proposal. Nicely done.

This pattern is not about manipulation. It is about empathy and truly strengthening your work in a material way. There is also an awareness of some of the quirks of human behavior in business settings that don’t have to be allowed to run rampant.

Managerial and executive types do not like surprises. Ever. And they definitely don’t like their authority undermined or ignored. But if you line them up privately before the meeting so they can make valid and important points that you can consider, work into your proposal, and credit them with, and give them a chance to get their voice heard and state their frustrations or concerns, all will go well. You won’t be surprised, they won’t be surprised, and your proposal will actually be better, more relevant, and more impactful with the multitude of voices with different perspectives taken into account.

When this pattern is most deftly executed, people don’t have an experience of approving your work at all: they think you are merely representing them and simply relaying the strategy we all know is right. They will think, “We did it ourselves.”

Strategy is the art of creating power. If you don’t give them power, they will take yours.

Establish the Status Quo

The status quo grounds the audience: we know where we are on this common ground. We restate our shared goals, acknowledge the current process, state a clear picture of our teams, and show the architecture diagram of the current state. We’re getting buy-in here that this is Where We Stand Today. This is a level set of What We Know to Be True, and Our Shared Understanding.

Create an Inciting Incident

But something’s rotten in the state of Denmark. There’s a scratching at the door. We show the current state architecture with all its spaghetti mess of connections, leaving our teams debilitated. We point out the areas of exposure, weakness, and vulnerability in security. We show charts depicting the number of Priority One incidents: the trend is bad. In fact, if we stay on this course and do nothing, we are doomed. We show the effect of exactly what the state will be if we do not act. We have two years to migrate the servers, and then we’re out of IP addresses and we can’t add more customers. State clearly, with real data and projections, exactly what you expect to happen. The alien ships will land and enslave everyone they don’t kill, we’ll lose the family farm to the bank and end up on the street, the spaceship will go careening into the sun/black hole or run out of fuel, and everyone dies without a parent to raise their dear children. You show what bad effects are in store for the business if you don’t act. As in the movies, the stories in business are few. The effects are going to reduce to one of these:

• Our costs will go up, while our quality and availability go down.

• We will be slower to market, and the competition will win.

• We will lose this revenue opportunity.

• We will lose these key customers.

• We will lose these key employees.

You should illustrate these with data you cultivate, like the movie scientist with the white coat and pointy stick who warns everyone what will happen, but they’re too dumb/lazy/entrenched in making money to heed his emphatic warnings.

You are showing, as vividly and truthfully as you can, what The Problem is and what the impact will be if we continue the status quo. If the problem you’re solving doesn’t reduce to one of these, you might be framing it wrong.

The Plan

The plan is how we state the way out. This is the “therefore” moment. The Rock has got to steal the helicopter, fly it into the dam, and defuse the bomb—we’ve got two hours until it goes off.

We were living on credit cards and never updated our legacy software, and now it’s time to pay the piper. Here’s how we decompose the monothlic system and turn it into a modern platform. Here’s how our new tech will capture this market. Here’s how we fix the quality and scalability issues that have plagued our mission-critical system.

Because the world changed in ways we didn’t ask for, didn’t anticipate, or weren’t ready to confront, we must act. And here is the simple single statement of the path forward, the clear recommendation you’re making, your plan: to fix the problem, we must do this. Make it a single sentence of your new goal. We were just going to live on this planet and be farmers, but now we have to go be Jedi Knights and blow up the Death Star to restore peace and justice to the galaxy.

Show what changes you expect across people, process, and technology. Who will be involved, what work will they do, what processes need changing, what tech will you buy or learn or add to, and what is the future state architecture?

Using Directional Costing (see “Directional Costing”), show how much the plan will cost, so they know what you’re asking. Show how long it will take and who will do the work.

But much of this we’ll look at in more detail in “Ask Deck”.

Shock and Awe

Shock and Awe was a military tactic developed in the late 1990s. Its goal is to paralyze the will of the adversary to fight. Using this as a metaphor, you overload your audience with such an onslaught of brutal facts about the status quo that they become incapable of resistance. Make a show of such decisive force in your deck—the painful succession of problems and bad outcomes for not agreeing to your plan, such that it’s urgent that the executive make a decision now—they obviously will choose your path since you’ve so clearly gathered the facts and thought it through and they just can’t wait for your plan.

Here, you all but crush the hero. You never use hyperbole or overstate the case or say anything false. Just be brutal in making the audience uncomfortable, confronting them with the real problems, as a Rented Brain would (see “Rented Brain”). Be specific about the bad things that will happen, using charts and graphs and projections in order to be clear on the time frame you have. How long until the bomb goes off? You pile on more and more in succession until they all but beg you to stop.

Finally, you state the following:

1. Your definition of done: this is the concrete statement and clear view of what the world looks like at the end of all this, the future state architecture once you’re done.

2. How you will measure that success, how you’ll show progress, and the metrics you’ll use.

3. The structure you’ll put in place to report back on those metrics and progress to a steering committee made up of these stakeholders. The executive is still in control: all she has to do is agree, and everything will be fine.

You have rocked their world with a cataclysmic event, piled on more and more pain like the Book of Job, shown them a path forward, and given them the assurance and mechanism of transparency that leaves them confident and relieved that this plan is in place and they are still in control and can’t wait for the New Normal.

Here’s a second great benefit to employing Dramatic Structure: if you can’t honestly weave your request into this structure, if you don’t know clearly what the real reasons are that you want to move to the cloud or make all the programmers learn AI, or you can’t explain why everyone should stop doing Agile and start doing Fred’s Cool New Software Development Method, then you might not have good enough reasons.

If you can’t create the inciting incident this way, and don’t know what will happen if the team doesn’t follow your recommendation—or if what will happen is that Everything’s Still Just Fine—then you might have a solution looking for a problem or you might have merely made a Shopping List of Shiny Objects that would be fun to put on your résumé. If you’re not solving a real business problem for anyone, then it shouldn’t be done.

I’ve employed this structure in every Ask Deck I’ve made for the last decade, and there have been many of them, requesting many tens of millions of dollars to go do important stuff that needs doing. With this structure, I’ve never been told no. It can work for you too.

Business as System

Architecture is the broader purview over a system. Strategy is the broader purview over a line of business. Thinking like an architect, technology executive, or strategist is to look at the nexus of external forces and internal forces operating on our work as considered holistically, whether those be a software application, a process, or an organization. These take effect across various temporal trajectories, operating at various velocities, with various degrees of dynamism within the system.

To improve the organization, observe these forces and see them as a context to create a model of the world as a system. You are a maker of systems, which are built with an architecture, which desires certain properties: usefulness, firmess, and beauty. Attributes we tend to design explicitly for as architects include:

• Fitness to purpose

• Portability

• Scalability

• Extensibility

• Availability

• Monitorability

• Manageability

• Maintainability

• Resilience

• Security

• Auditability

• Performance

• Testability

• Elegance

We commonly employ certain principles in architecting and designing:

• Hide details behind an interface.

• Apply the principle of least knowledge.

• Create a strong separation of concerns.

• Ensure loose coupling.

• Isolate what changes independently.

• Look for opportunities for reuse.

• Explicitly manage risk.

Finally, let’s recall the SOLID principles of object-oriented system design:

Single responsibility

Things should have one and only one reason to change, meaning that a class should have only one job.

Open-closed

Things should be open for extension, but closed for modification.

Liskov substitution principle

Objects of a derived class should always be substitutable for a parent class.

Interface segregation

A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.

Dependency inversion principle

Things must depend on abstractions, not on concretions. The high-level module must not depend on the low-level module.

You can architect an application, a data center, a project, or an organ­ization. You design the interactions between software services with a protocol and a message payload; you design the interfaces between two departments to maximize efficiency, clarity, security, availability, monitorability, and speed. You design these systems according to SOLID and the desirable architecture attributes just stated.

The organization is a system.

The project is a system.

You can apply what you know from designing technology systems to business systems, like structuring the processes or the projects. The valued properties are similar across all of these system types. When you’re designing a process, keep the architecture qualities in mind: I know of at least one Infrastructure department I’d love to have learn the principle of interface segregation.

Reread the SOLID principles and the architecture attributes just given, but this time seeing them through the lens of process designer.

The Origin Theory

I have a theory I’ll call the Origin Theory that might help you assess why your company behaves the way it does or has the problems it has when it’s trying to grow. Sometimes a company starts its life as a support function. For example, maybe a big company had a little IT shop to support its real value creation work, and someone along the way made a software application for internal use that worked well enough that somebody else thought they could make more money if they were to spin off a company to sell it as a software product. That new company has its origins as a support function. The Origin Theory states that it will therefore continue to act as a support function, even to its detriment. In essence, you end where you began.

This happens because in the Olden Days, the little company hired leaders who matched its size and culture, which is typically one in which people must perform heroics, and must wear several hats. That’s not a problem in a startup—it’s a necessity of survival. So the people were nurtured through the ranks with everyone acting as participants in a support function. They do not think like product people. They don’t think in terms of a P&L (profit and loss), or having clear guardrails and documentation and external supporting functions, and strongly separating responsibilities, and inter-departmental interfaces, because there’s only one department and it’s called Get Stuff Done. They think in terms of projects: those long, drawn-out loci for people doing activities instead of thinking in terms of outcomes. I have seen this in multiple companies, even multibillion-dollar public companies that act like private companies because even after decades in business and having gone public, there’s really one or two majority shareholders: “Junior.”

It is very difficult to turn around a company in this state. First you have to recognize it, then you have to get others to see it, then you have to rethink all your processes to define clear outputs and interfaces, and then you must make a cultural shift that will involve dramatically changing who is on your staff, changing how you manage and communicate with customers, and thinking of your products and services as independent of your heroes’ hand-holding. Helping make such a transformation when you need to grow and scale your business is the aim of this pattern.

Aspects of the Scalable Business Machine

Implementing this pattern to create your scalable business machine (SBM) will mean making a project that you need to lead and track. Even if you are just implementing it within your own department at first, expect that this is a nontrivial amount of work. You should make a RACI and Stakeholder Alignment too. Before doing any work, make sure you’ve got your leader’s buy-in and know who will make decisions. It’s the kind of thing that you could pay consultants to do for you, but they wouldn’t do it as well as you would, and the people wouldn’t receive the change as well if you have this framework in mind.

Let’s define some terms first. The following are the component parts of the SBM.

Company

A company is a legal fiction that has the status of a special person. The company itself doesn’t make anything. It is an abstract class for holding business units or departments. There are no company outputs that are of value to customers that are not already defined by some specific business unit.

The company itself is not a value creator other than as a sum of the department parts. For a smaller company, say, those under $100M, you may not be subdivided into business units with their own P&L. In these cases, the business unit and company share an “identity” relation (they’re the same thing). In such cases, treat their use here interchangeably.

Figure 7-1 shows a logical architecture of how these components all relate. In general, here’s the idea behind the SBM: companies do a bunch of stuff that doesn’t matter and on occasion need to identify those things and refine their processes to remember how to efficiently create value and make a difference in the market. They need to get out from under the inertia that sets in and focus on outcomes.

The SBM is engineered to help you identify where you are, separate the wheat from the chaff, focus on optimizing outcomes for delighting customers, and allow you to scale and grow.

Figure 7-1. The terms in an SBM

Executing

Now that we have the relevant terms defined as we’ll use them, here are the steps for creating an SBM.

Define the departments and customer outcomes

Next you need to create the list of departments that are in scope. This sounds too obvious to do, but it is in no way obvious to the people in your organization what the different departments are, why they exist, what they do, and how they interrelate. Just name them for now and agree on scope. If you want to give each one a charter or mission statement, that gets you bonus points, but again, only if you really use it to organize your thoughts as a Logic Tree.

Start with your external customers first. What is the output of your business unit for customers?

Then identify the desired outcome for them. What would give them a benefit or delight them?

Then determine the outputs at a department level. What outputs does a department make to feed the next department as their necessary input? These are the internal customers you identify.

List these for each department.

Now you have an overarching vision, a validated list of departments, their mission for each, the outputs they create in support of it, and the benefits that will add up to great outcomes—the benefits for which you exist to give your identified customers.

We are ignoring for now deliverables and actions. That’s on purpose, and it’s important. We want to go from the outside in, focusing on what we create that’s of value for someone else, and being clear on what that value is. We do not care at this point how we create that value. Companies all too often get focused on their own internal processes and forget about customers.

At this point, you have a burgeoning spreadsheet (a list of lists) with roughly the structure shown in Figure 7-2.

Figure 7-2. Your work thus far

It doesn’t look like much, but getting this far is actually pretty great work. Remember, the key is to be outcome-oriented. Without measurable outcomes, there is no need for outputs.

At this point, we are hovering above the surface, going one inch deep across the entire field. Then we can dive deeper later, once this much is validated.