In this post
Most technical crises are visible months before they hurt, and they are visible in how the team talks, not in the code. Five signs follow, each with the evidence behind it and a question you can ask this week.
1. Simple changes take longer every month #
You ask for a new dropdown on the signup form and hear “two weeks”. Last year the same kind of request took a day. Nobody is slacking. Each shortcut taken to ship faster made the next change a little harder to make safely.
Martin Fowler calls this the Design Stamina Hypothesis: skipping design effort buys short-term speed, then “accumulates technical debt which will slow your productivity later” (Fowler, 2007). His own view is that the payoff line sits much lower than most people think, “usually weeks not months”. A team that has crossed it will not look unproductive. It will look busy and ship less.
JetThoughts’ Crosslake engagement is a public example of the reverse direction: on a legacy Rails and React product we took over, releases went from every 2 months to every 3 weeks (Crosslake case study).
Ask: “How long did the last five small changes take, and how long did we estimate?” Ask for the list in writing.
2. The team avoids parts of the codebase #
Every product has a corner the team calls “fragile” or “that part”. Payments and permissions are common ones. When only one person will touch it, you have two problems: the code is hard to change, and one resignation takes the knowledge with it.
Researchers measured this on open source. They estimated the “truck factor”, the number of developers who would have to leave before a project stalls, for 133 popular GitHub projects and found that 65 percent had a truck factor of 2 or less (Avelino et al., 2016). Those are popular projects with many users.
We do not get a pass. Run this on the public repository of the snap_diff-capybara gem, where Paul Keen is the top contributor:
$ git shortlog -sn --no-merges --since="12 months ago"
212 Paul Keen
9 Diego Algorta
8 dependabot[bot]
2 Twill
1 twill-hq[bot]
Output from our clone on 30 October 2026. Of the 223 commits not labelled as bots, 212 are one author’s. Nearly all the work sits with one person, and it is the first thing we would flag if a client showed us the same table. Crosslake’s page describes the same pattern on their side: after the original developer moved on, little documentation and lost knowledge made maintenance slow.
Ask: “Which two areas would worry you most if one person left?” Then run the command above on your own repository, or ask your lead to.
3. Technical decisions need another meeting #
Two developers disagree about how to store file uploads. The discussion moves from Slack to a call to a second call. Nobody is authorized to decide, so the decision waits for consensus.
Jeff Bezos put the fix in his 2016 letter to Amazon shareholders: “Many decisions are reversible, two-way doors. Those decisions can use a light-weight process,” and most decisions “should probably be made with somewhere around 70% of the information you wish you had” (Amazon 2016 shareholder letter). The upload question is a two-way door. Somebody should be allowed to pick, write down why, and move on. The irreversible ones (the primary database, the billing model) deserve the long meeting.
Ask: “Who decides when two engineers disagree?” If the answer is a name, good. If it is “we discuss until we agree”, you have found the gap technical leadership fills.
4. Developers start saying “rewrite everything” #
A request to add social login turns into a proposal to rebuild authentication. The code feels riskier to change than to replace. That feeling is a real finding, and the rewrite is usually the wrong response to it.
Spolsky’s account of Netscape is the standard reference: they “decided to rewrite the code from scratch”, which he called “the single worst strategic mistake that any software company can make”, and the gap between version 4.0 and the next major release was almost three years while market share fell (Spolsky, 2000). He wrote that in 2000 about a browser, so check how much of it applies to a three-year-old SaaS. His argument carries over: old code is full of bug fixes nobody remembers writing, and “when you throw away code and start from scratch, you are throwing away all that knowledge.”
Ask: “Which specific change is blocked, and what would unblock it inside the current code?” If the answer is a short list of tests and one module to untangle, you have a refactor, which is cheaper than a rewrite.
5. The team stops committing to dates #
Estimates turn into ranges, demos slip, and the standup is mostly risks. Founders often read this as lost motivation. It is more often a rational response to a codebase that has surprised them before.
There is no number for this one, so treat it as the sign that most needs checking against the other four. If signs 1 to 4 are present, sign 5 is their downstream effect. If they are not, look at the team: workload, turnover, unclear priorities.
Ask: “What did we say we would ship in the last three weeks, and what shipped?” Look for a pattern in the misses.
What to do first #
- Collect the written answers above. One page, from the people closest to the code.
- Name a decision owner for technical choices. It can be your most senior developer.
- Pick the one area the team avoids and make it safer. Add tests around the behavior before changing it.
- Get an outside review if nobody inside can judge. Our post on what to ask a dev shop and the one on assessing team health in 15 minutes give you questions that work without reading code.
If you want a team that ships steadily while you run the business, see how we work. JetThoughts is rated 4.8/5 on Clutch.
Sources #
- Martin Fowler, Design Stamina Hypothesis, 2007.
- Avelino, Passos, Hora and Valente, A Novel Approach for Estimating Truck Factors, ICPC 2016 - 133 GitHub projects, 65 percent with a truck factor of 2 or less.
- Amazon, 2016 letter to shareholders - two-way doors and the 70 percent rule.
- Joel Spolsky, Things You Should Never Do, Part I, 2000.
- JetThoughts, Crosslake case study and the snap_diff-capybara repository.
