[HN Gopher] How I influence tech company politics as a staff sof...
___________________________________________________________________
How I influence tech company politics as a staff software engineer
Author : facundo_olano
Score : 242 points
Date : 2025-10-04 15:09 UTC (7 hours ago)
(HTM) web link (www.seangoedecke.com)
(TXT) w3m dump (www.seangoedecke.com)
| vcryan wrote:
| 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.
| woadwarrior01 wrote:
| There's a way out. Build your own company and make it something
| beneath you.
| antasvara wrote:
| 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.
| j16sdiz wrote:
| On that level, there are other policies.
|
| Politics in standards bodies, industrial organisations,
| regulatory issues, funding and investment, etc
| kylecazar wrote:
| 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.
| azemetre wrote:
| There's an even better way out, implement workplace
| democracy.
| eptcyka wrote:
| 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.
| AaronAPU wrote:
| I am a solo founder literally to avoid ever having to deal with
| politics and video calls.
| desireco42 wrote:
| amen brother :)
| vinnymac wrote:
| 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.
| elktown wrote:
| 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.
| bdangubic wrote:
| politics is 100% escapable
| eschneider wrote:
| Yeah, this approach largely works.
| hkon wrote:
| Where is the influence?
| tayo42 wrote:
| 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.
| anticristi wrote:
| "He gets what he wants done, compromising on timing." is a
| really good summary!
| zug_zug wrote:
| 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.
| SeanAnderson wrote:
| 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.
| mewpmewp2 wrote:
| What size companies have you worked at?
| SeanAnderson wrote:
| Relatively small. 50-100 people. I could see it being totally
| different at larger companies, but gosh it sounds miserable!
| bbminner wrote:
| 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.
| apwell23 wrote:
| > I can't relate to the opening remarks in this article at all.
|
| i am guessing you never got promoted at work?
| SeanAnderson wrote:
| I was a staff engineer at my last employer
| apwell23 wrote:
| 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.
| esafak wrote:
| > we had fresh grads with staff title.
|
| Your company was doing it wrong.
| apwell23 wrote:
| for sure. but thats not relevant to the point i was
| making.
| getnormality wrote:
| 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.
| Trasmatta wrote:
| I would rather not live my life with the sole purpose of people
| pleasing managers
| okdood64 wrote:
| What? This is what you are paid to do in your work life.
|
| This isn't a thread about your whole life.
| smallnix wrote:
| In case you can share an alternate strategy to make a career
| in a large tech company, please do, would be interested.
| Trasmatta wrote:
| That's the crux. I don't want a career in a large tech
| company.
| the_af wrote:
| Is working in a _small_ tech company any different?
| Trasmatta wrote:
| Not really, I'd love to get out of tech entirely.
| rjh29 wrote:
| 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.
| jcheng wrote:
| 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.
| Aurornis wrote:
| > 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.
| crystal_revenge wrote:
| > 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.
| ikiris wrote:
| > 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.
| crystal_revenge wrote:
| 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.
| mystifyingpoi wrote:
| > 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.
| crystal_revenge wrote:
| 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.
| bdangubic wrote:
| 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
| andrew_lettuce wrote:
| The politics in small companies are far more extreme in
| my experience.
| exodust wrote:
| 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.
| YZF wrote:
| 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.
| rafaelero wrote:
| 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.
| georgeburdell wrote:
| 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.
| tamimio wrote:
| "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..
| chausen wrote:
| 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.
| marcinzm wrote:
| 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.
| 010101010101 wrote:
| 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.
| codazoda wrote:
| 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?
| bradlys wrote:
| 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.
| varispeed wrote:
| > 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".
| akudha wrote:
| 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
| andrew_lettuce wrote:
| 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.
| marcinzm wrote:
| > 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.
| andrew_lettuce wrote:
| 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.
| marcinzm wrote:
| 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.
| Aurornis wrote:
| > 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.
| gmfawcett wrote:
| Very well expressed. That's great early-career guidance, but
| also a good refresher for many senior staff.
| notyourwork wrote:
| 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.
| maccard wrote:
| 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.
| mcv wrote:
| 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.
| varispeed wrote:
| 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.
| tamimio wrote:
| 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.
| mewpmewp2 wrote:
| The only problem is that big corps can pay so much more...
| Jgrubb wrote:
| > 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.
| masfuerte wrote:
| Not just a slide deck. The lobbyists have already written the
| legislation.
| awill88 wrote:
| Based lol
| moandcompany wrote:
| Understand what your boss's boss cares about and make sure your
| work can described in relation to those goals or concerns.
| MarkMarine wrote:
| 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.
| elevatortrim wrote:
| Do you mean if 1-pagers helped you get recognition and advance
| your career, or if they helped your ideas come to life?
| MarkMarine wrote:
| 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.
| anon84873628 wrote:
| 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.
| MarkMarine wrote:
| I didn't get a manual, just sharing what works for me so
| the next (new) staff and principals have one more data
| point.
| YZF wrote:
| 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.
| posix86 wrote:
| 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.
| codazoda wrote:
| > 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?
| softwaredoug wrote:
| 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.
| gjgtcbkj wrote:
| 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.
| jakeydus wrote:
| 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.
| Aurornis wrote:
| > - 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.
| awesome_dude wrote:
| 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
| Aurornis wrote:
| > 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.
| awesome_dude wrote:
| I'm in Australia, and I've yet to find a company that
| isn't broken.
| idiotsecant wrote:
| All companies are broken. Many companies are broken in
| ways that are tolerable or even decent.
| awesome_dude wrote:
| Look, if everyone could just run their companies how _I_
| think that they should be run we 'd all be happy :)
| aianus wrote:
| Have you tried working at a company with less than ~30
| people total? Those have been the best in my experience.
| maccard wrote:
| 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.
| whstl wrote:
| 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.
| halper wrote:
| 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!
| atomicnumber3 wrote:
| 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.
| leptons wrote:
| >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.
| cactusplant7374 wrote:
| 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.
| thaumasiotes wrote:
| > 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?
| apwell23 wrote:
| because thats their job description and not yours
| thaumasiotes wrote:
| 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.
| softwaredoug wrote:
| The VP is likely to get political backing to do a "big
| change" and leverage resources to make it not theoretical.
| apwell23 wrote:
| 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.
| johnfn wrote:
| 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.
| andrew_lettuce wrote:
| 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.
| jlund-molfese wrote:
| 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.
| creer wrote:
| 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.
| jlund-molfese wrote:
| 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.
| creer wrote:
| 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.
| awesome_dude wrote:
| 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
| creer wrote:
| > 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.
| awesome_dude wrote:
| Can you demonstrate, or show how that would work (serious
| question)
| creer wrote:
| 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.
| awesome_dude wrote:
| 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"
| kubav027 wrote:
| 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.
| creer wrote:
| > 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.
| gtowey wrote:
| 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.
| mrbombastic wrote:
| 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.
| fullstackwife wrote:
| 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.
| imiric wrote:
| > 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.
| apwell23 wrote:
| > 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.
| yinser wrote:
| You should consider finding a career coach, professional
| therapist. This level of pessimism can't be healthy.
| apwell23 wrote:
| why? i got director level by following those strategies. nor
| am i depressed. perhaps you are commenting about language in
| my post?
| josfredo wrote:
| 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".
| zwaps wrote:
| 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.
| marcinzm wrote:
| 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.
| procaryote wrote:
| 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
| anon84873628 wrote:
| 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.
| byte_surgeon wrote:
| 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.
| teiferer wrote:
| > 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.)
| byte_surgeon wrote:
| 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.
| fogzen wrote:
| 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.
| martin-t wrote:
| 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.
| braiamp wrote:
| > 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.
| oh_fiddlesticks wrote:
| >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."
| poisonborz wrote:
| 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.
| rzz3 wrote:
| >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.
| anon84873628 wrote:
| 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.
| rustystump wrote:
| 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.
| bdangubic wrote:
| 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...
| quacked wrote:
| 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.
| firesteelrain wrote:
| 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
| riazrizvi wrote:
| > 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.
| imiric wrote:
| 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.
___________________________________________________________________
(page generated 2025-10-04 23:01 UTC)