A senior technical consultant asks for a meeting after a long integration project. She has worked on three go-lives in four years. She asks the owner a simple question: what is the next role for me, and what would I need to show? The owner says 'we will see after this quarter'. Two months later she resigns.
In a small or mid-sized implementation firm, titles often grow by accident. This post explains how to write a career ladder that is honest about what the firm can offer, and fair to both functional and technical people.
Why a ladder matters in a services firm
Consultants are sold by role and level. Clients ask who will lead the finance design and who will build the interface. If levels are vague, billing is vague and pay is argued case by case. A clear ladder helps delivery planning, pay decisions and retention together.
It also helps hiring. Candidates compare firms on growth. A firm that can show a written path to architect or practice lead competes better with larger employers, because the candidate sees the next step in writing.
Two tracks, and one place where they meet
Functional consultants move from configuring a module, to owning a process area, to designing across modules and advising the client's leadership. Technical consultants move from building and unit testing, to owning an interface or data migration, to designing the technical landscape and making architecture calls.
The tracks meet at solution architect, where a person must understand both the business process and the system constraints. Some firms also offer a manager track for those who want to lead people and projects. Keep it separate from the expert track so that a great consultant is not forced into management to get a raise.
Build the ladder in five steps
- 1
List the roles you really have
Start from live projects, not from titles. Write down who does what today across analysis, configuration, development, testing, migration and client leadership.
- 2
Choose three to five levels per track
Fewer levels are easier to keep fair. Each level gets a name, a short description of scope and the decisions the person owns.
- 3
Define evidence for each step
Describe what a reviewer should see before a promotion: a module delivered with little rework, a client workshop led, a junior coached, a design adopted. Use examples from your own projects.
- 4
Mark the switch routes
Say how a technical consultant can move toward functional design, or a functional lead toward delivery management, and what learning is expected.
- 5
Review it every year with the team
Ask consultants whether the ladder matches their work. Update the wording when the product mix or client type changes.
What counts as evidence for promotion
- Scope handled without close supervision, shown by project documents and client feedback.
- Quality of work, such as fewer defects raised after hand-over and clear design notes.
- Ability to explain trade-offs to a client in plain words.
- Help given to colleagues: reviews, coaching, reusable templates.
- Reliability under pressure during testing and cutover.
- Learning shown through certifications, internal sessions or a new area taken on.
A sample ladder outline to adapt
Level one, associate consultant: works on defined tasks under review. Learns the product and the project method.
Level two, consultant: owns a module or interface for a client with light review. Writes own design and test notes.
Level three, senior consultant: owns a process area or technical component across a phase. Coaches juniors. Leads client workshops or design reviews.
Level four, lead or principal consultant: designs across modules or systems. Advises the client's project sponsor. Reviews colleagues' work.
Level five, solution architect or practice lead: sets standards, shapes proposals, supports presales and signs off complex designs.
Manager branch: delivery manager or project manager roles for those who choose to lead people and budgets.
For each level: scope, decisions owned, three examples of evidence, learning expected.Link the ladder to pay and learning
A ladder without a matching pay structure causes disputes. Each level needs a pay band set by the company, informed by what you charge, what you can afford and what people at that level are paid in your market. Do not copy another firm's figures. Our role design and job descriptions service helps write the level descriptions, and the same work supports a pay structure.
Learning should match the ladder too. A consultant moving toward architect needs time and support for new areas. See certification and training support: a fair reimbursement and bond approach for how to fund that fairly.
Talk about the ladder, not only publish it
Share the ladder in a team session and ask people to place themselves honestly. Then hold a private career talk once or twice a year. In that talk, name the next level, the gap in evidence and one assignment that could close it. Many resignations in this industry follow a vague answer to exactly this question.
Custom development firms face the same issue, as the HR guide for custom software companies explains. Where a project ends and the team scatters, see also keeping consultants after go-live.
