·

Micromangement, The Silent Killer

The Control Trap: Why I Was Still Approving Emails at a Company I Co-Founded

It was 11:30 on a Tuesday night, and I was rewriting an email Rushi had already sent.

Not a high-stakes investor pitch. Not a press release. A sourcing inquiry to Vikram in Barmer, someone she had already met in person, already built rapport with, and already decided to work with. Rushi had written a perfectly good follow-up. Professional. Warm. On-brand.

And there I was, in bed, editing sentence structure on my phone.

Rushi saw the draft the next morning and said something that stopped me cold: “Dan, you realize you just edited a sent email, right? I already hit send. You were fixing something that’s already gone.” She said it the way she says most things, direct, no cushion, and completely right. Ouch.

I laughed it off. But it stayed with me. Because what I was actually doing, what I’d been doing for weeks, wasn’t editing. It was controlling. And I hadn’t noticed the line I’d crossed because micromanagement never announces itself as a problem. It disguises itself as diligence. As high standards. As the kind of founder who actually gives a damn.

Here’s the thing I’ve learned, and it took longer than it should have: it isn’t any of those things.

TL;DR: Editing sent emails at 11:30 PM isn’t diligence — it’s the control trap. The same outside-in mistake that ruins products ruins leadership. When founders build trust from the outside in (monitoring outputs) instead of inside out (building capability), everyone loses.

What’s the Mistake I Keep Seeing in My Own Mirror?

If you’ve read anything I’ve written about the Product Onion framework, you know the central idea: great products are built from the inside out. You start with the core problem, build a clear vision around it, and each layer earns the right to exist because of the one beneath it. Start from the outside with features, with marketing, with what looks impressive, and the whole thing collapses.

I’ve preached that for two years on this blog. And then I went and made the exact same mistake with how I was leading.

Micromanagement is building from the outside in, applied to people. You’re obsessing over the outermost layer of the output, the email, the slide deck, the exact wording of a supplier message, instead of working from the core. And the core, when it comes to leading a team, isn’t the deliverable. It’s alignment. It’s whether the person understands why this decision matters, not whether they formatted it the way you would have.

When I was rewriting Rushi’s emails, I wasn’t protecting quality. I was skipping every inner layer of the shared context, the trust we’d built, the fact that she’d sat across from these farmers, and I hadn’t, and going straight to surface-level control. Outside in. The same mistake I tell PMs never to make with products.

What Does Micromanagement Actually Cost You?

At HP, before I started building Trevean, I watched this pattern play out at scale. Managers who approved every minor product decision before a feature could move to the next sprint. They thought they were protecting quality. What they were actually creating was a bottleneck with a pulse. Nothing moved until they moved. And they were always behind.

The output wasn’t better. It was just slower. And over time, something worse happened: the team stopped thinking for themselves. There was no point. The answer was always going to come from the top anyway.

That’s what micromanagement actually costs you. Not time, although it costs plenty of that. It costs you thinking. The people around you stop bringing ideas. They stop flagging problems early. They start waiting to be told what to do, because that’s the system you built, even if you never meant to.

I’ve written before about how feedback works differently at startups; the signal-to-noise ratio is higher, and the stakes are more personal. But feedback only flows freely in an environment where people feel safe to think out loud. Micromanagement kills that environment. Fast.

And for founders specifically, there’s a scaling problem that’s almost mathematical. Every decision that has to run through you is slowed, distorted, or dropped. At a startup where the only real advantage you have over bigger competitors is speed, that’s a death sentence in slow motion.

Why Do Founders Micromanage Anyway?

Confession time. I know exactly why I was editing those emails.

It wasn’t arrogance. It was fear. There is that word again. Keeps coming up, doesn’t it?

Trevean Spice is the thing I’ve poured two years of my life into. The sourcing relationships, the NFC story, the blends Rushi has developed, all feel personal in a way that makes loosening your grip genuinely terrifying. What if the standard slips? What if the vision only lives clearly in my head, and nobody else is carrying it with the same intensity? What if I let go and something breaks?

Those fears aren’t irrational. But acting on them by controlling the output instead of developing the person, that’s where I went wrong. And I think most founders who micromanage are in the same trap. It’s not that they think they’re smarter than their team. It’s that the stakes feel too high to trust anyone else with.

There’s also an identity problem that nobody talks about. When you’ve been the person with all the answers, when being “hands-on” is a badge of honor, stopping that behavior feels like losing your role. Like becoming less essential. And nobody wants to feel unnecessary in the thing they created.

But here’s what I keep coming back to: the goal was never to be the most essential person on the team. The goal is to build something that works without me at the center of every decision.

What Happens When You Apply the Product Onion to People?

This is where the framework clicked for me in a way it hadn’t before.

In the Product Onion, Layer 1 is the core customer problem. If you get that wrong, nothing downstream matters; your features, your marketing, your growth engine are all built on quicksand. The whole point is to work outward from what’s real, not inward from what’s visible.

Leadership works the same way.

Layer 1 for your team isn’t the output. It’s alignment. Does this person understand the core problem we’re solving? Do they know why this supplier relationship matters to the NFC story we’re telling? Do they carry the product vision in a way that lets them make good decisions without checking with me first?

If the answer is yes, and with Rushi, the answer has always been yes, often more than with me, I don’t need to edit her emails. She’ll get it right. Maybe not the way I would have, but in a way that serves the same core.

