Key takeaways:
- You usually don’t need more people first, you need defined roles. Headcount added on top of fuzzy role ownership just spreads the same confusion across more salaries.
- Combining roles is normal and often necessary. The damage starts when nobody knows which hat they are wearing or how much time they should be putting on a given ticket type or board, or when nobody has planned how those roles eventually split.
- Growth changes which role breaks first, not how many bodies you need. Scaling for volume and scaling for complexity strain completely different parts of the chart, and copying another MSP’s structure is the most common way to hire against the wrong one.
Every MSP hits a point where the business is growing, the work is technically getting done, and it still somehow feels worse than it did a year ago. Tickets slip through. Two techs touch the same escalation, and neither one closes it. Your best engineer is doing a password reset at 4:45 on a Friday because nobody else picked it up.
The instinct is to hire, and sometimes that is the right call. More often, capacity is not the constraint. It’s that nobody is entirely sure who owns what, and adding a person to that will not fix it.
This post draws on insights from Amanda Doucette-Lachapelle’s Frankly IT newsletter on LinkedIn, specifically issue #15, “How to Scale a Team That Won’t Break.”
In the early days, everyone wears every hat, and it works right up until it doesn’t
Amanda Doucette-Lachapelle is an MSP field strategist at Auvik. She writes the Frankly IT newsletter, mostly about the unglamorous parts of running a service business. Her description of a young MSP is the one most owners recognize instantly.
“When you first start your MSP, everyone wears a dozen hats,” she writes. “The owner is the technician, the marketer, the dispatcher, the vCIO, the salesperson, the janitor, and sometimes the therapist.”
Starting a business requires exactly that kind of hustle. But as the business grows, wearing all those hats gets harder, and things start to break down in a specific order:
- Tickets get lost
- Ownership over tasks gets fuzzy
- Burnout sneaks in
That is the moment you realize you don’t just need more people, you need defined roles.
Amanda’s test for this is blunt. Ask your team who owns a given piece of work, and see whether they can answer without laughing. Or crying.
There is real data underneath the joke. Gallup and Workhuman found that employees who strongly agree they know what is expected of them at work are 47% less likely to experience frequent burnout and 23% less likely to say they struggle with work-life balance. In an industry where retaining technical staff is already expensive and recruiting scarce tech talent is harder, role clarity is not a soft nicety. It is a proven retention lever.
Most MSP org charts revolve around the same seven functions, even when the titles don’t match
Every MSP’s structure looks a little different, but most eventually revolve around a few core roles. The useful exercise is not memorizing the titles, it is knowing what breaks when a function has no owner.
| Role | What it actually owns | What it looks like when nobody owns it |
| Tier 1 / help desk | First response, triage, password resets, basic troubleshooting | Everything escalates. Senior engineers get interrupted constantly |
| Tier 2 | Escalations, deeper troubleshooting, system administration | Tier 1 either sits on tickets too long or throws them straight at Tier 3 |
| Tier 3 / senior engineers | Complex issues, projects, infrastructure design, advanced troubleshooting | Projects slip because your senior people are buried in reactive work |
| NOC | Monitoring, patching, automation, maintenance, the quiet efficiency behind the scenes | Alerts pile up unread and problems are discovered by the client first |
| TAM (technical account manager) | The bridge between the tech and the client: communication, planning, reporting | Clients only hear from you when something is broken |
| vCIO | Strategic partner. Aligns technology with business goals and long-term planning | Renewals become price conversations because no one built the roadmap |
| Service manager / dispatcher | Flow of tickets, team workload, escalation paths | Work gets assigned by who shouts loudest or who happens to be online |
You may not have all of these today, and Amanda is clear that this is fine. “What matters is understanding the functions behind them so you can combine or separate as your business evolves.”
The useful question when you’re growing is not “which of these do we have,” it’s “which of these is currently a hire and which is still just a habit.”
Combining roles is normal, as long as everyone knows which hat they are wearing
In smaller MSPs, combining roles isn’t just normal, it’s necessary. Your Tier 3 might also act as vCIO. Your help desk might double as NOC technician overnight. Your service manager might be… you!
“There’s nothing wrong with that, as long as it’s intentional,” Amanda writes. “The trouble starts when people don’t know which hat they’re wearing, or when you never plan how those roles will eventually split apart.”
The fix is smaller than most owners expect. Assign ownership early, even if one person is holding several responsibilities. When everyone knows what they’re responsible for, accountability gets easier, burnout gets lower, and your business becomes scalable instead of chaotic. Auvik’s own guidance on assigning responsibility for IT makes the same point about documentation specifically: shared ownership of a task usually means no ownership of it.
| Pro Tip: Write the split before you need it. Pick the role in your business that one person is currently doing two jobs’ worth of. Write down, today, which half of that job leaves first when the workload doubles, and roughly what ticket volume or client count triggers it. You are not committing to a hire. You are removing the panic from the decision, so the split happens on your timeline instead of on the day that person hands in notice. Pair it with your employee utilization rates so the trigger is a number and not a feeling. |
There is no universal org chart, so stop copying the one that looks most professional
This is where a lot of MSP owners get tripped up. As Amanda puts it, “they try to copy another company’s org chart because it ‘looks more professional,’” when the truth is that there’s no universal org chart that fits everyone.
What your structure actually depends on:
- Your client base: Co-managed IT, SMBs, and regulated industries all require different depth. A co-managed client wants your team to slot alongside theirs. A compliance-heavy client wants named, credentialed owners.
- Your team’s strengths: Some MSPs thrive with generalists who wear multiple hats. Others need specialists who go deep. Both models work. They just fail differently, and they hire differently.
- Your growth goals: Scaling for volume and scaling for complexity require different team models, and they strain opposite ends of the chart. More on that in the next section.
“If you don’t offer specialized skills like vCIO or vCISO,” Amanda notes, “then you don’t need to have those in your org charts just because someone else does.”
The same logic applies to tooling. An MSP’s operational maturity level determines what will actually help versus what will just add noise, and copying a more mature MSP’s stack has the same failure mode as copying their org chart.
MSP growth changes which role breaks first, and it is rarely the one you’re hiring for
Most MSP growth advice is about the top of the funnel: pricing, packaging, acquisition, MRR. That work matters, but it tends to skip the part where growth actually lands, which is on a specific person on a specific Tuesday. Structure is a growth constraint long before it is an HR one.
The pattern below is common enough to plan against, but it’s not a prescription; the bands move depending on your client mix and automation, which is exactly why copying another MSP’s chart doesn’t transfer.
| Stage | What usually splits off | What is failing when it doesn’t |
| 1 to 5 people | Nothing yet. Owner plus generalist techs, all functions combined | The owner is still the escalation path, so growth stalls at the owner’s calendar |
| 5 to 15 people | Tier 1 separates from Tier 2 and 3. Dispatch becomes a real job rather than a habit | Senior engineers are interrupted constantly and project revenue slips |
| 15 to 30 people | NOC separates from the help desk. vCIO separates from senior engineering | Alerts go unread and renewals turn into price conversations |
| 30+ people | TAM separates from vCIO. Service management separates from dispatch | Client communication becomes reactive and workload balancing depends on one person’s memory |
Two different growth motions pull on completely different parts of this. Adding more seats at the same complexity is a Tier 1 and NOC problem, and it usually shows up as ticket volume outrunning triage. Adding more complex clients at the same seat count is a Tier 3 and vCIO problem, and it shows up as project slippage and quiet churn at renewal. Growth that gets misdiagnosed usually results in hiring another Tier 1 when the actual bottleneck was strategic capacity, or the reverse.
The other reason to plan the split in advance is cost. A role that should have divided six months ago does not announce itself with a resignation letter. It shows up first as reopened tickets, then as a slow degradation in one person’s queue, then all at once. If you want the financial framing, Auvik has previously published the math on how much revenue each role can carry, which turns “should we hire” into an MRR threshold instead of a gut call. Pair that with a defensible MSP business model and the org chart stops being a slide and starts being a plan.
Green techs and specialists are two different bets, and both of them can pay off
Some MSPs do incredibly well hiring greener techs: people with great attitudes, curiosity, and potential. Training them up internally can be powerful if you have a strong culture, solid documentation, and time to coach. Amanda’s view is that this is how you create a homegrown team that grows with the business, and it tends to build loyalty and consistency along the way.
The catch is the word “solid.” Growing your own only works if a new tech can get productive without shadowing your most expensive engineer for three months. That is a documentation problem more than a training problem, and documentation nobody actually trusts is the thing that quietly makes the greener-tech model expensive.
Other MSPs serve high-security or compliance-heavy clients, where experience and certifications aren’t optional. Those technicians are expensive and often out of reach for smaller providers. That is where outsourcing or fractional specialists can be, in Amanda’s words, your secret weapon. You get the depth on the accounts that need it without carrying the salary across every account that doesn’t.
Neither approach is better. As Amanda puts it, “they’re just different paths up the same mountain.”
Clarity is the antidote to chaos, so build the role before you build the headcount
Every MSP eventually hits the tipping point where doing more with less starts to cost more than it saves. That is the signal to define roles clearly, document responsibilities, and start building layers that protect your people from burnout. Here is the framework Amanda recommends:
- Define the outcomes you expect from each role, not just the tasks. Break it into Goals and Standards. Standards are the expectation to keep your job. Goals are the things to reach for. Most role descriptions only ever capture Standards, which is why they read as a floor and never as a direction.
- Assign ownership early, even if it’s one person for now. Be reasonable about what one person can accomplish and make sure they have room to succeed. If you want a sanity check on that, IT staffing ratios across the industry tend to land somewhere between 150 and 250 users per tech depending on client mix and automation.
- Plan your next split. When the workload doubles, which role divides first? Which person might be carrying more than they should?
- Communicate constantly. Make sure everyone knows their lane and who to go to when things shift. If someone is out sick or unsure of something, they should not have to guess.
The real key to scaling isn’t how your chart looks on paper, but how clearly your team understands their role in making the whole thing work. Get that right, and your MSP stops running on hustle and starts running on structure.
One caution worth carrying into any of this: your dashboards will not necessarily tell you when a role is overloaded. Your MSP KPIs might look healthy and still be lying to you, particularly when a single person is quietly absorbing the gap between two roles.
Where Auvik fits: most escalation problems are really context problems
Role definitions only hold if the knowledge behind them is portable. In most MSPs, the reason Tier 1 escalates too quickly isn’t skill. It’s that the context lives in one senior engineer’s head, or in a document last touched eleven months ago. Every escalation of that kind is your org chart failing quietly, and it gets more expensive with every client you add.
Auvik Network Management automatically discovers and maps client networks and keeps that automated network documentation current on its own. Practically, that means a Tier 1 tech opens a ticket with topology, device relationships, and configuration history already in front of them, instead of posting “does anyone know this client’s firewall setup” in Teams and waiting for someone senior to be free.
Auvik AI, powered by Aurora, is newer and worth being specific about, because “AI” in this industry usually means a summarizer. Auvik AI grounds its troubleshooting and alerting guidance in your actual network data rather than the public internet. It surfaces likely root causes as hypotheses, not verdicts, and every recommended action still needs a human to review and approve it before it runs, with an audit trail of what was recommended and who signed off.
For an org chart, that matters in one narrow but expensive way: it raises the ceiling on what Tier 1 can close without escalating, which is usually the exact constraint that forces you to hire a Tier 3 you can’t yet afford. Fewer false positives reaching the NOC means less alert fatigue for the people you can least afford to lose.
None of this replaces a role. It changes which role a piece of work has to land on, which is the only lever most MSPs have when hiring is slower than growth.
Write down your next split, then let Auvik carry the context
Before you redraw anything, do the smaller thing first. Find the person on your team who is currently doing two jobs’ worth of work, and write one sentence about which half leaves when the workload doubles. That sentence is worth more than a new chart, because it turns your next hire from a reaction into a plan.
Then look at what that person actually spends their day on. If a meaningful share of it is context nobody else can reach, that is not a headcount problem and another hire will not solve it.
That is the part Auvik Network Management and Auvik AI are built to take off your senior people. If you want to see what your team would be working with rather than read about it, book a demo and bring the client environment that gives you the most trouble. Judge it against the split you just wrote down.
Book an Auvik demo
See how Auvik simplifies network management in a live, guided demo.
FAQs
What happens to the person who has been doing four jobs when you finally split the role?
They usually experience it as a demotion even when it is a promotion, because scope is how people measure their standing. Name the new role before you name what is leaving it, give them first refusal on which half they keep, and be explicit that compensation is not moving down. The split that goes badly is almost always the one announced as an org change rather than as a conversation.
How do I tell a client that “their guy” is no longer their point of contact?
Frame it as coverage, not reassignment, and do it before the change rather than after the first ticket lands with a stranger. Clients tolerate structure well when it comes with a named backup and a documented escalation path. They tolerate it badly when they find out by getting a reply from someone they have never met.
Will defining roles drive away my best generalist?
It can, if the role you write is narrower than the person. Strong generalists usually stay when the definition includes a stated Goal that is bigger than the day job, such as owning standards across the team or leading the next split. What pushes them out is being handed a Standards-only description that reads like a ceiling.
Who owns the work that doesn’t fit anyone’s role?
Somebody has to, and by default it lands on whoever is most conscientious, which is how good people burn out invisibly. Keep a short, visible list of orphan tasks such as vendor portals, license renewals, and the one client’s weird backup job, and assign each one to a named person with a review date. Orphan work is the leading indicator that your chart is out of date.
At what revenue or client count do we actually need to add a role?
There is no universal revenue or client count that tells an MSP it is time to add a role, because those numbers do not show how efficiently the current team is operating or whether the business can afford the hire. Start by understanding each person’s capacity, establish the median level of efficiency across the team, and then look at that alongside backlog, ticket volume, service quality, and profitability.
A growing backlog may mean you need another person, but it can also point to inefficient processes, noisy client environments, poor documentation, or work that is not priced profitably. The right time to add a role is when the data shows that demand is consistently exceeding the reasonable capacity of an efficient team and the profitability exists to support the hire.
How do I know a role needs to split before the person burns out?
Watch for the operational tells rather than waiting for the conversation: response times degrading only on one person’s queue, that person’s tickets reopening more often, work that only moves when they are online, and time-off requests that get quietly withdrawn. Pair those with utilization data so you have a number to act on rather than a hunch.
Does the org chart change if we lean heavily on AI and automation?
The functions do not disappear, but the volume that reaches each one shifts, usually upward from Tier 1 and downward from Tier 3. The risk is assuming that means fewer people rather than different work. As Amanda has written elsewhere, AI scales whatever operational reality you hand it, so an unclear org chart plus automation gives you unclear ownership at higher speed.
What do we do about after-hours coverage when we don’t have a NOC?
Most MSPs solve this with some mix of rotation, an outsourced NOC, or automated monitoring with a tight escalation policy. The failure mode is an informal rotation nobody wrote down, where coverage depends on who happens to see the alert. Whatever you choose, the deliverable is a documented escalation path with named owners and a defined response window, not a general expectation of availability.
Do titles actually matter to technicians, or is it just about pay?
Titles matter mainly because they signal a path. A tech who cannot see what Tier 2 requires or how long it typically takes will assume the answer is “never,” and start looking. Publishing the criteria for each level, even informally, is one of the cheapest retention moves available to a small MSP.
How do I write role definitions that don’t turn into stale documentation nobody reads?
Keep them to one page with Goals, Standards, and a named backup, and review them on a fixed cadence tied to something that already happens, like quarterly planning. Roles drift the same way processes do: the team changes, responsibilities shift, and the document keeps describing a business that no longer exists. If nobody has questioned a role definition in a year, that is not stability, it is nobody reading it.
