Team Lead Handbook

Hero image for 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 we envision leadership at Nimble. That is why our squads are structured with servant leadership in mind.

First, our squads have a flat structure in which no member is hierarchically above another member. Second, our 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 the development lead in a squad, the Team Lead 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, the Team Lead must serve the assigned Engineering Lead to provide engineering updates and performance reports on the developers during the whole lifecycle of the project. Eventually, the Team Lead 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 we value 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 decided 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 our 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. A developer is assigned to this role based on his/her level on the Developer Track, skill sets, and fit for the project at a given time. In line with our 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 Sprints’ 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 our 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 tackled 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 our 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 to assign 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 set up, 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 our production 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 fulfil the same responsibilities when needed.

Coordinate Development Resources

The Team Lead is responsible for all the development resources planning in the squad. To deliver the sprints on time, they must plan accordingly when either a developer or he/she 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 re-assigned 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, the Team Lead can handle the request by himself/herself, redirect the request to another developer or explain to the client that the request will require to wait for the return of the developer from his/her leaves.

    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 a Team Lead is on 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. The Team Lead has the sole discretion on the decision to fully delegate the responsibilities or to instruct the team to wait for his/her return to perform both actions.
  • During the leave:

    A Team Lead should enjoy the time-off :-) He/she must have handled the hands-over 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 on 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 to the developers.
    • Day #1 → Day #5 (Monday → Friday)
      • Development on user stories, bug fixes and chores.
      • Ensure code review is 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 on user stories, bug fixes and chores.
      • Ensure code review is 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.

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”.