A survey of engineering strategies.

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