Forget RACI, SPADE will pay off in spades

Another good read from the folks at First Round Review covering Gokul Rajarams decision making framework:

Square Defangs Difficult Decisions with this System — Here’s How

It’s a 5-part framework: Setting, People, Alternatives, Decide and Explain – or in short, SPADE

Setting

Defines the decision that needs to be made, using the standard 3-W’s:

  • What – articulates as precisely as possible what needs to be decided.
  • When – defines the timeline for making a decision. This cannot be a fake deadline, the timeline needs to be defensible.
  • Why –  goes one level deeper and makes the assumptions or beliefs that deemed the decision important explicit.

People 

Defines the groups of people that should be involved in the decision making process. This actually happens before or in parallel to defining the setting. Here Rajaram diverges from the classical RACI by defining only three roles:

  • Responsible – this is the person making the decision and the one accountable for executing it.  The often-confusing ambiguity between the “responsible” person and “accountable” person in some interpretations of RACI is eliminated by merging the the roles, which also reduces the systematic disempowerment in situations when one is held accountable for executing on a decision made by someone else.
  • Approver – is the person with veto rights over the decision. The intent here is that this right will be used sparingly and be focused primarily on the quality of the decision making process rather than its outcome.
  • Consultants – are the people that should be providing both input and feedback on the decision.

I find the way the approver role has been defined pretty interesting. If done correctly, it should create a dynamic similar to the one between a developer and a tester rather than a more traditional escalation up the chain of command.

I also can’t stress enough the importance of being thoughtful and proactive in identifying consultants and soliciting their input and feedback. Giving people a voice is the best way to reduce objections and road blocks further down the road.

Alternatives

These are essentially the potential outcomes of the decision making process.

Alternatives should be feasible, diverse and comprehensive. Engaging the people identified as the consultants for the decision is the best way to identify the best potential alternatives.

Decide 

Given the self-explanatory title, let’s focus on the actual steps:

  1. Gather the consultants in a room, present the best alternatives and have them provide feedback on them
  2. Solicit their confidential vote and reasoning for the alternative that each of them favors. Confidentiality can be removed if the level of trust is high enough, but it’s a powerful default, particularly around very contentious decisions
  3. Make the decision. Choose one of the alternatives and clearly formulate the reasoning for why you chose it. Note that making the decision does not require neither consensus nor a majority of the votes in favor of that alternative.

Explain 

  1. Run the decision by the Approver
  2. Walk the consultants through the decision that you’ve made and the reasoning
  3. Ask each of them individually to make a public commitment to support the decision
  4. Summarize the SPADE of the decision into a 1-pager and share with the rest of the company

The “explain” part is where I’ve seen many decisions-makers cut corners and then pay a steep price later on when execution on the decision stretches out or even stalls.

Advertisements
Forget RACI, SPADE will pay off in spades

Problem & Context, even over Solution

Joel Gascoigne, Buffer‘s CEO, penned a really thoughtful piece on his ideal leadership style:

How I try to lead when making changes that affect people

Joel builds on Ben Horowitz’s description of the CEO as the owner of the information architecture in the company.

He captures the crux of the CEO’s challenges as a leader in this quote:

I naturally end up with a unique picture of the whole company, since I’m learning insights from all the different teams and areas. I see patterns across multiple areas, and this leads me to ideas for making changes that could make the whole company more effective.

That’s where the danger comes. I’m both in one of the best positions to notice and implement changes to how we work, and also I’m far removed enough that I might be missing some context about how my ideas for changes could have negative implications.

He then outlines his approach to dealing with this challenge:

  1. I try to have the communication architecture to put me in the best position to understand a lot of the context and to draw patterns between challenges in different areas.
  2. I aim to notice the challenges arising in areas, and spend time to reflect on them in a way that others might not have the viewpoint or time to do so.
  3. Once I start to find myself moving towards a solution for challenges, I stop myself.
  4. I then speak with people who will be affected by any potential changes to solve the challenge I’ve found.
  5. When I speak with people, I try to share all the context, without a solution.
  6. Sometimes I may have a hint of a solution in my mind, however I try to be fully open to a different solution being the optimal one, which I can only learn based on speaking with people.
  7. The goal and result of this method is that often I’m not even the one who comes up with solutions, and the changes we make are more fully embraced.

