As the head of a department, how do you justify your remuneration when what you do is hard to measure?

Question

I am currently in charge of a bunch of guys who are generally self starters and self organizing, so being their manager, most of the time I just have to step out of their way and provide some minor goals for every iteration of delivery of our product.

Since I can't really add anymore to their technical know how or better the processes, the value I provide to them is more towards getting management out of their way and providing more spiritual assistance in terms of morale boosting.

I found it hard though when asked recently by my CEO of what my contribution to the whole team is as it is not really measurable in the traditional way and some of the things that I do daily flies in the face of normal managerial practices. So, how do I justify my remuneration in such a scenario ?

Answer 1

There are a few really hard problems to solve that relate to programmers in the workplace. In my opinion, it's your job as part of management to solve some or all of them. If you are doing so, you could say you are indirectly responsible for the efficiency of the programmers, overall. You may also take account of a few things compared to other companies, such as: low employee turnover, ability for everyone to work reasonable hours (home at 5:30, for example, if they want), clarity of communication across departments, and more.

So, these hard problems are as follows:

1. Programmers need long periods of completely uninterrupted time to think about how to solve problems. You can provide this via office silence policies, offices with doors that shut, work from home (or some quiet place) opportunities, enforced meeting windows (no meetings except between 9 and 11am, for example), and more. Basically anything you can do here is a godsend. So, if you're doing those things, tell management that you're increasing programmer productivity by several hours per day.
2. Programmers generally don't want to fiddle with office politics, but often bear a fragile ego. Make sure that you foster community within the programming department and breed a culture of forgiveness, humility, and teamwork. Doing this saves you uncountable hours of wasted time from duplicate effort or bad practices. Seriously, uncountable.
3. Reduce mental overhead. Don't weigh your programmers down with overbearing project management tools, meetings, communication requirements, reports, or whatever. Document everything they need to do clearly. Document every process they need to follow clearly. Make sure processes are valuable to everyone, and if they aren't valuable, destroy them or replace them. This will save every programmer hours every week of wasted time on pointless communication, freeing them up to communicate effectively as needed. If you're doing some sort of Scrum or Agile, split up into small teams so everyone doesn't have to listen to 50 other people drone on about irrelevant items. It's your job as manager to handle that complexity.
4. Reduce barriers to communication and resources. If a programmer needs to spend some money on some software, it shouldn't require a persuasive paper, a PO, and a 3 month waiting period (yes, I've had to do that). Find a way to make it work. Tight feedback loops and reduced barriers will make your team fly, and it shouldn't be up to programmers to make that happen.
5. Encourage autonomous and independent work. Give people their own little piece of the world to be responsible for, and they won't quit even when times get hard or they're not being paid enough. Tell management that you are reducing turnover this way, and helping to foster a sense of pride in the work.

If you get all these figured out, you probably won't have to justify what you do very often. Your team will be singing your praises.

Answer 2

A competent CEO would not ask this question. The contribution of the leader is the team's performance. What the team does the leader does. If the team succeeds, the leader gets credit; if it fails, the leader gets credit.

Self-organizing is a bit of a misnomer. Team's do not self organize. Throw several people at a task and someone will emerge as the de facto leader.

I am wondering if the CEO has noticed someone else on the team assuming this role and playing it effectively, to the point where the CEO is interfacing with this individual, not you, to understand what's going on. The CEO could interpret this situation that you built the dynamic, grooming someone to take your spot so you can move on and up, or that you were sidelined by this individual. I would hope the former. But this is purely speculation on my part.

Answer 3

There should always be a way to get an impression about the teams performance: the product they deliver. Especially with in iterative process (as you seem to have), it should be possible to see whether there's value dropping out of each iteration or not.

Your CEO should be very happy (and content), if you can tell him that you manage a happy team that produces a lot of business value on a regular basis. That should put an end to every discussion about your methods.

If you cannot identify the value your team creates, I doubt your management and team situation is as good as it sounds. Regardless of the methods, knowing what your team does, how complex the tasks are, and how many of them get done in what time is THE responsibility of a team's manager.