Big tech veterans don't fail at startups. The structure does

A senior engineer joined Buser from a big tech name. Six weeks in, 1:1, he tells me: 'the scope here is much bigger than what I'm used to.' No drama. No complaint. Just an observation. He was right. And I had told him exactly that in the interview.

I tell every candidate from a large company what our rhythm is and what stage we're at. They agree. They sign up. They come in. The shock still hits, every time. The warning doesn't prevent it. The warning is what lets us talk about it afterwards.

It took me a few of these conversations to understand what I was watching. The shock isn't personal failure. Not lack of skill, not lack of effort, not lack of fit in any individual sense. It's an organism trained to operate inside one organizational structure being dropped into another, and finding out its instincts no longer match the terrain.

Two structures, both correct

Henry Mintzberg spent the 70s mapping how large organizations actually work, not how management books wished they worked. In Structure in Fives he describes Machine Bureaucracy as the structure of mature companies. Tight scope per role. Coordination by standardized process. A thick layer of analysts whose job is to define how work happens. It's not a flaw. It's the structure that makes operating at scale possible. Banks, telcos, large platforms, governments. They all look like this because nothing else works at that size.

Adhocracy is the other end. Coordination by mutual adjustment between people, scope defined by the problem instead of the job description, decisions decentralized to whoever is closest to the work. Startups look like this. Not because founders read Mintzberg. Because it's the only structure that survives the speed and ambiguity startups operate in.

Both are correct. They're correct for different problems. A Machine Bureaucracy running a startup dies of slowness. An Adhocracy running a bank loses your money. The structure isn't moral. It's environmental.

What happens when someone moves between them is what biologists call ecological mismatch. Same animal, wrong habitat.

The dark side of each side

I'm done reading posts that pretend one of these is obviously better. They aren't. Each has a real cost the other side doesn't pay.

A big company engineer has defined scope and goes deep. Becomes world-class on one specific surface. Ships papers, builds infra that handles billions of requests, mentors a generation of juniors. Also spends months on a single decision a startup engineer would resolve in a Slack thread on Tuesday. Gets stuck in promotion politics unrelated to the work. Watches projects die in review committees. Gets really good at navigating org charts and stops knowing if the customer cares about what they're shipping.

A startup engineer has fluid scope and ships fast. Touches product, infra, ops, sometimes hiring, sometimes sales calls. Learns ten things in a year that big tech would have given them in five. Also burns out. Context-switches so hard they stop being able to go deep on anything. Watches a decision get made, reversed, and remade differently inside the same month. Their career level becomes unreadable to recruiters. Builds something that works and eighteen months later has to rebuild it because the company they helped create no longer fits the architecture.

Neither side has the high ground. Both have different costs.

What I see at Buser

We were 550 people. Today we're much smaller. Not by accident. By design.

When a company grows, the easy move is to break the software to scale the team. You hit a coordination ceiling, you split the codebase, you create another squad, you hire another EM. The team gets bigger. The software gets worse. The original problem - too many people, not enough overlap - is now distributed across more services, but it didn't go away. You just gave it more surface area. Clayton Christensen described a version of this in The Innovator's Dilemma. A mature company optimizes to protect what it has, and the structure that protects the core kills the ability to move fast somewhere else.

We do the opposite. Squads stay small on purpose. A small squad looks at scopes that, in a bigger company, would belong to two or three different teams. The bet is that being together justifies itself. Context flows without ceremony, decisions happen at the conversation level, and the cost of one engineer holding three adjacent problems is less than the cost of three engineers holding one problem each and never talking.

It isn't romantic. It demands a specific type of person. T-shaped - the term Tim Brown at IDEO popularized for someone deep in one thing and willing to go shallow into four others. Comfortable with the problem shifting underneath them. Comfortable not knowing where their job ends.

That's exactly what someone coming from Machine Bureaucracy wasn't trained for. They were trained to be excellent inside a clear box. The box is what made the excellence legible. Take the box away and the same person, with the same skills, looks lost. Not because they got worse. Because the metric they were optimized against doesn't exist here.

The interview doesn't solve this

I warn every candidate from a large company about what they're walking into. Most still get shocked. I used to think this meant I was bad at interviewing. Then I understood. The warning is a contract, not a vaccine.

The candidate can't know what fluid scope feels like until they live it. The words 'you'll own more surface' mean nothing until Monday morning, when an engineer is debating a pricing rule with a PM, fixing a query, and writing a one-pager for the next board, all before lunch. The shock isn't the person not paying attention. It's the gap between a verbal description and the embodied experience of a different structure.

The warning matters because it creates the language to talk about it later. The 1:1 conversation - 'the scope here is much bigger' - only happens because we agreed in the interview that this was the deal. Without it, the same observation lands as a complaint instead of as data.

What this actually is

It's not a career decision between 'good' and 'bad.' It's a decision between structures, and structures fit different career moments and different problem domains.

If you want to go deep, ship at planet scale, work inside systems that already work, and learn from people who've done this for fifteen years - big tech is where that lives. Don't be ashamed of it. The people who built S3 didn't do it in a garage.

If you want to learn ten things in a year, see your decisions reach a customer the same week, watch a company become what it becomes because of how you held the problem - startup is where that lives. Don't romanticize it. You'll pay for that speed in stability, in clarity, and sometimes in sleep.

The mistake is treating one as the goal and the other as a stepping stone. They're different ecosystems. The fact that someone thrived in one says nothing about whether they'll thrive in the other.

The senior engineer in that 1:1 didn't fail. He noticed, accurately, that the structure was different. That's the conversation I want every time. Not whether he'll stay - that's a separate question. Whether he can name what he's experiencing instead of taking it personally.

That's what the warning bought us.

When someone gets shocked at Buser, I don't read it as a hiring mistake anymore. I read it as the gap between Machine Bureaucracy and Adhocracy showing up exactly where Mintzberg said it would, fifty years ago, in a person who has the right skill set for the wrong structure - or the right structure for a skill set that needs to be retrained for it.

The question isn't which side is better. The question is which side fits the problem you're solving, and the career moment you're in. Get both right and the work makes sense. Get one wrong and no amount of effort fixes it.