Nearly thirty geek years in this industry, and the way we build teams quietly became the wrong shape

I've been in IT for nearly three decades. I started in tech, and along the way I've worked most aspects of product: from design to software and data engineering, quality and compliance, architecture and infrastructure, through to product ownership and management; I've lectured and trained professionals in it, and I've been the person doing the hiring for most of the teams I ran. I was good at that part, and I believed in it, and over the past couple of years I've come to think the thing I was good at quietly became the wrong shape. The problem itself is old; I'd lived with it my whole career. What's new is that I stopped accepting it.

Here's what started it. A founder I know built a product in three weeks with an AI coding tool. It was good. Auth, payments, a clean UI, a real database behind it. He asked me what it would take to put it in front of paying customers, and the honest answer was: most of the work. Not because the tool did a bad job, but because the things that make software a product were never in the prompt. What happens at concurrent load. Which data can't leave which country. What happens when users arrive from different time zones, in different currencies. What happens when someone opens it on a phone, or on a wall-sized screen. Who answers the page at 3am. Nobody types those. They're the things you learn to ask after you've shipped a few.

He could hire for it. That's the reflex, and it was mine for years. So I did the exercise with him. What does a real product need? Backend and frontend, all the time. A database person, now and then. Security, every few months, and all at once when something happens. DevOps, a lot at the start and then in bursts. A designer, intensely for six weeks and then rarely. QA around releases. Someone who knows compliance when a regulation moves. Documentation, which nobody wants to do and everybody needs.

That's the list, and it's not even complete. He needs some of each. Beyond the two or three who write the code every day, he needs none of them full time. And there's no way to buy that.

I know, because I've been on every side of it. I've been the manager who hired the full team for the roadmap and watched the roadmap turn. The people were as good as ever; the shape was fixed on the day I hired it and the product moved. I've been the one who couldn't get budget for the specialist and shipped without the review, telling myself we'd backlog it, which is how most technical debt gets its name. I've been the fractional consultant dropping in for two days and leaving with the only honest position I could take: I stand behind what I said today, and nothing after, because the thing I reviewed will change next month and I won't be there to see it.

That last one is the part that bothers me most. Add up a stack of part-time specialists and you don't get a team. You get a stack of disclaimers, and none of them covers the gaps between.

So what actually happens, in most companies I've seen, is two or three generalists on the product and a lot of hope. Security gets done partially. The database is fine until it isn't. Accessibility is discovered during a procurement review. The bill comes eighteen months later, with interest.

Somewhere in that conversation with the founder I heard myself describe the problem and recognized it. Not from engineering. From infrastructure, about twenty years ago.

You couldn't buy four days of a database server. If you had the money, you bought the server, sized it for your worst hour, and paid for the idle. If you didn't, you ran on less than you needed. Capacity came in whole units, and you either ate the waste or ate the risk.

Cloud didn't fix that by making servers cheaper. It fixed it by making capacity divisible. You stopped buying machines and started buying what you used.

Engineering is still bought like a server room in 2005. Whole people, sized for the peak, idle absorbed by the owner. And I spent a good part of my career getting good at provisioning the racks.

I've been working this out for some time, and I'm going to lay it out here in parts.