Your Best Tech Just Told You the New System Doesn't Work. He's Lying, and He Doesn't Know It.

He told you the system doesn't work. Flat out. That's exactly what you might expect one of your tenured technicians to say when you roll out a new service delivery system meant to remove hurdles and reduce the amount of manpower needed to solve issues other MSPs handle with fewer resources.

Before you rolled out the new system, you and your leadership had thoughtfully gone through different scenarios. You mapped out how a ticket flowed through your workflows. You concluded that the new way of delivering service to your end users would do two things. It would free your team to focus on higher impact work, and it would give your best client facing people more time in front of clients, making sure those clients understood what services you could offer beyond basic IT support.

With all the hard work you put into planning, and the experience you leaned on from other MSPs whose systems had actually worked, your best tech told you the system doesn't work. He wasn't actually lying to you. He just didn't understand the benefit of having a system yet.

The actual lie was in the details. He didn't have any. He was simply stating a feeling. Partly it was unease about change. Partly it was distrust. The real lie was that he reported a feeling as if it were a fact. Statements like tickets are piling up or there are more client complaints since we implemented the system sound like findings. They're feelings dressed up as data. He said the process was slower than before. No data. Nothing measured. That's the real crux of the problem.

A complaint like this new process is slowing us down, with no specific ticket or example attached, makes it sound like the system is fundamentally broken and incapable of improving. From that statement alone, you have no idea what's actually going on. But the team, even the leadership team, may interpret the comment as fact anyway. Several people on our leadership team suggested we roll back after two weeks of implementation. We tried holding the line. It didn't work out.

Two weeks of generic complaining led to a cave-in. Several people said we needed to go back to the old way. We hadn't even had enough time to get direct client feedback yet. The team pointed at some averaged KPIs that had gotten worse. Response time went up. Resolution time went up too. But it wasn't clear what was actually causing either one. We had no real data. We were simply feeling our way around.

A feeling isn't a data point. It's that plain and simple. Feelings don't tell you what to fix. What I found after we implemented the service system was that we had been running our business on feelings the whole time. Feelings are essentially as good as running blind. I had to change people's minds, not by getting them to feel, but by getting them to see what was actually happening.

It's very easy to fall into the habit of feeling your way through decisions. When something feels harder, your brain reports it as fact, because it genuinely feels true in the moment. We're wired to perceive feelings as facts. That tech wasn't lying on purpose. He just didn't know any better, and honestly, I had initially believed his feeling too.

But that doesn't make accepting feelings as fact the right way to run a business. I'd flip the script the next time someone reports something that's actually just a feeling. When someone complains, ask them directly. Which ticket. What happened. How much time, compared to what they experienced before. Very often they won't have the details. That's exactly when you should keep probing for actual answers.

This happens to everyone.

It shouldn't surprise you when your most tenured people are the ones giving you feedback based on feelings. They've been doing things a certain way for a long time. Feelings are simply the cost of having built real expertise inside an old way of doing things.

One tech in particular raised the loudest alarms about formalizing a proven service delivery system with real metrics, defined accountability, and clear ownership.

When I didn't just accept that everything had fallen apart, and dug in a bit deeper instead, I got to the heart of what was actually bothering him. First, he didn't like using timers. He was used to working an issue until it was finished, and tracking time in a ticket felt like an annoyance he simply didn't want to deal with. I explained that without timing tickets, we had no way of knowing where the team's work was actually going, and no way to spot projects a client needed but didn't know they needed. He understood that.

Second, he liked working tickets himself. He didn't like having to simply tell another tech what to do when he was the escalation point instead of just doing the work himself. I asked him how he'd gotten so experienced in the first place. When he said he figured it out himself, I pushed back. I used to be his escalation point. I'd worked with him through the exact same process I was now asking him to run for someone else. After that conversation, he understood that developing other techs was a better use of his experience than solving everything personally.

Change is always going to feel hard, and your team will have objections. Their habits will fuel a lot of those objections. Your job is to separate the two.

The difference between a business that scales and one that flattens out over time is whether you implement systems and actually stick with them. Start building your systems and start that conversation at builttorunmsp.com.

Frequently Asked Questions

Why do employees report feelings as facts when a new system gets introduced?

When something feels harder, it's reported with the same confidence as something that's measurably broken, because the difference between an impression and a finding isn't obvious from the inside.

How should a leader respond when a trusted employee says a new process "doesn't work"?

Ask directly for specifics: which situations, how often, compared to what outcome. Trust in the person doesn't substitute for evidence about the system.

Why does defining the problem matter more than jumping to a solution?

A solution built on a vague or misdiagnosed problem tends to fail regardless of how well-designed it is, since it's solving the wrong thing.

How can a leader tell if resistance to change is legitimate or just habit?

Legitimate issues have a specific shape, a particular failure, a particular cause. Habit-based resistance and feelings-as-fact reporting tend to stay general and don't hold up once specifics are requested.