Taking a leadership role

1410 words

It's no secret to anyone that I'm ambitious. I've spent a lot of time improving myself, getting experience, and becoming someone that people look to. In every job I've had, I've been looking for ways to grow, help others and do my best.

Key points

When considering whether to aim for a leadership role, not necessarily just in software, there are a few points to consider.

1. Are you doing it for the right reasons?
2. Do you know what increased responsibility entails?
3. Do you put the team before yourself?

In my view, being a leader is something that you want to do because you want to get things done. I don't really think anyone wants someone to just tell you what to do and get on with it or else, that's the typical Victorian factory owner mindset. Having a team leader who is part of the team getting stuff done not only helps the team get stuff done but helps their leaders work out what they can change. If you're just watching from the balcony barking at them how are you going to get the most out of people?

...being a leader is something that you want to do because you want to get things done...

Taking a leading role is not necessarily any easier than the alternative. It often entails doing the things the team don't really want to do and helping solve a teammate's problems with sometimes zero context. I've found that the best way to get a team to believe in you is to enable them to make choices, feel like they can come to you for help, and help them. Play to their strengths but push the boundaries of their capability slightly. Too much and they want to give up, not enough and they get bored.

Keeping a team running smoothly isn't always easy, you have to sometimes do a bit of legwork to find solutions to the meta-problems that the team faces. In a software context that's using automation to make sure code is consistent, pretty and functional; putting new tools together to cut out the stuff that annoys them, and helping them get their job done as well as possible. I call this a meta-problem because it's not really solving the problem the developers are solving in their work.

Managers vs Specialists

The Romans had this romantic idea that a good soldier would be a good farmer. For all the achievements the Romans had, this was not one of them. If someone is good at marching, fighting and building it doesn't mean you're going to be good at ploughing, harvesting and selling your products at the market. Admittedly they might have an advantage over a complete novice farmer in that they were strong, hardy and no stranger to hard work, but it's a completely different skillset. In the same way, leading a team is different to being in one.

One thing that I think most industries would benefit from and that I know software departments can benefit from is having a dual progression path. One for making someone an absolute A-game specialist, and one to make a great strategist and leader.

In the armed forces, you have the generals and commanders who no doubt make or break any operation, but on the ground, you have experts like non-commissioned officers, special forces, and key support personnel. Doing both require leadership skills but also very different skillsets, and without one the other isn't able to do their job as effectively.

I think software can work in the same way, with good leadership and contact between the department and the wider business, strategy and responsibility for making sure the team works well together, is happy and has as few barriers as possible, but with other people who have put in the years who want to be given the hardest problems, the fiddliest tasks and the biggest challenges. Having this as not only an option but an actively encouraged policy can stop people from falling into the two main traps of career progression.

The Peter Principle is the idea that good workers get promoted until they are incompetent, and it acts on the basis that once you reach a job you are no good at you then stay there, not advancing because you're no longer an effective team member. There are 2 main ways to get around it according to Wikipedia. The first is the Cravath System, which mainly promotes internally and fires people who reach their level of incompetence (no surprise it was made by a law firm demanding high performance). The second option is the one suggested by Brian Christian and Tom Griffiths who suggest reassigning low performers to their previous jobs. There is a third way, though.

The second trap, more interesting to non-managers is the fact that once you get to a position where you are knocking it out of the park in your role and get promoted to management, you then can't do what got you the promotion and you end up doing a load of crap that you hate. How many times have I heard people complain that they got a promotion and now can't do what they love and are good at? Literally last Friday I heard someone say this in conversation. I think this is the main driver of the Peter Principle. You shouldn't really blame someone for being incompetent if they were not promoted because they had the skills to do the job they were given. There needs to be another path.

People who are killing it in their job and want to progress in their careers shouldn't have to become managers if they want a pay rise, it's kind of obvious when you think about it but just because someone is an excellent programmer doesn't make them a good manager. It's a waste! Get them doing things they're good at! Get them teaching others how to be like them! They will still be leading but from the tip of the spear. Got a critical problem to solve that your more junior colleagues can't get around? Parachute in the A-team and get it done. Got a deadline you might not meet and you can't afford to push anymore? Bring in the best of the best and they can get it done.

At a certain point, we can fork people off so they're on parallel career paths but still vital to the team and doing the work they love and are good at. It's best for the team and it's best for the team members. I hope all the teams I work in will have this way of thinking.

A good specialist is like gold dust. They have the ability to do things that others just can't. This is often the result of years spent honing their craft. Specialists can just get stuff done at an alarming rate and pass that knowledge on to team members. The thing is, a specialist won't always make a good leader.

A good leader is also gold dust, and while I firmly believe that a leader should be able to do pretty much anything the team can, they need to be able to do other things, like:

• Make the team laugh
• Make people feel at ease and able to share concerns
• Help the team understand why they're doing what they're doing
• Let other teams know what they're up to and what's coming up
• Roll your sleeves up and get digging when you need to

I really believe that a leader should not ask someone to do anything they wouldn't do themselves. The best way to show this is to do it. It's important to stay grounded so you can understand the day-to-day frustrations of the team.

A leader doesn't have to be the boss

A specialist is still a leader, but they're leading from a different position. They can do what others can't and be a teacher and mentor for the fine details and make sure their teammates are doing well. A good example of this is an Agile scrum master.

I have done aspects of both career paths so far, and I think once I've gone the next step up for me I'm going to have to choose which I'd rather be.

Having these qualities helps you be a great leader and someone who's good to work with. That's what I'm aiming for and I think that's something we can all work towards. I'm not sure if I want to be a specialist or management just yet but I know I'll probably be having a lot of fun and getting some awesome stuff done.