IT Career Path Without Management: A Senior MSP Role

Agree That the Person Wants Technical Responsibility

Ask the technician whether they want deeper technical ownership or responsibility for managing people. Give them the actual duties to consider. Don't make a choice on their behalf because they solve difficult tickets.

Dustin Puryear describes an employee who tried project management, preferred technical work, and returned to his former job. He says he asked the employee how to explain the change to the team. That is one career-fit account, not evidence that technical staff should avoid management.

Erick Simpson recommends asking whether someone wants a development opportunity and revisiting interest later rather than treating readiness as a permanent verdict. He also supports people who prefer their technical work. I'd use that conversation before writing a development plan the employee never asked for.

State the decision plainly: 'We can explore a senior technical role with these responsibilities. We have not agreed a management promotion.' Give the person room to say that the proposed technical work isn't what they want either.

Give the Technical Track a Business Job

Start with technical work the MSP needs to own. Choose a defined area where the person can investigate a problem, make a recommendation, and leave a result another technician can use. Avoid a role description that amounts to being available whenever the owner gets stuck.

The following is a proposed split for your role brief. Change the boundaries to match your actual service operation, and name who accepts each decision. Technical authority should be visible before colleagues depend on it.

Paul Green asks whether a service desk manager must be a technician, emphasizing communication and resource planning when considering that role. His role-design suggestion is a useful distinction here. Decide which management work needs doing rather than treating technical depth as the entire management job.

Skip career-framework jargon. Write what the person can decide, what they must refer, and who answers the referral. A new title cannot take a ticket off the board.

Name the Output and Its Reviewer

For a hypothetical role brief, give the senior engineer responsibility for reviewing designs within your supported stack. The proposed output is a recorded technical decision with conditions the project owner can act on. The reviewer checks the reasoning against the requirements and the actual implementation constraints.

Keep the authority precise. The engineer might accept a technical approach within an approved standard while referring an exception to the named service authority. Don't let a technical sign-off quietly become permission to promise an unpriced service to a client.

Ray J. Green says he documents a role's intended outputs and boundaries, then uses that document in follow-ups and revises it with the person doing the work. I'd use that approach to inspect this job. Keep the conversation about the work delivered and the decisions still blocked.

Choose evidence that belongs to the responsibility. For design review, inspect the review record and whether the project owner can follow its conditions. For technical mentoring, inspect the learner's explanation and the resulting work rather than counting the senior engineer's attendance alone.

Remove Work When You Add Responsibility

Put the proposed role beside the live workload before approving it. Have the service manager identify the current assignments that will move to someone else. Name the person taking that work and check that they can carry it.

Erick Simpson recommends considering protected first-line coverage instead of repeatedly pulling the same staff into projects and onsite work. He pairs that advice with documented methods and trained rotation. Use the same care when arranging access to your senior engineer; a mentoring request needs a place in the work plan.

My test is simple: what does this do to the board on Monday morning? It should show the technical responsibility as planned work, with someone named to carry the assignments it displaced. If everything remains assigned to the same person, revise the plan before calling it progression.

Keep a route for urgent technical escalation, with the service manager deciding what work is displaced. Don't make every colleague's request an automatic interruption. Record the demand so the next role review includes the job being performed rather than the quieter job on paper.

Assess Technical Progress Against Agreed Work

James Bier recommends showing technicians a possible next role and the agreed benchmarks or qualifications supporting progression. He also recognizes that some technicians prefer to stay in their current help-desk role. Make the path available without making advancement an obligation.

Assess the responsibilities you actually agreed, using work the person had a fair opportunity to demonstrate. Keep a missing opportunity distinct from an unsuccessful attempt. Give a specific next assignment where the record doesn't yet show the required judgment.

Dustin Puryear treats a red KPI as a prompt to investigate role fit, resources, and the measure itself. I'd apply that caution before declaring this role unsuccessful because ticket closures changed. Check which work the engineer was assigned and whether the measure describes it.

Have the technical reviewer record the decision and the remaining gaps. Keep the employment and pay decision with its authorized owner. A good technical result can justify a readiness discussion without creating a job or a budget that hasn't been approved.

Budget the Role and State the Pay Decision

The owner owns the budget decision. In the opening hypothetical, $84,000 × 1.25 = $105,000 is the annual burdened-pay cost of the role. If an existing employee moves into it, calculate the actual change from their current cost and any work you intend to backfill; don't automatically add another whole employee.

Set the actual compensation for the defined role and your approved budget. Jack Lincourt describes a pay structure with listed certification increases, while treating role-level increases and other adjustments separately. His account is an example of separating pay decisions, not a pay band to copy into your MSP.

Tell the technician what decision has been made and who can approve a change. If the business can't support the role yet, say so and discuss a bounded responsibility you can genuinely fund. Don't extend an assessment indefinitely to conceal a budget refusal.

Put Names Against the Role Agreement

Use this checklist before assigning the new responsibilities. Each owner should accept their line, including the time and decisions it requires.

• Owner: approve the role purpose, cost, compensation decision, and work that needs backfilling.
• Service manager: assign the technical work and name who takes the displaced queue or project duties.
• Technical reviewer: agree the decision standard and record the evidence used to assess readiness.
• People manager: explain the employment responsibilities that remain with management.
• Technician: confirm interest in the role and identify the support or authority still missing.

Leave the agreement with an actual technical assignment and a named reviewer. The useful career step is a responsibility the employee can exercise and the business can support. Keep that promise small enough to be true before you make it larger.