Don’t Fear Power

Every engineer thinks they want a seat at the table. Until they actually get one.

Three years into my role as a Principal Engineer at [redacted], I found myself in a crucial architecture review meeting that would determine the technical direction of our entire platform. The room was filled with senior leaders, product managers, and fellow engineers. I had meticulously prepared our technical proposal, backed by weeks of research, benchmarks, and proof-of-concepts.

The proposal got absolutely destroyed. Not because of technical flaws – the engineering was solid. It died because I fundamentally misunderstood how decisions actually get made in large technical organizations.

See, I had made the classic engineer’s mistake: believing that the best technical solution would win on its own merits. I had spent countless hours perfecting our performance metrics and scalability projections, but virtually zero time building coalitions, understanding competing priorities, or managing key stakeholders before the meeting.

That painful experience taught me something crucial: technical excellence is necessary, but not sufficient for driving real change in tech organizations. True technical leadership requires understanding and effectively navigating power dynamics – something most engineers are never taught and often actively resist learning.

After 15+ years building and leading engineering teams across various tech companies, and countless conversations with friends at FAANG giants about their experiences, I’ve learned that power in tech organizations operates by a specific set of rules. Rules that might make many engineers uncomfortable, but that you ignore at your own career’s peril.

Let’s talk about how power actually works in tech companies – not the sanitized version you’ll find in management books, but the real, messy, human dynamics I’ve observed and tested throughout my career.

The Reality Check

Most engineers I know have a deeply uncomfortable relationship with organizational power. There’s this persistent belief in our industry that technical merit alone should drive decisions – as if we’re all living in some pure meritocracy where the best code always wins.

I see this mindset everywhere: in the senior engineer who believes their decade of technical excellence should speak for itself, in the team lead who avoids playing politics on principle. In the architect who thinks detailed technical documents will somehow magically convince the organization to adopt their solution. I was all of these people in the past. It felt noble.

Let me be brutally honest: this mindset is career suicide.

The reality I’ve observed across multiple companies (and heard echoed by friends at every major tech company) is far messier. Technical decisions are rarely made on purely technical grounds. They’re made through a complex web of relationships, timing, organizational priorities, and yes – politics.

Here’s what I mean:

That architectural decision? It’s just as much about who you convinced before the meeting as it is about your elegant system design.
That promotion you’re aiming for? It depends as much on who knows your work as it does on the work itself.
That critical project you want to launch? Its success hinges as much on stakeholder management as it does on clean code.

“But that’s not fair!” I hear you say. “We should focus on building great technology, not playing political games!”

I used to think exactly the same way. Then I watched project after project fail not because of technical problems, but because I and other engineers refused to engage with organizational dynamics. I saw brilliant technical solutions get shelved while objectively inferior approaches won out, simply because their champions understood how to navigate the system.

Here’s the uncomfortable truth: by refusing to engage with organizational power dynamics, you’re not taking some noble stand. You’re just choosing to be powerless. And when competent engineers choose to be powerless, we all lose – because it means important technical decisions end up being made by people who might not understand their full implications.

Think about it this way: Would you deploy code without understanding how it works? Would you integrate with a system without learning its protocols? Of course not. Yet, many of us try to navigate organizations without understanding their fundamental operating principles.

Rule 1: Get Out of Your Own Way

Let’s start with the biggest obstacle to your effectiveness as a technical leader – and I can say this with confidence because it was my biggest obstacle for years.

It’s not your technical skills. It’s not your company’s processes. It’s not even your manager.

It’s the stories you tell yourself about power and influence.

I see these self-limiting narratives play out constantly in engineering teams. They usually sound something like this:

“I’m just a tech person, I don’t understand office politics”
“If I focus on anything besides coding, I’m selling out”
“Leadership should recognize my work without me having to promote it”
“I’m not ready for that role/project/promotion yet”
“Seeking influence feels manipulative”

Sound familiar? I cringe remembering how many times I repeated these exact phrases to myself.

