1. If your manager has something in particular they want you to do, you should do it.
2. If your manager doesn't have something in particular they want you to do, you should figure out what they will want you to do in the future, and make any necessary preparations so that it will be doable when they want it.
I'd say it's good advice. The only thing I would add is that managers and leadership are sometimes happy to be given something different than what they asked for, so long as it's still what they wanted at a higher level. This is risky, but success can be a fast track to respect and autonomy.
This point seems obvious, but it's one topics I've had to coach many early career people on over and over again.
Many of the people who were having difficulties or heading toward PIP could be turned around by implementing a simple loop where they:
1. Ask their manager for the top priority, explicitly. Re-confirm the top priority every time you encounter a question about what to work on or new information that might change the situation.
2. Write it down. Put it somewhere visible. Check it every morning. Remind yourself about the top priority.
3. Do the top priority until it's done. Confirm that your manager agrees that it's done when you think it's done.
It sounds simple to those of us who internalized these loops early in our careers, but some people don't see it so clearly until it's laid out for them. They get distracted, go on side quests, take too many tasks from people who aren't their manager, or avoid their manager's requests in favor of a task they find more interesting.
> They get distracted, go on side quests, take too many tasks from people who aren't their manager, or avoid their manager's requests in favor of a task they find more interesting.
I had a great manager when I was fresh and I watched someone else on the team go down this path and succeed. I know now that the difference was that they knew what was going to bite us in 2 weeks/2 months, and that it was partially experience and partially they had info on where the project was going that I didn't. But had I looked at what they were doing and mimic'ed it, I would have failed.
One of the reasons companies get dysfunctional is low- & mid-tier managers seem to be allergic to the idea of laying out what the priorities are and provide feedback on whether people are working on them or not.
Great staff engineers actually set direction (which includes convincing management), instead of trying to coddle their managers. I particularly enjoy working with those - they’re rare findings (particularly in the usual American corporate culture)
If you have something prepared and then there’s a site speed, SEO, or series of bug complaints you might be able to pitch your minimal ideas as part of that solution.
I like the concept but I don’t know how well it would work in practice or how I would document my preparations for some point in the future. I do often wonder if I should run my work a bit like I run my blog though, generating documents about why and how. Maybe keeping them in wait for that opportunity.
That could be a lot of extra work that never sees the light, but we probably do a lot of that anyway?
I'm often convinced people extrapolate their insane luck with teams+companies and assume every other company/team can replicate their results. I have a hard time finding people in high level positions who give the slightest of fucks about engineering focused tasks but I am someone who works on product teams. The target goal is always about making money - not saving money or improving velocity.
Why would you want to do that? You will not get the cream for such work. From experience, you'll never get recognition for these things, you will never get paid more and most certainly they may dump more work at you.
Taking initiative and improving something never pays off to you.
Unless you are the type of person that looks out of the window at the company car park and sees board member in a branch new Lambo and then say to yourself proudly "I did that".
Don't do things those with more political power than you manager don't want done unless someone with even more power publicly tells you to. That doesn't mean you do what they want done but simply that you avoid pissing them off.
Enemies are rarely worth making and the majority of managers will throw you under the bus to save their own skin in that situation.
My experience is still fairly limited with this, but I do have some successes.
We need this feature, but before we can build this feature we need to make some changes to one or a few parts of the system. Otherwise we will be building on a bad foundation and fixing the foundation will be much more challenging after we have built on it.
1. Only do bare minimum. They key is to keep your manager unhappy, but not unhappy enough to fire you.
2. If there is nothing in particular to do, always spend time on things that will benefit you directly. For instance, upskill to find a better job, read, volunteer or even simply entertain yourself to keep mental health in check.
Before you do something, always ask yourself a question: am I paid enough to do this? Answer is almost always: No.
There’s no part of expecting people to hand you money that doesn’t obviously lead to your sole purpose being to please those people. Even if you’re a solo contractor you’re going to spend your time pleasing clients - sure, you can shed bad ones more easily than you can a bad manager, but you’re still beholden to someone who controls the purse. If you found a start up you’re pleasing your investors. If you’re a CEO of a large company you’re pleasing your board.
Work is just the act of pleasing other people in specific ways based on your skillset.
One time a manager hinted to me to be a snitch on my coworkers just so he could see I have “leader” attributes to get promoted later. Stay away from corps..
This isn’t a thread about your whole life.
Fuuuuck no. If he thinks you did it in 24 hours then he’ll expect you to do it in 24 hours next time too, instead of the three weeks it actually took you.
Work on something amazing. Also, who doesn’t have something to do???
Life is too short for stupid games
I've never seen two people fight to the death over something meaningless as much as some engineers do. Politics is the end product of multiple people working together with different views. Engineering doesn't save you from it. Engineers who think it does tend to cause more political turmoil in teams than anyone else.
I’ve found writing 1 pagers and technical documents that I can circulate, and then re-reference when there is a crisis is the way to have my ideas floating around at the time. I’ve had some success driving the architecture I want iteratively, slowly progressing towards my goals by building consensus but I’ve also been owned by VPs and directors that are much better at politics than I am. Having the library of 1 pagers, sending them around so they are latently in the air, and waiting for the impetus to execute on that idea has been much more successful.
One surprising thing I learned when I became a mid/upper manager: It's very easy to spot lower level employees playing politics.
Part of it is because most ICs or even 1st level EMs are overconfident in their ability to play politics. They commonly overestimate their own level of social/political intelligence relative to their managers.
The other part is that they just don't have as much insight and communication within the company. They think they're persuading or manipulating (depending on intentions) a certain stakeholder to form some alliance to push an agenda, but 5 minutes after that conversation that stakeholder sends a message back to their manager giving them a subtle heads up about the politicking going on. I can't count how many times we, as management, watched clumsy office politicking attempts play out while doing our best to gently keep them contained without bursting someone's bubble and making them angry.
Ya’ll are so much better at this it’s scary. I can’t really read when I’m being lied to in the moment, I usually naively believe that support I’m getting is because my ideas are good, or that management has the same view of the collective good that I do.
I spent a while in the marines as an enlisted man, lower NCO. There is no politics and people next to you have to trust each other with their lives. I never really made the turn to what the world is outside of that, I’ve always struggled with it.
I learned not to try. Ya’ll can do politics. I’ll write one pagers and wait for my chances to make things better.
In the source, the author says that when there is a crisis (an outage or similar) management will come to you and ask for help solving the problem and you should already have a solution ready to go. What I’ve found is that you should pre-seed your solutions with 1 pagers. Identify things that need to be improved, changes to solve tomorrow’s problems and just take the extra step of writing a 1 pager about it and circulate it. Then when the problem happens that your solution fixes, your fix is already there ready to be fully fleshed out.
i am guessing you never got promoted at work?
- Ship often to prod (don’t do theoretical work).
- Ship wins (as defined by generally acceptable metrics.)
- Have someone in management or a PM who is good at selling your wins
Even here, though, you will run into problems. There is always a new VP or leader looking to make an impact. Because you maintain the current systems your team is engaging in WrongThink and new VP has shiny new RightThink (AI, etc). As soon as your code hits prod you have “legacy” code.
New VP can make promises of future, theoretical riches that you can’t compete with, as you maintain the boring, current reality. Reality is not sexy or interesting. You’re in the old guard now.
A lot simply boils down to patronage. Making your higher up VP look successful and being in a position to move with them to their new company.
As a staff engineer, it's very important to make sure people know you are not the code. The code is just a liability - as you said, it's legacy the second it hits prod.
I've found its best to position yourself not as on the side of the "code" but as a EQUAL PARTNER to leadership/product/whoever has power. It's often just a framing problem, too! You can do nearly the exact same things as if you were the BOFH. But just positioning yourself so that leaders see you as an ally in shipping product and impact, vs someone they have to bully to get approvals from on "just building the damn product." Makes it night and day.
That sounds so utopian to me that it's practically ridiculous. Never in my 40+ years working in tech has any higher-up treated me or thought of me as anywhere near equal. I try to treat the people on my team that I manage as close to equal as I can, but the higher ups would really have zero compunction about "letting me go" in favor of the new hot whoever that someone introduced them to recently, or whatever. They very rarely listen to reason about any issue and it's rare that I'd even get to talk to them.
It's been like this at every startup and company I've ever worked for.
Looking back on my career, one of the single biggest changes I could have made to improve my success was escaping teams with bad PMs as fast as possible.
Great PMs improve everything, but they're hard to find. I spent too much time sticking around on teams where bad PMs were driving us in the wrong direction and failing to interface effectively with the rest of the management team. As soon as something changed that removed those PMs from the situation, everything improved.
And I mean it, it's a change like "going home at 5PM instead of crunching to deliver every other day".
The planning and the selling of the feature make rework much less necessary, plus you can work together and define tasks in a way that are more appropriate for the current software, rather than being stuck in a hamster wheel of changes that don't really push the product forward.
Add to that when a new/junior manager comes along, they're too busy trying to show everyone that they're the centre of the universe for any actual progress to be made.
Edits: typos and spellchecker being too smart so words injected that didn't make sense
> New VP can make promises of future, theoretical riches that you can’t compete with
Why is theoretical work advantageous to the VP when he does it but disadvantageous to you when you do it?
It’s not ideal to ship often IMO. How could someone ship something substantial in one day? I work on projects that generate the company additional revenue and if those projects took one day to complete they would fire me because they would really only need a software engineer for four days of the year.
It’s a vanity metric.
Like, as an engineer, I don’t doubt that this work is valuable. But you have to imagine what it must sound like from the perspective of a PM or EM. Itd be like my PM saying “I spent the last month organizing all eng docs to be properly formatted with bullet points.” You’d be like, uhh, okay, but how does that affect the rest of the company? More importantly, how does the PM distinguish engineers who are doing impactful work from the engineers who are doing the “bullet point formatting” work, of which surely some exist? From the perspective of a PM, these types of work can be hard to tell apart.
Really what you want to do is articulate what you plan to do, ahead of time, in a way that actually clicks for non-technical people. For instance, I was pushing unit tests and integration tests at my company for years but never found the political will to make them a priority. I tried and tried, but my manager just wouldn’t see it. Eventually, there was a really bad SEV, and I told her that tests would prevent this sort of thing from happening again. At that point the value became obvious. Now we have tests, and more importantly, everyone understands how valuable they are.
The easiest way to do that is to speak the same language everyone else is. Your product manager probably speaks in dollars (or euros, renminbi, etc). If you provide a good-faith estimate (ballpark ranges are totally fine) that increased test coverage or whatever your technical objective is will cost 200 dev hours, and save 400 dev hours on an annual basis, or reduce the rate of support tickets by 15%, or allow for X future business scenario to be supported or whatever, you'll generally have way better luck. My favorite "trick" is taking tech debt work, and framing it in a way so, not only do I not have to push for it as "tech work", but my PM will actually put it on the roadmap proactively because it just makes sense from a business perspective.
It also gets easier over time. You might get some skepticism at first, but if you have a history of delivering accurate estimates and results over months or years, you'll build trust with stakeholders such that what might've taken a round of meetings to convince them before, can now be a 10-minute conversation.
Saving money on the current product is only useful if the company has no clue where to go next. Since normally the current product will be gone in 2 years. It can be useful when your company is in long steady production, like a refinery where saving 0.5% would be huge.
This is something people often miss about dodgy code bases. Or about writing a large application in a weird choice for a language. IF you were able to deliver that application AND it's still profitable 5 years later, THEN already it was hugely successful. You can argue that it was not in the correct language and you are wrong because it was ALREADY hugely successful. Same for cleaning up the documentation.
If you're on a construction project and you, say, spend a bunch of time inspecting and maintaining the safety systems so that you prevent any accidents that seriously injure or kill someone, it's an all-too-common problem that management doesn't think you've done anything and doesn't reward the effort.
It's a huge failure of management that they don't seem to have any concept of benefits unless it can be quantified as ROI. And in the case where it truly is a life or death situation, I consider it a moral failure as well.
In fact, this scenario isn't even a stretch of the imagination. This is Boeing, right now.
If your managers think that, and don't understand the value of refactors, you've already lost. You can try explaining it to them, but if this is how they perceive that type of work, it's a sign that you're working at a company that doesn't understand software engineering.
Of course, new features have to be built, and bugs have to be fixed. Those are always priorities. But refactors are just as important for keeping the software in a maintainable state, precisely because they enable new features to be built faster, more efficiently, and in a more robust way.
It is one of career progression milestones for a programmer when they can set a bar for their craftsmanship themselves. Successful SWE is someone who got hired at a team which does not require this kind of education. A team where this type of engineering hygiene is obvious like breathing.
is true but may be irrelevant. Your hierarchy may have the correct understanding: that this better code base will be irrelevant because the company would then be out of business (because you spent your hours on the wrong obsession). Or will be irrelevant because this product line will change to use an entirely different protocol. Or this engineering group will be working on a different product and different code base. Etc.
I feel that it's fine to do small refactors when they help YOU understand the issue you are working on. Anything beyond that does NOT go without saying. Anything beyond that may well be hours you are wasting on a non-existent issue. In theory worthwhile but the company / your engineering group does not live in theory
Now, ideally, when you discuss refactoring with your manager, they have an understanding they can share - so you can understand. And this will make it easier for the individual contributor to work this way and not that way.
Absolutely none of those can be measured (hence intangible) which is why they are a hard sell
They can be estimated (with a wild range) and that's still useful: If that impact is clearly in the noise, drop it. If that impact is clearly huuuge then set up some ongoing measurements and get started step-wise and demonstrate results. If you think you need to rebuild the whole thing before seeing any results, you see the world in a way that won't happen (except if your business is not delivering solutions but is selling solutions - in which case carry on). That doesn't mean the ground idea is incorrect.
I shouldn't need to promote and sell my ideas to anyone. I'm paid to provide my skills and ideas, and if the people around me don't find them valuable, that's on them. I'd rather move on to places that do value them, than engage in politics.
> Some program of work will be funded whether you do this or not. However, if you don’t do this, you have no control over what that program is.
Why would I want control over that?
I share my technical opinion, and it's up to the team or higher-ups to decide which direction to go in. Besides, who says that my opinion is correct, anyway? It should be held to the same level of scrutiny as anyone else's.
This idea that engineers should constantly push for their ideas to be implemented, and to take on projects with the highest visibility, is incredibly toxic. It leads to a culture of obsession over KPIs, OKRs, and other pointless metrics, where people prioritize work that looks good on their record when it's time for a promotion, rather than doing work that has a positive impact on the product, no matter how small. It's all a theater, and I refuse to have any part in it.
I’m interested in hearing more about how you execute on this. Where/how do you keep your plans in wait?
The crucial mindset imo is that you're trying to do something that's already useful. At the time you write these things, you're probably more familiar with the topic at hand than anyone else in the company; try to leverage that into writing a document that someone else (or yourself in the future) can save time once they actually execute what you write by getting faster to the point where you're at right now. E.g. from the article, rewriting a js package structure in vite; think through implications and potential hurdles you already have a solution for.
They're useful in almost all outcomes. If they won't be executed, at least you know why (e.g. too complicated/effortful), and if they're executed, best case you can improve the company's offerings substantially.
One of them is: technical ability is actively detrimental to your power and career. You have to spend time and energy on actually doing things, and every competent manager will do their best to keep you right where you are, with as little political influence as possible.
Conversely, as a manager, so the book says, you want to avoid actually doing anything. You should start initiatives -as many as you can- and deftly use your political capital to either own, disown, or weaponize them. Whether they succeed in creating value is irrelevant, certainly not something you should focus on.
People focused on success and value of initiatives are still working hard when you have moved on. These people are hopelessly behind the scheming manager, eating crumbs.
And if necessary, you the manager just claim credit retroactively.
Engineers often can't tell the two apart, and have too much ego to not publicly and privately make their manager look bad.
Engineers have a hard task - building and maintaining code is a high focus activity, leaving no time for scheming. Meanwhile the non technical people have all the free time and use it wrongly on scheming.
With vibe coding, perhaps this dynamic can shift.
In the early days of the software industry there weren't these many non technical people running the show.
I appreciate the authors workarounds but shouldn't the larger question be whether this is the correct way to run a company?
This is basically my theory of how things get done in Washington. There's no grand plan most of the time, just an army of operatives ready with a slide deck to pitch when the conditions for an idea present themselves.
The people doing actual real work often have a much clearer picture of what's a good or bad idea. Meanwhile management, let alone owners, are looking to either
a) maximize short term profits (because they intend to be somewhere else by the time the bad decisions manifest)
or
b) create infinite growth from finite resources (but they still intend to sell when the peak is reached).
Customers, workers, management and owners have wildly different incentives. And only customers and workers have incentives that lead to long term prosperity - building value (indirectly) from natural resources and human time. Management and owners don't build anything, their incentives are redistributing the created value, ideally so as much as possible goes to them.
If that's how your workplace works, then find a new one.
Call me naive, but not all companies work like that. (Mine doesn't.)
Where I see a lot of folks fall down:
1. Focus on problems that aren't attached to either important issues: tabs vs spaces isn't gonna sink the company. If you start getting triggered about a technical thing and can't explain the impact in terms of availability, cost, productivity you'll quickly get tuned out. That isn't to say the work isn't important, it's just not workable at the political level, you just gotta fix it through influence with other IC's.
2. Inability to explain how the problem is attached to important issues: Similar to above, even if it's a real problem the ability to craft a narrative so the managers and other leaders can connect it up to real value that they'll see.
3. Discomfort with taking risks: No important problem / political problem is without risks / gaps, either in terms of timeline, impact, decision paralysis (as there are truly multiple ways to skin a cat). If you need 100% certainty to kick into gear it'll be hard to influence at the top levels as it often requires taking decisions and the inherent risks involved in signing up for those outcomes.
If I see a staff engineer consistently trying to latch onto company initiatives and strategy goals to get funding for their pet project, I would like to fire them
Why not try to actually solve the issues, and spend the politics budget on making sure people noticed? Even if you failed on the politics thing you've at least done something useful
High level engineers should be looking ahead and predicting what projects will be needed based on technical weak spots or market trends.
this involves you getting a chance to work on it in the first place. why would you in particular be getting to work on those projects?
you have to first align yourself with VP and become their bitch. someone who they can trust. you should always follow prison strategy of finding the biggest bully in the yard and becoming their bitch. only then you get to even sniff work thats important. don't even think that you will be given important projects if you show off your technical acumen and skills. that strategy usually backfires and puts a target on your back both from ur peers and superiors who now see you as a threat.
just remember ppl who got into managment positions have no technical skills anymore and are highly insecure of that fact. they will murder you if they even have a little bit of inkling that you are someone who is technically proficient that can drive projects with little help.
Jokes aside, congratulations on slipping and falling up the summit, collecting not a single bruise to your ego or soul along the way. I am genuinely happy for you.
> Only a crisis—actual or perceived—produces real change. When that crisis occurs, the actions that are taken depend on the ideas that are lying around. That, I believe, is our basic function: to develop alternatives to existing policies, to keep them alive and available until the politically impossible becomes politically inevitable.
I have confirmed that this is true, and a useful mental model to be successful in the world of start-ups, but also describes very well the opportunity seized by certain historic character of 1930s Europe.
You can play the game, but ask yourself if that’s the game you want to be playing. I’m wary of people who seem happy to make themselves slaves to money no matter the human cost.
"Scheming takes practice and power, and neither of those things are available to software engineers."
Most of us are terrible at scheming not only, not even primarily, because of a lack of practice. It is a lack a of information.
All the advice from the article assumes you know what the people above you really want. Reliable information about this is the precondition for blatant scheming as well as the subtle influencing the article promotes, yet is the hardest part to achieve. Make a mistake their and you'll actively hurt your career.
Hiding your real motives is a main part of politics and you should expect that anyone above you will do it to some degree. Navigating that well is simply not in the skill set of most technical peope who generally appreciate openness.
It’s also the same reason why MSFT doesn’t have a blockbuster AI product.
1. At work or for personal use, I use GPT-5 or Claude Code. I am forced to use Copilot because that has access to internal company data but it’s nowhere close to GPT-5 or Claude.
2. MSFT open sourced VS code but on its own couldn’t engineer products like Cursor or Windsurf. Lets leave aside the economics of these products for now.
The regular down in the trenches engineer like myself is so busy thinking about how I can advance my career by playing political games, currying favour with my manager or manager’s manager that little time gets spent on product building.
Good thing MSFT has all the cash in the world to invest in companies like OAI, GitHub etc because the bureaucracy is stifling at MSFT.
That said, it's often easier said than done. We've all worked at places where projects were canceled 3 months in due to all sorts of reasons (e.g. security breach changes all priorities, nobody cares about your database change now).
So I do think there comes a point where an engineer asks themselves -- "How many projects do I have to prepare, how many stakeholders do I have to convince, how many wins do I need before I see tangible benefits commensurate with my investment?" What if I just let the executives set the course and provide my insight if asked, and still get 90% of the pay.
Ultimately this is a guide to work successfully within a dysfunctional system, but nonetheless great advice for that.
I don't think engineers are universality bad/good at politics. It's just like anything else, takes practice.
It's rare to have a CEO that can decide things 100% by themselves and still retain talented employees. It's also super rare to have investors with zero desire to determine a company's direction.
Politics in standards bodies, industrial organisations, regulatory issues, funding and investment, etc
Becoming a career CEO might be a way out, though.
But of course, I still want my hut in the woods.
Point is my predecessors made things too complicated by chasing shiny things instead of using what is native in our environment to get the job done and simple maintenance
I have become very good at hitching my wagon to passing VP trains, it's sad, but it works.
Reminded me of Proverbs 22:29 "Have you seen a man skillful at his work? He will stand before kings; He will not stand before common men."
I like this truth. Talent is mostly a zero-sum game against your time. You can’t be great at playing politics unless you have the time in your role to focus on that, and software engineers are paid to be code mules.
I think ideas also need to mature in peoples minds. That can take a long time. And when the right timing comes, people might come back to your idea. Of course that will not always work.
I think ideas also need to mature in people's minds. That can take a long time. And when the right timing comes, people might come back to your idea.
Api is slow, api wasnt being gzipd, good snack, give snack to other eng, find more snack.
Oh look product doesnt have metric, get product the metric, now team look good because boss see what team do.
Oh, my sweet summer child. Do you really believe that I would be allowed to be able to make a high profile project successful? I literally have been sidelined of many high-profile projects were they failed in the precise way I said it would fail if continuing the path we were on which is caused by actively working to make it successful. Telling your boss they are wrong and why tend to not work when your boss already have an idea on its head about how it will work.
I’m sorry, WHAT? How old is this author? “I fail to communicate effectively with anyone who isn’t an engineer because I lack the required empathy and perspective” is very different from “the average stakeholder is stupid and dysfunctional”. I stopped reading at this point because author is clearly someone who doesn’t take responsibility for their own failures in communication.
Thus my interpretation is that those points are examples of the extreme, often false stereotypes people believe. They are the mistaken position against which the author is arguing.
politics at work isn't any different than any other politics. Its not a spl breed of politics thats more pure and noble.
succeeding at workplace politics requires the same skills of identifying who to suck up to, who to eliminate and who can be trampled over to get where you want.
