Notes for a novice team lead

I have over five years of experience working as a team lead and lead of leads across various team sizes and levels. In this period, I’ve assumed leadership roles in three different companies, including my most recent role at a global company collaborating with teammates from over 60 countries. Each of these roles marked a distinct phase in my professional development:

1. Initially, I was under the impression that a team lead’s primary role was to be the most skilled developer;
2. Then I realized that in medium (3–10 members) and large teams, the essential role of a team lead evolves into that of an organizer and a leader, rather than just a technical expert;
3. Finally, I focused on reinforcing and disseminating the lessons learned from this realization, particularly highlighting the importance of leadership and organizational skills in larger teams.

I would like to explore the third point more thoroughly. Following a reorganization of the company’s technical direction, several new teams were formed. We identified developers who not only excel as technical specialists but also exhibit the skills and willingness to assume responsibility for a team and to advance within the company, and we proposed them for team leadership roles.

Given that some of the developers had little to no prior experience in leadership roles, I made the decision to arrange a series of workshops tailored for novice team leads. The response from the team was positive, which prompted me to extend this knowledge-sharing initiative to the broader community for the following purposes:

1. To facilitate the exchange of experiences and receive valuable feedback from seasoned colleagues.
2. To impart my own experiences to the beginners, aiding them in evaluating whether a management career path is a suitable for them.

In the first post, I will start with the basics — sharing how I establish communication with each individual team member. If the post receives a good response, I will try to cover other topics — I have planned over 10 workshops for the internal audience on topics such as building processes and planning within feature teams, interacting with business stakeholders from non-development teams within the business, conducting interviews for soft and hard skills, building grades as a foundation for personal growth plans and performance reviews, preventing stress and burnout, and more.

Fundamentals of team lead work: team management

“A Team Lead is a person who describes and assigns tasks” — this is one of the most popular associations with the role of a team lead for those who have not worked in this position themselves. Task assignment is indeed a significant part of the work in a leadership position, so I will start my narrative from it.

How to describe and delegate tasks

How to describe a task with SMART methodology

For formulating large tasks (requiring a week of independent work), I use the SMART methodology. According to this methodology, a task must be:

• Specific
• Measurable
• Achievable
• Realistic and relevant
• Time-bound

I think this methodology is well-known enough, so I won’t dwell on the theory in detail. However, in reality, new leads often struggle when they start handling real tasks. I will share an example from my own experience to illustrate how to use methodology in practice.

Task description example — situation

We have several feature-driven cross-functional teams working on a product — a mobile app. This app is released a set number of times per month according to a schedule based on a predefined process. The release process includes a fairly standard set of actions for such cases:

• Branching for release,
• Creating releases in Jira,
• Ensuring that all tasks included in the release are in the correct statuses,
• Creating test runs for regression,
• and so on.

The project has CI (Continuous Integration) capable of assembling a new build triggered by a push to a branch, but there are no further automations. The release manager spends 1–2 hours on all these manual actions for each release, which amounts to 2 hours 2 mobile platforms number of releases per month — a significant amount of time. The goal is to automate this process as much as possible and save the expensive time of the release manager. And this task needs to be assigned to a developer from the mobile platform team.

Task description example — how to formulate

We have a problem: developers responsible for the release are spending 1–2 hours per release on monotonous tasks that can be automated (relevance).

We need to create an integration with Slack, which, upon a given command, initiates the release process and performs the following steps — {description of steps}. After each step, as well as upon the readiness of the new build, the automation writes a message in the release thread (specificity).

This way, we can make life easier for release managers and plan an hour more of interesting tasks instead of monotonous ones in the sprint for them (measurability).

The automation can be implemented using the APIs of Slack, Jira, and CI — in the written task assignment, I detailed which APIs I believe should be used, but if you have more optimal suggestions, let’s discuss them. The automation will work within the infrastructure of our company, which we have already discussed with the DevOps team (achievability).

Decompose the epic into subtasks by tomorrow and make an estimate; we’ll discuss how long the task will take (time-bound — in this example, it’s only for the first step, but after discussing the estimate, it will be set for the entire task).

How detailed should the task be formulated

In the example from the previous point, the task is described in enough detail, even though it is assigned to an expert in mobile development from the platform team. I’d like to explain this aspect as well. Generally, I have an approximate dependency of the detail level of task assignment on the specialist’s experience:

• For a novice: provide a goal, expected measurable result, and step-by-step guidance.
• For an experienced employee: give a goal and expected measurable result.
• For an expert: set a goal and allow them to propose solutions.

Based on this description, one might assume that the task should be framed as a goal, offering autonomy in devising the solution. However, some parts of the task include a step-by-step description for achieving the goal.

The point here is, in my opinion, that the degree of detail in task setting depends on the specialist’s experience in the area in which the task is set. In this case, I am assigning a task to an experienced mobile developer, but at the same time to a person without significant experience in infrastructure tasks and experience in automations of this kind.

How to assign responsibility

