The technology industry has been overloading the term ‘senior engineer’. A senior engineer is not a senior engineer is not a senior engineer.

What “senior” really means depends on what your organization needs and how it operates. Much of my experience has been in small organizations, so this list may be tilted more toward jack of all trades, but I’ve seen some of these patterns at larger companies as well. Here are a number of attributes that all seem to get wrapped up in the word “senior”.

Domain knowledge: sometimes getting up to speed on a domain can take too long. If you are operating in a highly regulated or intricate problem domain (real estate, finance, health care, government contracts), senior may mean “this is not their first rodeo”. In other words, someone who can jump in and understand complicated entity relationships and acronyms quickly.

Deep technical skill in the problem space: someone who has been there before. ‘There’ is a technical area where screwing up is going to be very bad for the company, for example, scaling an application, running a database or securing an environment.

Deep technical skill in the exact technology: someone who has used your exact technology stack before. The idioms, the libraries, the warts, all of these vary enough and if you want someone senior in technology, a close substitute won’t do. If your app is in Django, you need a senior Django person, you don’t need or want someone with Rails or Laravel experience. Same for someone with PostgreSQL experience (as opposed to MySQL). I see lots of job applications where this was a belief, but fewer organizations where this is a reality. This is often just a simple way to filter applicants.

Broad technical skill in a related area: someone who has used something similar and can come up to speed quickly by making analogies between similar situations. Maybe you can’t find that exact match. In that case, you can broaden your search. At a hight level, MySQL and PostgreSQL have a lot of similar characteristics, and mapping knowledge of PostgreSQL into MySQL (or vice versa) can be effective. This senior developer works best when paired with a someone with “deep technical skill in the exact technology” person because then they can pick up idioms and libraries.

Utility player: this type of senior developer can fill gaps in your team. They notice what isn’t being done, whether that is setting up a build system, documentation, project management, user testing, design or something else, and either do it or advocate for it. Or both. Probably more important in smaller organizations.

Leadership: this is the ability of a senior developer to lead a team toward a business goal. This includes understanding why the goal is important, caring about the goal, communicating the goal to the team, and rallying the team when the goal seems unattainable.

Mentoring: this is the ability to develop other talent in your organization. Whether or not there is a formal mentorship program, skills transfer and teachable moments happen every day (and are not always performed by the more experienced party!). Doing this requires empathy. If your organization has a lot of less experienced developers, a more formal program may be useful.

Humility: senior developers are senior because they’ve made mistakes. This is the ability to acknowledge mistakes, learn from them, and try to figure out how to make only new mistakes.

Continuous learner: this type of senior developer is looking at new technologies and developments and seeing how they map into the current problem space. Often they are just “playing” with technologies on their own time. If they’re really good, they’ll acknowledge their “shiny object” syndrome and advocate for ways to explore new technology that don’t impact long term maintainability (spikes, hackathons).

Cross department communication: the ability to build a mental model of who knows/owns what in your organization. When hiring a new developer, they won’t have this map, but they may have built one for previous organizations. Someone with this knowledge knows who to ask to get something done, or who needs to be notified when changes are coming. This can prevent the significant pain of building the right solution to the wrong problem. Leveraging someone with this skillset cuts down on formal process, but eventually these communication channels may need to be formalized as the organization grows. Probably more important in smaller organizations.

Project management: depending on the size of your team or organization, a senior developer may need to be the adhoc project manager. They probably won’t enjoy this much, but someone has to do it. They’ve seen what happens when someone doesn’t (see “Humility” above).

Development support/operations/devops: this is the glue around your application that helps your application function. These tasks can range from developer focused tasks like a coding style guide or maintaining the developer docker image to operations tasks like setting up the monitoring system to devops tasks like debugging the failing jenkins job.

Deep knowledge of current application: this obviously isn’t a senior position you can hire for, but is one that a developer can grow into. This is the senior person that knows all the answers about the growth and path of the application code. If they’re really good, they document and share the knowledge.

When you are posting a job description for a “senior” engineer, think about what dimensions listed above matter. You can’t find someone who is good at everything, so what do you really need? What does your organization need?

8 thoughts on “When is a senior engineer not a senior engineer?

  1. Carsten Schwartz says:

    I think you forgot to mention, general experience in does and donts of software development 🙂

  2. Jacques says:

    Interesting points! I’ve been a software developer for about 12 years. Most of my experience has been with desktop applications (WPF) and I’d consider myself a senior in that domain. Recently I moved jobs and now I’m writing Angular 4 apps and in that regards I’m still a junior, moving on to intermediate.

  3. T says:

    At my large (>$10B) company, “senior engineer” is just a rank.  It’s purely subjective.  It is only the second rank of engineer, meaning 2-4 years of experience.  All the best engineers here are way past “senior”.  It hardly denotes being experienced or seasoned. It’s one step above new-grad. This also seems to be the norm at large companies.  It’s just a word…

  4. moore says:

    That’s a good point. My experience has been with smaller companies, but I’m sure a senior engineer at a company like Oracle or Google has a different scope of responsibilities than a senior engineer at a 5 person startup.

  5. Brad says:

    I would add to this list:

    Plugged in to the global engineering community: This person knows how to reach outside the organization for help, and helps the organization give back to the community. This might be personal connections at other companies, open-source contributions, reporting bugs and pushing along solutions in external bug-tracking systems, involvement in StackExchange communities, or being plugged in to local developer groups.

    Several former colleagues come to mind when I think of this skill. Having someone around that can fix bugs in Android and file bugs with the iOS team is really helpful when building a mobile game.

  6. moore says:

    That is a great one! Note that getting involved in local groups is something everyone can do with a small time investment, no matter how much or little experience you have.

  7. David Howell says:

    At a smaller company you definitely have to wear many of these hats. It’s hard to be an expert at everything, especially a domain expert or deep technical specialist. I am the continuous learner, technical support, maintenance, devops, broad technical knowledge, mentor etc etc because it’s only a small team. You’re right I hate project managing, especially all the meetings and gantt charts. There’s also the business analysis and test automation, deployment management, architecture, security and integrations, presenter, trainer, all the roles that big companies have dedicated people and sometimes whole teams managing. On the plus side there’s a lot less cross communication required and generally less time spent establishing shared conceptual models between team members simply because there are fewer edges in the social graph. There seems to be a lot less inertia yet a lot more momentum if you know what I mean

  8. moore says:

    It’s definitely a trade off! Your comment covers some of things I missed. Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *



© Moore Consulting, 2003-2017 +