The founder is still the roadmap.

Picture a restaurant where the chef also runs the host stand. The food is good, which is why there's a crowd at the door. But every party waits for the chef to wipe his hands, walk out front, check the book, pick a table and lead them to it. Behind the pass, the cooks stand at their stations with the burners lit and nothing to fire. Good cooks. Idle, because the only person who can send them a ticket is out front holding menus.

I've watched companies run exactly like this. The product works. Customers pay. And every decision that matters still walks into one office, waits its turn, and walks back out a week later.

Nobody planned it. The founder was right often enough, early enough, that asking them became the process. That's flattering. It's also why your best engineers start sounding tired.

How the fastest person becomes the queue

Before product-market fit, the founder's speed is the whole advantage. One person holds the customer, the product and the bank balance in their head at once, so a decision takes thirty seconds in a hallway. That's right for the stage. A committee would have killed the company.

Then it works. Customers arrive with requests, bugs and opinions, and the team grows to handle them. The number of decisions grows with all of it. The founder's week doesn't. The habit stays, though: people keep asking because asking used to be fast, and the founder keeps answering because they're often still right. Each decision still takes the founder about a minute. It just waits a week to get that minute.

One founder's queue

I was brought in to help a founder in marketing technology get a new line over the hump to commercial launch, and bring the rest of his roadmap along behind it. He had a novel idea. He'd raised money on it.

What I found was a small team and one decision-maker. He was the only person who could say whether something made sense, and whether he liked it. He was deciding the design himself. And he never talked about why. A thing was right or it wasn't, and the reasoning stayed in his head.

So he was a roadblock for anyone else working on the roadmap. The engineers and designers didn't know what he was trying to get to, what really mattered, or what he'd learned along the way, so they couldn't act without him. He wouldn't really support research that might have let them find out on their own. When he was looking at something, it moved. When he looked away, it stalled.

Then his concepts started to sell, and that made it worse. Now there was a growing set of offerings and still one head holding all of them. He couldn't split his attention into a roadmap that hung together.

Here's how it ended. He burned through his runway. His product delivery team turned over three times. And the roadmap slipped long enough that he's no longer first to market with the idea he raised money on.

The idea was good. What sank it was a queue with one person at the front, and a team that was never told why.

What the wait costs

Time is the obvious cost. Ship dates move a few days at a time, and every move comes with a reasonable explanation.

The bigger cost is what it does to people. When every call gets reviewed, and some get reversed, capable people adjust. First they stop bringing answers and start bringing options. Then they stop bringing options and start bringing questions. The ones with offers elsewhere take them. Keep that up long enough and you get what that founder got: a delivery team you rebuild over and over. And a founder in that spot ends up spending weekends on approvals anyone on the team could handle.

The two moves

Do these in order. A host with no rules has to guess, and a host who guesses wrong gets overruled.

Write down the why. The founder's taste is real. It's also stored in one head, which is the whole trouble. Take the calls the founder makes the same way every time and write each one as a rule a new hire could apply, with the reason next to it. The reason matters more than the rule. A rule covers the case you thought of. The why lets people handle the one you didn't.

To give you the flavor, a rule might read: "We don't build features for a single account, because each one slows down the next release for everyone else." Then write decision rights. For example, a team might own anything that fits in a couple of weeks of engineering and doesn't touch pricing, while pricing stays with the founder. Those are examples; your lines will sit somewhere else. Write them from the calls the founder has actually made lately, because aspirational rules get ignored by Wednesday.

Then let the team go learn. If the founder's judgment comes from customers, the team needs its own way to hear customers. Research is how the why stops being one person's memory.

The test is plain. Could someone new read the page and predict what the founder would say? If so, they can make the call.

I saw what this does to speed when I evolved Guidehouse's innovation lab into an incubator. Zero-to-one launches got 70% faster. Most of that came from coaching teams to work out quickly what was important and build that, instead of waiting for the person with the most expertise to decide what mattered.

Hire the host. Or appoint one, if the right person already works for you. The host is a strategic lead who owns the queue: what comes in, what order it goes in, and the daily calls that keep the kitchen cooking. The founder's job changes shape. They set direction and review outcomes on a fixed rhythm (what shipped, and what it did for customers), and they stop reviewing tickets. ("From pickup game to team" has more on who to bring in first.)

The hard part of this belongs to the founder. At some point the host will make a call the founder wouldn't have made. It'll work out fine, and the founder will want to reverse it anyway. Don't. If the call broke a written rule, fix it and talk about why. If it didn't, live with it or change the rule for next time. Overrule the host in front of the team twice and you've hired a receptionist.