Management - Where the buck stops

I have always entertained very informal relationships with my collaborators and allowed them to decide in as many situations as possible. This was only possible because, beside being friendly and open, I systematically made clear that I had the overall responsibility and that, therefore, could overturn any decision made by a team member.

It is very easy for people to confuse a team led by a friendly boss with a democratic group of equals. This is never the case and you must make it very clear. A company is at best a constitutional monarchy, rather than a democracy.

The only way for the system I am advocating to work is to draw clear lines and delimit responsibilities. In doubt, a collaborator is forced to ask her boss for confirmation, and that is equivalent to passing up the responsibility for a decision.

There will always be misunderstandings, and even people in bad faith that abuse their bosses’ tolerance. Nevertheless, it is extremely important to set clear limits to what everybody can decide upon.

For example, in a software development group, it is essential for each engineer to know the scope of her work. It is also essential for her to be able to work within those limits without external interference.

That's why engineers who accept promotions to management positions only because of prestige or money usually become bad leaders: they cannot leave the fingers off the tasks that no longer belong to them.

An example: an engineer has been wrestling with a complex algorithm for a couple of days. Clearly, she needs more support than she is getting. The manager could sit together with her and inject some order into her thoughts, perhaps suggest some steps to implement intermediate algorithms before tackling the final one. What she does instead, she sits down, codes 80% of the algorithm, and passes it on to the engineer to figure out the last details.

Does it sound familiar? How does that make the engineer feel? What does it do to her self-esteem?

The next time, that engineer is likely to give up much more easily and turn directly to the boss. Incidentally, this is why so many development project managers are horribly overworked: beside their own jobs, they also have to do the jobs of their collaborators.

True, sometimes there are no alternatives for a manager to stepping in and taking charge of a blocked situation, but such an action should only represent a last resort, when everything else has failed.

Like in everything else, there is no simple rule for finding the right balance between controlling and letting go. Inexperienced team members must be supervised more closely, and new hires must be taken by hand for a while, regardless of how much experience they have.

Perhaps the single most important thing that a manager can do is to be aware of these issues, express them clearly to her collaborators, and admit her mistakes openly.