Build an individual contributor career path around work you would still need if your best specialist left. Start with one senior role. Write down what the specialist can decide, which duties they will stop doing and who can approve the pay. Test the remit against two recent cases before you discuss a title with a candidate.
What you'll learn
- Decide whether there is enough recurring specialist work for a senior role.
- Write a remit that distinguishes specialist decisions from people management.
- Test the remit against real work before making a promotion promise.
Start an individual contributor career path with recurring work
Picture a 24-person software company. One support specialist handles the hardest tickets and notices when the same incidents recur. When the queue gets busy, nobody updates the runbook, the team's instructions for handling a known issue. Someone needs to keep those instructions current and send reproducible product faults to Engineering. That work would still exist if your current specialist took another job.
Look at the last few weeks of tickets, escalations or rework. Pick out the problems that needed specialist judgment and ask which ones will recur after the current project. Give one-off work, such as a migration or a short backlog, a project owner and an end date. A ready candidate may still have nowhere to move. When the company cannot fund a lasting role, use the conversation for a promotion with no approved role.
Buffer's career framework from 2019 distinguishes development within a level from a change in the scope or complexity of the work. GitLab's engineering handbook requires a business need for the role before a Senior Engineer can move into a Staff Engineer or Engineering Manager role. Would you put the specialist role in next quarter's staffing plan if nobody had asked for a promotion?
Give the senior specialist decisions and time
Here is a role brief for the fictional support team. Use the same format for a different specialist role and substitute decisions that actually arise in your work.
- 01
Define the work
The senior support specialist reviews repeat incidents, keeps the support runbooks current and still takes complex cases. When a setup fault recurs, they can document the support workaround and send Engineering the steps to reproduce the fault. Check whether a colleague can use the runbook on the next case.
- 02
Set the decision boundary
They can change support runbooks and the routing rules for known issues within the agreed support policy. The support manager assigns staff and runs performance reviews. Engineering owns product changes. The support manager decides whether to make an exception to a customer commitment.
- 03
Make time and approve the scope
Remove one routine queue shift each week from the specialist's rota. The manager must arrange cover before the start date, and the founder approves the ongoing remit and the pay or pay range. If the team cannot cover the shift, reduce the new scope or put the role on hold.
Give the specialist time to help colleagues use the new runbook. Decide separately who takes onboarding, meeting notes and the other helping work that can accumulate around one person. Put the operating agreement where the team can find it. Keep pay details and any candidate assessment in the appropriate private record.
Test the role against two cases from last month
For the support team, take a repeat issue where the runbook needed a correction and a customer request that would change a service commitment. Could the specialist have corrected the runbook? Would they know to take the exception to the support manager? Check the rota for time to handle both cases. If the specialist would have to leave a queue shift that nobody can cover, settle the staffing problem first.
Discuss the actual job before offering it
In the same survey, 28% were interested in a management promotion and 31% said they wanted no promotion. These are stated preferences. The public summary does not describe recruitment or weighting, and it does not track which roles people actually took. Ask the person in front of you about the work they want.
Before offering the job, share the remit with everyone eligible and explain how you will assess candidates. For the support role, that could be sound judgment on complex tickets and a runbook update a colleague can follow. Bring one real decision the new role would own. In the fictional support conversation, you might say, “We have three tickets about the same setup failure. You would decide what the support runbook tells people to do. If fixing the fault requires a product change, Engineering makes that call. How does that mix of work sound to you?” The individual contributor versus manager guide can help if they want to compare what each job asks of them.
Say which terms have been approved and when the change would start. If scope or pay is unresolved, say who owns that decision and when you will come back to them. While approval is pending, keep the conversation exploratory and don't ask the person to start doing the permanent job.
After the first month, review a real case with the specialist and manager. Check who made the call, whether another colleague could use the runbook and whether the specialist still had the time set aside for the new work. Fix whichever part failed. If a case would help the next person see what good work looks like, share an anonymised version. Keep candidate assessments and customer details private.
Write down who decides and set a date to revisit the remit. If you use Cooperly, Fundamentals can help the team discuss who owns the work.