Ask the CTO: Defeat micromanagement by trusting more and controlling less
Let the systems and your team do the work.
Line in the sand. (source: Pixabay)
The problem: Where’s the line between managing and meddling?
I have been managing people for a couple of years now and was moved into a role managing multiple teams. This is an exciting promotion, and now that I have oversight of all of the technology related to our billing systems, I hope to finally fix some things that have been annoying me for ages. However, I just got word from my manager that the tech lead on a new team is complaining that I’m micromanaging her, asking for too many details, and meddling in decisions that her old manager left to her discretion. But her old manager also was the person who let those annoyances build up. How do I know where the micromanaging line is, and how can I correct this situation without micromanaging her?
The solution: Trust more, control less
Micromanagement is one of the most hated management flaws out there. We have all heard the term and are familiar with it, at least theoretically. But how do you tell when you’re becoming a micromanager, and how do you step back from that place?
Learn faster. Dig deeper. See farther.
Luckily, someone will usually tell you when you are being a micromanager. If you’re getting complaints that you are asking for too many details or following up too much, you may be micromanaging. Micromanagement is a function of the person you’re managing and the role they hold. Junior engineers often appreciate having a manager who is constantly following up and asking for a lot of details and providing a constant stream of feedback because they don’t trust themselves to know what to do yet. Managing a junior team can give you a false sense of what good management feels like. However, even with junior employees will start to feel stifled in an overly controlling environment.
Trust and control are the main issues with micromanagement. If you are micromanaging someone, chances are it’s because you don’t trust that the task will be done right or you want to very tightly control the outcome so that it meets your exact standards. This happens a lot when talented engineers become managers, especially if they pride themselves on their technical skills. If your value to the team has shifted from the thing you’re good at, writing code, to the thing you don’t yet know how to do well, managing people, it can be tempting to treat those people as if they should be just like you. When a deadline slips, as it inevitably will, a micromanager will feel it as a failing to control the situation precisely enough and will ratchet up the attention. When something goes astray, it seems to reinforce your belief that micromanagement of the team is the right way for you to spend your time.
One theory of motivation is that most people are happy and motivated when they feel autonomy. This is why micromanagers find it so difficult to retain great teams. When creative and talented people are stripped of their autonomy, they lose motivation very quickly. There’s nothing worse than feeling like you can’t make a single decision on your own, or feeling like every single piece of work you do has to be double and triple checked by your manager.
Practical advice: Let go, delegate, and trust your team
How do you balance the need for your employees to have autonomy with your ultimate responsibility for outcomes?
Use the team’s goals to guide which details to dig into: When you feel like you want to micromanage, ask the team how they’re measuring their success and ask them to make that visible to you on an ongoing basis. Then sit on your hands if you must, but wait a week or two to see what they give you. When they have nothing to share, it is a sign that you may need to do a course correction, which probably means digging into details. How do you decide when to ask for this information to begin with? My philosophy is simple: if the team is making progress on their goals, the systems are stable, and the product manager is happy, I rarely dig into the details beyond a cursory overview. However, that requires goals with a plan for people to be making progress against, and a product manager who can give you another perspective. When you are managing a team that does not have a clear plan, use the details you would want to monitor to help them to create one. What are you holding them accountable against this month, this quarter, this year? If you can’t answer that question, the first step is to help the team create those goals.
Gather information from the systems before going to the people: As engineers, we have an advantage because systems can push valuable information up without the team needing to do much of anything. If you want to know the status of work, look at the version control system and the ticketing system. If you want to know how stable the systems are, subscribe to information about the alerts, look at the metrics, follow what has happened in on-call. The worst micromanagers are those who constantly ask for information they could easily get themselves. It’s OK to ask for status summaries and OK to use your team as a way of surfacing the most important information from all of these sources, but use a light touch. The team will not be productive or happy spending half their time gathering information for you that you could easily find yourself. And remember, this information is just a piece of the context, not the whole picture, and it means nothing without the goals discussed above.
Adjust your focus depending on the stage of projects: If you are managing a single team or two directly, you should know all of the details of the project status as as part of your regular team processes, such as morning standup meetings. Different details are important at different stages of projects. In the beginning and design stage of a project, you may wish to be more involved in order to facilitate a good set of project goals or a good system design. When you are close to a delivery date, the progress details become more important, because there are more decisions to be made and those specifics convey much more actionable information. During the course of normal workflow, it’s usually enough to know simply what is moving forward and what is taking longer than expected, especially if you can use that information to reshuffle work or help a struggling team member.
Establish standards for code and systems: I am one of those deeply technical managers, and I have opinions about the way systems should be built and operated. Letting go has been hard for me, so I developed some guidelines to help me feel better about the structure around these issues. Developing basic standards as a team helps everyone communicate with one another in code and design reviews, and it depersonalizes the process of providing technical feedback. For me, that meant things like how much unit testing we expected to happen with each change (generally speaking, there were always required to be tests), and when a larger group needed to get together to review a technical decisions, such as the process for adding a new language or framework to the stack. As with goal setting, putting standards in place here helps people know which details are important to think about when they’re creating the technology.
Treat the open sharing of information, good or bad, in a neutral to positive way: Let’s consider this scenario: Jack is having a hard time with a project, but hasn’t been asking for help with his problems. You finally hear about his struggles. At this point, it is appropriate to tell Jack that he needs to be more proactive in sharing his progress, even if it means admitting he’s struggling. You could have Jack give you daily updates as a way of helping, but I would do that only for a brief period. The goal is not for you to punish him with micromanagement for failing to communicate status, because all you’re doing is punishing yourself and hindering his ability to be held accountable for his own work. Instead, your goal is to teach Jack what he needs to communicate, when, and how. A word of caution though: if you treat a struggling engineer or project as a massive failure on the part of the individual or manager, she is going to feel that blame and criticism, and instead of giving you more information in the future, she will keep hiding it from you as a way of avoiding blame until it is too late. Hiding important information intentionally is a failure, getting stuck on a problem or making a mistake is often just an opportunity for learning.
In the long run, if you don’t figure out how to let go of details, delegate, and trust your team, you are likely to suffer personally. Even if your team doesn’t quit, you will end up working longer and longer hours as your responsibilities increase. If you are in this situation already, try simply limiting the hours you will let yourself work in a week. If you were only allowed to work 45 hours this week, what would you do with those 45 hours? Would you really spend five of them nitpicking a junior developer’s code? Would you pore over the details of some project that is going smoothly, searching for any minor error? Or would you put your attention on bigger problems? Would you take some of those hours to focus on the future instead of the details of the current moment? Your time is too valuable to waste it, and your team deserves a manager who is willing to trust them to do things on their own.