Here’s a real example: A couple of years ago, our company needed someone to lead a critical platform migration. I initially held back from volunteering because I didn’t feel “ready” – I thought I needed to understand every technical detail perfectly first. Meanwhile, a peer with less technical expertise but more confidence stepped up. Guess who got to shape the entire technical direction of our platform for the next year?

The engineering mindset that makes us excellent at building systems often sabotages us when it comes to building influence. We’re trained to identify every potential point of failure, to anticipate edge cases, to strive for perfection. These are fantastic traits for writing reliable code. They’re paralyzing when applied to organizational dynamics.

Look, I get it. The idea of actively seeking power or influence can feel uncomfortable, even dirty. But here’s what I’ve learned: power isn’t inherently good or bad – it’s a tool. And like any tool, its impact depends entirely on how you use it.

Think of it this way: Would you rather have technical decisions made by people who deeply understand and care about engineering excellence, or by those who just happened to be better at playing the game?

The first step in getting out of your own way is recognizing these self-limiting beliefs for what they are – bugs in your mental model of how organizations work. They’re not protecting your integrity; they’re limiting your impact.

Ready to break this down into actionable steps?

Start noticing your automatic “no”s
When opportunities arise, pay attention to your instant rejections. Are they based on real limitations, or just comfortable excuses?
Challenge your “readiness” assumptions
You’ll never feel 100% ready. Neither does anyone else. The difference is they act anyway.
Reframe “politics” as “organizational dynamics”
It’s not about manipulation; it’s about understanding how human systems work.
Audit your self-talk
Replace “I’m not a political person” with “I can learn to be more influential while staying true to my values.”

Rule 2: Break the Rules Strategically

Some of the most impactful technical changes I’ve seen weren’t approved – they were apologized for after the fact.

Let me share a story that changed my whole perspective on rule-breaking in tech organizations. At a previous company, we had this painfully slow approval process for new technologies. Every new library or tool needed to go through three different committees. Standard big-company stuff.

One of our senior engineers decided this was killing innovation. Instead of following the process for adding a new caching layer, he quietly built a proof-of-concept during a hack week, demonstrated it solving real production issues, and presented it as a fait accompli. Was management initially annoyed? Absolutely. Did it matter once they saw the 30% performance improvement? Not one bit.

Here’s the key: he broke the rules strategically. He didn’t ask for permission, but he also didn’t recklessly ignore legitimate concerns. He built in monitoring, wrote thorough documentation, and had a rollback plan ready. In other words, he broke the process rules while respecting the engineering principles behind them.

This is what I call “strategic rule-breaking,” and it’s a crucial skill for driving change in tech organizations. But – and this is important – it’s not about being a cowboy coder or ignoring processes for the sake of it.

Here’s my framework for strategic rule-breaking:

Identify the “Real” Rules vs. the “Process” Rules

Real Rules: Security requirements, data privacy, production stability
Process Rules: Approval chains, documentation formats, meeting requirements

Calculate the Risk-to-Impact Ratio

High Impact, Low Risk: Perfect for strategic rule-breaking
High Impact, High Risk: Need more preparation and safety nets
Low Impact: Not worth the political capital

Build Safety Nets

Have a rollback plan
Document everything
Monitor obsessively
Build quiet support before going public

Choose Your Battles — I’ve seen too many engineers die on hills that didn’t matter. Save your rule-breaking capital for things that really move the needle.

Here are some examples of strategic rule-breaking that I’ve seen work:

Bypassing the full approval process by building a prototype “just for testing”
Using a new technology in a non-critical service to prove its value
Creating a “shadow” documentation system that people actually use
Starting informal cross-team collaborations without going through official channels

And here are some that usually backfire:

Pushing code directly to production to skip code review
Ignoring security protocols to ship faster
Surprising executives with major architecture changes
Breaking team processes without bringing others along

The art of strategic rule-breaking is knowing which rules protect the organization and which ones protect the status quo. The former deserve our respect; the latter deserve our scrutiny.

The goal isn’t to be a rebel. The goal is to drive positive change. Sometimes that means working within the system. Sometimes it means creating a new path. The trick is knowing which approach serves your ultimate objective better.

