My guest for this episode is Ty Sagalow (episode page), one of the founding members of the Lemonade Insurance Group. Ty has held various underwriting and product development position at AIG over his 25 year career there and served as Chief Innovation officer at Zurich North America and Tower Group before joining Lemonade as its first Chief Insurance Officer.
Ty wrote a book about his Lemonade experience called the “Making of Lemonade” which is the topic of the interview!
We cover all kinds of ground in the conversation but I didn’t take long to get to the heart of the matter. The thing that distinguishes many tech startups of course is that their technology is so great. What is that like? Here is a relevant bit:
Ty Sagalow: If you want to create a new process, it’s a thousand times fold better, you’ve got to start from very beginning, start completely from scratch and that takes a different type of way of looking at things. Um, and I’ll give you, I’ll give you one of my best examples.
So, um, we were at the tail end of almost getting all licensed from, uh, from New York and they wanted to make a number of changes, a dozen changes. So I call up Moshe and I say Moshe, we need to make a whole bunch of changes. So I start rattling off these changes as fast as I can and I’m hearing clicking noises in the background and at the end of, by dozen changes, and I’m saying as quickly as I can, I say to Moshe, do you got that? And he says, what do you mean Ty? And I said, well, have you taken note of everything that I’ve just told you we have to change? And he said, no. And I said, Moshe, why the hell not? He says, well, I made the changes as you were saying them should, should I have not done that? Should I undo the changes? And I said, [laughs] no, you don’t have to undo the changes. And that’s the last time I ever questioned Moshe Lieberman. If I was dealing with a traditional insurance software provider, I would have to send that in email. It would then prompt a meeting, which would prompt a number of emails, which would prompt then a number of meetings and maybe six months later I would have it.
It’s worth pointing out that this explanation, that building a system from scratch is better because of the flexibility that developers have in using more modern techniques appears to fly in the face of software development orthodoxy. See Joel Spolsky’s famous post Things you Should Never Do: Part 1:
…they did it by making the single worst strategic mistake that any software company can make:
They decided to rewrite the code from scratch.
…
There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
It’s harder to read code than to write it.
Contrary to popular belief, most software ages more like wine than cheese. Bugs are hard to find and take enormous time and care to replicate, isolate and eliminate. Software needs time in users’ hands to become fully functional and to the extent that it looks like a mess that just means it reflects a messy reality and complexity in the operating environment.
On the other hand! There is real progress in software development tools, especially since modern consumer businesses are vastly greater in scale than before. One very (the most?) interesting innovation actually honors Joel’s quote above: microservices. This is the philosophy that software should be built of detachable component modules that you can replace if you want. A piece of software tends to be an accumulation of a lot of different functions (ingestion, storage, billing, reporting, etc) and these can be made architecturally distinct. If you want to totally change your web app you can just pull that part out and keep the rest together. This lets you keep the wine and throw out the moldy cheese.
That doesn’t mean I disagree with Ty! There’s a difference between licensing systems and building systems and I think an important exception to make for software that supplies the critical business function of a firm. And for an insurance firm that means recording its history.
Every company is different and every policy management system needs to be just as different or the insurer will be hopelessly unable to adapt the system to their needs.
So if you licensed a vendor system and you’d have to rewrite most of the software to suit your needs anyway, you might as well not pay for the legacy code you won’t use. That means that the new code (your code) is written by a few developers who, if they are good, can make changes quickly because they don’t need to read their own code, it is already sitting in their heads.
Yes you need to have a developer good enough to code a system almost single-handedly, and overall smarts and development knowledge is definitely a critical advantage of the valley startups.
The rest is maybe just not being afraid of building your own software!
Not Unreasonable 