ISCS

Vice President, Professional Services (2008 to 2010)

When I first sat down with the company’s founder, who had built ISCS and run it for more than a decade, he was tired. He had a good software suite for property and casualty insurers and customers who stayed, but the company could not take on new customers fast enough to grow, so every plan he made ran into the same ceiling. He could not see past that trajectory, a flat line with a little growth on top, and he had an offer to sell that he thought was low. He was close to taking it. I told him I believed I could get growth going. That belief is what I put on a single slide before they hired me, where the goal I wrote in plain language was significant growth toward an acquisition or an IPO.

I had diagnosed the bottleneck from the outside, and the product was not the problem. The part of the business that turned a signed customer into a live one could absorb only one or two new implementations a year, and nobody could say with confidence why. That delivery engine was quietly capping the whole company’s growth, and fixing it, in my first executive role, was the job. ISCS had been around since 1994, ran a platform called SurePower Innovation, and sold mostly to carriers under a billion dollars in premium from a headquarters in San Jose and a small second office in Missoula, Montana. Roughly forty people, fourteen customers, a good company on a flat line. My job was to change the slope.

Measure it before you manage it

I came out of eight years at Accenture, and the most useful thing I brought with me was not a methodology, it was a reflex: do not trust a story you cannot see in the data. Even before I accepted the role, my diligence notes were full of questions like what are the current revenues and what are the cash reserves. So the first thing I did was not reorganize anyone. It was instrument the place.

When I arrived, the services team had almost no visibility into its own work. We could not reliably say what was in flight, how far along it was, or whether a given piece of work had even been approved in a way that let us recover its cost. There were monthly write-offs that came down to confusion between our project teams and our customers about what was billable. We had a person whose actual job was walking around asking people what they were working on. So I went and made the work visible, because nearly every problem I found was hiding behind a lack of measurement rather than a lack of effort or talent.

Changing the slope

The clearest proof is the chargeability line. The week I started, the team was billing about thirty-eight percent of its hours. Four months later it was in the high seventies, peaking at eighty-one. In four months we had nearly doubled how much of the team’s time went to paid customer work, and it happened because for the first time people could see where the time was going. It did not stay at that peak, but the team never went back to working the old way.

Everything downstream moved with it. The team that had historically managed about one customer implementation at a time was running four or more in parallel, and across 2009 it completed more than fifty projects in a year that also cleared a large backlog and stood up brand-new processes at the same time. Throughput did not come at quality’s expense, which is the trade I had braced for: across our customer implementations, the open-defect backlog fell from more than three hundred in early 2009 to around fifty by the end of the year.

Then there was the revenue, which is the number I was hired to move. Services had not been a cost center; the team was already doing billable work, including a meaningful amount of project work that came in disguised as support, but it did so informally, with no consistent way to scope it, capture it, or charge for it. By formalizing how we estimated and billed, and by going from one implementation at a time to several at once, we nearly doubled services revenue off that small base. The cleanest way to see it is to compare the same quarter a year apart: the first quarter of 2010 brought in roughly twice what the first quarter of 2009 had. Margins climbed with it, project work from the high teens to the mid twenties and support, the recurring side, into the high fifties. Growth that arrives at a worse margin is not growth, it is just more work. I had been hired to turn a constraint into an engine, and that is what the numbers say happened. The system made the work visible. The team did the harder part, changing how it estimated, logged, reviewed, and delivered while clearing a backlog at the same time.

The growth did something the metrics do not capture. The founder had been ready to sell a tired company. By the time the growth was undeniable, he told me the work had become fun again, and that he was no longer in a hurry to sell. Bending the trajectory had given him his company back.

Giving the business a nervous system

The instrumentation was not a dashboard I bought. It was an operating system I assembled out of cloud tools so that I would not need an IT department to run it, because I wanted to spend my attention running the business, not the servers. I put Salesforce at the front door for both sales and support, OpenAir in the middle as the professional-services automation engine where every project carried a budget in both dollars and hours, and Intuit QuickBooks at the back as the system of record for invoicing. Then I wired them together so a customer’s life flowed through them automatically.

Every new implementation started as an opportunity in Salesforce, became a project in OpenAir, and ended up as an invoice in QuickBooks. I added a piece I cared about, a bottom-up estimating habit where the people doing the work logged not just their hours but their own estimate of the effort remaining on each task, which gave us a live, honest burn-down that both we and the customer could see. The change that moved the economics most was on the support side. A lot of what came in as a support ticket was really billable project work wearing a disguise. So I made support cases flow into OpenAir as tasks. When a “support” request was actually new work, the system caught it, charged for it, and put the case number right on the invoice, so the customer could see exactly what they were paying for. For the first time we could see profitability by account and by maintenance agreement, not just in aggregate.

The system’s sharpest test was an escalation. The CIO of one of our longest-standing customers was unhappy, and I took the call while looking at a dashboard that showed his account running at a negative margin for us. I made a deliberate bet rather than getting defensive. I asked him a question: how much profit do you think is fair for us to make on the work we do for your team? We talked it through, agreed that for a software services relationship something like twenty-five percent was reasonable, and then I told him the truth, that we were well underwater on his account, and offered to send him the reports. Putting our own cost structure on the table was a calculated risk, and it was mine to take, because I owned that P&L. It paid off. Once the numbers were in front of us, I could show him that he was over-investing in an older version of our platform and would be better served moving to the current one, and he agreed. The disclosure that could have ended the relationship deepened it instead. That is the whole thesis of the financial work in one conversation: when everyone can see the same numbers, you stop negotiating and start deciding.

The turn away from waterfall

