Assessing Organizational Change Readiness: Can the Team Actually Adopt What You Are Proposing?

Solution Engineers are trained to ask whether a solution will work. Fewer ask whether the customer’s team can actually adopt it. A team already running at full capacity, a team that has lived through a failed rollout, or a team that sees automation as a threat to their role will struggle with even the best design. When the SE does not assess this, the deal may close and then stall in implementation, or the evaluation may quietly lose momentum for reasons nobody says out loud.

This article covers an atomic discovery skill from the SE Ignite catalog: gauging whether the customer’s engineering team has the bandwidth and appetite to adopt new workflows.

The problem this solves

• Problem: readiness is assumed. The proposal and evaluation plan ignore the team’s capacity and attitude, so timelines slip, adoption is low, and the customer blames the product.
• Reader: Solution Engineers and presales leads shaping proposals, evaluation plans and rollout recommendations.
• Stage: discovery and qualification, revisited before the evaluation plan and the implementation handoff.
• Decision it supports: how ambitious the scope and timeline should be, what enablement to include, and whether the opportunity is really ready.
• Success test: you can describe the team’s capacity, its appetite for change and the main adoption risks, and your plan addresses each one.

Two dimensions: bandwidth and appetite

Bandwidth is whether the team has time. Look for competing projects, open roles, on-call load and planned freezes. Appetite is whether the team wants the change. Look for past experience with new tools, perceived threat to roles, and whether the change was requested by the team or imposed on it. A team can have one without the other, and each needs a different response.

Questions that reveal readiness

1. “What else is the team delivering over the next two quarters?” This shows competing priorities.
2. “Who would run the evaluation day to day, and what would they stop doing to make room?” If nobody can name it, bandwidth is a risk.
3. “How did the last tool rollout go?” Past adoption is the best predictor. See diagnosing failed prior initiatives.
4. “Whose idea was this project?” A change requested by the team has a different appetite from one handed down by leadership.
5. “What would make this change harder for the people doing the work?” Asking directly gives permission to raise concerns.

Using the answers

• Low bandwidth, high appetite: reduce the evaluation to the minimum viable steps, offer more hands-on help, and phase the rollout.
• High bandwidth, low appetite: involve sceptics early, show how the change reduces their toil, and use their language. Champions from the team matter more than executive pressure.
• Low on both: raise it honestly with your account team. The opportunity may need a later start date or a different first use case.
• High on both: move with confidence, and record this in the handoff so post-sales can keep the momentum.

Adapting it to the situation

• Frontline users who fear automation: appetite is the key risk. Show how routine work shrinks and skilled work stays with them.
• A prospect burned by unused software: they will ask for proof of adoption. Build adoption measures into the success criteria, not only technical ones.
• A merger or acquisition: teams are often absorbing many changes at once. Ask where your change sits in their priority list.
• A rapid-growth assessment: bandwidth is usually consumed by firefighting. A first phase that removes toil can create the capacity for the rest.
• A multi-region rollout: readiness varies by region. Choose the most ready region for the first phase.

Common mistakes

• Asking only the sponsor. Executives tend to overestimate team capacity. Ask the people who will do the work.
• Treating resistance as an objection to overcome. It is information about risk. Use it to shape the plan.
• Leaving readiness out of the handoff. Post-sales teams need to know what you learned.

Where this skill sits

Readiness connects discovery with execution. It shapes the mutual action plan, informs the success criteria, and gives context to the technical debt the team is already carrying.

Practising the 80%

Assessing whether people can absorb a change is vendor-neutral. It is part of the 80% of Solution Engineering that SE Ignite teaches. Practise the five questions with a simulated stakeholder who is supportive in public and cautious in private. The SE Ignite curriculum is free to use.