Host Intro (Gene Kim)

All right. For this last introduction of the morning, I'm going to try to tie two ideas together.

First, Clare Hawthorne last year presented a fantastic experience report on her Product Operations journey at Oscar Health and the unique role she played in improving flow and resolving audit-control issues. Second, it turns out that Clare also knows a lot about optionality, which I think is a critical tool for leaders to help enable them to make good decisions, as we've heard throughout the morning.

Part of the reason why Clare knows a lot about optionality is that she got to learn from Dr. Carliss Baldwin, the William L. White Professor of Business Administration, Emerita, at Harvard Business School. Among other things, she was the advisor of Dr. Steven Spear, my co-author in Wiring the Winning Organization, and has been a lifelong inspiration to Dr. Mik Kersten, who first heard her talk at Xerox PARC in 2000. She taught him the economic value of modularity, which is what he decided to study for his PhD thesis.

In her amazing 1999 book Design Rules, Volume One, Dr. Baldwin explained why modularity and architecture are so important, because they create option value.

Clare is now VP of Product Operations and Head of Technical Product Management at Datavant, and will help distill the relevant and lifelong learnings of Dr. Baldwin, who also happens to be her mom. Here's Clare and Carliss.

Clare Hawthorne

Thank you, everyone, and thank you, Gene, for such a wonderful warm welcome.

Today we're going to share a little bit of theory about how technology shapes organizations and walk you through how that theory is playing out at Datavant.

As Gene mentioned, I'm Clare Hawthorne. I've been at Datavant for just under six months now. It was incredible for me how closely the journey Datavant is going through mirrors some of my mom's academic research.

With that, let me turn it over to Carliss.

Dr. Carliss Baldwin

Hi, everyone, and thank you. This has been my first IT Revolution conference, and it's been a very warm and welcoming time, and I just thank you all.

I want to do a quick clarification of the formula that Dave and Steve talked about. That formula is a flow. As the flow of value goes up, it's not a change in stock price; it's a change in the dividend rate. So you have to take that flow and integrate it. It's the height of the stream that gets capitalized. It's like a dividend. Option theory was based on continuous-time mathematics, and so that's the way we think.

Clare Hawthorne

Before we dive into our presentation, I wanted to give you a quick overview on Datavant and what we do.

Let me start with a problem. Healthcare data is data-rich, but deeply fragmented. Data is hard to move, protect, and use. Every stakeholder, probably some of you in this room, has felt that friction.

Why is it hard? Because of the fragmentation. If we look at the supply and demand of healthcare, on the supply side we have patients, clinical records, and claims. On the demand side we have many users: providers, payers, lawyers, insurance brokers, and life-science companies. Everybody needs to access this data.

Datavant sits in the middle, connecting the supply with the demand. Our platform securely moves data from wherever it sits to wherever it's needed, bridging these concepts of supply and demand. We are the data-collaboration platform trusted for healthcare.

Our scale is massive. We have 80,000 hospitals and clinics in our network. Our customers include all of the top 20 life-sciences companies, and we process more than 100 million patient records every year.

We achieve this scale through a lot of mergers and acquisitions. Our CEO actually just announced another one this morning, and this is where it starts to get tricky.

Each of our divisions, which are primary customer groups, began as independent businesses, each with its own complete technology stack. But at the simplest level, all of our customers, each of these divisions, retrieve records and sell charts. Customer requests flow through intake, routing, fulfillment, chart QA, delivery, and billing.

We know there are opportunities to share some of these capabilities. As an example, it would be silly and inefficient to maintain four distinct billing systems.

So the strategic question our technology team is facing is: where do we build shared platforms, which would unlock efficiency and give us more options, and where do we stay unique? To answer this question, we needed a language. So we turned to Carliss's research.

Dr. Carliss Baldwin

How Technology Shapes Organizations is the first word from our sponsors. This is a blurb for my new book, Design Rules: How Technology Shapes Organizations, which can be downloaded for free from MIT Press.

The main message is that similar technology structures create similar challenges. The thing to remember here is: structure matters.

