Your Best Tech and Your Best Dispatcher Are Fighting Each Other. Neither One Knows It.

When your bicep contracts to bend your arm, your tricep has to relax. We all get this. There is no world where both are actively working to lift something or to bend your arm in a better way. They are wired to work against each other and create for an uber efficient way to make sure your arm bends and straightens. If both muscled worked for the same exact result of contracting to bend your arm, you’d be better off not having either muscle. It would lead to an exhausted mess.

Physiologists call the phenomenon of your bicep and tricep movements as reciprocal inhibition. One muscle contracts and the other relaxes. This is a simple design that works every single time without you having to think about it. Your body has figured this out over millions of years of optimization.

Most technical teams never figure out that they actually figure out that often reciprocal inhibition can seriously help or hurt their operations.

There’s no question that you have very talented people on your team and individually each of them is incredibly good at their job. The problem comes in when both of them start fighting over the same problem and no one realizes that they are fighting each other to the point of canceling out any good either would have had. In this scenario your best tech and your best dispatcher are fighting each other and canceling each other’s work out. No one is the wiser.

You might say that healthy conflict makes your team better. Yes, in discussions it might help coming at a problem from different points of views. But when you boil down successful teams, you realize that even though people might not agree on everything, they decide to overcome these objectionable moments and walk lock step in unison because the company needs direction, not indecision.

I used to think our biggest problem on the helpdesk was speed. I would look at ticket numbers every week and think we just needed faster techs. Turns out I was looking at the wrong thing the whole time.

Here is what I actually found when I paid close attention. A ticket would come in and my frontline tech would open it up. Before they could do anything real, they needed three things. They needed to know the client's setup. They needed to know if this had happened before. And they needed to know who fixed it last time, in case that person knew something worth asking about.

None of that lived in one place. The setup notes were in one system. The history was buried in old tickets that were not organized by what actually went wrong, just by which client it happened to. And knowing who fixed it last time usually meant walking around the office hoping that person was at their desk.

My tech would spend four or five minutes just gathering the basics before they even started troubleshooting. That does not sound like much. But do that on every ticket, every day, across a team of ten people, and you are burning hours a day that never show up on any report. It just looks like normal work. Nobody flags it because nothing looks broken.

Then it got worse at the handoff. When a ticket got escalated to second line, my second line tech usually did not fully trust the notes from frontline, and honestly sometimes those notes really were missing something. So they would start digging again, partly redoing work that had already been done. A five minute ticket would turn into a forty minute ticket, and that is exactly where I started missing SLAs, even though every single step along the way looked reasonable on its own.

After seeing the pattern, I stopped blaming my team and started looking at the system they were working inside of. This was never a discipline problem. It was a design problem, and design problems need design fixes, not pep talks.

Here is what we changed.

We started bundling context automatically the moment a ticket opened. Client setup, a history of similar tickets, and the name of whoever solved something like it last, all attached before a tech even clicked into the ticket. Nobody had to go digging for it anymore.

We switched how we organized history. Instead of filing it under which client it happened to, we filed it under what actually went wrong. That way a fix from six months ago on a completely different client could show up for a tech who had never touched that client in their life.

And we started tracking something most MSPs never look at. Not just total resolution time, but the gap between when a ticket opened and when a tech actually started doing real work on it. That number told us the truth. If that gap was long, it meant our tools were costing us time, not saving it.

Here is the thing I tell every partner now. If your team is missing SLAs, the easy answer is to hire more people or tighten up the process. But if the real leak is minutes spent rebuilding context that already exists somewhere in your systems, more people just means more people doing the exact same unnecessary search. Fix the system once, and you fix the leak for everybody, all at the same time.

Start documenting those roles at builttorunmsp.com.

FAQ (3-4 sentences each)

What is reciprocal inhibition and how does it apply to team dynamics?
Reciprocal inhibition is the physiological principle where one muscle contracts while its opposing muscle automatically relaxes, allowing clean, efficient movement. Applied to a team, it describes what should happen when two roles are meant to be complementary, one taking ownership while the other steps back, rather than both trying to actively manage the same problem at once.

Why do two skilled team members sometimes work against each other without realizing it?
This typically happens when two roles that are supposed to be complementary, such as a dispatcher and an engineer, both attempt to actively manage the same decision at the same time. Neither person is doing anything wrong individually, but without a defined rule for who owns the decision and when the other should step back, their efforts collide instead of combining.

Why does an escalation handoff sometimes fail even when a senior technician tries to help?
If the senior resource takes over and fully solves the problem instead of guiding the junior technician through it, the junior tech never gets the chance to learn, and nothing gets properly documented. The handoff only works when the senior resource explicitly relaxes into a coaching role while the junior tech stays actively engaged in the work.