Will Larson lethain

Engineering Decision-Making Strategy

Our engineering organization lacks a clear, consistent process for making software architecture decisions, leading to friction between engineers who feel excluded from decisions versus those who feel slowed down by lengthy approval processes. This ambiguity around decision-making authority—particularly when a few highly opinionated engineers can effectively overrule others' work—is reducing overall engineering velocity and creating frustration across the team.

Key Feedback on Engineering Decision-Making Strategy

1. Measure AAG Bottleneck Risk

The strategy should include specific metrics to detect if the AAG becomes a bottleneck:

Time from ADR submission to initial AAG feedback
Time from ADR submission to final decision
Queue depth of pending reviews
Percentage of decisions requiring escalation beyond AAG

Without these measurements, you won't know if the AAG is helping or hindering velocity until it's too late.

#	Claim (quoted or paraphrased)	Why it needs support	What to add
U-1	“Senior engineers spend significant time in reactive architectural debates rather than proactive l

| # | Where | Why it’s a problem | Suggested fix | | ------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

onlinewardleymaps.com syntax

This is a file used for in-context learning to generate onlinewardleymaps.com style Wardley Maps. Example maps are separated by lines with headers that start with "##". Each map itself starts with "title <map's title>" and ends with a line composed of "style wardley".

Compute Ecosystem Map

title Compute Ecosystem

Engineering Decision-Making Strategy

Our engineering organization lacks a clear, consistent process for making software architecture decisions, leading to friction between engineers who feel excluded from decisions versus those who feel slowed down by lengthy approval processes. This ambiguity around decision-making authority—particularly when a few highly opinionated engineers can effectively overrule others' work—is reducing overall engineering velocity and creating frustration across the team.

Engineering Architecture Decision-Making Strategy

Reading this document

To apply this strategy, start at the top with Policy. To understand the thinking behind this strategy, read sections in reverse order, starting with Explore, then Diagnose and so on.

More detail on this structure in Making a readable Engineering Strategy document.

Policy & Operation

Engineering Architecture Decision-Making Strategy

Executive Summary: We will implement a federated architecture decision framework combining team autonomy with coordinated oversight, using Architecture Decision Records for documentation and a lightweight advisory process to eliminate decision-making ambiguity while maintaining engineering velocity.

Policy

Our policies for engineering architecture decision-making are:

1. Federated Decision Authority Framework

Team-Level Decisions: Product engineering teams have full authority over architecture decisions that affect only their services and don't create cross-team dependencies

	## User & Value Chains

	Gitlab describes itself as “most comprehensive AI-powered DevSecOps platform.” This is a broad ambition, and consequently there are quite a few users for the platform. For this mapping exercise, we are going to focus on four users:

	1. Developers at the company. The product and infrastructure engineers who are using the Gitlab platform as a tool within their workflows. These are the developers responsible for creating and running the company’s product.

	The value chains they’re focused on are deploying software, debugging failed deploys, and optimizing the speed at which builds and deploys occur. Underneath those needs are a number of infrastructure components performing the actual deploy, collecting logs for debugging, and so on.
	2. Developer Experience who are responsible for selecting, onboarding and operating the deployment infrastructure in the company. More broadly, this team is responsible for the overall productivity of the company’s developers.

	They don’t

	title GitLab DevSecOps Platform
	anchor Developers [0.95, 0.2]
	anchor Developer Experience [0.95, 0.4]
	anchor Security & Compliance [0.95, 0.6]
	anchor Finance [0.95, 0.8]

	component Deploy Software [0.85, 0.15]
	component Debug Failed Deploys [0.8, 0.25]
	component Optimize Build Speed [0.75, 0.3]