Using ADKAR to Improve Technology Team Management: A Decision-Grade Guide

Intro

Technology leaders often face a common challenge: a promising process change, tool adoption, or reorganization stalls despite clear technical merits. Engineers resist, middle managers hesitate, and old habits persist. The ADKAR model, developed by Prosci founder Jeff Hiatt, offers a structured way to manage the people side of change. ADKAR stands for Awareness, Desire, Knowledge, Ability, and Reinforcement. Unlike broad change frameworks that focus on organizational phases, ADKAR targets individual transition. For engineering managers, it provides a practical lens to diagnose why a change is not sticking and to design targeted interventions. This guide explains when ADKAR is the right tool, how to apply it to a realistic technology team scenario, and how to govern its use with clear decision rights and metrics. You will learn to distinguish ADKAR from adjacent methods like Kotter's 8-Step Model or stakeholder mapping, and you will get checklists and criteria to decide whether to continue, modify, or stop a change initiative.

Management Context: Where ADKAR Applies

ADKAR is a goal-oriented change management model that describes the five sequential outcomes an individual must achieve for a change to be successful: Awareness of the need for change, Desire to participate and support the change, Knowledge of how to change, Ability to implement required skills and behaviors, and Reinforcement to sustain the change. It is best suited for changes that require people to adopt new behaviors, tools, or processes, such as moving to a new architecture, implementing agile practices, or adopting a new project management system.

Unlike Kotter's 8-Step Change Model, which is an organizational, top-down process for large-scale transformations, ADKAR is individual-focused and can be applied at any level. It is also distinct from stakeholder mapping, which identifies influence and interest but does not prescribe how to move individuals through change. ADKAR is complementary to these tools: you might use stakeholder mapping to prioritize communication, Kotter for overall governance, and ADKAR for day-to-day coaching.

ADKAR is not a universal framework. It works well when the change is clearly defined, the desired future state is known, and the main barrier is human adoption. For ambiguous situations like exploring a new market or defining a new product, discovery methods such as customer discovery, design thinking, or Lean Startup are more appropriate. Similarly, for improving an existing measurable process with identifiable root causes, DMAIC or PDCA may be better suited. ADKAR should be used when the primary problem is that people are not changing their behavior despite a clear technical solution.

The cadence of ADKAR application depends on the change. Some changes, like adopting a new code review tool, may take weeks; others, like shifting to a DevOps culture, may take months or years. Do not force ADKAR into a fixed quarterly cycle. Instead, assess progress against each ADKAR element in regular one-on-ones and team retrospectives, and adjust interventions based on evidence.

Technology Organization Example

Consider a technology organization that wants to reduce rework in its content pipeline. Currently, topic ideas often turn into poorly scoped articles that require multiple revisions. The leadership decides to implement a structured process: researchers create briefs, writers generate drafts, reviewers evaluate, and editors approve. This change requires writers to follow new guidelines, reviewers to use new criteria, and managers to enforce the workflow.

The ADKAR model can guide this change. Here is an illustrative example with explicit phases, roles, and decision points. This example is hypothetical and uses illustrative numbers.

Phase 1: Awareness

• Goal: Writers and reviewers understand why the new process is needed.
• Actions: The engineering manager presents data on rework rates (e.g., 30% of drafts require major revisions) and explains how the new process will reduce wasted effort. They hold team meetings and one-on-ones to discuss the impact.
• Owner: Engineering manager.
• Decision point: Is there sufficient awareness? If not, continue communication before moving to Desire.

Phase 2: Desire

• Goal: Individuals are motivated to participate.
• Actions: The manager addresses concerns, such as fear of reduced creativity or increased bureaucracy. They involve influential team members in designing the workflow and offer incentives like recognition for high-quality briefs.
• Owner: Engineering manager with support from team leads.
• Decision point: Are key influencers on board? If resistance remains, identify root causes (e.g., lack of trust) and address them.

Phase 3: Knowledge

• Goal: Team members know how to use the new process.
• Actions: Provide training sessions on writing briefs, using the review checklist, and providing constructive feedback. Create documentation and templates.
• Owner: Technical writer or process expert.
• Decision point: Can team members demonstrate knowledge? If not, provide additional training or simplify the process.

Phase 4: Ability

• Goal: Team members can perform the new process in practice.
• Actions: Start a pilot with one team or one type of article. Provide coaching and feedback. Measure performance against baseline.
• Owner: Team lead.
• Decision point: Is the team able to follow the process without excessive support? If not, adjust the process or provide more hands-on help.