Once a task is assigned, it’s necessary to establish responsibility for its resolution. In the case of standard tasks, this usually happens during planning, when the specialists agree with the task estimation given by themselves or the team during the general planning, and then it is assigned to them for the sprint. However, there are situations when a specialist, for one reason or another, does not want to take on a specific task — for example, they doubt their abilities or dislike solving that type of task. For such cases, there are several approaches:

• Requirement — “Do this because you need to do it in accordance with your job responsibilities.”
• Persuasion — “Do this, and the business will benefit in such a way, which will also reflect on your bonus.”
• Entreaty — “Please do this for me — you will really help me out.”
• Order — “Just do this, it’s an order.” Without explanation or justification, etc.

From my experience, novice team leaders should mainly use the first and second forms, because a entreaty is usually a manipulative form that needs to be used skillfully and not too often, even with the ability to do so. Using orders requires sufficient authority, which beginner leaders might lack.

Feedback

After a person has completed a task, it is necessary to provide feedback. In my opinion, there are important aspects to consider in giving feedback:

• Feedback should be in proper time;
• Feedback should be related to a specific task, result, or action;
• Feedback should be based on facts, not emotions;
• Feedback should emphasize the importance of the discussed result for both the individual and the team/company;
• Positive feedback is just as important as negative feedback;
• Positive feedback can be duplicated in a public space — for example, announcing good results at a standup meeting or recognizing the contributions of team members when announcing work results. This not only helps team members feel their significance but also improves the team’s atmosphere and demonstrates what the leader and company consider a significant contribution to the work;
• Be sincere when giving praise. It’s hard to give a general recipe here, but at the same time, this is very important for building personal relationships and the atmosphere in the team. To start, simply smile when giving positive feedback ??

Let’s analyze an example. Imagine a situation where a developer has automated part of the release process of a mobile application from the task-setting example. After the first use of the automation, I invite him for a chat and structure the conversation like this: “Thank you for developing the bot. I think that for you, as someone who regularly performs the role of a release manager, it will be more convenient when a significant part of the routine work is automated. And not just for you — I remember many requests to automate these actions. This innovation is also important for the business because it saves release managers’ hours, which is valuable time compared to other specialists. Also, I’ll note that solving such a complex task meets the requirements for the next grade level, so just 1–2 more examples of such complex tasks — and we can discuss a promotion at the next review.”

Identifying motivation and working with it

There are moments when team members do not want to take on a certain task. The reasons can be quite varied — for instance, a person may fear they can’t handle it, or they believe the task is not within their direct responsibilities and are not prepared to step out of their comfort zone. Yet, the leader is convinced that the task is important and necessary for the team, and that the person can handle it. In such cases, the leader’s job is to convince the person to take on the task. There are different ways to do this. The most straightforward ones are promising a bonus or threatening with dismissal. However, there is a softer and less painful method — determining the person’s motivation and convincing them that solving this task will help achieve what motivates them.

Let’s start with defining the team member’s motivation. There are several different classifications of motivation, among which I prefer the following:

• Recognition: This can include titles like “Employee of the Month,” “Sprint Hero,” etc. Career growth also falls here, if its main goal is to obtain a new formal title, like a senior badge. This also includes the desire to work in a prestigious company.
• Psychological Comfort: A good team, clear company rules, and comfortable communication.
• Convenience: A good office or remote work, a clear and comfortable work process.
• Professional Growth: The opportunity to learn new tools in the professional sphere, for example, technology or team workflow.
• Security: Being confident that salary will arrive on time, not being at risk of job cuts, and company stability.
• Money.

An important note about money: it’s last on my list for a reason. Many beginner managers think that to motivate people, they just need to keep offering them more money. My experience and interactions with more experienced colleagues show that this isn’t always the case. Money is a motivator for most people until they earn less than a certain comfortable minimum. This minimum is different for everyone — some are satisfied just to afford rent and good food, others want a big apartment and to change cars every couple of years. But the common thing is that once this comfortable level is reached, motivation for more than 90% of people is no longer about money.

I can confirm this statement with my own example. When I first heard this from more experienced colleagues, I didn’t believe it. Later, I realized that when we were discussing this, I hadn’t yet reached my comfort level. And some time after that, it turned out that this comfort level isn’t constant — it can change under certain life circumstances.

After realizing this, I try to consider it from a team management perspective. So, how do you determine motivation? The answer is quite simple. You just need to listen to the person, paying special attention to the reasons behind their actions in various situations. A basic example would be discussing with colleagues why they chose to work at the current company.

How to use this knowledge? Primarily, show that completing the task will help achieve the goal that motivates the person. For instance, if a person is motivated by professional growth, you could say that the task is a great opportunity to try a new technology. The company might assist by paying for courses in the new technology or sending them to a conference.

It’s worth noting that understanding motivation helps not only in the described scenario with tasks but also, for example, if a valuable specialist in the company is considering leaving for another company. In such cases, it’s important to compare the current company and competitors primarily in terms of how working in the current company will help achieve the goals that motivate them.

How to discuss these topics

