#17 How To Work With Difficult Engineers
Quick Announcement 🎉
This is the final newsletter of 2024! Thank you all for reading, commenting, and sharing your feedback. Your support inspires me to keep writing every week. At any point you’d like to share some feedback, feel free to message me here or on LinkedIn.
I’ve got some exciting plans for this newsletter in 2025—so stay tuned! If you’re enjoying this content and would like me to keep it going, make sure to subscribe.
I’ll be taking a break over the holidays and I’ll be back on Friday Jan 10th 17th.
Now let’s get right to it.
Introduction
Throughout your career, you’ll work with different types of engineers: some may be easy to work with, some may be Rockstar engineers, and others may be slightly difficult to work with. Activities like reviewing the tech stack, re-prioritizing the backlog, and choosing technical solutions can take more time until everyone is on board.
Let’s unpack how to work with difficult engineers and how to differentiate between task conflicts and relationship conflicts.
What is a Difficult Engineer?
“Difficult” here doesn’t refer to incompetence (i.e., incapable of doing the work). Rather, it refers to the challenges of collaborating with them on an assigned project.
For example, they might be perceived by others as:
Quickly opposing different ideas or suggestions from peers.
Picky when reviewing peers’ pull requests.
Skeptical when peers introduce new technologies to the stack.
People might think that working with them will be slow and painful for the team. But before drawing that conclusion, we need to first question these statements: Are they true? And if so, to what extent are they true?
Why Are They Difficult?
It might be tempting to second-guess this by thinking that they've always been this way. However, it's important to first consider the current context in which you're working with them to better understand the situation and see if there are hidden influences that you (and they) might not be aware of.
There may be external challenges (e.g., organizational issues, leadership changes, customer feedback, etc.) that are causing other engineers to become “difficult” at work. These challenges could also affect you, making you indirectly difficult as well.
Taking the time to understand the context is like viewing the application’s stacktrace when an exception is thrown.
The stacktrace can be long, but the goal is not to figure out the entire stack. It can include things outside of work, i.e., personal stuff. A simple example is that I woke up on the wrong side of the bed this morning, so I might be a bit slower or less productive today.
When we skim through a stack trace, we look at different stack frames: some refer to application code the team wrote, while others refer to third-party libraries we’ve imported. The same applies to the human side. Some frames will be personal, some will be team-related, some will be business-related, and so on.
Debugging code you don’t know is easier than debugging people you don’t know.
The goal here is not to identify difficult engineers, but to develop situational awareness, where we can understand the current project we’re working on, the challenges behind it, and whether it will affect the people involved.
Task vs Relationship Conflict
Let’s say you're having a conflict with an engineer over some technical design. Its important to understand where the conflict sits on the Relationship/Task region, and ensure it only lives on the Task region.
All conflicts at work should be Task conflicts by default. It’s our collective responsibility to ensure that any conflict that accidentally drifts into the Relationship region is redirected back into the Task region until resolved.
Examples of possible Relationship Conflicts:
Alice: That API design proposal is completely wrong.
Bob: I don’t understand anything in your PR. Its a complete mess.
Charlie: That planning meeting was just a waste of time.Examples of Task Conflicts:
Alice: Can we revisit the API design proposal for X, I don’t think the proposed schemas match with the frontend engineers’ expectations.
Bob: Can we hop in a call to discuss the PR? I don't think I fully understand the changes for Y.
Charlie: Are you free for a quick chat? I have some thoughts for improving the way we’re running the planning meetings for Z.If you work with Alice, Bob, and Charlie. You should mentally approach all examples as Task conflicts. Respond in a task-focused manner that shifts the conversation from using the word “You” or “I” to “this” (i.e., Relationship to Task). If at some point you were Alice, Bob, or Charlie, you can voice your concerns with the team while remaining laser-focused on the problem—without accidentally attacking anyone.
If a conflict doesn’t start as Task conflict, it should should always end as one.
One great thing about Task conflicts is that they can help improve a team’s problem-solving skills. Task conflicts allow engineers to challenge new ideas, debate technical solutions, inspire each other to innovate, and determine the best technical direction for the team to take. Having Task conflicts is great for the team’s growth—don’t shy away from them.
After all, there are no villains in the story—only people with complex incentives doing complex work.
Key Takeaways
Approach working with difficult engineers as Task conflicts, not Relationship conflicts.
Task conflicts can spark interesting conversations and drive new innovations.
Do not let Task conflicts slip into Relationship conflicts.
Debugging code you don’t know is easier than debugging people you don’t know.
And that’s a wrap for 2024! I’ll see you next year!
