The Recovering Micromanager's Guide to Letting Your Developers Work

Written by: Erik Francis

It's Friday at 4 PM. You wish this status meeting was over, yet it drones on. It's impossible to stay focused, knowing that in four hours, you and your family are boarding a plane to Mexico for a long-planned and much-needed family vacation. You can taste the salt of that first margarita and feel the hot sun calling you out for a dip in the refreshing ocean. As your team reports one by one what they worked on today, you begin to notice their "what I will work on tomorrow"s seem ambiguous and far-reaching. Darn, you think. These folks know I'm leaving for vacation, and they seem lost already. I can't have progress slow down while I'm vacationing; everyone knows how important this project is! I'm going to need to stay late again and make sure each person has a full plate for the week ahead. Have you ever been in a similar situation? Your team seems to function well when you're their taskcontroller, but as soon as you step out of the picture, the progress nearly halts. Your vacations are usually only half relaxing because you and your family know that work is just a phone call away.  You remain tightly tethered to your phone and have access to email at all times. You can't unplug. You're frustrated with your team members because no one will step up and make decisions without your approval, and the only creativity when it comes to product development is a result of your ideas and suggestions. If you can identify with this---and believe me, I can---you might be a micromanager.

Recognize You Have a Problem

The path to micromanagement is not a complicated one.  Promotions are given to developers when they're really good at what they do.  The set of skills to be a good developer include many of the following traits:

  • Problem-solving and thinking all around the box, not just outside it

  • Great attention to detail

  • Good at managing tasks and breaking problems down into smaller chunks

  • A love of learning

  • Pragmatic

  • Analytical

Throughout the career of the software developer, these traits are reinforced by management time and again as the developer builds software and solves problems.  The developer becomes recognized by their own leaders as a true asset to their team and is promoted to lead developer.  In the developer's mind, this is great news!  More money, some new responsibility, and they still get to code! Now things begin to change.  The development team will start coming to the leader with questions, expecting answers.  So the new lead shifts into the pattern of problem-solving---an area of expertise---but now its problem-solving for others.  Over time, the team relies on the leader to solve problems for them and think of creative solutions.  The more the lead provides answers and solutions for the team, the more this behavior is reinforced.  A micromanager is born. This is the natural progression of things, especially in the world of developers.  If we're not intentional about how we behave, we'll understandably fall into natural patterns. In this case, there are better alternatives.

The Case FOR Micromanagement?

Before we drive down the road to recovery, why don't we investigate the case for micromanaging your team?  Are there times or scenarios where micromanaging an employee or your team makes sense?  Two areas quickly come to mind: a poorly performing team (or team member) and a new team (or new team member). But I'll argue that neither of these cases truly should be addressed with micromanagement.

The Poor Performer

Obviously, a poor performer could benefit from someone making sure their job gets done and gets done correctly, right? Initially, one may tend to think that yes, this is a valid time to start micromanaging.  You may be able to get a poor performer back on track by managing their duties and tasks for them. But in the end, what will you have?  An average, or even slightly below average, team member who exhibits the signs of being micromanaged (lacks decision-making abilities and creativity, needs you to check their work over once or maybe twice an assignment). As leaders, we want our team to be exceptional, not average.  As leaders, we want to be casting the vision for our team and leading them there, not managing their day-to-day work activities.  A true professional does this without being told.  Wouldn't it be great to be surrounded by true professionals? That can only happen if you coach your poor performers to be this way.

New Teams/Team Members

Would a new team member or even a new team benefit from micromanagement?  Surely they'll need to know how to perform their job and how they're expected to behave in this new environment.  The micromanager could simply sit with them for the first few weeks, give them some tasks, and then, each day, make sure those tasks are getting done.  How else could this new member get training? It is true that new team members need training, but is micromanaging them really going to get them to where they need to be?  If we want professionals on our team and we're hiring well, we have to have confidence that the new team member can engage quickly.  Sure, you want the new team member to have work they're responsible for, but this is the leader's opportunity to learn about how this new teammate will work.  If the team all of a sudden has some turnover, the micromanager won't recover by sitting with all the new team members day after day, making sure their work is getting done.  Instead, the leader should have onboarding guides for new team members and consider pairing them up with others who could be their liaison for resolving blockers. The case for micromanaging is weak to nonexistent.

