What makes you senior

Isn't that just called "being put in charge"? The causality seems reversed to me here, as in, you're not senior because you're reducing ambiguity, but you've either explicitly been made senior or just have tenure and now others come to you with questions about what you think makes sense. Consequence rather than cause

Or maybe that's just in egalitarian companies, like in tech where I'd ask a second opinion or technical input of just about anyone, whereas in other lines of business it's different? I imagine a water treatment facility has a lot more niche constraints to work with than we do and so expertise goes much deeper and you're not immediately prompted for advice

I suffered with this problem quite often with my previous job. There would be something vague assigned to me and I didn't quite get what to do but I also felt like if I asked questions, it'd give off a vibe like I didn't know what I was doing so I would just start programming and making a bunch of assumptions.

That wasted a lot of time which is a lesson to be learned from.

I also struggled with self management.

  > The moment you hand them something fuzzy, though, like ...
  > “we should probably think about scaling”,
  > that’s when you see the difference.

Can someone who worked in multiple industries clarify: is it only software that has constant identity crisis with "what makes you X" and "what is expected of Y"?

The only thing that makes a senior are years of experience, that's all. You can be a shitty senior if you only do one thing for 10 years, but you're a senior nonetheless.

When everyone in the room wants to go in a certain direction. And you tell the team "9/10 times i did it that way it blew up in my face.", and you don't fight them and let it play out as a lesson. And there is still a 10% chance it could work!

Meanwhile the industry standard definition since the 80s:

- Junior - someone who can work under guidance.

- Regular - someone who can work alone.

- Senior - someone who can guide others.

It's subtle, but I think the use of "senior" rather than "Senior" in the article is an attempt to distinguish the concept of being a senior engineer from the title of Senior Engineer. The article is focused on actually being senior, not playing title games. I'd take it further and use the term "leader" instead of "senior engineer".

Leaders reduce ambiguity, so others can operate with more clarity. The ambiguity involved can be in many different domains. It can be focused on product and tech, as in the article. Another example is ambiguity around people and organizational structure, which is more common in management roles, where some in management are more effective leaders than others. It can be around finding ways for people to understand why they might want a product, which is more common in sales and marketing roles. And so on.

A very important skill for Senior engineers not mentioned in the article is an ability to take the initiative on something. For example, when a dev sees a bug in an area of code they aren't responsible for and thinks "I'll raise an issue for that and mention it to the product manager so we can get it fixed" instead of "Oh, a bug", then they're starting to show that senior mindset. It's a desire to make the whole of the software good rather than just the little bit they work on good.

I like this. I more generally look for reduces chaos.

I’ve seen the pursuit of disambiguation employed to deadlock a project. Sometimes that’s the right thing to do—the project sponsor doesn’t know what they want. But many times the senior needs to document some assumptions and ship something rather than frustrating the calendars of 15 people trying to nail down some exact spec. Knowing whether to step on the brake or the gas for the benefit of the team and company is a key senior trait.

This is a yes, and to the article; building without understanding the problem usually will increase chaos—though sometimes the least effort way through it is to build a prototype, and a senior would know when to do that and how to scope it.

Eh. Whenever someone posts something like this, you get a bunch of folks, stating how they meet that description, etc. Sometimes, they do it humbly, sometimes, not.

In my case, I met that description on my first job, and I guarantee, I was not senior.

You see, my initial training was as an electronic technician (RF/microwave stuff).

That thought process described, was exactly what they trained us to do. Debugging a wonky RF board is about as ambiguous as you can get.

So maybe there's a different definition of "senior."

Great article. The key things often missing in meetings discussing a vague problem is do we really understand the problem and how do we make concrete progress. Its a hard skill and often just comes through experience - being able to put yourself in the user's shoes to understand their problem, and knowing based on past experience, how to execute. That is the value of seniority.

age