A survey of engineering strategies.

This is pruned fromEngineering 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收集更多的在这里):

• Anna Shipman wroteThe difficult teenage years: Setting tech strategy after a launch, which applies theGood Strategy, Bad Strategydefinition of strategy against an engineering predicament to good success.
• Damian Schenkelman wroteAchieving Alignment and Efficiency Through a Technical Strategy, which uses strategy definition to improve technology decision making.
• Daniel Schauenberg wrote inLearning to have an engineering visionabout 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 wroteHow 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 wroteDelivering 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 wroteDefining 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 wroteRun less softwarewhich 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 wroteMagnitudes of explorationwhich 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.