Restarting a Failed $5M GTM Transformation as an IC Architect
How a client-centric GTM transformation got rebuilt from a stalled discovery — and what it took to land it as an individual contributor.
The transformation shape
The work was not scoped by one vertical. The value appeared through capability-led architecture across GTM seams.
The starting point
In October 2023, a $5M Salesforce reimplementation had just failed. I asked for the chance to restart it. Eighteen months later it had changed how the company sells, and I had been promoted to Technical Fellow and rated "Transformational" for two consecutive cycles.
This is the story of how that happened, and why it mattered that I never held a title that gave me authority over any of it.
The company was built like a startup and ran like one. The commercial architecture was operational-centric — organized around how the business processed work internally, not around the client. That was fine at one scale and a liability at the next. The fix was a client-centric model, and everyone agreed on the destination. Nobody had been able to get there.
A large consulting partner had run a discovery to reimplement the CRM. It produced $5M of artifacts and no path forward. Around the same time, I had pitched an MDM idea that got handed to another director and stalled. Two attempts at the same underlying problem, both dead.
I asked my manager for a third shot.
Asking for a third shot
The opening was thin. She mentioned a consultant being brought in to review the prior discovery outputs and repackage them. I asked to be looped in. Within three weeks I had run my own discovery with sales ops and built a working proof of concept — with a consultant, a program manager, and a technical product manager. The PM and I split the product work: they handled technical product management, I led the strategy and process, holding the current and future state end-to-end in one mental model.
The move that mattered was not the proof of concept. It was the reframe. The $5M discovery had defined the work as a CRM reimplementation; it was not — it was a client-centric commercial architecture gap, and naming it correctly was what made a path forward visible at all.
Some of my boss’s directs were not rooting for this. A few were hoping it would fail. That is worth saying plainly, because it shaped every senior conversation that followed: I walked into most of them at a disadvantage and had to flip it inside the first few minutes.
The quiet go-ahead
The company went through major layoffs around this time. In the aftermath, my boss gave me the green light — quietly.
In three or four days I had put together the full value proposition, rollout strategy, roadmap, and cost estimate.
I chose against a big-bang rollout. Instead I designed a phased approach and deliberately kicked off Phase 2 before Phase 1 closed, so the phases de-risked each other rather than stacking risk. Funding was approved almost immediately — the impact case was clear and there was surplus to deploy.
Getting the room
The mindset shift was the hard part, not the architecture. I designed the persuasion deck — the slides whose only job was to flip the frame from operational to client-centric. Then I met leaders individually and tailored the case to their org.
This was not communication dressed up as strategy; it was the strategy — building the executive narrative before scaling the solution, so the organization aligned around the right problem before anyone funded the wrong one.
My boss asked me to present directly to the senior leadership team. That is where the cross-altitude thing mattered: I could hold the same idea at the SLT level and at the developer level in the same week, and connect to both the strategy and the people in the room.
It made decisions faster — fewer translation layers between strategy and execution — but it also concentrated the risk: one person carrying both ends means one person who has to be right, alone. My boss used to tell me I was at least six months ahead of where others were thinking, and to be patient with the daily grind that came with it.
The decision was made to lead Phase 1 outside the traditional product structure. Product and delivery were deemed too slow for transformation work, and the directs who would normally have owned it were, candidly, blindsided. My boss provided the cover. I led Phase 1 with a program manager and a handful of engineers.
Building through friction
I wrote the Phase 1 scope, roadmap, and stream breakdown in about a day, with limited legacy context to lean on.
In parallel I designed the target-state enterprise architecture, the CRM dual-run strategy, the migration plan, and the Phase 2 architecture.
The pushback was constant and came from every direction: engineering leads protecting ownership and control, architecture wanting more rigidity, and even my boss preferring detailed user stories over the ambiguity I was asking teams to operate inside. The teams were not comfortable with that ambiguity. It took two to three months to shift the culture enough that we could move.
The Technical Fellow promotion came through during this stretch — mid-program, before either crisis hit. It was the company’s way of signaling the bet was working, and it gave me the air cover I needed for what came next.
Two moments are the real story.
Crisis one: the agency data nobody owned
To enable book management at scale, I shipped a critical capability outside Salesforce — essential for business continuity, and not something the CRM was going to do well. Meanwhile a core team I did not control sat on minor legacy changes for six-plus months.
Data migration had started but lacked strategic data skills and clear ownership. Once development stabilized, I pivoted and took the data transformation myself. I spent nights and weekends cleaning millions of records so commissions and sales workflows would not break at cutover.
Then I hit the agency data. It had no owner, and a relationship-centric model is impossible without it. The business wanted to skip it. I refused. There was no one else in the building who could reconstruct it in the time we had, and the layoffs had cut off the usual escalation paths. So I built the mastering logic across five sources, aligned the stakeholders, and cleaned the data in two weeks.
That was not grunt work and it was not heroics. It was the only available way to figure out what the truth actually was before go-live. Reverse-engineering process truth from data lineage is the thing I have been doing for 28 years. This is where it paid for the whole program.
Crisis two: the Phase 2 migration recovery
Phase 2 migration was a six-month, ten-team effort that had stalled. Morale was collapsing. The conflict had gotten personal — name-calling, at one point close to a fistfight. Multiple directors and a VP had visibility, and none would own the recovery. The professional services partner had backed away too.
I volunteered to spend two weeks helping. I came in with a rearchitected migration strategy I believed was doable with the right mindset. Within a week the situation had clarified enough that the original migration lead was reassigned.
We rebuilt the core migration and reconciliation logic, rolled out in three phases inside a month, and went live on the original date with no business disruption.
The risk of doing nothing was higher than the risk of acting, for the whole team. So I did what was needed.
Outcomes
- Helped establish a client-centric GTM foundation tied to significant in annual revenue opportunity.
- The company moved from an operational-centric to a client-centric commercial architecture — the destination two prior attempts had failed to reach.
- Both data crises were resolved without slipping the date and without disrupting commissions, sales workflows, or the business.
- Promoted to Technical Fellow during the program and rated "Transformational" for two consecutive cycles.
What I take from it
I did not have a title that gave me power. Every senior conversation started at a disadvantage, and I had to convert doubt into trust in real time — through diagnosis, clarity, and delivery, not authority.
Authority earned in real time turned out to be more durable than the kind that comes with a title.
The reason an IC was trusted with this scope is rare and worth naming: my manager saw something before I had proven it, cut through the org structure, and put me in front of the C-suite to make the case myself. I had not delivered anything strategic for her before this. She took the chance anyway.
Most transformations of this kind do not get an architect who can operate across every altitude at once. Mine got the chance because one leader bet on it.
The six levers behind this transformation are captured in the companion playbook: The IC Architect’s Transformation Playbook.
Reader Takeaway
This is a case study in how architecture becomes a leadership instrument when an organization is stuck between strategy and execution.
The lesson is not that every transformation needs an architect to become the hero. The lesson is that enterprise transformation often fails when no one can connect business truth, system truth, data truth, and delivery truth at the same time.
That connective role is where architectural authority becomes real.
The same pattern shows up now in AI-native product work — different surface, same connective role.