Hey folks,
Letter No. 9 hit inboxes yesterday.
In it, I did a deep dive (for a daily letter, anyway) on how you can navigate between being a hands on manager and a micromanager.
And this particular letter is free, so give it a read, but as promised, here's a quick summary here on dev.to!
At the outset, of course everyone hates being micromanaged. It destroys trust with your team, so obviously you want to stay away from it.
However, being hands on as a tech lead, engineering manager, or startup founder is inevitable and in some instances desirable. Every manager, sooner or later, will need to dive into the details, whether it's because he or she is managing a high profile project, under time pressure, or something has gone off the rails. Moreover, a lot of EMs at software companies spend a lot of their time writing code.
So the most important question is not whether you are managing details, but how the folks on your team are reacting to your fine grained management. "Micromanagement" is less of a process and more of a feeling by the one being micromanaged!
So, in the letter, I suggest two approaches to minimize the micromanagement effect. First is to check our motivations: if you're feeling the need to control your team for a variety of reasons, that could be a red flag.
Second, make sure you have a solid understanding of your team. If you don't, then use this as an opportunity to gain that understanding and gain trust with your team.
Then later in the letter, I mention that--for better or worse--there's no law against micromanagement. There are, however, some really important trust issues that we need to consider as leaders at our companies.
Without trust, your engineers can't do their best, creative work.
Top comments (2)
I have found a great question to discriminate between "hands-on" and micromanaging to be "is my team more or less productive when I talk to them?" I had one boss who would refuse to leave my desk until I could give an exact estimate he would hold me accountable to on a problem. I don't know about you, but sometimes I have no clue how long something will take until I have 20-30 minutes to dig into it and figure out what I am talking about.There were times when he would lecture me for up to an hour, during which time I probably could have finished the freaking task.
When I was briefly a team lead, I just made sure I knew what everyone was working on at all times. It may have been a little different because it was the consulting world, so I just wanted to make sure everyone was working on the projects I thought they were working on and making forward progress (I didn't ask about progress, I would check burndown charts and if a task had made 0 progress for a day or two, something was definitely wrong and we needed to figure out a plan together).
I made sure they had time to time to talk and ask questions. If they had any concerns or doubts, I wanted to know so I could get answers for them. If there were workplace problems, I needed to deal with them. I'd start the conversation allowing them to talk, and generally I would learn what I needed to without having to even ask that many direct questions once I gained their trust.
Maybe I just got lucky, but my team trusted me fully and I figure that means I must have been doing something right.
Scott - thanks so much for taking the time and writing a thoughtful comment. Super awesome!!!