Skytree Case Study: Restarting a Failed $5M 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.
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 — something that, to my knowledge, had not happened to anyone after a promotion.
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 starting point
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.
The re-entry
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, reframed the problem as a client-centric process rather than a tooling reimplementation, and built a working proof of concept. I did it with a consultant and a program manager — the assigned product manager wasn't effective, so I stepped into that gap too.
Some of my boss's directs were not rooting for this. A few were hoping it would fail. That's 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 built the full value proposition, the rollout strategy, the roadmap, and a 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 built what we internally called the "money shot" slides — the ones whose only job was to move people from an operational frame to a client-centric one. Then I met leaders individually and tailored the case to their org. My boss asked me to present directly to the senior leadership team. That's 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.
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 built the target-state enterprise architecture, the CRM dual-run strategy, the migration design, 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 weren't comfortable with that ambiguity. It took two to three months to shift the culture enough that we could move.
Two moments are the real story.
Crisis one: the agency data nobody owned
To enable book management at scale, I built a critical capability outside Salesforce — essential for business continuity, and not something the CRM was going to do well. Meanwhile a core team I didn't 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 wouldn't 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 wasn't grunt work and it wasn't 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've 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
- 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.
- I was promoted to Technical Fellow during the program and rated "Transformational" for two consecutive cycles.
What I take from it
I didn't 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. That turned out to be more durable than the formal kind.
The reason an IC was trusted with this scope is rare and worth naming: my manager saw something before I'd proven it, cut through the org structure, and put me in front of the C-suite to make the case myself. I hadn't delivered anything strategic for her before this. She took the chance anyway. Most transformations of this kind don't get an architect who can operate across every altitude at once. Mine got the chance because one leader bet on it.
The six levers I used to run it are in the companion piece: How an IC Architect Runs an Enterprise Transformation When Traditional Product and Program Leadership Can't.
Reader Takeaway
Skytree was not only a technology delivery story. It was a case study in how architecture can become 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.