How to influence tech company politics as a staff software engineer

Having the right idea handy at the right time is your responsibility.

The important thing is to have a detailed, effective program of work ready to go for whatever the flavor of the month is.

make your pet idea available for an existing political campaign. Suppose you’ve wanted for a while to pull out some existing functionality into its own service. There are two ways to make that happen.

The hard way is to expend your own political capital: drum up support, let your manager know how important it is to you, and slowly wear doubters down until you can get the project formally approved. The easy way is to allow some executive to spend their (much greater) political capital on your project. You wait until there’s a company-wide mandate for some goal that aligns with your project (say, a push for reliability, which often happens in the wake of a high-profile incident). Then you suggest to your manager that your project might be a good fit for this. If you’ve gauged it correctly, your org will get behind your project. Not only that, but it’ll increase your political capital instead of you having to spend it.

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.

In my experience, this is where companies make their worst technical decisions: when the political need to do something collides with a lack of any good ideas. When there are no good ideas, a bad idea will do, in a pinch.

Organizational interest comes in waves. When it’s reliability time, VPs are desperate to be doing something. They want to come up with plausible-sounding reliability projects that they can fund, because they need to go to their bosses and point at what they’re doing for reliability, but they don’t have the skillset to do it on their own. They’re typically happy to fund anything that the engineering team suggests. On the other hand, when the organization’s attention is focused somewhere else - say, on a big new product ship - the last thing they want is for engineers to spend their time on an internal reliability-focused refactor that’s invisible to customers.

Scheming takes practice and power, and neither of those things are available to software engineers.