Team Lead Handbook

This handbook aims to guide software developers on their role of Team Lead of a squad by providing detailed insights on:

1. What the role is really about.
2. In what ways it differs from the developer role in the squad.
3. The expectations from the perspective of not only management but also of the squads.

Core Principles

A key part in better understanding the Team Lead role is to have a good grasp of the following underlying core principles.

Servant Leadership

The concept of servant leadership is at the core of how Nimble envisions leadership. That is why the squads are structured with servant leadership in mind.

First, the squads have a flat structure in which no member is hierarchically above another member. Second, the squads are by nature cross-functional, and as a result, leadership is shared between multiple individuals, namely the Team Lead, the Engineering Lead, and the Product Manager. Each of these leaders has an area of focus and a set of responsibilities. Therefore, collaboration is required between all members to deliver a project.

As development leads in a squad, Team Leads must first serve their fellow developers. The latter are encouraged to rely on the Team Lead to resolve blockers on their tasks whether there are engineering or product-related issues. On a second level, Team Leads must serve the assigned Engineering Lead to provide engineering updates and performance reports on the developers during the whole lifecycle of the project. Eventually, Team Leads must serve the external stakeholders by providing technical and engineering support whenever needed.

Technical Decision Arbitration

In addition to servant leadership, group ownership and individual ownership mentality are also core principles that be valued at Nimble in all areas.

Every developer is encouraged to participate and contribute to every part of the product development. Whether it is a suggestion for a UX/UI improvement or the discovery of a security issue, the developer’s inputs are valued on the same level as the Team Lead’s, the Engineering Lead’s, and the Product Manager’s.

At the same time, this does not mean that every decision must be made unanimously by the whole squad. Doing so would lead to paralysis and friction between squad members, especially between the Engineering Lead and Team Lead. A decision-maker is needed on the engineering side to ensure development progresses. In the squads, the Team Lead has the final say and is the decision-maker. Developers must respect and abide by the decisions taken whether it is the selection of a specific technology for a whole project or a specific implementation decision for a feature or bug fix.

Having a decision-maker does not mean having a dictator. Being a good leader requires trust, honesty and context. Therefore, getting the squad’s buy-in is essential. This ensures that if (when 😇 ) things go wrong, the whole squad will be mobilized to turn things around.

Ephemeral Role

No developer is a Team Lead forever and on all projects that they work on. Developers are assigned to this role based on their level on the Developer Track, skill sets, and fit for the project at a given time. In line with the commitment to individual growth, the role of Team Lead is often assigned to less senior developers as an opportunity to learn and demonstrate leadership skills.

The role assignment lasts at most — in most cases — the duration of a single six-month rotation. Upon the end of the rotation, a new developer is entrusted to becoming the squad Team Lead. Following the role re-assignment, the former Team Lead might still remain in the same squad in the role of Developer or rotate to another project either in the role of Team Lead or Developer.

For projects lasting less than a single rotation period, the Team Lead is rarely reassigned to ensure stability and continuity needed for both the squad but, more importantly, for the product development.

Hands-on Role

The Team Lead is expected to perform the same development duties as all developers on the squad. Therefore, it is not a purely team-management-focused job despite the role title.

In essence, Team leads have to combine the same responsibilities as developers with an additional set of responsibilities (detailed below).

In practice, since a Team Lead cannot focus entirely on development tasks, a velocity lower than the other developers on the squad is expected and accepted as normal. Being a Team Lead always results in less time available for executing on development. However, it should be noted though that this is not a rule. A Team Lead can also be the developer having the largest output. It varies depending on the skill sets of the developers on the squad and the type of projects.

Responsibilities

Collaborate on the Product Backlog

While Product Managers own the backlog, a Team Lead must collaborate closely and on a continuous basis with the Product Manager of the squad to execute the backlog grooming efforts.

First, the Team Lead must review the requirements of any new user stories added. This feedback is essential in ensuring the user stories are ready to be picked up by developers during the sprint. If amendments are required, the Team Lead must collaborate with the Product Manager to improve the user stories and/or create new user stories.

