Engineering Lead Handbook

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 (EL) 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, 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.

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 is still an active “coding” role.

While many managers stop coding, the team firmly believes 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 client 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 discussions on all assigned projects. Code review helps to reinforce the quality of the codebase, while taking part in technical discussions helps to ensure that the EL has enough domain and project knowledge to participate meaningfully in a project without necessarily requiring to perform active development.

Besides, an EL can fully participate in the development process of one project when assigned as they work side-by-side in the squad, i.e., working on development tasks and committing code. Furthermore, an EL 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), development work is limited to a single project. Doing development on all projects would entail not only an immense workload but also significant context switches incompatible with the remaining 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 EL that enables the development 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 EL is held accountable for the technical implementation and delivery of all the assigned projects at the required quality. The EL 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 Software Developers, Technical Leads, or Principal Software Engineers, they often have the technical abilities to make adequate 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 ELs 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 would create conflicts in the development team. The squads must continue to work collaboratively and have group ownership. Thus, an EL 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 PM is purposefully the main point of contact between the squads and the client stakeholder(s), ELs are encouraged to engage in conversations punctually 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 PM 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 60 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 the team development processes. In a large team, Engineering Leadership is meant to ensure the team processes are maintained across the board from development to security.

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

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

A Typical Week

Schedule

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, involved in active development for one of them, and manages 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 a one-on-one with the assigned team members (monthly). Prior to the event, the EL must prepare keynotes for the meeting.
  • Attend the one-on-one meeting with the CTO (monthly).
  • 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 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).
  • Perform a one-on-one with the assigned team members (monthly). Prior to the event, the EL must prepare keynotes for the meeting.
  • Write the report for the CTO and attend the EL Retrospective meeting (bi-weekly).
  • Participate in the Engineering Lead retrospective (bi-monthly).
  • 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 additional engineering initiatives to deliver the engineering roadmap and to remain hands-on, perform technical writing for Compass and the blog.

Best Practices

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

• DO strategically oversee each project based on its needs at any given time.
• Do NOT simply split your time equally between each assigned project.

👉 No project is the same; each has its specific timeline, constraints, and challenges. Therefore, an Engineering Lead must know how best to oversee their assigned projects. In practice, one project might require more effort than others. As a rule of thumb, at the two extreme points of a project lifecycle, i.e., when a project starts and ends, the Engineering Lead must be more involved in the day-to-day activities to ensure a smooth start and hand-over since these represent sensitive moments for the squad. Similarly, a project on a complex or novel domain would likely require more involvement than a project on a domain that the team has extensive experience in.

• DO minimize context switching between work activities of different types.
• Do NOT treat every work activity as identical to one another.

👉 An Engineering Lead needs to combine both a maker’s and a manager’s schedules. They have software development duties that require deep focus for long periods of time (i.e., several hours), similarly to Developers and Team Leads. That represents their maker’s activities. While, unlike individual contributors, they also have management duties that involve coordination and collaboration efforts for short periods of time (i.e., less than an hour). Switching too often from one type of activity to the other usually results in poor outcomes in both areas. Therefore, it is best to group work activities that fit into a manager’s schedule (e.g., interviews, one-on-one reviews) together on the same day while scheduling work activities that fit into a maker’s schedule (e.g., development, code reviews, etc.) on days when disruptions are less likely.

• DO meet reports at the scheduled date and time for one-on-ones.
• Do NOT postpone on short notice one-on-one sessions with reports.

👉 While Engineering Leads might find themselves, at times, busier than they planned for, they should still honor their commitments with their reports. Postponing a one-on-one session implicitly sends the message that there is other work more important than the one-on-one, i.e., the Engineering Lead values other activities more than their time with their report, hence depleting the trust battery between an Engineering Lead and their report. When rescheduling is necessary, it should be made with ample notice period and accompanied by an honest rationale.

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 engineering team members.
• 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 engineering team members and projects.
• Assess and recruit new engineering team members.