This is also the chapter where I changed my mind about how software should be delivered. At Accenture I had been trained inside the waterfall world, the V-model, big up-front requirements, catch every defect before you ship. ISCS is where I set that down. I got certified as a Scrum Master, then made the case to spend real money bringing in the coach who had certified me, for both the R&D organization and my own professional-services teams, and we rebuilt our implementations around short iterations with real customer reviews along the way instead of one long march to a distant go-live.

The coach was not what anyone expected. He was a rock-and-roll agile guy with blue hair and tattoos, and I could read on my team’s faces the day he walked in that they thought I had lost my mind. Then he started talking, and he had the room. Within a session everyone was engaged, and we were on our way. I thought about that a lot afterward, because the resistance I had braced for never really came. My team turned out to be genuinely curious about learning a new way to work, and our customers came along because the instrumentation gave them something they had never had before: they could see the work as it happened, so they had reason to trust a process that asked them to review it in pieces. I hired that coach again years later at Elastic Path.

The insight I kept coming back to was that a services business cannot ask a customer to hold their breath for a year. So we structured work to show value inside a single thirty-day sprint and to avoid committing to anything that could not prove itself within a quarter and pay for itself within a year. That cadence de-risked delivery for the customer, and it let us bill sooner and free up people faster than the old model ever had. The instinct to test against reality early rather than trust a plan came from my Accenture years, but ISCS is where I learned that agile was the better way to honor it.

Building the team and the bench

It was my first time as the executive, and I inherited a team with almost no scaffolding: no clear titles, levels, or sense of how to get better and earn more. So I borrowed the parts of Accenture’s people system I had genuinely valued and built a version sized for us: a five-level career framework, a small set of competencies everyone was measured against at every level, an honest annual review, and a bonus tied to the company actually succeeding rather than to individual effort alone. For a roughly two-dozen-person team split across two offices, it gave people a map of where they stood and where they could go.

Capacity was the other constraint, and I did not want to solve it only by hiring ahead of demand and carrying the cost on my own bench. So I built a partner program and ran the playbook I had watched work at Accenture, where the right system integrators alongside a software company let it sell faster than it could ever staff. My anchor partner was a global integrator, but deliberately not the largest one in the room, and the reason is the actual lesson. They had a small property-and-casualty practice in the United States that they were trying to grow, so a tiny software company in San Jose was exactly the foothold they wanted. Their ambition and mine were aligned, which is worth more than size. I rounded that out with a couple of boutique firms for specialized and staff-augmentation roles. The strategic payoff was bigger than the headcount. Once the company saw that services no longer capped how fast we could grow, the president gained the confidence to hire a dedicated salesperson. That is a thing you only do when you believe you can deliver what you sell.

The operation underneath

Delivery was not the whole job. Every ISCS customer ran on infrastructure we hosted ourselves, across three generations of the platform: the original mainframe SurePower, a client-server version, and the modern web stack we had renamed SurePower Innovation. Customers were already migrating onto that web application, so I made a deliberate choice about where to spend my attention. With the legacy mainframe and client-server worlds handled day to day by a system administrator, I put my own energy into the platform’s future. The one infrastructure question I would not let go of was resilience. Everything ran out of a single on-premises datacenter in our own building, which left the company with no real continuity plan if that site went down, so I proposed moving us onto a multi-location, professionally managed hosting provider for proper redundancy. It was the least glamorous corner of the job, and the kind of single-point-of-failure risk you deal with before it deals with you.

What I take from it

ISCS is where I became an operator rather than only a builder. The first move was to make the truth visible. Measurement did not solve the problems, but it showed us which problem to solve first, and that sequence travels to any business with a profitable core and a stalled trajectory, whether what it makes is code or something you can hold in your hand. I learned to make unpopular-sounding calls, like telling a customer to his face that his account lost us money, by putting real numbers on the table rather than by argument. And I learned that you scale a services business with structure and aligned partners, not with heroics.

I also knew my limits at that stage. I did not yet have much go-to-market sophistication, the pricing and positioning craft I would build later in my career. What I had was enough to get the delivery engine firing and the company’s value moving in the right direction, and for that company, at that moment, that was the thing that mattered. It is also, quietly, one of the accomplishments I am proudest of, in part because it was mine: for the first time there was no partner above me to validate the diagnosis or absorb the consequences. The plan and the operating calls were mine, and I got to watch the team make them work.

I left in the summer of 2010 for two reasons. The commute had become brutal, around sixty-four miles each way, and it had reached the point where almost anything else looked interesting. Then a friend at Adobe called with a step into product management, the room I had been trying to get into since my last years at Accenture, and it was a no-brainer. Walking away from something that was working and still growing was not easy. But the model kept working without me. I stayed in touch with the team, and the things I had put in place, the instrumentation, the partner program, the sprint cadence, stayed in place after I left. Six years later, in 2016, Guidewire announced it would acquire ISCS for a hundred and sixty million dollars, and closed the deal in early 2017. While that was long after I had gone, and I did not benefit from it, I loved to see that the founder who had been ready to sell a tired company in 2008 was still running it eight years later. The goal I had written on that first slide, significant growth toward an acquisition, is exactly what came to pass. Watching the thing I helped build get bought was the truest validation I could have asked for, even from a distance.


This chapter is part of My Work, my career told one company at a time.

← Accenture · All chapters · Adobe →

About the Author

Darin Archer builds businesses where physical operations meet digital intelligence. Over 25 years he has taken hardware and software to market at Intel, IBM, Adobe, and Elastic Path, operated inside Gap Inc., and most recently, as Chief Product Officer at Yottaa, wound down a physical network and rebuilt the product around AI.