Leadership

In Software Engineering

Gregor Noczinski
8 min readNov 19, 2018
slelham@unsplash

What is a good reason to want to lead?

Does this situation sound familiar? A colleague, a friend or a relative says something like: “I want to take the next step in my career. I want to lead a team.”

The first question that comes to our mind is: “Why?”

When we ask this question, we usually get answers like:

  • “I’ve been working as a senior engineer for years. This is the next logical step in my career”
  • “I want to take on more responsibilities”
  • “I want to earn more”
  • “I don’t like my supervisor”
  • “I feel so powerless”
  • “I want a new challenge”

Can you see a pattern here? Let’s try some other rare answers that might highlight the trend further:

  • “People always tell me that I’m a good leader and they are happy with my leadership — they recommend I make it official”
  • “I want to support people who want to achieve their goals”

The difference between the two sets of answers is quite simple. In the first set of answers, the respondent focuses on themselves. In the second set, the respondent puts others ahead of themselves.

Why?

Because leadership is all about the people, not just yourself.

The only genuine reason to want to lead is that you really want to support people and to create an environment to let them grow and succeed.

For people with the first set of answers

  1. “I’ve been working as a senior engineer for years. This is the next logical step in my career.” and “I want a new challenge.”
    — What about growing and collecting more experience as an engineer? Do you really know everything there is to know in your current role? Maybe it’s worth becoming a specialist in the field?
  2. “I want to take on more responsibilities.”
    — Responsibilities are not assigned or granted — responsibilities are taken up.
    If you want more responsibilities you do not need a title for that. Search for a field that nobody is currently responsible for and take it up — that’s it!
  3. “I want to earn more.”
    — Your title is not directly proportionate to the level of pay.
    In football (referred to in some areas as soccer) the players earn much more than the coaches. I too lead several people in my team who earn much more than me. So if you want to earn more money: Just be better at what you do.
  4. “I don’t like my supervisor.”
    — Maybe try and understand the root of the problem, have an open conversation with your supervisor and see if things can change. If that does not work: escalate matters to their supervisor.
  5. “I feel so powerless.”
    — Power doesn’t always come with a new title.
    You have to mediate everyday between people above and below you. The company’s vision is set — you can only consult here. Your teammates are the specialists — which means they have to decide what is good and bad — you can only challenge that.

So what creates the right leader?

The most important thing to note is: There is no one type of leader that fits the bill.

A leader has to enable the team to do their work effectively. But each team is set up differently. Each team has its own tasks, skills, weaknesses and strengths. This means that the leader has to have the right skillset to get the most out of their teams.

When people usually talk about ‘Team Leads’ in software engineering (also referred to as ‘Engineering Managers’ or ‘Delivery Leads’) they often expect this person to be experienced in all programming languages and frameworks the team uses. If we follow this approach we should also expect the same from a ‘Director of Engineering’, ‘VP of Engineering’ or a ‘CTO’.

I had the honour of working with an ‘Engineering Manager’ of a software engineering team who never really developed code. This person was not able to write serious code and was never exposed to the coding bit of the team. But all engineers in this team had developed a sense of deep respect and trust in their Engineering Manager.

You may wonder how this could be?

The answer is simple. It was because the team was really experienced and did not really need a technical mentor. They needed someone who understood their language, was able to translate it to the rest of the company and the other way around. They needed someone who was able to remove roadblocks for his team. This Engineering Manager was a perfect fit for the engineering team in this company.

Side note: This team was deemed one of the most productive in the company.

Sometimes you may be tasked with leading teams that are not too technically experienced, they may have never worked in agile environments, may have some issues with communication, and so on. However, as a leader, we have to learn to deal with all these tricky situations. We have to be able to find a balanced solution for each problem. In best case scenarios we can find a specialist or a mentor for these situations, but often we have to manage these situations ourselves. Be prepared!

Leaders have to find ways to take care of things that are not already taken care of by the team members themselves.

See also: Situational leadership theory

What is the target of a leader?

Have you ever experienced a situation where a leader wants to participate in every meeting? Wants to be involved in every decision? Always has an “idea for the team”? Wants to “challenge” every decision made by the team?

What you are effectively telling your team is, “I don’t trust you, I can do this better.” This may also increase your bus factor, prevent the growth of your team, frustrate them and finally make them want to quit.

