Sooner or later, the same question arises in some committee, phrased in different ways: why is the development team going so slow?
It is a legitimate feeling. Management sees the market moving, sees competitors launching, and doesn't see their product advancing at the expected pace. The instinct is almost always the same: more pressure, more people, more urgency. And that is where most organizations make the wrong diagnosis.
The Wrong Diagnosis
Development is not a tap you can just turn on harder. It is a system with scarce capacity. Nine pregnant women do not make a baby in a month. You can add people, you can apply pressure, you can demand 'more urgency', and yet the system has a limit to how much it can process well at one time. Putting more into a saturated system doesn't speed it up: it saturates it further, generates more context switching, more debt, and more incidents. Frederick Brooks documented this decades ago in The Mythical Man-Month, and it remains as true today as it was then.
This doesn't mean there are no levers within the system (there are, and I know them well because I've touched them all in 15 years of leading teams): good engineering practices, architecture that doesn't collapse under its own weight, trained people, correct tools. All of that matters. But it has diminishing marginal returns. You can optimize the system by 20-30%. You are not going to triple the speed by optimizing how what enters is processed.
The real leverage lies elsewhere: what we decide goes into the system.
The Two Real Levers
Any 'slowness' problem can be separated into two axes:
- Supply (how we process): engineering, team, technology, training.
- Demand (what we let in): the business and product bets that commit that scarce capacity.
Most organizations invest all their energy in supply and almost none in demand. They hire, reorganize, change methodologies, and still fail to ask themselves if the bets they are putting into the system make business sense. That is where I have seen the greatest waste of capacity in my career: not in bad lines of code, but in good lines of code building things that shouldn't be built yet, or shouldn't be built that way.
When the Bet Has No Business Case
At Creditas, I experienced firsthand what it means to establish an operation from scratch in a new market: hiring, training high-performance teams, and above all, deciding what to build first when everything seems urgent. With Creditas Store, Creditas Benefícios, and Creditas Auto on the table, the discipline was not in coding fast; it was in having clarity about which bet deserved engineering capacity and which didn't, with goals and OKRs that forced justifying the 'why' before the 'how'. When that discipline exists, 'going slow' stops being the problem, because what enters the system has already been filtered by business sense.
When Something Doesn't Scale and Traps You
At Enterticket, the challenge was different: a legacy product that needed to be modernized and opened to new markets, without stopping the business. The easy temptation there is a total rewrite, spending months or years 'fixing everything from the inside' while the business waits. We chose the opposite: evolutionary modernization, hexagonal architecture, and microservices where they added real value, and a focus on launching the new purchase portal and expanding to Mexico with Product-Led Growth. Product governance was key there, deciding what deserved architecture investment and what didn't, instead of getting trapped refactoring indefinitely something the business no longer needed in that form.
When Accelerated Growth Demands Filtering, Not Just Executing
In high-growth stages, something I experienced firsthand at RD Station, everything feels urgent at the same time. There, the risk is not a lack of execution, but a lack of filtering: when any initiative seems reasonable, the system fills up with mediocre bets competing for the same scarce capacity. The lean culture is demonstrated right there: measuring before scaling, validating before committing months of engineering, and using Kanban not as decoration but as a real way to make visible how much is 'in flight' at once, because what is not seen is not managed, and what doesn't have a WIP limit accumulates silently until 'everything goes slow'.
What Really Changes the Perception of Speed
With this in mind, the list of what really moves the needle is not technical first, but of business, culture, and governance:
- Clear goals and objectives: without a clear business objective, every initiative seems equally urgent, and that is where capacity is lost.
- Good bets with a business case: every large initiative should justify why it deserves development capacity before committing it, not after.
- Lean thinking and values: validate before scaling, measure before committing, kill fast what doesn't work.
- Make work visible, Kanban: make visible how much is in progress, where it gets stuck, and how much each thing costs in real capacity.
- Adjust culture: perceived speed is also a matter of trust and alignment, not just delivery.
- Reward the good, fire the toxic: scarce capacity is destroyed faster by a tolerated bad attitude than by a bad technical decision.
- Train the team: investing in people is investing in the only part of the system that improves over time if cared for.
Practical Checklist for Senior Management
Before asking 'why are we slow?', ask yourself this:
- 1. Does every large bet have an explicit business case before committing development capacity?
- 2. Do we know, at any given time, how much we have 'in flight' at once (WIP)?
- 3. Do we review bets in progress (not just new ones) and kill those that are not working?
- 4. Who has real authority to say no to an initiative, and is that authority used?
- 5. Are we rewarding those who contribute and being honest with those who do not fit the culture?
- 6. Are we investing in training the team, or just demanding more from them?
- 7. Are we measuring development capacity as a business constraint, and not as an engineering failure?
If most of these answers are 'no', the problem was never the speed of the team. It was what we decided to put into a system that, by design, was never going to be able to handle everything at once.
