Five Hats - The Leader

A few months ago, I suggested there were "five hats" that a Software Development Manager wore in their day to day job. These hats are -

1. The Leader
2. The Manager
3. The Troubleshooter
4. The Ambassador
5. The Coach

It's finally time to look at these in more detail, and so today I want to talk about Hat #1 - The Leader. There has been so much written about leadership that you might wonder if I have anything new to add. The straight answer is "no" - however, I'll be looking to apply some ideas that are already out there to our context.

One of the worlds great authorities on Leadership is John Kotter from Harvard. He states that leaders "...don't make plans; they don't solve problems; they don't even organize people. What leaders really do is prepare organizations for change and help them cope as they struggle through it." (HBR, 1990) When you have your Leader hat on you are changing things - your team first, and later on the whole organisation.

Leadership involves creating and managing change - that's the what. Ok, how do we about it? I've read many different ideas on this, but they all boil down to one thing; setting a new direction for the organisation, and then aligning people to that direction.

What sort of "new directions" will you be setting as a Software Development Manager? There a lots of possibilities, ranging from the small to the large. But they will generally fall in the area of new projects, new technologies and new methodologies. Here are some examples -

1. This year, we will release our first mobile application
2. By years end, we will be writing all new software in NewTech(TM)
3. Starting next project, we will review all code before release

You'll notice that most of these had dates attached to them, which seems appropriate to me for direction setting at the departmental level. But that can be disputed.

So you've chosen your new direction - how do you go about aligning people to it? This is really where the "art" comes in, as there is no formula. It seems to me there are two essential elements, though - trust and communication. If you have built up trust with your team over time, they are far more likely to buy into your new direction. Building trust takes time and effort. In my experience, you earn it by being scrupulously honest and fair over a long period of time.

Communication is the other element. You need to be talking about your new direction with your department, both individually and as a group. You need to help them understand why you think this is important. You need to understand their own priorities and needs as well, so you can find common ground with your direction. When you are talking about new projects, technologies and methodologies, there is an obvious advantage to the developer, as such things tend to increase their market value. I'm never embarrassed to point that out.

Much more could be said on this topic, and I doubtless will do so later. In the mean time, there are plenty of books an articles on this topic - you won't lack for reading.