Will Larson lethain

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

#	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

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.

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.

	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]

	## 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