What does a Senior Engineer Look Like?

What does a Senior Engineer look like?

This is the second installment on what I share with engineers which I manage, describing some of the key competencies engineer’s at a certain level typically display. Last time I wrote on the Lead Engineer level, Lead Engineer, what does it look like?, in this installment I share on the Senior Engineer level. I typically share this with my Engineers and Senior Engineers to help them understand my expectations. 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.

What does a Senior Engineer look like?

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 Senior Engineer competencies demonstrated on a few dimensions. While the below items are certainly not a definitive list of all competencies needed to be effective at this level, the below description typically helps to paint a sufficiently broad and vivid picture that in reflection and discussion, growth opportunities present themselves with those that I work with.

Senior Engineer Competencies*:

Technical**

Scope of oversight

• I expect that the scope of oversight at the Senior level would cover a handful of features to a small product, or 1–3 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 features, a small product or services to accomplish the business outcomes needed. They effectively engage with product development conversations to collaborate on good technical decisions (within their scope of oversight) with a solid and growing level of understanding of the impact of those decisions. While they may need the assistance of others to make sure they understand enough of the surrounding services or code base to effectively design the feature, they can take on the decision making role with effective judgment based on a depth of understanding of the feature that they are working on, it’s boundaries, and how to debug it within the system.

Technical Operations

• I expect that they have a solid and growing depth of understanding of how to effectively tool their code for scale. While the level of scale may vary based on the context of the product or team, they understand and apply principles to effectively test, track, log, monitor, and evaluate the ongoing health of their product. While they may not be the best individual to debug any and every production system, they are growing in their understanding of how to, and they design their features and products in such a way that others could of theirs as well.

People/Project Management

Scope of Oversight

• In regards to the above technical scope of oversight, I expect a Senior Engineer to also have the ability to effectively break down and scope that work into workable chunks for themselves and possibly another engineer. Effectively scoping and sequencing includes creating these work packages in small enough pieces such that estimations are effective, keep in consideration how they and the other engineer 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, Senior Engineers have displayed ability in breaking down their tasks, awareness of other dependencies and cross-team constraints, and a general experience level that allows them to anticipate and articulate potential impacts so that those risks rarely result in major impact to the team or project.

Accuracy of Estimations

• I expect that they often (70–80% of the time) succeed in accurately estimating (within 150% of the estimated sizing) their personal Stories/Tasks, as well as showing continuing improvement at estimating tickets of those that they are working with. I expect that they understand what a properly defined ticket looks like, that they write them (when appropriate) 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 and a growing understanding of how to help others in their team accomplish that. 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.

Self and Team

Continuous Improvement

• I expect that they are able to identify areas for improving the efficiency of their own work as well as a growing awareness of how to improve their teams work. They are able to identify constraints, make suggestions, identify tools or process changes which could make themselves and their team better.
• I expect that they are curious about their product and how to make it better. They have a solid 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 features that they build.

Leadership

• I expect that they are looking for ways to help others on their team to grow. Examples I have seen of this type of servant leadership include onboarding others, pair-programming, mentoring, teaching new tools or processes, etc. I expect that they are displaying some form of leadership towards those around them such that they are magnifying the impact of their colleagues and team.

Communication

• They effectively communicate with their teammates, they develop an appropriate level of rapport with those outside the team, and they are an effective team representative when needed.
• I expect them to be comfortable and effective at communicating with other engineers and teams to keep their work (and any that they may be overseeing) unblocked.

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 Senior/II level to be successful and to grow into this at a professional software company.

I welcome discussion on other competencies or points that you think are critical for success at this level, or if you feel that something I have included is not necessary or too high a bar.

Jeremy is VP of Product and Engineering at Base as well as InVision Engineering alum. He leads open-source projects with Code for Greenville, and is a mentor for Engineering leaders with Plato. Connect 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 that we should see these skills demonstrated in progressing growth as they grow in understanding of the product and team. Generally at InVision this was 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. However, the timeline will vary highly based on the org and the size and complexity of the code base.

**Many individuals which I have led, have been technically skilled and have been able to excel and grow in the Technical area while yet requiring other competencies to make it to the Lead level. In these cases, you often see those engineers overseeing more technical surface area (perhaps a med sized product, many features, or multiple services) while remaining at the Senior level. In my expectation, this one area of competency (lacking in the demonstration of other key areas) does not prepare them to operate effectively at the Lead level. This is why it’s key that we have growth and expectation discussions so that I/we can help them to identify, prepare and grow.

What does a Senior Engineer Look Like? was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.