You’re in the hallway between meetings. One of your engineers, someone you’ve worked with since the beginning, pulls you aside. They have a quick question about a feature tradeoff. It’s a call you would have made instantly a month ago.
But a month ago, you didn’t have a manager. Now you do. Your new Head of Engineering is standing ten feet away.
This is the moment. It feels small, a simple question in a busy hallway. But it’s one of the most important tests of your ability to grow the company. Most founders fail it. I know I did, more than once.
We think hiring our first manager is a delegation problem. We write a job description, hand over a to-do list, and expect to get our time back. But it’s not a delegation problem. It’s an authority problem. And when you get it wrong, you don’t just fail to get your time back. You actively sabotage the person you just hired.
The Anatomy of a Failed Handoff
#The pattern is painfully predictable. You hire a great person to run a team you used to run. You’re excited. They’re excited. You tell the team Sarah is in charge now. Then the old habits kick in.
That hallway question? You answer it. It’s faster. It feels helpful. But you just taught your engineer that you are still the source of truth. You are still the real boss. Sarah is just a waypoint.
Soon, the team develops a pattern. They go to Sarah for process questions, but they come to you for the important decisions. They BCC you on emails. They ask for your opinion on mockups “just to get your eyes on it.”
And you, trying to stay in the loop, keep answering. You start overriding Sarah’s decisions, not in meetings, but with quiet suggestions to her direct reports. Within a quarter, Sarah isn’t a manager. She’s a high paid coordinator, a router of information between you and the team. She has responsibility for their output, but none of the authority to direct it. She’s frustrated, the team is confused about who to listen to, and you’re still buried in the day to day.
This whiplash, the constant thrashing between two centers of power, is the enemy of a team that can move smoothly. It’s how you burn out a good manager and stall your company’s growth.
Authority Is A Public Act, Not a Memo
#You don’t transfer authority by writing an announcement. You transfer it with your body in a hallway. You transfer it by making it visible, again and again, until the new pattern sticks.
When that engineer asks you the question, you have to turn, walk over to your new manager, and say, “That’s a great question for Sarah. Let’s see what she thinks.” You have to perform the transfer of power, publicly. It feels awkward. It feels slow. It is the only thing that works.
The harder version comes a week later. Sarah makes a decision you would not have made. Maybe she prioritizes a different feature or approves a technical approach you think is suboptimal. Your instinct is to fix it.
You have to let it stand.
Unless the decision is genuinely dangerous to the business, you must back her play. You can talk to her about it later, in your 1:1, as a coaching opportunity. But in public, her call is the call. The team needs to see that her decisions have weight, even when they differ from yours. The cost of a few suboptimal but owned decisions is far lower than the cost of a leader with no real mandate.
Drawing The New Map
#Authority isn’t just a single point of decision. It’s a territory. A failed handoff happens when the map of that territory is blurry. The new manager doesn’t know where her land ends and yours begins. The founder, used to roaming everywhere, keeps wandering back into her territory to “help.”
You have to draw clear lines. This isn’t about building walls. It’s about creating clarity so everyone knows how to operate.
Getting this right means being painfully explicit about who owns what. It might look like this:
- The Manager Owns: The weekly sprint planning, the 1:1s, the performance reviews, the day-to-day technical tradeoffs, and assigning engineers to projects.
- The Founder Owns: The quarterly product roadmap, the annual budget, cross-departmental dependencies, and the hiring plan for the next two quarters.
This isn’t a one-time conversation. It’s a living document you both refer back to. When a gray area comes up, you discuss it and add it to the map. This gives your manager the confidence to act, knowing she’s on solid ground. And it gives you a framework to hold yourself accountable. You can’t claim you’re just “helping out” on something that is clearly on her side of the map.
The Uncomfortable Price of Scale
#Here is the hardest part. The part you have to accept before you even write the job description.
Your new manager will be worse at the job than you were. For a while.
They don’t have your context, your years of history with the product, your intuition built from a thousand tiny failures. They will make mistakes you would have avoided. They will move slower. The team’s velocity might even dip for a quarter.
This is not a sign of failure. It is the cost of admission for scaling past yourself. You are not buying a perfect clone of you. You are investing in capacity. You are buying back your own time to work on the next set of problems the company will face. You are creating a system that can function, and eventually thrive, without your hands on every single lever.
That feeling of the company moving without you, of a decision being made that you only hear about later, is deeply uncomfortable at first. It feels like a loss of control. But that feeling isn’t the threat. It’s the goal. It’s the first sign that you’re building something that might actually be bigger than you, something that can grow beyond what you can hold in your own head.