Engineering Roles

Nailing down the roles and responsibilities a company expects from their engineers is one of the most over-looked, but important, areas of a company’s organization. It’s often talked about when hiring or promoting, but rarely at other times. When it is talked about, it’s usually more of a gut feeling by individual stakeholders rather than objective criteria. The conversation usually resembles something like this:

Person A: I feel like what I’m looking for in a senior is someone who has a real hacker mentality and isn’t afraid to tackle the difficult problems

Person B: Yeah! Someone that is really familiar with the platform and can help others

Person C: We really use {difficult_tool} a lot, so they should be good at that to

What’s wrong with this approach?

It’s not really a list of objective criteria that can be measured and understood, it’s more a list of feelings that can shift arbitrarily by project/day/manager. In fact the only concrete thing mentioned (the difficult tool), is also the thing most likely to change in short term. If you don’t nail down the roles and responsibilities of your engineering team, you will inevitably cause un-needed frustration and confusion.

Every company has different team, project, and budget sizes. This isn’t meant to describe the details of every situation, but you’ll notice that almost every situation fits in to this description.

Roles and Responsibilities

Engineering roles are relative to each other, the company they exist in, and the projects they are attached to. Because of this relative nature, it’s impossible to nail down “X level engineer must know Y” where ‘Y’ is some combination of technologies and/or stacks. Someone that knows a popular framework well (e.g. jQuery, React, or Rails) might easily fill the Senior role at a local startup, be the equivalent to a Chief Architect for a Mom-and-Pop local business, and yet be completely unqualified to work even in a Junior role at a major company like Google or Facebook. This doesn’t mean they aren’t good engineers, or that the role is defined poorly, it just means that they might not be a good fit for that company. So in coming up with these definitions, it’s more about the context of the company you are working in.


Each role should be capable of fulfilling any of the roles further down the chain, but the majority of the time is focused on the responsibilities appropriate to their level.




To help walk through the different levels of engineer, I’ll describe the essential qualities of each role in regards to four main categories:

Career Advancement

The roles listed are very much a ladder that can be climbed rung to rung or, in exceptional cases, levels can be skipped. Understand that there is a difference between someone being able to serve in that role, and actually serving in that role. If you promote an engineer just because of their ability, you’ll end up in situations where there are “too many cooks in the kitchen” or the work you have for them is too low level and boring. If you promote an engineer outside of their ability, just to fill a need, you risk stressing them out and causing burn out.

Making sure your company has proper roles means that sometimes you will:

What to look for in promoting

Common Problems

Our company doesn’t have/need a Senior Engineer/Chief Architect

What this really translates to, is that you haven’t formally given someone that title. If you watch your team closely, you will notice that they have already organized themselves to fill in this deficiency. On the positive side, some engineer has stepped up and others have gravitated to them as being “the guy/girl”. But on the negative side you typically see persistent conflicts over trivial matters, or a manager/product owner having to step in to give a sense of direction so that work still gets done.

Our company is too big, we need to have even more levels to split people into

If you feel like your company is so big that you need more levels, then you usually have a different problem happening. Common ones are: