There comes a time in the scaling of any engineering team when the cost of coordinating everything that’s going on in the present and keeping the team running smoothly – not to mention planning for the future – becomes more demanding than what individual contributors can handle as a side project, and requires a full-time role to do well. There are many names for this role, but at Hex we have chosen the title Engineering Lead.
In some organizations, becoming a manager or lead conveys new authority and the ability to make decisions for the team. This, we believe, is an anti-pattern.
At Hex, we’ve hired an incredibly talented group of people and have built a culture around individual ownership of projects and outcomes. In many ways, this is the “secret sauce” to our team – it’s how we are able build so much, so quickly, at the level of quality that we do.
Adding a dictator who either makes or otherwise gatekeeps all decisions on the team will not only add a layer of bureaucracy that slows us down, but will lead to dissatisfaction and disempowerment on the team, as well as to worse outcomes, since the lead is often not the closest to the problem and not guaranteed to have the best solution.
So if an Engineering Lead’s role is not to make decisions or tell people what to do, what are they responsible for? Broadly, the Engineering Lead is responsible for the healthy functioning of the team, while the engineers are responsible for the concrete implementation of features. The Engineering Lead role is a peer role to a senior engineering role: their focus and considerations are different, but both roles are equally responsible for ownership and decision-making. To underscore this fact, people moving from a senior Software Engineer to Engineering Lead or vice versa will have no compensation adjustments as part of the change: the move is purely lateral.
As an Engineering Lead at Hex, your responsibilities generally will include the following:
All of these questions are critical to answer on an effective engineering team, and the lead’s job is to make sure the most important ones are being addressed.
Overall, an Engineering Lead’s success is not measured by how much code or how many Notion docs they write, but by the overall output of the team. They are constantly thinking about how to make the team more effective, remove bottlenecks, and improve quality.
While most of these responsibilities are arguably based on “soft” skills, the Engineering Lead role still requires deep technical knowledge. In order to have informed opinions about plans and changes to the team, as well as to be able to accurately communicate with the rest of the company, as a technical leader you need to possess both specific knowledge of the codebase and the broad knowledge of the industry at large. As such, Engineering Leads will still code at first, though the scope of their projects will become reduced in order to make time for the other critical demands on their time.
Over time, particularly as the number of direct reports or the size of the team increases, there may not be enough time in the week for a lead deliver engineering projects in a timely manner in addition to their lead responsibilities. At this point, it’s usually time for the lead to step back from implementation work. This is completely fine and expected. A lead adds value by helping the whole team be more productive, not by their own raw output. This does not, however, mean that the role becomes non-technical: typically it will still involve a lot of technical work such as code reviews, architecture and RFC feedback, and coaching. To do these things effectively, a lead must remain close to the technology, even when not directly writing code.