Dealing with Friction: Office Politics, IT-Resistant Folks & Asshole Developers

The hardest part of coding isn’t the syntax—it’s the people. Between IT-resistant skeptics, senior devs with god complexes, and office politics that make Game of Thrones look tame, navigating the human side of tech is a skill of its own. This guide will help you survive (and maybe even thrive) in the madness. 🚀

The IT-Resistant Species: Identifying and Handling the Tech Skeptics

Some people treat new tech (or any tech) like it’s radioactive. The mere mention of automation, process changes, or (god forbid) AI sends them into a spiral.

How to handle them:

🚀 Speak their language. If they love spreadsheets, give them automation that makes their spreadsheets better. If they fear change, show them small, non-threatening improvements.

🗣️ Peer pressure works wonders. Find the office influencers—the gossip, the bro, the one everyone glances at for approval in meetings.

🎁 Give them a WOW factor. Something they don’t need but can’t ignore (think "free dessert" at a restaurant). Once they start raving about it, the rest will follow (and you’ll remind them to log a ticket like the process-loving gremlin you are).

🎭 The "accidental" rollout. Some folks hate change until they’re already using it: “Oh, you didn’t notice we automated half your job? Weird. But look at how much more time you have to complain now!”

Managing Senior Devs Who Think They’re Code Gods (But Are Actually Team Killers)

Some senior devs mistake "senior" for "entitled" rather than "experienced." They:

🔐 Hoard knowledge
🚫 Resist feedback
⚔️ Belittle junior devs
🕵️ Ignore team processes and build their own shadow workflows

Then they leave, and suddenly you're Indiana Jones swapping the idol for a bag of sand.

How to handle them:

🏆 Leadership isn’t about tenure—it’s about impact. Frame feedback as a way to help them cement their legacy rather than a threat to their ego.

❌ No one is irreplaceable. If they’re toxic, document everything and be ready to escalate.

🚌 The "bus factor." If a dev leaving would set the team back months, it's a ticking time bomb. Address it now.

Junior Devs: How Not to Be a Hero (And Why That’s a Good Thing)

New devs often try to prove themselves by:

⏳ Working late
🔥 Rewriting everything
🗣️ Arguing in every meeting

Advice for them:

⚖️ Pick your battles. No one is impressed by 2 AM commits that break production.

🪦 Nobody is writing your eulogy saying, "Died young, but he really refactored that monolith!" Take your time.

📈 Steady, high-quality work beats dramatic rewrites.

🤔 Ask questions, but don’t outsource thinking. Balance getting help with learning on your own.

Team Leads: Don’t Expect Thanks

A good team lead:

🛡️ Shoulders the blame
🎉 Shares the wins
🚧 Protects the team from BS

How to lead effectively:

🏅 Always give credit. If someone praises your team’s work, say: “Yeah, Simone really helped us out with that one.”

📢 Pass praise down. When you get back, tell Simone how impressed they were.

🔥 Take the heat. If something goes wrong, it’s your responsibility—not your devs'.

⚠️ Manage burnout before it happens. Signs to watch for:

• 🕵️ Your best dev suddenly goes quiet in meetings? They’re probably burning out, not "focusing deeply."

The Art of Managing Up (Because Your Boss Has No Idea What You Do)

Most engineering managers don’t have time to micromanage you (and if they do, they shouldn’t be managers).

How to work with them:

📌 Keep updates concise. They care about:

• 📅 Deadlines
• 💰 Budgets
• 😊 Team morale

🎯 Make their life easier. I once asked a CTO for his monthly board presentation and formatted my updates to match. He loved it. Did it make the board understand engineering better? Of course not. But it made my life easier.

📊 Match their communication style. Figure out if they’re:

• 📄 A "bullet points in an email" person
• 📊 A "slide deck" person
• 📈 A "data and graphs" person (because who doesn’t love a good graph?)

Surviving Office Politics Without Losing Your Soul

You can’t avoid politics, but you can avoid being a pawn.

Rules to survive:

🚷 Never get involved in drama that doesn’t affect your work directly.

⚔️ Pick your battles. Some fights are worth having. Others? Just grab the popcorn.

🐺 Lone wolves get eaten first. If leadership is making bad decisions, find allies.

🚪 If you can’t win, don’t fight. Some battles are decided before you even enter the room—figure out which ones.

🔥 Sometimes, the best move is to shut up, nod, and update your resume. As the great Thomas Jefferson said (according to Lin-Manuel Miranda): “If there’s a fire you’re trying to douse, you can’t put it out from inside the house.”

Code Reviews: Why Your "Nitpick" Might Actually Be a Problem

Some devs treat code reviews as a battleground for personal style preferences.

How to review code without being an ass:

🤝 Be kind, be clear, and pick your battles.

🛠️ If style/formatting is a constant fight, automate it.

• .editorconfig, Roslyn analyzers, pre-commit hooks—these exist for a reason.

🏛️ Every rule should have a reason. If it doesn’t, question it. Rules should evolve, not fossilize.

🧐 Before leaving a nitpick, ask yourself:

• "Does this meaningfully improve the code?"
• If not, close the tab, step outside, and touch some actual grass.

Final Thoughts

This is the reality of working in tech: you’ll deal with friction, egos, and politics. But with the right approach, you can navigate the chaos, protect your sanity, and maybe even enjoy the ride.