Practice Areas
Structural change looks different in every organization, but the work of getting ahead of it doesn't.
One discipline, applied across three practice areas. The method is the same in each: diagnose the current state with evidence, define what good looks like, build what's needed, measure the outcome, and iterate. Right now the change on most leaders' desks is AI, and that's where most engagements begin - but the practice areas apply to any technology-driven change, in any industry: corporate, professional services, education, nonprofit. The goal in every case is the same: an organization that meets change with confidence instead of dread.
Readiness and Strategy
Readiness assessments are everywhere right now, and most of them tell you what you want to hear. Mine won't - which is exactly what makes the good news in them worth believing.
A readiness engagement answers three questions in plain language: what problems in your operation are actually worth pointing new technology at, what your organization can absorb today versus after deliberate preparation, and what sequence of moves gets you value without betting the company on a pilot. You get a written assessment and a prioritized roadmap - specific enough to act on Monday, honest enough to include the options I'd advise against and why.
Acquisition support - both sides of the table.
Strategy usually ends in buying something: a platform, a tool, an implementation partner. Buying is also where organizations new to a technology get hurt, because the vendors have run this play hundreds of times and you may be running it for the first time.
I've spent years on both sides of the RFP process - writing and running procurements as the buyer, and answering them for a living on the agency side - so I know how vendors read your RFP and where the weak points in a polished proposal hide. I help organizations author RFPs that attract the right bidders and make honest comparison possible, and I help evaluate the replies with structured criteria instead of demo-day impressions. Because I sell no technology and take nothing from vendors, I sit on exactly one side of the table: yours.
What to expect: a fixed-scope engagement of several weeks, delivered as a working document, not a slide ritual. Acquisition support is scoped to the procurement's timeline.
Adoption and Change Leadership
The open secret about technology initiatives is that most stall for organizational reasons - unclear ownership, unprepared staff, workflows redesigned on paper but not in practice. The technology usually works. The adoption doesn't. The encouraging corollary: adoption is a solvable problem, and solving it is where the excitement becomes real for the people doing the work.
This is the problem I've spent the largest part of my career solving. I've led technology adoption across teams of hundreds of instructional staff and programs serving more than 20,000 users, through growth, acquisition integration, and a pandemic that doubled demand overnight. The method is the same at any scale: identify who has to change what they do, understand what that change costs them, and build the support, communication, and measurement that carries them across.
I don't sell a branded change framework. I build change plans on the intervention logic and measurement instruments that independent research has validated, matched to your organization rather than to a vendor's license.
What to expect: a change strategy and measurement plan, with optional ongoing counsel through the rollout.
Evidence and Evaluation
Before you scale anything, you should be able to answer one question: how will we know it worked? Most organizations can't, and it costs them - pilots become permanent by inertia, and failures are discovered only after they're expensive. Evidence is also what sustains enthusiasm: teams stay excited about change when they can see it working.
I design the evidence layer: pilots with pre-defined success criteria, honest go/no-go decision points, structured vendor-proposal evaluation, and longitudinal measurement built from independently validated, openly published instruments rather than proprietary vendor benchmarks. This is infrastructure I've built from scratch - at Johns Hopkins CTY there was no systematic measurement of program quality when I arrived, so I built the surveys, the performance data, and the feedback loop that decisions ran on afterward.
The result is not just a verdict on one project. It's a durable capability your organization keeps.
What to expect: evaluation design as a fixed-scope project; measurement architecture as a longer build.
For organizations that want continuity beyond a project, ongoing fractional advisory arrangements are available.