Why is my dev team slow?

Most engineering teams that feel slow are not slow because the developers are bad. They are slow because of one or two specific, findable problems: an unclear delivery process, a review and testing gap that makes every release risky, an architecture that fights the team, metrics nobody trusts, or a structure where every decision waits on one person. An engineering team audit is a one to two week, fixed-fee diagnosis of which of those it is for you, delivered as a written assessment you keep either way.

The symptoms I actually hear

Before I open a single repository, this is usually already true:

• Every release feels risky, so releases happen less often, which makes each one riskier still.
• Nobody can explain why the last sprint slipped, only that it did, again.
• Every technical decision, small or large, ends up on the CEO's or a single lead's desk.
• The team adopted AI coding tools months ago and nothing measurable changed.
• Your best engineer has quietly started taking recruiter calls, and you can't say exactly why.

That AI point is common enough to be worth a number: only 23% of companies get a measurable financial return from AI, and 69% are still running pilots (Deloitte-HKU AI Adoption Index, 2026). Adoption without a result is a process problem, not a tooling problem, and it is exactly the kind of thing an audit finds.

What I actually look at

Five areas, in this order:

• Delivery. How work moves from idea to production: planning, branching, review, release cadence, and where it actually gets stuck.
• Quality. Test coverage that means something, what breaks in production and why, and whether AI-authored code is reviewed with the rigor it needs. CodeRabbit's State of AI vs Human Code Generation Report found AI-authored pull requests had about 1.7x more issues than human-only ones (470 pull requests, December 2025).
• Process. Whether the team's rituals produce decisions or just meetings.
• Architecture. Whether the system's shape is the reason things are slow, and whether the fix is a rebuild, a rewrite of one component, or a build-versus-buy decision nobody has made yet.
• People. Who can make a decision without escalating it, and who is quietly a bottleneck because nobody has ever asked them to stop being one.

None of these five sit in isolation. A quality problem is usually a process problem wearing a different name, and a people bottleneck is usually what happens when nobody owns architecture decisions clearly enough. The audit's job is to find which one is actually driving the other four, not hand you five separate complaints and call it a diagnosis.

Who this fits, and who it doesn't

The audit tends to be the right first step for:

• An SME or scale-up with an existing engineering team, roughly five to fifty engineers, that everyone agrees ships slower than it should, but nobody can say precisely why.
• A CEO or founder inheriting a team they didn't hire, who needs an outside, technical read on what's actually going on before making people or process changes.
• A team that has already adopted AI coding tools and wants to know whether the gap is tooling, review discipline, or something upstream of both.

It is the wrong fit if you already know the answer and just need hands to fix it, in which case skip straight to an engagement, or if your team has no engineers yet, in which case building the first version is the actual job.

What you get: the written assessment

The audit runs one to two weeks, for a fixed fee, and ends with a written assessment: what is actually slow, why, ranked by impact, and what I would do about each one. It is not a slide deck built to justify a bigger engagement. If the honest finding is "hire two mid-level engineers and stop here," that is what it says. If it is "your team needs to move to AI-native workflows," that is covered on how I run that transition. Either way, the plan is yours to execute with or without me.

How the audit runs

Same three steps as any engagement: a free intro call, then the diagnostic itself, one to two weeks, fixed fee, and only after that a decision about an ongoing engagement, priced as a fixed monthly retainer if you want one. Nothing is billed by the hour, and nothing continues past the audit without you choosing it.

Worth being precise about what the audit is not. It is a point-in-time diagnosis: it finds where delivery is broken today and tells you why. Keeping it fixed once the gaps are closed is a different, ongoing job, the measurement and org structure that stop the same problems creeping back, which is what engineering OKRs and KPIs covers. The audit finds the gaps; that page is how you keep them closed.

Frequently asked questions