Steps 1 and 2 are the hallmarks of a good leader, but it’s in step 3 where great leaders get separated from the good. It takes tremendous discipline to stop yourself when you think you know the answer. And rather than issue an edict to execute your solution, loop in the affected people, describe the problem that you’re seeing and the big-picture context that they may be missing, and let them come up with the solution themselves.

 

Problem & Context, even over Solution

Turn the Ship Around (Book Review)

I first heard of David Marquet‘s

Turn the Ship Around

in an Agile conference four years ago, and I added it to my reading queue. For whatever reason, other books kept getting ahead of it (a relatively rare event in my reading queue), until it was mentioned in a book I recently finished causing it to jump back to the top of the queue.

The book chronicles David’s personal story, taking command of an under-performing nuclear submarine, the USS Santa Fe, and transforming it into a top-performing one. What makes this book a worthwhile topic for this blog, is the way David chose to go about doing that: by pushing power/control/decision-making down the chain-of-command – in a complete opposite direction to traditional Navy doctrine.

The biggest lesson learned, in my opinion, from David’s experience is best summarized in his own words:

“Control, we discovered, only works with a competent workforce that understands the organization’s purpose. Hence, as control is divested, both technical competence and organizational clarity need to be strengthened.”

Many books and articles make the case for why pushing control/power/decision making down the org (often times erroneously referred to as “empowerment”) is important. But the tight coupling between doing so, technical competence and organizational clarity was illuminating to me. Reflecting on past situations when I hesitated to delegate control, or did so and was disappointed with the outcome, I can almost always attribute the root cause for my hesitation or disappointment to one, or both, of these elements.

Even though the quote I shared above is taken from the book’s introduction, this is not one of those would-have-been-better-as-a-10-page-HBR-article books. The book adds colors and nuances to this high-level idea, and breaks it down to specific mechanisms that David use to push down control, improve technical competence and enhance the organizational clarity. Many of which can be adapted from a submarine-setting to a corporate-setting (environment that are worth a more in-depth comparing and contrasting).

 

Turn the Ship Around (Book Review)

A Leader’s Guide to Deciding

A good piece by Steven Sinofsky on decision making and the critical role that it plays in an executive’s job:

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

In this post, Steven tries to put some structure on striking the right balance somewhere in between the two extreme ends of the decision making spectrum: being in the center of a command-and-control scheme and fully delegating any decision.

He argues that decision making gets complicated as the organization scale primarily due the number of stakeholders that are being affected by the decision. Based on his experience, typical responsibility assigning schemes (RACI and the likes) tend to slow things down and push responsibility around.

