 From Sand Hill Road to the heart of Silicon Valley, it's theCUBE, presenting the People First Network, insights from entrepreneurs and tech leaders. Everyone, welcome to this special CUBE Conversation. I'm John Furrier with theCUBE. We're here at Mayfield Fund on Sand Hill Road, venture capital for investing and stuff here for the People First co-created production by SiliconANGLE theCUBE and Mayfield. Next to us, Phil Finokhan, who's the former CTO of Express Scripts as a variety of other roles. Went to Stanford, Stanford alum. Good to see you, thanks for joining me for this interview. Thank you, thank you for having me. So, before we get into some of the specifics, talk about your career, your former CTO Express Scripts. What are some of the other journeys you've had? Talk about your roles. Yeah, I've had sort of a varied career. I started off as just a peer coder for a contract coder in the mid-90s. I sort of stumbled into it, not because I had a computer science background, but because when you start coding, sort of for fun in Silicon Valley in the mid-90s, there are just lots of jobs, and I was lucky to have great mentors along the way. In 2003, I joined Yahoo and came in as the lead engineer and sort of the ops guy and the building release guy for the login and registration team at Yahoo. So I learned how to, went from being just a coder to being somebody who knew how to run and build big systems and manage them all around the world. That was in the day when everything was bare metal and I could go to a data center and actually look at my machine and say, wow, that one's mine, right? And sort of progressed from there to being the architect by the time that I left for some of the big social initiatives at Yahoo on my way out, the YOS, the initiative to try to build Facebook in I think 2007, 2008 to try to take them on. That didn't work out too well, but it was definitely a formative experience in my career. From there, I went to Zynga where I was the CTO for Farmville, was really, really good at getting middle-aged women in the Midwest to come play our game and was there for about three years. And it was highly high growth too, Farmville. Huge growth. Took off like a rocket ship. Over the 10 quarters that I worked on the game, we had over a billion dollars in revenue and that was the Zynga IPO on the back of that, right? And we weren't the only game, but we were certainly- That was one of the big games. The big whale, us and poker were the two that really drove the value in Zynga at that point. After that, I went to American Express where I worked in a division that sort of sat off on the side of American Express focusing on stored value products. I was the chief architect for that division, stored value products and international currency exchange. So at one point, I was in charge of both a pre-paid platform and American Express' travelers checks platform, believe it or not, I think that still exists, although it's not heavily used anymore. And finally, I went to Express Scripts where I spent the last three years as the CTO for that org. It's interesting, you got a very unique background because you've seen the web scale talk about bare metal the other days. I mean, I remember those days vividly, dealing with database schemas. I mean, certainly the scale of just Yahoo front page, never mind the different services that they had, which by the way, silo-like native databases. Oh, totally. So building a registration identity system must have been like really stitching together core part of Yahoo. I mean, what a herculean task that would have been. It was a lot of fun, we learned a lot. It was my first experience in figuring out how to deal with security around the web. We had at the beginning some vulnerabilities here and there. As time went on, our standards around interacting around the web got better and better. Obviously, Yahoo's running into trouble around that in the subsequent years, but it was definitely a big learning experience being involved in the development of the OAuth 2.0 spec. And all of that, I was sort of sitting there advising the folks who were in the middle of it. And that became essentially the standard, as we know, tokens dealing with tokens and SaaS. Really drove a lot of the SaaS global generation in cloud, which becomes kind of that next generation. So you have web 1.0, web 2.0, then you have the cloud era, cloud 2.0.9 are going DevOps and apps. I want to give you a thought and you throw crypto in there just to have for fun. I'm dealing with blockchain and then token economics and new kinds of paradigms are coming online. It's amazing how far we've come in those years, right? I mean, I look at the database that was built inside of Yahoo and this predated me. This was back to circa 1996, I think, but big massively scalable databases that were needed just because the traditional relational database just wouldn't work at that scale. And Yahoo was one of the first to sort of discover that. And now you look at the database technologies that are out there today that take some of those core concepts and just extend them so much further. And there's so much easier to access, to use, to run, operate all of those things than back in the days of Yahoo's old UDB. And it's amazing just to see how we've come. I want to get your thoughts because just thinking about the Yahoo and just your experiences and even today. At that time, it was like changing the airplanes engine at 35,000 feet. It was really difficult. A lot of corporate enterprises right now are having that same kind of feeling with digital, digital transfer, I say the cliche, but it is true this impact, the role of data that's playing and just for value creation, but also cyber security could put a company out of business. So there's all kinds of looming things that are opportunities and challenges that are sizable, huge tasks that was once regulated to the full stack developers and the full web scalers. Now the lonely CIO with the anemic enterprise staff has to turn around on a dime, staff up, build a stack, build commodity, scale out. This is pretty massive. And not a lot of people are talking about this. What's your view on this because it's super important. Yeah, it is. So I had kind of a shock moving from working my whole career here on Silicon Valley and then going to American Express, which is very similar in a lot of ways to express scripts and the sort of corporate mindset around what is technology. There's this notion that everything is IT. And here in the Valley, IT is internal networks and laptops and those sorts of things, that the stuff that's required to make your enterprise run internally, their IT is all of your infrastructure, right? And IT is a service organization. It's not the competitive advantage in your industry, right? And so both of the places that I've gone have had really forward-thinking leaders that have wanted to change the way that their enterprise operates around technology, and move away from IT to technology, to thinking about engineering as a core competency. And that's a huge change, not only for the CIA. You're saying they did have that vision. They had the vision, but they didn't know how to get there. And so my charter coming in and others who were on the teams around me, our charter was to come in and help build a real engineering organization as opposed to an IT org that's very vendor-oriented, that's dependent on third parties to tell you the right thing or the wrong thing, that hires consultants to come in and help set up architecture standards because we couldn't do that on our own. We're not the experts on this. That's sort of the mindset in many old-school companies, right? That needs, that I think needs to change. I mean, this notion that software is eating the world is still not something that people have gotten their heads around in many companies, right? And data's washing out old business models. So software's eating the world. Data's the tsunami that's coming in and gonna take out the beach and the people there. Right, and so it's like all of these things, it's one thing for a forward-thinking CEO like Tim Wentworth at Express Scripts who was responsible for bringing mean and the group in. Those kinds of folks, it's one thing to know that you have to make that transition. It's another thing to have a sense of what that means for an engineering team and all the more for the rest of the organization to be able to get behind it. I mean, people, I don't know, any number of business partners who have been used to just sort of taking the spec, throwing it over the wall and saying, come back to me in two years when you're done. That's not how effective organizations work around technology. Let's drill into that because one of the things, it's cultural. I mean, I do so many interviews on theCUBE, we talk to leaders all the time like yourselves and the theme keeps coming back. It's culture, it's process technology, all those things they're talking about. But culture is the number one issue people point to in saying, that's the reason why something did or didn't happen. Correct. So you talk about thrown over the fence. That's waterfall, right? So you think about the old waterfall methodology, agile, well-documented, but the mindset of product thinking is a really no-vill concept to corporate America, not to Silicon Valley and entrepreneurs. They got to launch a product, not roll out SAP over two years or something that they used to be doing. So now that's a cultural mindset shift. It's difficult for folks, even if they want to get on board to come along some of the time. One of the real big successes we had early on at Express Scripts was transitioning our teams to agile wasn't difficult. What was difficult was getting business partners to come along and be actively engaged in that product development mindset and lifecycle and all those sorts of things. And we had one partner in particular. We were migrating from a really old, really clunky customer care application that had taken years and years to build, took on average, a new agent took six weeks to get trained on it because it was so complex and it's Oracle Forms and every field in the database was a field on this thing and there were green screens to do the stuff that you couldn't do in Oracle Forms. And we wanted to rebuild the application. We tried to get them to come along and say, okay, we're gonna do it in really small chunks, but business partners were like, no, we can't afford to have our agents swiveling between two applications. And so finally after we got our first sort of full feature complete, we begged to go into a call center with our business partners and sit down with a few agents and just have them use it and see if it looked like it worked if it did the right thing. And it was amazing seeing the business partner go over the course of an hour from, I can't be engaged in this, I don't want agent swiveling, I don't want to be delivering partial applications, I want the whole thing too. Oh my God, it works way better. The design is much nicer, the agent seemed to like it. Here are the next things we should work on. These are the things we got wrong. Like they immediately pivoted and it wasn't, it wasn't because it was because they're the experts. They know how to run their business. They know what's important in their call centers. They know what their agents need. And they were just, they just never seen the movie before. They just had no concept that you could work that way. So this is actually interesting because what you're saying is a new thing foreign to the business partners, the tech teams on board, being agile, building products, they have to, they can't just hear the feature benefits, they got to feel it. Yeah, they have to see it and experience it. This seems to be the experience of success before they can move. Is that a success that you think culturally, something that people have to be mindful of? It's absolutely something you have to be mindful of. And that was just the first step down the path. I mean, that team made a number of mistakes that folks here I think in the Valley wouldn't normally make, you know, over committing and getting themselves into deep water by trying to get too much done and actually getting less accomplished in the process because of it. And, you know, the engagement around using data to actually figure out what's the next feature that we build when you've got this enormous application that you have to migrate, you should probably have some insight as to, you know, feature by feature, what are you going to work on next? And that was a real challenge because there's a culture of expertise driven, you know, being subject matter driven, expertise driven as opposed to being data driven about how do you actually develop- Let's talk about the data driven. We had an interview earlier this morning with another luminary here, the Mayfield 50 conference celebration that they're having. And he said, data is the new feedback mechanism. And his point was is that if you treat the agile as an R&D exercise from a data standpoint, not from a product, but get it out there, get the data circulating in, that's critical in the formulation of the next phase. It is, yeah, it's absolutely critical. That was the eye-opener for me going to Zynga. Zynga had an incredible, probably still does have an incredible product culture that, you know, every single thing gets rolled out behind an experiment. And so, you know, that's great from an operational perspective because it allows you to, you know, move quickly and roll things out in small increments. And when it doesn't work, you can just shut it off and it's not some huge catastrophe, but it's also critical because, you know, it allows you to see what's working and what's not. And the flip side of that is some humility of the people developing the products that their ideas are not gonna work sometimes. Just because you know this domain well doesn't mean that you're necessarily gonna be the expert on exactly how everything's gonna play out. And so, you have to, you know, have this ability to go out, try stuff, let it fail, use that. Hopefully you fail quickly, you learn what's not working and use that to inform what's the next step down the path that you take, right? And, you know, an agile plays into it. But that's, for me, that's the big transition that corporations really have to struggle with and it's hard. You know, you've been there, done that, seen multiple ways of innovation. Want to bring up something to kind of get you going here. You see this classically in the old school, you know, 90s, 80s day. Product management, product people, and sales people. Yes, sales, yeah, button heads. Product marketing, marketing people want this, sales marketing want this, product people, button heads. But now with agile, the engineering focus has been the front lines. People have built in their engineering teams, in-house, they're building custom stacks for whatever reasons, the apps are getting smarter. The engineers are getting closer to the edge, the customer, if you will. How do you help companies, or how do you advise companies to think about the relationship between a product-centric culture and a sales-centric culture? Because sometimes you have companies that are, oh, about the customer-centric, customer-centric, customer-centric, product-centric. And sometimes if you try to put them together, there's always going to be an alpha, beta, kind of thing there. And that's the balance in this. What's your take on this? It seems to be a cutting-edge topic. Well, so, you know, one of the last big initiatives that I worked on at Express Scripts, Express Scripts has, to my knowledge, the largest automated home delivery pharmacy in the world. It's amazing if you walk into one of our pharmacies where, you know, automation is packaging, and filling prescriptions and packaging, and shipping, and doing all of that stuff. And we've built so much efficiency into the process that we started getting slack in the system. You know, every year you're trying to figure out how to make something work better and, you know, have better automation around it. And so, you know, what do you do with all of that slack? The sales team can't sign up enough new customers for Express Scripts to actually fill that capacity. And so they created a vision of commoditizing this, you know, basically white-labeling your pharmacy. We call the pharmacy as a platform. Exposing APIs to third parties who might want to come along and, hey, Phil's pharmacy. You can now fill with branded, you know, prescriptions that get sent to you in your home, right? And so it's a fantastic vision, but there is a real struggle between, you know, engineering who had all these legacy stacks that we needed to figure out how to move to be able to really live up to this. You know, the core of Express Scripts was our members and not somebody else's members. And so there's a lot of rewiring at the core that needs to be done. A, an operations team, a product team that's, you know, running these home delivery pharmacies, and a sales team that wants to go off and sell all over the place, right? And so, you know, early on, we started off in a sales team, tried to sell like six different deals that all required different parts of the vision, but, you know, they weren't really, there was no real roadmap to figure out how do you get from where we are at to the end. And we could have done any of those things, but trying to do them all at once was going to be a train wreck. And so, you know, we stubbed our toes a couple of times along the way, but I think it just came down to, you know, having a conversation and trying to be as transparent as possible on all sides, in all sides, to, you know, try to get to a place where we could be effective in delivering on the vision. The vision was right, and everybody was doing all of the right things, but if you haven't actually, with so much of this stuff, if you haven't seen the movie, if you haven't worked this way before, there's no, there's nothing I can tell you that's going to make it work magically for you tomorrow. You have to just get the teams together and work in small increments and figure out how to get there, right? Yeah, exactly. You gotta go through spring training, you gotta do the reps. Yep, absolutely. Cutting the reps in. All right, so on your career, as you look at what you've done in your career and what people outside are looking at right now, you got startups trying to compete and get a market position. You have other existing suppliers who could be the old guard, retooling and replatforming, refactoring, whatever the buzzword you want to use. And then the ultimate customer who wants to consume and have the ability of having custom personalization, data analytics, unlimited elastic capability with resource for their solution. What advice would you give to the startup, to the supplier and to the customer to survive this next transition of cloud 2.0 and the data tsunami and all the opportunities that are coming? Because if they don't, they'd be challenged. Start goes on a business, supplier gets displaced. Right, I mean, well, so the startup, I don't know if I have good advice for the startup. Startups in general have to find a market that actually works for them. And so, you know, I don't know that I've got some secret key that allows startups to be effective. Don't run out of money. Yeah, don't run out of money, you know. That's my favorite advice. Try to figure out, you know, how to build effectively to get you to the point where you're, you know, where you're gonna win, right? One of my early, one of the early jobs I had in my career, I came into a startup and I tried, one of the founders had written the initial version of the code base. I as a headstrong engineer was convinced that he had done horrible work. And so, I sort of holed up for like six to eight weeks doing a hundred hours a week, trying to rewrite the entire code base while getting nothing done for the startup. You know, in the end, that was the one job I've ever been fired from and I should have been fired because, you know, honestly as a startup, you shouldn't worry about perfection from an engineering perspective. You should figure out how to try to find your marketplace. Everybody has tech debt. You can fix that as time goes on. You know, the startup needs to figure out how to be viable more than anything else. As far as suppliers go, you know, I don't know, it's interesting that, you know, I sort of look at corporate America and there are many, many companies that really rely heavily on their vendors to tell them how to do things. They don't trust in their own internal engineering ability. And so, and then there are the ones like the teams that I've built at AmEx and Express Scripts that really do wanna learn it all and be independent. I would say identify when you walk into somebody's shop which they are and sell to them appropriately. I, you know, I've been a Splunk customer for a long time. I love Splunk, but the Splunk sales team early on at Express Scripts tried to come in and sell me on a whole bunch of stuff that Splunk was just not good at, right? And you knew that. And I knew that because I've been a hands-on customer ever since Zynga, right? I know what it's good at and I love it as a tool, but, you know, it's not the Swiss Army and if it can't do everything. Well, now you got single FX so now you can get the observability you need. Yeah, exactly, right? So, yeah, you know, I would say, you know, for those kinds of companies it's important to go in and understand what your customer is, you know, what your customer is asking for and respond to them appropriately and in some cases, they're going to need your expertise either because they're building towards it or they haven't gotten there yet. In some cases, one of the things that I've done with teams of mine in the past was it with AppDynamics at Express Script, excuse me, at AmEx five or six years ago, they were sold on, you know, bringing in AppDynamics as a monitoring tool. I actually made them not bring it in because they didn't know what they didn't know. I made them go build some basic monitoring, you know, using some open source tools just to get some background. And then, you know, once they did, we ended up bringing that AppDynamics in but doing it in a way that they were, you know, creative to what we were trying to accomplish and not just this thing that was going to solve all of our problems. Yeah, so that brings up the whole off-the-shelf, general purpose, software model that you're kind of, you're referring to that. The old model was lean on your vendors, they're supplying you, so you lean on them because you don't have the staff to do it yourself. Correct. That's changing. Do you think that's changing? It is, it's changing, but again, I think there's a lot of places where people nominally want to go there but don't know how to get there, right? And so, you know, people are stubbing their toes left and right. And that's, you know, that's, if you're doing it with this mindset of we're constantly getting better and we're learning and it's okay to make mistakes as long as we move forward. It's okay to stub your toe if you don't cut up an artery open. Yeah, that's true. Yeah, exactly. You don't want to bleed out. That's a cybersecurity act. That's true, that's true. Well, I mean, but for me, a lot of the time that just comes down to how long are you waiting before you stub your toe? If you're, you know, if you wait two years before you actually try to launch something, the odds of you cutting your leg off are much higher than... Well, I want to get into the failure things. I think stubbing your toe brings up this notion of risk management, learning what to try, what not to do, take experiments to try to, your apnea, which is a great example. Before we get there, you mentioned suppliers. One of the things we're here and I want to get your thoughts on this is that a lot of CIOs and CISOs or CDOs, whatever title is acronym, they try to reduce the number of suppliers. They don't want more tools, right? They don't necessarily want another tool for the tool's sake or they might want a replatform. What does that even mean? So we're hearing in our interviews and our discussions with practitioners that, hey, I want to get my suppliers down. Oh, by the way, I want to be API driven. So I want to start getting to a mode where I'm dictating the relationship to suppliers. How do you respond to that? Do you see that as aspirational, real dynamic or fiction? It's a good goal, it's good motivation. I believe it. For me, I approach the problem a little bit differently. I'm a big believer. Well, so because I've seen this pattern of this next tool is going to be the one that consolidates three things and it's going to be the right answer. And instead of eliminating three and getting down to one, you have four because you need to unwire this new thing. There's a lot of time and effort required to get rid of your old technology stack and move to the new one, right? I've seen that especially coming from the CISO for Express Scripts is an amazing guy and was definitely trying to head down that path but we stubbed our toes. We ran into problems in trying to figure out how do you move from one set of networking gear to the next set? How do you deal with all of the virus protection and all the other, there's this huge variety of tools. So it's not just technical debt, it's disruption. Yeah, it's disruption to the existing stack and you've got to move from old to new. So my philosophy has always been with technical debt. When you're in debt and I think technical debt really does operate in a lot of ways like real debt, right? Probably good to have some of it. If you're completely debt-free, that's, I've never been in that place before. You're comfortable. You might not be moving. Yeah, exactly. If you're happy on the beach sitting on the beach. Right, exactly, right. It's a, but you know, with that technical debt, you know, there's two ways to get to pay down your debt. You can scrimp and save and put more money into debt, you know, principal payments as opposed to spending on other new things or, well, and or, build productive capacity. And so a huge focus for me, for the engineering teams that we build, and this is not anything new to folks in this area, but you know, always think about an arms race where you're getting 1% better every day. The aggregation of marginal gains and investing internal improvements so that your team is doubling productivity every year, which is something that's really possible for some of these engineering organizations is the way that you deal with that, right? If you get to the point where your team is really, really productive, they can go through and eliminate all the old legacy technology. That's actually great advice, and that's interesting because a lot of people just get hung up on one thing, operating something, and then growing something. And you can have different management styles and different techniques for both, the growth team and the operating team. You're kind of bringing in saying, we can do both. Yeah, you absolutely can. Operating with growth in mind to the 1% better approach. You know, and for me, it's been an interesting journey. You know, I started off as the engineer and then the architect, who was always focused on just the technology, the design of the system in production. Sort of learned from there that you had to be good at all the systems that get code from a developer's desktop into production. That's a whole interrelated system that's not isolated from your production system. And then from there, it has to be the engineering team that you build has to be effective as well. And so I've moved from being very technology centric to somebody who says, okay, I have to start with getting the team right and getting the culture right. If we're ever gonna be able to get the technology to a good place. Mind you, I still love the technology. I'm still an architect at my core, but I've come to this realization that good technology and bad teams will get crushed by bad technologies and good teams. Because I've now seen that in a couple of places where you have old but evolving technology stacks that have gone from low availability and poor performance and low ability to get new features into production to a place where you're fixing all of that at a high rate. But it starts with a team. We're bringing some core Silicon Valley ethos into the IT conversation because what you're talking about is I'll fund an A team with a B plan any day over a B team with an A plan. And where this makes sense, I think is true is that to your point about debt, A teams know how to manage it. So this is kind of what you're getting at here. You can take that same ethos. So it's the agile enterprise. That's what we're talking about. Okay, so hypothetical final point I want to chat with you about. Let's just say you and I were starting a company. I'm a chief architect. You're the chief architect, I'm coder. What are we doing? Do I go horizontally scalable cloud? Certainly cloud native. How would you think about building? We have an app in mind. All the requirements are defined. It's going to be data centric. It's going to be game change that have community. It might have some crypto in there. Who knows, right? It's going to be fun. How do we scale this up to be really fast? How would you architect it? Yeah, well, I do start in the cloud. I go to AWS or Azure or any of the offerings that are out there and leverage everything that they have that's already wired up already for you. I mean, the thing that we've seen in the evolution of software and production systems over the last, well, forever, is you get more and more leverage every day, every year, right? And so if you and I are starting a new company, let's go use the tools that are there to do the things that we shouldn't be wasting our time on. Let's focus on the value for our company as much as we can. Don't over architect. I think premature optimization is a thing that I learned early on as a real problem. You should, you know. Give an example of what that looked like. I've seen team. Database scale decisions done with no scale. Correct, yeah, you know, you go off and you build. Let's take this data, this is the most scalable data is what we have no users yet. Right, you build the super complicated, you know, caching architecture or, you know, you go design the most critical part of the system out of the gate, you know, using assembly. You know, you use C++ or, yeah, you use a low level language when a high level language with your three users would be just fine, right? You know, you can get the work done in a fraction of the time. And get the business logic down. Correct. The IP. Right, solve the problem when it becomes a problem. Like it's, you know, I've any number of times I've run into systems, I've built systems where you have some issue that you run into and you have to go back and redesign some chunk of the system. In my experience, I'm really bad at predicting and I think in general engineers are really bad at predicting what are going to be the problem areas until you run into them. So just go as simple as you can out of the gate. You know, use as many tools as you can to solve problems that, you know, maybe as an engineer, I want to go rebuild everything from scratch every time. I get the inclination, but it's- It's a knee-jerk reaction to do that, but if you stay your course, don't over provision, overthink it. Just start taking steps towards the destination you want to, the division you want to go to and get better. Solve the problem that you have when it shows up. Both mindset, execute, solve the problems when they're there. And initially the problem that you have is finding a market, not, you know, building the greatest platform in the world, right? Find a market, exactly. Phil, thanks for taking the time. Thank you very much, appreciate it. Hey, we're here for the people first. Mayfield's 50th celebration, 50 years in business. Secube co-production, I'm John Furrier. Thanks for watching. Thanks, John.