One thing that I consider to be a really important part of a senior engineer's job that's not enumerated here is: helping more junior engineers come up with estimates for difficulty and time on projects they're about to undertake. To a senior engineer, there are a large number of projects that are fairly easily scope-able, e.g. "add a new API endpoint"; "refactor this medium-large model" that a junior engineer may not have the necessary degree of confidence to estimate. While this can sometimes be the responsibility of an engineering manager, not all EMs are sufficiently technical to know how long it'll take a _junior_ engineer to take on an otherwise easily-scoped task.
> I put “write code” first because I find it surprisingly easy to accidentally let that take a back seat<p>As a first-year-out-of-school developer, I shadowed an interview once from a "Principle Engineer" at another company. By the end of the interview, we understood two things: 1: He did not code in his job and hadn't in a while. 2: He could not code anymore.<p>This role was for a senior engineer position, where he would need to mentor people on writing software. It was a pretty hard 'no' by the time we did our group follow-up with the other interviewers.
Totally disagree with the section "What’s not part of the job"<p>Part of any job is stepping up and deputising for your manager, sure if you don't want career progression or want to go into the technical side you could argue they would try and do some of that instead, but if you want to be a senior you have to be a rounded individual that can mentor new starters, help with sprint planning when your boss is not around. Thats part of being a senior, otherwise you are just a good Mid.
Good read, I like JE's posts. But I definitely feel like this falls into the trap that a lot of similar posts fall into - attempting to "bullet-point" a role description inevitably will result in people criticising the inclusion or exclusion of individual points. Which is a shame because it detracts from the overall spirit of what's being said.<p>Struggling to find the link now, but I read another post on the subject of seniority, and it basically summarised the crux of it for me. This unravelled everything. Seniority is measured contextually by asking: "to what degree can I leave stuff with this person and expect it to get it done with high quality? Further, to what degree can I NOT leave stuff with this person and _still_ expect that to get done."<p>From this, one can derive their own context-appropriate "check list". In an environment such as finance, where an engineer is absolutely not the expert, can I trust that this person can work with the experts to get to an appropriate solution? In an environment where you have many intermingled teams, will s/he be able to propose solutions and get buy-in across the org? In a consulting/client scenario, can this person represent our company? What might they need help in? In a bootstrapping startup scenario, can I entrust them with the entire build of (some major component)?<p>In different contexts, the above set of questions would unroll a different set of measurements for seniority, and may require a different mix of soft/technical skills. But that's fine, there's no one-size-fits-all seniority ladder.
In the section where she explicitly mentioned what is not part of her job, I bring two of her points which I disagree with.<p>* Make sure work is allocated in a fair way<p>* Make sure folks are working well together<p>While she is not directly responsible for these two items, she and everyone else on the team should be responsible for alarming their manager/team leader when either of these items are not working. With more eyes and ears monitoring the team, it helps to reduced the risk of bad behaviour disrupting the team's cohesion.
I think there are some less concrete responsibilities. This post assumes all your colleagues give a shit, while some work might get delegated to a colleague who then waits for you to step them through it. How do you motivate people to take responsibility for their work (when firing or changing teams isn’t possible)?<p>I think a senior engineer is also going to be one writing fundamental proofs of concept when time is tight (or at least I have been doing this)
> "...review design docs"<p>In my opinion, one of the most important and most difficult parts of the job. Architecture and design shouldn't be limited to senior engineers--it won't be in practice, anyway. Doing so is a sure fire way to stilt the growth of your team.<p>But, reviewing designs is hard. It requires recapturing much of the context that the engineer gathered in a very short period of time. I also find it sometimes difficult to separate, "this is a fatal design flaw" from "this isn't how I would do it." I really like the suggestion of providing feedback via additional information.<p>Mistakes are a very important part of learning. I try to make sure everyone has the opportunity to make their own instead of making mine.
I think that setting explicit job boundaries is a good thing to do. Otherwise you end up with role creep and potential burnout. This happened to me. There is a considerable pressure to pick up as many activities at the job as you can as hiring more developers is hard or impossible at some locations as the demand for developers has skyrocketed. This demand buries you even deeper under tasks once your colleagues leave elsewhere for better offers.
It's interesting the author mentioned estimating but said they are not very good at it yet. I have read somewhere else that what distinguishes a senior engineer from a junior engineer is exactly the skill in estimating work.
I have my own sort of loose rules about this. I long ago came up with it, and it works for me, but maybe there are a few holes worth poking.<p>Basically it goes like this: There are no 'senior'/'middle'/'junior' level developers. There are _A, _B and _C.<p>_A guys sit at the top. _B supports _A. _C support _A and _B, and .. other _C's. _A supports all _B's, all _C's, and of course.. all other _A's.<p>The position is self-determined, i.e. up to the individual. Occasionally, when enough _A's, _B's and _C's serve together, they self-organise. Sometimes, you need to tweak a few things.<p>For example, there is a kind of _A who doesn't want to work on things without a few multiples of _C around to clean up after him. This guy needs a _B.<p>Then there are _B's who ignore _C's and just wanna work with _A's. This guy needs a better _A. And, also, a few _C's.<p>And there are _C's who want to be _A's, while ignoring their duty to _B. This guy needs a few more _A's, and either becomes a _B, or an _A. (Or a _D, which is 'goes and does marketing stuff instead'.)<p>Either way, there is another 'type' of developer, and this guy is an _X. He gets all the _A's and _B's and _C's happily playing together, executing on the plan. He can be an _A or a _B or a _C: he doesn't care, as long as things are executing.