Okay, then what’s the target?

Make yourself superfluous!

The ultimate goal of a leader is to be no longer required for everything — whereby nobody needs the support of the leader anymore.

Sure, this sounds easier said than done, most of us may never reach this goal and it does not always make sense. But it is not the job of a leader to do the work of his team members. A leader is not the specialist — the team members usually are.

Leader etiquette

1. Stop frustrating people

Many people search for the perfect way to motivate others. The truth is, nobody really knows how to motivate every single person across different roles, duties, cultures, backgrounds and preferences. And if we try to do that, we’re sure to frustrate people.

Stop frustrating people and you will automatically find them to be more motivated.

2. Be aware that you work in a creative environment…

…not in a scientific one.

People will not always deliver the same quality of output each day.

There are days people work for four hours more than you pay them and then there are other days where the same people work four hours lesser. It vastly varies between tasks and their current state of minds.

Respect that. But also pay attention.

3. Set targets with clear requirements and boundaries

Your team can only be successful in working independently if the targets are clearly set out for them.

Targets require a clear definition of the requirements in order to identify when the target is achieved. A target such as “good code coverage” is pointless. Also “meaningful code coverage” is not really effective unless you are aligned with your team on what it means in detail.

People also need boundaries so they know not to overstep them but also to know where their involvement is not required. Having no boundaries or saying something like “I have to be involved in every decision” is counter-productive. Maybe align with your team on something like “as long it is planned and does not violate our agreed targets and boundaries you can work on your own. Please just notify me about the outcome.”

4. Estimations are (not always) possible

How often do you hear someone say “I cannot estimate that because it is not too clear to me”?

If you often hear something like this, it simply means that the engineers do not take enough time to refine the topic and understand it in depth — OR — the engineers are not experienced enough on the topic. Both very solvable problems.

How often do you hear “it will take 5 days”? But will it take 5 months after that?

  1. We should be aware that we cannot fully account for everything in the moment we make estimations. Things can change and so can the estimations. That’s just the nature of it. Everybody, including yourself, other managers and stakeholders should bear this in mind at all times.
  2. Also good estimations need time to be fully created. Wrong estimations often have enough the same root cause as with answers like “I cannot estimate that because it is not too clear to me.”

5. Delegate

I know this sounds banal but is very important and too often neglected.

You want your team to be independent? Let them do stuff they have never done before. Maybe help them to do it the first few times, then just let them just do it by themselves.

6. Let things happen — appreciate failures

There are moments when your team explains their new approach to you and you see pride and conviction in their eyes. It may make complete sense to challenge them — as a means to understand their approach. You can also (carefully) express your personal feelings with some arguments. But what if they are still convinced of their idea?

Obviously you could be the boss and say: “No! We will do it my way!” — or you can let them run with their idea, as long as the potential impact on the business is not too big and the team might be able to recognize the drawbacks in their approach themselves — let it happen!

Your team will make mistakes. Some will hurt a bit, some will hurt like you just lost your leg, but they’ll grow back.

“The greatest teacher, failure is.”
— Yoda

7. Leading by example

If you want that your team behave in a specific manner, set an example.

If you want your teams to show up on time for meetings, attend meet ups, contribute to open-source projects, write technical blogs or collaborate with other teams, then make sure you do these things too.

8. You are (not) a part of the team

You don’t stand next to the team and you most definitely don’t own it, you are a part of it.

But it is different when you speak about the team:

  • If everything is in the green state, you talk to the team using words like your idea” and talk about the team using words like their idea”.
  • If something is in the red state you talk to the team using words like we can do that” and about the team using words like we did this”.

9. Trust and follow your team

“A wise leader knows when to follow.”
— Star Wars: The Clone Wars (S2E16)

Often enough there are more specialists in your team than you.

10. Admit when you make mistakes in leading your people

…and tell your people that you messed up.

There’s nothing bolder than admitting you were wrong.

11. Be proud of everything that your team achieves

…and let them notice it.

Closing words

Why did I write all this?

Because I had already made so many mistakes by not following the above mentioned points. I sometimes didn’t trust my team, I pretended that I was better than the specialists, I didn’t delegate and so much more.

I’m pretty sure I will make these mistakes again. But it is always important to make amends and learn to follow these points.

Be a good leader.

--

--