Engineering Lead Handbook

Hero image for Engineering Lead Handbook

Welcome to the People path of the Developer Track đź‘‹

This handbook aims to guide software developers on the engineering leadership path by providing detailed insights on:

  1. What the role is really about.
  2. In what ways it differs from an individual contributor on the Technical path.
  3. The expectations from management and from the squads that the Engineering Lead oversees.

Core Principles

A key part in better understanding the Engineering Leadership’s role is to have a good grasp of the following core principles.

Servant Leadership

It is not a coincidence that the role is named Engineering Lead and not Engineering Manager. The title “Manager” puts the focus on having a specific role in a company, whereas “Lead” puts the focus on the actual leadership skill. Leadership means being able to guide and influence others, not bossing people around.

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.

Squad with engineering leads in non-team roles

Even though the role is named Engineering Lead and not Engineering Manager, there are still management duties involved. Management refers to a type of task - just like there are also development-related or recruitment-related tasks - which an Engineering Lead must fulfill.

Hands-on Role

“Each week that passes where you don’t share the joy, despair, and discovery of software development is a week when you slowly forget what it means to be a software developer. Over time it means you’ll have a harder time talking to engineers because you’ll forget how they think (…)” (source)

The Engineering Lead remains a 100% software engineering role with some management responsibilities. In practice, it means that while the role comes with reduced development activities, it’s still an active “coding” role.

While many managers stop coding, we firmly believe that an Engineering Lead must keep their coding hat on for the following reasons:

  • To assess technical bottlenecks and process problems, Engineering Leads must keep their technical skills up-to-date by writing code themselves.
  • To advise the squads on the shortest and most efficient path through the systems to implement features, Engineering Leads must understand all the software pieces. The better they know code, the more efficient implementation paths they can suggest.
  • To lead with influence instead of authority, Engineering Leads need to be recognized for their technical expertise.

Management & Mentoring

An Engineering Lead is assigned 6-9 developers as reports. It means that these developers report to the Engineering Lead for their individual performance and growth path.

Engineering Leads and their direct reports are not required to have the same area of expertise. An Engineering Lead expert in Android development can manage iOS or Web developers.

Even though software developers work in different areas, the same management and mentoring apply to all software developers. Software developers usually face the same challenges thus the same guidance is applicable. Engineering must think of themselves as leaders of software teams, regardless of the technology used.

Responsibilities

Engineering Leads have to combine the responsibilities of a Developer (omitted below for brevity), a Team Lead (if they are leading a squad), and finally the following additional responsibilities (tagged with → a type to differentiate the specific area of responsibilities):

  • Software delivery accountability → execution
  • Provide insights and reports to the CTO → management
  • Nurture and assess software developers → management
  • Participate in the recruitment process → execution
  • Facilitate and ensure that developers follow the company engineering processes → management

Software Delivery Accountability

An Engineering Lead (EL) is assigned to project squads ranging from one (minimum) to three (maximum) in their area of expertise (Android, iOS, or Web). For example, an EL with Web expertise would be assigned to and vouch for the deliveries of one to three Web applications. On the other hand, an EL with iOS or Android expertise would take care of one to three mobile applications.

Code Reviews and Development

The minimum set of development responsibilities is to do code reviews and attend to technical discussion on all assigned projects. The former helps to reinforce the quality of the codebase, while the latter helps to ensure that the Engineering Lead has enough domain knowledge to participate meaningfully in a project without requiring to be in active development.

Besides, an Engineering Lead can fully participate in the development process of one project when assigned as they work side-by-side in the squad, i.e., work on development tasks and actually commit code. Furthermore, an Engineering Lead can decide their priority and type of tasks within the squad (this relates to self-management).

While code review responsibilities must be fulfilled on all the assigned projects (two to three at most), the actual development must be limited to a single project. Doing development on all projects would entail an immense workload and context switches incompatible with the rest of the responsibilities.

Collaboration with Product Managers

In addition, Engineering Leads (ELs) must assist the Product Managers (PMs) in most of the technical meetings with the stakeholders. The presence of Team Leads in such meetings is optional.
While the PMs take the lead in the meeting, the ELs can provide insightful technical details when needed.
At the end of meetings, the minutes would contain both business requirements from the PM, and the technical implementation details from the Engineering Lead that enables the engineering team to understand the features thoroughly. This forms a strong link between the Engineering team and the Product team, where both can participate in shaping the project efficiently.

