How We Built a Claims System in Three Months.

What it means to move fast and with an eye on the future

The introduction

August of last year, we set out to do the impossible: recruit and build a top-tier, in-house claims department that was functional within 21 days of being fully staffed. We did it. The talented team was hired within 30 days and we had taken over all claims within seven days. This is how it all came together.

First, a little background. I am the engineering lead of the claims platform team at Root Insurance Co. At Root, we like to build things fast. We’re different from every other carrier because we only sell insurance to good drivers. Our customers take a test drive so we can analyze the driving data collected through their smartphone to determine how safe of a driver they are. This allows us to price insurance much more accurately than traditional methods based on marital status, address, and credit scores.

Prior to our own claims team, an experienced third party company handled our claims and we audited them to ensure accountability. This arrangement was done for a variety of reasons, but primary among them was that we wanted to focus on building the most accurate pricing in the insurance industry and ensure it was a great experience. Handling claims internally wasn’t initially critical to validating the business concept as a whole and is something many insurance companies never do.

At the time of making the choice to move claims internally, we had grown to be in 20 states. You can imagine the benefits of bringing something so central to the customer experience and so valuable to the core business under our complete control. Superior customer experience and better costs are easier to achieve in the claims experience when we are the ones providing that service. In addition, given our high volume of electronic claims submissions (because all of our customers joined Root via their smartphone), we are in a unique position in the industry to offer a level of automation and innovation in service that is hard to achieve in traditional modes of communication.

When we decided the time was right to take over the claims experience, my team was tasked with designing, building, and deploying a claims management platform in three months. This is a summary of the techniques, outcomes, and lessons learned from that effort.

The technique

There are all kinds of strategies and philosophies that espouse various techniques on how you can build a given system quickly. For me, the best management systems boil down to two things:

1. Keep it simple
2. Iterate

I feel like I wasted more time in my career, not by building things slowly, but by building the entirely wrong thing. This seems to be true by an order of magnitude. The tendency in many organizations is to push harder, become frantic, and work more. The benefits from these activities are minimal and short-lived, and you usually end up paying more for them than you gained. What an organization needs to focus on more than effort is correctness.

If you can manage to keep anything you build simple to an almost radical nature, it will keep you from over-building that system. If you iterate, you have the opportunity to make it better. These forces oppose each other; they pull the product up and down. Iteration allows for complexity to be built, and keeping it simple each time ensures the product that is built is useful. These two forces are the tension, allowing the process to move the product in the correct direction.

Yes, this is the heart of most agile systems, but it’s very easy to get ahold of a process and expect it to solve problems. A process only works if the people involved grasp the reason for the process and carry that weight when making decisions. In many ways this is a non-dogmatic view of an agile approach and how it worked.

The approach

“Keep is Simple” is one of the most common tropes in software development. It is repeated so often that it can often lose meaning, but keeping a system simple is critical. Many of us have the understanding of what simple is, and can recognize it when we see it, but many organizations cannot achieve it. Simple is hard. Why? It isn’t that we can’t recognize simplicity. Just like quality or leadership, we can often recognize it, but we cannot easily quantify it or reliably create it. I found that the following aspects were particularly helpful in us maintaining simplicity on the first version.

The team

I have seen the most success in creating simplicity when everyone on the team has some experience with overly complex systems that have not worked, and come to realize that this is something to avoid. You need those mistakes. You need the pain of past complexity haunting the choices you make. When this awareness is wholly understood by the team, then design sessions can be much more directed and we can restrain our impulses to increase complexity.

At Root, we have a strong culture of simplicity and have the support of the entire leadership team to deliver simple products that meet the needs of the business. Particular to our team, our core product owners understood this and were willing to look at every feature with this concept in mind.

The trap to avoid

Another thing to keep in mind when building an automated system: don’t automate unless you must. I use the word automate, because that is what most software does. It doesn’t do things we can’t, but it does make things easier to do. One of the reasons we were successful in delivering our own claims offer in time was that our product owners in claims were willing to push off the automation of all but the most essential tasks. As a developer, when you are building a system, you can’t always have a deep knowledge of what must be automated and what doesn’t have to be. Because we were able to not automate some potentially time-consuming, lower-return features, we were able to deliver the features that really mattered. This translates into a system that will have a few more clicks per required feature, but it will have those required features.

The timing

Don’t solve future problems. This is something developers love to do. We want to solve all the problems we will ever have, and we want to solve them in one release.

Here’s a great example: we needed to assign incoming claims to a Root adjuster, who would then manage that claim. Since claims come in at all hours of the day, this process needed to be automatic. During the design session around this claim assignment, the conversation quickly became quite complicated. The conversation was about how, when, and why an adjuster would need to be assigned a claim. It is a complicated problem because there are potentially lots of people involved with different availabilities and abilities. And it’s is a complicated problem we don’t have to solve right now.

This is a problem that only needs to be solved when you have too many adjusters and a much simpler process won’t suffice. That is how we settled on a simple random assignment, and edge cases can be handled by people simply talking to each other. Highly managed assignment is a 100-person problem, not a 10-person problem. Solve that problem later, when it matters.

The repetition

The reason you iterate is simple: you rarely do anything right the first time. The more times you do something the better you get at it. It’s that simple.

The deliberate practice

Start with a process, any process, and repeat it on a short interval. For example, we deploy our system at minimum once a day. It feels like a huge waste of time at first, but by deploying our changes everyday, we are able to get user feedback everyday, and make sure we are building the right thing.

There is one caveat: blind repetition does not lead to improvement. Have deliberate practice in your iteration. With intention and introspection, the process will keep improving.

The quote from Grandma

My Grandma used to say “Good better best, never stop to rest, until the good is better and the better best.” If the outcome of your current attempt is better than your last attempt, you will approach the “best.” This method applies to almost everything that you can actually do more than once. In development that applies to the improvement of the iteration through practice, and the features we develop with our iterations. We had all kinds of this improvement over the course of our deployments. For example, a list of claims was good, a searchable list of claims is even better. You won’t know what is better unless you get that feedback from simple features.

The summary

We were able to design, build, and deploy a system that met the needs of the organization and moved the business significantly forward in a short amount of time.

The examples

In short, we kept the entire product simple by:

1. Leaving out specific and hard to define validation rules
2. Avoiding automation with external systems
3. Employing simple percentage based assignments
4. Keeping the layout to default framework styles

We iterated on simple ideas by:

1. Releasing each individual view as soon as it was ready
2. Adding automatic check-sending after the initial manual entry to maintain data
3. Adding specific tracking fields and organizational information to the claim data

These are just a few of the notable examples of our process. This version was just the beginning, exactly as it should be.

The external application

I will end by trying to give some advice if you belong to an organization that has trouble doing anything quickly, and you are wondering where to start.

First, try to identify a smaller project that doesn’t have too much overhead in your organization. Doing this will make your work easier because you will have less old weight to move.

Second, start with trying to deploy a small change very quickly to that project. Pick something almost laughably small, perhaps some simple copy changes in an application. Push that change through to deployment and identify where all the places it moving. Fix those bottlenecks so that you can deploy changes at will. If you cannot deploy a change without impediment, you will never go fast. You will always be slowed down by your process, and then the process has failed you. To be honest, getting some organizations to make just these changes is going to be monumental.

Finally, identify a small but useful feature. Show the stakeholders of that feature how you can deliver small meaningful changes quickly. Doing this will help you build the trust needed move quicker and with more small features.Thanks to the Root team for reading and editing my words, they made them better.