Roles existed. Standards didn't.
At a professional services firm I worked with, no one agreed on what "good" looked like. Managers interpreted expectations differently. Employees didn't know how to grow. HR hired against one definition; the business evaluated performance against another.
Job descriptions described the role. They didn't define success. That gap showed up everywhere.
One framework. Six systems. No interpretation required.
I replaced job descriptions with a competency framework built to connect -- not just define. Every role broken down into specific, observable behaviors. A manager and an employee could read the same criteria and know exactly what good looked like.
Most competency models get referenced once a year during review season. This one fed hiring, performance, development, compensation, and coaching from the same source.
Hiring
Interview questions pulled directly from competency criteria. Evaluators assessed real behaviors, not impressions.
Performance Management
Reviews built around the same language. No invented expectations. Ratings consistent because the standard was shared.
Training and Development
Performance gaps mapped to a specific competency. Training had a clear target. Development conversations had a starting point.
Manager Coaching
Managers coached against defined criteria -- not gut feel. One-on-ones became more direct and more useful.
Compensation
Contribution measured against defined criteria. Pay decisions became easier to defend and harder to dispute.
Career and Internal Mobility
Employees saw exactly what each level required. Growth had a roadmap. Movement across roles had clear criteria.
What a competency form actually looks like.
Every role had a form like this one. Each competency written as a specific, observable behavior -- no interpretation needed in a review or a coaching conversation.
This example is from a professional services firm, for consultants leading technical implementations. The structure works for any role in any organization. The criteria change. The approach doesn't.
- Adjusts communication style and detail level based on the audience -- whether that's a project sponsor, a day-to-day user, or an internal team member.
- Follows up on open items without waiting to be reminded, keeping stakeholders informed of status before they ask.
- Flags when a conversation has shifted scope and documents what was agreed before moving forward.
- Prepares for client meetings with a clear agenda and leaves with documented next steps and owners.
- Asks clarifying questions rather than making assumptions when requirements are ambiguous.
- Proactively identifies risks or delays on their workstream and brings a proposed path forward before being asked.
- Tracks their own deliverables against the project plan and raises conflicts early enough to resolve them.
- Takes responsibility for the quality of their work output without needing a senior team member to catch errors.
- Understands how their workstream connects to the broader project and adjusts when upstream changes affect their tasks.
- Completes handoffs cleanly -- the next person can pick up the work without a walkthrough.
- Translates client conversations into clear, structured documentation that the broader team can act on without follow-up.
- Captures not just what the client asked for, but the business reason behind it.
- Keeps documentation current as requirements evolve, versioning changes in a way that's easy to trace.
- Identifies gaps or contradictions in requirements and surfaces them before they become configuration problems.
- Writes documentation at a level of detail appropriate for the audience -- technical enough for the build team, clear enough for the client to confirm.
- Manages multiple open tasks across workstreams without dropping details or missing handoffs.
- Prioritizes effectively when competing deadlines arise and communicates trade-offs clearly.
- Uses project tools consistently so others have visibility into task status without having to ask.
- Accounts for review and revision time when estimating task completion -- not just execution time.
- Recovers quickly when priorities shift, reorganizing without losing track of outstanding items.
- Shares information and context with teammates in ways that make the overall project easier to execute.
- Gives direct, useful feedback when asked -- not vague reassurance.
- Supports newer team members by explaining context and process without being condescending.
- Raises concerns within the team before they become client-facing problems.
- Contributes to team retrospectives with specific observations, not just general impressions.
- Offers a clear recommendation when a client is weighing options, rather than presenting choices without a point of view.
- Backs recommendations with reasoning the client can evaluate, not just assertions.
- Recognizes when a client decision has downstream implications and says so before the decision is made.
- Builds enough credibility with the client that they ask for this person's input, not just their deliverables.
- Stays current on platform capabilities so recommendations reflect what's actually possible.
- Knows the system well enough to tell a client what is configurable, what requires a workaround, and what is outside scope.
- Can demonstrate core platform functionality without relying on scripted walkthroughs.
- Understands how configuration decisions affect end users, not just the technical build.
- Stays current on product updates and flags when a new release affects an active project.
- Knows where to find answers when they don't know something, rather than guessing.
- Builds configuration that reflects documented requirements and holds up through testing without requiring repeated rework.
- Organizes configuration in a way that makes future changes easier, not harder.
- Documents configuration decisions so another team member could understand the logic without a walkthrough.
- Tests their own work before handing it off -- not just that it functions, but that it behaves correctly under real conditions.
- Recognizes when a configuration approach won't scale and raises it before it becomes a problem.
- Identifies data quality issues early and flags them before they create problems downstream.
- Validates source data against target requirements before migration begins, not during.
- Documents data mapping decisions clearly enough that errors can be traced back to their source.
- Understands the business meaning of the data they're moving, not just its technical format.
- Runs reconciliation checks after migration and resolves discrepancies before sign-off.
- Writes and executes test cases that reflect real client workflows, not just technical functionality.
- Documents defects with enough specificity that another person can reproduce and fix them.
- Distinguishes between a defect, a configuration gap, and a scope change -- and routes each appropriately.
- Retests fixes thoroughly rather than assuming the original issue is resolved.
- Tracks testing progress against the plan and escalates when coverage is at risk.
- Understands how data flows between connected systems and knows when an integration question needs to be escalated.
- Identifies integration dependencies early in the project and surfaces them before they delay the build.
- Tests integration touchpoints as part of their QA process, not as an afterthought.
- Communicates integration risks in business terms the client can understand, not just technical language.
- Documents integration behavior clearly enough that support teams can troubleshoot post-go-live.
- Diagnoses configuration issues methodically and documents the fix in a way others can reference later.
- Isolates the root cause before making changes, rather than trying fixes at random.
- Knows when an issue is beyond their ability to resolve and escalates with enough context to accelerate the fix.
- Checks whether a fix introduces any new issues before closing it out.
- Builds a personal reference of common issues and resolutions to avoid repeated investigation time.
The framework defines the path, not just the role.
Every form was built with movement in mind. Advancement, lateral shifts, and track changes all had defined criteria. Employees knew what the next step required. Managers had something concrete to coach toward.
Switching tracks didn't mean starting over. It meant identifying what carried forward and what needed to be built. That conversation was grounded in criteria, not guesswork.
When escalations spiked, the framework showed exactly where to look.
Project quality issues were traced back to inconsistent documentation and QA practices. The framework pinpointed the competency gaps. We worked with frontline managers, updated the criteria, built targeted training, and pushed it out through the same system already in place.
Clear criteria made the diagnosis fast. A flexible system made the fix straightforward.
What guided the build.
One language. Every decision.
Hiring, performance, development, and compensation all ran off the same foundation. Managers coached with better tools. Employees had clearer expectations. Hard conversations became practical ones -- because the criteria were already defined and shared.