Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: micromanagement

  • Difference between Managers and Leaders

    When talking about managers people often confuse two terms: a manager and a leader. The difference is pretty simple however.

    Management is a job while leadership is an attribute.

    You can be promoted to a manager role, but you can’t be promoted to be a leader. To become one you need to work your butt out showing your leadership in the battlefield. You have to inspire people, make them believe they can achieve a goal and motivate them to work harder. Or smarter. Whatever. That’s definitely not enough to tell them “go and get that and better be quick.”

    In normal situation managers, who aren’t leaders, usually end their work when they tell their teams what to do. Micromanagers go even further. They tell what and how exactly thing should be done. Anyway they’re barely a kind of task-dealers.

    Leaders not only point goals and give out tasks but also encourage people to show their own initiative and creativity. They take decisions when it’s needed and are always ready to face any problem team can encounter. You’d willfully follow the leader while you wouldn’t follow the manager if you didn’t have to. Not that you often have a choice.

    Good manager is always a good leader while poor manager is barely a white collar.

  • My Micromanagement Experience

    I’ve already written about micromanagement in general. Thing I haven’t yet shared is my own experience with learning how to live without micromanagement.

    When I started having any impact on my colleagues (I wasn’t their formal boss, it was just an informal leader role) I also got some responsibility for a part of development process – it was planning and running functional testing against an application. Because people I worked with were all newbies I decided (surprise, surprise) that I’ll do the most responsible part leaving “my” team the rest. It looked so natural. Hey, who’s the most experienced person here? Who’s the hero?

    There were only five of us, including me, so it worked well that way – the final release was hard earned, but despite 3-week slip I still consider it as a success. I earned my very own team then. It soon grew up as we took over also responsibility for support. And then the model collapsed. I could no longer take every important issue on me. I could no longer check everyone’s work. I could no longer say how to do every tiny detail of our work. More people – more managerish work and less time for the rest. Bigger responsibility – more important tasks to control.

    I was lucky to have quite a good team then with several persons which had already earned my trust, so my lesson didn’t have a big impact on our general performance, but with other people I wouldn’t be so sure if I’d be there, where I am now.

    Later on, my boss asked me who’d be my successor as a manager. I didn’t know, but I told him I’d come with some plan on that. I thought about that: “Hey, I’m the one who know the job – the team is only executor of my will. How they’d know what to do without me?” The Red Light of Micromanagement would blink then if there were any. This was another lesson to learn – the team has to do all the tasks, even most important ones (maybe except of some managerial crappy things no one wants to deal with). “What-ifs” came to support the lesson. What if I went to holidays and something serious would happen? What if a car hit me? What if I changed the job? Oh, wrong example, who’d care than? What if I was promoted than? The answer was always: it would be a problem.

    I found a couple of people and delegate (what a nice word) important tasks to them. Not every single case was delegated, but at least every type of task. I found my successor too. And when I was promoted half a year later, my leaving was totally smooth.

    There’s another lesson I still learn. I work with project managers these days and I’m often tempted to say: do this and that. Act like this. Send the darn e-mail to the darn subcontractor with the darn escalation of the darn issue. To be honest I don’t always restrain the temptation (in other case it wouldn’t be the lesson I still learn). With experienced PMs it’s easier because I know they’ll discuss it with me if they have another idea. It’s harder with those who are still learning the job. I keep reminding myself, like a mantra: “let them decide, let them decide, let them decide, let them…” I know they’ll screw some tasks. However, that way their learning curve will be narrower and they’ll progress to a level when they’ll be tough partners in discussion. Especially when I’ll try to micromanage.

    I think the last thing is the most important one – let people learn. Even when you know they’ll fall, don’t take them through the obstacles on your own back. Let them fall and give them a hand then. Most of people learn on their own mistakes, only some very smart ones learn on others’ mistakes. I prefer to have first two project done with some issues and another ten done well (without my help) than to have first to project done well and another ten facing serious issues, because I can no longer make decisions and PM hasn’t had a chance to learn how to do it himself.

  • Micromanagement

    Today, I’ll write something so obvious that I’m almost ashamed of it. I thought if there’s anybody who doesn’t know that, but I still see lots and lots of people who act like they should read below advices. There’s a second reason also – it’s always worth to remind to myself these points.

    Micromanagement, that’s what I want to write about today. Why is it bad? There’s a bunch of reasons:

    • Manager can’t do everyone’s work. He has in the team 5, 10 or maybe 50 people, so in every case they do more than a single person could. Even if he’s a superhero. Even if there’s only one person in the team. Remember the manager has his own work. Oh, at last he should have some.

    • Manager’s competence doesn’t cover all competence in her team. She usually isn’t the best developer, the best tester, the best project manager. She has the best managerial attributes. Oh, at last she should have some. That’s why she’s the boss. I hope that’s the reason, in other case I offer my condolences to you.

    • Telling people how exactly they should do their tasks is usually stupid because they usually know better. They are closer to issues, closer to code/functionality/project plan/whatever and they work on that every single day (not only during micromanagement day of the week). Manager is like a driver – he can say if the car looks nice and drives fast. His team is like mechanics – they know what exactly happens in the engine. You’d rather ask the mechanic, not the driver how to fix brakes in you car, wouldn’t you?

    • In these several cases when the manager knows better what to do and how to do, telling people how exactly they should do their tasks is stupid, because people don’t learn accountability then. If the manager taught them micromanaging, they won’t take initiative, won’t be creative and won’t look for improvements of their work. Why should they? That’s the manager who tells them exactly how to work. But remember, she doesn’t have the time to micromanage every single person on regular basis. Even if she’s a superhero.

    Yeah, stupid indeed. It’s obvious. Why to write about that? I’ll answer with a question: why so there’s still so much micromanaging?

    I think reasons are different. When I recall micromanagers I met they’re driven by different demons. There’re two I Know It Better demons – first when the manager really know better how to deal with a task or an issue and second when he thinks he knows. The latter is much more common. There’s Do What I Say demon, when it doesn’t really matters if the solution is right or wrong, it’s all about doing what the manager said just to support his ego. There’s You Don’t Know The Big Picture demon, when micromanaging is justified with lack of wide knowledge about whole situation within the team. Nothing easier but to share the knowledge. There’re of course others, but those are the most common.

    You should listen none of them. There’s always a better way to deal with the task or the issue than micromanaging. You can come with your idea in every situation but don’t treat yourself as unmistakable, because you’re not (I bet). Bring discussion and be open to change your mind if someone, especially someone who’ll actually do the work, comes with another idea. And tell people what to do, not how to do that.