Technology Adoption & Change Strategy
You Can’t Change Technology Without Changing the People Who Use It
18+ years of enterprise commerce transformations, and the org change that comes with each one.
A replatform changes what your team does every day. Maintenance work disappears, roles shift, workflows get rebuilt, and someone has to decide what that means for the people doing them. We treat that as part of the project, because a technically flawless build that nobody adopts is still a failed project.
Transformations rarely fail on the technology
A modernization project is both a response to technology problems deferred for years and a catalyst for organizational change. The second part gets planned for far less often than the first.
Organizational risk
Buy-in is assumed rather than earned
Leadership wants to know whether the new platform can meet the business’s needs. Engineering wants to know what happens to their role. Grove Collaborative’s first phase existed to answer exactly that question; Follett went from kickoff to a live campus store in under three sprints.
The org chart doesn’t describe how the work happens
Planning a change against the chart rather than against reality means the gaps you find are the wrong gaps. Finding out what people actually do takes functional interviews, and there’s no shortcut.
Role impact goes unaddressed until it’s obvious
When a replatform cuts maintenance time, the follow-on question is whether you need the same engineering capacity. We put that question in the analysis rather than in a footnote.
Change management treated as an afterthought
It gets scoped last, resourced least, and started once the build is underway. We scope it with the technical work, at the same time, in the same statement of work.
What that produces
New system, old workflows
The most common outcome of an unplanned change is a team that keeps the spreadsheet — usually because nobody showed them the new path.
Under-resourced training
A tool at partial adoption is often worse than no tool, because the team maintains a parallel manual process and the organization pays for both.
Institutional knowledge walking out
The people who understand why your systems work the way they do are the same people most unsettled by a transformation.
Benefits that quietly don’t arrive
When adoption is partial, the efficiency gains that were the business case are partial too — and because nobody measured the baseline, it’s hard to say by how much.
Experience
18+
Years of Unlocking Growth
Scale
$3.14B+
in GMV Migrated to Shopify
Partnership
1 of 5
Founding NA Shopify Platinum Partners
Precision
94.7%
Implementation Predictability
Clients
8
Unicorns & Counting
Every one of those migrations changed how a team worked. That part was scoped, too.
Five things we’ve concluded about technology change
These come from Eighteen years of transformations, including the ones where we learned this the hard way.
Technology change is business change
Every transformation produces ripple effects through roles, workflows, and reporting, whether or not anyone planned for them. The projects that go badly aren’t the ones with the most change — they’re the ones where the change wasn’t anticipated.
We’ll tell you who and what to keep, and who and what to move on from
Across people, systems, and teams, some of what you have will carry you into the next phase and some won’t. We’ll tell you which senior people are worth investing in retaining, which roles need to change shape, and which systems and vendors should not survive the project. The aim is to set you up for the next three years, not to get you through the next three months.
The people affected should hear it first, and from you
On Follett, an agile working rhythm was established across three organizations — Anatta, Follett, and Shopify leadership — on a single cadence, which is what made a 1,200-store program legible to everyone accountable for it.
Adoption is measurable, and measuring it changes the conversation
Capturing a baseline before launch is what makes adoption signals mean anything afterward — without it, “adoption is going well” is a feeling.
A generic playbook isn’t a change plan
What makes a change plan work is the specific detail: this team’s workflows, this person’s actual responsibilities, this platform’s real learning curve. We publish our framework further down this page precisely because the framework isn’t the valuable part.
The work
Organizational mapping
Functional interviews across the affected teams to establish who does what and how they do it — including the responsibilities that aren’t on anyone’s job description.
Change impact assessment
A view of the size and volume of change the transformation will create, by team and by role.
Gap analysis and governance model
Each gap comes with a specific recommendation: retrain, reallocate, hire, partner, or replace — including which people, roles, or vendors don’t carry into the next phase.
Buy-in and business case support
Business requirements documentation and solution vision decks, plus functional proofs of concept on the concerns your stakeholders can’t get past.
Communication planning
An internal communication timeline agreed before kickoff, with the sequencing and material your leadership needs for all-hands and standups.
Enablement and adoption measurement
Documentation and live demo sessions for each affected team, an adoption baseline captured before launch, and the signals tracked afterward.
What a change engagement commits to
| Commitment | Acceptance criterion |
|---|---|
| Organizational map | Built from functional interviews, validated by the people interviewed |
| Change impact | Named per team and per role, before kickoff |
| Role gaps | Each one carries a specific recommendation, not a list of options |
| Hard findings | If a role reduces, a team is misplaced, or a vendor shouldn’t continue, it’s in the analysis and stated plainly |
| Communication timeline | Agreed and dated before the project starts |
| Enablement | Documentation plus live sessions for every affected team |
| Adoption baseline | Captured pre-launch, so post-launch signals are interpretable |
| Post-launch support | Continues past go-live, with adoption reviewed rather than assumed |
The fourth row is the uncomfortable one, and the reason the rest hold.
How change work runs alongside a build
Organizational discovery
Weeks 1–2, with technical discovery
Functional interviews, current-state map, stakeholder identification.
Impact and gap analysis
Weeks 2–4
Change volume by team, role gap analysis, target structure, governance model, retain-and-release list.
Buy-in and communication
Before kickoff, then continuous
BRDs, solution vision, functional POC, communication timeline agreed and executed.
Enablement
Pre-launch through post-launch
Documentation, demo sessions per team, adoption baseline captured.
Adoption review
30, 60, 90 days post-launch
Signals measured against baseline, gaps addressed while they’re still cheap to address.
Timelines: The scale of this work is proportional to the scale of the change. A theme upgrade doesn’t need an org impact analysis. A replatform that eliminates a maintenance workload does.
Where this comes up
Replatforming
The largest change event in commerce, and the one where role impact is most predictable. → System Replatform
ERP or back-office change
Affects finance, operations, and CX simultaneously, often teams that weren’t in the technology conversation at all. → Integrations
Subscription platform migration
Migrating the contracts is the technical problem; migrating the operating habits is the other one. → Subscription & Retention Experiences
Bringing work in-house, or moving it out
Both directions change roles fundamentally, and both are frequently framed as procurement decisions rather than organizational ones.
New capability launches
B2B, retail, international, or a new fulfillment model each create responsibilities nobody currently owns. → Omnichannel Commerce · Market Expansion
Stack consolidation
Retiring an application means changing a workflow somebody depends on. → Technology Stack
Anatta’s Agentic Operating System
Every engagement runs on one system.
Senior architects paired with an agentic framework that absorbs the commodity execution, which on this work means the documentation, the enablement material, and the reporting — so the time goes to the conversations that need a person in the room.
See how we workTransformations we’ve run
Follett
1,200+ campus stores, and an agile cadence built across three organizations to de-risk the decision in stages
Explore the Follett success storyGrove Collaborative
A two-month discovery and a two-sprint proof of concept answered “can Shopify meet enterprise needs” before anyone committed
Explore the Grove Collaborative success storybuybuy Baby
A $1.5B retailer relaunched and four stores reopened in 31 days, after 130+ closures and a site gone dark
Explore the buybuy Baby success storyGood Ranchers
A stack simplification that put campaigns and promotions back on marketing’s clock rather than engineering’s
Explore the Good Ranchers success storyWe wanted the agility to scale resources as needed, and a team of experts giving us recommendations and advice on UX and technology rather than something restrictive or purely execution-focused.
Maranda LujajohnsonDirector of Special Projects, Thesis
Anatta addressed all of our challenges in a practical way.
Chris ClarkCo-Founder & CDO, Grove Collaborative
How to plan your own change strategy
This is the structure we work from. It’s foundational rather than complete.
- Clarify your current organizational structure. Not the chart — who does what, and how.
- Understand the level of change coming. A 360° view of size and volume, by team.
- Identify gaps in roles and responsibilities. For each gap: retrain, reallocate, hire, partner, or replace.
- Write the second list. What and who doesn’t carry forward — the list most organizations avoid writing.
- Secure stakeholder alignment before anything else. Buy-in comes from evidence of wins, communicated consistently.
- Set the communication timeline before kickoff. Who hears what, when, and from whom.
- Resource the training properly. Budget it as scope.
- Capture an adoption baseline. Measure before launch, not just after.
- Review adoption on a schedule. 30, 60, 90 days.
The Change Impact Framework
The worksheet version, with the interview prompts and the gap-analysis structure built in. Name and email.
Frequently asked questions
Isn’t change management HR’s job?
HR generally owns the process. What a technical partner contributes is knowledge of what specifically changes — which workflows break, which skills stop being needed, and how steep the learning curve on the new platform actually is.
Can’t we just train people after launch?
You can, and it’s the most common approach. Between launch and training your team runs the new system on old assumptions and builds workarounds that then have to be unwound. Earlier is cheaper.
What if the analysis shows some roles get eliminated?
Then that’s in the analysis, stated plainly, along with the alternatives — reallocation or retraining. Your senior people will reach the conclusion on their own, and the version they construct in the absence of information is usually worse than the truth.
Will you tell us who and what we should move on from?
Yes, if you want that. The gap analysis names which capabilities carry into the next phase and which don’t — people, teams, systems, and vendors alike. The decisions stay yours.
How do you measure adoption?
Against a baseline captured before launch, using signals like whether the old process is still running in parallel and how many requests go to engineering that shouldn’t need to.
Can our internal team run this?
Often, yes — and the framework on this page is the one we use. Internal teams already know the people; we add pattern recognition from many similar transformations.
When should this start?
Before the technical project kicks off, because the communication timeline needs to be set before anyone forms an impression from incomplete information.
Tell us what your team is worried about.
