Hacker News Reader

Comment by 29athrowaway | Hacker News Reader

My criteria for seniority is very simple:

Given clear requirements, can you be left alone for a reasonable amount of time and not come up with a monumental mess? If you can, you are a senior engineer.

And as a corollary, if you need constant supervision, you are not as senior as you think.

View on HN

In a vacuum maybe, but one of the major challenges in any large technical organization is architectural alignment between different work streams. Meaning, that whatever you're doing for project A also has to be compatible for whatever is happening with completely different project B. Given how social cliques work, even if you are a senior engineer it's possible to find yourself going back to others over and over again just to make sure you're aligned with the major decision makers.

And given _unclear_ requirements, you should be able to ask the right questions to make them clear. This is probably a harder barrier to overcome.

This is very much a hard barrier.

I find it even harder to produce clear requirements that don't precipitate such questions.

I guess it depends on your org but if you're required to do BA work, I find that the most challenging.

I humbly proffer that in order to produce clear requirements, it necessitates asking clarifying questions in the context of understanding what engineering effort is being requested.

And, perhaps, the most valued skill a senior developer acquires is enough business analysis (which I assume you reference as "BA work") ability such that the stakeholders feel comfortable in what they have conveyed is, in fact, what the development team will set out to deliver.

>And, perhaps, the most valued skill a senior developer acquires is enough business analysis (which I assume you reference as "BA work") ability such that the stakeholders feel comfortable in what they have conveyed is, in fact, what the development team will set out to deliver.

I could not agree with you more. Learning how to clearly communicate to stakeholders is an invaluable skill. One I have yet to master but deeply long to.

Another thing is, you have to lead other engineers. Not only you shouldn't need constant supervision, you are the supervisor in many cases.

How does this work on a team composed exclusively of senior engineers?

Where is the source of direction or vision for the project? Rarely is this task evenly divided.

There can be different sources of "direction" for the project: product, engineering and project management. The roles may overlap but the leaders that are good at those 3 things are rare.

The one with the most domain knowledge and technical excellence leads? thus Lead Senior Developer.

Those that sound like they know what they are doing, seem to make good decisions, appear to the manager as someone that will make them look good, and seem to be someone the manager can understand and trust will be promoted over someone with more domain knowledge and technical ability that doesn't have those other qualifications in some cases.

Don't assume a meritocracy, even if it had seemed that way initially, because managers change, and things often don't work like that.

Your job title/level/rank (“Principal Engineer”, “IC6”, ...) is what you’ve been deemed capable of (usually by doing it). But your role on a particular project is going to depend on what’s needed. Sometimes you’ll be the lead of the whole thing. Or the lead of a piece of it. Or just another contributor.

Some performance management systems are poorly designed to handle scenarios like this, admittedly.

Yeah agreed. Amazon expects everyone to follow their Leadership Principles but no team can succeed if everyone attempts to lead.

It depends on your role. If you are an individual contributor, you may not be expected to supervise other engineers or organize their work.

A senior engineer does not have to lead other engineers to be senior, only have the ability to do so if called upon.

Reply on news.ycombinator.com