Career ladders for support and operations staff so good people move up, not out

Meera joined an IT support firm as a service desk engineer four years ago. She now knows every difficult client user by name, fixes printer and VPN faults before the ticket is logged, and trains each new joiner. Last month she told her manager she had an offer from a software company. Her title had not changed in two years.

Losing her will cost the firm more than her replacement's salary. Clients will notice. This post shows how to build a ladder that makes Meera's next step visible before she starts looking.

Support and operations work is repetitive by design. People stay when they feel they are learning and when someone sees their progress. They leave when every year looks the same, when promotion depends on a manager's mood, or when a better title is available at a rival firm. A ladder cannot fix poor pay or heavy shifts on its own. It does remove the sense of being stuck.

Describe each level by what the person handles, not by years served. A first-level engineer resolves known issues using scripts and the knowledge base. A second-level engineer handles faults that need diagnosis, owns a small client group and writes new articles. A third-level engineer takes the hard problems, works with vendors, and shapes the runbooks. Above that sits either a senior specialist or a team lead.

The role design and job descriptions service from GullyHR is built for this exercise. The output is one page per level that a new joiner and a manager can both read.

1. 1

   List the roles you actually have

   Service desk, field support, infrastructure support, monitoring, client coordination. Write one line on what each does today.

2. 2

   Choose the levels

   Three to five per family is common. Fewer if the firm is small. Name each by responsibility, such as associate, engineer, senior engineer.

3. 3

   Write what changes at each step

   The kinds of tickets, the clients, the decisions the person can make alone, and the people they help to grow.

4. 4

   Define the evidence

   For each promotion, list the proof you will look at: tickets resolved without help, a runbook written, a client praise note, a junior coached.

5. 5

   Add the two paths

   Beyond a middle level, let people choose technical depth or team leadership. Make both paths carry real pay and respect.

6. 6

   Review twice a year

   Hold a promotion panel on a fixed calendar with at least two people, so decisions are not left to one manager.

Many firms promote the best fixer into a lead role and lose an excellent engineer to a mediocre manager. A technical path lets someone stay hands-on, own the hardest faults and mentor, with pay and standing that match. A lead path suits people who like rosters, client calls and coaching. Make it clear that both are promotions, not one being the consolation prize.

• Let strong service desk engineers shadow the infrastructure or cloud team for a few weeks each year.
• Offer rotations into project work, onboarding new client sites or migrations.
• Support a short list of learning goals per person, with time set aside to study during the week.
• Move people from support into pre-sales, quality or training roles if they show the aptitude.

Rotations cause gaps in cover, so plan them as carefully as leave. The post on shift rosters for security and network operations centres shows how to keep a roster whole while people rotate.

A ladder without a pay range feels like a title game. For each level, set a pay range using market data and your own margin, and tell staff that ranges exist. The post on pay and grading for infrastructure and security engineers sets out the steps. Keep promotion decisions and increment decisions separate, so a promotion is not delayed by the budget calendar.

Employee, current level, proposed level and date of last promotion.
Examples of work already done at the proposed level, with ticket or project references.
Client or colleague feedback gathered in the last cycle.
Skills shown: technical depth, communication, documentation, coaching.
Gaps to close before or soon after promotion.
Panel members and each person's recommendation.
Decision, effective date and the pay range for the new level.
Message to the employee, including development goals for the next cycle.

Hold a career conversation with each person at least once a year. Ask where they want to be in two years, what they have learned lately and what is getting in their way. Write it down and return to it next time. This takes thirty minutes per person and does more for retention than most perks. For the wider picture in firms of this type, see the IT support firms page.

You do not need a full framework before you act. Pick the family with the most resignations, usually the service desk. Sit with its two best people and the manager for one afternoon. Ask them to describe what a new joiner does in month one, what a trusted engineer does in year two, and what the person everyone calls for help does differently. Write the answers as three short paragraphs. That is your first draft of the ladder.

Share the draft with the whole team and ask what is missing. Engineers will point out tasks the managers have forgotten, such as handling a difficult user call or writing a fix note that others can reuse. Their comments make the ladder believable, and they show people that the firm is listening.

• Promoting someone to stop them leaving, without the work to match the new level.
• Keeping the ladder in a manager's drawer, so staff never see it.
• Setting levels so close together that every promotion feels like a rename.
• Ignoring night and weekend staff, who are often the most overlooked in reviews.
• Forgetting to update the ladder when a new service line starts.