Monolith vs Services: The Velocity Problem That Wasn’t Architectural
A freight brokerage marketplace (190 engineers, ~$2B GMV) watched median cycle time climb from 9 to 34 days while headcount nearly doubled, and planned an 18-month, 40-service microservices migration with a 12-person platform team. Envion instrumented nine months of delivery data: 56% of cycle time was cross-team dependency wait, manufactured by layer-organized teams — only ~5% was plausibly the monolith’s fault. The recommendation: reorganize into stream-aligned teams, enforce module boundaries inside the monolith, extract exactly two evidence-backed services, and fix the delivery pipeline. Median cycle time fell to 7 days at roughly a quarter of the migration’s planned cost.
The challenge
Feature delivery had slowed measurably: median cycle time from ticket start to production had gone from 9 days to 34 over two years, while headcount nearly doubled. The diagnosis inside the company was unanimous — the monolith was the bottleneck — and a plan existed to decompose it into roughly 40 services over 18 months, with a dedicated platform team of 12.
The board asked Envion to validate the plan before funding it. The CTO, to his credit, asked for a genuine assessment rather than a rubber stamp.
Roughly 190 engineers had been told microservices were coming, and several had joined expecting to work on it — any recommendation would have to survive contact with that expectation.
Decision path
Envion measured where time actually went, instrumenting the delivery pipeline across nine months of tickets. The median 34-day cycle time decomposed as: 2.1 days coding, 1.4 days in review queue, 19 days waiting on another team, 6 days in a shared staging environment queue, 4 days in release coordination, 1.5 days deploying. Roughly 5% of cycle time was spent on activity the monolith could plausibly be blamed for. 56% was cross-team dependency wait.
Mapping team ownership against the codebase found the actual pathology: teams organized by technical layer — frontend, API, data, integrations — so every customer-facing feature required coordinated work from three or four of them. Conway's law was operating in reverse: the organization was manufacturing the dependencies, and the architecture was merely where they became visible. Envion modelled the proposed split: converting in-process function calls into network calls between the same teams that already couldn't coordinate would likely make cycle time worse — a cross-team dependency becomes considerably more expensive once it crosses a service boundary, a deployment schedule and an API contract.
Envion contribution
Envion did not conclude the architecture was fine. Two areas genuinely hurt: the carrier integrations module — 60+ external APIs, all deploying on the monolith's release train, with one flaky integration able to block everything — and the pricing engine, which had genuinely different scaling and latency requirements from the rest of the system.
The environment constraint was quantified too: nine days of median cycle time sat in staging queues and release coordination — a single shared staging environment and a weekly release train requiring sign-off from four teams. Cheap to fix, and entirely unaddressed by the migration plan.
Envion also wrote the part senior leaders find most useful: a short, plain-language rationale the CTO could take to an engineering organization that wanted the migration.
Delivery
Envion recommended not funding the 40-service migration, and proposed a sequenced alternative. First, reorganize into stream-aligned teams immediately: eight cross-functional teams owning end-to-end customer capabilities — quoting, booking, carrier onboarding, payments — each with frontend, backend and data capability inside it. A people decision, not a technical one — and Envion was clear it was both the hardest part and the one that produced most of the gain.
Second, enforce module boundaries inside the monolith over three months: a modular monolith with owned modules, enforced import rules and per-module test suites — team autonomy over code without distributed-systems overhead. Third, extract exactly two services over six months: carrier integrations and the pricing engine, where the case was evidence-based rather than architectural fashion. Fourth, fix the delivery pipeline in six weeks, in parallel: ephemeral per-branch environments, independent module deploys, no release train.
Outcome and evidence
Fourteen months on: median cycle time fell from 34 days to 7. Cross-team dependency wait dropped from 19 days to 2. Deploys went from one per week on a release train to 60+. Two services extracted instead of the planned forty. Change failure rate fell from 14% to 4%. The platform team required 4 people instead of 12. Programme cost came to ~€1.3M against €5.4M planned.
Around 40% of the improvement arrived in the first eight weeks — before any architectural work at all — from the team reorganization and the environment fixes. The lessons generalize: measure where cycle time actually goes before choosing a remedy; your team structure will reproduce itself in your architecture; extract services with evidence — a genuine difference in scaling profile, release cadence, failure isolation need or ownership — not by default; and do the cheap, unglamorous things first.
| Metric | Before | After |
|---|---|---|
| Median cycle time | 34 days | 7 days |
| Cross-team dependency wait | 19 days | 2 days |
| Deploys per week | 1 (release train) | 60+ |
| Services extracted | 0 (40 planned) | 2 |
| Change failure rate | 14% | 4% |
| Platform team headcount required | 12 (planned) | 4 |
| Programme cost | €5.4M (18mo, planned) | ~€1.3M |
Client feedback
What the client says about this engagement
“The uncomfortable finding was that our architecture wasn't the problem, our org chart was, and I'd built that org chart. Envion put nine months of our own pipeline data in front of me: nineteen days of every ticket spent waiting on another team. You can't argue with your own numbers.
What made it workable was that they didn't just tell me not to do the migration — they gave me the reasoning in a form I could take to 190 engineers who'd been promised microservices. Two services instead of forty, and we got a bigger velocity gain than the full migration was forecast to deliver.”
Evidence gate. This page publishes only what Envion's project records and client disclosure permissions support. Outcomes are added once verified against a baseline, a measurement period, and an approved source.
FAQ
Questions about this case
Facing a similar challenge?
Planning a microservices migration to fix delivery speed? Measure where cycle time actually goes first — Envion validates the plan before you fund it.
Discuss a Similar ChallengeKeep exploring
Similar case studies
Executive Technology Leadership
Support for high-stakes product and AI decisions
Bring senior technology leadership into the business when the roadmap is unclear, delivery is at risk, an AI initiative needs stronger ownership, or the company needs an experienced technical voice before hiring a permanent CTO.
Discuss Interim CTO SupportCore responsibilities
- Align product and technology priorities with business goals and measurable outcomes.
- Review architecture, delivery risks, data foundations, security needs, and AI readiness.
- Lead internal teams and external partners through a practical execution plan.
- Clarify team structure, ownership, decision rights, and delivery cadence.
- Support investor, board, partner, and due-diligence conversations with credible technical judgment.
New experience
Prompt-to-Page — try it right here
Describe the landing page you want, in your own words. We turn it into a finished page and email you a private link in 5–10 minutes — no briefs, no calls, $0 to see the result.
- Describe what you want to create.
- We structure, write, and compose the page.
- You receive a private link when it is ready.
Start with a sentence — the interactive builder takes it from there.
Generate My PageSafe, respectful content only. No obligation.