When is a senior engineer not a senior engineer?
The technology industry has been overloading the term ‘senior engineer’. A senior engineer is not a senior engineer is not a senior engineer. In other words, yes, every senior engineer is a special snowflake :).
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, cloud native architecture, 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 high 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).
Engaged in their community: advocating for the company and/or network in their community (either worldwide, via the internet, or more locally) helps with both hiring and software delivery. Hiring from a wide network of connections is obviously helpful. Software delivery can be accelerated by using a saas service or open source framework which can be integrated. This allows the team to write less custom code. These can be discovered through the network passively, by reading about them, or actively, by asking someone.
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 an attribute you can hire for, but one that a developer grows 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?
This post was originally published at https://www.mooreds.com/wordpress/archives/2812