Learning by Shipping

products, development, management…

Posts Tagged ‘process

A Leader’s Guide To Deciding: What, When, and How To Decide

Science fiction (Star Trek) with officers sitting around a meeting table.Decision-making is one of the most difficult skills to master as a manager. A startup CEO literally sees a constant stream of decisions to be made: from hiring and firing, to Android or iOS, all the way to Lack or Billy. As the company grows to 10–20 people (usually mostly engineering) the bonds and shared experiences continue support decision-making at the micro-level. Once a team grows larger there is a need for management and delegation. While growth is a positive it also a stressful time for the company and founder/CEO.

Even for the tightest knit group with founding-team trust, the first decisions made without the CEO (or by simply giving a heads up to the CEO) are nail-biting moments for everyone. The closer the decision is to the core of the CEO experience the trickier. Deciding on UX changes or tweeting from the company account all test the ability for the CEO to delegate and the team to be delegated to.

As a company grows to having leaders and groups across different functions (heads of sales, marketing, eng, operations) the need to be systematic in delegating and deciding goes from optional to mandatory. Many founders resist this move. First founders rightfully care about everything — everything matters — and it is very likely he/she is in the best situation to make the best decision for the company. Second, founders that worked at a big company too often experienced dysfunctional decision-making and part of building a new company is to do better than that.

As a manager, I always found deciding to be both trivially easy and impossibly difficult. It is easy because like many, if you ask for an opinion from me you can get one. It is difficult because like many, the implications of sharing that opinion are not really known at the time.

For me, knowing what a decision really is about, understanding the full context of a decision, even just awareness of what is actually being decided are a few of the many challenges. Add to that all the management-speak about delegation and accountability and quickly I came to conclude I could justify any course of action. I could be anything from the center of a command-and-control decision making machine to a completely non-accountable, human-router-delegator of important choices in the name of building an empowered team.

I wrote this post in an effort to create a framework for how to think about decisions from the vantage point of a CEO/founder/exec as an organization grows beyond when the “hub and spoke” is the expected norm, and how to think about the good and crisis times when it comes to decision-making.

Deciding with Dysfunction

Making decisions is easy on paper, but a lot more difficult in practice. Worse, the more one practices the harder it is to make decisions simply because of knowing more and seeing potential downsides of just about everything. One might think experience would make things easier, and often it does, but it can slow down or even just prevent things from happening. When I was young, I could decide to drop in on a 15’ vertical half-pipe without hesitation. That was before I knew the downsides of injury (it was also before YouTube so all we had to look at for examples were photos)!

As the team grows, CEOs (and execs, depending on company size) face many challenges in getting things done or just picking the right things to do. One of the main factors is the increasing number of people involved in any choices. Deciding iOS or Android first will seem easy or “obvious” when resources are very tight and there’s no Android developer anyway.

Fast forward and consider the complexity when there is a newly hired sales leader who knows “works anywhere you do” will close deals, an engineering manager who still can’t hire an Android lead, a QA manager who is all about fragmentation complexity, or a newly hired BD lead who can choose between two partnerships but the better logo requires both iOS and Android. All of a sudden there’s no simple decision to be made and a lot of people contributing who feel their success hinges on going with their point of view. Play out over time the various potential outcomes and who is promoted, gets more responsibility, or is credited with success to see that this challenge is far more than just getting the right answer. That is normal.

As a result of people living this pattern over and over, many decision-making techniques and tools have been created. These codify a “decision making process”. In fact there is a whole Wikipedia article describing responsibility assignment matrix. These have a variety of acronyms like OARP, RACI, ARCI and more. The letters are various ways to define roles in important decisions such as reviewer/approver, recommends/consulted, responsible/accountable and more. These are tools designed to speed decision-making, clarify execution accountability, and ensure robust choices. Leaders figure out what to decide and assign various roles to participants and like magic decisions are made.

In my own experience these tools more often than not slow things down, make no one accountable, and all but guarantee compromises with which no one is satisfied. There are innumerable stories of how a well-intentioned taxonomy like the above can be used to grind work to a halt, push accountability around without establishing it, and turn a specific decision into a general battle over the meta. That’s unfortunate because making the right choices is incredibly important and having tools that add reliability and consistency to the effort would really help.

