In my previous post, I talked about how a good software development manager should be lazy, dumb, incompetent and forgetful. In this post, I'll talk about why a lazy manager is a good thing.
A lazy programmer will become more efficient at coding and will become better at avoiding redundant code. But that doesn't apply to a lazy manager. A lazy manager is one that doesn't want to do anything. A lazy manager's ultimate goal is to spend the day reading the paper with his feet up on the desk. But how can that be achieved' It's easy if you use your developers for more than just coding.
The best friend of a lazy manager is delegation. To ensure that we're all thinking of the word in the same context, here's Wikipedia's blurb on the matter:
Delegation is the handing of a task over to another person, usually a subordinate. It is the assignment of authority and responsibility to another person to carry out specific activities. It allows a subordinate to make decisions, i.e. it is a shift of decision-making authority from one organizational level to a lower one.
In other words, delegation occurs when you let developers make decisions on activities that they are directly involved in. In most cases, that developer is usually a Lead that has earned a certain level of trust within the team.
Effective delegation is the trademark of a lazy manager. To do delegation effectively, make sure that the developer has the necessary skills and experience to do the job. That means that you shouldn't delegate enterprise-level decisions to a junior developer. However, that doesn't necessarily mean that you can't delegate anything to a junior developer. In my experience, juniors respond to delegation better than any other level of developer. To be successful here, you have to ensure that you set the bounds of the assignment to clear away any ambiguity.
Of course, clearing ambiguity starts to send you down the path towards the evil empire of micro-management. It's OK to go down that path a little bit if your developer lacks experience, but going too far down this road will kill the lazy manager. Micro-management will not only increase your stress but will also diminish the growth of your developers.
Think of micro-management and delegation as two ends of a spectrum. A lazy manager wants to spend as much time as possible on the delegation end of the spectrum. But in order to do that, you need a very experienced group of developers. As the experience level of the developers goes down, the manager will be forced to move farther and farther away from delegation. It would make sense to only hire experienced developers if you didn't have to also worry about the higher salaries that experienced developers require.
The reality, of course, is that reaching the goal of being a lazy manager requires a manager to be very un-lazy. Your goal is to spend as much of your day as possible managing and leading your group of developers. Easier said than done. You have to actively break down all of the work that comes across your plate, categorize it according to what level of developer it can be delegated to and then meet with everyone involved to ensure that the delegation is done effectively. Inevitably, you'll find scraps of work that can't be delegated effectively but you'll have to assign them anyways.
Even if you achieve the nirvana of being a lazy manager, you will be faced with feeling unproductive and anxious. As a manager that used to be a developer, I find it difficult to measure my productivity not that I don't write code. It can affect your confidence and can scrape away at the relationships that you have with your developers if the delegation doesn't go according to plan.
But if you continually work at being a lazy manager, it will eventually happen. You will see your team grow in confidence. You will see natural leaders start to emerge from your group. You will be able to identify developers that aren't keeping up. Most important of all, you will enjoy your job.
In the next post, I'll talk about why being a dumb manager is almost as good as being lazy.