Valérian de Thézan de Gaussan
Many software teams still think this way: developers are expensive, so they should always be busy. If a developer is not coding, fixing a bug, or working on a ticket, it can look like wasted time. But this is often the wrong way to think about software work, because the main problem is usually not writing the code. The harder problem is deciding what is worth building, what problem really matters, who has that problem, and whether the solution is useful enough for people to pay for it.
AI makes this even more clear. Code is becoming faster and cheaper to produce, so the value moves somewhere else. It moves toward good decisions.
100% busy does not mean efficient
Lean teaches an important idea: keeping everyone busy does not always make the whole system faster. When everyone is already at full capacity, new work has to wait, small problems can block many other things, and priorities become harder to change.
This happens often in software teams. An urgent customer problem appears, but everyone is already working on something. A developer discovers that a feature is going in the wrong direction, but there are already many other tasks waiting. Everyone is busy, but the team is not moving well.
The problem is that we often try to optimize each person instead of the whole system. A developer with some free time is not a waste.
The goal is not to produce more code
Software companies do not make money because developers write a lot of code. They make money because their software solves useful problems. A developer can spend one week building a feature that nobody needs and be busy the whole time, but the company still wasted one week.
This is a basic Lean idea. Building something that nobody needs is waste. So the question should not be, “How can we keep every developer busy?” The better question is, “Are our developers working on the right things?” That changes how you manage a software team.
Good engineering work is not always coding
If developers are expected to code all the time, they are pushed to start building too early. There is a ticket, so they start writing code, even when the problem itself is still unclear.
Sometimes the best use of their time is to talk to a customer, read support messages, look at how people use the product, or discuss the problem with the product team before building anything. Sometimes the best result is deciding not to build the feature at all. From experience, I’ve developped countless features that were never useful. And then I can think of a few that had huge impact. If only I had spend time on the useful things, I would have work 3, 4 times less?
If one day of thinking saves three weeks of useless development, that is good work. A good developer should not only turn requirements into code. They should also help decide if the requirement makes sense.
Lean was about learning faster
Lean Startup became popular because software teams could already build and release things faster than before. Once you can ship every few weeks, building itself is not the only problem anymore. You can also build the wrong things very quickly.
So the question changes from “Can we build this?” to “Should we build this?” The Build-Measure-Learn loop is sometimes misunderstood because the goal is not to build as much as possible. The goal is to learn as fast as possible.
You should build only what you need to test an idea. If a simple mockup is enough, do not build the full product. If talking to customers can show that nobody cares about the problem, do that first. If you can test the service manually, you may not need to automate it yet.
AI makes this more important
AI lets developers produce software faster, and the easy reaction is to give them more tasks. That is not a good idea.
If one developer can now build twice as much, giving them twice as many tickets does not mean the company creates twice as much value. You’re building useless things faster and burning out your developers.
If coding takes less time, developers can spend more time understanding the problem. They can speak with customers, test ideas, build small prototypes, and challenge bad assumptions before the company spends too much time on them.
Free capacity is useful
Managers often see free capacity as something bad, but free capacity is healthy. It gives developers time to investigate problems, improve weak parts of the system, and react when an important customer issue appears.
A team that is always at full capacity has no room for surprises, and software work has many surprises. If everyone is already fully busy, every surprise creates delay.
So trying to use 100% of every developer’s time can make the team slower, not faster.
Measure value, not activity
Developer utilization is easy to measure. Usually it’s done by counting hours. People do it without even bad intention: it’s how work has been done in the tertiary world. The thing is: it does not tell you if the team is creating value.
If an engineer finds a simpler solution, that is good. If a developer stops a bad project before it starts, that is good. If the team spends two days understanding a problem and avoids two months of useless work, that is also good. None of these things maximize coding time, but they reduce waste.
That is what a software team should care about.
Your developers need time to think
AI gives companies a choice. They can use the extra speed to fill the backlog faster and produce more software, or they can use some of that time to make better decisions before work enters the backlog.
The second option may look less efficient because developers are not coding every hour, but that is exactly the point. The bottleneck is not how many hours your developers can spend coding. The bottleneck is knowing what is worth building.
Your developers do not need to code all the time. They need enough time to make sure the code they write is worth writing.