Things that aren't engineering strategy.

This is pruned from 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.