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!