Mailbag: Building alignment around a new strategy.

staff-eng (15), mailbag (12)

Another question regarding Staff Engineer that came in recently:

There was a bit in your book where you mentioned after you finished writing your vision - that you shared it out because you were very excited (and then trying not to be let down by not hearing much back in terms of response). Was curious if you could share more about how you think about sharing larger technical visions or strategies. Do you start with smaller circles? Do you send out to everyone at once? Do you introduce it at an All Hands meeting? Do you have comments turned on? We’re experimenting with some different ways right now, but don’t think we’ve nailed mass cross-organizational consensus building - at least not efficiently. Maybe that’s not possible?

For context, this question is referencing the end of Writing engineering strategy:

After you finish writing your vision, the first step folks usually take is sharing it widely across the engineering organization. There is so much work behind the vision–five design docs for each strategy, five strategies for one vision–it’s hard not to get excited when you’re done. So excited that it’s easy to get discouraged, then, when the response to your strategy will almost always be muted. There are a few reasons for the muted response. First, the core audience for your vision is folks writing strategies, which is a relatively small cohort. Second, a great vision is usually so obvious that it bores more than it excites.

Don’t measure vision by the initial excitement it creates. Instead, measure it by reading a design document from two years ago and then one from last week; if there’s marked improvement, then your vision is good.

There’s really no way to avoid the truth here: making decisions in a large engineering organization can be a real grind. One of the techniques I’ve developed to address this is the working group, specifically with a structured process for gathering feedback and identifying working group members. Mark wrote a good post about how we use this model at Calm.

The structured working group model does a great job of building alignment, but over time I’ve come to appreciate that sometimes they don’t generate great work. Groups usually make worse decisions than individuals, even for activities where you’ve likely been taught the opposite, like brainstorming. This isn’t a refutation of the working group model, it’s more a tweak in how they work. Do the initial research as a group, and iterate on the proposal as a group, but don’t try to write the proposal as a group. Instead identify one member to take the lead on synthesizing the research into a proposal, delegating specific sections to other working group members as necessary.

The most common way that working groups fail is that they encounter a vocal minority that filibusters their proposal. Consensus doesn’t scale to very large groups, but it’s surprising how many organizations implicitly rely on consensus for overarching decisions. Organizations either develop a practice of genuinely following disagree-and-commit, or they end up relying on frequent escalations to make forward progress (sometimes these are lateral escalations to blessed decision owners in a given area like a data architect for data modeling decisions, etc). Awkwardly, companies that depend on frequent escalations almost never acknowledge this reliance, which makes many folks working there ineffective, because they continue to view escalations as a failure of diplomancy rather than simply the way the organization works.

Pulling all these threads together to directly answer the question, my general approach to these sorts of problems is:

  1. Write a clear problem statement, soliciting feedback from stakeholders to ensure it’s genuinely the right problem statement
  2. Create a working group around solving that problem statement, including the right folks to build consensus among key stakeholders
  3. Proactively solicit feedback and input for the working group, focusing on mining for dissent from the folks who are most likely to have objections
  4. Have one person within the group synthesize all the research into a proposal
  5. Iterate within the working group until members are aligned on approach
  6. Share a non-commentable document with the organization, along with an invite to a Q&A session about the proposal. Also solicit written feedback as documents rather than comments (document comments encourage nit-picks and minute feedback rather than more useful big picture feedback)
  7. Spend extra time with the folks who are really frustrated, trying to understand their frustration. Figure out who within the working group is best positioned to address each concerned party
  8. Once the rate of useful feedback slows, incorporate what you’ve gotten into the proposal
  9. Align with all stakeholders in a single thread to ensure there’s joint commitment to the proposal. If there’s a small disagreement, iterate a bit until it’s resolved. If it’s a structural disagreement, escalate to someone who can effectively resolve the disagreement
  10. Share the approach with the organization in Slack. In an email. At the All Hands. At new hire onboarding. Basically, never stop sharing it if it’s something you want folks to actually remember. How far you go will depend on the size of the strategy or decision, but generally speaking these things are undershared. This is doubly true in a fast growing organization where new folks won’t know about whatever decision you made last quarter

This isn’t a perfect approach, but it’s good enough in my experience.