Rule 3: Master Your Presence

Let me tell you about two architects I’ve worked with. Both were brilliant technically. Both had deep system knowledge. Both regularly presented architecture proposals to senior leadership.

The first one, Alex, would dive deep into technical details, qualifying every statement with “I think” or “maybe.” Their presentations were technically flawless but filled with caveats and nuance.

The second, Sarah, would start with the business impact, speak with conviction, and save the technical details for Q&A. Her proposals weren’t always technically superior to Alex’s, but guess whose architectures got approved more often?

“But that’s just politics!” I used to think. “We should focus on technical merit!”

Here’s the reality I’ve learned: Your presence – how you carry yourself, communicate, and show up in rooms where decisions are made – matters just as much as your technical chops. It’s not about manipulation; it’s about effectively conveying your expertise.

The good news? Presence is a technical skill like any other. You can debug and optimize it.

Here’s my technical spec for commanding presence:

Core Components:

Voice Configuration

Remove hedge words (“just,” “maybe,” “I think”)
Lower your tone at the end of sentences
Pause for effect after important points
Speak 20% slower than you think you should

Body Language Settings

Take up physical space (don’t shrink in your chair)
Keep your hands visible and use deliberate gestures
Maintain eye contact 60-70% of the time
Stand when presenting (even on Zoom, it affects your voice)

Communication Protocol

Start with impact, not implementation
Use silence strategically (don’t fill every gap)
Answer the question that should have been asked
Learn to say “I don’t know” without apologizing

Emotional State Management

Channel nervousness into focused energy
Practice controlled emotional expression
Stay calm during confrontation
Use passion strategically

Implementation Examples:

Instead of: “I think maybe we could try implementing a caching layer which might improve performance…”

Say: “Adding a caching layer will improve response times by 40%. Here’s how…”

Instead of: “Sorry, I don’t know the exact numbers off hand…”

Say: “I’ll get those specific numbers for you. The key point is…”

Instead of: “This might be a stupid question, but…”

Say: “I want to make sure I understand correctly…”

Error Handling:

If you make a mistake, acknowledge it clearly and move on
If you lose composure, take a deliberate pause
If challenged, respond to the intent behind the question
If you ramble, stop and reset with a clear statement

Advanced Features:

Reading The Room

Notice power dynamics
Track engagement levels
Identify allies and skeptics
Adapt in real-time

Energy Management

Match then lead the room’s energy
Use intensity variations purposefully
Create momentum at key points
Know when to pull back

Presence isn’t about being the loudest or most charismatic person in the room. It’s about ensuring your technical expertise gets the attention and respect it deserves.

I still see too many brilliant engineers whose ideas get overlooked not because they’re wrong, but because they haven’t mastered the art of presence. Don’t let that be you.

Rule 4: Build Your Tech Leadership Brand

Most engineers don’t like the idea of a “personal brand.” It feels fake, corporate, inauthentic – everything we hate about modern workplace culture.

But here’s the reality: You already have a brand. It’s what people say about you when you’re not in the room. The only question is whether you’re actively shaping it or letting it develop by default.

I learned this lesson the hard way. For years, I was known as “the debugging guy” – great for job security, terrible for career growth. Every production issue landed on my desk, while strategic architectural decisions happened without me. I had accidentally branded myself into a corner.

Think of your tech leadership brand as an API. What endpoints are you exposing? What’s your interface contract with the organization? Most importantly, what responses are you known for generating?

Here’s how to architect your tech leadership brand:

Core API Endpoints:

Technical Expertise

Document your knowledge (write those design docs!)
Share learnings from incidents
Create reusable solutions
Mentor other engineers

Strategic Thinking

Connect technical decisions to business impact
Propose forward-thinking solutions
Question status quo constructively
Think in systems, not just features

Problem Solving

Take on complex challenges
Drive cross-functional solutions
Build coalitions across teams
Share your thought process

Reliability

Keep your commitments
Communicate proactively
Handle pressure gracefully
Be consistent in your interactions

