When you step into management, whether you dutifully trained for that promotion or were thrust into it, the collective wisdom around your new role can be distilled into one directive: “Don’t micromanage.” It’s the golden rule of management — if you want to be a good manager.
But has this well-meaning advice created an anti-pattern for brand-new managers and seasoned leaders alike?
Newly minted managers are so scared of breathing down a report’s neck that they feel like they can’t help when someone runs into a problem. When product and design leader Hareem Mannan first became a manager, she remembers a fear of micromanagement holding her back from meaningfully supporting a new report. “I read everything I could get my hands on, and over and over again folks talked about not being a micromanager. I was so allergic to micromanaging that I ended up under-managing, which was probably the biggest place I failed early on — to the detriment of my direct report,” she says.
Under-managing is also characteristic of long-time execs who are so used to delegating that they never bother to poke around in the sprint plans or lines of code. Veteran CTO Will Larson thinks some leaders have gotten too comfortable flying at this bird’s eye view. “Too many executives take this kernel of advice not to micromanage and as they grow more senior, start to think of themselves only as resource allocators — that their main job is to allocate budgets to different teams and periodically check in on the quality,” Larson says. “While that’s certainly an important part of management, that’s not the entirety of it.”
As you get too far out of the details, you just become a bureaucrat.
-Will Larson, CTO at Imprint
We’ve long been interested in sharing strategies for better management here on The Review, from questions for manager self-reflection to the micro-habits of the most impactful managers to tips for managing up. With so much chatter both in favor of, and vehemently opposing, the notion of the “hands-on founder,” we were curious to explore the somewhat controversial topic of micromanagement in the startup world. As a company starts to scale, founders and startup leaders face a fork in the road: become a mascot or a micromanager?
So we wondered: How much micromanagement — and what kind — is productive? Can you stay involved in the minutia without stripping teams of autonomy?
We scoured the archives of The Review and the In Depth podcast to surface how founders and leaders across the org chart strike the right balance between details and delegation. Here’s who you’ll hear from — a roster of founders and execs who’ve managed across all phases of scale:
- Jack Altman, co-founder of Lattice
- Matt MacInnis, COO at Rippling
- Krithika Shankarraman, Stripe’s first marketing hire and former VP of Marketing at OpenAI
- Mike Brown, early Uber employee and former COO at Newfront Insurance
- Will Larson, CTO at Imprint, formerly Carta, Calm and Stripe
- Jay Desai, former founder and CEO of PatientPing
- Sidharth Kakkar, co-founder and CEO of Subscript
- Hareem Mannan, Head of Product & Design at Squint, formerly Pave and Segment
- Michael Lopp, Senior Director of Engineering at Apple
- Sam Corcos, co-founder and CEO of Levels
We’ve broken down their advice into both altitudes of management: Where and when to spend your time in the details, and how to empower your team to do excellent and impactful work without actually doing it yourself. Some of their philosophies may seem slightly at odds with each other. All share tactics for leading more effectively. Take what jibes with your own management style and company culture.
Flying close to the details
With a non-stop drumbeat of back-to-back meetings, startup leaders couldn’t pore over every nook and cranny of the business even if they wanted to. Use these strategies to figure out where to focus your attention on the ground level with your limited time.
Model the behavior you want to see from your team
To Lattice co-founder and former CEO Jack Altman, micromanagement is a tool that can be wielded both for good and for bad, particularly at the founder level.
“I believe that micromanaging has a bad rap and is extremely important and effective,” he says. “CEOs should do it. Executives should do it. Managers should do it. It's a potent tool that you should use sparingly.”
The wrong way, in his view, is hovering over someone who’s likely fundamentally incapable of doing their job. “A bad way to use micromanagement is to use it as a crutch to help somebody who’s in over their head, and to perpetually be doing their job for them,” he says. “If that's what you feel you need to do to be getting good results consistently over time, that’s a sign that you’ll need to change who's on the team.”
But the effective way to “micromanage,” as Altman sees it, is to model the kind of work you expect from your team. “One good way to use micromanagement is for standard setting and demonstrating the caliber of thought, work and effort that you want to see,” he says. That might look like writing a blog post or fixing a bug yourself, for example.
Another use is to channel some TLC toward a function or area of the business that you’d like more investment in. “The CEO being highly involved in a certain area can attract energy in that direction. So by getting yourself into the details in that area, you'll bring others along over time.”
Like any tool, Altman encourages using it wisely. “Micromanagement is a shortcut that you don't want to always use, but shortcuts have value. As long as you're using it sparingly and you're using it in a way that's either helping coach and guide, setting standards and bringing attention, those are really important uses of micromanagement,” he says.
Look for data anomalies as a cue to micromanage
“If there's any one secret to ‘effectiveness,’ it's that great executives do one thing at a time and they do the high-priority things first,” says Rippling COO Matt MacInnis.
At Rippling, this philosophy is codified in one of their nine leadership principles: go and see. “It means leaders shouldn’t live in the dashboard,” MacInnis says. “When the anecdotes disagree with the data, you've got a problem. You have to go and see for yourself, which means getting straight down to the atomic level of the function you're interested in to gather context.”
When the macro data isn’t adding up, execs need to understand why by getting to the ground truth. This could mean:
- Reading through customer support tickets
- Watching sales call recordings
- Dissecting customer interactions with the brand website
“By watching back a Gong call of a sales engagement, an exec can say, ‘Hey, I noted in this call, when the customer said X, the rep did not redirect back to the superpower we have that would solve the problem,’” MacInnis says. That catalyst should kick off a chain reaction of curiosity for any high-impact exec.
“It implies the rep doesn’t understand what our superpower is, which in turn, implies a bunch of reps don’t understand what our superpower is. Which implies our training sucks, which implies the product marketing organization has failed, which implies we’re screwed,” says MacInnis. “You’re packaging this all up as a hypothesis and serving it to your department heads, and asking them what they think.”
It then becomes the functional team’s job to disprove the exec’s hypothesis. Most of the time, MacInnis says, they can quickly point to incorrect assumptions. “But if they can’t, then we work together to figure out if my hypothesis is true or false. We’ll write it down and go through the motions over the course of weeks, trying to debug the system. But it always starts with ‘go and see.’”
I’m not a micromanager, but I’m microinterested.
-Matt MacInnis, COO at Rippling
So when can executives step back after doing some field research? Whenever that dashboard starts showing the numbers you want to see. “We haven't solved the problem until we've seen the output metrics begin to turn in the direction that we want them to,” MacInnis says. “We keep fiddling with the system until our output metrics start moving in the right direction.”
Create review systems to maintain the quality bar
Stripe is known for its reverence of taste and craft. That’s largely because of Krithika Shankarraman, who was Stripe’s very first marketer and responsible for shaping much of the foundation behind the brand today.
It’s remarkable Stripe’s brand diligence hardly wavered as it evolved into a billion-dollar, multinational company. Shankarraman credits much of that consistency to the organizational reviews put in place by the marketing team — alongside founders John and Patrick Collison — to make sure everything they shipped stayed true to the Stripe brand. “I'll be a little contrarian here and say that I don't think we scaled taste at Stripe. Instead, we invested in processes and systems that ensured that everything that went out the door had taste,” she says.
Internal reviews don’t just help steward a company’s brand — they can help decentralize knowledge, ensuring that new hires can learn the founding team’s taste.
“Often, what I see happen at scaling startups is that everything is in the head of the founders or the one early marketer who knows everything. And by the time a new person comes in, they don't know how to succeed. Too much of it relies on social capital,” she explains. “We designed systems so a marketer in their first month at Stripe would know exactly how to take something from idea to execution, following a series of processes to make sure their work was very effective at the company.”
She shares two tactics Stripe used to structure internal reviews:
Assign “red pen holders” to advocate for the user.
At Stripe, there were designated red pen holders (this was a literal title) in each domain who marked up anything that went out the door to an audience of more than 100 users, whether that was a blog post or email or event plan. The red pen holders’ role, says Shankarraman, was to act as someone looking at the project with zero context.
“There were some people who held the red pen, and as reviewers they were putting on the hat of the user and asking, ‘Hey, if I'm a user who's seeing this piece of collateral for the first time, am I confused? What questions do I have? Is it in line with the Stripe brand in terms of consistency?’” Shankarraman explains. “It was about improving the work rather than questioning the strategy.”
Set 20% and 80% checkpoints.
Don’t wait until the night before launch to take a red pen to the materials the team put together. Review when there’s still plenty of time to change course, if necessary.
“At Stripe, we would do a 20% strategy review to make sure we were aligned on the goals and intent of any big project,” says Shankarraman. “Then we would do an 80% review for the execution and check in on how things were going — what each of the channels and collateral looked like. It’s important to check in at the 80% mark, and not the 99% mark, because you still want the ability to make changes.”
The thoroughness of the check-ins depended on the stakes of the project. “Sometimes it would be a very quick, ‘This looks good, let's get it out the door’ situation. Sometimes it was about asking, ‘Is this really the right audience? Is this really the right positioning?’” Shankarraman says. “For product goals, we might ask, ‘Is this the right product direction if we're marketing it in this way? Are we constrained to market it in this way? Should we not be making some changes upstream to what we're launching in the first place?’”
I don’t think you can build a good brand without micromanagement. It gets a bad rap for depriving people of independence or autonomy — but it’s about putting your user first.
-Krithika Shankarraman, first marketing hire at Stripe and OpenAI
Establish a cadence to go deep on a KPI
Mike Brown, who oversaw Uber's expansion in Asia, recommends a regular cadence of zooming into different projects and business areas.
“Good management is about more than setting clear goals and holding people accountable. Truly great managers get deeply and personally involved in key decisions and help shape the outcomes,” he says. “I don't like it when an employee says, ‘My manager is great. She leaves me alone to do whatever I want and doesn't micro-manage.’ I understand the sentiment here, but to succeed, managers must identify the key decisions or problems that are material to the business and they must personally drive results.”
Great managers, according to Brown, are like porpoises, the aquatic mammals that can swim at both the surface and the depths of the ocean.
The best managers know how to ‘porpoise’ — they know what’s going on with everything at a surface level, but go deep on select initiatives.
-Mike Brown, early hire at Uber and former COO of Newfront Insurance
Brown “porpoised” on a quarterly or at least semi-annual basis when he was at Uber, choosing several projects most closely tied to his team’s KPIs to dive below the surface. “I would go deep on one project tied to a people/culture KPI, one project tied to a top-line growth KPI, one project tied to cost reduction/efficiency KPI and one project most likely to improve customer experience,” he says.
If an existential threat or once-in-a-startup-lifetime opportunity presents itself, leaders should recognize the signal to dive into the details immediately. “I was always hands-on in those circumstances,” says Brown. “For example, when the Philippines government shut down our business for a month, I camped out in Manila and worked side by side with the team on the ground to figure out how to get cars back on the road and repair our then-strained relationship with the transport regulator.”
Go “conflict mining” with ICs to gather micro-context
Imprint CTO Will Larson’s advice for senior leaders coming fresh into a new role, whether that’s at a new company or within a new function at a fast-growing startup, is to get context as quickly as possible through what he calls “conflict mining.”
His experience is in the engineering side of the house, but his advice stands for leaders of any domain. “The number one way that I see new engineering leaders struggle when they come into a new place is that they assume the context from their previous company applies as is,” says Larson.
One of his favorite tactics for resisting this impulse — and learning the ins and outs of a new culture and system — is to have long conversations with team members who are closest to a problem and might be skeptical about an executive’s gameplan.
Larson learned this by making the mistake of trying to force a system he’d used at a previous company onto his new one. When he left Uber to join Stripe, he wanted to replicate the self-service provisioning he’d spun up that worked well at Uber. But the idea was met with resistance from a Stripe engineer. He thought his new colleague was just being stubborn at first, but after digging deeper with him, he realized there was a core architecture issue preventing the proposed solution.
This process of conflict mining served Larson a key lesson. “I could have just ignored him, but then I would have missed the key learning, which is that I was the one who was missing context, and needed to refine my approach,” he says. “Things are not the same across companies, and you can figure that out pretty quickly by finding something controversial and testing for conflict. The wrong way to solve this is to actually implement the conflict-heavy thing. The right way to do it is just to go have a bunch of conversations.
One of the biggest lessons in management over the last decade is that micromanagement is bad. But I think this is an anti-pattern, because it creates disengaged and context-free leadership, and leadership can be so much more than that.
-Will Larson, CTO at Imprint
A core component of Larson’s conflict-mining strategy is talking to the people who have the most context around a problem — who are typically ICs, not other executives. “You can usually get buy-in from other executives pretty easily, but it’s much more difficult to get buy-in from people with the most context around a given problem,” he says. “Their opinion is most valuable because they are the ones who live in the details. You can’t lie to them. They know the truth of how things run.”
Micromanage your product on behalf of your users
“If you ever talk to somebody who's worked at Rippling, you'll hear funny stories about how our CEO, Parker Conrad, personally approves every expense over $5,” says Matt MacInnis. “He still runs payroll for the whole company.”
Conrad doesn’t have a particular passion for accounting. Rippling is an end-to-end payroll platform, so he’s never once stopped using his own tool to manage the now 3,000-person, $11 billion dollar company’s finances — because it’s the best way to keep a pulse on the product and how customers are experiencing it.
MacInnis says that dedication to dogfooding is a charter for all leaders at Rippling. “There’s a company I know, a competitor even, with a pretty good payroll business that at a certain scale, switched to Workday for its payroll needs,” MacInnis says. “When they stopped using their own product, they outsourced the work of figuring out what’s useful to customers and staying abreast of the market. If your business is predicated on the very fine, nuanced things you believe about the market and a relentless pursuit of those things, somebody who's there from the beginning has to keep their hand on the yoke.”
But there’s something to learn here from Conrad’s intense accounting practices even if you aren’t building a payroll platform. “If you take your eyes off these things, you no longer have a founder mindset toward spending money, it becomes an employee mindset,” MacInnis says. “You’ve got to watch it like a hawk, or that stuff will slip away from you. And it’s very hard to pull it back.”
If you stop being the most critical user of your product, you are toast. You take your foot off that gas by 5% or even less, you’re still toast.
-Matt MacInnis, COO at Rippling
Zooming out to empower your team
Leading a startup through hypergrowth means handing over at least some of your Legos. When you need to fly at a higher altitude, use these systems to recognize (and stop) the unproductive kind of micromanagement — and delegate without sacrificing the quality bar.
Treat micromanagement like a symptom — and get to the root cause
Former PatientPing founder and CEO Jay Desai popularized the practice of writing a “user guide,” which is essentially a user’s manual for your coworkers. You can borrow his template, which outlines preferences and expectations across all the important domains of a manager-report relationship, from communication to reporting to 1:1s. There’s a section in Desai’s user guide specifically dedicated to micromanagement, which he views as a symptom of distrust.
“I am hands-on until I trust you. Once I trust you, I’m hands-off and we’ll collaborate as you need me or when I bring you ideas for us to work through together,” he writes in his user guide. “Our relationship will feel more like a partnership or me supporting you than boss-manager if we’re successful at building trust (though I will be in the manager role when needed).”
When Desai notices that he starts creeping into micromanagement territory, he knows it's because trust has splintered. “If I get in your hair again, it’s because I’m losing trust in you or don't feel like we are making adequate progress on a given topic,” he says.
Naturally, there’s a section in his user guide for when that happens. He encourages managers to diagnose and repair trust before they can zoom back out. “It’s important to intervene early as soon as you recognize you’re starting to lose trust in a report. Micromanagement is a great trigger that this is happening,” says Desai. “That’s when I tell them I'm starting to lose confidence in them. Then, I refer them to the section of my user guide about feedback as a tool to diagnose why trust may be deteriorating — then we talk about it. That intervention is necessary because, once the trust is fully gone, I’ve never been able to regain it.”
Give regular feedback to stem the need for micromanagement
Sidharth Kakkar, co-founder and CEO of Subscript, is firmly anti-micromanagement. He’s built a fully asynchronous, remote company culture with no meetings (read more about how he did that here) where zero micromanagement is a core pillar.
He believes the founder’s role is to think about the system-level things you can do differently so bad decisions — or misaligned decisions — don’t happen. In an autonomous workplace, employees are trusted to find solutions to the problems the founder hired them to solve.
Here’s how Kakkar keeps his own micromanagement tendencies at bay:
- Before you give an opinion, ask yourself, “Am I right or do I just have an opinion? If I am right, what’s the cost of being right?” You might discover what you have to say is better off left unsaid.
- Trust others to do what they do best. Focus on the things that only you can do and leave the rest to everyone else.
But that doesn’t mean he never gives anyone any direction. Feedback, instead, is Kakkar’s vehicle for making sure his team is operating effectively. “Everyone should give each other feedback, but without a dedicated forum, feedback always feels a little more offensive,” says Kakkar. These are his three recommendations from running the feedback process at Subscript:
- Make it regular — monthly, even. Subscript operates on a monthly cadence. “It’ll feel like a lot, but it’s so worth it,” says Kakkar. Regularity helps everyone get more comfortable giving and receiving feedback.
- Design a lightweight system. “It shouldn’t feel like a big, onerous task that you want to put off.” He suggests the Start-Stop-Continue framework.
- Don’t leave your high performers out of the process. “Don’t rob these folks of the chance to improve, even if they’re already operating at a high level.”
Set up peer office hours
Like Kakkar, design leader Hareem Mannan gives plenty of feedback to avoid micromanaging while still making sure everyone on her team is performing. But instead of spending her own 1:1 time with a report who’s not meeting expectations, she empowers a peer to deliver that feedback.
She unpacks a few of the structures she implemented at Segment — particularly when someone on her team is struggling. “If a designer’s work is not at the visual quality I expect, micromanaging might look like this: Every 1:1 I pull up the design, give them my in-depth opinion and critique. That’s not really my style. Instead, I prefer to create mechanisms for peer accountability or gates for quality,” she says. “You can create tools and mechanisms in your team that allow for that quality bar so you’re still able to ship high-quality work as a manager, without having your hands in everything.”
That meant shoring up her team’s design critique process in the form of weekly office hours with design leads. “One of the first things I did to scale critique was implementing design office hours with design leads. I never want folks to say they didn't have an opportunity to get feedback on a piece of work. When I felt like the work of a direct report was not of the quality I expected, instead of using my 1:1 time critiquing, I would ask them to go to office hours that week. Sometimes I’d chat with the person who was leading the office hours and let them know the challenges I was seeing and where I’d like to see improvement, without dictating exactly how to get to that end result,” she says.
But you can’t just expect teammates to give each other feedback if they don’t know each other. To get her team more comfortable with one another, so that receiving peer feedback in an office hours session wouldn’t feel out of left field, Mannan also held a “Design Hangout” every other week. “I'd say that Design Hangout and doing something fun together as a team has done more for design quality than even design critique itself. Because now I find that designers I didn't even know were friendly with each other are meeting and sharing their work. As a leader, it’s your responsibility to create that environment,” says Mannan.
You can’t expect critique sessions or office hours to work unless you create forums for folks to connect with each other socially, so they’re comfortable with using those forums to begin with.
-Hareem Mannan, Head of Product & Design at Squint, formerly Pave and Segment
Give your team a box filled with ideas
“As an engineer, nothing ticks me off more than micromanagement,” says Apple engineering leader Michael Lopp. “I never want to tell people what to do, because I never want to be told what to do.”
Instead of barking orders, Lopp’s communication style is grounded in storytelling — and sharing a grab-bag of ideas with his team. “Instead of giving people a list, good leaders offer them a box and fill it with interesting ideas,” says Lopp. “It allows the folks you’re leading to go and put themselves in that box and see what they want to do with it. Whether you influence them or not doesn’t really matter. Your goal is to get your people thinking and give them as much information as possible.”
Some people still like to be told what to do, but Lopp prefers his “season the soup yourself” method. “I’ve gotten frustration from engineers who end up saying, ‘Can you just tell me what to do here?’ Most of the time, I say no. Sure, a lot of people want to be told what to do, but even when you try to be dictatorial, they tend to apply their own approach to that order anyways.”
As a leader, it’s your job to be a storyteller. Give your folks the soup, then leave it to them to drink it as is or add whatever they want.
-Michael Lopp, Senior Director of Engineering at Apple
Hire managers who can do the work themselves
A few years back on The Review, Sam Corcos shared the minute-by-minute breakdown of how he spent his time over the first two years of building his company, Levels. Recently, he returned with the 5-year update of his data — and had several reflections on where he could’ve spent his time differently as CEO.
In hindsight, one of his regrets is that he stopped writing code as the company scaled and he turned his attention toward growth, operations, strategy and recruiting. “I took about a two-year hiatus from the codebase. This was a costly mistake that was quite painful to undo,” he says.
As Levels grew to 60 people and added new management layers, shipping decelerated. “What happened next was all too predictable: Velocity ground to a halt. Two-week projects ballooned into three-month ordeals. We drowned in pre-work, specs and planning meetings. We’d spend months building in one direction, then change direction without shipping anything. Meanwhile, our app was becoming a buggy mess,” says Corcos. “Looking at the data, I have no one to blame but myself. It’s easy to see from reviewing my time from these couple of years that software development was not my priority, and it should have been.”
Corcos has since recalibrated both his own time spent on software development and the team’s processes. Now, across functions, he looks for managers who can still do the job of the people they manage — so the CEO doesn’t have to swoop in to micromanage when things break.
“We no longer hire pure ‘managers’ at Levels, and we probably never will again,” says Corcos. “The managers we hire need to be capable of performing the tasks of those they manage. If they manage engineers, they need to be able to write excellent software. If they manage marketers, they need to be exceptional marketers themselves. Hire people who can be ‘button clickers’ instead of finding someone else to click the buttons for them.”