The Road to Recovery

Once the shift is made from micromanager to recovering micromanager, it may help to remember one thing.  The skills required to be a great developer are different than the skills required to be a great leader.  Leading people is a new skillset. Instead of resisting learning this, dive in head first!  It will have you writing articles like this one before you know it.

Your New Goal

As a team leader, you have a new goal.  In addition to delivering high quality, mind-blowing software, you need to develop your team and its members!  Your goal is to get to know your team members and start building relationships with them.  Understand that everyone has different personality types, and try to figure out what type each of your team members has.  Learn what they enjoy doing and what they don't enjoy doing. This can happen during a weekly one-on-one meeting.  These meetings can be awkward at first, and you might be tempted to cancel it.  Try to stick with it each week since you are learning more about your team member.

A Cautionary Tale:

When I became a new leader, I wasn't fortunate enough to receive advise like this.  I thought I could just use the skills that elevated me to this position and just work harder and smarter.  Maybe I could compensate for a weak team member by working harder.  Late at night after work, I could redo a bad pull request. But this can only work for so long. Exhaustion and burnout are on the way.  Instead of doing what I did, spend your energy getting to know your teams. It's the foundation of what comes next.

Delegate, Don't Do

Sadly, as a team leader, you won't have as much downtime to just sit and crank out elegant code.  Delegation, while being the easiest skill to understand, might be the hardest one to implement.  Learn as much as you can about it, practice it, and stick with it because this is the first step to building the next you. You'll be tempted to just do some of the work yourself. But instead, use your energy to teach someone else how to do it.  Remember, a small task on your list is equivalent to a big task for your delegate.  Try to recall the first time you did that task and its result. Was it perfect?  Have grace for your delegate.

A Cautionary Tale:

I am a do-er, so everything about delegation is counter to who I am and what made me successful to the point of becoming a leader.  Even though I clearly understand the benefits, I often struggle with this on the teams I lead. I've been extremely fortunate to be part of a leadership group that meets about every six weeks.  We discuss challenges and try to hold each other accountable.  I have found these meetings to be very encouraging. I recommend you find a group of like this that can help you work through the impulse to do everything yourself.

Coaching and Feedback

Daydream with me here...you're getting to know your team, their likes, dislikes, and maybe their goals and aspirations.  You're delegating tasks to them and having regular one-on-ones with them.  The team is functioning well but could be better.  You like that the team has the freedom to make decisions, is coming up with creative solutions, and even performs well while you're on vacation.  But there's room for improvement, and you want your team to function even better. The next logical step is to start coaching them.  This can be done using the feedback model.  This will help you to coach your team members in the directions you feel they will excel best.  In fact, even if the dream doesn't come true, coaching and feedback can bring you closer together.  Setting clear goals and coaching your team to achieve them can unlock unknown potential in your team members. As you start thinking of a leader to succeed you, these techniques will be invaluable.

A Cautionary Tale:

Feedback can be very difficult.  When I first started giving feedback, I gave only positive feedback (mostly because, hey, who doesn't want some positive feedback?).  I found the positive feedback to be effective for many things, but I feared the day that would force uncomfortable, negative feedback.  Soon, I realized this wasn't fair to my team members because, deep down, I was disappointed when they didn't get it right and positive feedback wasn't working.  I wasn't putting my team first by helping them grow; I was putting me first by avoiding discomfort.

A Leader, Not a Manager

If you've identified yourself as a micromanager, you have some choices to make.  There's strong evidence for why you should lead your team versus micromanage them.  In the face of this, to continue on the path you're on seems illogical and not very pragmatic. You can learn the skills of coaching and delegating quickly, and while it won't be easy, it will be worth it.  These translate into valuable life skills that will help you in so many areas. You shined as a developer. So how well can you help a developer shine? I encourage you to make the investment and become a leader of great developers!

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.