Second, following the review, the Team Lead must also do an initial estimation of any new user stories added so that the Product Manager can gauge the efforts required and plan the future sprints based on the squad velocity. All user stories must be estimated prior to starting the future sprints.

Eventually, the Team Lead must bring forward engineering-oriented tasks to the Product Manager so that they can be prioritized in the backlog. In the backlog management processes, this means creating chore epics and writing chore tasks for the project. Tackling technical debt, application architecture changes and automated testing improvements must be addressed continuously to build robust applications. The Team Lead is entrusted to ensure that the codebase quality keeps improving and that the application architecture evolves at the same pace as the product.

The Sprint Planning session, scheduled once per sprint, is the core review process during which both the Product Manager and Team Lead meet and discuss the upcoming sprints. Outside of this session, whenever there is a change or a concern during the sprint, the Team Lead is responsible to collaborate with the Product Manager to alter the development planning if needed and provide information.

The Engineering Lead is not responsible for the day-to-day development planning — the Team Lead is. However, in case of changes and concerns, the Team Lead can collaborate with the Engineering Lead to discuss and decide on technical implementation options and alternatives.

Lead the Development Sprint

Once a planned sprint starts, the Team Lead is responsible for delivering the sprint goals while meeting the highest quality standards in all development areas.

Backlog Efficiency

Assigning a task to a developer is the sole responsibility of the Team Lead. Both the Product Managers and the Engineering Lead are hands-off in that regard. The Team Lead is accountable for assigning the tasks strategically to the developers of the squad, balancing the sprint requirements, the skill sets and domain knowledge of each developer, and the need to diversify the type of tasks assigned to each developer to ensure group ownership. The latter means that a developer should never be assigned only the same type of tasks e.g. only frontend or only backend.

As part of efficiently assigning the backlog items, the Team Lead must also decide which tasks make more sense for them to work on to both deliver the sprint goals but also to ensure they will not fall behind their additional responsibilities. By working on the wrong tasks, a Team Lead can effectively become the bottleneck which will delay and/or result in the poor execution of code reviews, code merges, and releases.

During the sprint, the Team Lead is also responsible for the prioritization of the backlog items. The Product Manager usually plans a mix of features, bugs, and chores for a sprint and sets an initial order of all backlog items. However, the Team Lead can change the order of implementing the backlog items if it makes more sense for engineering reasons. The only constraint is that the sprint duration and the list of deliverables defined by the Product Manager must be respected.

Sprint Goals Delivery

Once the backlog items have been assigned, the Team Lead must monitor the progress made by the developers daily. In practice, while developers should proactively communicate both their progress and issues, the Team Lead must also proactively inquire about the status of the work done by developers. Say a developer has not picked up a new task over a few days because he/she is still stuck on the same task, this might derail the ability of the Team Lead to deliver all the sprint commitment.

The Team Lead must also ensure that the points estimation on each backlog item corresponds to the actual effort spent by the developers. Any constant inaccuracy would prevent the use of velocity as a predictive metric by Product Managers. By monitoring the progress daily, a Team Lead can be on top of the actual velocity of the development team and make prompt adjustments.

Code Reviews Management

Every developer on the squad must review all pull requests regardless of the number of approvals required to merge a pull request. Code review is essential in ensuring not only code quality but also that every developer knows every part of the application. The Team Lead must thus ensure that all the developers on the squad are reviewing the pull requests in a consistent and timely manner. Any failure by one of the developers could delay the sprint and imbalance the code review workload for the other developers. In practice, a Team Lead has to continuously rally the developers to prioritize code reviews and focus the whole squad on the pull requests with the highest level of priority.

In line with the technical decision arbitration principle, the Team Lead has the final say on the changes that surface during the code reviews, and that must be executed to merge a pull request. In a squad with three or more developers, there could be cases when different paths for implementations are proposed. It comes down to the Team Lead to finalize and communicate the decision. In practice, the developers are also encouraged to share their implementation details before any code implementation to ensure that it fits the vision and strategy defined by the Team Lead and avoid inefficient large refactoring work.

