A team comes in saying they need to rewrite the monolith as services. They have charts. They point at the framework, the language choice, the database that's slowing everything down. Six months and a small fortune later, they're shipping the same features at the same pace, with the same complaints, on a stack with a more fashionable name. The technology was never the problem. It just looked like one.
The symptom looks technical
Most of the things that go wrong inside a software team show up wearing technical clothes. The codebase is unmaintainable. The framework can't keep up. The database is the bottleneck. The build is too slow. Engineers are leaving because the stack is dated. Each of these is a real sentence somebody can stand up and say in a planning meeting, and each of them lands like a diagnosis.
They are almost never the diagnosis. They are the symptom that's easiest to talk about.
Technology as the lightning rod
Technology makes a convenient lightning rod because it's the part of the system everyone can see. The architecture diagram is on the wall. The repo is in front of every engineer. The bill from the cloud provider lands in someone's inbox every month. When something feels broken, the eye lands on the artefact, not on the process that produced it.
So the team argues about Postgres versus the new shiny database. About monolith versus services. About React versus the framework that didn't exist eighteen months ago. These are real questions and they have real answers. But underneath, more often than not, is something nobody wants to name out loud: we cannot, as a team, decide things and make them stick.
Arguing about Postgres is easier than arguing about who gets to make the call. The technology argument has a winner. The decision-making argument doesn't, and everyone in the room knows it.
What's actually broken
When you pull a struggling team apart, the failure mode is almost always one of three:
- Decisions get re-litigated.A choice was made in March, again in June, again in September. Each time it's framed as "revisiting", but nobody can say what changed. The decision was never really made; it was held at gunpoint by whoever spoke last.
- Decisions have no owner. Anyone can object, nobody can decide. The result is the slowest possible form of consensus: nothing happens until everyone is exhausted enough to stop caring.
- Decisions evaporate. The meeting ended, nobody wrote anything down, and within a week three engineers have built three different things based on three different recollections of what was agreed.
Each of these failures shows up downstream as a technology problem. A re-litigated architectural choice produces an inconsistent codebase. An unowned decision produces stalled migrations and abandoned services. An evaporating decision produces a system held together by folklore. The artefact looks broken because the process that built it is broken.
The signs
The signal isn't in the code, it's in the conversations around the code. A few patterns to watch for:
- The same architectural argument has been had three quarters in a row.
- No one in the room can name the owner of a given system in under five seconds.
- Roadmap items that have been on the wall for more than a year, and a story about why each one is "blocked".
- Retrospectives that always conclude the team needs to "communicate better".
- Engineers describing features as belonging to whoever is currently angriest about them.
Any one of these can have a benign explanation. Three of them at once, in the same team, is not a technology problem.
If the same argument keeps coming back, the answer isn't the argument — it's the absence of a decision.
What to do instead
The fix is unglamorous. There's no migration to a better framework, no platform to adopt, no consultant deck. The work is reshaping how decisions get made and recorded. A few moves that consistently help:
- Name the decision in one sentence.If you can't state it in a sentence, you're not deciding anything yet — you're still scoping.
- Name the decider.One person, not a committee. The committee can advise; the person decides. Without an owner, the decision is no one's job to land.
- Time-box it.Set a date. If the date passes and the decision hasn't been made, the default ships. The discomfort of the deadline is the entire point.
- Write down the trade-off, not just the conclusion. A decision without its trade-off rots within a quarter, because no future version of the team can tell whether the original logic still applies.
- Distinguish reversible from irreversible. Reversible decisions should be made fast and re-examined cheaply. Irreversible ones earn the long meeting. Confusing the two is how teams end up debating the colour of a button for a week and the schema of the most important table in twenty minutes.
None of this requires new technology. All of it requires the team to be honest, in the room, about what kind of problem it's actually solving.
Closing notes
The technology will keep being wrong, in some way, forever. There has never been a stack a team didn't outgrow, a framework that didn't age, a database that didn't hit a limit. That part is permanent. What changes between teams is whether they can name the wrong, decide what to do about it, and act — without having the same conversation again next quarter.
The teams that can do that ship through any stack. The teams that can't will keep migrating, every two years, in search of the framework that finally makes the decisions for them. It doesn't exist. It never did. It's not a technology problem.