Implementation Patterns:

Internal Visibility

Write technical blog posts for your company wiki
Lead architecture reviews
Host brown-bag sessions
Contribute to design docs
Participate in code reviews meaningfully, not just rubber-stamping

External Recognition

Speak at industry conferences (or even just local meetups)
Write blog posts about solved problems
Contribute to open source
Share learnings on social media (without breaking confidentiality)

Relationship Building

Build allies across departments
Mentor junior engineers
Support peer growth
Connect with leaders in other teams

Anti-Patterns to Avoid:

Being the “no” person who shoots down ideas without alternatives
Becoming the “emergency only” engineer
Getting pigeonholed into one technology or system
Being known only for pointing out problems
Developing a reputation for perfectionism that blocks progress

Real Example: A few years ago, I noticed I was being left out of crucial platform decisions. After some feedback, I realized I was known as someone who “makes things too complex.” Fair criticism – I love elegant solutions. So I deliberately started prefacing my suggestions with simplified versions that could be built upon later. Within months, I was being pulled into architectural discussions earlier because people knew I could “break down complex problems.”

Brand Monitoring:

Pay attention to how you’re introduced in meetings
Notice which problems get routed to you
Watch for patterns in feedback
Monitor what kind of questions you’re asked
Track which meetings you’re invited to (or not)

Course Corrections: If you find your brand isn’t serving you:

Identify the gap between current and desired perception
Create opportunities to demonstrate desired traits
Find allies who will vouch for your growth
Actively seek roles that align with your target brand
Gradually shift your contribution patterns

Your technical brand isn’t about self-promotion. It’s about making your value visible so you can have maximum impact.

Rule 5: Network in Engineering Organizations

“I hate networking.”

I’ve heard this from virtually every engineer I’ve ever mentored. And I get it. The word conjures up images of awkward meetups, insincere LinkedIn messages, and that one sales guy who won’t stop talking about synergy.

But here’s the truth: the most successful engineers I know are all exceptional networkers. They just don’t call it networking. They call it “grabbing coffee to discuss that interesting scaling problem,” or “helping debug that weird production issue,” or “whiteboarding that new architecture idea.”

About 10 years ago, our team was fighting for resources to rebuild a critical service. Despite clear technical merit, we couldn’t get traction. Then I discovered another team had already solved 60% of our problems in their domain. Not through official channels – I learned this over lunch with their tech lead, someone I’d met during an overnight production incident. Within weeks, we had a shared roadmap and twice the resources.

That’s real engineering networking. Not exchanging business cards, but building a web of technical relationships that amplify your effectiveness.

Here’s how to network like an engineer:

Technical Alliance Building:

Cross-Pollination

Join architecture review boards
Participate in post-mortems (even for other teams)
Contribute to shared libraries
Review PRs outside your immediate team

Knowledge Exchange

Host technical brown bags
Start an engineering book club
Create internal tech newsletters
Build shared documentation

Problem-Solving Networks

Debug sessions
System design discussions
Code reviews
Incident response

Authentic Connection Building:

Follow the Trail of Interesting Problems

Who’s solving similar challenges?
Who has expertise you need?
Who could benefit from your lessons learned?
Who’s working on tech you want to learn?

Create Value First

Share useful documentation
Offer code review help
Provide technical mentorship
Build tools others can use

Maintain Genuine Relationships

Follow up on technical discussions
Share relevant articles/papers
Remember personal details
Celebrate others’ wins

Anti-Patterns to Avoid:

Only networking when you need something
Staying within your technical comfort zone
Treating every interaction as a transaction

Real Example: One of my best engineers maintains a simple system: Every week, she has lunch with someone from a different engineering team. No agenda, just a random technical discussion. These lunches have:

Prevented duplicate work across teams
Surfaced common problems we could solve together
Created back-channel communication paths that proved crucial during incidents
Built a network of allies for larger technical initiatives

The ROI of Technical Networking:

Faster Problem Solving

Know who to ask
Access tribal knowledge
Get rapid feedback
Find existing solutions

