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