At Nimble, Product Managers are all technical. They are well-versed in software development (although not at an engineer’s level). They can take part in technical discussions and break down technical requirements for the Engineers. However, Engineering Leads must provide support when a technical challenge is beyond the Product Manager’s capabilities. For example, when it comes to detailed implementation plans or software architecture decisions.

Collaboration with Team Leads

Accountability means the Engineering Lead is held accountable for the technical implementation and delivery of all the assigned projects at the required quality. The Engineering Lead is thus the point of contact for the management (CTO and CPO) regarding the assigned projects.

Accountability does not mean decision-making. When it comes to having the final say, the Team Lead of the squad remains the decision-maker.

When the Team Leads are Senior/Principal Developers, they often have the technical abilities to make good decisions for the projects independently. In the advent of a Team Lead who is new to the position, the EL must spend more time on coaching and ensure such decisions can be made gracefully.

Eventually, the Engineering Leads must use their technical expertise and management skills to get the team to go in the right direction. They have to use their influence, debate, and persuasion skills instead of forced authority to impose a decision.

While it might seem counter-intuitive to have someone accountable but not calling the shots, the reality is that forcing technical decisions will create conflicts in the engineering team. Our squads must continue to work collaboratively and have group ownership. Thus, an Engineering Lead must work in collaboration with the Team Lead and the squad as a whole to achieve the best possible outcome.

Rapport Building with the Client Engineering Leadership

While the Product Manager is purposefully the main point of contact between the squads and the client stakeholder(s), Engineering Leads are encouraged to punctually engage in conversations and solicit feedback from the engineering leadership on the client-side. The latter usually consists of either Chief Technical Officer (CTO), an Engineering Lead/Manager, or a Team Lead overseeing the project. Thanks to their skills, Engineering Leads are best placed on building such rapport so that the Product Manager can focus on the product and the Team Lead can focus on the delivery of the sprint’s goals.

The purpose is two-fold:

  • Building a relationship with the client team that goes beyond executing the current work. Nimble aims to partner successfully with its clients so that they succeed in the long term. Therefore, as the project progresses, different and future needs can emerge that Nimble can support the client with.
  • Getting insights on how the squads are performing in delivering what the client needs from their viewpoint. While Git analytics provides robust and proven insights, the latter do not replace human-centered feedback. Engineering Leads should strive at sourcing all the feedback they can to ensure the project’s success.

No specific rituals or schedule is enforced as each project and client differ. However, as a rule of thumb, having check-ins 1) on Slack or by email work best and 2) every 2-3 sprints provide enough time for the engineering client stakeholder(s) to reflect on while not generating a burden to them. At no point should this effort feel forced or impractical.

Best practices

In order to avoid some pitfalls, the following guidelines must be followed:

  • DO collaborate and pave the way for the team to move forward.

  • Do NOT coerce the squads to follow a specific direction.

👉 As a servant leader, an Engineering Lead must use influence and guide, not order and force. Respect the decision-making process occurring in the squad.

  • DO support the Team Lead to make the best decisions for the project.

  • Do NOT make technical decisions in place of the Team Lead.

👉 When software developers are placed in a Team Lead role, it is because they have been assessed and deemed ready to take on the role and/or they need to grow their leadership skills as part of their individual growth.

An Engineering Lead must guide and coach Team Leads so they understand the bigger picture of a project, learn how to balance the business and technical perspectives, and know how to make a decision.

  • DO take the responsibility and stay on top when incidents happen.

  • Do NOT blame the Team Lead and/or the whole squad when issues arise.

👉 An Engineering Lead is accountable therefore is ultimately responsible for the outcome.

By doing code reviews and being involved in the development process, the Engineering Lead must be on top of all events happening in a project. Therefore, forecasting issues and being proactive in solving the problem is the Engineering Lead’s responsibility.

Insights and Reports to the CTO

A constant line of communication must be maintained between the CTO and Engineering Leads with the following rituals:

  • Bi-weekly Retrospective

    Limited to 30 minutes, the purpose is to have bi-weekly retrospectives of successes and blockers across all projects and for all reports.

    For projects, the bi-weekly schedule is necessary as not all projects start at the same time or have the same sprint duration. As reports’ one-on-ones can occur at different schedules, having a bi-weekly schedule also allows reducing the time to report issues to the CTO.

  • Bi-monthly Planning Session

    In order to guarantee coordination between all engineering areas, this meeting is used to review and define initiatives for the next period of 8 weeks.

These sessions come in addition to the monthly one-on-one dedicated to the individual growth of the Engineering Lead.