Phase 5: Reinforcement

• Goal: Sustain the change.
• Actions: Monitor metrics, celebrate successes, and address backsliding. Integrate the process into regular workflows and performance reviews.
• Owner: Engineering manager and HR.
• Decision point: Is the change becoming the new norm? If not, reinforce with additional measures or consider modifying the process.

A narrow pilot is essential. For instance, pilot the new process on internal documentation first, where the stakes are lower, before rolling out to customer-facing articles. Measure both success metrics (e.g., reduction in rework, faster time to publish) and guardrail metrics (e.g., writer satisfaction, quality of published articles, missed deadlines). This pilot aligns with the principle that the first useful pilot should be narrow, measurable, and easy to inspect locally.

Decision and Governance Checklist

Effective governance of an ADKAR-based change requires clarity on decision rights, progress metrics, and criteria for continuing, modifying, or stopping the initiative. Use the following checklists to structure reviews.

ADKAR Progress Assessment Table

Decision and Governance Checklist

• Have you defined the change clearly and confirmed that the primary barrier is human adoption?
• Have you identified the target population and their current ADKAR status?
• Have you assigned a sponsor with authority to allocate resources and remove obstacles?
• Have you established baseline metrics for the current state?
• Have you defined success metrics and guardrail metrics for the change?
• Have you planned a narrow pilot to test the change?
• Have you established a review cadence (e.g., weekly during pilot, monthly after rollout) to assess ADKAR progress?
• Have you defined criteria for continue, modify, or stop decisions at each ADKAR stage?
• Have you identified potential resistance and planned Desire-building interventions?
• Have you planned reinforcement mechanisms (e.g., recognition, performance metrics, process integration)?

Continue, Modify, or Stop Criteria

Use these tables in management reviews to make evidence-based decisions. Avoid relying on anecdotes; collect data at each ADKAR stage.

Common Pitfalls and How to Avoid Them

ADKAR is straightforward in theory but easy to misapply. Here are four frequent mistakes, why they happen, and how to recover.

Pitfall 1: Skipping Desire because Awareness seems high

Managers assume that once people understand the reasons for change, they will support it. In reality, individuals may understand the need but fear personal loss, extra work, or loss of autonomy. To avoid this, never assume Desire follows Awareness automatically. Engage in one-on-ones to surface concerns. If Desire is low, use techniques like involving resisters in design decisions, offering incentives, or linking the change to personal career growth. Reassess Desire individually, not just as a team average.

Pitfall 2: Treating Knowledge and Ability as the same stage

Knowledge is knowing how to do something; Ability is being able to do it under real conditions. A common mistake is to provide training and assume Ability will follow. For example, a developer may pass a quiz on a new branching model but struggle to use it during a high-pressure release. To avoid this, create opportunities for practice in a safe environment before go-live. Run a pilot, pair team members, and provide coaching. Measure Ability through observed performance, not just test scores.

Pitfall 3: Forgetting that ADKAR is individual, not organizational

Some leaders apply ADKAR as a project plan, moving the whole team through stages together. But individuals progress at different speeds. One engineer may be ready to change while another is still unaware. To avoid this, assess ADKAR status for each affected person, especially key players. Use one-on-one meetings to track progress and tailor interventions. A team-level score can hide pockets of resistance that later derail the change.

Pitfall 4: Neglecting Reinforcement after early success

Initial wins create momentum, but old habits return if the change is not reinforced. Teams may revert to the old process when pressure mounts or leadership attention shifts. To avoid this, build reinforcement into the operating rhythm: include the new process in checklists, dashboards, and performance reviews. Celebrate milestones publicly. Monitor guardrail metrics for at least three months after rollout. If backsliding occurs, investigate the cause and reapply appropriate ADKAR elements.

Metrics and Measurement

To govern an ADKAR-based change, you need data at every stage. Below are example metrics for the content pipeline scenario, with owners and review cadence.

Awareness metrics

• Percentage of team members who can correctly state the business case in a survey. Target: 90% within two weeks. Owner: Engineering manager. Review: weekly during Awareness phase.
• Number of awareness sessions held and attendance. Target: 100% attendance. Owner: Engineering manager.

Desire metrics

• Engagement in change discussions: number of questions, suggestions, and volunteers. Target: at least 5 substantive contributions per week. Owner: Line managers.
• Sentiment score from pulse surveys (e.g., 1-5). Target: average above 4.0. Owner: Line managers.

Knowledge metrics

• Training completion rate. Target: 100% within one month. Owner: Process owner.
• Assessment scores on process steps. Target: 85% or higher. Owner: Process owner.