Once the number of required approvals is reached AND a pull request passes the automated continuous integration (CI) requirements, the Team Lead is the sole individual in the squads who can merge pull requests. No other developers should have merge permissions.

The Team Lead acts as the conductor of the pull request merges. Code merges usually require orchestration and alignment on the sprint priorities to be done efficiently. For instance, merging first a pull request for a backend feature to unlock several frontend-oriented feature tasks could be the right decision even if there are other completed pull requests. Another recurrent requirement is to prioritize the merge of a pull request for a hotfix or a general bug fix to unblock the Product Manager and/or end-users.

Eventually, having a single engineering team member responsible for all code merges enforces the role of code quality gatekeeper. The Team Lead must ensure not only that the team conventions are followed but also that the codebase quality meets the highest standards while still fulfilling the product requirements and sprint timeline. By merging a pull request, a Team Lead effectively vouches for the newly added code.

On large projects (more than 4 developers on the same platform), the number of pull requests daily can be very large. Thus, it can be inefficient for all developers to review all pull requests all the time if it impacts their velocity negatively. In this case, developers are encouraged to review as many pull requests as possible while the Team Lead and Engineering Leads must be the ones reviewing all pull requests.

Release Management

As a by-product of leading the code review and code merge processes, the Team Lead is in charge of carrying all releases on all environments. Therefore, the Team Lead must fully understand the details of the release process; this includes the deployment/distribution setup, what could potentially go wrong, and how to fix those issues.

At the start of a project, the Team Lead must ensure that deployment/distribution to both staging and production environments are implemented in the first sprint to adhere to the Release Processes.

In the case of breakages, the Team Lead is also the first respondent to debug and resolve release-related issues.

Once a release has been processed, the Team Lead is responsible for conducting all official communication with stakeholders concerning the release in a timely and clear fashion, such as sending a message on Slack to notify stakeholders.

In the case of unforeseen problems delaying a release, the Team Lead must communicate and collaborate closely with the Product Manager in a proactive manner about any changes and opportunities to resolve the situation. The Team Lead is the backbone of the release process, not the Product Manager.

The release process must be fully automated to minimize human interactions and documented so that other developers can fulfill the same responsibilities when needed.

Coordinate Development Resources

The Team Lead is responsible for the planning of all the development resources in their squad. To deliver the sprints on time, the Team Lead must plan accordingly when either a developer or themselves is on sick or personal leave as it affects the overall velocity of the team.

In the case of a developer taking a personal leave:

• Before the leave:

  The Team Lead must coordinate with the developer to ensure anything left undone is reassigned adequately to ensure completion.

• During the leave:

  The Team Lead must ensure that the requests raised to the developer — who is currently on leave — by the technical counterparts on the client-side (e.g. anyone with whom he/she collaborates directly daily) are handled gracefully. In practice, Team Leads can handle the request by themselves, redirect the request to another developer or explain to the client that the request will require to wait for the return of the developer.

  A good practice is for the developer to set up an Out-Of-Office auto-reply email and turn it on during the leave period. The Team Lead should ensure that the developer is following this good practice.

In the case of a Team Lead taking a personal leave:

• Before the leave:

  The Team Lead must first inform the Product Manager and the developers on the squad with as much notice as possible. A good practice is to provide at least 2 to 4 weeks of notice as this translates to 1 to 2 sprints of development. The Team Lead should also inform proactively the technical counterparts on the client-side (e.g. anyone with whom he/she collaborates directly on a daily basis). A good practice is to inform the client-side at least 1 week in advance.

  Beyond informing about the leave, a Team Lead must plan and communicate the delegation plan i.e. which developer will be in charge during the time of the leave. Depending on the duration of the time-off, the delegation scope varies:

  • Short leaves (< 3-5 days): the delegation can be limited to handling all communication with external stakeholders.
  • Longer leaves (> 5 days): the delegation must define the process for code merges and release processes. Team Leads have the sole discretion on the decision to fully delegate the responsibilities or to instruct the team to wait for their return to perform both actions.