I believe that to establish a trusting relationship with team members, it’s important to regularly communicate with them one-on-one. During such meetings, you can discuss in detail the task setting and current status of tasks, personal growth and development plans, provide feedback and ask for feedback on your work, and sometimes just have casual conversations about life.

I’d like to make a special comment about casual life conversations. At the beginning of my career as a team lead, I underestimated this aspect. It seemed that spending time on personal talks was a waste of time that could be used for more productive tasks, such as coding or testing. However, over time, I realized that such conversations help build trust within the team. They allow for a better understanding of employees’ motivations, receiving feedback that might not be shared in formal performance review forms, and learning a lot of other useful information.

Thanks to these trusting relationships in the team, I was able to retain several members who were considering leaving, and also timely prepare replacements for those who could not be retained because they had set their sights on working for a foreign company.

However, it’s important not to go to the extreme where 1-on-1 communication is just casual conversations about life and most often does not have another goal from the leader’s side. In such cases, the leader should more precisely define the purpose of such meetings for themselves and not forget about these goals when preparing for the meetings.

In my opinion, the frequency of such meetings should be once every 1–2 weeks. Infrequent meetings can lead to a loss of context in communication, especially if team members are not working on common tasks daily.

How to understand that I am not wasting my efforts in building relationships

Reflecting on my experience, I can recall over 10 cases where well-established contact helped me retain someone in the team, quickly find a person for a new company, or know in advance that a person was planning to leave and find a replacement without interrupting work. This statement might seem too optimistic, but I only counted the cases where current or former team members explicitly mentioned it or texted me about looking for a new place and asked if I had anything interesting in mind.

But this is looking back over several years of experience. So, what should a novice team leader do if they haven’t yet accumulated extensive statistics, have little experience, and occasionally suffer from impostor syndrome? I’ve identified the following signs that communication with team members is well-established:

1. The first sign of good communication is that your one-on-one conversations are more like informal communication than regular reporting to a boss. You discuss common topics of interest to all parties, both sides ask questions, argue their viewpoints, and may disagree with each other. It’s important to note that this doesn’t mean team members can comfortably refuse to do a task you assign them and dump it on you. But in my view, even in such a case, persuasion through accumulated authority and informal leadership, rather than the approach of “do this because I’m the boss and I said so,” is a sign of good leadership.
2. The second sign, partly a continuation of the first, is that communication with team members is not built solely around work tasks. If team members share personal problems with you, it’s a sign of trust, which will likely be shown in work as well.
3. The third sign is that the leader gains useful information from one-on-one communication. For example, information that allows identifying motivations or hidden conflicts between team members before they lead to unpleasant consequences like the dismissal of one of the conflict participants.

One-on-One life hacks

During my time in various leadership positions, I have collected several useful life hacks, which now seem obvious to me — as they probably do to many experienced leaders — but didn’t at the beginning. Here is a rough list:

1. One-on-one communication can be more or less formal. More formal is when you meet strictly according to schedule in a meeting room once a week to discuss something. Less formal can be a joint lunch, a coffee break, or even a bar visit after work. A good team lead uses a combination of these approaches.
2. When communicating, it’s important to establish eye contact with the interlocutor. If we’re talking about personal interaction — even the formal version from the previous point — it’s composed of small things, like looking the person in the eyes, rather than sitting opposite them, separated by a laptop.
3. For online interactions — turn on the camera. By the way, in online communication, there’s also a chance to “hide behind the laptop” — for example, if you use an additional monitor and constantly look at it instead of the camera. For such cases, the Mac feature of split screen, or just two windows in other operating systems, is helpful. One window for the interlocutor, another for meeting notes.
4. Don’t plan several meetings in a row without a break or meetings at the end of the day. After most regular 1-on-1s, there are notes to process, and the meetings themselves might drag on or involve heavy discussions, after which you won’t have the energy to attentively listen to the next person and understand their problems.
5. If someone shares a problem with you, not necessarily work-related and doesn’t ask for help — ask about it next time. This helps build a trusting relationship.
6. With many team members and meetings, it’s easy to forget some results, especially personal issues. To prevent this, I keep notes from meetings with each team member, including personal matters they share.
7. Help your teammates to solve work problems you hear about during discussion and highlight the progress of solving these problems, so team members won’t think their problems are just being ignored and will understand that sharing them with you is useful.
8. f teammates bring up problems that you can’t solve alone — escalate them to those who can and share the outcomes with your team members. It’s crucial that they understand you represent their interests when communicating with senior management, not just as a chain link for task transmission.

Conclusion

Thank you for your attention. I would be happy to discuss the topic of this post and hear about your experiences. As I already mentioned at the beginning — if the post generates significant and positive feedback, I plan to write more regularly. So, if you find the topic interesting but have nothing to add, please leave a plus sign — it will indicate to me that the topic is interesting.

P.S. I understand that a good post, especially a lengthy one, is easier to read if it includes illustrations — but I can only draw diagrams of service interactions and organizational structures, as I unfortunately do not possess artistic talent. Therefore, if anyone is willing to help with illustrations for this post or the next ones, I would be very grateful :)