Ability metrics

• Pilot performance: rework rate on articles following new process vs. baseline. Target: reduce from 30% to 10% within two months. Owner: Team lead.
• Coaching sessions per team member. Target: at least 2 per month during pilot. Owner: Team lead.

Reinforcement metrics

• Ongoing rework rate after rollout. Target: remain below 15% for six months. Owner: Change sponsor and HR.
• Process adherence: percentage of articles following the new workflow. Target: 95% after three months. Owner: Change sponsor and HR.

Guardrail metrics

• Writer satisfaction survey (monthly). Threshold: no decline below 3.5 on 5-point scale. Owner: HR.
• Quality of published articles (editorial score). Threshold: no drop in average score. Owner: Content lead.
• Missed deadlines: percentage of articles late. Threshold: no increase above 10%. Owner: Project manager.

Review cadence: During the pilot, review progress weekly in a 30-minute meeting with the change sponsor, process owner, and team leads. After rollout, review monthly for at least six months. The single accountable owner for the overall change is the engineering director, who reviews the ADKAR dashboard and makes the final continue, modify, or stop decision at each stage gate. Stage gates occur at the end of each phase: after Awareness (week 2), after Desire (week 4), after Knowledge (week 6), after Ability (week 10), and after Reinforcement (monthly thereafter).

When to Stop a Change Initiative

ADKAR includes a sobering truth: not all changes should continue. If you have invested in awareness, addressed concerns, provided training, and coached extensively, yet the change still fails, it may be time to stop or redesign. Use these red flags to trigger a stop decision:

• Awareness: After three weeks of communication, less than 50% of the target population can state why the change is needed.
• Desire: After two weeks of engagement efforts, active resistance persists and key influencers refuse to participate.
• Knowledge: After two rounds of training, assessment scores remain below 60%.
• Ability: After one month of the pilot, performance is no better than baseline and team members report high frustration.
• Reinforcement: Three months after rollout, process adherence has fallen below 50% and backsliding is widespread.

If two or more red flags occur at the same stage gate, the sponsor should convene a stop review. The decision to stop is not a failure of the team; it is a rational response to evidence. Document the reasons, capture lessons learned, and either revert to the old process or redesign the change with a smaller scope.

Comparison with Alternative Approaches

ADKAR is one of many change models. Here is how it stacks up against common alternatives for technology teams.

Kotter's 8-Step Model: Organizational and phase-based, ideal for large-scale transformations with a clear vision. ADKAR is individual and diagnostic. Use Kotter to plan the overall change program and ADKAR to coach individuals through their personal transitions.

Prosci 3-Phase Process: A project management framework for change, with phases like Prepare, Manage, and Sustain. ADKAR is the individual model embedded within it. If you need a complete methodology with tools and deliverables, use Prosci 3-Phase. If you need a quick diagnosis, use ADKAR.

Lewin's Change Model (Unfreeze-Change-Refreeze): A high-level three-stage model. It is less prescriptive than ADKAR and does not separate Knowledge from Ability. Use Lewin for conceptual understanding and ADKAR for tactical execution.

McKinsey 7-S Model: A diagnostic tool for organizational alignment, not for individual change. Use 7-S to assess whether strategy, structure, systems, skills, staff, style, and shared values are aligned. Use ADKAR to address the people side of a specific change.

Situational Leadership: Focuses on leadership style adjustment based on follower readiness. It complements ADKAR by helping managers decide how much direction and support to give each person at each stage.

Choose ADKAR when you have a defined change, a known solution, and resistance rooted in individual behavior. Choose other tools when the problem is structural, strategic, or ambiguous.

Conclusion

The ADKAR model gives technology leaders a practical, individual-focused framework for managing change. By assessing Awareness, Desire, Knowledge, Ability, and Reinforcement, you can diagnose why a change is stalling and take targeted action. Remember that ADKAR is not a one-size-fits-all solution. Use it when the primary challenge is human adoption of a known solution; for ambiguous problems, use discovery methods, and for process improvement with root causes, consider DMAIC or PDCA.

Start with a narrow pilot, measure both success and guardrail metrics, and establish clear decision rights. Use the checklists in this article to conduct regular governance reviews. By applying ADKAR with discipline, you can reduce rework, improve team alignment, and achieve lasting change in your technology organization.

Next steps: identify a change initiative that is currently struggling, assess the ADKAR status of key individuals, and plan your first intervention. Then, schedule a review to evaluate progress and decide whether to continue, modify, or stop.