It seems like this post can be summarized as follows:
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.
> 1. If your manager has something in particular they want you to do, you should do it.
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.
I completely agree. I've foudn that skill never goes away no matter how far you get. The trick is as you go higher up, spotting what comes next and knowing how to solve it faster.
> 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.
This is it, pretty much. If you do your own thing and it works, then you'll come out well. If you do your own thing and it fails, you'll look bad, while if you do what yiu're asked you're going to be much safer. So if you go off-piste you should have some confidence it'll work.
> if you go off-piste you should have some confidence it’ll work
Just remember that the definition of “working” is in the eyes of your manager. Assuming they’re competent and not pointy haired boss, then they might have different goals and priorities to you. I’d you end up diverging from them, even if what you did is technically good and a good fit for the project, you’ll probably have a bad time.
Yes, you do still need to solve a problem that is considered a problem and at least around the same level of importance of whatever you were supposed to be working on, preferably greater.
> spotting what comes next and knowing how to solve it faster
This is such a strange mindset to me. Part of staff engineer is learning you don't need to solve tomorrow's problems. You solve it with the constraints you understand and leave room for expansion if needed.
Why do we have the opposite belief organizationally? And why as a manager would you want your top workers to be speculating about things you might want rather than achieving at the tasks you gave them?
It’s obviously way more nuanced than 2/3/5 lines of text on both sides but;
It’s not about speculating vs achieving what I’ve assigned them. It’s an over simplified example but if an engineer has two tasks to be completed that are dependent, it’s poor engineering for task A have to be re-done for task B to work (imagine an API that has ambiguity in the definition of done). A good engineer thinks just a little bit farther ahead.
At a staff+ level, 8: expect them to not only consider that but to consider “how likely is it what I’m going to have to re do this work” and scope accordingly, or to come to me and say “hey, every feature we add to service Alpha, we end up having to do XYZ to it, but with Beta we don’t”. They spend 10x more time than me writing code so they know that better than I do.
My team know my priorities, know what I value and know the areas I’m keeping an eye on. If one person is continually going on unhelpful tangents then that’s a single person issue to be handled with them directly.
YMMV with team sizes, team maturity, and where you are with your product dev.
That makes sense. I guess seeing the full lifecycle is always how I think about software I work on. I can do a better job of communicating that’s what I’m doing and why the approach I’m using (of doing less) actually helps us to be able to make changes.
In certain tribal societies, there is no "chieftan" per se, there is just the guy who happens to be correct about things more than everyone else, so his opinion gets the most weight.
As a former engineer who recently transitioned to management, this is precisely how engineers who are competent are perceived as underachieving. Focus on the right problems, put side quests on the back burner.
But how do you know what the management perception is of whiat is currently considered to be 'the right problem' vs 'side-quest'? To what extent is that subjective and manipulable? Or that everyone in the management chain is fighting to maximize their perceived contribution to the former and minize their perceived contribution to the latter?
Without knowing the context, it's impossible to tell whether the key word in your sentence is 'perceived' or 'achieving' or 'focus'. Or what set of people shape the perceptions. Or on what KPI. Or what if there aren't even clear metrics. Most engineers like working on designing things, not executive palace coups.
(Corollary: have you never seen a group or entire dept get sidelined by being assigned something that they're officially told is important but at some point is publicly/secretly determined not to be, at some murky point up their management chain? What happens when the Director, VP, CXO are changed, perhaps multiple times, in a project?)
> But how do you know what the management perception is of whiat is currently considered to be 'the right problem' vs 'side-quest'?
You ask.
A large number of the problems I helped people work through while mentoring came down to engineers get stuck in their own head instead of communicating.
Whenever it's not clear, you communicate. Many companies have this as a daily update ritual in standup, but some engineers treat standup like a game where they have to say the right thing to get it over with as quickly as possible before going back to their computer and forgetting what they said they were going to work on.
If ambiguity persists, it's a good idea to write a short e-mail to your manager saying you're working on X instead of Y or Z because you think that's what's best, but then finish by asking them to let you know quickly if you got it wrong.
> Corollary: have you never seen a group or entire dept get sidelined by being assigned something that they're officially told is important but at some point is publicly/secretly determined not to be
No, I have never worked at a company so dysfunctional that management will make secret decisions but forget to inform the company, or make public decisions and an entire department will ignore them.
I don't get it. What's the incentive for anyone to do this?
Though I have worked with some people who would go off on their own tangents, then when the consequences caught up with them they'd concoct excuses about how it was never communicated to them (despite us pointing to records in Slack where they acknowledged) or elaborate conspiracies about management coming up with secret changes or something.
You don't have to do anything. But as you say, they are the one in the position of power. If you are working on some side quest they don't see as valuable, it may not end well for you. Doubly so if you are shirking what they see as a high value task for your side quest.
It's not about what is right or who "should" do what, it's about securing the best outcome by making sure you and your manager have the same understanding, even if your manager isn't doing a good job of making sure you have the same understanding. (Also known as "managing upwards.")
Obviously the context is after you and other people have asked; multiple times. You should interpret my comment with that reasonable preamble. And obviously as you say when people are being ambiguous or not communicating well, you memo what was communicated in writing. But that doesn't cure all organizational ills, not by a country mile.
It's nice if in your sample size you've personally only ever come across management chains that were trustworthy, competent and aligned. It's nice if you've only ever seen one unambiguous flow of truthful information from the bottom to the top and vice versa, and everyone's aligned to cooperate. But the alternatives abound.
I've seen (or been told of) directors battling other directors on organizational priorities, senior managers quietly undermining and deposing VPs so they could take their jobs, EVPs of sales selling capabilities that their own engineering had been telling them could never ship, the sales-side of an organization having a totally different roadmap than engineering and feeding it to a (nontechnical) CEO who couldn't tell which was accurate; CEOs putting out press releases about fictitious component their engineering was telling them they would not be available. Managers cheerily suppressing showstopper issue reports to send "mostly green/96% done"-type status reports up the pipe, on a project they knew to be doomed, before they completed their company-sponsored MBA then promptly jumped ship to a rival, and the company failed. Board members hyping underwater stock internally, only to quietly step down and immediately dump all their stock now they were no longer designated as privileged insiders. (Remember: once you go public, there are disclosure requirements and possibly shareholder class-actions, so even when something's universally known internally to be an issue, often executives can't acknowledge that, even internally (think "audit trail"); although you can infer a lot from their actions.)
Also you're presumably aware of some company cultures where internal secrecy and internal competition are fostered, pitting departments against each other (or at absolute minimum, where cooperation between departments is heavily discouraged, or punished). Or, in the middle of a product development cycle suddenly launching a "partner collaboration" or "strategic acquisition", where that is misaligned or competes with internal groups. Fear, intentional ambiguity, conflicting priorities as a management tool. Often this stuff is indirect evidence of conflicts at VP-level or higher; sometimes it's culture or force-of-habit.
Nobody said "forget" to inform the company or "departments ignoring clear and unambiguous directives". I implied misinforming or misleading groups/depts, or maintaining strategic ambiguity about what priorities were.
> What's the incentive for anyone to do this?
All of the above happen regularly, and it's pretty obvious what size and structure or organizations, and what individual metrics for compensation, and in particular when metrics are intentionally designed to be in conflict. For example, in a large company once you define separate "business units", people are overtly now working to differing metrics.
"conspiracies" and "go off on tangents" is a pretty disparaging way to misinterpret my question. You've never heard of any of the above ever being intentionally deployed? And "dysfunctional" might be our shared opinion, but I've heard from board members that passionately believe companies should be incentivized like that.
There's a reason Software Anti-Patterns (both technical and management) were recognized to exist several decades ago. [0] I think you're merely saying you haven't personally encountered them much.
For sure there are some engineers who treat standup like an annoying interruption to real work, or can't be articulate; equally there are scrum meetings where people play points hero or points olympics in inflating their perceived velocity. I've seen some adept operators nurse a weak spot in their part of the product so it could get closed then quickly reopened multiple times for multiple different customers, making them look great, but no mention of refactoring or adding testcases, or explanations of whether the thing was incorrectly closed or underestimated previously. Agile is only as good as the people overseeing it and measuring; it's easily gamed.
Communication does not happen merely because you mandate a 15-minute daily(/weekly) team meeting and tell people to do it; it only happens when people's official or unofficial incentives are generally roughly aligned to facilitate it. It's much easier to do that in a 10-person shop all working on the same product than 10,000 people, multiple teams, multisite, multiple products, dendritic orgchart, etc. You haven't really focused on the "managing perceptions" aspect of my question at all. There are certain breeds of middle-manager whose careers thrive on going into problem depts of large companies and cultivating the perception of them as firefighters/powerpoint-warriors, whether that's decoupled from reality or not, before they move on before the success/fail outcome becomes apparent. Again, misaligned incentives, and works best at the interface above which management stops being technical. If you're inside the dept in question, you can actually see how much of the perceived performance is objective verifiable fact vs managed perception. Or to put it another way to you, you've never seen people who are roughly as good as each other, yet one is more adept at managing perceptions?
It helps us gauge your personal experience if you tell us what size of team and organization and company stage (early starup/late-stage startup/small/large public company/etc.) you're anecdotally referring to.
> But how do you know what the management perception is of whiat is currently considered to be 'the right problem'
Ask! Literally. But also listen.
Many people in management will repeat over and over that feature X is the thing they wake up thinking about, even though feature Y is important to the PM or director or whatever. Especially if you’re young enough that promotions and performance reviewed are really important for career growth, work on X not Y.
If your manager doesn’t start every meeting with some passive remark that project X is consuming their time, ask them what is important. Ask them what project they’re worried about.
Example:
“Hey Boss, I’ve been working on ProjY, but I also have tasks from ProjX pulled into this sprint. Which one is a bigger priority for the team, because I have 10 days of tasks, but only 1 week left in the sprint?”
… “hi boss, a week ago you told me to prioritize finishing X and not Y. Should I just allocate all of this sprint to the next set of tasks for X?”
… “hi boss. It’s me again asking this question every week “
If you want a good performance review/promotion/etc, usually that starts with your direct manager, so do what they think is important and ignore the rest. You need their trust first, so get it by working on their priorities. With their trust, you can get flashier or more fun work, or you can get them to trust you when you suggest alternative priorities, and you can earn the gossip/news they hear in management meetings from up the chain.
Your corollary is just rage-bait FUD or dysfunctional behavior. Any you can’t control it anyways so ignore it and focus on what matters that you can control. If your CXO doesn’t like what you’re working on, but your manager does, pick your manager, they actually write your performance review.
Although we should notice the other side of that - managers that don't have an explicit onboarding where they lay that algorithm out for their reports are doing a terrible job. It is literally 3 lines. Lay it out at least once. Maybe go through it in a standup once a year. They are letting people slip through the cracks to the point where we have junior and even mid software engineers that don't realise there are priorities and that they should be working on them. Wow.
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.
> 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.
Have you considered the possibility this is not a result of incompetence, but intentional? If these things are never clearly communicated and, more importantly, put in writing, management can just reframe what was agreed upon as best suits them later to deflect any blame if things go sideways. This is a perfectly rational move, since they hold all the power to do so.
I think a lot of what is wrong with this discussion is that people implicitly assume management is honest and communicates openly and sincerely. This is sadly only true in a small fraction of cases, likely because the incentives point squarely in the opposite direction: those who judge the game are always better off cheating.
exactly. my last job the project i was working on suddenly became "my project" where manager wanted to "give me a win" by shipping. it became my project when we discovered all the way in the end that what he had come up with isn't viable at all. thing i was telling from the get go but he didn't listen and adamant that it would be fine.
we even had it in writing the i had objected to his scheme and that he overrode it but that document was completely hidden from upper managment.
The simpler version is "Actually deliver on what you're asked to do".
It sounds so simple that people get offended when you say that. Yet it's at the root of a lot of employee performance problems where the employee is doing a lot of activity, but not delivering on expectations.
I've worked with some brilliant engineers who failed because they were always off trying to reinvent the wheel with their own completely unnecessary framework or rewriting some code that didn't need to be touched. In each case their managers were practically begging them to just focus on delivering the tasks they were assigned, but they were still surprised when the performance management actions came along.
It’s good advice for the average engineer who wants to chug along. Not exactly anything that would classify as “influence” though.
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)
I read number 2 more as being ready with your own agenda items. For example, if you want to make a code base more minimal, have a POC and some details worked out for when the opportunity presents itself.
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?
To flesh out things to where you could actually make a reasonable pitch with things like realistic time estimates and documents that would be useful to read then you'd have to have already done it, it'd be trivial, or you apparently have plenty of spare time to do serious spikes in your day to day. You'd also have to have the spare time to update these project ideas as the months pass, the product and codebase changes, etc.
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.
> if you want to make a code base more minimal, have a POC and some details worked out for when the opportunity presents itself.
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".
And this is the reason that at one point, Google has 4 different messaging apps and presented 3 at one presentation. No one gets promoted by improving an existing service
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.
I'll add that all this goes up the food chain and is good advice for engineering managers too. As a director reporting to the CTO I tried to do this as well.
I lean towards telling your manager what they should want. Put issues that you identify as important on the table and draw attention to them. Explain why they're important. Make them benefit from your expertise by being proactive about this sort of thing.
My experience is still fairly limited with this, but I do have some successes.
Strongly agree. Our expertise is why we are there, when I tell my managers that something is important, they listen.
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.
If you are not a shareholder, then it is an incredibly poor advice.
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.
This makes for a pithy sound bite, but that’s pretty much only possible if you’re independently wealthy to the point of being in the “fuck you money” category of wealth.
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.
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.
IMO, the people who need to be pleased are the customers, and, IME, management's expectations very often run contrary to those of the customers.
Turns out that anagement really doesn't like negative feedback from engineers which turns out to be echoed by users. I'd rather see career advice on how to prevent management from tanking the company without causing them to resent the engineer(s).
The alternate strategy is loyalty to "the business" rather than any particular person.
When you're invested in the success of the business above all else, and you make that known, you'll carve out a position where you're valued.
Not because you went on a "carving out your importance" mission, but because your energy goes into your work, and the details and care for the long term business objectives. Also... you can then enjoy yourself more, which opens creativity which opens innovation. Sometimes this might mean disagreeing with managers or working on stuff nobody really knows you're working on right now.
> "So if you want to get something technical done in a tech company, you ought to wait for the appropriate wave"
No. That doesn't work. You have to start building it. Don't wait.
I agree with this. That's been my take throughput my pretty long career and was a recipe for success.
You still need to:
1. Be good at what you do.
2. Be good at politics/communication when that's needed.
3. Be in an organization that has good people and also cares. There are organizations where there's just a complete disconnect from the business for various reasons. Dysfunctional.
This is a good strategy, imo. I was following it for almost a year and I was having a blast working in a startup. Then a new manager came along and started to dictate how things should be done without much input from the technical team. I kept fighting for what I thought was good for the product instead of aligning with him. In the end it was just too stressful (the manager was not only an idiot but also rude). I resigned, but I wouldn't have done any other way. I simply can't be made to do dumb things from uncurious people.
It's a shame when resigning is the only way out. Before reaching that point, the usual strategies should be attempted:
Picking your battles;
Negotiate rather than fight;
Be better at analytics and research than anyone else. So you have the data to measure or predict success about a particular feature or direction.
Armed with your data, you must carefully communicate findings without shaming others.
It's a fine line between fostering a positive work environment in the face of misguided decisions, and being condescending or derisive towards other team members. There is no silver bullet, but a touch of self-deprecating humour never hurt. If you advice isn't taken, you'll have a non-snarky receipt. Any email written with an irritated tone, will look twice as bad months later.
I did create benchmarks and simulated impact following different scenarios (including the one I was advocating for). Unfortunately that was received in deaf ears. Even worse, actually; they thought I was being too pushy by adding the scenario I was proposing to the analysis. At this point I knew I had to leave.
you should do everything possible to make a career in a small company. after three decades as SWE it is my #1 (there is not even remotely close #2) advise for everyone in the early stages of their career
I am 51. I love small companies. My second best experience was working as the second technical hire by a then new to the company CTO who was hired to bring technical leadership into the company. The two non technical brothers who were founders outsourced the development to a consulting company until they found product market fit.
But I still did the same thing the article and commenters suggested. I stayed strictly aligned with what the CTO wanted and just from that, I was able to guide the entire technical architecture of the company for two years even though I had no hands on experience with AWS.
Let’s not be fooled though. My next job after that startup that had 60 people was at the second largest employer in the US - AWS working in the consulting division (AWS Professional Services).
It was an immediate 50% bump in pay. An even greater contrast is that an intern I mentored got a return offer at 22 in 2022 that was the same I made at 46 in 2020. They are now at 25 making slightly more than I’m making at a medium size third party consulting company working full time as a staff consultant.
Your principled stand is leaving a lot of money on the table.
At 51, I would rather get a daily anal probe with a cactus than ever work at any large company again and I have turned down a position that was going to be created for me at another large well known non technical company where a former coworker was a director and ignored overtures from GCP in their professional services department that would pay a lot more.
I also wouldn’t like the company I work at now with around 700 people if I weren’t brought in as a staff engineer where I have almost complete autonomy on how I lead my projects and the ear of the CxOs
But let’s not pretend the extra $75K to $100K+ I could be making isn’t worth playing politics. I’m just at a place in life where I can prioritize other things than money.
Also, at 51, I’ve learned a few things. Not to make your “career” at any company and to always be prepared to jump ship when the environment changes or the raises don’t keep up with the market. I’m now on my 10th job.
not everything in the career is about money, your entire post is related to compensation which is also core reason why many people in the industry endure fucked up place to make an extra few bucks. there is a much better path in the industry that isn't built around "jumping ships" and chasing every dollar there is to chase. and that path is much better for your long-term physical and mental health as well everything else that surrounds your life, especially in the years that matter, when you are young and full of life in the late 20's, 30's and 40's. having stress-free life in your 30's and 40's (coupled with normal working hours etc...) beats the hell out of having financial freedom in your 50's
I work for one reason - to exchange labor for money to support my addiction to food and shelter. There is no higher calling.
If I were 22 post 2010, instead of 1996, you damn well better be believe I would have been “grinding leetcode to get into a FAANG” instead of wallowing in enterprise dev making what a returning intern makes at BigTech.
I’m not bitter, by 2012 I was 38, recently remarried and wasn’t about to uproot my (step)kids. But by youngest graduated from high school in May 2020 and I had an offer from BigTech June of 2020.
I definitely encourage any younger developer to play the game.
As far as jumping ship, if my goal is to exchange labor for money, why wouldn’t I exchange the most money for my labor given my other priorities? Instead of letting a company pay me less than market value or even worse what they pay someone coming in at my level.
Besides, I had my first house built in 2002 for $175K when I was making $65K and had no student loans. Neither is true for most students graduating today.
And it’s copium thinking that people at BigTech making 50%+ more at every level work that much harder than an enterprise CRUD developer doing Java at a bank.
I’m not advocating someone works 70 hours a week at a startup getting underpaid with the promise of “equity” that will statistically be worthless. I am advocating they get paid in cash and/or RSUs and immediately sell as soon as they vest and diversify.
And next year will be my 30th year working, I’ve never experienced burn out because I exercise my agency to say “no” to being overworked knowing I could get another job worse case and continue exchanging my labor for money and stay housed and fed.
I don’t know if it’s different, but I always carve out about a day a week to work on “skunkworks” projects that will benefit my team but that nobody has asked for yet. Then, when it does get asked for, I have a rough solution ready to go.
I would swear by this when I started working in IT, but 3y later I changed job and took a gig at a big corporation. It was eye opening and jaw dropping. Everything was lightyears ahead in terms of tech, management, money, investments in people, and much more compared to the small company. It geniuinely made me mad for not doing this sooner.
Strange, I've had the opposite experience: I've mostly worked with small startups and every few job changes will try a go at a big tech company. I'm always shocked at the gap in talent between small startups and large tech companies. Far and away all of the best and most talented coworkers I've had have been at small startups.
Of course there's a lot of variance among small companies (much moreso than large ones). But the one thing that all small companies have is people who can actually get shit done not matter what it requires. The amount of "not my lane" nonsense that occupies corporate life is both exhausting and boring. I understand why this exists for practical reasons, but it's no fun.
It's SO different. It doesn't guarantee that life is good, but politics plays a much smaller role, especially at the very small sizes. If you're objectively awesome, the chances of you being sidelined for political reasons is pretty low when there are like 10 people in the whole company. It's just obvious to everyone who is delivering value and who is not.
Conversely, if you're mediocre, there's nowhere to hide.
Or maybe instead of saying there aren't politics at small companies, it's more accurate to say that there are politics, but they're simple--everyone strives to make the (hopefully benevolent) dictator, I mean founder, happy. If your founder is awesome, life is good. If your founder is not awesome, well, everyone is going to have a bad time anyway.
> but politics plays a much smaller role, especially at the very small sizes.
I thoroughly believed this after working at a small company with little politics in one of my first jobs.
But then a couple of the later small companies/startups I worked for had politics to such an insane degree that I no longer believe small companies are better or worse in general. They just have a larger variance.
The larger the company, the more the workforce trends toward the mean. When you hire 10,000 people you can't exclusively build a company of low-politics people.
With a 10-person company you technically can build that company of mostyl 1-in-100 employees who work well together. However, you could also stumble into a company where you're working with 10 people who have worked together previously and have no intention of bringing you into their inner circle. The politics at this latter type of company is truly next level hell because there's nowhere to go, unlike at a big company or FAANG where you can transfer teams or rely on your resume to get you into the application process at another company easily.
> It's just obvious to everyone who is delivering value and who is not.
In my experience at highly political small companies, this doesn't matter. The people running the political show want the upper echelon of the company to be composed of their close friends and allies. They want the people who produce to be stuck doing the grunt work.
This does not align with my experience at small tech companies at all, and I've worked an many.
But the flavor of the politics is very different. At a small company as an IC you will very likely be working directly with multiple C-levels, often providing important context between them. A senior IC will need to be reaching out pretty actively across teams to make sure things are happening and you'll quickly build an internal network of "good people who get shit done fast".
Politics can seem no existent because in some cases just getting along well with leadership can be enough to make your life very easy. But you'll see how truly political these situations are if you have the opposite situation: someone in leadership just doesn't like you. One bad relationship can ruin you in a small company.
In a large company it's not too hard to just keep your head down (at least as an IC) and largely let your manager worry about politics. For managers it can seem more political because typically the "be friends with leadership" doesn't work because the hierarchy is both broader and deeper.
Thanks for the thoughtful reply. I agree with all that and I think I was trying to say something similar with my last paragraph.
I’ve gotten along with _almost_ every person I’ve worked with, including some pretty challenging personalities. I’ve always done very well at my job duties and gone “above and beyond” regularly. The only times I felt that might not be nearly enough, was at the two large companies I’ve worked at. Someone several levels away from me, that I would never meet, would decide whether I got a promotion or a raise or a juicy new assignment based on a game of organizational telephone. Frankly, when I tried I did pretty well at that game, but it was the first time in my career that I was tempted to do something out of cynical self ambition or winning rewards for my team instead of just trying to do the right thing for the customer or the business.
That’s what I think of when I hear “politics” and why, by comparison, it felt to me like at a small enough scale it’s not a thing. But if politics means needing leadership to like and appreciate you, then yeah absolutely, that is true anywhere there’s even one level of hierarchy.
I do think this could be true. Your productivity is way more visible in a small company, execs actually know what you’re working on maybe from day-to-day and most definitely week-to-week. Slackers don’t last long and mediocre developers standout, now why they might be perceived as mediocre is another discussion. My first job was at a big corporation (~150,000 employees) and honestly I saw so much politics and fiefdoms and just generally low quality developers not doing much but they could sneak under the radar because they’re a small cog in the apparatus. My next company (~50-60 employees) the devs were definitely better and way more productive, but it also felt very performative/showy environment of what devs did every what and if you were perceived as not doing enough you definitely stood out. It was a very public, perhaps stressful, work environment with demos every 2 weeks.
I’ve mostly worked at small startups in my 30 year career, and been fortunate to work mostly with excellent founders and teams. Certainly that experience colors my convictions, as your experience colors yours.
Massively different. You generally have more autonomy, fewer managers, more responsibility and wear more hats. In my experience no corporate fake people pleasing or PR language or HR nonsense. Just regular people talking normally trying to get stuff done.
Wildly different. One of the biggest things at a small company is that you can wear multiple hats to solve a problem and not step on anyone's toes. Need to play PM, backend engineer and data scientist to get a product shipped fast? No problem, and you'll be seen as a person who can get things done by leadership (if you make sure to keep your work visible).
The main divide I've seen between what makes people happy in one or the other style tech company is whether they really enjoy solving problems or doing their job. If you want to check in, do only what is technically required of you and get out, then big tech corp is for you. If you are mainly interested in finding solutions to problems and you are happy to employ whatever is necessary to do so, you'll have more enjoy small companies much more.
No matter what founders and managers say the reality is that 95% of tech jobs are meaningless outside the capitalistic flywheel. You're not making the world a better place. You're moving some bits around and extracting a profit from it. Pleasing a manager or pleasing the capitalistic flywheel doesn't seem much different to me.
“You lack soft skills and initiative; unfortunately, you will not be promoted while having more responsibilities” - the manager who wants to be pleased.
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..
It doesn’t have to be your some purpose; it could be within your normal working hours. It’s basically just choosing a goal to be intentional with at work.
Or better options - just do the job you were hired for and go home or find that rare job (if possible) where engineering has a bigger role than politics. It is not pleasant to play a guessing game trying to please some manager, just because they’re your boss.
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.
If you think corporate politics is just a stupid game you'll never be happy with what you accomplish and lucky to keep your job. Awareness and understanding, being able to tie effort to outcomes, positioning and sales; these are not guessing games.
Make your manager's manager look good. Because only then you would be able to go up the food chain (assuming that is the goal. your manager may become your competitor/peer in this case).
>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.
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???
One of my favorite quotes: “ 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.” - Milton Friedman
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.
> but I’ve also been owned by VPs and directors that are much better at politics than I am.
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.
I’m dumb about it. I don’t have a scheme, I don’t have a hidden agenda, I don’t have ulterior motives… I’ve got what I think is great engineering (divorced from what the customer or business wants in the short term) and I just diligently try to make that happen. I’ve been doing this a long time and I’ve always got the long term health of the system (and fairness to the workers next to me
) in mind. I say the same thing to everyone, I’m open and honest, and I get wrecked every time I try to execute any strategy that doesn’t accidentally align with something a VP wants.
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.
Working with naive people is such a relief. They never surprise you with some f-ed up shenanigans just to make themselves look good, and they are worth their weight in gold. I try to be naive myself as well. But reality is political in the end.
I do the politics I think are necessary, but otherwise stay in my bubbles of naive, trusting and kind people I have stumbled upon.
I like the quote and I think this can work. The problem is the timescales can drive you crazy. The other problem is sometimes crisis is ignored, i.e. there is a crisis but it's not acknowledged or is somehow otherwise normalized.
Send them to coworkers. I've had success with the same strategy. There are three important parts required to make this work though:
1) Have a reputation solid enough that people are willing to take the time to read what you send them.
2) Read the room and write ideas/proposals on topics that are of interest and are relevant to the organization.
3) Find an audience that can provide meaningful support (basically, people with clout)
They helped my ideas be “lying around” and picked from when the crisis happened.
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.
Absolutely! I thought this was inherent in the Staff Engineer position in the first place, so was sort of surprised it needed to be stated in the article.
Man, I must not have worked at dysfunctional enough companies. I can't relate to the opening remarks in this article at all. I'm used to really open communication from the top down and, even when we build in a direction I disagree with, we've discussed things enough that I'm at least interested in seeing why someone else I consider intelligent sees the world so differently. Perhaps it has to do with only working for companies founded by engineers rather than product/marketing? I'm not really sure.
Big American corporations (and to lesser extent, other countries that try to mimic US corporate culture) operate in a particularly dysfunctional ways. There’s ample literature on it (moral mazes, bullshit jobs and five dysfunctions of a team are particularly good books on the topic). You’re lucky to not have been a victim of that system!
I have seen how some big european and asian companies operate and every dysfunction which you can point out in an american corp is usually way worse there. Plus there’s some additional ones due to local customs
Different dystopias, for sure. The average Japanese big corporation values work hours way more than the average American one, for instance. In my experience in Germany and Switzerland, the corporate moral maze is definitely not as bad as the American one. Pick your poison, I suppose
I suppose that's because higher level VPs at large companies have broad goals and even broader notion means. It is not necessarily bad - allows to fiddle with different approaches before locking in on a specific technique. Wasteful? Yes. Efficient at satisfying board mandates informed by real time tectonic shifts in the industry? Also yes.
Yeah, it's definitely miserable, but unfortunately frequently those larger companies pay a lot more, so there's the trade off. Kind of selling your soul.
I dunno, maybe? It's tough to compare alternate realities. I had equity in the company that paid out well, had a base over 200k, 30% EOY bonus, was leading a team of 6, fully remote work, no on-call. Certainly there are areas I'm weaker in than I would be if I worked in a FAANG-style corporation (only doing minor work with microservices, not doing much with distributed computing), but the job was quite different than what I did when I was first hired out of college.
Frankly, I felt mentally and socially challenged enough while also being compensated more than fairly. If that means I've got a junior role while also avoiding toxic large-scale organizational dysfunction then I'm down to make that trade-off every day.
- 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.
I think you're absolutely correct and I think it goes one step higher level too.
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.
>its best to position yourself not as on the side of the "code" but as a EQUAL PARTNER to leadership/product/whoever has power.
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.
> - Have someone in management or a PM who is good at selling your wins
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.
Totally agree. Having good PMs (and good designers) is indeed life changing.
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.
This is why I almost gave up SWE. My skills, abilities, and output had little to nothing to do with my career trajectory, it's only about getting higher ups to sing praises about things that I might not have even done.
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
> it's only about getting higher ups to sing praises about things that I might not have even done.
If a company is so broken that promotions are decided based on factually incorrect information, there's nothing to do other than escape to a different company.
I'm talking about companies that are functioning okay, but they let the PMs drive what the team works on. A bad PM will send the entire team in the wrong direction and waste your time.
In the most extreme example, our PM would get distracted from the goals set by management and want us to do side quests all the time, so the entire team was constantly producing things that management didn't want while missing all of the things they wanted us to do. If your PM is the link between management and the team's directions, a bad PM will sink the team.
> If a company is so broken that promotions are decided based on factually incorrect information, there's nothing to do other than escape to a different company.
To me, this means that every traditionally run company (top-down) must be broken by construction. And indeed, I have never seen or heard of truly fact-based management.
The entire challenge with multi-level management is that you always play a long game of telephone with increasingly less technical people, which are unable (due to lack of time and understanding) to grasp the ground-truth facts without simplification. Thus, management based on hard facts is impossible in this setting, though it is a great theoretical ideal many aspire to.
In practice, doing so is very hard and people are lazy, so the "facts" can become so twisted as to be entirely unrecognizable.
If everywhere you look stinks, it's time to look under your own shoe.
No company is perfect, no team is perfect, no person magically knows what's right to do and has a perfect vision. Even if you get somewhere with the right team, right vision and right priorities, and you stick with them, the world will change and one of those will end up incorrect.
I liked how you phrased that: "promises of future … you can't compete with". That happens so often, and strangely the argument that those promises have never become real the previous 26 times never works. The glorious future sure is amazing!
What would it look like if you were a staff software engineer whose job description didn't include theoretical work, but whose output consisted almost entirely of theoretical work?
That's not an issue of losing political battles, that's an issue of you getting fired very rapidly.
This advice is entirely premised on the idea that you can choose to do theoretical work if you want to, but that it will be a bad idea.
I have never heard of theoretical work but I have heard of shipping every day. I don’t know how often you think is often. But in other places I know people are shipping every day.
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.
This could not be more true, however the id like to add the patronage goes farther up the chain. They are all just saying want they need to to clear the checks. It an executive has ever actually invented a successful business model I have yet to meet one.
Oh they have invented a successful business model, it's just that it's successful for those in executive positions. The whole C-suite mentality is as successful for execs as it is cancerous for everyone else.
A lot of the frustration I typically hear in this camp is something like “well I shipped a huge refactor that cleaned up all the code, why does no one appreciate that?” One particular interaction that got me thinking was a few years ago listening to an acquaintance telling me how he spent months meticulously cleaning up the data pipeline and making it perfect, and how no one appreciated this work.
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.
I agree! You have to also remember that, if you're the person pushing for something to be priority, it's your job to make it make sense to whoever is responsible for prioritization.
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.
Sure except that "saving money" is not what makes a company win, and so it's rightly not what makes a career. If you can show that building that new library for $X will streamline engineering by Y% which will allow doubling sales by launching 3 new products - NOW you have a good proposition. (Your "X future business scenario").
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.
I don't disagree, but I'm not sure if you meant to reply to my comment? I didn't make any references to saving money; the point I'm making is that spending 10 hours this week in order to have 10 additional hours of capacity (ability to build out new features tied to revenue) every month is often a bargain that makes sense.
In the context of full-time engineers, "saving time" actually means that time will be reinvested into product feature development, rather than resulting in less spending on engineering pay. Similarly, engineers spending less time on support, means they can spend more time on feature development.
And I argue that this is rarely the right perspective. It's 200 hours NOW - and that the company doesn't have budget for. In order to save 400 hours maybe perhaps, if the stars align, two years from now. It's not the same budget. It's not the same time frame. It's not your dept's responsibility. In theory yes maybe but in most businesses, no. These 200 hours now are an investment. This 400 hours maybe perhaps are savings, not profit. They may allow an equivalent 400 hours spent on some profitable new product - but then just ask for budget for the profitable new product, don't worry about where that money comes from. That's sooo far above your pay grade, it's not even funny. If the idea for where to spend the 400 hours is worthwhile, the chairman will raise money to do it. Bring THAT idea to management. THAT would be well received.
In summary: the savings and the new product don't come from the same bits of the balance sheets. They don't affect the future company the same. The wasted 400 hours are already considered in the estimates for the next few years, they are essentially already amortized. They already don't matter. It's not fun for an individual engineer to consider that their work for the next 3 years is financially already long forgotten, lol (?), but basically yes.
It MAY be the right perspective for several levels of management higher up, if people are REALLY working on a 40 year perspective for, I don't know, a mainstream database package, a compiler. But nobody does (in first approximation).
It's also is a good viewpoint where crazy thin differences do make an impact (a refinery).
Still: Most companies that don't plan to be gone in two years do have a methods department or working group. People who do try and make the processes better. They have budget to do that. Bring the idea to them. Hell, even start working part or full time on their budget. But with the understanding that this is yet another group, mission, budget. It's not 200 hours here in exchange for 400 there. And this is a highly technical group - not CXO track except perhaps for a brief stint there.
Although I agree with this, I can also think of a counter example by analogy.
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.
Yep, maybe i am destined to never make staff but I absolutely loathe that everything must be tied to some company wide target metric that moves in a quarter or it is invisible.
Many things that are worthwhile and that companies absolutely should be doing are not easily measured on a quarterly timeline.
I think what you're describing is communicating the value in terms that the audience understands and appreciates. This is really a sales skill and most developers have little experience or recognize it as such. A good manager can help here, and I agree that a strongly aligned staff dev and engineering manager can accomplish a lot. That's been my experience and I'm always grateful for devs who work this way too.
> 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.”
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.
Think chefs at top restaurants for example: washing hands is something obvious, no need to get any customer infected with fecal bacteria in order to convince the restaurant management for investing into soap (hygiene takes time, you could serve additional customer!)
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.
Im actually curious what happens in a professional kitchen when someone isnt pulling weight on menial tasks like scrubbing or batch prep. I know what usually happens in software teams - nothing
Having worked in professional kitchens, my experience is that nothing predictable happens.
It depends not just on management, but also on the personal relationship between management and the person, and on how bad the current market for staff is.
That said, the kitchens I've worked in were filled with people who worked as hard, or harder than the FAANG teams I was a part of.
Agreed. I have always thought about refactoring as developer responsibility. If it needs to be done do it while working on real feature and update deadlines accordingly. That way it is way easier to justify it because you talk about it only with technical people. In long run it makes code base way better. This results in easier maintenance and faster development of new features.
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.
Just for the record, those have intangible results. They improve maintainability, reduce vectors for bugs (which are always based on misunderstandings) and increase velocity.
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.
> reduce vectors for bugs (which are always based on misunderstandings)
Is that really impossible to measure? (For cheap that is. Cheap measure, cheap estimate, cheap confidence). Is that really impossible to monitor?
Grab a random sample of 100 fixed bugs in the past 2 years. Go through them one by one. How many do you really seriously think would have been avoided? If it's not much more work, give it some weighting on confidence and impact or something. For how much addl work? Once you notice what you could count, restart from the top (re-randomize?) - it's only 100 bugs. Is it really 100%, or is it now that are looking at the data more like 10% at best? Was it really impossible to get data?
Now that you have an estimate, write it up and circulate it - It's risky: you could be volunteered to fix the problem and maybe you don't want that.
Would it really be impossible to monitor over the next year? (Still cheap data, cheap results - except if you really estimated 100% because now you were able to get real budget - even if too small - to attack it.)
Estimates, targets, budgets, deadlines are all different concepts. A fraught but carefully worked up estimate is rarely impossible.
Entire businesses get founded and funded on "impossible" estimates.
Although to be clear, the estimates will "this is where we think that we will be saving money"
followed by a review (in 12 months time) that will be "this is what we think is the result, but it will include improvements from other vectors, such as better communication from business"
Sure. This is rough engineering. If you identify a plausible significant cause, and you attack that, and you get useful improvement, people are not too likely to be overly concerned that there was some confounding factor in the improvement. If there is any excess, it's likely to be in the other direction: deciding that the likely improvement is not worth it. Engineers hate that kind of decision.
The biggest political capital that you can build up is your technical understanding & skills. But they are only useful insofar as you put them into the context of the broader company strategy. Giving appropriate advice, and delivering, in the interest of the company, will give you capital, i.e., people listening to you & relying on you, trusting you, which gives you power to steer. Preparing contingency plans & pitching then, then executing them, is the best way.
Depends on the scope. Simple things might be docstrings or sections in READMEs, bigger things issues/tickets or a page on Notion/Google Docs or whatever you use; overview there or in your head.
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.
As someone that has influenced company politics as an independent contributor (non-manager) repeatedly, I find you have to go through a lifecycle:
1. When you first join you need to show you can actually accomplish things, likely through code contributions / launching something.
2. After you do that you start becoming part of conversations and can start influencing directly. The key here is problem identification and bringing useful independent data. Whether we like it or not managers have built in leadership authority, IC's have to establish it by above, so usually the leadership group is dominated by managers, but if you can bring useful technical data / solutions and become a "voice of the people" if you will that lets managers not have to dig in and solve every problem you will start influencing politics.
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.
Appreciate this discussion. I worked 15yrs in large tech companies as a software engineer and felt like a pawn always.
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?
Politics in the workplace is exhausting. I refuse to play these games, which is probably to my own detriment.
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.
> The important thing is to have a detailed, effective program of work ready to go for whatever the flavor of the month is.
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.
There is a career book that makes a lot of good but extreme points.
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.
I slightly disagree. Managers aiming to move up the political chain are very much happy to give political influence to those that will publicly and privately support the manager's own political goals. They want to be pushed up from below and pulled up from above. Managers that are coasting won't because they don't want competition from below.
Engineers often can't tell the two apart, and have too much ego to not publicly and privately make their manager look bad.
Unfortunately and with the pain of my soul, after 10 years working in start ups, I have to admit that yes, the truth is that politics matters and matters much more than good engineering, that is something that I have learned the hard way. And it’s the only reason I’m considering leaving the game completely, as soon as I have enough economic freedom.
> 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.
This is good advice but it has one flaw that makes it unrealistic for most software engineers.
"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.
I work at MSFT. Everything the author says is 100% true not only at MSFT but probably at every Mag-7 company.
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.
I am sure these techniques are effective; but they're disingenious and self serving.
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
You're implying that the pet projects don't align to the goals. If the person is actually technically competent and has good ideas, then it won't be much of a stretch to justify why the project is relevant. Unless the new initiative is really a complete 180.
High level engineers should be looking ahead and predicting what projects will be needed based on technical weak spots or market trends.
> The easiest way is to actively work to make a high-profile project successful. This is more or less what you ought to be doing anyway, just as part of your ordinary job
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.
Is that a moon? No, that's your survivorship bias!
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.
People should collectively own the companies they work for.
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.
I think this is largely practical advice if you want to influence a tech company at all costs. That is -- to have multiple projects lined for each executive goal that you can singlehandedly deliver on to thunderous applause.
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.
It is interesting to notice that when the goal is considered positive by a large enough percentage, the act is named "influence". Whereas when the goal is considered selfish and against the common good, the act is named "manipulation".
My advice is to spend it where it matters. I took over a data center project. It’s really a software development environment. They implemented istio when nginx would have worked just fine. Only needed ingress controller and nothing crazy for what this is. There is a VM that runs nginx and it is the reverse proxy for Atlassian tools running in VMs. But we have NSX-T which can handle this so no need for a separate nginx reverse proxy.
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
If you have other people working at your company or investors, politics will come into play.
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.
Yeah, and you can also get rid of local politics by moving to the countryside and homesteading. And you can bypass national politics by homesteading on a ship or an island that nobody cares about. And you can just move to a different planet to escape global politics. But any group of people will develop some form of politics, and to do anything meaningful longterm, you need a group of people, not just an individual, why not get better at politics? It is inevitable you will have to take part in them.
I used to run my own business when I was a child, and made a lot of money from it. Paid my way through school with my earnings. There was no sales or marketing, and all I did was product and engineering, and at no point was I politicking. So no, it's possible (albeit difficult) to not be part of the meat grinder, I have done it.
Sure, to some degree it will always be there. But company size and careerist culture - both local to the company and differences between countries - makes it vastly different in presence.
All good advice; I would also advise doing whatever is possible to be considered personally useful by very important executive staff that you like personally, even if it means doing jobs that are trivial but showy for non-technical users (like dashboards). Once they like and trust you, pitch them an actually good idea that they can take credit for at the right time.
> It is simply a fact that software engineers are tools in the political game being played at large companies, not players in their own right.
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.
All great advice. But I wish I had spent more time asking myself whether I should spend my life eating crap and kissing someone’s butt in order to further someone else’s ambitions.
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.
I wish there were more articles on this topic. Politics is always something engineers have to suffer because, not a part of life in a way they could actively utilise, even though they are the core business-forming part of the lower ranking workforce.
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 build my entire career doing exactly this and after three decades in the industry, last one as a contractor, this is one of the very core things I do…
This is usually in big corps, so if you like working in these hellholes, then proceed with all these shenanigans. I worked there before and it's not really good for engineering, let alone engineers' mindset, because in addition to the actual technical stress, now you have to deal with all this bs from people who do nothing all day but these games. Small companies are the best for me, and I remember one time in a small company they hired a manager from a corp. In a year, he managed to fuck up everything, 4 engineers left including myself, and turned the work culture into rules and policies instead of adults working with each other towards a common goal.
>Powerful stakeholders are typically so stupid and dysfunctional that it’s effectively impossible for you to identify their needs and deliver solutions to them
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.
The preceding paragraph says software engineers *believe* these things and has a footnote referencing HN discussion.
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.
> The easiest way is to actively work to make a high-profile project successful
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.
Instead of waiting to be told what to do and being cynical about bad ideas coming up when there's a vacumn and not doing what he wants to do, the author keeps a back log of good and important ideas that he waits to bring up for when someone important says something is priority. He gets what he wants done, compromising on timing.
glad to see someone being real and not parroting infuriating "politics is just learning how to interact with other humans narrative" .
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.
It seems like this post can be summarized as follows:
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.
> 1. If your manager has something in particular they want you to do, you should do it.
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.
I completely agree. I've foudn that skill never goes away no matter how far you get. The trick is as you go higher up, spotting what comes next and knowing how to solve it faster.
> 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.
You can go on sidequests but first you need to accumulate sufficient credibility.
This is it, pretty much. If you do your own thing and it works, then you'll come out well. If you do your own thing and it fails, you'll look bad, while if you do what yiu're asked you're going to be much safer. So if you go off-piste you should have some confidence it'll work.
> if you go off-piste you should have some confidence it’ll work
Just remember that the definition of “working” is in the eyes of your manager. Assuming they’re competent and not pointy haired boss, then they might have different goals and priorities to you. I’d you end up diverging from them, even if what you did is technically good and a good fit for the project, you’ll probably have a bad time.
Yes, you do still need to solve a problem that is considered a problem and at least around the same level of importance of whatever you were supposed to be working on, preferably greater.
> spotting what comes next and knowing how to solve it faster
This is such a strange mindset to me. Part of staff engineer is learning you don't need to solve tomorrow's problems. You solve it with the constraints you understand and leave room for expansion if needed.
Why do we have the opposite belief organizationally? And why as a manager would you want your top workers to be speculating about things you might want rather than achieving at the tasks you gave them?
(This is a genuine question.)
It’s obviously way more nuanced than 2/3/5 lines of text on both sides but;
It’s not about speculating vs achieving what I’ve assigned them. It’s an over simplified example but if an engineer has two tasks to be completed that are dependent, it’s poor engineering for task A have to be re-done for task B to work (imagine an API that has ambiguity in the definition of done). A good engineer thinks just a little bit farther ahead.
At a staff+ level, 8: expect them to not only consider that but to consider “how likely is it what I’m going to have to re do this work” and scope accordingly, or to come to me and say “hey, every feature we add to service Alpha, we end up having to do XYZ to it, but with Beta we don’t”. They spend 10x more time than me writing code so they know that better than I do.
My team know my priorities, know what I value and know the areas I’m keeping an eye on. If one person is continually going on unhelpful tangents then that’s a single person issue to be handled with them directly.
YMMV with team sizes, team maturity, and where you are with your product dev.
That makes sense. I guess seeing the full lifecycle is always how I think about software I work on. I can do a better job of communicating that’s what I’m doing and why the approach I’m using (of doing less) actually helps us to be able to make changes.
In certain tribal societies, there is no "chieftan" per se, there is just the guy who happens to be correct about things more than everyone else, so his opinion gets the most weight.
As a former engineer who recently transitioned to management, this is precisely how engineers who are competent are perceived as underachieving. Focus on the right problems, put side quests on the back burner.
But how do you know what the management perception is of whiat is currently considered to be 'the right problem' vs 'side-quest'? To what extent is that subjective and manipulable? Or that everyone in the management chain is fighting to maximize their perceived contribution to the former and minize their perceived contribution to the latter?
Without knowing the context, it's impossible to tell whether the key word in your sentence is 'perceived' or 'achieving' or 'focus'. Or what set of people shape the perceptions. Or on what KPI. Or what if there aren't even clear metrics. Most engineers like working on designing things, not executive palace coups.
(Corollary: have you never seen a group or entire dept get sidelined by being assigned something that they're officially told is important but at some point is publicly/secretly determined not to be, at some murky point up their management chain? What happens when the Director, VP, CXO are changed, perhaps multiple times, in a project?)
> But how do you know what the management perception is of whiat is currently considered to be 'the right problem' vs 'side-quest'?
You ask.
A large number of the problems I helped people work through while mentoring came down to engineers get stuck in their own head instead of communicating.
Whenever it's not clear, you communicate. Many companies have this as a daily update ritual in standup, but some engineers treat standup like a game where they have to say the right thing to get it over with as quickly as possible before going back to their computer and forgetting what they said they were going to work on.
If ambiguity persists, it's a good idea to write a short e-mail to your manager saying you're working on X instead of Y or Z because you think that's what's best, but then finish by asking them to let you know quickly if you got it wrong.
> Corollary: have you never seen a group or entire dept get sidelined by being assigned something that they're officially told is important but at some point is publicly/secretly determined not to be
No, I have never worked at a company so dysfunctional that management will make secret decisions but forget to inform the company, or make public decisions and an entire department will ignore them.
I don't get it. What's the incentive for anyone to do this?
Though I have worked with some people who would go off on their own tangents, then when the consequences caught up with them they'd concoct excuses about how it was never communicated to them (despite us pointing to records in Slack where they acknowledged) or elaborate conspiracies about management coming up with secret changes or something.
They are the one in a position of power. Why do I have to ask?
You don't have to do anything. But as you say, they are the one in the position of power. If you are working on some side quest they don't see as valuable, it may not end well for you. Doubly so if you are shirking what they see as a high value task for your side quest.
It's not about what is right or who "should" do what, it's about securing the best outcome by making sure you and your manager have the same understanding, even if your manager isn't doing a good job of making sure you have the same understanding. (Also known as "managing upwards.")
Obviously the context is after you and other people have asked; multiple times. You should interpret my comment with that reasonable preamble. And obviously as you say when people are being ambiguous or not communicating well, you memo what was communicated in writing. But that doesn't cure all organizational ills, not by a country mile.
It's nice if in your sample size you've personally only ever come across management chains that were trustworthy, competent and aligned. It's nice if you've only ever seen one unambiguous flow of truthful information from the bottom to the top and vice versa, and everyone's aligned to cooperate. But the alternatives abound.
I've seen (or been told of) directors battling other directors on organizational priorities, senior managers quietly undermining and deposing VPs so they could take their jobs, EVPs of sales selling capabilities that their own engineering had been telling them could never ship, the sales-side of an organization having a totally different roadmap than engineering and feeding it to a (nontechnical) CEO who couldn't tell which was accurate; CEOs putting out press releases about fictitious component their engineering was telling them they would not be available. Managers cheerily suppressing showstopper issue reports to send "mostly green/96% done"-type status reports up the pipe, on a project they knew to be doomed, before they completed their company-sponsored MBA then promptly jumped ship to a rival, and the company failed. Board members hyping underwater stock internally, only to quietly step down and immediately dump all their stock now they were no longer designated as privileged insiders. (Remember: once you go public, there are disclosure requirements and possibly shareholder class-actions, so even when something's universally known internally to be an issue, often executives can't acknowledge that, even internally (think "audit trail"); although you can infer a lot from their actions.)
Also you're presumably aware of some company cultures where internal secrecy and internal competition are fostered, pitting departments against each other (or at absolute minimum, where cooperation between departments is heavily discouraged, or punished). Or, in the middle of a product development cycle suddenly launching a "partner collaboration" or "strategic acquisition", where that is misaligned or competes with internal groups. Fear, intentional ambiguity, conflicting priorities as a management tool. Often this stuff is indirect evidence of conflicts at VP-level or higher; sometimes it's culture or force-of-habit.
Nobody said "forget" to inform the company or "departments ignoring clear and unambiguous directives". I implied misinforming or misleading groups/depts, or maintaining strategic ambiguity about what priorities were.
> What's the incentive for anyone to do this?
All of the above happen regularly, and it's pretty obvious what size and structure or organizations, and what individual metrics for compensation, and in particular when metrics are intentionally designed to be in conflict. For example, in a large company once you define separate "business units", people are overtly now working to differing metrics.
"conspiracies" and "go off on tangents" is a pretty disparaging way to misinterpret my question. You've never heard of any of the above ever being intentionally deployed? And "dysfunctional" might be our shared opinion, but I've heard from board members that passionately believe companies should be incentivized like that.
There's a reason Software Anti-Patterns (both technical and management) were recognized to exist several decades ago. [0] I think you're merely saying you haven't personally encountered them much.
For sure there are some engineers who treat standup like an annoying interruption to real work, or can't be articulate; equally there are scrum meetings where people play points hero or points olympics in inflating their perceived velocity. I've seen some adept operators nurse a weak spot in their part of the product so it could get closed then quickly reopened multiple times for multiple different customers, making them look great, but no mention of refactoring or adding testcases, or explanations of whether the thing was incorrectly closed or underestimated previously. Agile is only as good as the people overseeing it and measuring; it's easily gamed.
Communication does not happen merely because you mandate a 15-minute daily(/weekly) team meeting and tell people to do it; it only happens when people's official or unofficial incentives are generally roughly aligned to facilitate it. It's much easier to do that in a 10-person shop all working on the same product than 10,000 people, multiple teams, multisite, multiple products, dendritic orgchart, etc. You haven't really focused on the "managing perceptions" aspect of my question at all. There are certain breeds of middle-manager whose careers thrive on going into problem depts of large companies and cultivating the perception of them as firefighters/powerpoint-warriors, whether that's decoupled from reality or not, before they move on before the success/fail outcome becomes apparent. Again, misaligned incentives, and works best at the interface above which management stops being technical. If you're inside the dept in question, you can actually see how much of the perceived performance is objective verifiable fact vs managed perception. Or to put it another way to you, you've never seen people who are roughly as good as each other, yet one is more adept at managing perceptions?
It helps us gauge your personal experience if you tell us what size of team and organization and company stage (early starup/late-stage startup/small/large public company/etc.) you're anecdotally referring to.
[0]: https://en.wikipedia.org/wiki/Anti-pattern#In_software_engin...
> But how do you know what the management perception is of whiat is currently considered to be 'the right problem'
Ask! Literally. But also listen.
Many people in management will repeat over and over that feature X is the thing they wake up thinking about, even though feature Y is important to the PM or director or whatever. Especially if you’re young enough that promotions and performance reviewed are really important for career growth, work on X not Y.
If your manager doesn’t start every meeting with some passive remark that project X is consuming their time, ask them what is important. Ask them what project they’re worried about.
Example:
“Hey Boss, I’ve been working on ProjY, but I also have tasks from ProjX pulled into this sprint. Which one is a bigger priority for the team, because I have 10 days of tasks, but only 1 week left in the sprint?”
… “hi boss, a week ago you told me to prioritize finishing X and not Y. Should I just allocate all of this sprint to the next set of tasks for X?”
… “hi boss. It’s me again asking this question every week “
If you want a good performance review/promotion/etc, usually that starts with your direct manager, so do what they think is important and ignore the rest. You need their trust first, so get it by working on their priorities. With their trust, you can get flashier or more fun work, or you can get them to trust you when you suggest alternative priorities, and you can earn the gossip/news they hear in management meetings from up the chain.
Your corollary is just rage-bait FUD or dysfunctional behavior. Any you can’t control it anyways so ignore it and focus on what matters that you can control. If your CXO doesn’t like what you’re working on, but your manager does, pick your manager, they actually write your performance review.
Although we should notice the other side of that - managers that don't have an explicit onboarding where they lay that algorithm out for their reports are doing a terrible job. It is literally 3 lines. Lay it out at least once. Maybe go through it in a standup once a year. They are letting people slip through the cracks to the point where we have junior and even mid software engineers that don't realise there are priorities and that they should be working on them. Wow.
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.
> 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.
Have you considered the possibility this is not a result of incompetence, but intentional? If these things are never clearly communicated and, more importantly, put in writing, management can just reframe what was agreed upon as best suits them later to deflect any blame if things go sideways. This is a perfectly rational move, since they hold all the power to do so.
I think a lot of what is wrong with this discussion is that people implicitly assume management is honest and communicates openly and sincerely. This is sadly only true in a small fraction of cases, likely because the incentives point squarely in the opposite direction: those who judge the game are always better off cheating.
exactly. my last job the project i was working on suddenly became "my project" where manager wanted to "give me a win" by shipping. it became my project when we discovered all the way in the end that what he had come up with isn't viable at all. thing i was telling from the get go but he didn't listen and adamant that it would be fine.
we even had it in writing the i had objected to his scheme and that he overrode it but that document was completely hidden from upper managment.
Very well expressed. That's great early-career guidance, but also a good refresher for many senior staff.
The simpler version is "Actually deliver on what you're asked to do".
It sounds so simple that people get offended when you say that. Yet it's at the root of a lot of employee performance problems where the employee is doing a lot of activity, but not delivering on expectations.
I've worked with some brilliant engineers who failed because they were always off trying to reinvent the wheel with their own completely unnecessary framework or rewriting some code that didn't need to be touched. In each case their managers were practically begging them to just focus on delivering the tasks they were assigned, but they were still surprised when the performance management actions came along.
What do you do if your manager sends you on boondoggles of a project?
It’s good advice for the average engineer who wants to chug along. Not exactly anything that would classify as “influence” though.
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)
I read number 2 more as being ready with your own agenda items. For example, if you want to make a code base more minimal, have a POC and some details worked out for when the opportunity presents itself.
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?
To flesh out things to where you could actually make a reasonable pitch with things like realistic time estimates and documents that would be useful to read then you'd have to have already done it, it'd be trivial, or you apparently have plenty of spare time to do serious spikes in your day to day. You'd also have to have the spare time to update these project ideas as the months pass, the product and codebase changes, etc.
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.
> if you want to make a code base more minimal, have a POC and some details worked out for when the opportunity presents itself.
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".
And this is the reason that at one point, Google has 4 different messaging apps and presented 3 at one presentation. No one gets promoted by improving an existing service
I'd add:
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.
I'll add that all this goes up the food chain and is good advice for engineering managers too. As a director reporting to the CTO I tried to do this as well.
I lean towards telling your manager what they should want. Put issues that you identify as important on the table and draw attention to them. Explain why they're important. Make them benefit from your expertise by being proactive about this sort of thing.
My experience is still fairly limited with this, but I do have some successes.
Strongly agree. Our expertise is why we are there, when I tell my managers that something is important, they listen.
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.
If you are not a shareholder, then it is an incredibly poor advice.
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.
I would rather not live my life with the sole purpose of people pleasing managers
This makes for a pithy sound bite, but that’s pretty much only possible if you’re independently wealthy to the point of being in the “fuck you money” category of wealth.
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.
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.
IMO, the people who need to be pleased are the customers, and, IME, management's expectations very often run contrary to those of the customers.
Turns out that anagement really doesn't like negative feedback from engineers which turns out to be echoed by users. I'd rather see career advice on how to prevent management from tanking the company without causing them to resent the engineer(s).
In case you can share an alternate strategy to make a career in a large tech company, please do, would be interested.
The alternate strategy is loyalty to "the business" rather than any particular person.
When you're invested in the success of the business above all else, and you make that known, you'll carve out a position where you're valued.
Not because you went on a "carving out your importance" mission, but because your energy goes into your work, and the details and care for the long term business objectives. Also... you can then enjoy yourself more, which opens creativity which opens innovation. Sometimes this might mean disagreeing with managers or working on stuff nobody really knows you're working on right now.
> "So if you want to get something technical done in a tech company, you ought to wait for the appropriate wave"
No. That doesn't work. You have to start building it. Don't wait.
I agree with this. That's been my take throughput my pretty long career and was a recipe for success.
You still need to:
1. Be good at what you do.
2. Be good at politics/communication when that's needed.
3. Be in an organization that has good people and also cares. There are organizations where there's just a complete disconnect from the business for various reasons. Dysfunctional.
This is a good strategy, imo. I was following it for almost a year and I was having a blast working in a startup. Then a new manager came along and started to dictate how things should be done without much input from the technical team. I kept fighting for what I thought was good for the product instead of aligning with him. In the end it was just too stressful (the manager was not only an idiot but also rude). I resigned, but I wouldn't have done any other way. I simply can't be made to do dumb things from uncurious people.
It's a shame when resigning is the only way out. Before reaching that point, the usual strategies should be attempted:
It's a fine line between fostering a positive work environment in the face of misguided decisions, and being condescending or derisive towards other team members. There is no silver bullet, but a touch of self-deprecating humour never hurt. If you advice isn't taken, you'll have a non-snarky receipt. Any email written with an irritated tone, will look twice as bad months later.I did create benchmarks and simulated impact following different scenarios (including the one I was advocating for). Unfortunately that was received in deaf ears. Even worse, actually; they thought I was being too pushy by adding the scenario I was proposing to the analysis. At this point I knew I had to leave.
you should do everything possible to make a career in a small company. after three decades as SWE it is my #1 (there is not even remotely close #2) advise for everyone in the early stages of their career
The politics in small companies are far more extreme in my experience.
I am 51. I love small companies. My second best experience was working as the second technical hire by a then new to the company CTO who was hired to bring technical leadership into the company. The two non technical brothers who were founders outsourced the development to a consulting company until they found product market fit.
But I still did the same thing the article and commenters suggested. I stayed strictly aligned with what the CTO wanted and just from that, I was able to guide the entire technical architecture of the company for two years even though I had no hands on experience with AWS.
Let’s not be fooled though. My next job after that startup that had 60 people was at the second largest employer in the US - AWS working in the consulting division (AWS Professional Services).
It was an immediate 50% bump in pay. An even greater contrast is that an intern I mentored got a return offer at 22 in 2022 that was the same I made at 46 in 2020. They are now at 25 making slightly more than I’m making at a medium size third party consulting company working full time as a staff consultant.
Your principled stand is leaving a lot of money on the table.
At 51, I would rather get a daily anal probe with a cactus than ever work at any large company again and I have turned down a position that was going to be created for me at another large well known non technical company where a former coworker was a director and ignored overtures from GCP in their professional services department that would pay a lot more.
I also wouldn’t like the company I work at now with around 700 people if I weren’t brought in as a staff engineer where I have almost complete autonomy on how I lead my projects and the ear of the CxOs
But let’s not pretend the extra $75K to $100K+ I could be making isn’t worth playing politics. I’m just at a place in life where I can prioritize other things than money.
Also, at 51, I’ve learned a few things. Not to make your “career” at any company and to always be prepared to jump ship when the environment changes or the raises don’t keep up with the market. I’m now on my 10th job.
not everything in the career is about money, your entire post is related to compensation which is also core reason why many people in the industry endure fucked up place to make an extra few bucks. there is a much better path in the industry that isn't built around "jumping ships" and chasing every dollar there is to chase. and that path is much better for your long-term physical and mental health as well everything else that surrounds your life, especially in the years that matter, when you are young and full of life in the late 20's, 30's and 40's. having stress-free life in your 30's and 40's (coupled with normal working hours etc...) beats the hell out of having financial freedom in your 50's
I work for one reason - to exchange labor for money to support my addiction to food and shelter. There is no higher calling.
If I were 22 post 2010, instead of 1996, you damn well better be believe I would have been “grinding leetcode to get into a FAANG” instead of wallowing in enterprise dev making what a returning intern makes at BigTech.
I’m not bitter, by 2012 I was 38, recently remarried and wasn’t about to uproot my (step)kids. But by youngest graduated from high school in May 2020 and I had an offer from BigTech June of 2020.
I definitely encourage any younger developer to play the game.
As far as jumping ship, if my goal is to exchange labor for money, why wouldn’t I exchange the most money for my labor given my other priorities? Instead of letting a company pay me less than market value or even worse what they pay someone coming in at my level.
Besides, I had my first house built in 2002 for $175K when I was making $65K and had no student loans. Neither is true for most students graduating today.
And it’s copium thinking that people at BigTech making 50%+ more at every level work that much harder than an enterprise CRUD developer doing Java at a bank.
I’m not advocating someone works 70 hours a week at a startup getting underpaid with the promise of “equity” that will statistically be worthless. I am advocating they get paid in cash and/or RSUs and immediately sell as soon as they vest and diversify.
And next year will be my 30th year working, I’ve never experienced burn out because I exercise my agency to say “no” to being overworked knowing I could get another job worse case and continue exchanging my labor for money and stay housed and fed.
I don’t know if it’s different, but I always carve out about a day a week to work on “skunkworks” projects that will benefit my team but that nobody has asked for yet. Then, when it does get asked for, I have a rough solution ready to go.
I think this ties very well into the advise of the article and is not orthogonal / different.
That's the crux. I don't want a career in a large tech company.
> I don't want a career in a large tech company
I would swear by this when I started working in IT, but 3y later I changed job and took a gig at a big corporation. It was eye opening and jaw dropping. Everything was lightyears ahead in terms of tech, management, money, investments in people, and much more compared to the small company. It geniuinely made me mad for not doing this sooner.
Strange, I've had the opposite experience: I've mostly worked with small startups and every few job changes will try a go at a big tech company. I'm always shocked at the gap in talent between small startups and large tech companies. Far and away all of the best and most talented coworkers I've had have been at small startups.
Of course there's a lot of variance among small companies (much moreso than large ones). But the one thing that all small companies have is people who can actually get shit done not matter what it requires. The amount of "not my lane" nonsense that occupies corporate life is both exhausting and boring. I understand why this exists for practical reasons, but it's no fun.
Is working in a small tech company any different?
It's SO different. It doesn't guarantee that life is good, but politics plays a much smaller role, especially at the very small sizes. If you're objectively awesome, the chances of you being sidelined for political reasons is pretty low when there are like 10 people in the whole company. It's just obvious to everyone who is delivering value and who is not.
Conversely, if you're mediocre, there's nowhere to hide.
Or maybe instead of saying there aren't politics at small companies, it's more accurate to say that there are politics, but they're simple--everyone strives to make the (hopefully benevolent) dictator, I mean founder, happy. If your founder is awesome, life is good. If your founder is not awesome, well, everyone is going to have a bad time anyway.
> but politics plays a much smaller role, especially at the very small sizes.
I thoroughly believed this after working at a small company with little politics in one of my first jobs.
But then a couple of the later small companies/startups I worked for had politics to such an insane degree that I no longer believe small companies are better or worse in general. They just have a larger variance.
The larger the company, the more the workforce trends toward the mean. When you hire 10,000 people you can't exclusively build a company of low-politics people.
With a 10-person company you technically can build that company of mostyl 1-in-100 employees who work well together. However, you could also stumble into a company where you're working with 10 people who have worked together previously and have no intention of bringing you into their inner circle. The politics at this latter type of company is truly next level hell because there's nowhere to go, unlike at a big company or FAANG where you can transfer teams or rely on your resume to get you into the application process at another company easily.
> It's just obvious to everyone who is delivering value and who is not.
In my experience at highly political small companies, this doesn't matter. The people running the political show want the upper echelon of the company to be composed of their close friends and allies. They want the people who produce to be stuck doing the grunt work.
> but politics plays a much smaller role
This does not align with my experience at small tech companies at all, and I've worked an many.
But the flavor of the politics is very different. At a small company as an IC you will very likely be working directly with multiple C-levels, often providing important context between them. A senior IC will need to be reaching out pretty actively across teams to make sure things are happening and you'll quickly build an internal network of "good people who get shit done fast".
Politics can seem no existent because in some cases just getting along well with leadership can be enough to make your life very easy. But you'll see how truly political these situations are if you have the opposite situation: someone in leadership just doesn't like you. One bad relationship can ruin you in a small company.
In a large company it's not too hard to just keep your head down (at least as an IC) and largely let your manager worry about politics. For managers it can seem more political because typically the "be friends with leadership" doesn't work because the hierarchy is both broader and deeper.
Thanks for the thoughtful reply. I agree with all that and I think I was trying to say something similar with my last paragraph.
I’ve gotten along with _almost_ every person I’ve worked with, including some pretty challenging personalities. I’ve always done very well at my job duties and gone “above and beyond” regularly. The only times I felt that might not be nearly enough, was at the two large companies I’ve worked at. Someone several levels away from me, that I would never meet, would decide whether I got a promotion or a raise or a juicy new assignment based on a game of organizational telephone. Frankly, when I tried I did pretty well at that game, but it was the first time in my career that I was tempted to do something out of cynical self ambition or winning rewards for my team instead of just trying to do the right thing for the customer or the business.
That’s what I think of when I hear “politics” and why, by comparison, it felt to me like at a small enough scale it’s not a thing. But if politics means needing leadership to like and appreciate you, then yeah absolutely, that is true anywhere there’s even one level of hierarchy.
> Conversely, if you're mediocre, there's nowhere to hide.
This line alone makes me believe you've never worked at small companies.
Small companies are where people who don't have better options go to coast either voluntarily, or involuntarily.
I do think this could be true. Your productivity is way more visible in a small company, execs actually know what you’re working on maybe from day-to-day and most definitely week-to-week. Slackers don’t last long and mediocre developers standout, now why they might be perceived as mediocre is another discussion. My first job was at a big corporation (~150,000 employees) and honestly I saw so much politics and fiefdoms and just generally low quality developers not doing much but they could sneak under the radar because they’re a small cog in the apparatus. My next company (~50-60 employees) the devs were definitely better and way more productive, but it also felt very performative/showy environment of what devs did every what and if you were perceived as not doing enough you definitely stood out. It was a very public, perhaps stressful, work environment with demos every 2 weeks.
I’ve mostly worked at small startups in my 30 year career, and been fortunate to work mostly with excellent founders and teams. Certainly that experience colors my convictions, as your experience colors yours.
Massively different. You generally have more autonomy, fewer managers, more responsibility and wear more hats. In my experience no corporate fake people pleasing or PR language or HR nonsense. Just regular people talking normally trying to get stuff done.
Wildly different. One of the biggest things at a small company is that you can wear multiple hats to solve a problem and not step on anyone's toes. Need to play PM, backend engineer and data scientist to get a product shipped fast? No problem, and you'll be seen as a person who can get things done by leadership (if you make sure to keep your work visible).
The main divide I've seen between what makes people happy in one or the other style tech company is whether they really enjoy solving problems or doing their job. If you want to check in, do only what is technically required of you and get out, then big tech corp is for you. If you are mainly interested in finding solutions to problems and you are happy to employ whatever is necessary to do so, you'll have more enjoy small companies much more.
Not really, I'd love to get out of tech entirely.
No matter what founders and managers say the reality is that 95% of tech jobs are meaningless outside the capitalistic flywheel. You're not making the world a better place. You're moving some bits around and extracting a profit from it. Pleasing a manager or pleasing the capitalistic flywheel doesn't seem much different to me.
“You lack soft skills and initiative; unfortunately, you will not be promoted while having more responsibilities” - the manager who wants to be pleased.
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..
It doesn’t have to be your some purpose; it could be within your normal working hours. It’s basically just choosing a goal to be intentional with at work.
What? This is what you are paid to do in your work life.
This isn’t a thread about your whole life.
Or better options - just do the job you were hired for and go home or find that rare job (if possible) where engineering has a bigger role than politics. It is not pleasant to play a guessing game trying to please some manager, just because they’re your boss.
Life is too short for stupid games
> engineering has a bigger role than politics
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.
If you think corporate politics is just a stupid game you'll never be happy with what you accomplish and lucky to keep your job. Awareness and understanding, being able to tie effort to outcomes, positioning and sales; these are not guessing games.
'make your manager look good'
Make your manager's manager look good. Because only then you would be able to go up the food chain (assuming that is the goal. your manager may become your competitor/peer in this case).
>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.
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???
One of my favorite quotes: “ 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.” - Milton Friedman
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.
> but I’ve also been owned by VPs and directors that are much better at politics than I am.
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.
I’m dumb about it. I don’t have a scheme, I don’t have a hidden agenda, I don’t have ulterior motives… I’ve got what I think is great engineering (divorced from what the customer or business wants in the short term) and I just diligently try to make that happen. I’ve been doing this a long time and I’ve always got the long term health of the system (and fairness to the workers next to me ) in mind. I say the same thing to everyone, I’m open and honest, and I get wrecked every time I try to execute any strategy that doesn’t accidentally align with something a VP wants.
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.
Working with naive people is such a relief. They never surprise you with some f-ed up shenanigans just to make themselves look good, and they are worth their weight in gold. I try to be naive myself as well. But reality is political in the end.
I do the politics I think are necessary, but otherwise stay in my bubbles of naive, trusting and kind people I have stumbled upon.
I like the quote and I think this can work. The problem is the timescales can drive you crazy. The other problem is sometimes crisis is ignored, i.e. there is a crisis but it's not acknowledged or is somehow otherwise normalized.
What does it mean to make your 1 pagers and technical documents "float around" in your case?
Send them to coworkers. I've had success with the same strategy. There are three important parts required to make this work though: 1) Have a reputation solid enough that people are willing to take the time to read what you send them. 2) Read the room and write ideas/proposals on topics that are of interest and are relevant to the organization. 3) Find an audience that can provide meaningful support (basically, people with clout)
Do you mean if 1-pagers helped you get recognition and advance your career, or if they helped your ideas come to life?
They helped my ideas be “lying around” and picked from when the crisis happened.
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.
Absolutely! I thought this was inherent in the Staff Engineer position in the first place, so was sort of surprised it needed to be stated in the article.
I didn’t get a manual, just sharing what works for me so the next (new) staff and principals have one more data point.
Man, I must not have worked at dysfunctional enough companies. I can't relate to the opening remarks in this article at all. I'm used to really open communication from the top down and, even when we build in a direction I disagree with, we've discussed things enough that I'm at least interested in seeing why someone else I consider intelligent sees the world so differently. Perhaps it has to do with only working for companies founded by engineers rather than product/marketing? I'm not really sure.
Big American corporations (and to lesser extent, other countries that try to mimic US corporate culture) operate in a particularly dysfunctional ways. There’s ample literature on it (moral mazes, bullshit jobs and five dysfunctions of a team are particularly good books on the topic). You’re lucky to not have been a victim of that system!
I have seen how some big european and asian companies operate and every dysfunction which you can point out in an american corp is usually way worse there. Plus there’s some additional ones due to local customs
Different dystopias, for sure. The average Japanese big corporation values work hours way more than the average American one, for instance. In my experience in Germany and Switzerland, the corporate moral maze is definitely not as bad as the American one. Pick your poison, I suppose
I suppose that's because higher level VPs at large companies have broad goals and even broader notion means. It is not necessarily bad - allows to fiddle with different approaches before locking in on a specific technique. Wasteful? Yes. Efficient at satisfying board mandates informed by real time tectonic shifts in the industry? Also yes.
What size companies have you worked at?
Relatively small. 50-100 people. I could see it being totally different at larger companies, but gosh it sounds miserable!
Yeah, it's definitely miserable, but unfortunately frequently those larger companies pay a lot more, so there's the trade off. Kind of selling your soul.
> I can't relate to the opening remarks in this article at all.
i am guessing you never got promoted at work?
I was a staff engineer at my last employer
so am i but i got it through switching jobs. staff at 50ppl startup is just a junior. we had fresh grads with staff title.
I dunno, maybe? It's tough to compare alternate realities. I had equity in the company that paid out well, had a base over 200k, 30% EOY bonus, was leading a team of 6, fully remote work, no on-call. Certainly there are areas I'm weaker in than I would be if I worked in a FAANG-style corporation (only doing minor work with microservices, not doing much with distributed computing), but the job was quite different than what I did when I was first hired out of college.
Frankly, I felt mentally and socially challenged enough while also being compensated more than fairly. If that means I've got a junior role while also avoiding toxic large-scale organizational dysfunction then I'm down to make that trade-off every day.
> we had fresh grads with staff title.
Your company was doing it wrong.
for sure. but thats not relevant to the point i was making.
IMO the best you can do:
- 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.
I think you're absolutely correct and I think it goes one step higher level too.
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.
>its best to position yourself not as on the side of the "code" but as a EQUAL PARTNER to leadership/product/whoever has power.
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.
> - Have someone in management or a PM who is good at selling your wins
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.
Totally agree. Having good PMs (and good designers) is indeed life changing.
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.
This is why I almost gave up SWE. My skills, abilities, and output had little to nothing to do with my career trajectory, it's only about getting higher ups to sing praises about things that I might not have even done.
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
> it's only about getting higher ups to sing praises about things that I might not have even done.
If a company is so broken that promotions are decided based on factually incorrect information, there's nothing to do other than escape to a different company.
I'm talking about companies that are functioning okay, but they let the PMs drive what the team works on. A bad PM will send the entire team in the wrong direction and waste your time.
In the most extreme example, our PM would get distracted from the goals set by management and want us to do side quests all the time, so the entire team was constantly producing things that management didn't want while missing all of the things they wanted us to do. If your PM is the link between management and the team's directions, a bad PM will sink the team.
> If a company is so broken that promotions are decided based on factually incorrect information, there's nothing to do other than escape to a different company.
To me, this means that every traditionally run company (top-down) must be broken by construction. And indeed, I have never seen or heard of truly fact-based management.
The entire challenge with multi-level management is that you always play a long game of telephone with increasingly less technical people, which are unable (due to lack of time and understanding) to grasp the ground-truth facts without simplification. Thus, management based on hard facts is impossible in this setting, though it is a great theoretical ideal many aspire to.
In practice, doing so is very hard and people are lazy, so the "facts" can become so twisted as to be entirely unrecognizable.
I'm in Australia, and I've yet to find a company that isn't broken.
If everywhere you look stinks, it's time to look under your own shoe.
No company is perfect, no team is perfect, no person magically knows what's right to do and has a perfect vision. Even if you get somewhere with the right team, right vision and right priorities, and you stick with them, the world will change and one of those will end up incorrect.
Have you tried working at a company with less than ~30 people total? Those have been the best in my experience.
All companies are broken. Many companies are broken in ways that are tolerable or even decent.
Look, if everyone could just run their companies how I think that they should be run we'd all be happy :)
So is OP. He appears to be looking for them the same way i am. Working for American companies remotely.
I liked how you phrased that: "promises of future … you can't compete with". That happens so often, and strangely the argument that those promises have never become real the previous 26 times never works. The glorious future sure is amazing!
> Ship often to prod (don’t do theoretical work).
> 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?
The VP is likely to get political backing to do a “big change” and leverage resources to make it not theoretical.
because thats their job description and not yours
What would it look like if you were a staff software engineer whose job description didn't include theoretical work, but whose output consisted almost entirely of theoretical work?
That's not an issue of losing political battles, that's an issue of you getting fired very rapidly.
This advice is entirely premised on the idea that you can choose to do theoretical work if you want to, but that it will be a bad idea.
I have never heard of theoretical work but I have heard of shipping every day. I don’t know how often you think is often. But in other places I know people are shipping every day.
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.
This could not be more true, however the id like to add the patronage goes farther up the chain. They are all just saying want they need to to clear the checks. It an executive has ever actually invented a successful business model I have yet to meet one.
Oh they have invented a successful business model, it's just that it's successful for those in executive positions. The whole C-suite mentality is as successful for execs as it is cancerous for everyone else.
A lot of the frustration I typically hear in this camp is something like “well I shipped a huge refactor that cleaned up all the code, why does no one appreciate that?” One particular interaction that got me thinking was a few years ago listening to an acquaintance telling me how he spent months meticulously cleaning up the data pipeline and making it perfect, and how no one appreciated this work.
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.
I agree! You have to also remember that, if you're the person pushing for something to be priority, it's your job to make it make sense to whoever is responsible for prioritization.
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.
Sure except that "saving money" is not what makes a company win, and so it's rightly not what makes a career. If you can show that building that new library for $X will streamline engineering by Y% which will allow doubling sales by launching 3 new products - NOW you have a good proposition. (Your "X future business scenario").
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.
I don't disagree, but I'm not sure if you meant to reply to my comment? I didn't make any references to saving money; the point I'm making is that spending 10 hours this week in order to have 10 additional hours of capacity (ability to build out new features tied to revenue) every month is often a bargain that makes sense.
In the context of full-time engineers, "saving time" actually means that time will be reinvested into product feature development, rather than resulting in less spending on engineering pay. Similarly, engineers spending less time on support, means they can spend more time on feature development.
Your comment mentioned
> cost 200 dev hours, and save 400 dev hours
And I argue that this is rarely the right perspective. It's 200 hours NOW - and that the company doesn't have budget for. In order to save 400 hours maybe perhaps, if the stars align, two years from now. It's not the same budget. It's not the same time frame. It's not your dept's responsibility. In theory yes maybe but in most businesses, no. These 200 hours now are an investment. This 400 hours maybe perhaps are savings, not profit. They may allow an equivalent 400 hours spent on some profitable new product - but then just ask for budget for the profitable new product, don't worry about where that money comes from. That's sooo far above your pay grade, it's not even funny. If the idea for where to spend the 400 hours is worthwhile, the chairman will raise money to do it. Bring THAT idea to management. THAT would be well received.
In summary: the savings and the new product don't come from the same bits of the balance sheets. They don't affect the future company the same. The wasted 400 hours are already considered in the estimates for the next few years, they are essentially already amortized. They already don't matter. It's not fun for an individual engineer to consider that their work for the next 3 years is financially already long forgotten, lol (?), but basically yes.
It MAY be the right perspective for several levels of management higher up, if people are REALLY working on a 40 year perspective for, I don't know, a mainstream database package, a compiler. But nobody does (in first approximation).
It's also is a good viewpoint where crazy thin differences do make an impact (a refinery).
Still: Most companies that don't plan to be gone in two years do have a methods department or working group. People who do try and make the processes better. They have budget to do that. Bring the idea to them. Hell, even start working part or full time on their budget. But with the understanding that this is yet another group, mission, budget. It's not 200 hours here in exchange for 400 there. And this is a highly technical group - not CXO track except perhaps for a brief stint there.
Although I agree with this, I can also think of a counter example by analogy.
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.
Yep, maybe i am destined to never make staff but I absolutely loathe that everything must be tied to some company wide target metric that moves in a quarter or it is invisible. Many things that are worthwhile and that companies absolutely should be doing are not easily measured on a quarterly timeline.
This is commonly referred to as McNamara Fallacy
I think what you're describing is communicating the value in terms that the audience understands and appreciates. This is really a sales skill and most developers have little experience or recognize it as such. A good manager can help here, and I agree that a strongly aligned staff dev and engineering manager can accomplish a lot. That's been my experience and I'm always grateful for devs who work this way too.
> 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.”
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.
Think chefs at top restaurants for example: washing hands is something obvious, no need to get any customer infected with fecal bacteria in order to convince the restaurant management for investing into soap (hygiene takes time, you could serve additional customer!)
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.
Im actually curious what happens in a professional kitchen when someone isnt pulling weight on menial tasks like scrubbing or batch prep. I know what usually happens in software teams - nothing
Having worked in professional kitchens, my experience is that nothing predictable happens.
It depends not just on management, but also on the personal relationship between management and the person, and on how bad the current market for staff is.
That said, the kitchens I've worked in were filled with people who worked as hard, or harder than the FAANG teams I was a part of.
Agreed. I have always thought about refactoring as developer responsibility. If it needs to be done do it while working on real feature and update deadlines accordingly. That way it is way easier to justify it because you talk about it only with technical people. In long run it makes code base way better. This results in easier maintenance and faster development of new features.
> In long run it makes code base way better.
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.
Just for the record, those have intangible results. They improve maintainability, reduce vectors for bugs (which are always based on misunderstandings) and increase velocity.
Absolutely none of those can be measured (hence intangible) which is why they are a hard sell
> Absolutely none of those can be measured
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.
Can you demonstrate, or show how that would work (serious question)
Sure. Let's take that idea:
> reduce vectors for bugs (which are always based on misunderstandings)
Is that really impossible to measure? (For cheap that is. Cheap measure, cheap estimate, cheap confidence). Is that really impossible to monitor?
Grab a random sample of 100 fixed bugs in the past 2 years. Go through them one by one. How many do you really seriously think would have been avoided? If it's not much more work, give it some weighting on confidence and impact or something. For how much addl work? Once you notice what you could count, restart from the top (re-randomize?) - it's only 100 bugs. Is it really 100%, or is it now that are looking at the data more like 10% at best? Was it really impossible to get data?
Now that you have an estimate, write it up and circulate it - It's risky: you could be volunteered to fix the problem and maybe you don't want that.
Would it really be impossible to monitor over the next year? (Still cheap data, cheap results - except if you really estimated 100% because now you were able to get real budget - even if too small - to attack it.)
Estimates, targets, budgets, deadlines are all different concepts. A fraught but carefully worked up estimate is rarely impossible.
Entire businesses get founded and funded on "impossible" estimates.
Ah, I think that I get that, thanks.
Although to be clear, the estimates will "this is where we think that we will be saving money"
followed by a review (in 12 months time) that will be "this is what we think is the result, but it will include improvements from other vectors, such as better communication from business"
Sure. This is rough engineering. If you identify a plausible significant cause, and you attack that, and you get useful improvement, people are not too likely to be overly concerned that there was some confounding factor in the improvement. If there is any excess, it's likely to be in the other direction: deciding that the likely improvement is not worth it. Engineers hate that kind of decision.
The biggest political capital that you can build up is your technical understanding & skills. But they are only useful insofar as you put them into the context of the broader company strategy. Giving appropriate advice, and delivering, in the interest of the company, will give you capital, i.e., people listening to you & relying on you, trusting you, which gives you power to steer. Preparing contingency plans & pitching then, then executing them, is the best way.
> Preparing contingency plans & pitching then, then executing them, is the best way
I’m interested in hearing more about how you execute on this. Where/how do you keep your plans in wait?
Depends on the scope. Simple things might be docstrings or sections in READMEs, bigger things issues/tickets or a page on Notion/Google Docs or whatever you use; overview there or in your head.
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.
As someone that has influenced company politics as an independent contributor (non-manager) repeatedly, I find you have to go through a lifecycle: 1. When you first join you need to show you can actually accomplish things, likely through code contributions / launching something. 2. After you do that you start becoming part of conversations and can start influencing directly. The key here is problem identification and bringing useful independent data. Whether we like it or not managers have built in leadership authority, IC's have to establish it by above, so usually the leadership group is dominated by managers, but if you can bring useful technical data / solutions and become a "voice of the people" if you will that lets managers not have to dig in and solve every problem you will start influencing politics.
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.
Appreciate this discussion. I worked 15yrs in large tech companies as a software engineer and felt like a pawn always.
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?
Politics in the workplace is exhausting. I refuse to play these games, which is probably to my own detriment.
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.
> The important thing is to have a detailed, effective program of work ready to go for whatever the flavor of the month is.
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.
Not just a slide deck. The lobbyists have already written the legislation.
There is a career book that makes a lot of good but extreme points.
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.
I slightly disagree. Managers aiming to move up the political chain are very much happy to give political influence to those that will publicly and privately support the manager's own political goals. They want to be pushed up from below and pulled up from above. Managers that are coasting won't because they don't want competition from below.
Engineers often can't tell the two apart, and have too much ego to not publicly and privately make their manager look bad.
Understand what your boss's boss cares about and make sure your work can described in relation to those goals or concerns.
Unfortunately and with the pain of my soul, after 10 years working in start ups, I have to admit that yes, the truth is that politics matters and matters much more than good engineering, that is something that I have learned the hard way. And it’s the only reason I’m considering leaving the game completely, as soon as I have enough economic freedom.
> 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.
This is good advice but it has one flaw that makes it unrealistic for most software engineers.
"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.
I work at MSFT. Everything the author says is 100% true not only at MSFT but probably at every Mag-7 company.
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.
I am sure these techniques are effective; but they're disingenious and self serving.
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
You're implying that the pet projects don't align to the goals. If the person is actually technically competent and has good ideas, then it won't be much of a stretch to justify why the project is relevant. Unless the new initiative is really a complete 180.
High level engineers should be looking ahead and predicting what projects will be needed based on technical weak spots or market trends.
> The easiest way is to actively work to make a high-profile project successful. This is more or less what you ought to be doing anyway, just as part of your ordinary job
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.
You should consider finding a career coach, professional therapist. This level of pessimism can't be healthy.
Is that a moon? No, that's your survivorship bias!
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.
why? i got director level by following those strategies. nor am i depressed. perhaps you are commenting about language in my post?
[dead]
> Scheming takes practice and power
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.)
Yeah, this approach largely works.
People should collectively own the companies they work for.
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.
I think this is largely practical advice if you want to influence a tech company at all costs. That is -- to have multiple projects lined for each executive goal that you can singlehandedly deliver on to thunderous applause.
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.
It is interesting to notice that when the goal is considered positive by a large enough percentage, the act is named "influence". Whereas when the goal is considered selfish and against the common good, the act is named "manipulation".
> A slightly harder way (but one that gives you more control) is to make your pet idea available for an existing political campaign.
I have become very good at hitching my wagon to passing VP trains, it's sad, but it works.
My advice is to spend it where it matters. I took over a data center project. It’s really a software development environment. They implemented istio when nginx would have worked just fine. Only needed ingress controller and nothing crazy for what this is. There is a VM that runs nginx and it is the reverse proxy for Atlassian tools running in VMs. But we have NSX-T which can handle this so no need for a separate nginx reverse proxy.
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
Politics is inescapable. Software engineers can't live outside of them. Whether these are the team politics, org politics, etc.
I don't think engineers are universality bad/good at politics. It's just like anything else, takes practice.
There's a way out. Build your own company and make it something beneath you.
If you have other people working at your company or investors, politics will come into play.
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.
On that level, there are other policies.
Politics in standards bodies, industrial organisations, regulatory issues, funding and investment, etc
I’ve been on both sides of the table. To me, all of those are far more palatable than petty company politics (both in BigTech and startups).
When I've reported to founders they were front and center in the politics (which is probably how it should be).
Becoming a career CEO might be a way out, though.
A fish rots from the head down.
Yeah, and you can also get rid of local politics by moving to the countryside and homesteading. And you can bypass national politics by homesteading on a ship or an island that nobody cares about. And you can just move to a different planet to escape global politics. But any group of people will develop some form of politics, and to do anything meaningful longterm, you need a group of people, not just an individual, why not get better at politics? It is inevitable you will have to take part in them.
But of course, I still want my hut in the woods.
There's an even better way out, implement workplace democracy.
I used to run my own business when I was a child, and made a lot of money from it. Paid my way through school with my earnings. There was no sales or marketing, and all I did was product and engineering, and at no point was I politicking. So no, it's possible (albeit difficult) to not be part of the meat grinder, I have done it.
I am a solo founder literally to avoid ever having to deal with politics and video calls.
amen brother :)
Sure, to some degree it will always be there. But company size and careerist culture - both local to the company and differences between countries - makes it vastly different in presence.
politics is 100% escapable
>The easiest way is to actively work to make a high-profile project successful.
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."
All good advice; I would also advise doing whatever is possible to be considered personally useful by very important executive staff that you like personally, even if it means doing jobs that are trivial but showy for non-technical users (like dashboards). Once they like and trust you, pitch them an actually good idea that they can take credit for at the right time.
> It is simply a fact that software engineers are tools in the political game being played at large companies, not players in their own right.
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.
All great advice. But I wish I had spent more time asking myself whether I should spend my life eating crap and kissing someone’s butt in order to further someone else’s ambitions.
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.
I wish there were more articles on this topic. Politics is always something engineers have to suffer because, not a part of life in a way they could actively utilise, even though they are the core business-forming part of the lower ranking workforce.
Interesting articles.
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.
Interesting article.
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.
I think this article completely misses a critical point at staff level, being a force multiplier cross functionally.
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.
I build my entire career doing exactly this and after three decades in the industry, last one as a contractor, this is one of the very core things I do…
This is usually in big corps, so if you like working in these hellholes, then proceed with all these shenanigans. I worked there before and it's not really good for engineering, let alone engineers' mindset, because in addition to the actual technical stress, now you have to deal with all this bs from people who do nothing all day but these games. Small companies are the best for me, and I remember one time in a small company they hired a manager from a corp. In a year, he managed to fuck up everything, 4 engineers left including myself, and turned the work culture into rules and policies instead of adults working with each other towards a common goal.
The only problem is that big corps can pay so much more...
>Powerful stakeholders are typically so stupid and dysfunctional that it’s effectively impossible for you to identify their needs and deliver solutions to them
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.
The preceding paragraph says software engineers *believe* these things and has a footnote referencing HN discussion.
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.
> The easiest way is to actively work to make a high-profile project successful
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.
Where is the influence?
Instead of waiting to be told what to do and being cynical about bad ideas coming up when there's a vacumn and not doing what he wants to do, the author keeps a back log of good and important ideas that he waits to bring up for when someone important says something is priority. He gets what he wants done, compromising on timing.
"He gets what he wants done, compromising on timing." is a really good summary!
[dead]
glad to see someone being real and not parroting infuriating "politics is just learning how to interact with other humans narrative" .
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.
[dead]
[dead]
Based lol