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.

Have you ever wondered what were your biggest mistakes in your professional career? Which things you should do another way or at least try to change? It’s usually easy to judge others, especially looking from a perspective of time. Hey, he shouldn’t have left the company then, because now he’d have been promoted at least twice. Easy to say, because it’s about him and you know exactly what happened during those two years after he left. Back then the decision probably didn’t look like a mistake.

With the same schema we can judge our own decisions, however it’s much harder. First, for most of us it’s difficult to accept that we actually made a mistake. Second, it’s even more difficult to be unbiased when you consider yourself and your own actions. Nevertheless it’s worth a try.

There’s one thing more – people usually tend to share with others their successes, not failures, so your own experience is even more precious – you have unlimited access to it. You won’t find a lot of “failure stories,” so I thought I’d share some of mine.

Personal interactions

When I was leading a support team I had a couple of conflicts with developers partially based on personal background. I thought that if I’m so dedicated and if I struggle to do my best everyone should too. It’s not so hard to imagine that it was rather naive point of view (we worked in a corporation then). Instead of letting other managers to resolve the problem with their people I was making my private tiny war. E.g. we did some performance tests to prove that one of developers didn’t make optimizations, just to show he’d ignored the task. Why didn’t I ask him if he had done that and spent much time for useless tests? Bah, don’t ask me now. You should have asked me then. I can recall several similar situations, all of them having source in my personal likes/dislikes and resulting in, let’s say, not optimal business decisions.

Building a team

I was once a department director, building a team and a product from a scratch. By the way it was a great job. I think my biggest mistake then was too slow promotions within the team. For me it’s very hard to promote someone unless I’m completely sure she’s the right person. However I should overcome my resistance instead of waiting too long before official promotion for a couple of the leaders. Not mentioning that I didn’t even thought about potential successors of any of the leaders. Subconsciously I tried to direct my people through the way I passed once: first informal role of leader with real manager controlling whole team and then eventually getting own team and formal managerial role. Unfortunately, I and one of my colleagues changed the job leaving over a dozen of people with no junior and middle management. The promotions were soon carried out, but with people rather unprepared to managerial role and little supervising it wasn’t a vast success. Some time was wasted too.

Communication with sales

As a manager of operations team (development, implementations, quality assurance and project management team) my biggest mistake was poor contact with several sales people. I know there’s always a conflict between sales and development, but I’m far from thinking that the technical side is the one which is infallible. Quite the contrary, I even wrote that in general it’s better to have a business person as a CEO and sometimes having a geek as a leader of a company isn’t a great idea. I know all of that, but still I haven’t managed to be on good terms with few sales. And by now I still don’t see how I could get it done right with those people. I’m not even sure if it was possible. Maybe more time has to pass and I’ll find out the answer then. Maybe our characters are too different and we hadn’t even a chance. Nevertheless, the fact remains, it’s my failure too.

Choosing an idea

I was working with my friend on a piece of software. Whole thing was intended as a micro-ISV idea, but none of us decided to leave everyday job. In this case our biggest mistake was choosing an application we worked on. It’s not about a market for the application – I still believe we had a chance. It’s about our attitude – we had little fun while working on the software we’d chosen and we reached the point where none of us was still motivating himself, not mentioning about motivating a partner. The software died unfinished. We’d chosen the application only because some of work (part of the code) was already done, so we thought it’ll take much less work to finish. Now I think we had about 5% of work completed, so the choice wasn’t a well-thought one.

Depending on situation my mistakes were followed by different consequences – in the first situation results were negligible, in the last example whole initiative ended up as a failure. It’s just a bunch of examples, but I can think about a list of others based on both my experience and my observations. Generally, it’s not shame to err – making a mistake once is an occasion to learn, but making the same mistake twice becomes a stupidity.

Short but very interesting discussion with Piotr followed my post about leading a team of developers. Piotr accurately pointed that a leader should listen to his team and the team should participate (more or less) in decision-making process. At least that’s true in most cases.

