A 15-person software team, inheriting a product and two demanding clients, kept getting hit by late-stage surprises. The fix everyone reached for was more discipline. The actual problem was an operating model that piled all the risk on the team, at the worst possible moment.
Sector and size
A software product company in the product information management space. Roughly 15 people. We were the “next-gen”: a small team that re-formed after the original startup went bankrupt, set up to keep supporting a couple of key customers who still depended on the product.
My role at the time
Delivery manager. Title aside, what actually landed on my desk was the full lifecycle: pre-sales support, project management, functional analysis with the BA, leading the development team, delivery, and post-go-live client services. End to end.
The presenting problem
The first year was unexpectedly smooth. We were running time-and-materials work for two or three key accounts: customer asks, we deliver. The original intent had been to buy them time to find a replacement system. We turned out to be a bit too good at that. Year one became year two, year three, and at some point we started opening up to new customers again.
That’s when the official problem statement crystallised: small team, tight budgets, no margin for error. Get the specs right, get the dev right, get the quality right. Land on time. No overruns.
What I actually observed
Two patterns sat underneath the official statement.
First, the way we worked. This was the early 2000s and we were running Rational Unified Process. Iterative on paper, but with large iterations. Long requirements phases, documents, client review, fixed budget with a margin, build, deliver, capture feedback. The trouble is that requirements documents are always an interpretation and interpretation gaps don’t show up until you ship. So we kept hitting late-stage surprises that needed rework.
Second, the product itself. We’d inherited it with real technical debt: places where we needed to re-architect to keep the non-functional requirements viable, performance especially. And there was no spare capacity for that work.
The moment I realised the real problem was different
It wasn’t a single moment, it was a combination of things clicking into place. The team had a clear sense of where they wanted to push the product technically. Two of our biggest clients were pulling it in different directions with their feature requests. We were tight on staff, tight on budget, no real buffers.
What the traditional route-based approach was actually doing was concentrating all the risk on us, late in the project. We literally couldn’t carry it. The presenting problem (“get more disciplined”) was operational. The real problem was structural. The operating model put the risk in the wrong place at the wrong time.
Where the risk piled up
Flow was the most visible tension. Risk piled up at the end of every project; no early warning, no way to course-correct without burning either margin or the client relationship. Experience was the secondary tension. The senior people carrying that risk were running on a level of stress that wasn’t sustainable.
What we did
We didn’t have a master plan. We had awareness, motivation, and a small enough team that most people already knew the model wasn’t going to hold.
We invested in learning first. Over a few months we went to conferences (this was the early days of the agile and XP wave) to learn and come back with options.
We went lightweight on requirements. Less specification, more conversation. We invited clients into brainstorm sessions to do requirements with us, which gave us the chance to surface where we wanted to take the product and the architecture. The conversation turned constructive instead of contractual.
We shortened the delivery cycle in stages: from quarterly, to monthly, to fortnightly sprints, eventually to a setup with one client where we were deploying daily into their production environment.
And we invested seriously in the technical practices that made all of that safe: test automation, build discipline, regression coverage. You cannot deliver daily on green without a safety net you actually trust.
Iteration without technical excellence fails on Quality.
The two key clients reacted differently. The operationally engaged one came along completely; their people loved the new way of working. The other was already in stabilise-and-rollout mode and the new cadence was less visible to them.
Outcomes
Release cycles moved from quarterly (or worse) to monthly, to two-week sprints, eventually to daily-on-green for at least one customer. Test automation on new code climbed past 80%. Regression bugs dropped meaningfully. Project-level visibility improved sharply. Early warnings on requirements-versus-budget pressure usually led not to more budget but to better prioritisation.
What I can’t easily quantify but knew was real: the energy in the team shifted from executing tasks to working toward outcomes. Conversations with clients became less defensive. Pressure was still high, but it had become sustainable.
Where we hit limits
Two things didn’t move, and both were structural rather than operational.
First, funding. We were project-funded, which meant the re-architecture work needed to fully resolve the inherited technical debt couldn’t run fast enough. We could keep the product alive and improve it, but we couldn’t get ahead of it.
Second, market. We were in a niche, and however well we operated, we couldn’t generate enough new customer growth to make the business sustainable long-term.
Better operating model, same hard ceiling.
What this experience taught me that I carry into every engagement now
The team knows best. Don’t try to solve it alone. Get the right people in the room, surface the problem honestly, allow the creative conflict, and the results will surprise you.
Iterate fast and show the work. Pilot customers and tight feedback loops remain the cheapest way to find out what you actually need to build, especially inside larger organisations.
Iteration without technical excellence produces slop. The practices that made daily-on-green possible weren’t a nice-to-have; they were the safety net. That is only going to matter more as AI produces more and more of the code.
Have a vision, not a plan. A clear long-term picture lets you spot which short-term client request actually accelerates you toward where you want to be, so you can prioritise accordingly.
And honestly: finance matters. If you’re undercapitalised for your ambition, you will hit a ceiling that no operating excellence can punch through.
What this case was really about
This was a case about collaboration: a small team, open communication, real respect, situational leadership, and enough trust to do something close to miraculous within the limits of what money and a niche market allowed.