Nurture and Assess Developers

An Engineering Lead is expected to:

  • Instigate curiosity and continuous learning in the area they are experts in.

    As an expert in an area, the Engineering Lead supports Chapter Leads in sharing technical information among team members either during retrospectives or workshops, updates the required technical skills for learning tracks on Nimble University and drives the technical direction of a Chapter.

  • Perform regular one-on-ones and 360 reviews (performance reviews) with the assigned software developers.

    In terms of schedule, at the minimum, the schedule for one-on-one sessions is set to be done every four weeks for both full-time developers and developers under probation. As for 360 reviews, they are done twice a year after each squad rotation in January and July.

    Whether it is a one-on-one or a 360 review, the Engineering Lead must define the objectives for their assigned developers to ensure they can level up and progress.

    In addition, an Engineering Lead must report performance issues and level up recommendations back to the CTO based on their assessments in their bi-weekly retrospectives.

Participate in the Recruitment Process

As an Engineering Lead, screening, and interviewing applicants to join our team are weekly activities to perform in addition to development activities. Screening includes resume and application form processing but also reviewing the code challenges submitted by applicants.

The activities are coordinated by the Talent Team. The actual workload can vary greatly depending on the number of applicants. But an Engineering Lead is expected to process applicants at the earliest to provide a good applicant experience.

Engineering Process Ambassador

At a macro-level, an Engineering Lead is an ambassador and enforcer of our development processes. As the team grows, Engineering Leadership is meant to ensure our processes are maintained across the board from development to security.

At the crossroads of a SCRUM master, an Engineering Lead also ensures that Agile rituals are held and deliver on their goals.

As a participant in retrospectives, an Engineering Lead can guide Chapter Leads to lead each session. In addition, an Engineering Lead can also make sure that developers provide useful information in daily standup.

A Typical Week

With a seemingly long list of responsibilities, it might look hard to visualize what an Engineering Lead would do on a weekly basis. So here is what it would typically look like for an Engineering Lead who is assigned in 2 projects, involve in active development for one of them, and manage 4 reports:

  • Monday:
    • Participate in the internal Sprint Planning along with the squads for the 2 projects he/she is assigned to.
    • Perform code review in all assigned projects and optionally do (in 0.5 days):
      • Development on secondary tasks, bug fixes or,
      • Work on internal engineering initiative.
  • Tuesday:
    • Screen and interview candidates (maximum 2 interview meetings per day).
    • Perform 2 one-on-ones meetings with the assigned team members (monthly). Prior to the event, the EL must prepare keynotes for the meeting.
    • Perform code review in all assigned projects and optionally do (in 0.25 days):
      • Development on secondary tasks or bug fixes or,
      • Work on internal engineering initiative.
  • Wednesday:
    • Participate in retrospectives in corresponding Chapter (bi-weekly).
    • Perform 2 one-on-ones meetings with the assigned team members (monthly). Prior to the event, the EL must prepare keynotes for the meeting.
    • Perform code review in all assigned projects and optionally do (in 0.5 days):
      • Development on secondary tasks, bug fixes or,
      • Work on internal engineering initiative or,
      • Prepare the reports, status updates for upcoming monthly/bi-weekly meetings.
  • Thursday:
    • Screen and interview candidates (maximum 2 interview meetings per day).
    • Write the report for the CTO and attend the EL Retrospective meeting (bi-weekly).
    • Attend your one-on-one meeting with the CTO (monthly).
    • Participate in Engineering Lead bi-monthly meeting.
    • Perform code review in all assigned projects and optionally do (in 0.25 days):
      • Development on secondary tasks or bug fixes or,
      • Work on internal engineering initiative.
  • Friday:
    • Participate in sprint planning/review with the Client along with the PM.
    • Perform code review in all assigned projects and optionally do (in 0.5 days):
      • Development on secondary tasks or bug fixes or,
      • Work on internal engineering initiative or,
      • Participate in team events like Nimble Growth, Nimble Code War, etc…

It is a simulated scenario so the days might not match identically with the actual days.

In addition, an Engineering Lead could take part in an additional Platform Engineering project to remain hands-on, perform technical writing for Compass and/or the blog.

Closing Words

Engineering Leads are technical leaders who handle the human side of software development by providing coaching and mentoring to:

  • Their reports i.e. assigned software developers.
  • The developers on their assigned projects.

Because of their skills and role in the team, they are the most suited to:

  • Report to the CTO about the performance of software developers and projects.
  • Assess and recruit new team members.