Conversation 4: On "Moving Faster"

The question you will hear: "We need to move faster. Why aren't we faster yet?"

Your stance: Speed is what you get when you stop doing things, not when you add tools.

AI helps with one slice of the pipeline: the initial drafting of code. The rest is unchanged. Code review, testing, deployment safety, on-call burden, security review, support escalations, and the cognitive load of maintaining everything already in production—that is still there. In some respects it is worse, because faster code generation means more code to review, integrate, and operate. The machine accelerates production. It does not accelerate validation.

How to lead in that room: Make the trade-off visible. Here are three things we could stop investing in to free capacity for the new priority. Here is what we would accept in terms of risk or quality. Here is what would break.

Force the conversation from "engineering is slow" to "the executive team is making a prioritization decision together." Stop being the person who says no. Become the person who frames the choice.

Before	After
Speed pursued by demanding more output	Speed pursued by explicit trade-offs about what to stop
Technology leader blamed for slow delivery	Executive team collectively owns prioritization
AI tools expected to triple throughput	AI tools expected to shift bottleneck to review and operations
Roadmaps expand to absorb perceived new capacity	Roadmaps trimmed to match actual validated throughput
"Move faster" as a motivational directive	"Move faster" as resource reallocation with visible consequences

What to avoid: Explaining why engineering is slow without offering subtraction options. Accepting the premise that AI should triple throughput. Letting the conversation become "engineering is the bottleneck."