• During the leave:

  A Team Lead should enjoy the time-off 🙂 He/she must have handled the handovers properly to avoid being disturbed when on leave.

  Just like developers, a Team Lead should set up an Out-Of-Office auto-reply email and turn it on during the leave period.

In the case of unplanned leaves, such as sick leaves, the Team Lead must imperatively and promptly:

• Assess if the reduced work output will affect negatively the ability of the squad to deliver the sprint goals and communicate accordingly to the Product Manager.
• Assess and execute the re-assignment of the pending tasks if necessary.

Any delay in handling unplanned leaves can derail the sprint planning.

A Typical Sprint

With a seemingly long list of responsibilities, it might seem hard to visualize what a Team Lead must do on a daily basis. Since the responsibilities of a Team Lead are attached to the development sprint, here is what it would typically look like for a single two-week sprint:

• Week 1
  • Day #1:
    • Attend the sprint planning meeting held by the Product Manager along with the developers.
    • Strategically assign the user stories to themselves and the developers.
  • Day #1 → Day #5 (Monday → Friday)
    • Development of user stories, bug fixes, and chores.
    • Ensure code reviews are prioritized and done consistently by all developers.
    • Orchestrate the code merges to ensure the Product Manager can perform QA on the staging environment continuously.
    • Regularly update the Product Manager on the progress and bottlenecks.
• Week #2:
  • Day #6 → Day #10 (Monday → Friday)
    • Review the backlog items created by the Product Manager for the next sprint and provide feedback to ensure the user stories are ready to be picked up by the developers.
    • Estimate all user stories for the next sprint.
    • Development of user stories, bug fixes, and chores.
    • Ensure code reviews are prioritized and done consistently by all developers.
    • Orchestrate the code merges to ensure the Product Manager can perform QA on the staging environment continuously.
    • Regularly update the Product Manager on the progress and bottlenecks.
  • Day #10
    • Ensure the developers on the squad familiarize themselves with the user stories planned for the next sprint to best prepare for the sprint planning session.
    • Create the release branch containing all the work accomplished during the sprint.
    • Prepare the release to the production environment along with the release notes to tag the main branch. If the last day of the sprints falls on a Friday, which is usually the case, the release is performed on the next working day.

Performance

Metrics

When officiating in a role, beyond knowing the responsibilities, one must also know the key metrics to assess how well they fulfill their duties.

Consistent Delivery of Sprint Goals

The primary mission of a Team Lead is to deliver all planned stories in every sprint. As a result, their performance is measured by how consistent and efficient they are in delivering the sprint goals. They must work closely with the Product Manager throughout the sprint and ensure the squad consistently maintains a high velocity in each sprint, i.e., the number of story points delivered.

Good performance in that aspect means:

• The higher the velocity, the better. Indeed, the more story points are delivered in each sprint, the more business value is delivered to end-users.
• The fewer carried-over backlog items from one sprint to the other, the better. Indeed, since The Team Lead leads the sprint, they must ensure all planned stories are delivered. They must make the right prioritization choices (i.e., making sure the order of stories makes sense) and keep track of the development status of each backlog item.
• The sooner delivery issues are surfaced to the Product Manager, the better. Indeed, a Team Lead must provide regular updates on the development progress to the Product Manager to ensure they are the required data to make backlog adjustments if necessary.

Stable and Flexible Applications

A Team Lead is the arbitrator of technical decisions and the code quality gatekeeper. As a result, they are accountable for the quality of the outcome of the development process: the application(s). They must ensure that the application functions as expected in production under every condition while, at the same time, making it easy to iterate on functional requirements.

Good performance in that aspect means:

• The fewer bugs and regressions, the better. Indeed, a Team Lead must thoroughly check for potential issues before any code is merged. In addition, they must constantly QA the application they are responsible for to ensure problems are discovered before end-users.
• The more straightforward new requirements can be implemented, the better. Indeed, as a tenet of Agile development processes, a squad must welcome changing needs. The codebase must be easy to evolve to maximize the benefits for its owners.
• The faster bugs and incidents can be resolved, the better. Indeed, a Team Lead must maintain a low MTTR (mean time to restore: the average time it takes to recover from a system failure) on the project they lead. Incidents are unavoidable, but the key difference is how fast a squad can identify and fix the underlying issues.

