Your Dev Team Is Too Big. And You're Still Short on People.

You have a product owner writing tickets. An analyst creating reports. A scrum master facilitating ceremonies. An agile coach teaching the team how to be agile. A team lead attending meetings. And developers waiting for assignments.

This entire layer of people didn’t emerge from bad intentions. It emerged because coordination has a cost — time, attention, context. And someone had to do it.

But the cost of coordination just dropped dramatically. And with it, the value of the roles that exist to manage it.

Meanwhile, your competitor shipped a feature in three weeks with a team of four.

”But we need an architect”

I hear this regularly. And maybe you do. But do you need one full-time? Or do you need a developer who thinks architecturally? In the AI era, those are increasingly the same thing.

According to Google’s State of DevOps Report, top-performing teams deploy hundreds of times more frequently than the slowest and have 3x lower deployment failure rates. The key factor? Autonomy and low bureaucracy — not a bigger team.

Why this isn’t just a CTO problem

Most CEOs handle the IT team by leaving it to the CTO. That’s a mistake. Not because the CTO doesn’t know what they’re doing — but because decisions about how the team is structured and what it builds are directly proportional to how fast your company responds to market changes.

AI is a technical thing — so CEOs naturally delegate it. But this is the last moment when that makes sense. The fastest-growing companies today are erasing the boundary between IT and the rest of the organization. HR teams use Cursor. Financial analysts work in Claude Code. Marketing builds its own automations. Technology is no longer the domain of a single department.

What you’re reading isn’t a guide to reorganizing your IT team. It’s a guide to rethinking how you build teams across your entire company. IT is simply the natural place to start — because it’s closest to the technology. But the principle is universal.

AI isn’t a smart autocomplete

AI won’t kill programmers. But it’s not enough to use it as a smart autocomplete.

Those who think about what AI can truly take off their hands — entire analyses, decision-making, architecture proposals, understanding the customer — will be a level above those who just let it complete lines of code.

In my practice, I’ve seen teams that claimed they didn’t need a product owner — that they understood the product. And they were right in that they understood the solution. They knew how things worked. But they didn’t know why customers used them. When I asked what their cart conversion rate was and where most customers dropped off — silence. They didn’t know. They weren’t tracking it. The system worked correctly. The customer still left.

When we looked at the data, cart conversion was 1.2% — the segment average is around 3%. The biggest leak? The shipping options page — 38% of customers dropped off there. The fix took two weeks. No new feature, no innovation — just understanding where the customer leaves and why.

That’s the difference between technical understanding of a product and genuine product thinking.

What kind of developer matters now

The developer you’re looking for looks different. I’ve most often encountered them in startups. They’re the kind of person who, when they hit the boundary of their competence, doesn’t redraw it as foreign territory. Instead of “that’s an infrastructure problem” or “that’s product’s job,” they start figuring it out and solve the problem. Each time a little differently and better. Each time with a broader reach.

In my talks, I call this the essence of engineering craft. It’s not doing the same thing ten times from a recipe. It’s solving the seemingly unsolvable — and in doing so, expanding the boundaries of what you can handle.

With AI, this person gains the capabilities of an entire team. Without AI, they’ll become increasingly rare.

Stop building things that don’t matter

But even the best person can’t deliver value if they spend half their time maintaining things that don’t matter. This is the second half of the problem — what your team is actually building.

In a recent article, I wrote about how your website will stop being a competitive advantage for e-commerce companies. That customers will shop through AI assistants, and the only relevant page left will be the product detail. If this holds true externally, it holds true internally too. Your IT team shouldn’t be building a website. It should be building what determines whether an AI assistant recommends you — or not.

If you’re building your own notification system, your own warehouse management, your own payment logic — your team’s cognitive load will never be small. Regardless of how good the people are. They’ll be buried in maintaining things that bring no competitive advantage. The same applies to investing in sophisticated site search — AI assistants are taking over the decision-making phase and your search is becoming a commodity.

Hidden costs you’ll never see on an invoice

At first glance, an external solution will always seem more expensive. But this comparison is dishonest — because we can’t quantify cognitive load. And it doesn’t grow linearly. It grows exponentially. Every additional system you own adds dependencies, outages, onboarding for new people, technical debt. Silent costs you’ll never see on an invoice, but you’ll feel them in your speed.

A study by Stripe and Harris Poll found that developers worldwide spend approximately 42% of their time on technical debt and maintenance — time that directly takes away from innovation. In 2021, Gartner predicted that by 2025, 70% of new applications would use low-code or no-code platforms. Judging by the adoption of tools like Cursor, Lovable, and Claude Code, that prediction is coming true — just in a different form than Gartner imagined.

