The Situation
When this Series B fintech approached us, their engineering team of 40 was in a familiar trap: a backlog that had grown to 18 months of work, a sprint cadence that hadn't improved in two years, and an investor board asking hard questions about delivery velocity.
The team wasn't underperforming by traditional standards — they were shipping features, fixing bugs, and maintaining a complex payments infrastructure. But the market was moving faster than they were. Competitors were shipping in weeks what took them months.
The CTO had tried the standard playbook: hiring more engineers, breaking into smaller squads, introducing Scrum ceremonies. None of it meaningfully moved the needle. The constraint wasn't headcount — it was the workflow itself.
The Diagnosis
We spent the first week mapping their actual delivery pipeline, not the idealised one on the Jira board. What we found was typical: the 22-day average cycle time contained about 4 days of actual work, surrounded by 18 days of waiting, translating, and re-doing.
- Requirements: Tickets were written in product language, not engineering language. Engineers spent days clarifying before writing a line of code.
- Architecture: Every non-trivial feature required a design doc that went through 3–5 async review rounds.
- Development: Engineers were context-switching between 3–4 features simultaneously, none getting full attention.
- Code review: PRs sat for an average of 2.3 days before first review. Large PRs were the norm — reviewers often rubberstamped them.
- QA: A dedicated QA team was catching bugs that should have been caught in development — a sign that testing was an afterthought.
The diagnosis: they had an information latency problem, not a people problem. Claude Code was the right intervention.
The Transformation
We ran a 6-week Claude Code transformation programme across their three core squads. The programme covered four shifts:
1. Spec-First Development
Engineers were trained to start every feature by generating a technical spec with Claude Code before touching the codebase. The spec — including data models, acceptance criteria, and edge cases — was reviewed and approved before any development began. Clarification questions dropped by 80% within two weeks.
2. Claude Code as a Pair Partner
We moved engineers from "write code, use Claude to review" to "direct Claude to write, then review and refine." This is a non-obvious shift — it requires engineers to develop strong prompt patterns and learn to validate AI output critically. We ran daily coaching sessions for the first three weeks.
3. Small PR Discipline
Because Claude Code generates code faster, the temptation is to batch more into each PR. We did the opposite — enforcing a strict 200-line PR limit and using Claude Code to auto-generate PR summaries that made review fast and focused. Review time dropped from 2.3 days to under 3 hours.
4. Test-First with Claude
We introduced a rule: Claude Code writes the tests from the spec before writing the implementation. This forced spec clarity (you can't write tests against an ambiguous requirement) and meant QA was verifying, not discovering.
The Results
By week 6, the team's average feature cycle time had dropped from 22 days to 4 days — a 5.5x improvement. Production bug rates dropped 67%. The team cleared 6 months of backlog in 8 weeks without adding a single headcount.
The CTO's comment at the end of the programme: "We didn't need more engineers. We needed a better way to use the ones we had."
The team continues to run the Claude Code workflow autonomously. We do a monthly velocity review to identify new optimisation opportunities as the tooling evolves.
Key Takeaways
- Claude Code works best as a workflow change, not just a tool adoption
- The biggest gains come from the edges of the development cycle — specs and tests — not the middle
- Coaching matters as much as tooling. Engineers need to unlearn habits before they can build new ones
- Small PRs + AI-generated summaries eliminate most of the code review bottleneck