Despite the last word belongs to the leader, the team should feel they’re important. They should feel their opinions matter. They should feel the leader wants to listen to them. To be honest, more important is what they feel, not what’s the truth. Even if the leader doesn’t really listen to the team he should try to create impression that he does. That’s better than nothing.

When I was learning the MSF, one of sensible yet surprising principles was that there’s a team of peers and every decision should be made by achieving a consensus. That’s of course utopia, but if by any chance you’re able to proceed with a decision in this way, you should. Even if it’s easier just to force your opinion.

How to make the decision with the team then?

• Ask teammates about their ideas, not suggesting them yours. This can give you fresh look on the problem. You aren’t a smart Alec (oh, if you believe you are and you’re still reading – give up the rest). Someone from the team can have a better idea.
• Encourage them to contribute. In many cases if you don’t directly invite your teammates to participate, they won’t find enough courage or will or whatsoever and they won’t even say a word.
• Discuss all ideas with the team. You’ll sometimes find that people would have changed their mind after discussion. Even on their own ideas. That’s much better than telling him that their concepts are worthless. Even if they are.
• During discussion drill down every idea until you feel you understand it. If something is ambiguous let it be explained. If explanation is ambiguous too – drill deeper. Force them to drill with you (that’s what my boss keep asking me to do and believe me – it does work).
• Think about all possibilities and make the decision. Team of peers is nice idea, but unless the choice obvious or there’s countless amount of time to discuss, someone just has to make find the way out. You won’t guess who it could be…
• Communicate the decision but give reasons for it. If there was another hot option that was turned down motivate it either. People should know what the motivation behind the choice was.

Sounds easy? It is not.

• Usually you don’t have enough time. Not enough for discussion. Not enough for thinking it over. Not enough for managing all risks.
• Sometimes not every factor can be known by whole team. Especially when decision is rather organizational than technical. In this case you can have your team against you. Even if you’re the one who is right.
• Sometimes you don’t have your own opinion and none of provided ideas is convincing enough. Choose one and act like you were convinced, then. Your team needs convinced leader.

If it was easy the leader wouldn’t be needed.

Feel free to add something to both lists (especially to the first one).

One of projects I’m contributing to is a micro-ISV service. Maybe it’s not the perfect example of micro-ISV, because at least several people are engaged. It’s not single-person business, but the basis is the same. Whole idea was in its origin a world-changing service (or close). The main person working on the idea is a guy who loves it and strongly believes that the service will be great success. The rest of team keeps adding new brainstormed ideas to current concept, keeping ourselves on fire.

Just like most of micro-ISVs. Just like most of micro-ISVs which failed. I wrote some time ago that faith and will to contribute in the long run are essentials when trying to build a product or service as the micro-ISV. But that’s not all. Another factor which is probably even more important is consistency.

I’ve seen different “micro-ideas” (like you can call micro-ISV’s ideas for products or services) which had potential at least to earn for themselves. I played my role in those projects as a co-author, as a supporter, as a user. Range of ideas was wide – from a very fresh look on Internet entertainment services to yet another communicator. All of them I can call (more or less) failures. None of them fulfilled author’s expectations in area of revenue, number of customers or users etc. Many weren’t even born to be shown to the world – they died during pregnancy.

When you have your application completed in 90% it’s usually much less than halfway to successful release. And when you’re 90% completed all the fun is the past. You developed the most enjoyable and the most challenging parts of a code. You exploited all your creative ideas during design. Now you have to focus on boring little improvements of website. Now you have to force your creative soul to think how to make your customers happy instead of thinking how to enjoy yourself with the work. Now you have to fix all those unrepeatable tiny little bugs which allow your frustration to grow. Now you have to deal with The Boring Time. And if you allow yourself to become bored – you lose.

90% of completeness is just the beginning of the road. In this case 90% finished often means 100% failed.