He identifies 3 key pieces to solving the challenge:

  1. “The most important thing an executive must do is keep the output and velocity of the team at the highest level, and focused on doing the right things” – if you understand that this is your #1 job as an executive, you will spend your time, on the right things.
  2. “The real challenge is in trying to define decisions, isolate important ones, and then figure out the stakeholders for that one instance” (as opposed to finding the solution.
  3. Being clear, up front, first of all with yourself, but then with everyone else involved on the role that you intend to play in the project:
    • Initiator (10% of time). Kicking off new projects.
    • Connector (60% of time). Connecting people to others so the work gets better.
    • Amplifier (10% of time). Amplifying the things that are working well or not so there is awareness of success and learning.
    • Editor (20% of time) Fixing or changing things while they are being done.

For each of those roles, he provides a few examples, the communication tools you should use, the granularity of the guidance you should provide, the time you should spend playing this role and the necessary mindset to drive an effective outcome.

As a final note, Steven touches on the exception to the rule: “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”. He ties this advice to Ben Horowitz’s distinction between a “wartime” and “peacetime” CEO, but in my mind, it goes deeper than that. What Steven is describing here, in his own words, are the “complex” and “chaotic” pieces of the Cynefin Model which I’ve covered at length here. It all connects in the end…

 

A Leader’s Guide to Deciding

Taming Complexity with Reversibility

Kent Beck wrote a lovely note on Facebook on the strategy the company adopted to fighting complexity:

Taming Complexity with Reversibility

He argues that complexity is the biggest enemy to scaling. And complexity, in turn, is driven by four different attributes of the system:

  • States. When there are many elements in the system and each can be in one of a large number of states, then figuring out what is going on and what you should do about it grows impossible.
  • Interdependencies. When each element in the system can affect each other element in unpredictable ways, it’s easy to induce harmonics and other non-linear responses, driving the system out of control.
  • Uncertainty. When outside stresses on the system are unpredictable, the system never settles down to an equilibrium.
  • Irreversibility. When the effects of decisions can’t be predicted and they can’t be easily undone, decisions grow prohibitively expensive.

A successful complexity-fighting strategy must focus on eliminating one of those attributes completely and figure out a way to manage the rest.

Since uncertainty is a factor of outside forces that our by definition outside of your control, it is extremely hard to design a strategy focused on it. Strategies focused on reducing the number of states are effective in some cases (Henry Ford’s Mass Production is a notable example). But in complex systems, like software, managing states and predicting interdependencies is incredibly difficult. So instead Facebook chose to focus on eliminating irreversibility in almost everything that they do with their software: for introducing “feature switches”, through doing gradual deployments to having backup internal communication channels in case the site crashes.

A rather compelling case for auditing the full spectrum of decisions your organization makes, identifying the ones that are currently irreversible, and figuring out what it would take to make them reversible.

Taming Complexity with Reversibility

Holacracy or Humacracy? (Book Review)

Holacracy has been on my radar for the last couple of years as an organizational paradigm that’s worth further exploration. I’ve covered some pieces of it on this blog as well.

I was thrilled to learn that Brian Robertson, Holacracy’s creator, has finally written a book about it, and was really looking forward to reading it:

Holacracy: The New Management System for a Rapidly Changing World

If you have no idea what Holacracy is, I won’t suggest jumping straight to the book, but starting with this short article instead:

Here’s Why You Should Care About Holacracy

The book provides the most holistic, yet still readable, description of what Holacracy is really all about (pun intended). Though it still leaves much to be desired (which we’ll get to in a second), it does a great job illustrating how governance and tactical meetings work and touching on some of the less known aspects of Holacracy such as its approach to strategy and to deadlines, both strongly resonating with me. The aspect that would have probably benefited the most from further exploration is the circle-based org structure. It doesn’t address some of the key org design challenges that exist in traditional hierarchical structures, like the need to alternate organization and focus by function, product/service and customer/region. It also enacts a meaningful organizational constraints that doesn’t get acknowledged: if each sub-circle is represented in governance and tactical meetings by both a lead-link and a rep-link, it puts the limit on the number of sub-circles within a circle at about 4-5. Otherwise the number of people attending the meeting quickly jumps to over 10 people, which makes them exponentially more challenging to run.

Sadly, my high level takeaway is that Holacracy is an exciting but incomplete paradigm. And there’s some reason for pessimism since this omission was made by design. Let me explain:

Many of the principles and concepts that Holacracy is based on and consists of strongly resonate with me: roles as living and evolving entities, the radical distribution of authority through the circles-based org structure, the unique and highly effective governance and tactical meeting structure, even thinking about strategy as a set of heuristics rather than a high-level, executable plan.

The one principle that Holacracy takes too far, in my opinion, is the decoupling of “role from soul”. Holacracy accurately observes that under the traditional paradigm, four “spaces” are too tightly coupled:  the person space, the role space, the tribe space and the organization space. A good example is the traditional manager’s job being simultaneously responsible for both for the business outcomes accomplished by her employee (role space) and her employee’s professional growth and development (person space). The solution that Holacracy prescribes is radical decoupling, ignoring the fact that in cases of extreme decoupling, misalignment will lead to chaos. Holacracy explicitly takes the “human spaces” (left column, person+tribe) out of scope:

holacracy

Or, to use a more familiar diagram to the readers of this blog:

od-hol

Dealing with “human spaces” problems such as hiring/firing, compensation, growth, etc. is not part of the Holacracy “operating systems” but mere “add-ons/apps” that each business should figure out on its own, once they adopt Holacracy. Yet at the same time, it’s been acknowledged that Holacracy is at odds with traditional “human spaces” solutions, and the friction between the two is a key cause for some companies attempting to adopt Holacracy but failing to successfully do so. To go back to our manager example, Holacracy offers clear guidance on what to do with half of her traditional responsibilities, but leaves practitioners completely on their own about the other half. To me, that sounds like a classic case of mistaking a bug for a feature.

A fix for this bug, would require viewing the organization as a sociotechnical system, acknowledging that it has a human component that cannot be fully decoupled. The human systems that align with the process components of Holacracy have to be an integral part of the Holacracy “operating system” rather than an add-on “app”.

Note that none of this invalidates any other principles and concepts that are already an integral part of Holacracy. I am confident that Holacracy is a superior organizational paradigm compared to the traditional one. I’m just disappointed that its creators decided to “call it done” and draw the operating system/apps line where they did. I fear that only addressing half of the problem space will have a substantial negative impact on its adoption (and success) rate. To use another software metaphor, they seem to be building the right product, I’m just not sure they have a Minimum Viable Product. Yet.

Holacracy or Humacracy? (Book Review)

Holacracy’s Integrative Decision Making process

I think I’m getting close to coming full-circle on Holacracy. At first I was totally psyched by how radically innovative it is; then the skeptic in me kicked in and it seemed more like an idealistic framework that can never work in a large scale organizations. But the more I study it and similar approaches, it resonates with me more and more. I’m not ready for a full “why is Holacracy awesome?” post, but I do want to focus on one aspect of it that can potentially stand on its own merits:

Holacracy’s Integrative Decision-Making Process

It’s a structured process for making decisions in a group that rings truer to me than both consensus and top-down decision making (the two extremes of the spectrum).

Here’s the gist of the process:

  1. Present Proposal – proposer describes the problem that she saw and the solution she proposes
  2. Clarifying Questions – anyone can ask clarifying questions. Proposer can answer. No reactions or dialog allowed.
  3. Reaction Round – each person can react to the proposal as they see fit. No discussion or responses.
  4. Amend & Clarify – proposer can optionally clarify the intent or amend the proposal based on reactions. No discussion allowed.
  5. Objection Round – The Facilitator asks each person in turn: ”Do you see any reasons why adopting this  proposal would cause harm or move us backwards?” (an “Objection”). Objections are stated, tested, and captured without discussion; the proposal is adopted if none surface.
  6. Integration – The goal is to craft an amended proposal that would not cause the Objection, but that would still address the proposer’s  problem. Focus on each Objection, one at a time. Once all are integrated, go through another Objection Round.

Beyond the meta-benefit of a repeatable, structured, decision-making process the two things that I like the most about this are:

  • Separating getting clarify on the proposal, giving everyone an opportunity to be heard (react) and dealing with material objections into three separate activities. They address three separate needs for the people who are engaging with the proposal and deal with each one separately.
  • Defining a valid objection as something that would “cause harm or move us backward”. This is typically where consensus-based decision making tends to fail.  And also somewhat related to Fred Wilson’s recent post on satisficing  – by setting an agreed-upon acceptable threshold for proposals, we can avoid some of the major pitfalls that cause important decision-making processes to stall.
Holacracy’s Integrative Decision Making process