Have you become the person that everyone on your team, or any team, goes to when they are stuck on a problem? Why is this detrimental? How can you get your team to work more like a team?
I’ve been in software development for over 25 years, so I’ve managed to get myself into every role imaginable. I’ve definitely been “The Fixer.” I’ve learned a few techniques over the years that not only free myself from the constant interruptions, but also enable my teammates by teaching them to work together. Remember, “there is no ‘I’ in ‘team’!”
Up front, I’d like to clarify that none of this is to imply that sometimes we don’t get truly stuck and need to have two or more sets of eyes on a problem; or that discussing an approach to a problem before diving in to coding should be avoided. This article is meant to address the “Well, I’ll just ask the fixer what to do” problem.
So, there you are, deep in flow state, hammering out code on a complicated algorithm, when, DING! A notification rips you out of your focus. It’s another developer. “Do you have time to look at something?”
Now, I get it. It can be gratifying to know that you probably have a lot of the answers people need. I admit that I sometimes get caught up in being “that guy”. It’s good to be needed. But that guy is “The Fixer”, and he’s hurting your team. Fight the urge to switch your train of thought and go help. If you can do that, you’ll be more valuable than “that guy”.
Technique One:
So far, your compatriot has given you zero context. You don’t know if they immediately called you or if they’ve been stuck for hours. Try responding with your own set of questions.
“Sorry, I’m kind of deep into something right now. Can you please explain the problem in more detail?”
This question forces them to do what hopefully they have done already, have the rubber-ducky conversation. They need to explain the problem to the least expensive member of the team (the rubber-ducky on their desk). The process of explaining the problem out loud (or at least in a DM) can often lead them to find their own solution without having derailed anyone else on the team.
If you can’t explain it to the duck you need to keep digging.
If they cannot clearly explain the problem, then maybe they need to dig into the code more, map things out, draw on a napkin, until they do. Let it be their job to at least define the problem.
If they can clearly explain it, then…
Technique Two:
“Excellent explanation. Thank you. What have you already tried to do to solve this?”
Now, we’re kindly asking them to justify why they are interrupting another developer. We’re ascertaining if they are truly stuck or just taking the easy way out.
If they haven’t dug into the code, debugged in various forms, examined logs, and maybe tried a thing or two from StackOverflow, then maybe they will feel bad about replying with a “nothing.” If they say they haven’t dug in thoroughly, then help them see they need to do that first. But, maybe they will feel compelled to go and try those things and come back with an “oh, I figured it out” or “I tried X, Y, and Z and I’m still not getting anywhere.” If the former, you’re off the hook and they learned something! If the latter, then you might step in and help. Or, you may try…
Technique Three:
“Could you please post all of this information about what the problem is and what you’ve tried so far to the entire team?”
What do we accomplish by doing this? First, we train them to treat the team as their support system. The reality is that “The Fixer” never has all of the answers. And the team often has people with the necessary skills and knowledge. There may be someone who just finished up a task and has time to look at the problem right now, without interrupting their flow state. Or, they may have seen this situation in the past and can even help to solve the problem faster and in a consistent manner. The team learns to rely on each other, not on just one person. If the beer truck takes out “The Fixer” where does that leave the team? If you’ve killed off “The Fixer” then they will continue to function as a team!
Secondly, the team’s knowledge grows. Yes, “The Fixer” may know the answer off the top of their head. But if two other devs go figure out and fix something, now three people on the team know the answer!
In summary, by using these three simple steps you will:
Build the team’s confidence in each other.Spread knowledge and experience.Reduce interruptions to flow state.Get more work done.Not be “The Fixer”!
If you enjoyed this article, please leave some claps and follow me.
If you love Angular development, please join us at ng-conf 2023!
ng-conf | June 14–15, 2023
Workshops | June 12–13, 2023
Location | Salt Lake City, UT
ng-conf 2023 is a two-day single track conference focused on building the Angular community. Come be a part of this amazing event, meet the Angular Team and the biggest names in the community. Learn the latest in Angular, build your network, and grow your skills.
Three Steps to avoid being “The Fixer” was originally published in ngconf on Medium, where people are continuing the conversation by highlighting and responding to this story.