>> Narrator: From Sand Hill Road, in the heart of Silicon Valley, it's theCUBE, presenting the People First Network, insights from entrepreneurs and tech leaders. >> Hello and welcome to a special Cube conversation, I'm John Furrier with theCUBE. We're here at Mayfield Fund on Sand Hill Road, Venture Cap for investing here for the People First co-created production by theCube and Mayfield. Next to us, Phil Finucane who's the former CTO of Express Scripts as well as a variety of other roles. Went to Stanford, Stanford alum. >> Mm hmm. >> 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, you're a former CTO of Express Scripts >> Yep. >> What are some of the other journeys that you've had? Talk about your roles. >> Yeah, I've had sort of a varied career. I started off as just a computer 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, sort of the ops guy and the build and release guy for the log in and registration team at Yahoo, so I learned how to, went from being just a coder to being somebody who know 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 you know, 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 you know, was there for >> And it was highly, >> About three years >> high growth, Farmville >> Huge growth >> Took off like a rocket ship. >> Yeah, you know, over the 10 quarters I worked on the game we had over a billion dollars in revenue and that was, you know, the Zynga IPO'd 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, you know, at one point, I was in charge of both a pre-paid platform and American Express's traveler's checks platform, believe it or not, a thing that still exists. Although it's not heavily used any more. And you know, finally, I went to Express Scripts, where I spent the last three years as the CTO for that org. >> It's interesting, you've got a very unique background, because you know, you've seen the web scale, talk about bare metal Yahoo days, I mean, I remember those days vividly, you know, dealing with database schemas, I mean certainly the scale of Yahoo front page, never mind the different services that they had, which by the way, silo-like, they had databases >> Very, oh totally >> So building a registration and identity system must've been like, really stitching together a core part of Yahoo, I mean, what a Herculean task that must've been. >> Yeah, it was a lot of fun. I learned a lot, you know, we, it was my first experience in figuring out how to deal with security around the web. You know, 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 has run into trouble around that in subsequent years, but it was definitely a big learning experience, being involved in you know, the development of the OAuth 2.0 spec and all of that, I was sort of sitting there advising the folks who were, you know, in the middle of that, doing all the work. >> And that became such a standard as we know, tokens, dealing with tokens and SAS. Really drove a lot of the SAS mobile generation that did cloud, which becomes kind of that next generation so you had, you know Web 1.0, Web 2.0, then you had the cloud era, cloud 2.0, now they're goin' DevOps and apps. I want to get your thought, and you throw crypto in there just for fun, of 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, you know, this was back to circa 1996, I think, but you know, 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 they're so much easier to access, to use, to run, operate, all of those things than back in the days of Yahoozle, UDB, and it's amazing just to see how far we've come. >> Phil, I want to get your thoughts, because you know, talking about Yahoo and just your experiences and even today, at that time it was like changing the airplane's engine at 35,000 feet, it's really difficult. A lot of corporate enterprises right nhow are having that same kind of feeling with digital, and digital transformation, I'd say it's a cliche, but it is true this impact, the role of data that's playing and the just for value creation but also cybersecurity 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 this is super important. >> Yeah it is, and you know, so I had kind of a shock, moving from working my whole career here on Silicon Valley and then going to American Express, which you know, is very similar in a lot of ways to Express Scripts, and the sort of corporate mindset around, "What is technology?" There is this notion that everything is IT and here in the valley, IT is you know, internal networks and laptops and those sorts of things, 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 but, to technology, to thinking about engineering as a core competency. And that's a huge change, not only for the CIO >> You're saying they did have that vision >> They had the vision, but they didn't know how to get there, so my charter coming in and you know, 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, you know, that's dependent on third parties to tell you the right thing or the wrong thing, you know 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 side. You know, that's sort of the mindset in many old school companies, right? That needs, that I think needs to change. 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 if software's eating the world, data's the tsunami that's coming in and going to take out the beach and the people there. >> Right. And so it's like, all of these things, it's one thing for, you know, a forward-thinking CEO like Tim Wentworth at Express Scripts, who was responsible for bringing me and the group in, you know, 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 you know, I don't know any number of business partners who've been used to, just sort of taking a 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 that's cultural, I mean I do some of the interviews of theCUBE, I talk to leaders all the time like yourself, the theme keeps coming back, it's culture, it's process, technology, all those things you talk about, but culture is the number one issue people point to, saying, "That's the reason why "something did or didn't happen." >> Correct. >> So, you talk about throwing it over the fence, that's waterfall, so you think about the old waterfall methodology, agile, well documented, but the mindset of product thinking is a really novel concept to corporate America Not to Silicon Valley, and entrepreneurs, they got to launch a product, not roll out SAP over two years, right, or something they used to be doing. So 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, you know, transitioning our teams to Agile wasn't difficult, what was difficult was getting business partners to sort of come along and be actively engaged in that product development mindset and lifecycle and all those sorts of things. And you know, we had one partner in particular, we were migrating from a really old, really clunky customer care application that you know 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 you know, 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, so and we wanted to rebuild the application. We tried to get them to come along and say, "Okay, we're going to 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, you know 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 an agent swiveling, "I don't want to be, you know, delivering partial applications "I want the whole thing." to, "Oh my god, it works way better, "the design is much nicer, the agents seem to like it," you know, "Here are the next things we should work on, "These are the things we got wrong." They immediately pivoted, and it wasn't, 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 had just never seen the movie before, they just had no concept you could work that way. >> So this is actually interesting, 'cause what you're saying is, a new thing, foreign to the business partners, the tech team's on board, being Agile, building product, they have to, they can't just hear the feature benefits, they got to feel it. >> Yeah, they have to see it >> This seems to be the experience of success before they can move. Is that a success 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 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, 'cause 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 >> Let's talk about data-driven. We had an interview earlier this morning with another luminary here at the Mayfield 50th 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, it's critical in formulation of the next >> 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 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 but it's not some huge catastrophe. But it's also critical because 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 going to work sometimes just because you know this domain well doesn't mean that you're necessarily going to be the expert on exactly how everything is going to play out. And so you have to 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 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're, been there done that, seen multiple waves of innovation, want to bring up something to kind of get you going here. You see this classically in the old school 90s, 80s day. Product management, product people and sales people. They're always buttin' heads, you know? Product marketing, marketing people want this sales and marketing want this, product people buttin' heads, but now with Agile, the engineering focus has been the front lines. People are building 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 all about the customer-centric, customer-centric customer-centric, product-centric and sometimes if you try to put 'em 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? Seems to be a cutting edge topic >> Yeah, well, so you know, one of the last big initiatives that I worked on at Express Scripts. Express Scripts has the, to my knowledge, the largest automated home delivery pharmacy in the world. It's amazing if you walk into one of our pharmacies where 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've started getting slack in the system. 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 create a division of commoditizing this, basically white labeling your pharmacy. We called it Pharmacy as a Platform, exposing APIs to third parties who might want to come along and hey, Phil's pharmacy can now fill branded prescriptions to get sent to you in your home, right? And so that's a fantastic vision, but there's a real struggle between 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. 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 and the 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're at to the end, and we could've done any of those things, but trying to do them all at once was going to be a trainwreck. And so, you know, we stubbed our toes a couple of times along the way, but I think it just came down to 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. 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 nothing I can tell you that's going to make it work magically for you tomorrow. You have to just get this together and work in small increments to figure out how to get there. >> You got to go through spring training, you got to do the reps. >> Yep, absolutely. >> 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 buzz word 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 resources for their solution. How, what advice would you give to the startup, to the supplier, and to the customer to survive this next transition of cloud 2.0, you know and data tsunami, and all the opportunities that are coming? Because if they don't, they'll be challenged a startup goes out of business, a 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 other than don't run out of money, try to figure out how to build effectively to get you to the point where you're, you know, where you're going to win. One of my earliest, one of the earliest 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've 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, 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 the, 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 then there are the ones, like the teams I have built at AmEx and Express Scripts that really do want to 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. 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 every 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 knife. It can't do everything. >> Well now you got Signal FX, so now you can get the observability you need. >> Exactly, right? So yeah, I, 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, and some cases, one of the things that I have done with teams of mine in the past, was it with AppDynamics at Express Scripts, 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 AppDynamics in, but doing it in a way that they were accretive to what we were trying to accomplish and not just this thing that was going to solve all of our problems. >> And so that brings up the whole off-the-shelf general purpose software model that you were referring to. The old model was lean on your vendors. They're supplying you, and because you don't have the staff to do it yourself. 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, and so, you know, people are stubbing their toes left and right. 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 as long as you don't cut an artery open. >> Yeah, that's true, yeah exactly >> You don't want to bleed out, that's a cybersecurity hack >> That's true, that's true. 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 thing, so 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, which is a great example. Before you get there, you mentioned suppliers. One of the things we hear and I want to get your thoughts on, is that, a lot of CIOs and C-sos, and CBOs, or whatever title is the acronym, they're trying 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 to replatform, what does that even mean? So, we're hearing in our interviews and our discussions with partitioners, "Hey, I want to get my suppliers down, "and 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 to give motivation, I believe it. For me, I approach the problem a little 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're, you need to unwire this new thing, there's a lot of time and effort required to get rid of, you know, your old technology stack, and move to the new one, right? I've seen that especially coming from the C-Sec for Express Scripts is an amazing guy, and you know, was definitely trying to head down that path but we stubbed our toes, we ran into problems in trying to figure out, you know, how do you move from one set of networking gear to the next set? How do you deal with, you know, all of the virus protection and all the other, there's a huge variety of tools. >> So it's not just technical debt, it's disruption >> 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, >> Exactly, right? But with that technical debt, you know, there's two ways to pay down your debt. You can scrimp and save and put more money into debt principal payments as opposed to spending on other new things, or, well and/or, build productive capacity. So a huge focus for me for the engineering teams that we've built, and this is not anything new to the 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 in internal improvements so that your team is doubling productivity every year, which is something that's really possible for, you know, 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 it'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, the operating team. You're kind of bringing in and saying, we can do both. Operate with growth in mind, to 1% better approach. >> Right, 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 the you know, 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 going to "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 now I've seen that 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. It starts with the team. >> You're bringing us some core Silicon Valley ethos to 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." >> Right. >> And where this makes sense, I think is true, is that to your point about debt, A teams know how to manage it. >> Yeah. >> So this is kind of what you're getting at here. >> Right. >> You can take that same ethos, so it's the Agile enterprise. >> Yeah, it is >> 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 startin' a company. We're chief architects, you're the chief architect, I'm a coder, what are we doing? Do I code from horizontally scalable cloud, certainly cloud native, how would you think about building, we have an app in mind, all of our requirements defined, it's going to be data-centric, it's going to be game change and have community, it might have some crypto in there, who knows, but it's going to be fun. How do we scale this out to be really fast? How would you architect this? >> Yeah, well, you know, I do start in the cloud. I go to AWS or Azure or any of the offerings that are out there, and you know, 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 startin' 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 you know, I learned early on is a real problem. You should, you know >> Give an example, what that would look like. >> I've seen >> Database scale decisions done with no scale >> Correct, yeah, you know? You go off >> Let's pick this! It's the most scalable database, well we have no users yet. >> Right, you know you build the super complicated caching architecture or you know, you go design the most critical part of the system out of the gate, you know, using Assembly. You use C++ or, you use a low level language when a high level language with your three users would be just fine, right? You can get the work done in a fraction of the time. >> And get the business logic down, the IP, >> 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 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 every thing from scratch every time. I get the inclination. But it's >> It's a knee-jerk reaction to do that but you stay your course. Don't over-provision, overthink it, thus start taking steps toward the destination, the vision you want to go to, and get better, operate >> Solve the problem you have when it shows up. >> So growth mindset, execute, solve the problems when they're there. >> Right, and initially the problem that you have is finding a market, you know, not building the greatest platform in the world, right? >> Find a market, exactly. >> Right? >> Phil, thanks for taking the time >> Thank you very much, appreciate it. >> Appreciate the insights. Hey, we're here for the People First, Mayfield's 50th celebration, 50 years in business. It's a CUBE co-production, I'm John Furrier, thanks for watching >> Thanks John. (outro music)