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 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.

In my experience (35+ years), it is the opposite now. It used to be massively top down, and now it is more and more bottom up, at least with the companies I have experience with.

I've certainly seen that shift in some places. 8 years ago I started on a project as a freelance software engineer, to build something they couldn't really envision yet. I had a ton of freedom, built a prototype, chose my own tech stack, designed every part of it. A team was built around it, and I migrated to a leadership role where I decided the direction, addressed issues I saw, redesigned parts that needed improvement. We had an enormous amount of freedom, and used it to build great things fast.

A bit over a year ago, I joined that same company again, as lead of what's technically the same team, this time as an employee, but everything had changed. It was very hierarchical, very top-down, very little freedom, lots of red tape and office politics, and a tedious, slow pace.

Every step up in my career has, ironically, lead to less autonomy.

Most of my career has been spent in JavaScript and then MuleSoft. I have only ever seen top-down authority in about 20 years of doing this, except for when I was at Travelocity early in my career.

The general perception is that JavaScript work in the corporate world is for young people who have no idea what they are doing and lack the maturity to write original solutions. This perception is common from developers who do other work, management, and developers who primarily perform JavaScript work. If I want to be creative or have autonomy to do anything more ambitious than putting text to screen I have to save it for personal side projects or do unrelated work.

MuleSoft work was just more of the same with all decisions funneled to strict silos of a select few and everybody else was just a keyboard pressing stooge.

Yes, that does sound dreadful, but what's worse is that it amplifies the personalities of people who will throw others under the bus for attention and potential rock stars who perform their most diligent work at hiding from that attention.

You can get to be a staff level engineer doing that. However, beware that to really make it up the corporate ladder, you actually have to reject that. Note that I didn't say reject doing the things assigned. I mean reject it as in you figure out the things that they should be assigning and get those done instead.

There are lots of different routes via staff and above level engineer. However, what they do have in common is working on really hard problems that take a lot of other people to work with. You will typically find your staff and higher level engineers rarely are actually writing code themselves. They are all management, but it's a technical management part.

The thing is, it's really hard to be there because management will constantly assign you various product-focused things and you end up being a widget. And so you have to figure out how to break out of that to say, no, this is the wrong widget and you have to show them that, look, I delivered this widget and when they see it, they should realize, wait, this guy was right. I assigned the wrong widget and he did it and so I need to trust this guy and give him more time to do things that give us the right widget.

Remember, the real goal is to make money for the company. As an engineer, you might say your salary is, say, $200,000 a year. But that is only a small part of it. For every dollar they spend on you, they need to spend $10 on other things to make it work. To pay your salary, you need to make not just enough product to bring enough to pay for your salary. You also have to pay for marketing, sales, product support, other managers, HR, and a bunch of other things I can't even think of off the top of my head. So the real question you should be asking is how do I earn, by actions I do, more than $2 million a year for my company. If you're earning your company $2 million a year as an engineer, they're breaking even on you at best, you should do widgets they trust will work. If they are earning $10 million, that's something that you should be putting on your resume and saying, look, this is why you need to give me a promotion. I am earning this $10 million every year. If you want to do even better than that, make it not $10 million that you're personally doing, but things that, because you're assigning other people to do them, are earning hundreds of millions. If you can earn the company hundreds of millions of dollars a year, you can justify a large salary for yourself, and you keep dozens of other engineers busy doing things.

Or you can take the lazy way out and just be a widget producing what they need you to do. That's good enough.

All anecdata here too but I agree. I’ve been in the industry long enough to remember when companies weren’t _all_ tech and us tech folks were considered specialists with a niche who charted their own course.

These days tech is indispensable to most businesses so top down control has been asserted.

I've had about the same level over the years. Early on, before I had a nest egg, I had little real autonomy, despite outward protestations top-down asking for risks and ideas. Afterward, maximizing average outcomes rather than worst-case risk, I've had a ton of career success either proposing and executing good ideas or else just ignoring the product roadmap when necessary to make the company better. I encourage my team to do the same (ideally they have to resort to subterfuge less than I did since I highly value bottom-up input, but either way is fine). It's, again, risky, but if you consistently deliver above expectations then in many environments you'll get more promotions and raises than you know what to do with, despite the lack of predictability.

Lately, product and my boss have been on board, so it's been fantastic to actually have partners to discuss these "risky" ideas with and better fit them into the roadmap rather than guarantee things which would get us all promoted will be shot down instead. I personally have more bottom-up autonomy than I think I've ever had at $WORK.

That's only anecdata. Another aspect of that tech microcosm is that at various points I explicitly did not have permission to do the right thing and had to be careful with the politics. It only worked out because I was right and because I was okay with the consequences if I had been wrong. Maybe that means I had low autonomy in your definition?

undefined

Its a good thing that the Author pointed out the caveat cause most companies/teams/people do not operate in this mode. Subtle in the details is a fact hidden that the author is able to manage what he wants to do, most people do not get that kind of luxury. This either means that the author has earned enough political reputation based on past work or they are aligned with their management chain.

tldr; this advice is probably impractical for a bigger chunk of industry.

This is my current world, at least. Bit of a shame. But they pay me well enough still and the work is interesting enough that I don’t mind too much.

I think it was correlated with outsourcing and H1B replacements, because you can’t outsource the leadership required for bottom-up methods.

