Optimal Organizational Structure for MSPs
Most MSPs have struggled at some point with figuring out the smartest way to organize their staff to meet the Customer’s needs most efficiently.
Can you relate?
Maybe you’re wondering what the answer is – or if there is one at all.
I’m going to be upfront with you before we even begin:
The answer is complex, and it takes a Business Analysis perspective to tackle it properly.
At least three factors go into designing the optimal Organizational Structure for an MSP’s Service Delivery operation. These are:
1. Staffing levels
2. Workflow Mix
3. Seat Size Range of the Target Market
Staffing Levels:
Let’s start with the Staffing Levels of a 3, 6, 10, 40, 80, & 120 Tech shop. Yes, we are familiar with each level of growth having worked for, or with, MSPs at each level.
Carol H. worked for an MSP that averaged 6 Techs during her tenure. I joined an 80 Tech shop that was still structured as a 40 Tech shop and helped them grow to a 120 Tech shop.
Over the last four years, in addition to working with MSPs of these sizes, we have also worked with 3 Techs or less in addition to the 10-40 Tech range. As we compare notes, we have found significant Service Delivery Operational differences exist between these levels.
3-Tech Shop:
At the 3-Tech level, life is very collaborative, and it is an all-hands-on deck approach. The focus is to capture all requests in a ticket and work to complete all tickets as best as possible. While things like Request Segmentation, Automated Customer Communication, and SLA Automation are very helpful, most of the decisions are intuitive because each Tech has a rich understanding of each Customer and a full understanding of who is best to do what within the company.
The 4th Service Delivery Team hire should be a Service Coordinator for no other reason other than a Service Coordinator will make the Techs 10% more efficient. This efficiency covers the cost of hiring a Service Coordinator including burden. Hiring a Service Coordinator at this stage makes it easier to scale to a 6-Tech shop and beyond.
Somewhere between 3 and 6 Techs, the all-hands-on-deck approach starts breaking down because not all Techs know every Customer, and who is best for what. The challenge of what to work on next already exists, but at 3 Techs, the ratio of Tech to Owner is not overly burdensome. The inefficiency, while being part of the barrier to growth, is not at an obvious level. By the time the MSP grows to 6 Techs, what to work on next becomes such a concern that the MSP is polarized and unable to focus on growth.
6-Tech Shop:
At this level, Request Segmentation (at a very crude stage) organically starts to emerge. It becomes noticeable when the best Tech in the shop starts doing more project work. Project work that, over time and with growth, becomes more difficult and stressful to do because of the number of escalations and disruptions.
This happens because the best Tech in the shop is focused on projects but is still needed for Managed Services support. They are also required for non-Managed Service customer support, but in this instance, it is best effort - which means less pressure and less of a disruption.
It is at this stage that a Tech is dedicated to managing the RMM and triaging all alerts. This is not a position to engage on the alert issues; but rather to:
· Analyze the noise
· Create scripts to drive down the ticket counts, as well as the ones needing engagement
· And finally, they ones needing engagement, are sent to Triage for Review and Assignment
At this point, the collaborations and communications break down. This causes the ticket backlog to grow out of control, Customers demanding to talk to their favorite Tech as they did in the 3-5 Tech days, and the Owner feels the burden of Service Delivery holding back growth.
10-Tech Shop:
At this stage of growth, dividing the Techs into Teams starts making sense. Most MSPs break off the Project Engineers and try to get them into a group by themselves. I say “try” because - in general - this does not work and is not the right way to go.
The best way is to structure the Teams with a Sr. Level III Project Engineer (Yes, I know this is three titles rolled into one, but you get the meaning of who I am talking about), several Mid-Level Techs/Engineers, and as many Help Desk Level I entry Level Techs as needed to engage on all End User issues the Customer base requires to meet expectations.
This Team model gives the benefit of the Front-Line Techs having easy access to the Level III knowledge, and the Level III Engineers stay in touch with what is going on at the front.
A conscious effort should be made to grow the Mid-Level Techs’ skill sets so they can take on more of the escalation work, freeing up the Level III to work on projects undisrupted.
This conscious career growth should be made at every Level.
We strongly recommend at a 10-Tech shop and above that an Intern partnership be built with the local college. That way, when Students graduate you have a ready list of applicants, and as these new hires grow in experience, they can be promoted up through the ranks and eventually become the Level III person. They’ll also be groomed the way you want, focusing on the Customers and Technical Quality. This also works great with Marketing people.
40-Tech Shop
This is the level where the Teams start taking on specialties. Here, a Help Desk emerges that takes on End User issues only. A Team that specializes in Phone work, another on Network Devices, while another on Core Devices. One Team may focus on Fieldwork, another on Cloud Services, and a full Team for Security as well as another for Monitoring Alerts. All the while keeping the Level I, II and III per Team structure in place.
This is also the level where Shift Left starts to hit its stride.
Shift left is the concept where a Level III develops the best practices, standard builds, and project documentation. This information is then handed off to the Level II techs for validation and refinement.
Once it becomes a repeatable process, the information is passed down to the Level I tech to continue implementing the Workflow (think VMware provisioning and Citrix NetScaler or Load Balancing). The end goal is to have a process so well defined and repeatable; it can be exposed to a Customer portal for Self-Implementation Tools.
80-Tech shops:
This is where the Teams take on an identity of their own. The skill level and competency in each area of expertise become so deep that Sales Engineering is a specialty on each Team.
At this stage, there will be a Service Manager for each Team, and a Director Level emerges. Rockefeller Habits in reverse works well. Rather than Top-down setting the vision and communicating down to the troops for execution, it is the Techs rolling up Customer-Facing issues so Executive Management is aware of where they need to put their Customer-Facing energies.
This is also the stage where true vCIO or Out-Sourced CIO services emerge. And the partnerships with Customers grow to the point of having a seat at their Executive Management table.
120-Tech shops:
Somewhere between 80 and 120 Techs a PMO team becomes a competitive advantage. In the world of MSP Project Management, the PMO resembles more of what PMI views as a PMO than having a group of Project Managers.
This is because of the governance aspect of managing projects within an MSP environment. Ideally, by the time you have 120 Techs, there would be enough Resources to go around.
The problem is, the ratio of Project work, to Field Work, to Preventive Maintenance work, to Break/Fix remediation remains about the same. Whether your Sr. Engineers are on a Professional Services Team or a Collaborate Team across all skill levels, Managed Service Support still disrupts Projects - just like at the 3-Tech shop and above.
In other words, as the MSP staff grows, the Service Delivery Issues remain the same, and fixing them is a lot more difficult as the shop grows.
How do we know? Because we have 22+ years of MSP Service Delivery Coordinator/Manager experience on staff, and 17+ years Autotask System Administration experience. Which is another way of saying we have been there and done that, and we know how to leverage the Autotask software to Resolve Service Delivery Issues.
