When I became an Engineering Manager, my biggest fear was turning into a control-freak micromanager I had worked for in the past.
So, over the next few months, I leaned hard in the other direction. I delegated everything, kept processes light, and even said in a meeting, “I hate Jira!”
But despite my best intentions, I became exactly what I was trying to avoid.
My Story as a Micromanager
Last year, I was assigned a project I didn’t fully understand. I did some surface-level reading and shared a vague outline with my team, “We need to tackle this project!”
Not wanting to micromanage, I left the project definition and execution to my team. After all, they were the experts.
Three weeks later, the work was nothing like what the stakeholders expected. I panicked and jumped in. Suddenly, I was:
Breaking tasks into minute details and assigning them myself.
Dictating exactly how things needed to be done.
Holding daily check-ins to monitor progress.
Pinging for constant updates because others were breathing down my neck.
The project got delivered, but I had to become a total micromanager. It was my fault because I didn’t do a good in the beginning. I didn’t set the dial to the right setting.
The Management Dial
I see management style as a dial between two extremes.
On one end, extreme micromanager who controls every detail, demands constant updates, and overwhelms the team with their presence.
On the other end, invisible manager who delegates everything, avoids accountability, and leaves the team in uncertainty.
Most of us aim to be somewhere in the middle, depending on the context and the team’s needs.
But in the last few years, I’ve seen new managers end up more on the invisible side like me. Because they are worried about being called a micromanager. Some EMs have never managed a remote or distributed team, so they just let leave them alone.
I’m learning that micromanagement isn’t inherently bad. Sometimes, it’s exactly what a situation needs. The key is knowing when and how to do it without being a jerk.
How to Be a Micromanager (in a Good Way)
The goal isn’t to control everything. It’s to provide the right level of involvement based on the situation. Here are three steps to take when you’re driving a project:
1. Start with Clarity
If you’re not clear about what needs to be done, your team won’t be either. Before delegating, gather and share as much context as possible. And be there to provide clarity along the way as you discover new information.
Define the problem: Who are the users? What are their pain points?
Clarify outcomes: What does success look like?
Provide context: What constraints, dependencies, or leadership expectations exist?
In the past I said something like, “Let’s build a dashboard for the deploy pipeline in the next sprint.” Now I’d say “We need a dashboard to help developers track deploy times. Right now, they rely on Jenkins UI, which has limited history and makes comparisons difficult. We have the possibility to allocate two engineers for the next three sprints to work on this.”
2. Create Structure
Engineers hate processes, so maybe don’t use that word. Instead, establish some team agreements on how you will communicate and track progress.
Define project tracking: Will you use regular standups, slack messages, or a shared board?
Set ownership expectations: Who’s accountable for what? How should issues be flagged?
Establish guardrails: Empower your team to make decisions within set boundaries.
On a recent cross-team initiative, I realized the weekly meeting wasn’t enough to understand the project health and blockers. So I set up a shared Kanban board, agreed on timelines, and established a more frequent communication cadence. I suggested to review in a few weeks if we need to dial it back.
3. Provide Feedback Regularly
Pay attention to how people behave and deliver. Use that to provide specific and timely feedback to ensure they learn and grow. This will eventually help you manage less.
Project Retrospectives: Use retrospectives to reflect on what went well and what didn’t.
Set individual expectations tailored to each engineer and their role in the project.
Provide 1:1 feedback to address specific behaviors or skills.
I don’t frame it as “hey, I have feedback” but more like “hey, I saw you asked questions on unclear requirements. Great job. Continue doing that”. Yes, someone might say you’re watching every behavior so you’re micromanaging. Let them say it, you’re doing your job well 😊
Final Thoughts
Remember, your number one job as an Engineering Manager is to deliver value to the organization while supporting your team’s growth.
If that requires stepping in and managing details, then micromanage. If the team is operating smoothly, step back and let them lead.
The key is to dial your management style to fit the situation. At the end of the day, your job isn’t to manage to a specific philosophy. It’s to meet your team’s needs and deliver results.
Any good manager does some work on self reflection. Any bad manager has a low self awareness. The first half is reading your post. The second half consumes all the energy in the organization.