Getting Through The Week When Your coworker Makes You Want to Quit
You got assigned to a joint project with someone you actively dislike. Maybe they stole credit for your work last quarter. Maybe they're incompetent and you're the one who has to clean up after them. Maybe it's just personality friction so bad you can't read their Slack messages without a headache. This happens. A lot. I've been doing enterprise software delivery for about fourteen years now and I can tell you that most of the painful collaborations in my career weren't with people I disagreed with ideologically. They were with people whose fundamental working style made everything three times harder than it needed to be. Learning to function professionally anyway is basically a mandatory life skill at this point. Let me restate something people miss on day one: this isn't about becoming friends with the person. That's not the goal and pretending it is just sets you up for disappointment. The goal is transactional output. You produce work together, you ship it, you move on. Everything else is noise. I learned this the hard way after spending about six months trying to genuinely connect with a lead architect who thought documenting decisions was a waste of time and refused to write anything down beyond commit messages. I kept hoping if I just showed him enough respect he'd change. He didn't change. I started cc'ing myself on every important email thread and building my own paper trail independently. The project shipped. Nothing personal about it. The core mechanism here is structural separation. You separate the person from the process. When you interact with someone you don't trust, you remove discretion from the equation. Every decision, every handoff, every acceptance criterion gets documented in writing before any real work starts. Not after. Before. I've seen teams skip this step because they're afraid of seeming paranoid, and then spend three weeks in blame arbitration when something breaks. That's not paranoia. That's basic professional hygiene.
One thing nobody talks about enough is the concept of controlled hostility. When you work with someone you genuinely dislike, you can actually use that as a performance lever. I found this out accidentally during a merger integration where my team had to absorb a department whose culture was completely incompatible with ours. The two lead engineers from the acquired team and I absolutely could not stand each other. We spent the first two sprints actively sabotaging each other's code reviews. Then I stopped caring about winning arguments and started caring about the ship date. I shifted every interaction to a written format. No more impromptu hallway debates. Everything went through a shared RFC doc where we'd post proposals and comment on them asynchronously. The quality of work actually improved because we both had time to think before responding, and the personal animosity stopped bleeding into technical decisions. It took about six weeks to get to that point but once we did, we shipped faster than either team had ever shipped individually. Here's a specific edge case that I still think about: working with someone who is secretly competent but deliberately obstructive. This is different from someone who's just difficult. This is someone who knows what they're doing and chooses to make your life harder for personal reasons. I had a product manager like this early in my career. She would approve requirements documents with comments that seemed reasonable on the surface but contained contradictions that would only surface during implementation. When I called her out publicly in meetings she'd play victim. When I tried to go around her she'd escalate to her manager. The workaround that actually worked was stopping the public confrontations entirely and moving every disagreement into written form where the contradictions were obvious to anyone reading. I started formatting my responses to her documents as numbered questions: "Section 3.2 says X. Section 5.1 says Y. Which takes priority and who authorizes the change?" It removed the emotional layer completely. She couldn't play victim over email because the paper trail was neutral. And when senior leadership eventually read the thread they saw exactly what was happening without me having to say a word. She transferred departments four months later. The technical framework for this kind of collaboration rests on four pillars. First, explicit scope boundaries. Every person involved should be able to draw a line around what they own and what they don't without asking anyone else. When scopes overlap you get either turf wars or coverage gaps, and with someone you dislike you get both. Second, asynchronous communication as the default. Real-time conversations with a difficult person are where things blow up. Email, shared docs, ticket comments - these give you time to craft responses that are technically accurate rather than emotionally reactive. Third, third-party escalation paths that are predefined. Not "we'll figure it out if something goes wrong" but "if Person A and Person B cannot agree on X within 48 hours, it goes to Manager C for final decision." Write this down before you need it. Fourth, shared metrics that both parties have to answer to. If you're both measured against the same shipped outcome, the personal friction becomes background noise instead of the main event.
Now let me be blunt about where this breaks down. Structural separation and written processes don't work when the other person is actively trying to get you fired. No amount of RFC docs will protect you from someone who controls the narrative with your management. In that scenario you need legal or HR involvement immediately, not after the fact. I've seen people wait too long because they thought if they just kept their head down and did good work it would be enough. It wasn't. The person who was undermining them had already shaped their manager's perception over months of one-on-ones. By the time the paper trail existed it was too late to change the story. Document everything from day one in those cases. Don't assume good faith exists when there's no evidence of it. Another limitation: this approach adds overhead. Structured collaboration means more meetings to align on process, more time writing documents, more version control on communications. If your team is small and moving fast, that overhead can slow you down. I'd estimate a 15 to 25 percent time increase on any project involving high-conflict collaboration compared to working with people you trust. Sometimes that's the right tradeoff. Sometimes it isn't. If you have the option to request a different collaborator, take it. Structural separation is damage control, not a lifestyle recommendation. There's also a psychological tax that nobody budgets for. Working with someone you actively dislike while maintaining professional decorum burns mental energy. You're constantly monitoring your own reactions, filtering your language, planning your next move in discussions. This leads to decision fatigue faster than normal. I've noticed it in myself particularly after back-to-back syncs with people I find draining. The quality of my independent work drops for the rest of the day. Block out recovery time. Schedule deep work after any interaction that requires sustained emotional regulation. It's not weakness. It's resource management.
Get the Full Details
A counter-intuitive insight that took me years to internalize: the people you dislike most professionally are often the ones who expose your own weaknesses. The architect who thinks documentation is useless is probably reacting to people who wrote useless documentation. The product manager who changes requirements mid-sprint may have been burned by teams that never committed to a plan. You don't have to excuse their behavior. But understanding the origin of it makes you better at predicting it. When you can predict it you stop being surprised by it. And when you stop being surprised you stop overreacting. That's where the real improvement comes from. Here's a practical template I use when I know a collaboration is going to be difficult. Before the first working session, I send a brief message that looks like this: "I want to make sure we're aligned on how we'll work together on [project]. Can we confirm: (1) our respective ownership boundaries, (2) the communication channels we'll use and response time expectations, (3) the escalation process if we disagree on a technical decision, and (4) the success metrics we're both accountable to. I'll draft something based on our conversation and we can iterate on it." This sounds stiff. It is stiff. That's the point. You're establishing the frame before the other person can set it for you. Most reasonable people will appreciate the clarity. The difficult ones will push back, and their pushback tells you exactly where the friction points are going to be. Either way you've learned something useful before writing a single line of code or delivering a single slide. I also want to mention something about the trust question specifically because it comes up constantly. You don't need to trust the person to collaborate effectively. You need to trust the system. A well-designed collaboration framework doesn't require interpersonal trust because it doesn't rely on anyone's word alone. Requirements are signed off. Decisions are recorded. Escalations are triggered automatically when conditions are met. You're trusting the process, not the human. This is how large organizations actually function. The intimate trusting relationships you see in movies don't exist in practice. What exists is contractual alignment with enforcement mechanisms.
There's a particular pattern I see with people who struggle with this: they either over-accommodate or over-confront. Over-accommodation means you let the difficult person set terms because you'd rather avoid conflict. This almost always backfires because the person senses your discomfort and exploits it. Over-confrontation means you turn every disagreement into a battle, which is exactly what they want if their goal is to derail the project. The middle path is dispassionate assertiveness. You state your position clearly, you anchor it to shared objectives, and you don't apologize for it. "We need this documented because our last project had a production incident caused by an undocumented dependency change. I'd rather spend an hour on docs than twelve hours debugging at 2 AM." That's not aggressive. It's factual. And facts are harder to argue with than preferences. One more thing about the long game. These collaborations shape how you approach future work. After you've survived a genuinely toxic professional relationship you tend to get better at reading red flags early. I can spot a setup for conflict now within the first thirty minutes of meeting someone new. They'll complain about a former colleague within the first conversation. They'll frame requirements in ways that deliberately leave ambiguity. They'll avoid committing to written decisions. None of this is inherently wrong on its own. Together it's a pattern. Recognizing it early lets you adjust your approach before you're deeply invested. That's the practical value of going through this stuff. It trains your judgment. If you're in a situation right now where you have to work with someone you can't stand, start with the scope boundaries. Write them down. Get confirmation from both sides and whoever cares about the outcome. Then move to communication protocols. Everything else follows from those two. Don't try to fix the relationship. Don't try to win. Just build a structure that produces the work you're both paid to produce and protects you from the parts of the person you can't control.
