Your MSP Does Not Need More Heroes
Early in my MSP journey, having a wall of glowing screens and a desk covered in half empty coffee cups felt like a badge of honour. We were putting out fires, rescuing clients, and running on adrenaline. It felt important, and there was always something happening that proved how much we were needed. Looking back, we were often exhausted firefighters who never had time to ask why the building kept catching fire. There is nothing wrong with being able to respond well when something breaks. Clients need that capability, and good engineers take pride in helping. The problem starts when emergency response becomes the normal way the business operates.
Nick Clift
9/30/20263 min read
Early in my MSP journey, having a wall of glowing screens and a desk covered in half empty coffee cups felt like a badge of honour. We were putting out fires, rescuing clients, and running on adrenaline. It felt important, and there was always something happening that proved how much we were needed.
Looking back, we were often exhausted firefighters who never had time to ask why the building kept catching fire. There is nothing wrong with being able to respond well when something breaks. Clients need that capability, and good engineers take pride in helping. The problem starts when emergency response becomes the normal way the business operates.
Reactive work does not politely ask for a place in the diary. It arrives, demands attention, and makes everything else look less important. The immediate issue gets handled because it has to, while the work that might prevent it happening again gets moved because it can wait.
Then it waits again. Eventually, the recurring problem becomes familiar enough that everyone knows the workaround. Familiarity makes it easier to live with, but it does not make the problem disappear. The team gets better at responding to the same headache while the business gets used to needing that response.
Now add more clients. If the way work is delivered is already unpredictable, growth asks the same people to manage more of that unpredictability. There is more to remember, more to coordinate, and more opportunity for recurring issues to interrupt the day.
More work does not automatically make an MSP more mature. It can simply give existing problems more room to spread. That is why sales and operations need to belong in the same conversation. Winning work matters, but understanding how the business will deliver that work matters too.
Operational maturity can sound rather formal. You might picture a large process manual, an impressive diagram, and a meeting to discuss whether another meeting is required. That is not what I mean. I mean creating enough predictability that good people can do good work without constantly improvising around the same problems.
The goal is not to remove judgement from engineers or turn the business into a production line. It is to stop spending their judgement on things that should already be straightforward. People need room to think, not just room to fit in another ticket.
A new tool can be appealing when the business feels chaotic. It offers the possibility of a clean start: a better dashboard, a clever automation, or one platform that promises to bring the others into line. Tools have their place, but they need something sensible to support.
Before shopping, ask your lead engineer what recurring headache they are quietly tolerating. Then listen, not just to the technical description but to what the problem does to their working day. Where does it interrupt them? Why does it keep returning? What has stopped it being addressed properly?
You may not need a grand plan to begin. Choose one issue and make time to fix it properly this month. Give it enough attention that “fixed” means more than “not causing trouble at this particular moment”.
This is where operational maturity becomes a leadership responsibility. If every attempt to improve the way work happens is displaced by urgent work, the team cannot change the pattern on goodwill alone. Someone needs to protect a little space for improvement.
That might feel uncomfortable. When clients need help, slowing down to address a recurring issue can seem difficult to justify. But continually postponing it has a cost too; it just arrives in familiar pieces rather than one obvious decision.
In my role at Morphability, this is the kind of growth question I want to explore with owners: what needs to become steadier so the business can grow without depending on more heroics? There will always be difficult days in an MSP. Technology has never shown much respect for anyone’s plan to leave early on a Friday.
But difficult days do not have to define the business, and exhausted people do not have to be the price of progress. Ask your team which recurring rescue they would most like to stop performing, then help them make that possible.