Selling your product to large enterprises is no easy feat and it’s imperative that you build an enterprise-specific strategy. In my most recent talk at Prisma Day 2019, I shared my perspective on what sales strategies I’ve seen work with enterprise buyers. In doing so, I hope to help companies define a path forward to help give their next-generation software a seat at the table in today’s complex enterprise environment.
I’ve found that when you break everything down into a series of small steps, the path to enterprise adoption becomes more clear and achievable.
Steps To Success:
- Create as little disruption as possible, even at the expense of 100% optimization
- Get buy-in with all levels in an organization
- Be personal, be an ally, be a friend
- Build allies within the org and subgroups
- Sell to the executive team in their terms
- Get everyone excited!
Transcript
[00:05] Good afternoon everybody. I know it’s late in the day, so I’m going to try to keep this upbeat. This is a different kind of talk, as Peter mentioned, and we’re going to take a little break from the hardcore coding, and we’re going to talk about strategy. Now, you may be looking at this going, “Well, maybe I work in the enterprise or maybe I don’t. Maybe you hate the enterprise (like I know I have for a majority of my career) or it’s a love-hate thing.” I hope the enterprise strategies and the principles that we’re going to talk about will be relevant to you no matter what.
The reality is a lot of things live or die by what works in the enterprise.
[00:51] Look at why Oracle is still a successful company today. Look at what we saw earlier, PHP is still one of the number one languages. A lot of that’s actually due to the enterprise. So I think it’s important for all of us to pay attention to this and to work as a collective community to make sure that the enterprise stays healthy and moves in the direction that we all want to go in, which is all these great new enterprise platforms. That’s the general thesis here. We’re going to start by looking at a retrospective on the fundamentals of data access. With all of the next generation stuff we’ve talked about today, I think it’s important to understand just exactly where we’ve come from. Five years seems like a long time, but we’re really talking about 30 plus years of the modern database, and that’s a lot.
[01:39] I think it’s also important to consider when you’re trying to implement some of these new tools in terms of how do you implement a strategy to get this to market or get this up to your internal organization, there’s a lot of principles that I think could be helpful.
Pretty much no enterprise today that I’m aware of is starting from a clean sheet of paper.
Any designs we’re considering has to take into account when we’re building software tools, what’s already there in the legacy environment and sort of what is the path to actually have success? And that’s the key that we’re going to focus on, is building a strategy and a pathway to get to these things so that we can all coexist there better.
[02:16] So first a little bit about me. Who am I, and why am I here talking to you about this? I’ve had an interesting career path. I started out way back when at Google back in the early days, and I was your typical kind of CS background. I did a Masters in UX because I really felt that there was a lack of usability in terms of building things for people at that time. There still is today of course but what really opened up a door for me was the fact that I really care about users, and I really care about the success of projects more than I did about actually just writing the code. So that led me onto more of a solutions architect path and designing very large scale distributed systems.
[02:58] I worked for a variety of analytics and database companies. Most recently, I was a principal solutions architect at AWS, focusing on the strategic accounts division. So that’s basically the top five accounts by revenue. You can imagine some of the projects in there. Really, really interesting, terrible problems to solve. And I’ve always oriented this towards a go-to-market strategy. So it’s literally been billions in revenue that I’ve been a part of in terms of getting things closed, and this is everything from an early-stage startup trying to sell to a very large company like a Microsoft, or a Comcast, or a very large organization. All the way from doing these kinds of behemoth deals where it’s Amazon trying to sell to Netflix, for example, is one.
[03:49] I’ve seen a lot of permutations of how do we evolve the enterprise? Most recently, I joined a venture capital firm called Amplify Partners. It’s an interesting role. I’m not a traditional VC in the sense that I’m out sourcing deals. What I’m actually doing is helping the portfolio companies figure out how to do this. Taking very technical products, very technically oriented founders and helping them achieve go-to-market success with what should be a very successful product. So that’s just a little bit about where I’ve been and hopefully what qualifies me a little bit to talk about this.
[04:25] I wanted to start with a retrospective on data. I find this stuff fascinating. Hopefully, you do too. If you go back to 1986, which is only a couple of years into the infancy of Oracle, most people may not know this, but Oracle launched in a very, very early ’80s so it’s been around pretty much forever. You could say worldwide that we had started with 2.6 optimally compressed exabytes and you can see just how this grows nominally all the way up through 2007 where we end up with about 295 optimally compressed exabytes. It’s pretty amazing to think about in less than 30 years, and I’m not going to tell you what it is today. We’ll get to that later, but I just think it’s something to consider that the databases were created to deal with the scale in 1986, in fact, even prior to that, and there’s never actually been a clean sheet rewrite of most of these traditional RDBMS systems.
[05:19] That’s pretty staggering. It’s just staggering. I’m not sure what else to say about it other than it’s amazing it even works, and we’re not even talking about access patterns right now. We’re just talking about dealing with this much content and storage in general. So given this massive explosion in data, it would stand to reason that there’s also been an equal number of solutions on the scene to try to tackle this problem, and we’ve heard of some great ones today so there’s no surprise there. Everyone knows the big elephant in the room is like, “Why do these monolithic systems continue to be pervasive in the enterprise? Why won’t they go away? What are some of the nuances that keep them sticky today more so than just how they got in the first place?”
[06:00] This isn’t going to be a talk about how they became successful, but I think it’s interesting to look at what caused this to come about in the first place. And that is the way you developed applications 20 or even 15 years ago was very different than it is today. You actually wanted to push things like stored procedures, business logic, and a lot of computational workloads to the database layer, because you actually had a very limited amount of resources to your disposal at the application layer. And these were purpose-built systems at the time that could actually do things like that very effectively. And today that doesn’t really make a whole lot of sense in the modern application world. Yet, we’ve got billions and billions of lines of code that are floating around here, and we’re basically stuck with a lot of these things, and the original people that wrote the code aren’t even around anymore to guide us through why did we write it this way?
[06:51] I’m sure all of you have felt that pain before. Even if you wrote the code three years ago, you probably don’t remember what it does. I know I’m guilty of this on many levels. We’re definitely battling on a number of fronts here. So let’s fast forward to today. I mentioned before I was going to revisit this, but if you want to visualize the amount of data that we have in the world today, we have to start thinking about zettabytes. And again, in my past, I’ve done exabyte scale things before with storage and with databases so I always thought that was kind of big, but try to wrap your head around a zettabyte.
[07:33] Today, we have estimated approximately 2-3 zettabytes of data captured optimally stored in the world today.
And to put this into perspective, if every brick in the Great Wall of China were one gigabyte of data, you would could build 750 entire great walls with that much data.
It’s nice sometimes to have a physical manifestation of just how big that is. Now comparably, when Oracle came on the scene, you didn’t have enough bricks to build a garden in your backyard for a retaining wall. So to think about how incredibly massive that is. And, again, no clean sheet rewrites here. So we’re constantly reworking, retooling, re-shifting things to try to make this thing work. It’s pretty amazing actually how that went down.
08:26 To keep these things running today in the modern enterprise, there are the unsung heroes of the data center and of the operations department. You’ve got SREs, you’ve got developers, you’ve got operations people, and really any amount of duct tape and string and whatever it takes to keep the plane flying on a daily basis. These are some of the most critical business apps that these enterprises run. And I’ve talked to many of you, even today, just casually over coffee. It’s this constant state of like, “Let’s see if we can make the Ops team more efficient and just get rid of people and keep the same amount of work.” So the problem’s compounding, trying to keep what you have working. It’s not getting better.
09:07 And on top of that you’re trying to think, “Well, geez, how do I get myself out of this situation?”
We ultimately want to get to a place where everybody’s happy, and we can all enjoy the fruits of the new technology, but we seem to be going backwards almost, and this is pretty ubiquitous.
One thing I do want to mention is when I say enterprise companies; I know for me the first thing that comes to mind is banks and these old school kind of curmudgeonly massive multinational companies. But I’m actually also talking about a lot of companies that you would think of as innovators that are just very large companies. I won’t name any specific names, but realize that this is not a thing that’s unique to just the really old school companies.
[09:47] Even things that were written 5 and 10 years ago are massively out of date right now, and you think about your average life cycle, especially of a Silicon Valley engineer. Most people are working in the role for maybe 3 years at a time. So you’re talking about two entire cycles of people that have moved on since that code was written. Let alone things that go back. So, and like I said before, the uptime perspective, these tend to be business critical applications. So you can’t just go in there and start monkeying around with things and swapping stuff out. It’s a real mess of a problem. I think we’ve all felt that. So it’s really a perfect storm of problems. So I think we all pretty much can probably agree that that’s true. So what do we do with that other than just kind of say, Well, they shouldn’t have done it that way. We’ll just rewrite it. It’ll be a little bit painful.”
[10:33] But the reality is that that doesn’t play very well when you get to the, especially when you get to the executive level and you need to get buy-in from folks that are up the chain, surprisingly. And in case you haven’t noticed, Oracle and IBM have taken note of this, and it’s created a very nice vendor lock-in to the point where they’ve actually even stopped pretending that they’re doing this to be a good partner. It’s literally just now, “We know you have to use this. This is what you’re going to pay for it.” So even more so CFOs, CIOs, and CTOs are incredibly motivated to try and get out from underneath this stuff for all the reasons we mentioned and more. But again, they’re also equal parts terrified because like, “how do I do this without breaking everything?”
[11:12] And I think the one thing that I don’t think people think far enough down and really think big about is, “how do I fix the problem for today?” In other words, of course, we want to use this great new database, we want to have all this ability to be flexible and use different sources, but what about five years from now and this happens again? What’s the guarantee that if I do this clean sheet rewrite and I really go in and I modify the application code, and I retrain all my SREs, and I get all the developers flipped over by the time I get done with that I’m actually back at where I started because everything’s now obsolete again, right? Because we’re now five years and there’s some other whizzbang thing that we need to use.
[11:49] So that’s sort of what I’ve noticed across all of the companies I’ve worked with is this trend that they sort of are like “until somebody shows me a path that gives me essentially a future-proofing or at least a plan that attempts to do that, there’s no action taken.” This is what handcuffs a lot of the really complicated environments that I’ve seen. And what we’ve been able to do to unblock those things and really unlock some of the very, very large shifts to whether it’s cloud computing, modern databases, you name it. This is the common thread that I’ve seen that unlocks the potential here. So this is really about telling a story. It’s about de-risking, and it’s about thinking much bigger than just what’s the next generational upgrade that we need to do.
[12:29] So in other words, how can we future proof this thing?
It’s about dividing things cleanly into phases. It’s about making a plan that’s very concise and clear, and that involves all the stakeholders that you actually need to get on board and some of those things aren’t always super clear.
And the same logic even applies today for the semi-modern enterprise. People that actually have adopted things like Node, GraphQL and Rest. Again, they are still running into the same thing because these dev teams tend to innovate even faster and they want to go even faster than the slower companies can go. So again, they’re getting outstripped. They’re running into the same types of problems even when it’s not that. They want to run specialized tools, and they want to have the custom data stores and all the nice things that we’re talking about today. But again, they have the same problem because they’re running into not being able to move quickly enough. So this is pretty much ubiquitous across every company that’s not a startup with a very, very small number of people, at least in my experience.
[13:22] So, again, how do we move quickly without locking ourselves out of future decisions, and how do we make it so all of these things can coexist? That’s really the question that we have to answer each and every time we’re doing this with a new technology. So we obviously know today that technology exists that can solve the immediate needs with best of breed tooling, but it also provides capabilities such that in the future we reserve the right to make some of these changes. And Prisma is a great example of something where I don’t think a lot of people really think about Prisma as a tool that unlocks this for the future, but it really is. In the sense that if you’re taking an abstraction layer and you’re giving yourself the ability to essentially interchange databases underneath the covers, that is a really, really powerful thing to tell to a CSO, CTO, or CIO in a sense that, look, it’s pretty much a guarantee that we don’t know what’s going to happen in the future, let alone five years from now. But what we have done here is we’ve given ourselves a way where if we want to make an application code change there’s a pretty good possibility that changing out the lower layers later is actually going to be a possibility.
[14:29] And that’s pretty exciting when you think about it. It really will light them up in the sense that, “Wow, this might actually be a good investment from a long-term perspective to give me to not only make everybody happy today but also achieve all my leadership goals. My developer team is going to be happy, you know, my business process because we’re cognizant of the present as well as the future.” And it’s obviously easier said than done to do this. This is why a go-to-market strategy is difficult, but again, thinking about incremental adoption path here is key.
[15:01] You need to think about time. You have to think about who’s going to be involved and for how long for each and every step. You’ve got to think about licensing. Are we buying a new product that we’re running the old one at the same time? The CFO’s likely already very upset that we’re paying too much for whatever database “X” is today. How are we going to make that work? There are very novel things you can do here. For example, let’s say we’re keeping Oracle around because we need stored procedures and business logic that we don’t have time to rewrite. Well, I’m going to bet that at least half of that database doesn’t actually use those things. It’s used for other things. By writing a middleware layer that can talk to multiple sources we can actually offload a huge amount of the stuff from the legacy database onto something new, and yet still keep the legacy database around as well for the things that we can’t get out from underneath.
[15:47] Now you think about that. If I can cut my legacy bill in half, I’ve made a lot of people extremely happy, and I’ve also opened up huge amounts of bandwidth, and dollars, and people’s time to get the things that I want installed in the environment. And this is exactly the sort of thing that, again, when you want to talk about what’s the same between a hundred thousand dollars spend and somebody that wants to do a billion dollar multi-year contract.
This is the common thread. It is you have to make the money. You have to make money appear essentially. So you’ve got to be smart about what you’re doing today.
It can’t be like, “Oh, five years from now, after you complete this migration, you’re going to save all this money.” It’s not going to fly, and people have tried this, and it does work sometimes, but if you want to sure thing, this is it. You’ve got to be able to tell the story about how we get there today.
[16:33] Now the other thing is, these are just a couple of considerations when you’re going to the executive staff.
The enterprise buying criteria is multifaceted. So you do have to get buy-in from a whole lot of different groups. And so you have to consider, you want to insulate all the teams. They’re all looking to be insulated from a certain subset of class of problems, right? If it’s SRE, they just want something that works better so they’re not getting woken up on the weekends. If it’s the CFO, obviously they care about money, period. They just want everything to cost less and get me there and make me look good on the board meeting. If it’s the developers themselves, they want best of breed tooling.
Think about how do I isolate each of these independent teams making them work as one but also addressing each of their needs independently?
[17:19] So you know, you’re giving them open source, you’re giving them a glide path where they’re not stuck on a single platform. Your API of everything so that we can now have the ability to interconnect things that never had the capability to do that before. But how we get there is actually by inserting our additional components into things that they already want. So I always like to say find out what the problem that this team cares about most is and make sure you’re solving that problem. Regardless if it has anything to do with the product you’re positioning the platform at all. This is key because let’s say for example, that this particular Dev team is moving to Kubernetes. They want to start running Envoy for networking. They’ve got a new data layer that’s coming in. Figure out how to massage your strategy for the tooling and for the middleware, for whatever it might be into that. Help them unlock that faster. Here’s why this thing enables you to get to Kubernetes faster because we rewrite this application code once. It’s easier to ship this way. Whatever the reasoning might be, but package it into a problem that they have already identified that they want to solve.
[18:20] Because what you immediately get is, excuse me, is buy-in. Quite frankly. Obviously if you’re there saying, “I understand your problems. I’ve taken the time to actually sit down and note what it is that your team wants and why this is important. And I’m going to get you there faster because I’m actually giving you a faster and easier path to do it.” They now have your back and guess what? If you go and replicate that model, you go to SREs and you say, “Hey, basically if I’m going to help you guys basically make this thing more reliable. And yes, it’s going to cost a little bit up front and you’re going to have to sort of give me a little bit of extra cycles to help do this. But in the long run, this is going to make things way more reliable and it’s going to be a very tangible amount of effort upfront.” You’re likely to get their support.
[19:06] So you know, again,
- Don’t fight too many battles. You don’t want to be Napoleon here. Don’t open up too many war fronts. You’ve got to get everybody allied before you go and make your big push to get up to the executive team. So the general learnings I’d like to share is
- Be personable. Really understand what each of these people want and what they fear, and what they really need to get their heads around and individually tackle those problems behind the scenes first.
- People are much stronger in groups and they tend to take risks as groups not as individuals. So keep that in mind. This doesn’t have to be you carrying the torch for the whole organization on behalf of everybody. It isn’t going to happen, especially in a big organization. And by the way, this goes for whether or not you’re building a product that you’re going to eventually sell to the enterprise or if you work in an enterprise and you’re trying to get something promoted up internally. They are essentially one in the same. The way you attack this, and I’ve been on both sides so I’ve seen that go down. So again, yeah, think about the multi fronts here. Consolidate everything down to a single front so that you’re all marching to the same beat there.
[20:09] So, just in conclusion, it’s very, very difficult from a multi-department perspective, but I think if you take some of the things we’ve talked about here today.
You break everything down into a series of small problems and small steps as opposed to this giant war. This is really going to get you the results you want.
So again, simultaneously you really have to do two things well.
(1) You need to understand the difficulties in running and evolving the environments, and;
(2) you also have to promote the future and draw the entire path start to finish for how everyone gets there. And I can tell you that if you do that properly and you get everyone’s support, you will have success in this space.
[20:46] So the executive team is the exact same thing. We want to again, expose that this isn’t going to be super disruptive. They’re okay with a little disruption. They’re not crazy and think that everything has to be free, but they need it to be tangible and quite frankly, when they see some of these new platforms and technologies it’s not always clear to them what problem is this solving that I have today? I don’t care about three years from now. I need things done now. So you need to position it in their world to solve that and then work backward.
Start with your manager. A lot of people forget the basics but talk to the people on your team. Talk to your manager, get their support first, and move forward as a unit, right? It’s kind of like if you’re playing a strategy game you want to conquer one step at a time here. You can’t go too fast. Don’t discount getting everyone to do a shared vision at your level.
[21:32] And expect them to be extremely gun shy. Expect them to be skeptical at first. Don’t be discouraged and don’t take that as a sign that you’re going down the wrong path. It’s just that you need to spend the time to really bring them along with you, and I think this is something that especially for developers is very frustrating for us because we already know we have the right answer, right? It’s obvious to us and it takes a long time to bring everybody else with you, but don’t discount the value of doing that. It’s very, very important. So again, start with a vision of the future and work backwards. Really get them excited about the vision and bring them along with you, and you’ll really be surprised at how this works.
[22:08] And be prepared to show them you’ve considered the negatives. This is another one where you don’t want oversell, don’t talk about what the positives are, also tell them what’s going to be terrible about this. There’s going to be pain, there’s going to be suffering, someone will go down and we’ll get screamed at by someone three levels up. It’s going to happen. So just figure out where those problems are going to be now and let’s get there first. And the confidence that you will give to the people around you that you’ve actually considered their needs and you know what’s going on, it’s going to be exponentially higher. They’re going to trust you and that’s what’s really key here.
[22:38] So I’ll leave it there. This is meant to be a conversation starter more than anything else. So it’s something I love talking about. I hope you will think about this a little bit and see how this may wrap into your worlds, wherever that might be. And if it’s something you want to continue talking about, I’ll be here at the barbecue as well, and would love to pick it up with you later on. So thanks again for your time today.