7 types of difficult coworkers and how to deal with them
Lessons from a Meta tech lead and Staff Engineer
Hey everyone, Jordan here 👋. Before jumping in, I want to thank you for the newsletter growth. In the past month, we’ve doubled in subscribers (from 12k to 24k). It makes me incredibly happy to know you are finding so much value from the newsletter.
👋 Intro to Raviraj
I interviewed
, a Staff Engineer at Meta to learn how he handles working with difficult coworkers.What makes Raviraj special?
Raviraj has 10+ years of experience across Meta and Microsoft and he’s been a tech lead at Meta for 5 years.
He is:
A go-to person at Meta to solve cross-organization challenges.
A coach for many Senior and Staff engineers on people skills, guiding them to resolve difficult situations.
A Staff Engineer with a track record of delivering long, high-impact projects.
Quick terminology: In big tech, a Staff Engineer translates to L6, which is 1 level above Senior.
If you’d like to jump straight to the TL;DR and takeaways at any point, see the bottom.
🎉 Upcoming course announcement
I’m officially going to be teaching a course on Maven!
The course “Mid-level to Senior for high-growth engineers” will be in early December.
You can join the waitlist here: https://maven.com/forms/02f7d3.
We’ll be covering the 5 key areas to get to Senior Engineer: Leading projects, becoming an expert on your team, getting your manager on your side, mentoring, and shipping senior-level code.
With 250+ of you already on the waitlist, I can’t thank you enough for all the support 🙏.
And yes, all subscribers will be getting a nice discount when it comes out!
⭐️ Main takeaways
7 different types of difficult coworkers and why they’re being difficult.
How to turn situations with difficult coworkers into wins for both of you.
💡Figure out why they’re being difficult
For all difficult situations, the one thing you should always do is assume good intent. This was a common trend in our last chat with an ex-Twitter Staff Engineer.
If you assume good intent, your coworker must be coming across as difficult for a reason. It’s your job to identify the reason.
Raviraj discussed 7 types of difficult coworkers you may run into and how to approach each one. In each case, we assume they are not actively being malicious, but have good reason for their behavior. It’s about how we can work with them better.
🛡️ (1) Risk-Averse: The Habitual Defender
They want to avoid risk at all costs and don’t want the system to break.
They will often push back on your initiatives and make moving forward difficult.
Why they do it:
They want to know you did your research and are not just “rushing to prod.”
They might feel like the change is large and need time to process their thoughts, questions, and concerns.
How to work with them:
Understand that working with them is good for you. They are a forcing function for ensuring your plans are well thought out.
Acknowledge the risks you’re aware of and ask if they have any to add.
Example: “These are the risks with this and here’s how we plan to address them. Do you have more? Do you need time to think about it?”
Make sure your plan doesn’t look rushed. Talk about edge cases, alternatives you considered, and how nothing will break in the process.
When Raviraj encounters risk-averse engineers holding back decisions, he focuses on making it easy for them to understand how the risk will be managed.
An example template for design docs he’d use is:
(1) The problem
(2) High-level goal everyone wants to get to
(3) Comparison table of the options to get there
(4) Proposed solution and why—usually clear from the comparison table
(5) Risks and how they will be resolved
With this, the other person sees:
You did your research.
You have clear reasoning for your solution.
You understand how you’ll address risk.
🏎️ (2) Risk-Taker: The Trailblazer
The opposite of the prior archetype. This person often feels the risk is justified or they will propose ideas without scoping out the risk.
Why they do it:
They see problems with the existing system and wish it was better.
They prefer fast feedback loops by hearing their teammates’ opinions early.
How to work with them:
Help them brainstorm. Ask them what risks they have considered and how the solution fits in with the existing systems.
Example: “How will this integrate with our CI pipelines? What are the ways this might go wrong? How should we handle that?”
Raviraj shared a story of an engineer proposing what seemed to be a risky dependency change. He focused on asking targeted questions that helped build out the proposal a bit more, which led to everyone, including the other engineer, having a better understanding of how the change would work.
🥷 (3) The Stealthy Critic
They will have opinions but save them for the last minute before something is ready to ship. Or they will comment on your design doc and leave things in an ambiguous state. They might make a light suggestion but only put their foot down on it until later.
Why they do it:
To avoid confrontation and lightly get their point across.
They might assume someone else will handle the confrontation instead of them needing to do it.
How to work with them:
Follow up with them directly on unanswered conversations.
Example: If they ask a question on a doc and you answer it, but it seems like their question is suggesting a different approach, ask them if your answer covers their concern.
Schedule a live 1:1 chat to go over their concerns. Afterward, send them a summary of the discussion and have them sign off on it.
This allows you to refer back to their agreement later if they suddenly try to revoice concerns that they held back before.
Set a deadline for signoff. After putting up a design doc for review, state the deadline for signing off. This ensures reviewers will take a look in a timely manner and you have a sign-off deadline to refer back to if they bring up concerns later.
Raviraj shared how he likes to schedule 1:1 chats to discuss their concerns, document everything, and then send it to them for them to sign off. You shouldn’t use this sign-off they give against them, but the process of getting them to do it is usually enough to ensure they don’t bring something up last minute.
He also likes to add sign-off checkboxes at the top of design docs he makes. This guarantees the sign-offs are explicit and forces them to think through their concerns.
Specifically, he’ll say, “Hey, if you agree, could you check the sign-off button?” Often, this leads others to voice their final concerns and Raviraj to address them, leading to the final, explicit sign-offs.
🎙️ (4) Opinionated and talkative
They’ll leave a lot of suggestions on anything you do. It could be a code review or design doc. The suggestions will usually be out of scope.
They might sidetrack meetings, talking about things that are not important right now.
Why they do it:
They have a lot of ideas for improvement and just want to help.
The scope or focus of the discussion might be unclear to them.
How to work with them:
If they sidetrack meetings, acknowledge their point and a path forward for it, but redirect the discussion back to the main topic.
Example: “That’s a great point. Let’s create a ticket for that so we don’t forget. I want to make sure we have time to discuss X, so let’s continue there.”
Create a “Not in scope” section in your design doc or code review to prevent too many suggestions. Another way is to have a “Future considerations” section where you can include their suggestions.
Example: “I love that idea. I’d like to keep the scope to X for now, but I’ll add this to the ‘Future considerations’ section so we have it documented.”
You should actually accept their suggestions when it makes sense. This will build trust that you aren’t always just deflecting their suggestions.
In the past, I’ve noticed a huge difference in the amount of feedback when I preemptively call out what I’ve thought about and decided not to include—whether it’s on a pull request commenting on my own code or in a design doc.
🧐 (5) The Perfectionist
They will be overly nitpicky, particularly in code. This is often because there is a difference in your bar for quality or opinion of what’s important for the company. You might think shipping to the customer as quickly as possible is more important and they think code quality is.
Why they do it:
To raise the bar for quality.
How to work with them:
Have a respectful conversation with them about it.
Example: “The suggestions you are bringing definitely raise the bar for our codebase, and I am very appreciative of it. One thing I noticed is that sometimes it can slow us down from experimenting. I’d love to know how we can work better to maintain that high bar and still be able to try things out and experiment. What do you think?”
Define standards up front. If you can have a clear definition of done in the ticket or what is out of scope, it’s easier to point to an artifact on why it’s not important right now rather than making it about you vs them.
Explicitly ask if their feedback is a blocker. The ideal situation is that they prefix all their comments with nit: and still approve, allowing you the decision to move forward or address their comments. If it’s unclear, ask if it can be done in a follow-up. This way you can move forward and address their feedback at a later point.
Example: “Good callout. Since this might add a good amount of scope to the change, does making a follow-up ticket work for you?”
😔 (6) Unmotivated
They seem checked out and not their usual selves. They submit work at a lower quality than you’re used to or they’re taking much longer than usual.
Why they do it:
They don’t like the work they’re doing.
Many other potential reasons: Personal life, issues with their manager, etc.
How to work with them:
Have a personal 1:1 with them. Be direct and let them know what you’re observing, but also show you care about them and want to know how you can support them. See the example from Raviraj below.
Bring it up with your manager. Let your manager know that you’re worried about the impact on you and the team. You’d like to know how you can help and you wanted to keep your manager in the loop on what you’re noticing. This gives your manager the opportunity to assess the situation and try to resolve it.
In Raviraj’s case, he ran into this as a tech lead. He met with them 1:1 and was direct but respectful. He created a concrete list of action items for them to improve like what to consider when managing risk, reviewing code and design docs, examples of the level of quality he expects, etc. At this point, it’s clear to the other person there is a set of expectations to be met and what needs to be done. This makes it easier for them to focus on the right things and realize the impact of the situation.
If you’re a peer rather than a tech lead, he recommends having a 1:1 and saying something like, “I’ve seen a pattern that your deliverables for the sprint are missing deadlines. I’m just curious what’s going on? Do you need help with anything or is it all okay on your part?” Approach it with curiosity and understanding.
😓 (7) The Overwhelmed Optimist
You rely on them for the work they do but they have too much on their plate.
For example, it might be an engineer you need reviews from, a designer spread across multiple teams, or your own manager.
At the same time, they end up agreeing to work they can’t reasonably do by the time you need it. This leads to missed deadlines on your end.
You also find yourself needing to follow up with them multiple times.
Why they do it:
Their overwhelming workload leads to poor prioritization.
They want to say yes to be nice but don’t realize the impact it’s having when they can’t follow through.
How to work with them:
Be understanding. It’s counterintuitive, but it’s worth doing for a while until the problem is repeated enough. You don’t want to come across as demanding when they already have a heavy workload. It can damage the relationship and make them not want to help you in the future.
If the problem persists, respectfully share the impact but also offer help.
Example: For a cross-team partner, you might say, “The last few reviews we did, I ended up needing to re-ping you a couple of times in order to get a review. I want to be understanding of your workload too, and I’d love to know if there’s any way for us to work better in those situations. What are your thoughts?” This allows them to tell you the best way to work with them, like if they just need you to ping them over and over, or for them to take responsibility and say they will improve on it.
Example: For a teammate, you can be more straightforward. “Hey I get the sense that you have a lot on your plate and that is resulting in deadline misses. Is there anything I can do to support you?”
Bring it up with your manager. Generally, keep this as a last resort. If you’ve tried to resolve it with the person directly though and it’s impacting the team, you should let your manager know.
Raviraj called out that in situations like these, it’s worth bringing it up directly with the person first rather than your manager. However, if you’re unsure of how to approach the conversation, consult your tech lead or manager on how to have the conversation effectively. The conversation with the other person might be awkward but having it will help you grow immensely.
📖 TL;DR
Risk-averse: The Habitual Defender
Working with them is good for you.
Clearly describe the risk and how you plan to address it
Risk-taker: The Trailblazer
Help them brainstorm. Ask them targeted questions and flesh out a more detailed plan with them.
The Stealthy Critic
Make sign-off explicit.
Follow up with them on unresolved comments.
Have a 1:1 with them to go over their concerns and document it.
Opinionated and talkative
Politely redirect the focus of the conversation. Acknowledge and thank them for their suggestions.
Preemptively call out what is not in scope.
The Perfectionist
Have a respectful 1:1 with them about their feedback. Describe the impact and ask how you can work better together.
Define standards and a definition of done upfront.
Ask explicitly if their feedback is a blocker.
Unmotivated
Have a heartfelt 1:1 with them. Ask how you can support them.
Let your manager know what you’re seeing.
The Overwhelmed Optimist
Be understanding of their situation. They are already overwhelmed.
Give examples of what you’ve noticed in a 1:1 and share the impact. Offer help.
If it persists, bring it up with your manager.
💭 Closing thoughts
There’s 1 common trend in how to approach each one of these situations.
Understand the other side.
If you want to build better relationships and navigate these situations, you NEED to be thinking about what they want and their perspective.
A big thank you 🙏 to
for sharing his insights with us.I encourage you to check his newsletter,
💡Raviraj’s recommended resources
One minute manager - Learned to be direct with feedback
Never split the difference - Reason about negotiations and how to approach them
Radical Candor - How to work better with the team
📣 Shoutouts of the week
Insights on how to go from mid-level to senior with another Jordan on YouTube!
- : 15 principles for managing up
- : 6 software engineering templates I wish I had sooner
As always, thank you for reading and for the growth to 24k+ subscribers.
- Jordan
P.S. If you’re interested, I’m accepting the following:
New coaching clients: See Mentorcruise for rates
Newsletter sponsorships: Feel free to reply to this email or check the Sponsorship packages
Did you find this issue valuable? If so, there are two ways you can help:
You can also hit the like ❤️ button at the bottom of this email to help support me. It really helps!
This is outstanding content! Keep it up
Pure practical situations! For sure, I'll put on actions a lot of tips from this post.