What structures are similar and what structures are different? At two extremes, one technology structure is a flow process. It allows high-volume standardization and promotes efficiency.

The other extreme is a classic job shop: a few people, like in a restaurant, where everybody talks to everyone else. Those two diagrams are supposed to show what's connected. Job shops allow expertise to develop, and they deliver variety so that you can do one-off products. They are the canonical flexible organization.

In the middle you have platforms. Platforms allow you to combine flow processes and job shops. Platforms promote coordination and connectivity, and importantly, combinatorial variety, which I think Mik was talking about a little. They allow you to combine flow processes, job shops, and even other platforms in many new ways.

Platforms are generative. I didn't know that word four years ago. My field doesn't know the word, but they are quintessentially generative organizations.

To make things more complicated, there are actually four useful types of platforms. There are innovation platforms, where the core product becomes a base for others to build on. Think of the initial IBM PC and smartphones.

Logistics platforms move goods, money, and data in standardized ways: container shipping, payment systems. Those are examples of logistics platforms.

Transaction exchange platforms match buyers and sellers. They can capture value from the transactions. Think of eBay, Amazon Marketplace, shopping malls, ride-hailing markets. All of those are transaction platforms. The platform takes a cut of the transaction.

Communication platforms enable the free exchange of media and messages, such as broadcasting and social media, and the money comes in through a third party, that is, ads.

It turns out there are infinite combinations of platforms and processes, some of which might work as a system. That's the next level of test.

I want to illustrate this very quickly by talking through how recombination creates evolution in organization structure, in profit streams, and in value. I'm going to illustrate the evolution of retail through the invention and recombination of processes and platforms.

Let's start in the beginning, around the time of Adam Smith, 1776. Each store on a street would be a job shop, and the street was the platform. You go back and you see the high street in many villages, Main Street in many American towns, the avenues in Paris, Oxford Street in England, Fifth Avenue: famous streets for having stores.

Macy's was an innovation that occurred in the late 19th century, with many stores in the same building. Each of the stores, which became departments of Macy's, was a job shop. The merchandisers brought the goods in, and Macy's Corporation took care of the building. They provided space allocation, accounting, and billing, and they didn't really interfere too much with how the merchandisers ran their piece of the store. Customers usually took care of delivery: you go, you buy a dress, and take it home.

Sears: earlier, I think yesterday, Steve Wilson talked about Sears. The catalog replaced the store. Customers sent orders in with payments; that was the billing part. Sears, for the first time, promised timely delivery. They took responsibility for getting the goods home.

They were almost immediately overwhelmed by the number of shipments that had to flow through their system. So they created out of thin air a centralized logistics platform that treated orders and packages as modules within an automated flow process. The process was a flow, but each package was its own module. It was a logistics platform.

Amazon replaced the catalog, or a physical store like Barnes & Noble, with a website. Totally new tech. It was a technologically enabled substitution of one set of processes for another. Their fulfillment model was exactly copied. In fact, they hired a bunch of people from Walmart's headquarters, so it was copied from Walmart. Walmart had copied their fulfillment model from Sears. You have a continuation of the processes ordered through a hundred years of evolution.

But the new model, with a website as the purveyor and the transaction platform, could be imitated. Steven said don't be Amazon, be Walmart, because you can't get there from here, from Walmart to Amazon, because you can't do that important front end.

Macy's was a physical transaction platform, a department store. Sears was a print transaction platform, the catalog, coupled with a logistics platform, warehousing and fulfillment. Amazon was a digital transaction platform coupled with logistics platforms.

Over to Clare.

Clare Hawthorne

We're going to come back to Datavant's typical transaction flow.

Our team sees an opportunity to build a standardized logistics backbone, just like Sears and Amazon did. We know that we want to build this platform with a modular architecture so that we can preserve optionality in the future, like for future acquisitions like we had this morning. Carliss's framework of the four platform types is giving us a common language so that we can all envision what we are building together.

Many of you probably might be thinking: there could be a transaction platform here too. I wish it were that simple.

