An Inside Look with Codeship: Elliot Cohen, CTO of PillPack

Elliot Cohen is the CTO of PillPack, a full service pharmacy which aims to improve the experience of filling prescriptions. We got to catch up with Elliot and discuss the challenges of innovating in the healthcare industry, building investor relationships, and the importance of hiring owners on your team.

An Inside Look with Codeship is a regular series providing an insider’s perspective on founding and building a tech company. Each session, we chat with some of the most exciting voices in tech and ask them where they’ve been, where they’re going, and what we could all be doing together. You can read all Inside Look interviews here.

I’m the CTO of PillPack, which is a combination of product and operations. For us, so much of our product is a service experience, and so it's not only important to have the right software but also to have the right operations to deliver that service. I don't run the day-to-day of the operations up in New Hampshire, there’s an amazing team of people doing that. But I work closely with them to make sure that I understand what those processes are and how we can support them with the best tools possible.

We want to make it delightful and simple to take and manage medication. There's a lot of elements in doing that well, but that's really the original impetus for the company and still the guiding light today.

Yes. I was trained as a cognitive scientist and a computer scientist. I always jumped between being really involved in research as an undergrad and also in things that were totally unrelated to technology, like organizing concerts and events. In a weird way, that did a lot to prepare me for what I'm doing now, because half of the job is about organizing and putting teams together, and half of it is thinking analytically and being an engineer.

After school, I went to Microsoft for a couple years. Then I have spent the rest of my career in early stage, small companies, helping to figure out what to build and how to build it. I’d also been working in healthcare for a while when we started PillPack, and the domain experience was also critical to my role.

We don't have product managers, at least not today, at PillPack. So we expect all of the team members to participate across the spectrum of product development. Our product team is a combination of designers and engineers. We believe strongly that you have to get close to the problem that you are trying to solve. Therefore you need engineers and designers that can collaborate together on the user research, requirements gathering, and ultimately the creation of new product experiences. When you silo these activities in different disciplines like design or product management or engineering, you end up requiring a lot of handoffs and subsequently losing much of the context critical to designing and building great experiences.

So when we're hiring engineers, we look for an aptitude to participate across this spectrum. It's important that they write great code, but it’s also important that they write the right code. [caption id="attachment_2318" align="alignnone" width="1024"]

photo credit: PillPack[/caption]

We want to make the entire experience of healthcare transparent and immediate. We think that's the basis of a really good customer service experience. That’s really never been built in healthcare before.

The reason it's never been built before is because healthcare has not seen a lot of software development and a lot of automation. Other industries have a whole set of APIs which create building blocks to build on -- like Stripe for processing credit cards. We are building that infrastructure in healthcare so that our customers have access to the information they would expect in any other industry; like what is their insurance going to charge them for a medication, or has the physician sent us their prescription.

We are taking a medical world designed for paper and trying to make it behave like a structured set of APIs. To do this well requires dealing with messy and ill-structured data and lots of complex distributed systems.

My primary responsibility to them is to build a great company. What makes our investors and board unique is that we all believe that if you build really great product experiences that your customers love, then the company will do very well. In our board meetings one of our main areas of focus is the happiness of our customers (which we measure using a Net Promoter Score); it’s how we know we are doing a good job and the foundation of building a great company.

I think this is the key that Apple has taught us, even at scale; if you continue to focus on building great experiences, it will translate to a better company.

Your job as a technical co-founder is to boil down the information that investors need to understand in order to advise you on big strategic decisions. For us, this is about synthesizing what we are building, the cost to build it, and the value of building it. For example, we are building a lot of infrastructure to help us deliver a better experience to our customers. The key is to make sure our board understands the cost of building that infrastructure and what the value to our customers will actually be. This enables them to participate in a richer discussion around how much we should invest in this and how fast we should build this area of the company versus other areas.

Whether it’s life sciences or tech, how you communicate that to your board is very different, not only from company to company but from domain to domain. But the commonality is about figuring out what they need to understand to participate with you in the strategy.

If you don't feel like you're good at that, you need to find other people who are. One of the things that is true with all founders but especially technical founders is you have quite a different array of options for what role you play on the team. You don't have to play the role that I just described, but somebody does. If you're not interested in it then you have to figure out who is going to do that. Is that going to be your co-founder? Is that going to be somebody else on the team entirely? You need an answer to how to do that, or you'll likely run into scenarios where you're not communicating clearly with your board and they don't really understand how to help you. That's what leads to a poor working relationship with your investors. [caption id="attachment_2319" align="alignnone" width="1024"]

photo credit: PillPack[/caption]

I have two different degrees, so I'll talk about the value of each of those separately because they were valuable for very different reasons.

Berkeley really taught me how to think. I don't know that everyone needs that, but I did. We have a couple of engineers on the team who did not finish their degrees, and we have some engineers on the team who did. There's no commonality between what they're weak and strong at. So, is a college degree required? Absolutely not.

On the other hand, I would not advise someone to drop out. There are some phenomenal engineers out there that are self-taught (a couple of them are on our team). However, for most people that I have met, school is still the best place to lay a strong theoretical foundation of computer science and more broadly a strong foundation in how to think through a variety of different problems.

Assuming you're in a good school and you feel like you're getting a good education out of it, then I would stay. Education can improve your ability to learn new things and tackle new problems in the long term. That's what I felt like I got out of my undergrad. I got something very different out of MBA at MIT. It really gave me the flexibility to explore a broad array of topics and interests. Again, by no means required. You can get that in a variety of ways in life. But at least in this case, I was able to explore everything from healthcare operations, to how companies get formed, to how they get funded, and how teams are built.

Those learnings came less from traditional textbooks and more from discussion and interaction with professors, mentors, and even other classmates. In that sense it was very different from my undergrad experience but still very, very productive.

This broad exploration taught me better how to go searching for answers in areas I don’t understand very well. And that has been very critical to my role as a founder -- you are constantly exploring new areas that you have little or no expertise in.

I don't think there's any "one-size fits all" answer to what you need to know to be a good technical co-founder. What I can say is I think what every founder needs, whether technical or not, is a deep sense of awareness.

The only way that you're going to build a team around you really fast is being brutally aware of what you are good and bad at and making sure that you surround yourself with people who can fill in the things that you're weak at. Nobody's perfect, but teams can be.

One of my uncles said this to me when I was growing up: "There's owners and then there's employees. Only hire owners." I have tried to follow this advice, and I would give it to myself again today if were starting over.

You're trying to build something that doesn't exist. You're trying to build a technical product that doesn’t exist. You're trying to create a customer experience that doesn't exist. You're trying to build a team that doesn't exist. There is always going to be more to do than you realize, you're going to forget stuff, and stuff's going to fall through the cracks. The only way to prevent that from resulting in a poorly functioning company or poor customer experience is to surround yourself with people who are equally passionate and motivated about solving that core problem and feel a sense of ownership over it.

You have to find people who are dying to work with you to make that thing come into life. You want those people to be real owners. They will always be the ones who step up and take ownership over something, take responsibility for it. They will tell you when they think something is broken and needs to get fixed or they'll just go fix it themselves. And you want to surround yourself with owners.

Mostly, just listen to your gut –- though you can inform that by asking them for examples of it. What are some things they've run in the past, where's a moment in time where they've stepped forward and led? You can ask them questions about why they are passionate, what are they passionate about, what gets them out of bed in the morning. If you just have an open-ended conversation with those types of questions as prompts, by the end of it you should have a pretty good sense of what type of person it is.