What I Wish More Engineers Understood About Power

Engineers often talk about power indirectly. They talk about alignment, influence, buy-in, escalation, ownership, and politics. Those words are useful, but they can hide the simpler reality: organizations allocate power, and engineering work is shaped by it.

Pretending power does not exist does not make engineering more pure. It makes engineers easier to surprise.

The thesis

Power is part of the architecture of an organization. Senior engineers need to understand it without becoming cynical.

Power decides which problems get attention, which risks are accepted, which tradeoffs are legitimate, and whose pain becomes visible. Technical judgment that ignores power often arrives late or lands poorly.

The production pattern

A technically correct recommendation fails. Not because the design is wrong, but because it threatens a deadline, budget, status boundary, product promise, or executive narrative. The engineer concludes that the organization does not care about quality.

Sometimes that is true. More often, the recommendation did not account for the full decision system.

Power is not only hierarchy. It also comes from owning a roadmap, holding scarce expertise, controlling budget, carrying user context, maintaining operational burden, or being trusted to synthesize ambiguity.

The model

I use a five-part model:

1. Formal authority: Who can approve, block, fund, or staff the work?
2. Operational authority: Who lives with the consequences when the system fails?
3. Narrative authority: Who defines what problem the organization thinks it is solving?
4. Expert authority: Who has credibility because they understand the domain deeply?
5. Relationship authority: Who is trusted enough to carry bad news without triggering defense?

Before pushing a major technical direction, I ask:

• Which authority types support this change?
• Which authority types feel threatened by it?
• Who pays the cost before the benefit appears?
• Who needs a different narrative, not more technical detail?
• What decision is formally required, and what trust is informally required?

This is not manipulation. It is situational awareness.

Where this goes wrong

The cynical failure mode is treating power as the only thing that matters. That leads to gamesmanship, shallow alignment, and technical decay hidden behind confident messaging.

The naive failure mode is treating power as dirty. That leads to avoidable frustration and late escalation. If a technical risk needs funding, prioritization, or behavior change, it is already a power question.

The counterpoint is that some situations require direct refusal. Understanding power does not mean accommodating every incentive. Sometimes the responsible act is to state the risk plainly, document the tradeoff, and decline to bless a decision.

What I do now

I try to separate three questions:

• What is technically true?
• Who has the power to act on it?
• What responsibility do I have if they choose not to?

That separation keeps me from confusing correctness with influence. It also keeps me from pretending influence is the same as integrity.

At principal level, power literacy matters because the work often crosses boundaries. A principal engineer must move technical truth through a social system without diluting it beyond usefulness.

The responsibility test

Power literacy should end in responsibility, not cleverness. I use a simple test when I am close to a power-sensitive decision.

First, what do I know technically that the decision system may be underweighting? Second, who is exposed if that truth is ignored? Third, what is the least dramatic way to make the risk visible to someone who can act? Fourth, what record should exist if the organization chooses a different tradeoff? Fifth, what line would I refuse to cross?

The fifth question matters because influence work can become self-erasing. An engineer may soften the message to stay in the room, then soften it again to preserve momentum, then discover that the technical truth has been converted into vague concern. That is not diplomacy. That is loss of signal.

The opposite failure is moral performance: escalating in a way that protects the engineer's identity but does not improve the decision. Power-literate communication tries to preserve both truth and usefulness. It names consequence, offers options, and makes the decision owner visible.

Used well, power literacy helps engineers spend less time being surprised and more time making responsible tradeoffs explicit.

There is also an operating checklist before escalation. Have I explained the risk in the language of the decision owner? Have I separated certainty from concern? Have I offered a lower-risk path, not only an objection? Have I named the consequence of doing nothing? Have I chosen the smallest audience that can responsibly act?

Those questions keep power literacy grounded in service of the work.

Closing takeaway

Do not worship power and do not ignore it. Map it, respect its consequences, and use your technical credibility to make better decisions possible.