Let’s address the most radioactive element in your team’s periodic table: the brilliant, toxic developer who you just can’t fire. L can’t We all know the type. The kind of engineer who codes like a wizard but communicates like a warlord. They ship flawless architecture in half the time... then blow it all up with a single Slack message. Worse, they’re considered “untouchable”, maybe because they own critical infrastructure, they’re the only one who understands your legacy system, or they’ve got execs wrapped around their Git history. Here’s the uncomfortable truth: you don’t need to fire them to fix the damage. But you do need a strategy. One that protects your team’s culture without lighting a fuse under your best coder. do Let me show you what actually works. 1. Acknowledge Their Brilliance Without Worshipping It 1. Acknowledge Their Brilliance Without Worshipping It Toxic devs often thrive in environments where their intellect is equated with immunity. Be clear: "We appreciate your expertise, but that doesn’t give anyone a pass on behavior." "We appreciate your expertise, but that doesn’t give anyone a pass on behavior." You can praise their output while still holding them accountable. It’s not about diminishing their genius; it’s about balancing it with team harmony. If their presence erodes morale, the entire team’s velocity drops (even if this person is dragging three features across the finish line solo). Try this: A private 1:1 where you explicitly separate their technical contributions from the interpersonal issues. Use neutral, observable facts. No loaded language like "arrogant" or "difficult"; just call out the impact. "When you criticized the database decision in the group chat, two junior devs told me they were afraid to speak up afterward. That slows down our collaboration." This isn’t about emotions; it’s about outcomes. When psychological safety disappears, so does innovation. Toxicity isn’t just a people problem. It’s a productivity problem. 2. Set Boundaries Like It’s Your Job (Because It Is) 2. Set Boundaries Like It’s Your Job (Because It Is) Brilliance can make people bold. But left unchecked, it turns into entitlement. If you let this dev set their own rules like skipping standups, ghosting code reviews, dominating architecture decisions, you’re reinforcing the idea that they’re above the system. Set expectations in writing. Include: Code review participation rules
Communication norms (e.g., respectful critique, no public shaming)
Response times and task ownership Code review participation rules Communication norms (e.g., respectful critique, no public shaming) Response times and task ownership You’re not micromanaging. You’re putting bumpers on a bowling lane. And here’s the kicker: enforce those boundaries for everyone. everyone If this dev sees others getting away with sloppiness, they’ll justify their own rule-breaking. Consistency is your armor. Also, be ready to repeat yourself. High performers often test limits as a way to seek validation or control. 3. Redirect the Ego: Make Them a Mentor 3. Redirect the Ego: Make Them a Mentor This sounds counterintuitive. Why give more influence to someone who already causes friction? Because ego isn’t the enemy. Unchanneled ego is. Unchanneled Assign this dev as a mentor to a high-potential junior (someone resilient). It creates two effects: It gives them a new identity: "mentor" instead of "lone genius."


It humanizes their teammates. It’s harder to trash talk someone you’re coaching. It gives them a new identity: "mentor" instead of "lone genius." It gives them a new identity: "mentor" instead of "lone genius." It humanizes their teammates. It’s harder to trash talk someone you’re coaching. It humanizes their teammates. It’s harder to trash talk someone you’re coaching. Make it clear the goal isn’t just technical transfer. It’s also about collaborative maturity. If they do well, recognize it. If they struggle, use it as a mirror: "This junior dev finds it hard to ask you questions. Let’s explore why." You're using their strength (technical excellence) to heal their weakness (poor collaboration). This shift in role can spark a transformation. Many devs want to be seen as leaders but don’t know how. Give them the playbook, and hold them to it. 4. Shield the Team Without Feeding the Drama 4. Shield the Team Without Feeding the Drama Sometimes, shielding the rest of your team is less about changing the toxic dev and more about buffering everyone else. Run post-mortems that focus on process, not people. Use anonymous feedback tools. Normalize phrases like: process "Let's prioritize clarity over cleverness."
"All feedback should be kind, specific, and actionable." "Let's prioritize clarity over cleverness." "All feedback should be kind, specific, and actionable." Create psychological safety. You want your devs to take risks, ask dumb questions, and push back—even in front of the most intimidating teammate. Team culture is more fragile than you think. It only takes one unchecked outburst to make someone quietly start looking for a new job. And remember: if your other team members start to check out, you’ve got a bigger problem than one high-performing jerk. And remember: if your other team members start to check out, you’ve got a bigger problem than one high-performing jerk. 5. Document Everything and Build Redundancy 5. Document Everything and Build Redundancy This is your insurance policy. If this dev is truly unfireable now, they shouldn't stay that way forever. now Start by building documentation. Pair them up on critical tasks so no system is a black box. Normalize knowledge-sharing sessions and rotate ownership of legacy code. Make them less of a bottleneck without making it obvious. Then document every incident of toxic behavior. Dates. Screenshots. Impacts. Quietly build a case that HR or leadership can’t ignore. You’re not plotting revenge. You’re preparing an option. option Because someday, someone will ask, "Why didn’t we act sooner?" And you’ll have an answer. will Having documentation also helps protect you and the team. It turns vague discomfort into visible patterns. Conclusion Conclusion There’s a fine line between brilliance and burnout. And sometimes that line runs straight through the smartest person on your team. T As a tech lead or manager, your job isn’t to cater to ego. It’s to cultivate a culture where everyone can thrive. That means giving your toxic star a path to improve, but never letting them hold the rest of the team hostage. everyone You don’t need to choose between code quality and team sanity. Lead both. And if you play it right, you might just turn your toughest dev into your most surprising success story. Or, at the very least, a slightly less grumpy genius. Got a toxic dev story that ended with a twist? Drop it in the comments.

How to Handle a Dev Who’s Brilliant, Toxic, and Unfireable, if You're a Technical Lead

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How to Use Automation to Keep Your Business Secure and Compliant in a Cloud-First World

Rules of Thumb for Software Engineering

The Noonification: How to Implement a Merkle Tree in Solidity (11/19/2023)

10x engineers take long naps

The Noonification: Perfect Duty Engineer (11/10/2022)

How to Use Automation to Keep Your Business Secure and Compliant in a Cloud-First World

Rules of Thumb for Software Engineering

The Noonification: How to Implement a Merkle Tree in Solidity (11/19/2023)

10x engineers take long naps

The Noonification: Perfect Duty Engineer (11/10/2022)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps