Tom Gaffney

Two halves of a career

Most people who build software spend their career in one world or the other. Startups or enterprise. Moving fast or moving carefully. I have spent about half my time in each, and the two halves taught me almost opposite lessons. Holding both is most of what I bring.

The first half: startups

I was CTO of a health engagement platform. Before that I built a professional services organization from zero at a SaaS company serving major media, sports, and enterprise brands.

What that half teaches you is triage: which problems get solved now, which get solved badly on purpose, and which do not get touched at all. There was never a separate team to hand the hard part to. You learn what actually has to be right before launch and what can be fixed the week after, and you learn it by getting the answer wrong a few times. You also learn how much of a technology problem is really a sequencing problem: not what to build, but what to build first, and what to deliberately leave undone.

The second half: a global bank

The second half was nine years inside a global bank, across three roles, each with more responsibility than the last. The work spanned Global Payroll, Human Resources, Real Estate, and Public Affairs. Most recently I led technology product for Total Rewards and Payroll, supporting a workforce of roughly 220,000 across more than 90 countries. For the last two and a half years there I led a GenAI product from prototype to enterprise production.

I was hands-on in a way most people at my level are not, writing and testing prompts myself rather than reviewing someone else's spec. But shipping inside a bank of 220,000 people took a team of product managers, engineers, risk partners, and designers. That is the part that does not fit on a slide: at that scale, the technology is maybe a third of the work. The rest is understanding who depends on the thing you are changing, what happens on the day it is wrong, and who has to sign off before it reaches anyone.

What carries over to a company your size is not the headcount, it is the judgment: what happens on the day the system is wrong, who has to sign off before anything reaches a customer, and how to sequence the work so the riskiest part is proved first rather than last. None of that needs a bank behind it. It is simply missing in most companies, because nobody there has had to do it yet.

Payroll is an unforgiving place to learn that. When the software is wrong, the error is in someone's paycheck, and nobody involved treats it as a rounding error. That half of my career taught me how to work at scale, in compliance, with risk in front of me rather than behind me. It also taught me which decisions can be automated and which ones need a human signature, which is exactly the judgment call every company is now facing about AI.

What both halves taught me

The building is the part everyone focuses on, and it is rarely where projects succeed or fail. The real work is upstream: figuring out the right thing to build, pressure-testing whether it moves a number that matters, and designing it to hold up in the real world. Get those right and the build becomes the straightforward part. Get them wrong and no amount of engineering saves it.

GO Tech Labs exists to bring that upstream work to the companies that need it and cannot staff it, which is why every engagement starts by working out what is worth building rather than by pricing a proposal.

What that gets you is a shorter list of things worth building, and work that holds up after we are gone.