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 de

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. 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." 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)? 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.