Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- Mailbag: How to encourage good documents rather than perfect documents?
- Mailbag: Building alignment around a new strategy.

Mailbag: How to encourage good documents rather than perfect documents?

A great question on Staff Engineer that I received recently:

When you’re writing docs (and reviewing them) I really resonated with the idea of pushing for them to be good and not perfect. Was curious how you go about fostering that culture beyond yourself? I feel like since we’ve shifted to a remote culture, doc grooming has reached an all time high. Also curious if that’s something you’ve felt at all?

There’s an increasingly pervasive belief that written communication is the “obviously best” communication culture. This was initially driven by the cultural export of Amazon’s memo culture, and has been bolstered recently by tailwinds from the pandemic-driven shift to remote work. I’m quite partial to written communication, but it’s a challenging shift. This question hits on one way this shift can get awry: an emphasis on perfection rather than good slowing down discussions.

This is a fairly familiar problem for engineering teams. It comes up frequently in system design, in the tension between YAGNI and not wanting to rewrite the system in six months. Even more commonly, most engineers have been on a team where the perception of nit picking feedback during code review leads to only sharing pull requests for review after the approach has calcified beyond alteration.

The example of code review is probably the most familiar, so we can think about how the tactics for debugging a flailing code review process can be applied to writing culture:

1. People hide work because they’re uncomfortable. If documents are being shared late, it’s because some aspect of the sharing process is making authors uncomfortable. Usually this is because the feedback they’re receiving isn’t helping them accomplish their goal. Maybe there’s too much feedback and folks are waiting until late to share to minimize responses. Maybe the feedback isn’t useful, so folks don’t bother requesting feedback until they’re past the point of cheaply incorporating new ideas.
2. There’s probably four people at your company who make documents uncomfortable. Before you start thinking about a systems level solution to this problem, I’d guess that there are a very small number of people who need to be given direct coaching on how to provide feedback on documents. If you hold them accountable for how they engage with other folks documents, that conceivably might be enough to solve the entire problem.
3. Provide a structured template and document lifecycle. A flexible document template will eliminate debate on structural issues. A document lifecycle process will make it clear when to provide which kinds of feedback. The template and lifecycle act like a code linter in code review, moving feedback away from style and towards substance.
4. There’s a teachable skill to reviewing documents. If you ask someone to edit a document, a surprising number of folks will immediately gravitate to tweaking words or providing grammatical feedback. Sometimes this is useful, but it usually isn’t. While engineers tend to become better at code review with frequent repetition, most don’t do enough document review to get good at it. Fortunately, this is a teachable skill. Have folks read the entire document once before leaving any comments (avoiding the dreaded “but this is addressed later...” response). Focus feedback on the ideas rather than the format.
5. Provide a designated friendly reviewer / writing coach. Going further, most folks don’t have much experience writing documents either! You can reduce the perceived risk of sharing a document by providing a writing coach, probably an experienced engineer in their area, who can provide very early feedback. This coach will also be in a great position to nudge folks to ship their document when it’s “good enough” rather than continuing to polish it. This person also provide “social proof” for the person sharing the document, loaning their privilege as a senior engineer to the author that their document is indeed ready to share.
6. Provide a repository of “golden documents” with the right quality level. I bet you already have a list of “example documents” that folks should emulate, and I bet they are absolutely incredible documents. Which is to say, that they are absolutely not the example you want folks to follow if there is too much emphasis on perfection. Create a new list of “golden documents” which aren’t necessarily the best documents but instead those at the correct level of quality. Ideally you should even acknowledge the documents which are “too good.” Yes, they’re beautiful, but no, that’s not what we’re trying to do here.

Of all those things, I think the most effective approaches are continuing to model “good rather than perfect” behavior yourself, pushing other leaders to model that behavior as well, and lending your privilege for imperfection to authors who take a larger risk when publishing imperfect work.

Mailbag: Building alignment around a new strategy.

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 organizaiton 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.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!