You promote your best tier-two tech to lead, and within two weeks the desk is slower than it was before the promotion. The new lead still closes tickets like they always did, nobody owns dispatch, and your other techs are watching to see if the decision was about skill or about who the owner likes best.
The fix is to stop treating each tier as "more skill" and start treating it as a different job. Each tier owns a different outcome, and you promote against a written standard that names the behaviors you can actually see. That standard is what makes the decision fair, and it's what keeps a good tech from becoming a bad lead.
Why Promoting Your Best Tech Can Backfire
Picture it: your strongest tier-two tech, the one who could untangle any mess, gets the lead title. You expect the team to level up. Instead, the new lead is buried in the hardest tickets, the queue backs up, and your other techs are escalating to you because they don't know who assigns work anymore.
The mistake is promoting the person who is best at the current job, not the person who can do the next one. Closing twenty tickets a day is not the same as getting twenty tickets closed. Those are different skills, and the second one is what a lead actually does.
So what does "owning" a tier actually mean in practice?
Tier One Owns the Simple Stuff, and the Exit
Tier one's job is to resolve standard requests and clear incidents within the documented time, close the ticket properly, and know when to escalate. The difference from tier two is not knowing more commands. It's that tier one works on problems with a known fix, and tier two works on problems that don't have one yet.
A tier-one tech resets a password in five minutes and notes the ticket. A tier-two tech investigates why password resets keep failing, finds the sync error, and fixes the root cause. Both are useful. Only one of them is diagnosis.
So what does tier two own that tier one does not?
Tier Two Owns the Messy Problems
Tier two owns problems that need diagnosis, root-cause thinking, and documentation updates. The outcome is not just "fixed." It's that the next time this issue appears, it's tier-one work because the knowledge base has a runbook.
Say you run a twelve-person MSP. A client keeps reporting that email is slow. Tier one escalates it twice. Tier two digs in, finds a DNS misconfiguration, fixes it, and writes a short runbook so tier one can handle it next time. That's the tier-two outcome: the KB is better than they found it.
Once a tech is great at tier two, how do you know they can lead a team, not just solve hard problems?
The Team Lead Owns the Flow of Work, Not the Hardest Ticket
The lead's job is to make sure the team delivers the service promise: dispatch, ticket review, coaching, and removing blockers. That means the lead does not take the hardest technical tickets. They take the ones that teach someone else, or they hand them to the tech who needs the stretch.
The skill list for a lead is different. Communication, delegation, and judgment about what to escalate to ownership matter more than knowing every protocol. My view: if a tech can't explain a fix to a peer without taking over the keyboard, they aren't ready to lead.
A lead notices a client keeps sending the same type of request. Instead of fixing it themselves, they adjust the template or the training so tier one can handle it. That's the job: making the whole team faster, not being the fastest one on it.
So what does the promotion standard look like in practice?
A Written Standard That Makes Promotion Feel Fair
Write a one-page matrix. For each tier, list three to five observable behaviors: "closes tickets without escalation," "updates documentation without being asked," "coaches a peer on a ticket." Then review each tech against it quarterly, using ticket history as evidence.
The standard makes the decision about behavior, not favoritism. A tech who escalates every unusual ticket does not meet the tier-two standard. Another who resolves two and writes a KB does. That's a fair comparison, and the techs can see it.
Budget for the review: roughly 30 minutes per tech per quarter, plus the initial time to define the behaviors. Treat that number as a starting point and adjust it against your own ticket volume and team size.
This standard assumes you have a ticketing and documentation base. If your notes are thin or your processes aren't written down, you can't see a tech's thought process, and the review is guesswork. Fix the tooling first, then promote.
When the Promotion Will Backfire, and What to Do Instead
The standard fails when the team is too small to take the lead off the queue. On a team under roughly five techs, the lead may keep a partial technical queue, and the management portion of the role gets adjusted accordingly. That's fine, as long as the management tasks are still on the list and someone covers the lead's tickets part of the week.
Owners who have tried this report the promotion went sideways because the lead never actually stopped being a tier-two tech: ownership kept pulling them back into technical work during tight times. If you can't resist that pull, don't make the promotion yet.
And it fails when the promotion is really about keeping a tech who might leave. A title with no management workload creates confusion, for the tech and for everyone else. If that's your situation, create a senior tech role instead: keep the technical work, add mentoring, and skip the management title.
On Monday, write the one-page matrix. Name the outcomes for each tier, list the behaviors, and tell your techs what moves them up. You'll still have hard conversations, but they'll be about the standard, not about whether you played favorites.
mspoutpost.com/articles/what-actually-changes-between-tier-one-tier-two-and-team-lead
Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.
