How I influence tech company politics as a staff software engineer

Obviously the context is after you and other people have asked; multiple times. You should interpret my comment with that reasonable preamble. And obviously as you say when people are being ambiguous or not communicating well, you memo what was communicated in writing. But that doesn't cure all organizational ills, not by a country mile.

It's nice if in your sample size you've personally only ever come across management chains that were trustworthy, competent and aligned. It's nice if you've only ever seen one unambiguous flow of truthful information from the bottom to the top and vice versa, and everyone's aligned to cooperate. But the alternatives abound.

I've seen (or been told of) directors battling other directors on organizational priorities, senior managers quietly undermining and deposing VPs so they could take their jobs, EVPs of sales selling capabilities that their own engineering had been telling them could never ship, the sales-side of an organization having a totally different roadmap than engineering and feeding it to a (nontechnical) CEO who couldn't tell which was accurate; CEOs putting out press releases about fictitious component their engineering was telling them they would not be available. Managers cheerily suppressing showstopper issue reports to send "mostly green/96% done"-type status reports up the pipe, on a project they knew to be doomed, before they completed their company-sponsored MBA then promptly jumped ship to a rival, and the company failed. Board members hyping underwater stock internally, only to quietly step down and immediately dump all their stock now they were no longer designated as privileged insiders. (Remember: once you go public, there are disclosure requirements and possibly shareholder class-actions, so even when something's universally known internally to be an issue, often executives can't acknowledge that, even internally (think "audit trail"); although you can infer a lot from their actions.)

Also you're presumably aware of some company cultures where internal secrecy and internal competition are fostered, pitting departments against each other (or at absolute minimum, where cooperation between departments is heavily discouraged, or punished). Or, in the middle of a product development cycle suddenly launching a "partner collaboration" or "strategic acquisition", where that is misaligned or competes with internal groups. Fear, intentional ambiguity, conflicting priorities as a management tool. Often this stuff is indirect evidence of conflicts at VP-level or higher; sometimes it's culture or force-of-habit.

Nobody said "forget" to inform the company or "departments ignoring clear and unambiguous directives". I implied misinforming or misleading groups/depts, or maintaining strategic ambiguity about what priorities were.

> What's the incentive for anyone to do this?

All of the above happen regularly, and it's pretty obvious what size and structure or organizations, and what individual metrics for compensation, and in particular when metrics are intentionally designed to be in conflict. For example, in a large company once you define separate "business units", people are overtly now working to differing metrics.

"conspiracies" and "go off on tangents" is a pretty disparaging way to misinterpret my question. You've never heard of any of the above ever being intentionally deployed? And "dysfunctional" might be our shared opinion, but I've heard from board members that passionately believe companies should be incentivized like that.

There's a reason Software Anti-Patterns (both technical and management) were recognized to exist several decades ago. [0] I think you're merely saying you haven't personally encountered them much.

For sure there are some engineers who treat standup like an annoying interruption to real work, or can't be articulate; equally there are scrum meetings where people play points hero or points olympics in inflating their perceived velocity. I've seen some adept operators nurse a weak spot in their part of the product so it could get closed then quickly reopened multiple times for multiple different customers, making them look great, but no mention of refactoring or adding testcases, or explanations of whether the thing was incorrectly closed or underestimated previously. Agile is only as good as the people overseeing it and measuring; it's easily gamed.

Communication does not happen merely because you mandate a 15-minute daily(/weekly) team meeting and tell people to do it; it only happens when people's official or unofficial incentives are generally roughly aligned to facilitate it. It's much easier to do that in a 10-person shop all working on the same product than 10,000 people, multiple teams, multisite, multiple products, dendritic orgchart, etc. You haven't really focused on the "managing perceptions" aspect of my question at all. There are certain breeds of middle-manager whose careers thrive on going into problem depts of large companies and cultivating the perception of them as firefighters/powerpoint-warriors, whether that's decoupled from reality or not, before they move on before the success/fail outcome becomes apparent. Again, misaligned incentives, and works best at the interface above which management stops being technical. If you're inside the dept in question, you can actually see how much of the perceived performance is objective verifiable fact vs managed perception. Or to put it another way to you, you've never seen people who are roughly as good as each other, yet one is more adept at managing perceptions?

It helps us gauge your personal experience if you tell us what size of team and organization and company stage (early starup/late-stage startup/small/large public company/etc.) you're anecdotally referring to.

[0]: https://en.wikipedia.org/wiki/Anti-pattern#In_software_engin...

It’s good advice for the average engineer who wants to chug along. Not exactly anything that would classify as “influence” though.

Great staff engineers actually set direction (which includes convincing management), instead of trying to coddle their managers. I particularly enjoy working with those - they’re rare findings (particularly in the usual American corporate culture)

They are the one in a position of power. Why do I have to ask?

Although we should notice the other side of that - managers that don't have an explicit onboarding where they lay that algorithm out for their reports are doing a terrible job. It is literally 3 lines. Lay it out at least once. Maybe go through it in a standup once a year. They are letting people slip through the cracks to the point where we have junior and even mid software engineers that don't realise there are priorities and that they should be working on them. Wow.

One of the reasons companies get dysfunctional is low- & mid-tier managers seem to be allergic to the idea of laying out what the priorities are and provide feedback on whether people are working on them or not.

>2. If your manager doesn't have something in particular they want you to do, you should figure out what they will want you to do in the future, and make any necessary preparations so that it will be doable when they want it.

Fuuuuck no. If he thinks you did it in 24 hours then he’ll expect you to do it in 24 hours next time too, instead of the three weeks it actually took you.

Work on something amazing. Also, who doesn’t have something to do???