Career Opportunities

Hear about projects early
Get recommended for roles
Find mentors naturally
Build your reputation

Technical Influence

Build support for initiatives
Gather early feedback
Create coalition for change
Access different perspectives

Effective networking in engineering is about building a distributed system of knowledge and capabilities. Each connection is a potential API you can call when needed.

Rule 6: Actively Use Your Power (for good)

The biggest mistake new engineering leaders make isn’t abusing power – it’s being afraid to use it at all.

I watched a talented staff engineer on my team sit silently through six months of architecture meetings, carefully building consensus for every minor decision. Meanwhile, tech debt accumulated, deadlines slipped, and morale dropped. Their fear of being “too pushy” was actually hurting the team.

Here’s the counterintuitive truth I’ve learned: Thoughtfully exercising power makes you more influential, not less. When used well, power creates momentum, builds trust, and drives results.

Let me break this down:

Types of Power in Engineering Organizations:

Technical Authority

Architecture decisions
Technology choices
Quality standards
Technical direction

Resource Control

Project prioritization
Team allocation
Budget influence
Tool selection

Information Access

System knowledge
Historical context
Cross-team insights
Strategic planning

Relationship Capital

Trust from leadership
Team loyalty
Cross-functional allies
External networks

Using Power Effectively:

Decision Making

Make clear decisions when you have authority
Own the consequences
Explain your reasoning
Stay consistent

Setting Standards

Define what good looks like
Hold the line on quality
Push back on unreasonable demands
Model best practices

Protecting Your Team

Shield from organizational chaos
Push back on unrealistic deadlines
Fight for resources
Create space for focus

Driving Change

Challenge broken processes
Question assumptions
Propose solutions
Lead by example

Real Example: Three jobs back, our team was drowning in technical debt while leadership pushed for new features. Instead of just complaining, I:

Used my management authority to declare two weeks of cleanup work
Leveraged my relationships to get buy-in from product
Applied my resource control to prioritize critical fixes
Drew on my information access to demonstrate the long-term cost of inaction

The result? Short-term pushback but long-term respect. The team’s velocity improved 40% over the following months.

Common Power Mistakes:

The Consensus Trap

Trying to get everyone to agree
Avoiding necessary conflict
Diluting decisions
Paralysis by discussion

The Perfectionist Block

Waiting for complete information
Over-engineering solutions
Analysis paralysis
Endless refinement

The Authority Dodge

Deferring to hierarchy unnecessarily
Hiding behind process
Avoiding responsibility
Playing it safe

The Power Vacuum

Not setting clear direction
Allowing drift
Ignoring problems
Avoiding tough conversations

Power Use Framework:

Evaluate the Situation

What authority do you have?
What’s at stake?
Who’s impacted?
What’s the timeline?

Consider Options

Direct action
Influence approach
Coalition building
Gradual change

Execute Decisively

Clear communication
Defined timeline
Success metrics
Follow-through

Own the Outcome

Monitor impact
Adjust as needed
Learn from results
Share learnings

Power isn’t about control – it’s about impact. Used thoughtfully, it’s how we turn technical expertise into organizational change.

Rule 7: Deliver Results and Control the Narrative

The most painful lesson I’ve learned in tech leadership? Great results don’t speak for themselves. In fact, they barely whisper.

Let me share a story that still makes me cringe: My team once completed a massive infrastructure migration – on time, under budget, zero downtime. A genuine technical triumph. But six months later, in my performance review, my CTO mainly remembered the two small outages during the project. Why? Because I let others control the narrative about our work.

Meanwhile, a peer team’s partial migration of a less critical system was celebrated as a massive win. The difference? They treated communication as a core part of delivery, not an afterthought.

Here’s how to make sure your results actually land:

The Results-Narrative Framework:

Before You Start

Set clear success metrics
Document current pain points
Identify key stakeholders
Establish baseline measurements

During Execution

Regular status updates
Early wins communication
Proactive issue management
Stakeholder engagement

After Completion

Impact quantification
Success story crafting
Lessons learned sharing
Credit distribution

