Defining a Senior Software Engineer seems to be a pretty difficult task for our industry. Managing expectations around this definition is also really difficult and causes strife in organizations that are trying to grow and retain talent. The current methodology is to create a “Job Description” which focuses on “responsibilities” and “requirements” by listing the work skills, technical requirements and years of experience required for the position.
Like everyone else, I used this approach for a while until I ran into problems. I started looking for a framework that I could use to scale an organization in both talent evaluation and career development. I wanted answers to questions like:
- How do you differentiate between a Software Engineer and a Senior Software Engineer?
- Is seniority based on years of experience or based on technical capability?
- How do you promote and fairly compensate engineers who use different languages and tools?
- How can you evaluate new talent consistently and compare them with the current members on your team?
- Where do the required years of experience come from and are they just an artificial crutch justification?
- How do you mentor engineers in their career and so that they can grow and learn?
There are more questions to be answered but this is a good starter set. Naturally, I searched the web for answers. It turned up a couple of somewhat useful threads on programmers.stackexchange and on Quora and while they left me admiring the technical complexity of some of the answers, there was still something missing.
Not finding what I wanted online, I talked with a few peers in my network. Turns out they use the “Job Description” method and they agree it is a failed approach. Since my search turned empty I instead spent a lot of time thinking on the topic and came up with a framework that provides guidelines for making the decisions around the questions above.
A New Approach
It is important to understand that the definition is actually for many levels than just the Senior Software Engineer. There are some who argue for a flat organization, but I’ll address that myth in another blog post. We should ensure that our level definitions make it easy to answer the questions we posited previously. They should also help us lay the foundation for a career progression that is possible within the company helping us retain talented people.
The challenge I set for myself which really helped provide a different frame of reference was to answer the following question:
If you could describe what an engineer at this level will do using only word, what would it be?
A single word is succint, descriptive and most importantly memorable. It will be easy for your teams to digest and in discussions leverage the simplicity. A single word is only useful if we can provide context so the next step in the framework is to provide a single sentence description of the level.
Summarize what the person at this level will be doing in a single sentence incorporating the single word definition from the previous step
Building upon context we can switch to defining the major areas of focus the role should have at this level:
Define 3 to 4 technically agnostic areas of focus that provide guidance for a person performing at this level.
It is important with the last step of the approach to not get caught up in the details of the technical requirements. Doing so prevents you from having an overall framework and leads to the dreaded Job Description model that we previously stated doesn’t help solve any problems.
Let’s walk through how I applied the model to engineering at ModCloth where we have 3 levels in the software development position:
- Associate Software Engineer
- Software Engineer
- Senior Software Engineer
Of course we have other roles on the team as well such as test and platform engineers and I am sure you do on your team’s as well, but I’ll leave them out for brevity.
Associate Software Engineer
This level is reserved for beginners, someone who is fresh out of school or making a career change. We don’t expect them to have a lot of experience and it is easy to envision them spending their first year learning about the languages used and best practices of their team. Applying the model we have the following:
At the Associate level you are learning skills and developing competence.
Areas of Focus
- Develop a basic understanding of the languages and tools used by the team.
- Gain exposure to software development best practices such as TDD, debugging, documentation, etc.
- Learn good communication skills to be used with your teammates.
At this level the engineer understands the basics of the areas of focus from the previous level. The distinction is they are now applying their basic skills instead of learning what they are and requiring supervision. Of course we are always learning but the difference is the person can now be trusted to apply their newly acquired skills independently.
At the Software level you are applying your skills and developing expertise
Areas of Focus
- Leverage best practices to write and continually improve the code base.
- Develop mastery in the tools, languages and frameworks used by the team.
- Begin practicing and learning how to teach/mentor less experienced teammates.
Senior Software Engineer
This level of engineer is the crux of any successful engineering team. They are able to go beyond just using tools and techniques and now recommend what the team should do and how to go about it. They have accomplished a technical maturity that allows them to solve complex problems and begin to take an ownership position on the code and systems they haven’t developed.
At the Senior level you are mentoring your teammates and sharing expertise
Level Areas of Focus
- Develop the necessary best practices to work with and write a great code base.
- Help evaluate and select the tools, languages and frameworks used by the team.
- On board and mentor new members of the team ensuring their success.
- Begin to take an ownership position on code and systems developed by others
We have covered a model framework for defining the different levels of any role within an organization. The benefits of the model are that it can be applied to role in the orginization and is scalable. A simple moniker for remembering the model follows below:
Description –> Context –> Areas of Focus
Let’s revisit how the example application of the model answers the questions posed at the beginning of this blog. By providing simple and flexible areas of focus it helps evaluate and contrast the different levels in the defined role easily. It is technology and years of experience agnostic instead judging engineers on their ability to go from individual to more team focused contributors. It also makes learning and mentoring a key component of how the team will judge it’s success.
The one question is doesn’t answer is where the years of experience numbers come from? Honestly, I have no idea and nor do I need to care anymore when writing a new job description!