Further, foreign business culture is significantly more too-down than American business culture.

I noticed what you describe 5 years ago.

Since then, not only have we lost autonomy, but there was no top-down direction to begin with. And there is none now.

Nobody knows what the next incentive to chase is, so they're liquidating headcount and engaging in fraud to appear profitable.

(re: fraud, I'm learning the hard way why my own employer's stock price dramatically improved-- ever since they switched to stack ranking, they just make shit up to PIP and deny severance ahead of layoffs.)

I think the autonomy was stripped not that long ago and it's making software products far worse.

It doesnt make sense that this would happen from an economic perspective at first glance - not unless you consider labor (devs), execs and investors to be three competing groups who are vying for power.

It depends on company culture, and there's as many of those as there are kinds of people. I've worked at large, medium, and small companies, in many industries, and there's no common pattern. The people in charge set the tone, and the people are all different.

If there's a pattern in the people, it's that more people in charge are less capable of doing the job, because they've grown up in a culture of ignorance. The past 10 years has been dominated by "StackOverflow Engineers" promoted to management, and people who read HN clickbait blog posts and believe it's good advice (it's not). They never had the time, training, or mentorship to learn from decades of experience. And Dunning-Kruger keeps them confident that they don't need to change.

However, on this point:

"the overall engineering autonomy has decreased over the years as the culture of tech has (in my opinion) shifted away from tech focus to more business, management, product focus with engineers just as the widgets who are tasked with fulfilling the goals of business, management, product"

That's exactly what engineers are supposed to do: listen to and enable the business. A mechanical engineer does not dictate the shape of the car. The designer tells the mechanical engineer what the car will look like. It's up to the engineer to make it work. However, it's also up to the engineer to tell the business that you can't fit a 600hp engine in a Mazda Miata without seriously affecting handling. It's supposed to be a two-way street. Good management/leadership knows this and enables it.

this

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 am doing exactly same thing of creating a solution which can be applied to multiple problems at the same time.

Sometimes coworkers does not like that because they don't see me working on the problem, but on a tool which will resolve the problem and similar problems from our backlog.

He says: That taught me to let potential problems pile up. Listening the way I do leaves me with far more of them than I could possibly solve, and not all deserve action. Most don’t need to turn into projects the first time I hear about them; waiting can be a superpower.

This is not distinct.

Even in a big corp there are always problems to solve. The point is to find problems that both:

1) are hard enough that someone junior won't be able to solve them alone, and

2) actually provide value to the company / users

It’s the same in a large corporate environment. I have a “personal projects” doc of ideas I’ve had to make development experiences better at my current role - it’s a couple hundred lines long.

I managed to get a couple of smaller tools out recently thanks to having copilot available to churn on them while I spend my time on prescribed work, but it would consume all of my time to even make a significant dent in it.

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?

I think that's a completely natural source of frustration for someone who is used to being able to put hands to keyboard and solve problems quickly, but IMO the higher you climb the ladder, the more you have the opportunity and responsibility to take a longer view and to delegate - which often means that other people are pushing the code.

Making life easier for yourself and your team is a big one for me, so I totally agree with you. Some times people don't complain about things they should be complaining about, because they don't know they can change them. I find that most big ticket items that unblock devs aren't code related but organizational which can in effect turn to coding issues.

Yes. My sweet spot is reporting to someone in the director levels.

You definitely need a technical leadership or leaders who understand the staff level value. You also need sponsorship. And you need to accept you maybe propose 5 things and only 1 gets funded and then 3 years later a previous proposal fits the zeitgeist and gets funded.

It depends on what you mean. There's lots of ways of looking at this, but I'd think of "entry level" as someone who is assigned individual tasks, and maybe needs help or oversight on completing them. Someone senior is assigned a project, or even a problem (and certainly has input on which projects they work on), and can handle the entire process of investigating, proposing, designing, and implementing the solution to that problem, which may involve oversight or tracking of other people.

Staff+ is additionally directly influencing which projects the org is prioritizing.

Thanks for letting me know; I cannot reproduce this myself on my mobile (it should be white text on a dark grey background) but I pushed a speculative fix which might improve things. Please let me know if it helps or, if not, I would love to know more details so I can fix this!

Thanks!

I spent the early part of my career (mid 2000s) working on a registration system for sports tournaments.

I had two jobs:

1. Writing the actual software for the registration website

2. Going to the events and managing the registration tent where people actually checked in

Doing 2 gave me a VASTLY better understanding of who the users were and how they thought. e.g. I assumed it would be tech savvy, organized people like me in their mid 20s. It was actually a mix of 40 something team dads who weren't tech savvy at all (b/c mid 2000s) but very organized and teenagers who were the opposite.

It meant effectively managing two completely different customer bases in the same product.

Coupled with the fact that cable modems were a new thing but not evenly distributed meant that we had to design the site accordingly.

At the time, I remember Joe Spolsky mentioning that at Microsoft they did two way mirror usability testing and it totally made sense. I wish more firms did that today.

This could easily be a blog. Multitasking using hermes takes skill

How do you deal with conflicting meetings? I stacked two jobs once before and ran into trouble with meeting conflicts.

Eh, it’s valuable advice to a lot of people. Titles are bullshit and all over the place, true, but “how to approach the changing responsibilities that come with growing out of the kind of roles you’re used to” is useful to people regardless of what the role is called.