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:

- A survey of engineering strategies.
- Things that aren't engineering strategy.
- Care and feeding for your engineering strategy.
- Surplus rules of engineering strategy.
- Engineering strategy every org should write.

A survey of engineering strategies.

This is pruned from an in-progress article on engineering strategy.

Before attempting to document what an engineering strategy ought to be, it’s useful to sharpen a related problem statement: why do engineering teams decide to write an engineering strategy?

One way to answer that is to work through a handful of the engineering strategies, technical visions, architecture strategies, and so on that folks have written about publicly (I’ve collected more here):

• Anna Shipman wrote The difficult teenage years: Setting tech strategy after a launch, which applies the Good Strategy, Bad Strategy definition of strategy against an engineering predicament to good success.
• Damian Schenkelman wrote Achieving Alignment and Efficiency Through a Technical Strategy, which uses strategy definition to improve technology decision making.
• Daniel Schauenberg wrote in Learning to have an engineering vision about using VSMO for an infrastructure team, and describes how an overly broad vision misaligned the team’s work with their wider organization.
• Keith Adams and Johnny Rodgers wrote How Big Technical Changes Happen at Slack, which centers on the problem statement of, “Slack wants to make sure we catch revolutions at the right time, while limiting the energy we spend chasing fads. What strategy can we follow to ensure this?” Their answer is, “We should explore some…. be a reasonable consumer of other teams technology… break dependencies… [and drive change] with a customer-centric attitude.”
• Pete Hodgson wrote Delivering on an architecture strategy, which is focused on balancing between product-oriented and technology-oriented work. The core of these strategies are a “Strategic Architectural Initiative” composed of three parts: target state, current state, and next steps.
• Sarah Taraporewalla wrote Defining a Tech Strategy, which defines a Tech Strategy document. The proposed sections are: vision, values, architecture vision and roadmap, cross functional requirements, accepted default for tools, and architecture operating model.
• Rich Archbold wrote Run less software which describes Intercom’s strategy for selecting technology platforms. He summarizes the strategy in three pillars: “Choose standard technology. Outsource undifferentiated heavy lifting. Create enduring competitive advantage.”
• When I was at Stripe, I wrote Magnitudes of exploration which summarized our engineering strategy regarding reusing existing technology versus adopting new technologies. The short summary was, “Mostly standardize, exploration should drive order of magnitude improvement, and limit concurrent explorations.”

While these cover quite a bit of ground, a handful of core questions emerge:

• What will our organization look like in two to three years?
• How does my team fit into the broader organization?
• What are our approved technologies?
• How do we evaluate and adopt new technologies?
• How will we use our approved technologies on this particular project?

This is a broad swath of questions to answer, but I believe a good engineering strategy can indeed address all of them.

Things that aren't engineering strategy.

This is pruned from an in-progress article on engineering strategy.

When you’re writing an engineering strategy, what you put in is important, but it’s almost as important to be deliberate about what you choose to leave out. The full list of things to exclude is uncountably vast, but there are a few worth emphasizing in particular.

LinkedIn’s Jeff Weiner documented their hierarchy of operating documents as Vision, Mission, Strategy, Objectives, Priorities, Culture, and Values (which some companies have standardized as VSMO). Some of those are very helpful, but two to leave out when writing an engineering strategy are “culture” and “values.” These are quite important, but must be handled at the company scope rather than the engineering scope. Organizations within a company that go too far in shaping values distinct from the company values inevitably create a Values Oasis: a short-term workaround that requires more and more maintenance energy from your organizational leadership until eventually they have little time for anything else. If you want to define engineering specific values, channel that energy towards aligning with the broader company’s values instead.

A third VSMO idea that I’ve excluded is “mission.” I’ve almost universally found that team and organizational mission statements create more confusion and misalignment than they resolve. Mission statements are an attempt to rewrite reality with force of desire, which is, I’m sad to say, folly. Mission statements are treated as statements of truth about what a team ought to be doing, but this is a fundamentally misunderstanding of why teams exist: they exist to support the business, and in the case of engineering teams, they generally do so by supporting other teams. A team’s purpose depends much more heavily on what their users need than on what they want to be working on.

Further, mission statements fall afoul of both the “don’t generalize” and “don’t lie” rules of effective engineering strategy. Most mission statements create confusion by articulating the team’s desired state rather than their actual state. They also tend to be overly broad in a way that causes incompatible interpretations. Finally, they tend to overstep to “claim territory” from other related teams, wasting energy on folks competing to “own” areas that neither team is capable of actually supporting. Rather than a team mission, write a team strategy explaining your guiding policies to navigate your current circumstances.

Finally, abandon your plan to proclaim axiomatic truths. It’s extremely tempting to start out your engineering strategy by writing a series of bold statements about reality—Simple code is good code! Optimize for discounted future developer velocity!—but lists of commandments are dead documents on arrival that cannot evolve with your organization as you grow. Instead of writing axioms, write a strategy explaining why these are important and fold it into your quality measure. That will create a living document that folks can evolve with you and lives beyond your tenure.

Care and feeding for your engineering strategy.

This is pruned from an in-progress article on engineering strategy.

If by some act of perseverance and skill you write an engineering strategy that’s well-received by your organization, then you’re faced with the next challenge. How do you keep this living document alive past that initial burst of excitement?