Ask yourself one uncomfortable question. Can the competition reach the same level in six months? If yes — you don’t have a competitive advantage. You just have costs. And the fact that we internally consider something our special edge doesn’t mean it’ll be relevant in a time when AI is changing the world around us faster than we can plan.

Invest your own development only where you’re building something that would take competitors years to catch up to. In deep knowledge about your customer. In unique data you’ve been collecting for years. In know-how that only comes from hands-on experience in a specific market and can’t be shortcut with money.

Everything else — integrate. Smartly. And with an eye on what’s coming.

Process as a goal instead of a tool

Here comes the part nobody wants to hear. You can reorganize processes, buy off-the-shelf solutions, and give your team the best tools. But if you have people who wait for assignments instead of thinking — you won’t speed up. You’ll change the scenery. Not the outcome.

And yet the first instinct of most companies is to add another process. Another ceremony. Another layer of approval. In the name of quality, predictability, control.

The result is exactly the opposite — the team slows down, wraps itself in procedures, and stops delivering. Process becomes the goal instead of the means.

Who are the right people

You’re looking for people who know their strengths and consciously deepen them. But at the same time, they don’t treat them as fixed boundaries. When they hit a problem outside their domain, they don’t call a colleague — they figure out what they need and solve the problem. Not because they have to. But because it naturally pulls them forward.

In practice, this means they’re capable of delivering things from start to finish. Without passing the baton. Without waiting for another department. This is critical in a small team — because passing the baton is exactly the place where things die.

There aren’t many such people. And that’s why you can’t just take your existing team and reorganize it. You need to know who you’re looking for. And be willing to pay for them — or build a team around them from scratch. The result will show up where the CEO feels it most: in the speed at which the company responds to market changes.

Context matters more than process

But having the right people isn’t enough. They need the right context.

A developer who only sees Jira will never understand why. A developer who sees the conversion rate, average order value, and knows the quarterly goal — that person decides differently. Writes different code. Prioritizes differently.

And when they hit a decision dilemma — and they will — they have something to navigate by. Not a rule in Confluence. But an understanding of where the company is heading and why current priorities are what they are. Mission and vision aren’t posters on a wall. They’re tools for everyday decision-making.

What makes sense to share

A small focused team isn’t the answer to everything.

In some areas, centralization and a certain degree of specialization are unavoidable — and operational reliability is exactly such a case. A small team can’t cover outages, monitoring, and night incidents on its own. With four people, it doesn’t work long-term.

The answer isn’t adding someone to the team to watch servers. The answer is having a central operations team shared across the entire company. The same logic as software integration: reliable operations aren’t your competitive advantage. They’re infrastructure. And infrastructure makes sense to share.

But watch out — the same principles apply here too. A central team isn’t an excuse for a bureaucratic structure full of coordination layers. Even there, you’re looking for people who think beyond their domain, understand the business, and are capable of delivering.

Where to start — specifically

First: map out what your team actually builds. Go through all your systems and divide them into two columns. What’s your competitive advantage — something that would take competitors years to catch up to. And what’s infrastructure you can buy. Most companies know that too little capacity goes toward building new things. But few admit why — because the answer isn’t in processes or headcount. It’s in what those people maintain.

Second: identify people with cross-functional reach. In every team, there are people who naturally cross the boundaries of their role. Who ask why, not just how. Who deliver things from start to finish. Find them. They’re the building blocks of a new model.

Third: give your team direct access to data and goals. Not through presentations and quarterly reviews. Daily. Conversion rate, orders, quarterly targets. Without context, even the best person can’t make the right decisions.

Fourth: start with one integration. Pick one system you’re building and maintaining internally, and replace it with an off-the-shelf solution. Not as a cost-saving measure — as an experiment. You’ll see how much capacity frees up. And you’ll likely find that what you considered your advantage, the ready-made solution handles better — at a fraction of the cost.

Conclusion

This isn’t a guide to saving money on people. It’s a guide to stop wasting their potential.

What AI brings isn’t a replacement for developers. It’s an opportunity to build teams differently. Smaller, more focused, faster. Teams that don’t buy time — but deliver value.

Savings will come. But not primarily from slimming down the team. They’ll come from stopping the building of things that don’t make sense — and replacing them with ready-made solutions. From getting rid of maintaining systems that slow you down. And yes — from honestly asking yourself whether people who can only code to spec are the right profile for what lies ahead.

And speed today isn’t just an operational advantage. It’s a competitive advantage that translates into new revenue streams. A company that can test, launch, and iterate three times faster than the competition wins the market — not once, but repeatedly.

Start with one question: how many people on your team today are actually building things the customer will feel?