Stay Interview Questions for Your Strongest MSP Techs

Explain What You Will Do With the Answer

Choose a private setting and tell the technician how you'll use the notes. Keep personal feedback out of the shared service board. You can record an operational action without publishing who raised it or the private detail behind it.

Open with: 'I want to understand what makes this a job you want to keep, and what gets in the way. I'll tell you what I can change, what needs a decision, and what I can't promise.' Then give them room to answer without correcting their account as they speak.

Don't promise secrecy you cannot maintain. If an issue needs someone else involved to address it, explain that and agree the next step where possible. A concern about the manager may need a different person to receive it.

If you can't hear a criticism without arguing, don't turn the meeting into a defence of your intentions. Ask for the work example and check that you understood it. You can investigate a disputed detail after the person has finished explaining the problem.

Ask Six Questions About the Job

These questions are a starting set I'd use for an MSP technician. They aren't a validated retention test and they don't predict a resignation. Follow the answer that matters instead of treating completion of the list as the result.

1. What part of your work here would you want to keep if your role changed? Ask for the task or responsibility they would miss.
2. What regularly makes it harder to finish good work? Ask them to walk through a recent example and the point where they became blocked.
3. Which work would you like to become better at, and what stops you practicing it? Separate the skill they want from a job title you may not have available.
4. What do you need from your manager that you aren't getting? Listen for a decision or form of support you can investigate.
5. What would make another role worth considering? Let them define the attraction without asking them to prove loyalty or name a prospective employer.
6. If we could change something about the work, what would you put first? Ask what a useful result would look like and who else it would affect.

When an answer is broad, ask for the example before choosing the fix. 'The queue is a mess' could mean missing ownership or a different issue entirely. Ask the technician to show where the work stopped, using the ticket record where appropriate.

Don't turn a request for development into an automatic promotion promise. Check whether the work exists and what capacity supervised practice would require. Be direct if the next management role isn't available.

Separate the Request From the Decision

Write down the concern in language the technician recognizes. Then separate what you need to investigate from the change you can approve. A request for fewer interruptions needs a workload check; it doesn't automatically mean buying another tool.

For a hypothetical example, suppose a senior technician says every difficult ticket reaches them without useful investigation notes. Check the handoff records and who is supposed to prepare them. The next decision may concern the escalation standard and coaching rather than the senior technician's willingness to help.

Give the responsible lead that operating problem to resolve. Keep the technician involved in checking whether the revised handoff provides what they need. Don't make them the unpaid owner of fixing a process they have just told you is consuming their time.

I don't buy a retention programme that renames unfinished management work as engagement. If the issue is a missing decision, make the decision. If it needs funding, take it to the person who can approve the cost.

Treat Pay as a Real Part of the Job

If the person raises compensation, record it plainly. Don't redirect them to a discussion about culture because the salary question is uncomfortable. Tell them who will review it and when they should expect an answer.

The model's position is to run healthy margins so you can pay good people well. Check an actual compensation proposal at burdened cost and put it beside the business plan. A private promise you haven't priced leaves another unfinished commitment.

The model's 20% annual staff turnover and $5,000 cost per hire are planning assumptions, not evidence that your technician is likely to leave. The hiring allowance covers such items as recruiting and onboarding lost time. It isn't a measured total cost for losing this person's knowledge or service capacity.

Don't use that allowance to claim a particular pay increase will pay for itself through guaranteed retention. You haven't established that result. You can still decide the proposed compensation is appropriate for the role and affordable without inventing a return calculation.

Put the Operational Change Where Work Happens

Test a proposed fix against the desk: what does this do to the board on Monday morning? If the answer involves a different escalation route, put that route into the actual handoff record and tell the people using it. Agreement in a private conversation doesn't change the queue by itself.

Keep the follow-up date tied to the work and any approval needed. Give the technician an update even if the decision isn't complete. Say what is waiting and who owns it rather than letting silence become the answer.

A suggestion box is not a line manager. Receiving the feedback doesn't finish the responsibility. Someone needs to make the decision and check whether the resulting change works.

• The interviewer checks the written concern with the technician before choosing the action.
• The service lead investigates any queue or handoff problem using the underlying work records.
• The owner approves or declines a funding or role decision and explains the reason.
• The action owner records the change and the agreed date for an update.
• The interviewer returns to the technician to check the result and any remaining problem.

Follow Through Without Claiming a Cure

If the person says the change helped, record what improved and what remains. Don't treat continued employment as proof the interview caused them to stay. Other parts of the role and circumstances outside work can affect that decision.

Use what you learn to inspect the operating problem elsewhere, without attributing private feedback unnecessarily. A missing handoff standard may affect more than the person who raised it. Verify that wider problem before presenting it as something the whole team believes.

Book the conversation with a clear purpose, then leave it with an action you can explain. Before you ask another technician the same questions, send the first person the promised update. That is the piece of the process you directly control.