Is it the architecture or the team? How to tell

A founder writes to me because the product keeps falling over. Users complain, the team scrambles, it gets fixed, and two weeks later something else falls over. Meanwhile the roadmap has slipped for two quarters. The engineers say the codebase is a mess and needs a rewrite. The founder wants to know if that is true, or if the engineers are the problem.

It is a fair question, and the honest answer in most cases is that both are true and they are connected. The useful work is finding out which one to fix first, and whether the fix is a change or a rebuild.

I have spent 22 years around engineering teams, including several that were convinced they needed a rewrite and one or two that actually did. This is how I tell the difference.

The two kinds of pain look different

Architecture and team problems produce different symptoms, and the symptoms are visible to a founder without reading code.

Architecture problems live in the system's behaviour under load and under change. Outages when traffic rises. Pages that got slower as the database grew. A change in one place that breaks something that should have been unrelated. Deploys that fail for reasons nobody predicted. Engineers who say "I do not know what that will affect" and mean it.

Team problems live in how work moves. Features that wait for days between stages. Nobody able to say who owns a part of the product. Estimates that miss by the same margin every sprint. A release process that depends on one person's memory. Engineers who can describe what they are building but not why it is this week's priority.

Write down your last five incidents and your last five delayed features. Put each one in a column. If the incidents keep pointing at the same component or the same kind of failure, that is an architecture target. If the delays keep waiting at the same point, on the same person or the same missing decision, that is a team target.

Most founders find things in both columns. That is expected.

Why they are usually connected

Architecture does not decay on its own. It decays because nobody owns keeping it healthy, and that is a team problem.

The pattern goes like this. The system was built for the load and team size the company had at the time, which is correct. Then the company grew. Traffic went up, engineers were added, features were bolted on. Nobody was responsible for asking whether the foundation still fit, because everyone was responsible for shipping. So every fix became a patch, and every patch made the next outage more likely.

That is why "fix the architecture" without fixing the team rarely holds. The rebuilt system decays the same way, because the conditions that decayed the first one are still there.

It is also why I usually look at the team first, even when the founder called about outages. Not because the outages are not real, but because the team is what produces the architecture, and a team with clear ownership and a sane process will fix the architecture on its own in most cases.

I described how I look at the team side in how to improve engineering team performance.

Fixable or rebuild

The question founders most want answered is whether the current system can be saved. There is a test for it that does not require reading code.

Ask the team to make a small, safe change and ship it. A copy change. A new field on a form. Something that should take an hour.

If it ships within a day without drama, the system is fixable incrementally. It may be ugly, it may embarrass the engineers, but a system that can accept safe change can be improved one piece at a time while continuing to serve users. That is almost always the right path.

If a trivial change takes a week, needs three people, and nobody can say with confidence what it will affect, you are near rebuild territory. The system has lost the property that makes incremental improvement possible.

Even then, "rebuild" should mean one part at a time. Find the component that causes the most incidents or blocks the most changes, replace that, and leave the rest alone until it earns the same attention. A full rewrite, where the team stops shipping and starts again from nothing, is the most expensive decision a startup can make, and the case for it is almost always weaker than it feels from inside the mess.

What the engineers are telling you, and what they mean

"The code is terrible and we need to rewrite it" is something engineers say about most code they inherited. It is sometimes true. It is not evidence by itself.

Ask for specifics. What can the current system not do that the product needs it to do in the next year? Which parts, exactly? What would replacing those parts cost, and what would the product get?

A team that can answer that has a real case, and the answer will usually be a list of components rather than "everything". A team that answers with adjectives is telling you they are unhappy with the code, which is real and worth hearing, but is a different thing from a technical need.

This is also the point where an outside technical read is worth its cost. Your engineers are inside the system and have a natural preference for building new things. Your tech lead may be the person who built the thing being criticised. A neutral reading of whether the list is real is cheap next to a rebuild.

What to do this week

Days one and two. Write down the last five incidents. For each, what broke, what the root cause turned out to be, and how long it took to find. Write down the last five delayed features. For each, where it waited and on what.

Day three. Run the safe-change test. Ask the team to ship something trivial and watch how long it takes and what gets in the way.

Day four. Ask each engineer, separately, what they own and what they would fix first if they could. Ask specifically what the system cannot do that the product needs.

Day five. Read what you have. Incidents clustering on one component: architecture target. Delays clustering on one waiting point: team target. Safe change shipped in a day: fix incrementally. Safe change took a week: consider replacing the worst component, after the team problem is addressed.

At the end of that week you will not have a technical plan. You will have something more useful: a clear description of what is wrong that you can hand to anyone, and enough evidence to tell whether the person you hand it to is telling you the truth.

The order matters

Fix ownership and process first, then let the team fix the architecture, and rebuild only the parts that have proved they cannot be fixed. Founders who do it in the other order pay for a rebuild, get a new system, and watch it decay the same way, because the team that produced the first one is unchanged.

The architecture is what broke. The team is why it keeps breaking. Start there.