February 16, 2021.
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:
This isn’t a perfect approach, but it’s good enough in my experience.