> That often means the decisions you make you know are not the most optimal, but the most politically optimal.

Not intended to quibble, but to me that smacks of the dreaded "mid-level management" tier.

As a lead or principle, I describe what I do as being a "fire-and-forget resource". I build everything myself and don't require supervision. I will deliver regardless and am also able to justify my decisions. People seem to be happy so far.

That process is almost completely independent from meat-space concerns, aside from the requisite UX design.

> As a lead or principle, I describe what I do as being a "fire-and-forget resource". I build everything myself and don't require supervision. I will deliver regardless and am also able to justify my decisions. People seem to be happy so far.

Terminology is subjective of course, but:

I would also expect the above from a "senior" developer.

I would expect a "lead" developer to additionally be involved in leading a team and coordinating work within that team. (either from a project, people or tech perspective, or all/both).

I would expect a "principle" developer to be working at a higher level coordinating work between multiple teams and making architectural decisions that cut across the whole org or a large subsection of it at a larger company.

I think it depends on the complexity of what you're building. If it's something very novel or something that requires a lot of domain or technical expertise, then you might need a principal engineer to be the point person to figure out how to even build it, or build it right. Some problems are best solved by a single person with the right skills.

Some career ladders allow for this, others are more rigid about the size of team you need to be directly leading .

I think this is the appropriate answer. In my experience as Staff engineer, the tasks I was best suited to were the nebulously defined "the customer needs X" where X cross cut a lot of domains and required input from a variety of people that would be affected by that feature X. This usually meant that I'd have to get them all together at some point and find a way to satisfy all their contradictory needs before even coming up with what the real task definition of X was.

That's generally more than you'd expect from a typical Senior Engineer.

This gets tough. My company also loosely views Senior as the pinnacle of technical achievement with Lead and Principal engineers essentially being much higher level with no direct reports, but still doing policy, stakeholder, and political activities. Recently, some have pointed out the flaws in such a system as it leaves out the potential for promoting and giving a pay raise to senior staff that have continued making themselves far more valuable, but don't want to be capped or go into politics. There needs to be a path for someone who is just beast on the technical side and can be brought out to solve any problem. If that person is an order of magnitude more knowledgeable than your seniors, then they deserve to be distinguished as such. Our competitors that have figured this out have titles to better reflect this reality.

Those are great points to consider, thank you

> Not intended to quibble, but to me that smacks of the dreaded "mid-level management" tier.

Reminds me of the classic: https://www.ribbonfarm.com/the-gervais-principle/

The political part is so important, and such a departure from solving technical problems. I feel like nothing in my life has prepared me for it, or maybe I just ignored everything that would have.

I think there's a continuum of political savvy, though, where most developers have some level of it. For example, if one of your developers creates a new service using a technology that is new to the codebase, and half of the senior developers say, "Ugh! I'm not touching that. It's just <developer's name> showing off his big brain. I'm not wasting my time figuring out that unnecessary academic crap," you can understand how that was a failure even if a purely technical evaluation concluded that the learning curve was reasonable and the benefits outweighed the effort required. Before committing to the technology, it was necessary to introduce the idea in a way that got the senior devs to buy in, and if you can't accomplish that, you can't use the technology at all, because it's going to create morale and social problems as well a creating an isolated service that few people will work on.

That's a basic level of political savvy I think most people can relate to, so, if you can understand that much, you have a base to build on.

In my experience the issue experimented technical contributors have with politics is not savviness, it's managing frustration. Unless you enjoy playing politics for politics sake and value the grind of improving your position in the system, the mix of ineffective compromises and letting things rot because the blame will go the right way tends to wear you down in the long run.

Another way to look at it is you are expected to include business factors into your decision making. Sometimes the most optimal engineering solution is not the most optimal business solution. Politics can definitely be a factor, but being able explain clearly why doing something helps the business can be a big part of making the jump to more senior roles.

> She and I agree that everything past a senior engineer is political. She is much better and handling the complex social dynamics of the management class. It's kinda a game of finding the least common denominator that works best by not pissing off people and making everyone maximally happy. That often means the decisions you make you know are not the most optimal, but the most politically optimal.

A colleague of mine at previous company once described all this in two words "managing expectations" :)

It goes beyond managing expectations. What goals do you take? What goals do you ouah back against? How do you do this? How do you route around cranky groups that get nothing done?

> She and I agree that everything past a senior engineer is political

At the big tech company I work at, we're often told that even even senior is primarily a non-technical designation. Technical expertise and independence is expected of the level below senior, and in order to make the jump to senior you need to demonstrate leadership and other for skills - influencing others, project management, coordinating between teams, etc. Principal is a level above that that is kind of the same but more.

All this to say: every company is different.

so, making it possible to ship at least the org chart?

Life is a human communication game first, as the “best system” we’ve socially engineered is externalized support towards common goals. It’s not science or engineering; it’s sympatico.

The problems we’re solving at these jobs (I reserve work for its meaning in physical systems, jobs/career for you know), are ostensibly people problems. So the decisions I make are optimized for that. I don’t call it politically optimal, but optimal, because that’s it; that’s THE game of life.

It’s subtle language emphasis maybe, but I used to visualize my thoughts as a text stream and “rewrite” constructs I did not appreciate in the moment. Redefining ideas like “optimal” to be human first behavior. Ideas like “optimal technical solution” are boxed away for when I’m working.

It helped me understand managements drive, to have folks doing useful things, but also made me question how useful much of this is except as busy work.

Nice post, I think "software engineering" is slowly becoming yet another "bullshit job".