paint-brush
What does a Lead Engineer look like?by@JeremyWight
9,851 reads
9,851 reads

What does a Lead Engineer look like?

by Jeremy WightOctober 25th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Recently another <a href="https://hackernoon.com/tagged/engineering" target="_blank">Engineering</a> Manager asked me how I look at qualifying someone as a Lead Engineer. This is something that I share with folks on my team, and given the strong response it got internally I thought it might be helpful for other Engineering Managers, Directors, <a href="https://hackernoon.com/tagged/startup" target="_blank">Startup</a> CTO’s, Tech Leads, aspiring Tech Leads, etc.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - What does a Lead Engineer look like?
Jeremy Wight HackerNoon profile picture

Recently another Engineering Manager asked me how I look at qualifying someone as a Lead Engineer. This is something that I share with folks on my team, and given the strong response it got internally I thought it might be helpful for other Engineering Managers, Directors, Startup CTO’s, Tech Leads, aspiring Tech Leads, etc.

While the naming, leveling, and expectations at your company may be slightly different, I hope that this will help to trigger conversations between engineers and managers to help further the growth of those we have been blessed to lead. I welcome any thoughts and feedback in the comments.

I look at Lead Engineer competencies demonstrated on a few dimensions. A Lead Engineer exemplifies all Senior Engineer qualities to a broader scale of impact and assumes that the individual understands and is operating at that level successfully. While this certainly is not a definitive list of all competencies needed to be effective at the Lead level, the below description typically helps to

paint a sufficiently broad and vivid picture that in reflection and discussion, growth opportunities present themselves.

Lead Engineer Competencies**:

Technical

Scope of oversight

  • I expect that the scope of oversight at a Lead Level would cover a small-med product, or 3–5 services (varying based on size), meaning they have a good understanding of those code bases, the design patterns, where the areas of concern are, how they operate, the architectural patterns, etc.
  • I expect that they have the ability to architect a product or a handful of services to accomplish the business outcomes needed. That they effectively engage with product development conversations to collaborate on good technical decisions with a deep level of understanding of the impact of those decisions. Essentially, they can take on the decision making role with effective judgment based on a depth of understanding of the services and how they will function together. They understand where those assumptions break down, and they effectively collaborate with other teams to establish resilient service boundaries, create cross-team project plans and deliver a good experience to our users.

Technical Operations

  • I expect that they have a deep and growing understanding of how to effectively tool their code for scale. While the level of scale may vary based on the context of the product, team or organization, they understand and apply principles to effectively test, track, log, monitor, and evaluate the ongoing health of their product.

People/Project Management

Scope of Oversight

  • In regards to the above technical scope of oversight, I expect a Lead Engineer to also have the ability to effectively break down and scope of that work into workable chunks effectively for 3 or more engineers. Effectively scoping and sequencing includes creating these work packages in small enough pieces such that estimations are effective, keep in consideration who may complete the work and the timing of that work in light of other cross-team constraints. This scoping will likely be in collaboration with other engineers, however, Lead Engineers have experience and displayed ability in breaking down tasks, effectively challenge others scoping, identifying potential impediments, etc. to make sure that it’s broken down effectively and that the overall project is effectively understood and articulated.

Accuracy of Estimations

  • I expect that they often (70–80% of the time) succeed in accurately estimating (within 150% of the estimated sizing) their Stories/Tasks and an understanding of how to help others on their team to accomplish that. I expect that they understand what a properly defined ticket looks like, that they write them and that they effectively push back when a ticket written by another team member needs further clarity. I expect that their estimates are consistently completed, meeting the defined criteria and the team’s Definition of Done, within 150% of initial estimation. This includes the consideration of all of the parts of the process to get to “Done”, not merely the functional coding, e.g. Research, Collaboration, Fudge Time, Test Writing, Personal QA, Delivery, etc.

Team/Departmental Improvements

Continuous Improvement

  • I expect that they consistently raise ideas for improving the efficiency of their teams/zone/departments work. Essentially, they are looking at things holistically and identifying constraints, such that they are making process suggestions, operational Improvements which reduce noise and overhead, improving testing patterns, etc.
  • I expect that they have a deep and growing understanding of their product, their users and the market that it operates in.
  • I expect that they know their team and product(s) success metrics and are applying that understanding to the products that they build.

Leadership

  • I expect that they display leadership such that others come to them with confidence because they are known to be those that others can come to gain deeper insight, clarity, etc.
  • They effectively lead others through meetings, planning, and any processes which are needed to accomplish the goals of the team.

Communication

  • They effectively communicate with those both inside and outside of the team. This is less of a single core competency, but it is one that allows them to be effective at improving the department, at project management, at being a leader at all of the other items. Communicating well and clearly, developing rapport with those throughout the organization, giving clear updates on projects, etc.

There are certainly other competencies which are important that someone brings at this level: Product Mindedness, User Empathy, Interviewing, Design Focus, Business Orientation, etc. just to name a few; and these can be incredibly powerful for individuals growing impact. However, when I think about the core competencies that I expect Lead Engineers to posses, the above are those that I expect to be demonstrated consistently in all engineers at this level. These are those that I am most often and consistently pointing to-to help engineers at the Lead level to be successful and to grow into this level at a professional software company.

Jeremy is a Senior Engineering Manager InVision, leads open-source projects with Code for Greenville, and is a mentor for Engineering leaders with Plato. Connect with me on Linkedin or schedule a time to chat on Plato.

  • *These expectations assume that the engineer has on-boarded and have been operating in this role for enough time to display these effectively. I expect to typically see these skills demonstrated in progressing growth, as they grow in understanding of the product and team. Generally, sometime within the 2– 3-month mark typically folks have a solid understanding of their teams products, and sometime between 4–6 months, they begin to really understand the broader ecosystem that their product operates in and display high impact in these areas.