Narrative Control Patterns:

Frame the Context

Why this matters
What’s at stake
Who benefits
How it fits strategic goals

Shape the Story

Clear before/after
Concrete improvements
Relatable examples
Memorable metrics

Control the Flow

Regular updates
Consistent messaging
Strategic timing
Multiple channels

Real Examples of Effective vs. Weak Narratives:

Weak: “We improved database performance.”

Strong: “We cut customer wait times by 40% by optimizing our database, directly improving our most common user workflow and saving 1,000 engineering hours per quarter.”

Weak: “The migration is complete.”

Strong: “We’ve eliminated our biggest source of production incidents by migrating to the new platform, reducing on-call burden by 60% and enabling three new strategic initiatives.”

Common Narrative Mistakes:

Focusing purely on implementation
Drowning in details
Missing business impact
Ignoring non-technical stakeholders
Downplaying achievements
Avoiding self-promotion
Hiding team wins
Assuming visibility
No success metrics
Poor progress tracking
Unclear impact
Lost context
Not recognizing contributors
Hoarding visibility
Failing to build allies
Missing team celebrations

Building Your Narrative System:

Documentation

Keep an “achievements” document
Track metrics religiously
Document key decisions
Save positive feedback

Communication Channels

Regular status emails
Team demos
Executive updates
Cross-team sharing

Stakeholder Management

Regular check-ins
Progress previews
Early feedback loops
Success sharing

Team Amplification

Highlight individual contributions
Create visibility opportunities
Share credit broadly
Build advocacy networks

Your results create value, but your narrative multiplies it. The best technical solution only matters if people understand and remember its impact.

A Summary – tl;dr

Seven rules. Thousands of lines of code. Countless meetings. And one fundamental truth: technical excellence alone won’t get you where you want to go.

I started this post by sharing my own painful architecture review failure. Since then, we’ve explored how power actually works in tech organizations, and how to use it effectively while staying true to our engineering values.

Let’s recap what we’ve covered:

The Seven Rules of Power in Tech:

Get Out of Your Own Way — Your limiting beliefs are your biggest bottleneck
Break the Rules Strategically — Know when process serves progress and when it serves politics
Master Your Presence — Command attention like you command your code
Build Your Brand — Shape how your value is perceived
Network in Engineering Organizations — Build your distributed system of influence
Actively Use Your Power — Impact requires action, not just position
Deliver Results and Control the Narrative — Great work invisible is still invisible

But here’s what keeps me up at night: Too many brilliant engineers opt out of this game entirely. They see the complexity of organizational dynamics and decide it’s not worth engaging with. They retreat into their technical comfort zones, letting others make the decisions that shape our industry’s future.

We can’t afford that anymore.

The stakes are too high. The technical decisions being made today will shape how we build software for years to come. We need strong technical voices in those conversations. We need engineers who can navigate both technical complexity and organizational dynamics. We need you to step up.

Yes, it’s messy. Yes, it’s uncomfortable. Yes, it requires skills they didn’t teach you in CS classes. But so did distributed systems, and you figured those out.

Think of organizational dynamics as just another system to debug. It has its protocols, its failure modes, its optimization opportunities. The rules I’ve shared aren’t about playing politics – they’re about understanding and effectively operating within human systems.

The question isn’t whether you’ll engage with power dynamics. You already are. The question is whether you’ll do it intentionally and effectively.

Where to start? Pick one rule that resonates with you. The one that made you most uncomfortable might be the best candidate. Start small. Run experiments. Debug your approach. Iterate.

Remember: Your technical expertise is valuable. But your ability to drive change through an organization – to turn that expertise into impact – that’s invaluable.

The future of tech is too important to leave to chance. Or to leave to those who might not understand the full implications of their technical decisions.

It’s time for engineers to step up. To learn these skills. To engage with these dynamics. To drive change.

Your code deserves to be deployed. Your ideas deserve to be heard. Your expertise deserves to shape the future.

But first, you need to understand how power works.

What’s your next commit(ment) going to be?