How I Influence Tech Company Politics as a Staff Software Engineer

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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