Productive Squad Environment

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. – The Agile Manifesto

A Team Lead directly impacts each developer’s daily work since they assign them stories and orchestrate code review efforts. Like a sports team coach, they must know each squad member’s strengths, weaknesses, and aspirations (e.g., a developer might want to work on specific tasks) and provide guidance and encouragement to ensure they deliver their best work. They must create an environment where everyone feels valued and motivated (i.e., no one should fall behind).

Good performance in that aspect means:

• The more active communication and collaboration efforts, the better. Indeed, in a well-performing squad, each member actively participates in all team discussions and collaborates with others to achieve the sprint goals as a group.
• The more the squad is aligned with the sprint goals, the better. Indeed, the Team Lead must ensure that each squad member understands the underlying context and reasons for the prioritization of the stories in each sprint. Every squad member needs to have the big picture of the project.

Best Practices

To avoid common pitfalls, the following guidelines must be followed:

• DO work on feature stories.
• Do NOT work only on chores and bug fixes.

👉  While a Team Lead plays a crucial role in removing technical blockers for the developers and spends a significant chunk of their time on code reviews and merges, their throughput also accounts for the team’s velocity. Therefore, a Team Lead must also deliver feature stories to support the delivery of the sprint goals. Strong in their experience and skills, a Team Lead should be equally or more efficient than their fellow developers. In addition, since they have technical arbitration, they not only have the capabilities to deliver well-thought-out code implementation but also often are instrumental in paving the way for the other developers, i.e., they deliver code implementation that the rest of the team can emulate and follow.

• DO plan continuously how to fulfill all your responsibilities efficiently.
• Do NOT become a bottleneck for the squad.

👉  A leadership role comes with added responsibilities. Success in such a role is achieved not only by the effort of one individual but also by the whole team. Therefore, a Team Lead must have strong personal organization skills to know where best to spend their efforts at any given time in a sprint. From the stories they assign to themselves to unlocking the backlog of pull requests to review and merge, they must aim at never being in a position where they are the bottleneck of their squad. A large chunk of a development team’s efficiency rests on their Team Lead’s efficiency.

• DO enforce technical decisions strictly to move the project forward.
• Do NOT involve all developers in every technical decision.

👉  As the technical arbitrator in the squad, a Team Lead must know how to wield their arbitrage power skillfully. A Team Lead must balance well seeking the team’s feedback and consensus and moving the project forward. Not every technical decision is equal. Some technical decisions require the involvement of every developer (e.g., a technical decision that affects the whole codebase), but most can and should be done at the discretion of the Team Lead and the developer in charge of the implementation. The squad’s developers delegate their decision power to the Team Lead. Hence they not only understand but expect that the Team Lead will use this power to make decisions for the benefit of the project.

• DO coordinate the onboarding of newly rotated-in developers.
• Do NOT let newly rotated-in developers figure everything out by themselves.

👉  A Team Lead has a vested interest in ensuring newly rotated-in developers have everything they need to be productive. The sooner these developers understand the project and codebase(s), the faster they can contribute meaningfully to the squad. The Team Lead usually takes charge of the onboarding but can also delegate it to another squad member, such as a developer or the Engineering Lead, depending on the project’s needs.

• DO stay on top of application errors/crashes.
• Do NOT leave errors unattended and uninvestigated.

👉  A Team Lead’s performance is partially based on the stability of the application they lead. Therefore, they must be the first to respond in case of fatal errors, such as server or application crashes. They should also regularly review non-fatal errors, even irregular ones, to ensure proper investigation and resolution. The Team Lead must prioritize production errors based on their severity and occurrences, and ensure they are resolved to minimize negative impacts on users.

Best practices for story estimations

Closing Words

A Team Lead leads the development efforts to ensure the delivery of the vision defined by the Product Manager for every sprint. A Product Manager defines the “What” for a sprint, while a Team Lead is in charge of the “How”.