One thing you should know about Datavant is that we are obsessed with our customers, which means a one-size-fits-all approach isn't going to work. For example, earlier this year we pressure-tested the idea of a common landing page. Amazon has one homepage, right? But for Datavant, it wasn't going to work. Our legal and insurance customers are high-volume transactional. Insurance payers are bespoke and have enterprise agreements. We knew we had to follow a different pattern.

The parallel here is General Motors, a classic example of a company that faced a very similar problem.

First, a little history lesson. GM was founded by William Durant, and General Motors, like Datavant, grew through rapid acquisitions: Buick, Oldsmobile, Oakland, Cadillac, GMC, Scripps-Booth, Chevrolet, Sheridan. Growth outpaced innovation, and GM became powerful in scale but very fragmented in its structure. It was more of a cluster of brands than any version of a single enterprise.

Enter Alfred Sloan. His insight was that different customers wanted different cars: a car for every purse and purpose. So he created the now-famous ladder of brands. Chevrolet was the entry point, and he went all the way up to the luxury Cadillac. This was in direct contrast to his competitor Henry Ford, who had an all-one-size-fits-all model with the Model T.

But Sloan had to reorganize his company, technology shaping organizations, to align with the strategy. This might be one of the most studied org charts in history. You don't have to read everything on here. The takeaway is that Sloan organized GM around the nine brands.

Each one kept its own identity. They had a sales strategy, they had their brand and customer relationships. At the same time, he centralized the backbone: finance, legal, HR, real estate, all of the things customers don't see he brought together.

This was how Sloan turned sprawl into a system, by keeping the customer experiences distinct while centralizing the backbone.

Let's go back to the typical Datavant transaction flow, and let's add in top of funnel. As we talked about earlier, we're centralizing that logistics platform. But the top-of-funnel activities, we've determined, need to stay divisional. Order routing, you'll notice, is still in gray. Centralizing risks losing some of that nuance of how we want to route these orders and charts, but divisionalizing risks maintaining bespoke tech that we don't need, which is a tension that all of us feel in this room all the time.

We're still charting our course to figure out how to strike the balance, particularly with this area.

Taken from this lens, Datavant's technology strategy is simple. Where customer experiences differ and workflows are specific, we're going to divisionalize. But as we centralize, we centralize the things that give us scale: logistics, and also the things I didn't talk about in the customer flow, like infrastructure and security.

The outcome is customer relevance and efficiency, striking that balance between the two.

I'll turn it back to Carliss, who's going to pull the threads together.

Dr. Carliss Baldwin

The three lessons you can take away:

First, assess your processes through a structural lens. What parts are a job shop? What parts are a flow process? What parts are platforms? What are the combinations that you have?

Second, identify the work that can be shared once you've done that.

Third, divisionalize where customer needs diverge. That's the essence of how technology shapes organizations.

Clare Hawthorne

As always, we want to close with an ask. At Datavant, we are in the middle of integrating acquisitions while building the shared backbone. I know many of you have gone through that similar journey. We'd love to chat either in the breaks, or my email address is up here.

Dr. Carliss Baldwin

The last three days I've heard a lot. The continuing theme has been code conversion using AI and the problems of legacy code. We have, on code conversion, Topo Pal, Jeff Gallimore, Johnny LeRoy, and others of you. I just picked the ones that seemed most salient.

Then we have the problem of technical debt, beginning with Tim O'Reilly mentioning Ward Cunningham on day one. Then we had Dave and Steve just a minute ago. Mik Kersten, you know, you're loaded down with technical debt.

What worries me is, as you go through all these code conversions, how do you know you're not raising your technical debt as opposed to lowering it? We've heard a bunch of people present on that, I think very cogently.

But the problem is that software has a hidden structure that isn't self-evident. You know it yourself, and you do some flow charts on it, but all I've seen is network maps, and the network maps don't reveal the hidden structure.

I'd love to talk to you all, or to anyone who's interested in the hidden-structure problem, because I think it's the one I see that's not solved.

Thank you all very much.