Rather than dissect a meta-process, I’d propose taking a step back and saying that the most important thing a CEO or executive must do is to keep the output and velocity of the team at the highest levels and focused on doing the right things. The first VP I worked for, way way back, hypothetically suggested “maybe a star could do the work of 3, or 5, or even 10 people” then he went on “the problem is we are doing work with 20, 40, or 50 people”. The implication of that math is clear. No matter how smart, hard-working, on top of things, or just amazing someone is, they need to work with other people and count on their work without actually doing it.

The core problem with a decision-making process starts with defining a decision and related inputs. Almost never is there all the information needed or wanted to make a choice and wait long enough then chances are context and options have changed enough to make the decision framing all wrong. So all that was really accomplished was slow everything down by simply by trying to define the decision to be made and what inputs were needed (apparently this also holds for the Federal Reserve Bank).

We know that almost nothing is made up of a single decision at a single point in time. Ask yourself how many discussions or meetings you had where you thought there was a yes/no, or a choice to be made, and after running over time the only decision was to wait, learn more, or come up with new options? It is only long after clear success or failure does the historic narrative turn into the “big decision” (and associated drama).

The essence of an agile organization is figuring out how to make fast progress against larger goals, learning and adjusting along the way. In that context, many at the company make decisions every day.

Stepping Up For Growth

With so much happening every day, rhythm is the biggest enabler of agility. If a team operates in a Flow, then everyone can do their best work. We all know what it is like to groove. We also know what it is like to have that groove interrupted by questioning the choices made or pausing to have choices validated, reconsidered, or tweaked.

Trying to get ahead of decisions sounds great. This quickly turns into trying to know what isn’t known and worse to prepare for it. Finding a way to codify the set of problems that will trigger a review or joint decision turns into a meta-planning exercise trying to agree on potential challenges.

In my experience, the real challenge is in trying to define decisions, isolate important ones, and then figure out the stakeholders for that once instance. Decisions are everywhere. Deciders are all over the place. Every identifiable decision is made up of many other choices, constraints, and stakeholders.

The following is my own idealization of the role a CEO or exec can play in decisions. Instead of kicking off a process for a single decision, spend the energy up front to decide what and how the CEO will work. Thinking this way allows for a variety of approaches for getting involved, delegating, or empowering. It avoids the complexities of figuring out what it is that is actually being decided and hairsplitting accountabilities among individuals. It introduces agility into a process rather than rigidity.

My own experience led me to believe that before I decided something that was brought to me, I had to have an idea of what role I was playing in the process. It is easy to be a boss and assume people need your wisdom, advice, or context. It can be tricky to know if you are really adding that, affirming the choices of those who work for you, randomizing them, or simply doing their job for them.

With that experience, my view is that before deciding something a CEO or exec should be clear how he/she contributes to a project or work, using one of the following:

  • Initiator. Kicking off new projects.
  • Connector. Connecting people to others so the work gets better.
  • Amplifier. Amplifying the things that are working well or not so there is awareness of success and learning.
  • Editor. Fixing or changing things while they are being done.

Let’s look at each of these in a little more detail.


