Initial focus of any company or development team is finding a product market fit. Products are developed quickly; they are iterated on and changed continuously and there are frequently multiple products being developed at the same time.

A year or five down the road, you find yourself on a team of over a hundred engineers continuously fending off hungry customers that demand more and more from all of your products. At that point you realize that you can’t continue growing down the straight lines but must occasionally stand back, rethink, regroup, reassess. As a part of that reorganization platform teams get established and start serving internal rather than external customers.

These teams will inherit piles of legacy code, technical debt, lack of process, and the enormous operational burden of keeping the lights on while the product teams continue attacking customer features at full speed. There isn’t a single solution to this problem (otherwise everybody would be already doing it), but as you see the same patterns over and over again across multiple organizations, certain themes do emerge.

In this talk I would like to cover a few different components that need to be paid attention to in the platformization effort, as well as some techniques and gotchas around them.

Themes:

* Platform team is not a “Legacy Dump”

- How do you define the mission and vision for the teams?
- Who does the rest?

* Getting out from under the support burden:

- Establishing an effective on-call process
- Streamlining development and deployment practices
- Building a technical roadmap

* Making platforms sexy

- Best hires are poached internally
- Building engineering trust

* Swapping out the foundation while the house is standing

- How do you innovate on platform products?
- Turning off legacy services

* Gaining adoption

- Platform as a real product
- Roadmaps, stakeholder communication, feature breakdown
- Securing customer trust

* Measuring success

- How do you know you are delivering value for the company?
- How do you know you are solving the right problems?

Each topic deserves a talk of its own, however it’s easier to paint a picture by example. In this talk I will tell a story of building out a platform organization at Flatiron Health, a five-year-old HealthTech startup, where I came a year ago to grow their data platforms.

Flatiron’s mission is to to improve lives by learning from the experience of every cancer patient. Our data platform (a.k.a. Learning Healthcare Platform) is a set of teams whose mission is to improve cancer care and expedite cancer research by decreasing the complexity of finding, using, and improving Flatiron’s ever-growing dataset. We aim to destroy data silos by creating, promoting, and supporting a platform that facilitates adaptation of all the data points available from a variety of tools to enable easy and efficient discovery, retrieval, ingestion, validation, documentation, and QA of our data.

And while my platform organization here is just a year old, I feel that highlighting some themes and patterns through the story of our successes and failures will be useful to those just venturing on the path to platformization. Leaving this presentation participants would be able to:

- identify main areas of focus when creating or reviving a platform team;
- gauge potential risks within their own organization;
- and gain exposure to variety of tools and techniques used in the industry.

Back to Agenda Page >