Hardest Non-Technical Problem: Dealing With Sticky Situations
Last part of my series on growing your soft skills
Welcome to Path to Staff Engineering! I’m Sidwyn, and I will teach you the skills to level up to the Staff level faster. If it's your first time here, subscribe to continue receiving this free content.
Looking for the first two parts of the series? Here’s Communication (first) and Adaptability (second).
Welcome to the last part of the Soft Skills series, where I cover a completely different side of software engineering that's rarely discussed—sticky situations.
As a software engineer, you’re constantly navigating interpersonal challenges and tricky situations.
In this post, I'll cover three of the most common sticky situations:
An underperforming teammate
A “overly controlling” manager
Endless technical debates
This advice assumes you’re already performing well—meeting deadlines and putting in the effort. If not, address that first and see if the situation improves.
Let’s dive in.
An Underperforming Teammate
In my career, I've worked with many top-tier engineers. But for every 50 great engineers, there's always that one engineer who underperforms.
Let's walk through how I’d try to address this situation.
What I try:
Talk to them 1:1. Let them know that getting results from them is hard. Hint to them that they haven't been pulling their weight. Be direct with them (see quote below).
Practice empathy. Understand if they have something going on behind the scenes. While this shouldn't fully justify their performance, you can empathize better. The most common situations I've seen are divorces, family emergencies, and personal sickness. Understand if the situation is temporary or more permanent. If it’s temporary, see if you can wait for the personal situation to resolve.
Gather more data points. Talk to those they work or have worked with and see if they are facing similar issues. You're not trying to create an "us vs. them." Collect data points on whether this is a reoccurring situation.
Bring it up to your manager. Let your manager know there's been some friction working with this person. If the other party also reports to your manager, let your manager handle some of this. As always, make sure you bring facts and examples. I type these all in a Google Doc to ensure I quote myself correctly.
Here's how you can be direct with them:
"The team expected this to be done by Friday, but you couldn't deliver this on time. Was there something going on?"
What if it still doesn't work?
Start shifting responsibilities off their plate. You can't rely on them anymore. If you lead team stand-ups, "To meet deadlines, Josh is now going to take over from Reuben this on to meet deadlines." You can give both Josh and Reuben a heads-up but have your manager's buy-in for a stronger transition.
Discuss it with their manager. If they don't report to your manager, you need to inform their manager. Do this when you have accumulated enough evidence, at least from another engineer.
Inform your manager. Let your manager know that you'd prefer not to work with them now and in the future. Explain how this person is impacting your and your team's performance. Remember to be objective here.
Approaching the other party's manager might be daunting at first, but they actually appreciate the feedback. It is important that you do this with enough evidence so it doesn't feel like you're just calling them out.
Found this helpful? Subscribe to make sure you don’t miss new articles.
The Overly Controlling Manager
Managers are essential in your career. They know your priorities and work with you to remove any blockers. They help you grow.
But what should you do if your manager starts to feel overly controlling? What if they always want to vet your decisions? Or if they don’t trust you?
Most managers are not like this, so it's vital to understand if you have one. Make sure that you have multiple data points before concluding that there is a pattern here.
If you are confident that it is, here are my strategies to navigate the situation effectively.
What I try:
Understand their working styles. Do they want to always be in charge? Are they afraid of making mistakes? Are they scared of looking bad in front of leadership? Identify the root cause of their behavior and jot down differences in working styles.
Explain how they are slowing you down. Share how their decisions (e.g., sign-offs, delays) slow you down. Be prepared to provide evidence of these delays.
Show that you can be trusted. Share how you’ve organized all the priorities on your plate. Over-communicate your progress through chats, documents, and public forums.
Deliver consistent, high-quality work to build your manager’s trust over time. This may make them more comfortable, giving you more freedom.
Ask for autonomy. Frame this as a way for you to grow and improve project efficiency.
Here’s something you could use, especially for #3.
”Sarah, I thought I’d share something with you. * pause * In the past month, I’ve felt that your opinions on Project X were helpful, but they have added quite a bit of churn for me. When you mentioned you wanted to read and sign off on my work last Tuesday, I felt that all of my work had to be validated before we could proceed. This has slowed me down by a couple of days. I’ve noticed that I work best when I have space to manage my tasks. Could we try a more hands-off approach on this project?”
This paragraph is excellent because it is 1) honest, 2) direct, and 3) evidence-supported. If Sarah asks, you should be able to provide evidence of how many extra days her sign-off took.
What if it still doesn't work?
Note: I recommend trying these options after at least two months of working together. This gives you enough time to adjust and understand each other's working styles.
Talk to other teammates. Find out if this is a common issue among your team. If it’s a shared experience, check in with your teammates to see how they've addressed this. If it’s just you, there is perhaps a reason deeper that you have to find out.
Talk to your skip. Build a relationship with your skip (your manager’s manager). Share your struggles if they can promise confidentiality. If not, learn more about your manager’s challenges through your skip. Are they poor at communication? Struggling with control? Have others noticed similar traits?
Pull the trigger. If the situation hasn't improved after two months, and you've tried all the above steps multiple times, consider finding a new manager or job.
Found this helpful? Subscribe to make sure you don’t miss new articles.
Endless technical debates
We've all been there—endless debates about whether to proceed with an architecture, remove a particular field on an entity or adopt a new framework. This is arguably one of the most challenging sticky situations an engineer faces. But there are ways out.
What I try:
Document opinions: Have each engineer create a clear one-pager outlining their views, pros and cons, and recommended approach. This will clearly explain their thoughts and give enough time for people to think offline about varying positions.
Facilitate group discussions: Gather everyone to discuss the documented opinions. Encourage active listening and understanding. Timebox this meeting so it doesn't run over. Ensure everyone gets a chance to speak their voice.
Seek common ground: Identify shared goals between all the engineers. Find a middle ground that integrates everyone’s perspectives. Repeat these steps until resolved.
What if it still doesn't work?
Escalate to senior engineers. Ask folks who've been around in your organization for longer to give their opinions. Ask them to weigh in. They should have enough experience to point in a direction.
Lean on managers for support. Share this struggle with your manager. There might be characteristics or idiosyncracies of the other party, e.g., "This happens a lot with Person X.” Even though they might not be able to resolve the technical bits of the debate, you might be able to understand if there’s a trend with this person.
Give in. This is not the same as surrendering defeat. When you give in, you should highlight and document the drawbacks to the team. Strongly share the cons of adopting the framework. Recognize that some battles are not worth your time.
How to give in:
I've weighed the pros and cons of both approaches and while I still have concerns about [specific drawbacks], I recognize that the overall benefits of moving forward with your choice outweigh them. I’m on board with this direction, but I want to ensure we’re all aware of the potential challenges, so we can address them proactively if they arise.
TLDR
Sticky situations are hard. Knowing how to handle them is arguably the toughest soft skill to master.
If you have an overly controlling manager, try understanding working styles and building trust.
Bring it up to teammates who aren't pulling their weight. Be honest with them. Escalate if necessary.
Seek common ground if you're stuck in an endless technical debate. Else, escalate, lean on managers for support, or give in but highlight drawbacks
In all cases, document everything so you can defend yourself.
Thanks for reading. I hope this helps you in your journey to grow as a software engineer. These are shared from a decade-long journey working as a software engineer in startups and Big Tech.
Have thoughts or feedback? Comment or reach out to me here or on LinkedIn.