The code gets replaced. The frameworks get deprecated. Relationships compound.
The technology is almost never the problem.
We spend a lot of time debating stacks and architecture. But the actual success or failure of an enterprise implementation usually comes down to something far more human.
I joined Guidewire when the company was still finding its footing. In those early days, every project felt existential. A major failure wasn’t just a setback; it could have taken the entire company down. That pressure shaped my whole approach to delivery.
By the time I left thirteen years later, I’d led implementations at some of the largest P&C carriers in North America. After watching eight-figure projects both succeed and fall apart, I arrived at a conclusion that surprised even me: the patterns that determine outcomes have almost nothing to do with the software itself.
Here’s what those years actually taught me.
1. A reckless promise is sometimes just vision
Early on, when the product was immature and every client felt like a survival bet, we hit a wall. The software had a gap; no framework for extracting a customer’s entity model. My boss had mentioned a potential solution to the client. Suddenly, they wanted it by a non-negotiable deadline.
Five of us rallied. We worked in shifts on four hours of sleep. By the deadline, we had something barely functional.
That framework was eventually absorbed into Guidewire’s core product, where it cut implementation costs by an order of magnitude and accelerated projects for years. The lesson wasn’t about working weekends. It was about what that commitment communicated to the client. In enterprise delivery, proving you’ll move mountains for their success is often more decisive than any technical milestone.
2. Ownership has no job description
I watched two versions of the same failure repeat themselves throughout my career.
The first: someone technically capable but contractually minded, arguing every requirement as if the customer were an adversary. They protect their “scope” so fiercely they lose sight of what that scope was supposed to achieve.
The second: someone deeply skilled but aimed at the wrong target. They disappear into technically interesting work nobody asked for while the actual deliverable sits unfinished. Busy being brilliant in private while the project bleeds in public.
When a deadline looms and you see these patterns, you don’t wait for a course-correct conversation. You cover the gap yourself and sort out ownership later. Talent without focus isn’t just wasted; it’s dangerous.
3. If they tell you it can’t be done, build it
Customer code quality was a persistent problem on Guidewire implementations. Poor customer code caused cascading bugs and unpredictable integrations. Our quality checks were manual and subjective and usually missed some glaring issues, so I proposed using IntelliJ’s inspection framework to automate the process.
The product team said it wasn’t feasible.
So I found out for myself.
For six months, I worked at customer sites all day and spent my nights in hotel rooms hacking away at the framework. 16 hours a day, for six months, weekends included. Documentation was almost nonexistent and I had to go directly to the IntelliJ team for answers. After enough failures and hotel-room meals, I had something working.
I demoed it to the product team and they adopted it on the spot. Twelve years later, it’s still in the core product helping customers in numerous ways that I had not envisioned.
When an organization says something is “impossible,” they usually mean they haven’t prioritized it. Know the difference.
4. Move forward one step at a time
Someone asked how I sustained energy through those six months of hotel-room nights or the sleepless sprints early in my career. The honest answer: I never looked at the full distance.
Enterprise implementations are massive. The gap between start and finish can feel paralyzing if you take it in all at once. The people I watched struggle most were the ones who froze in front of the scope, or refused to start until every detail was perfectly clear. Neither posture gets anything done.
I finished that thirteen-year career the same way I finished that framework. One inspection at a time. One deliverable at a time. One solved problem at a time.
5. The real deliverable is the people
I left Guidewire 7 years ago. The frameworks I built have been refactored. The products have been redesigned. The code I wrote has almost certainly been replaced.
None of that is what stayed with me.
What stayed are the people. The five of us from that first sleepless sprint. The architects who flew into crisis situations to figure things out alongside me. These aren’t just memories; they’re active professional relationships. I hired one of them into Akur8. I started a company with two others.
The only foundation that actually holds in this industry is going through hard things together and coming out the other side knowing exactly what the people around you are made of.