If the answer is no, editing their emails won’t fix that. It’ll just mask it.

Most of the things that feel like execution problems, the email that’s slightly off-tone, the deck that doesn’t quite land, the sourcing decision you would have made differently, are actually alignment problems. Someone’s doing the wrong thing precisely because they don’t have a clear context of the core problem being solved.

Micromanagement treats this as a compliance issue. Leadership treats it as a communication issue.

The fix isn’t watching more carefully. It’s aligning more clearly upfront, so you don’t have to watch at all.

What Changed for Me When I Let Go?

When Rushi and I disagree on a sourcing decision now, I don’t override her. I go back to the core. What are we actually trying to prove with this blend? What does this supplier relationship tell the customer when they tap the NFC tag, or doesn’t it? If we’re aligned on that, most tactical decisions resolve themselves. She doesn’t need my approval. She needs my context.

I also started running a simple audit on myself. For one week, I tracked every decision that came to me that I could have honestly trusted someone else to make. Not the strategic bets. Not the product direction calls. The smaller ones. The Slack messages. The copy edits. The meeting agenda tweaks.

The list was embarrassing. And clarifying.

Because here’s the other thing I’ve written about before: what you prioritize signals everything about what you actually value. If I’m spending energy on decisions that don’t require my judgment, I’m signaling loudly that those decisions are where my attention belongs. The team reads that. And adjusts accordingly.

Why Should You Develop First, Then Trust?

The part most founders skip: trust without development is just hope. Hope is not a leadership strategy.

Before you can loosen control, you have to actually build the people around you. What does good look like for their role? Have you shown them, not just told them? Have they seen you make decisions and understood the reasoning behind them, not just the output?

At HP and Dell, the managers (Ed Reynolds and Bruce Kornfeld) I respected most weren’t the ones who gave the most autonomy. They were the ones who invested time early on, making sure the team understood the “why” behind every major decision. Then stepped back. Because they’d already done the work.

The sequence matters. Develop first. Then trust. Then get out of the way.

If you skip the development part, you’ll end up in a worse position than before. Things will go sideways, and you’ll use it as proof that you were right to stay involved. That’s not proof. That’s a self-fulfilling prophecy.

What Does the Long Game of Leadership Look Like?

I’ve been thinking about this a lot as we approach the decisions that deserve the next twelve months of Trevean’s life. The NFC integration at scale. The first retail conversations. The storytelling infrastructure that makes our relationships with farmers visible to every customer. None of those gets done right if I’m still approving sourcing emails.

You can fix your own behavior; that’s the short game. The long game is building a culture where micromanagement can’t take root, even after you’re no longer running day-to-day operations. That means decisions are made at the lowest level with enough context. It means people own outcomes, not just tasks. It means you hire for judgment, not just execution.

It also means tolerating imperfect decisions made by people who aren’t you. Some of those decisions will be wrong. Not catastrophically wrong, but wrong in the way you wouldn’t have been wrong.

That’s the price of a functioning team. Pay it. The alternative to catching every mistake before it happens is a team that never develops the muscle to catch mistakes themselves.

What’s the Uncomfortable Truth About Control?

Here’s what this is actually about.

You started a company because you had a vision. Something you wanted to exist in the world that didn’t yet. That vision came from you, your taste, your judgment, your point of view.

But a company that can only execute through you isn’t a company. It’s a freelance practice with extra steps.

The real test of a founder isn’t whether they can do everything. It’s about whether they can build a system, starting from the core and working outward, that runs without them at the center.

The founders who figured this out early built companies. The ones who didn’t build jobs, they can’t quit.

I’m still working on this. Most weeks, I catch myself reaching for control I don’t need. But the awareness is the beginning, and the Product Onion gave me a language for what I was doing wrong: building from the outside in, one edited email at a time.

If you’re a founder reading this at 11:30 PM, editing something that’s already been sent, close the laptop. The real work isn’t in the email. It’s in the alignment you haven’t built yet.

Related Reading

This post is part of an ongoing series on The Product Manager’s Journal, where I write about PM frameworks that come from actually building things, not just theorizing about them. If you’re navigating the same tensions between control and trust, between doing and leading, I put together a free resource called the Startup PM Toolkit, five frameworks (including the Product Onion) that I actually use at Trevean Spice. Grab your copy and hit reply to tell me which one resonates with you.

Frequently Asked Questions

Why do startup founders micromanage?

Founders micromanage because the company started as an extension of themselves. Every decision, every detail, every email — it all went through them. As the team grows, the habit doesn’t automatically stop. Micromanagement disguises itself as high standards, diligence, and caring deeply. Recognizing it requires honest self-reflection.

How do you delegate effectively as a founder?

Start by investing in capability before expecting trust. Train people on the “why” behind decisions, not just the “what.” Set clear boundaries for what needs your approval and what doesn’t. Then actually step back — and resist the urge to edit after the fact. Delegation isn’t just assigning tasks; it’s building people who can make decisions without you.

What is the connection between product strategy and leadership style?

The Product Onion framework teaches you to build from the inside out — start with the core problem, then layer outward. Leadership works the same way. If you start with surface-level control (monitoring outputs, editing sent emails), you’re building outside in. Great leadership starts at the core: developing your team’s capability and judgment first.