← back to writing
-

Speed of execution is a culture output, not a process input

Adding more process to a slow team makes it slower. I’ve watched it happen more than once. The team is missing deadlines, so leadership adds a weekly status meeting. The team misses more deadlines, so they add a daily standup. The team misses more deadlines, so they bring in a project manager and a Jira workflow with eight mandatory fields.

At the end of this, the team is very busy attending meetings and filling in fields. They are not faster.

What process actually does

Process creates visibility. It makes work trackable, auditable, and legible to people who aren’t doing the work. These are real and valuable properties.

Process does not create speed. It can’t. Speed requires something process can’t provide: people who know what they’re supposed to do, trust that the decision they’re making is the right one to make, and feel genuine ownership of the outcome.

The three real inputs to execution speed

Clarity. Teams slow down when they’re not sure what they’re supposed to be doing, why it matters, or what “done” looks like. Every cycle spent on clarification, re-alignment, or rework from misunderstood requirements is a speed tax. The solution is upfront investment in expectation setting — which feels slow in week one and pays back across the entire quarter.

Trust. Teams slow down when every decision needs approval. When engineers don’t feel empowered to make the call, they wait. They schedule a meeting. They write a proposal. They wait for the meeting. The accumulated latency of decisions that could have been made in five minutes but instead took five days is enormous, and mostly invisible.

Ownership. Teams slow down when nobody feels responsible for the outcome. Ownership is not the same as assignment. An engineer who’s been assigned a task will complete it. An engineer who owns an outcome will do whatever is necessary to get there — including flagging problems early, making uncomfortable calls, and working across team boundaries.

The diagnosis question

When a team is slow, the right question is not “what process are we missing?” It’s “which of these three is broken?”

Usually it’s clarity. Most team speed problems trace back to insufficient expectation setting at the start — unclear goals, undefined success criteria, unspoken trade-offs. The team works hard in slightly wrong directions and only discovers the misalignment when it’s expensive to fix.

Sometimes it’s trust. This shows up as a process problem: too many approvals, too many checkpoints. The process is a symptom. The cause is that someone doesn’t trust the team to make good decisions without oversight.

Occasionally it’s ownership. This usually means the work has been decomposed across too many owners, or that incentives and accountability are misaligned.

What this means for leaders

If your team is slow, start with clarity. Write down what you’re trying to achieve, why it matters, and what success looks like. Share it before the kickoff meeting. Pressure-test it with the team.

Then look at trust. Ask yourself honestly: are there decisions my team should be making that currently come to me?

Process comes last. Once you have clarity, trust, and ownership in place, process exists to make good work visible and repeatable — not to compensate for their absence.

Speed is what happens when everything else is working. It cannot be installed directly.