As a practical matter, assuming the organization is running at > 100% capacity then there’s a finite amount of initiating that can be done. Almost everything kicked off at the exec level looks like the strategy, new projects, new organization, or the prioritization of work. Creating or seizing new opportunities from the leadership vantage point is precisely it means to be the initiator.

  • Examples: Kicking off something entirely new (hiring process, first sales deck, new product release, opening a new position. Deciding to make a big bet on a new technology, platform. Starting a new strategic or transformative initiative.
  • Tools: Write it down in a way that someone joining the project later can quickly get up to speed. I believe writing is thinking, so taking the time to gain clarity on what to do and what success looks like only helps. Pro tip: Drafts circulated to a small set of key people, but quickly along with seeking and acting on feedback can be very valuable.
  • Granularity: Almost always this will be fairly coarse like “launch day” or “new product” but can scale all the way down to being the specific such as “add this feature”, “create a partnership”, “publish APIs”.
  • Time: When operating in a rhythm (product cycles, launches, adding new leads) initiating becomes a key part of team rhythm. About 10% of overall work is initiating new work or projects.
  • Mindset. The most important work of an exec is in kicking off a new project so put the most effort into this work product. Initiating is the only time an exec does the work of an individual contributor.


Most all decision-making challenges happen across domains. Rarely does a solid engineering leader pick the wrong toolset. Rather the toolset is wrong because the full scope of the challenge was not known. Anything crossing functional lines requires a connection. The exec is in a unique position to be constantly connecting functions and work. Helping people to know more about what is going on with others on the team while recognizing this almost never happens by chance.

  • Examples: There are classic examples across functional lines such as connecting sales and product. Many of the most interesting examples are the non-traditional ones, which can help people to gain more experience such as connecting engineering to customers. Facilitated connections rather than simple introductions afford the chance to see how parties use the connection and to drive an agenda consistent with a rhythm.
  • Tools: Presence, listening and talking have no substitutes. Even with everyone being online and available, don’t assume everyone or the right people will read everything. With any size team, the amount of “FYI” or automated information will quickly overwhelm even the most diligent. Rather than believing status reports and scorecards will connect, execs must focus on making specific connecting efforts with clear intentions to move things along. Most work has natural points where checking in makes sense. Rather than relying on ad hoc connections, use a structured approach to surface the right issues.
  • Granularity: The reason connecting is fun is because when it not randomizing or micro-managing, but simply sharing and getting head of potential problems. Connecting peers together is a service to the team.
  • Time: Spending more than half, perhaps 60%, of the time connecting is routine among CEOs and execs. A useful way to spend time is on structured, periodic checkpoints that connect the status of the current work to the start of the project. Pro tip: Most every interaction can serve as a chance to connect one part of the team to another or a CEO’s external context to what is going on internally while also using the opportunity to demonstrate listening while not trying to solve everything along the way.
  • Mindset. Connecting is the field work of the exec. Execs should be thinking about what to connect almost all of the time. Connecting skillfully is a force multiplier.


The CEO or exec soapbox is a super valuable tool. Within a company there are not only good things worth letting everyone know about, but lessons learned that could be shared. Since it is a given that not everything can be thought through in advance, seeing and amplifying the creative ideas or great execution seen along the way can be seen as a proxy for initiating new things. When a CEO stands up in front of the team and celebrates success or learning it just matters more.

  • Examples: The best example is to amplify the good work of the team or to turn failure into a lesson. Amplifying the good work of competitors, sales wins, or collaboration across functions gives leaders a chance to call our efforts that cross many parts of the company.
  • Tools: The team meeting is the most valuable forum for amplifying and often supporting this with something in writing (or a t-shirt or sticker!) works best. Amplifying work is also related to connecting work and often they are two sides of the same coin. The most compelling efforts to amplify are supported by great stories — when taking the time to amplify something, do so with the whole story and the background that makes it worth amplifying. It is one thing to tell people something important, but another to describe why it is important.
  • Granularity: Amplify things that apply to many people on the team but do so with a frequency that maintains meaning and impact. Pro tip: When celebrating success, execs should be sure to give the right credit to the right people.
  • Time: Execs have a unique ability to amplify success, which in turn makes this a high value effort so it is worth spending 10% of time.
  • Mindset. It is fair to view amplifying as a bit of a tax. As is often said in management, “what’s worth saying is worth repeating”. Ronald Reagan was famous for not veering off important messages because he believed even though it was old news for the press corp, it was new to those in the live audience.


In a big company, people just wish execs would go away and let them do their jobs. In a new startup, execs are doing the work (i.e. coding, selling specific accounts, designing the UX). Everywhere else many people are doing the work and the exec is figuring out when to contribute. Somewhere between “swoop and poop” and “micro-managing” is the role of contributing editor. I use the term “editor” specifically because this is about changing (or improving) the work created by others. Editing is the right of a boss, but also a privilege in a team made up of smart and creative people. Everything about editing is in how it is done. Poorly done, editing makes people feel bad and never generates the best work (except for Steve Jobs as many like to say). Done well, and editing makes everyone feel better about the collective effort.

  • Examples: Redlining a document, drilling into a design review, redoing a positioning framework, creating an outline for a blog post or release, designing the 2×2 competitive framework are all examples of editing.
  • Tools: The most important “tool” to use when editing is to do so in-person. The vast majority of editing feedback comes across as negative and critical. While there is always enough bad work to go around, finding ways to be constructive is always worthwhile. For better or worse, editing without verbal context or worse just being critical over email almost always makes things worse.
  • Granularity: Chances are the granularity of editorial input is very fine-grained. The question is not really whether to edit or not, but how many times the same thing (even for the same person) is edited. Repetition means there’s a systematic problem with communication or the people doing the work.
  • Time: Editing is a big time commitment, but not the biggest. It also comes in fits and starts. More important than time is timing. The later in the process or the closer to the deadline the higher “cost” being an editor has. Overall about 20% of exec work is editing.
  • Mindset. This is the comfort zone for every exec, especially when it is the type of work he/she did individually. The important thing is for the exec to really know the importance of the changes.

With a framework or roles like this, there is clarity in how an exec is working with the team and how work is started, iterated, and completed. I would also encourage using this framework by managers at all levels in a company. One changes the time devoted to each type of interaction.

Diving In For Saves

At this point, you probably think this all sounds well and good, but what about when things are going sideways?

When things go sideways none of this matters.

In fact, none of this really matters if the company are such an early stage that there are no more than a couple of dozen people. It also doesn’t matter if there is not yet product-market fit.

In Ben Horowitz’s Hard Thing About Hard Things, he describes the differences between a “peacetime” and a “wartime” CEO styles (specific post is here). I love his framing of decisions that pose existential questions for the company. That is a fantastic way to know when there really aren’t decision making processes other than whatever the CEO wants to do to survive to another day. Rarely are exec level choices existential at the same level, which is worth noting.

In a startup, the wartime CEO pretty much describes things until there is a solid revenue and profit stream coming from a product that works for the market. Most everything amounts to an existential choice or decision.

In an organization that is more or less working, this is a more subtle challenge. At some point few decisions are truly existential, though it turns out it is tough to know this is the case while everything is happening.

There was a recent Facebook thread among a few of the original leaders of an old Microsoft product. From the outside, most people see only the victory and to read their comments one would think it was all a cakewalk. From inside the team, every day felt existential and every choice seemed to be about the success or failure of the whole. This is the norm at big companies and explains the origin of those questionable “decision support tools”.

This all boils down to product-market fit and deciding when in fact that state was achieved. Before that time, everything is existential. After that time, most decisions are relatively minor. Unfortunately, knowing this dividing line isn’t so straightforward and the clouds of disruption always loom on the horizon. This is the fog of war in a big organization.
Operating all the time in crisis mode or thinking every choice is existential is just not sustainable as a company or leader. As fun as it seems, a whole yoga practice upside down is not a good idea.

As a company scales, the long tail of choices and decisions feels existential from within even if they aren’t. There’s no magic answer as to when one is at war or peace, even in hindsight. My view is that a CEO can decide the one thing no one else can, which is to decide things using a poorly defined process. Just keep in mind that even the most successful CEOs and execs can eventually use up that luxury and either adapt how they work or watch people leave the company.

The original generals, in the military, have evolved their thinking and modern warfare now employs the notion of commander intent as a leadership practice for just these reasons (and more). If you are interested in how the largest and most process-oriented organizations evolve, the report linked to is fascinating.

With the most robust product market fit, there will be existential moments demanding wartime decisions: a major security breach, service outage, failed sale, or losing key members of the team. Don’t ever be worried about deciding in the most top-down, non-empowered, toe-stepping manner when facing a true crisis. That’s what leadership is all about. Using the framework above, a crisis situation just demands a great deal more editorial actions.

Making decisions is something that at first comes naturally, even easily, and then as a company grows the complexity creeps up on CEOs and execs. Some of this is because with experience comes awareness of all the things that can go wrong. Most comes from the challenges of scale and decisions of when and how to let go of some things. Decision making challenges come when an unlimited amount of passion meets a finite amount of time. Taking on this challenge without introducing a mindless bureaucracy is an opportunity for a growing company.

— Steven Sinofsky (@stevesi)

Note: Also sim-published this on @medium.

Written by Steven Sinofsky

September 10, 2015 at 10:59 am

Posted in posts

Tagged with , ,

%d bloggers like this: