I am the team lead of a couple of software engineering teams and I occasionally get the question “I see you often in meetings, talking all day long, but what do you actually do?”.

Whether you have the same question, or you are a software engineer considering a new challenge as a team lead and you would like to know more about the role, I tried in this post to enumerate as many facets of the role as I could think of, without going into too much detail in each of them.

#1 The team lead

Shouldn’t come as a surprise that one of the facets of a team lead is to lead the team.

My goal as the leader of a team is to make sure the team is moving forward and aligned with the strategy and goals of the organisation, can solve its own problems, can deliver value autonomously, is happy and motivated. Ultimately, I want the team to grow to a point where I become redundant to the team.

#2 The coach

Teams are composed by people. In order for people to develop themselves and perform better they need coaching. This means providing feedback about what goes well, what can be improved and how it can be improved. I mostly use recurrent 1 on 1’s and team sessions for this purpose.

#3 The architect

In the domain I work at, teams are very technical. I have a technical background but given the wide range of tasks I have to perform, I don’t have time to develop software myself. But I do get involved in high level technical decisions the team makes to validate that all angles were taken into account and the solution makes sense for the problem, the product and the department. I don’t say how it needs to be done, but I check if the team took the trade offs of the options into consideration.

#4 The HR manager

Most companies have HR processes like performance appraisals, development and improvement plans, salary discussions, hiring and firing people, etc, that have to be followed. It is my responsibility to do this with “my” people.

#5 The psychologist

I find it fundamental to build a trust relationship with people to be able to lead them. When trust is in place, people open up about their problems. Sometimes they are work related, sometimes they are not. People have relationship issues, children that don’t let them sleep, insecurities, etc etc and, as they open up about their problems, you can do one of two things: close the door for it, or listen. Listening and giving advice costs energy, but from my experience it takes the trust relationship to a higher level. It makes the interaction more rewarding and, as a leader, the more information I have at my disposal, the better decisions I can make.

#6 The recruiter

As a team lead you want to have the best team you can get and taking part in the recruitment process is a great way to contribute to hiring good people.

In my case, I’m also a hiring manager for several roles, therefore my involvement in the recruitment process is larger than just doing interviews. I assess CV’s, interview and source people, check if everyone if flowing well through the process and having a good experience, help others become better interviewers.

#7 The project manager

I work in an agile environment but let’s face it, there is work to be done that for one reason or another needs to be treated as a traditional project with fixed deadline. It’s just a reality we have to deal with. Sometimes the team lead has to get involved to do some project management: where are we in the project, what’s unclear, what are the dependencies, when do we foresee to have it done, manage expectations.

It’s not what I like to do the most, as I prefer to work in a more agile manner, but it occasionally needs to be done to make sure the team keeps moving forward and delivers value.

#8 The organizational developer

In an organization that is healthy, continuous improvement is key. There are always things to improve around the department/organization, and it’s part of our role to contribute to that too. And by contributing I don’t mean pointing out what is wrong, but to take ownership and solve problems outside of the scope of the teams.

Let me give some examples of this:

Define growth paths of engineers

Run surveys to assess how people perceive the department

Organize cross-team knowledge sharing sessions

Organize external facing events like Meetups

Formalize/standardize processes

And many more…..