The most important thing to remember is to continue steering attention its way. Refer back to it frequently when you’re doing system design or resolving a disagreement on approach. Track the areas where it doesn’t provide clarity and revisit them in batch periodically.

Mark your calendar a few times a year to reread the core components as well as review the latest batch of junctures. There’s a wisdom that emerges from reviewing many junctures together that you can’t find from looking at them individually. A good time to do this is when you’re writing your quarterly or annual retrospectives: did your work actually align with your strategy?!

It’s also helpful to review your strategy with new engineers as they join your team. You’ll become numb to its oddities and inaccuracies, and new eyes are always the sharpest. As they point out issues, address them!

If you’re pondering whether your strategy is working, one useful measurement of your strategy’s effectiveness is how often it’s referred to within technical specs and technical spec reviews, but you can go a bit further afield. An effective engineering strategy will allow more distinct engineers to write technical specs, reduce the time for technical specs to be written, and reduce the time for technical specs to be approved.

Of course, when you start measuring the efficiency of technical spec creation, remember that some are better than none, but having many is cause for concern rather than celebration. Your engineering strategy is a failure if it forces the creation of numerous, low-value technical specifications.

Maintaining a good strategy is work and requires ongoing evangelism. If that doesn’t seem like the sort of time investment you want to make, then consider if your engineering strategy is really pulling its weight at all. It’s fine to deprecate and come back later.

Surplus rules of engineering strategy.

This is pruned from an in-progress article on engineering strategy.

While sharing my advice for writing an engineering strategy, my second draft had an extended section of “rules for writing engineering strategies.” I think these were all useful, but it was a piece that suffered for too many ideas, and I ended up removing most of them.

I think they’re useful, so I’ve included them here. For context, the rules that I kept in the original piece are:

1. Start where you are (start small; start local)
2. Write the specifics (stop when you want to generalize)
3. Show your work (don’t make unsupported statements)

A few more to add to that list.

Every missing document is missing for a good reason

If you’re wondering why an engineering strategy doesn’t exist, it’s helpful to remember a variant on Lara Hogan’s Why Can’t They Just…?: every missing document is missing for a good reason.

It sure would be helpful if you had a clearly articulated business strategy before you started writing your engineering strategy, but every missing document is missing for a good reason. It sure would be easier to write your product engineering strategy if there was an engineering strategy or an infrastructure strategy written already, but–again for the folks in the back–every missing document is missing for a good reason.

Which brings us to the second surplus rule...

Don’t block on what you don’t know

An engineering strategy tries to address a broad, ambiguous problem space. There are more things you don’t know than you do know when you try to write this sort of document, and if you allow yourself to be intimidated by this ambiguity than you will simply never start.

As ambiguity mounts, invest less energy into the details and more into the direction. Focus less on perfection and more on using your provisional strategy document as a tool to drive clarity in the other missing documents. The more you’re able to brave the gaping maw of uncertainty, you’ll build the foundation for others to write their pieces as well.

That’s why you have to…

Fill the empty page

It’s easy to get caught up on trying to write something good or even great in your first attempt to write a strategy, but it’s far more important to write anything at all than to wait until you can write something good.

Once you’ve started writing something, other folks are able to join in and help improve your ideas. They may even hate what you’ve written so much that you unlock their ability to write a strategy of their own in protest of yours. When you’re getting started, momentum towards quality is far more important than initial quality.

Just start writing, but remember to…

Stick to what you know.

The negative framing of this rule is, “Don’t lie.” It’s tempting when you write an engineering strategy to talk about what you wish was true rather than what is true. You may hate your monolithic codebase and wish that your company was writing services for all new development, but if your company isn’t implementing new functionality in separate services, then you’ve not written a strategy at all, merely a trap for trusting peers.

There are undoubtedly more rules to writing engineering strategy, but hopefully these will be useful as you start your process.

Engineering strategy every org should write.

Writing my recent article on Engineering strategy was one of the most challenging pieces of writing I’ve done in the past few years because I had far more ideas than I could fit into a coherent narrative. I extracted a number of those into semi-edited snippets filed under the “strategy” tag, and here is the last one in that vein.

The question I want to briefly explore here is, “What strategies should most engineering organizations try to document?” I’ve taken a somewhat overly broad view of what you might consider an engineering strategy, including both technical and organizational aspects.

An unordered list of strategies I would recommend every engineering organization document as they grow are:

1. How do we review, merge, deploy, and release code?
2. What are our approved technologies for new projects?
3. When and how do we deprecate user-facing functionality?
4. When and how do we deprecate internal tools?
5. How do we document our software and process?
6. Because this is a surprisingly controversial topic, explicitly which tools do we and don’t we use for documentation?
7. How do we evaluate, select and adopt new technologies?
8. How do we migrate away from our existing technologies?
9. How do we respond to incidents?
10. How do we identify and prioritize incident remediations?
11. How do folks switch teams?
12. How do you staff work on ‘unowned” areas and tools?
13. How do folks move from individual contributor track to management track? How do they move back?
14. How do you think about evaluating internal versus external candidates for scarce roles?
15. How do you empower senior engineers to contribute to the engineering organization beyond day-to-day technical contributions?

For many of these, you could argue that they are more policy than strategy. That’s a reasonable argument, but for me the distinction is that you turn a policy into a strategy by explaining the rationale behind it: a policy is just an incomplete strategy.

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