This sounds about right. At least I feel it acutely in my career. And the more experienced I got instead of more autonomy it has decreased. So to me it seems autonomy is decreasing at a rather fast clip.

Even outside projects and general work condition it is worse. 10 years back I could just decide when to work from home, or do a few interesting projects show to managers get approval afterwards. Today I have to explain myself to managers and get proper approvals for same thing. And I have been in same place for quite some time so it is not even the case that I have to prove to my new employers first.

Being not much ambitious I use to think after these many years and multiple successful project my win is to be a kind of made guy in that same mid-level position. Supporting , fixing project which I delivered over years and just take it easy, start day late, leave early until retirement.

Turns out things I assumed, don't exist. And even if they do they are above my level. Not worked in big tech, no massive RSU based compensation and with AI flattening difference (in employer's view ) between 2 vs 20 years of experience, story is not going to end great for people like me.

Without providing too much detail, at my current place of employment I find that to be the case.

In most of my career, especially when in a Staff role, it has been up to me to propose the direction and priority of work within my scope. Usually, this is based on my estimation of the impact to the business (possible new features, security) or operations (devx, efficiency $$$). Obviously I still have to work with product to get things scheduled as they have needs that must be met, but it was as an equal partner. As a very creative person thats usually the space I enjoy the most.

I'm sort of in this area, and I'm fighting the same struggles because I desire "productivity", not autonomy.

I asked my manager if I should be creating tickets for the work I'm coming up with, and he answered a question I didn't ask, saying he doesn't count sprint points. So I clarified, shouldn't I at least be creating tickets so that we're accounting for it in our sprint planning? And he didn't seem to care.

IMO, it's a 180 degree shift to go from trying to accomplish assigned work to creating new work and accomplishing (or delegating) it / adding it to roadmaps / etc. To me, it wasn't at all obvious that this was what I should be doing, so it was strange to sort of stumble upon it when asking an adjacent question.

It would have been very useful to get an explicit instruction such as "hey, only spend 1/4 of your time on planned work" or similar.

I'm sure there are plenty of people out there who spent their entire career trying to avoid doing assigned work so it's an easier transition, but for rule followers it's a weird change.

I agree with this and think that when your company isn't profitable and is running out of runway (due to the end of the zirp) and can't get more, moving toward features that more directly could land sales is a natural top-down move (and totally correct in the abstract).

However I still see a lot of "work theater" where directors couldn't care at all about changing the bottom line but just care that work that sounds plausible enough is executed in a predictable way that makes them look good (in fact they get pretty disappointed if something happens TOO fast [like half the estimate] as it illustrates they are out of touch the work they are claiming to represent). What I'm saying is that "do more top-down-product" in theory makes sense as a direction, but in practice I usually see it as wasted energy.

Exactly. Everywhere I've worked had at least 3-4X more bugs than we had capacity to fix, and the bug count grew over time, net of any fixing happening. There was never difficulty finding problems to solve. Unfortunately most places don't give engineering the autonomy to solve critical issues. It's just feature cram and redesigns, over and over, and let the bugs pile up.

There are a lot of known problems... but there are also a lot of unknown, or at least unrecognized problems. Some of those unrecognized problems are going to be more useful and higher-leverage than recognized problems. The same "being a sponge" approach still helps.

I think this is more relevant reality. At Staff and Principal you have visibility into a lot of fires going around you. What helps is understanding the relative importance of what fire to douse and be at peace with the ones that you cannot control.

You probably pivoted your career towards the startup space so you found it effortless. For others it is basically a castle with a 20m wall.

I suspect you might hear a lot of push back on this take, but I for one fully agree. I would go as far as to say that in my workplace, this a nearly inverse relationship between quality of work and how actively that person is thinking about / talking about / acting-as-if-they-are-owed a promotion.

yea this was the case even before ai. fighting for scope is 80% of the job now. Ppl like OP dont really need to "Act like a sponge" and figure out "problems to work on" if there is natural demand for stuff they are building work will present itself.

There is also crazy ladder climbing with all these titles and difference in payscale. So ppl like the author are trying to optimize what a role X is supposed to be doing. Everyone is just the same thing everywhere.

Everywhere you go its the same ppl, same ladder , same tools same sucking up to boss blah blah. Cant wait to get out of this shit.

Like you, I dislike the "talker" role for people on IC ladders. I often encourage those people to switch to Director+ roles.

The flip side is people who get and stay too far into the weeds. Solving little problems here and there is a great way to keep your finger on the pulse of what's actually going on.

But if you get totally bogged down in details, you are probably avoiding your leadership responsibilities. You should be observing the structural or strategic opportunities, and then dragging the org(s) in that direction.

Sometimes you do that by writing some code to prove a point, other times you do it by getting the nearest VP to take something on as a commitment. For me, personally, I find that the style of work waxes and wanes. Sometimes I get almost no code committed in a month :(. Other times, I get to go off and do some work that nobody else would have done.

I prefer the latter, but I respect that my job requires the former. Many of the people who you see spending all their time talking believe that's the most responsible use of their time. They might not personally prefer it!

I’ve experienced this. The critical realization for me was that most of those problems which I know I can solve quickly, without even having to write a Jira ticket or groom them into a sprint or whatever, are problems I should let someone else solve.

Sure, I can do them faster than others and pretty well. But if they’re truly things I can knock out in a day or two, they’re things that other staff can knock out in a week or two, and learn from the experience, and at that size they likely don’t require the standard of quality that I delude myself that I hold myself to.

At the lead/staff level, it’s far better to look for the kind of problems described in TFA: problems that are complex to identify, and for which the appropriate solutions aren’t always the obvious ones. My time is spent much better looking for those than being a 10x-speed senior engineer or whatever. There are actual senior engineers for that; I’m paid for the kind of work that they don’t or can’t do (yet, and to help model and mentor and train them to be able to do it), not to do the kind of work they already can do—whether I would do it faster/better doesn’t matter.

It’s case-by-case of course; sometimes a simple issue is critical or obscure enough (or tempting enough to override my iffy-at-best self-discipline) that I’ll jump on it. But I generally try to remember that a lot of the stuff I could look heroic for fixing in a jiffy is probably both not worth my salary allocation in the eyes of my grandboss, not critical time-wise, and a potential learning/accomplishment opportunity for others.

Once upon a time my grand-grand-boss explained that he had no problem hiring top-notch engineers - pick up the phone, call recruiters for new candidates, connect the incoming stream to the interview pipeline, two months later you get the requested quantity of engineers. OTOH there is no repeatable process to hire someone who will help identify the right problems and drive them to resolution. So if such person is found they will be pushed towards doing things that have no obvious success recipe and away from the things that do.

> I don’t like being the person who talks and talks but doesn’t push code and ship features

It was fun while it lasted, wasn’t it?

For non-engineering teams my playbook is:

1. Get in all their support or public slack channels, watch for acute moments of freak out or consistent schlep blindness. 2. Meet with the head of the team once a month for 45 mins and get them to list out what just sucks.

You can limit chit chat very well this way.

You’re only going to be able to do so much so broadly picking the problem that is closest to the business’s immediate pains can be a win. Or maybe that’s already being swarmed on so you knock out a bunch of random stuff and get broad recognition.

For technical teams, almost every single thing I ship:

1. cements a new pattern or contributes to a new one that my team can use 2. improves cicd speed or checks

You can usually knock out the non technical team work and pick off 1 from technical team work along the way

Everything I do (except specific bug fixes) force multiplies, otherwise I’m wasting my effort.

I don’t feel like I need to talk too much to my teammates about their engineering problems. I’m doing the same work ultimately, so I have a solid understanding of what moves the needle

Edit: convincing the organization that your work is important gets much much easier when you have metrics and charts that make the case for time well spent. It could be a buggy ass feature, or a meaty pipeline the business relies on. Prove that it’s hurting the customers and ultimately the bottom line. Battling over and convincing of scope becomes less important when you’re talking in the same language as non technicals

It’s a cop out, but depends on the company and it’s somewhere in between. Even with success-of-the-company as your compass, other stuff always matters. Good work done invisibly can’t be rewarded. Working on the lowest-profile projects is often interchangeable with working on the least important projects to the company. And if you are building credit with the wrong people, maybe you aren’t working on the right problems.

There’s obviously the dysfunctional form of all this, but it’s also rare that there’s one simple and obvious “do this thing and it’s best for the company and everyone will automatically understand what you did”