Ep. #1, Delivering Software That Enterprises Love with Chef’s Adam Jacob

Grant Miller: Great. Adam, thanks for joining us.

Adam Jacob: Thanks for having me.

Grant: Really excited to talk to you and dive into some of these conversations. You and I have had a lot of conversations over the last few years about enterprise features and how to build enterprise software. And I really looked up to you as one of my mentors.

What I'd love to do is just dive in and understand a little bit about your background as an enterprise software guy.

Adam: Sure. Let's see. My background as an enterprise software guy. I am the CTO and co-founder of Chef, and Chef is configuration management software, in case you don't know. I've spent the last 10 years building that software and building that company, and the people who use it most and love it most are the large enterprise.

Before that I was a systems administrator, and I ran both customer-facing sites and web technology in that web 1.0 era bumping up against the web 2.0 era, if that dates me too much to talk about web 2.0. Do people think about web 2.0 anymore?

Grant: Yeah, it's still a thing.

Adam: It's probably web 3.5 now or whatever. But I spent a lot of time in the enterprise doing internal corporate-facing work. I ran corporate infrastructure and I did identity management and meta directories, if people remember meta directories, and a lot of that stuff. I built automated systems for assigning desks and phones, and all of that stuff.

Grant: You were the IT admin.

Adam: Yes, I was the IT admin, but I was building the automation systems that let you run 3 or 4 or 5,000-person enterprises and thinking about all the corporate infrastructure. It's a mix of the web-facing stuff and corporate-facing infrastructure.

Grant: Tell the quick story of how Chef evolved out of a consulting group that you were doing. Tell that story about how it evolved, and then started to get adoption, and how eventually enterprises started to use it and pay you money.

Adam: Yeah, for sure. We started out, like I said I was a systems administrator and the people that I worked for didn't care too much about me. There were a couple of moments where it made it clear that I was doing a lot of really good work for people who just didn't value the work that I was doing at all.

So I called my buddy, Nathan Haneysmith, and said "I work for these people who don't care about me. You work for IBM and they don't really care about you either. How about we quit our jobs and we'll go be consultants? And what we'll do is we'll build automation for startups."

This was in the birth of EC2. EC2 was brand new and Puppet was a big deal, starting to become a big deal. What we decided we would do is we would do fully-automated infrastructure for startups. You could pay us a flat fee and we would automate everything. Obviously we did configuration management, but we would do identity, app deployment, monitoring and trending, logging, metrics--

Grant: With a focus on startups?

Adam: Yeah, with a focus on startups. At the time this was the dawn of Facebook apps. iLike was one of our very first customers, Avvo who just now exited. They are a legal startup where they would connect you with a lawyer, which was their thing. Zoosk which did online dating on Facebook, if you remember Zoosk.

They would pay us a flat fee that was pretty large, and that would cover the initial automation. The goal was that we would just be really great at that first pass, and then you would pay us a retainer like lawyers to just maintain the automation, and we would get all this economy of scale out of maintaining all this automation for all of these customers.

What we learned was that any individual customer we had was happy with the automation because it worked for them, but they didn't care at all obviously about whatever the generic thing was that was going to let you manage all the rest of your customers.

They had their problem, they wanted that thing solved, and then they moved on. The technology we were using just didn't work so it wasn't as fun as we hoped it would be, and we weren't getting the economies of scales we wanted. We could do it really fast. The fastest we ever automated an organization was 24 hours from signed contract to, "We completely automated everything they did end-to-end," was a day.

Grant: Wow.

Adam: Yeah, it was great. We were super good at it. But what happened next was we had to decide, "Are we going to keep being consultants or not?" And the real question there was, "Only if we can figure out how to make the core premise work, which is, can we get so efficient and so good at managing all this variation that it makes sense to do?"

That's when I started working on Chef. Because what I was trying to figure out was, "How do I manage not one company, but thousands of them all at once?" Which if you think about it, is a lot like the enterprise.

If you go to a big automobile manufacturer, there are 6,000, 8,000, 10,000 applications inside that organization that range from off-the-shelf stuff, Oracle and SAP to COTS applications that they bought from vendors that vendors built for them to spec, but they don't have the source code for. There's stuff they built themselves that they have source code for that they've been deploying over time. All of those things map to multiple lines of business.

If you think about GE, GE poops out a new billion dollar business every couple of years. Just like, "How about we go into wind?" Or, "Microwaves," or whatever and poof, now it's a billion dollar thing. They were the biggest consumer lending business in the world for a minute, so that initial consulting premise which started with startups, it turned out that what we were doing was building the thing that the enterprise needed to manage all of that variation of complexity.

Grant: So you were building a tool that you at your consulting firm can use to manage all these other customers that you are going to have. Then it turns out that thing that you built to manage this huge amount of scale and all these different applications at this abstracted layer, was exactly the tool that an enterprise that has a multi-national GE pooping out a new billion-dollar line of business needed to control all their different software and applications?

Adam: You got it. Yeah.

Grant: Wow, that's amazing.

Adam: But we didn't start out to do that.

Our initial thought was that the long tail of startups and those things would be where all of the attraction would be, and that the enterprise would take a long time to catch up. And the reverse happened.

The long tail happened for Chef, don't get me wrong. There's a lot of people who use Chef and are not giant companies, but the enterprise needed Chef, so they showed up very quickly. They were like, "This thing that you built--" Our initial go-to market was a hosted platform and all of those things. They were like, "This thing that you built, we want it, but we want it on prem to run GE," the metaphorical, the platonic GE. Not the specific GE.

Grant: When you develop this, obviously you built this piece of business logic that can manage all these applications, but the thing that it probably didn't do is, "Log in with LDAP and do this audit log--"

Adam: It did none of those things.

Grant: How did you first discover those requirements and figure out, "If the enterprise is going to adopt it we need to lean into some of these features." What did that process look like?

Adam: It was super ugly and deeply painful. We started out, our original business model was we were going to run a hosted service. Chef is open source, so we had an open source product and then we had a hosted service that you could pay us for that we would just run all of the Chef stuff for you.

We were a lot ahead of our time in terms of people's willingness to use a hosted service to run their configuration management, if you are a bank or if you're a GE, or anything that matters.

This was 10 years ago, 12 years ago. That was crazy a little bit, a decade ago. What they wanted was for it to be on prem. First we spent a long time saying, "We don't do that. Our business is hosted and if you want these good things then you've got to come. You must come to me. Come to the mountain."

Grant: "Come to the future."

Adam: "Join us here in the future, it's where you belong."

Grant: "Use my application that I'll host that controls all of your servers."

Adam: To give that platform credit, it made a goodly enough amount of money to get to a place where that was a problem. But it didn't make enough money, or be strong enough to convince those organizations that's what they should do.

We had a lot of contention inside the organization to figure out, "Should we offer a product to the enterprise? And if we should, in what shape? Is it on prem? Is it the open source software? Is it all open source? Is it proprietary? How much of it is proprietary, how much does not? Which features go where? Are you building a platform that could extend into multiple products, or are you building one product that targets the enterprise?

And then, how do you knock down that list of, part one is just "I built this hosted platform. Yes, there was always an open source component you could run on prem, but it wasn't very nice to run because my focus wasn't there. My focus was running this hosted platform. But now I need to take my hosted platform and I need to make it runnable in the enterprise and it needs to be easy to install, it needs to integrate with our identity systems, it needs to have things like logging and troubleshooting. It's disconnected, so I can't get the telemetry I got out of my hosted platforms. How do I deal with those problems?"

The list was really long. The way we tackled that list once we got over the internal struggle of like, "Should we at all?" Was to find those customers who were willing to engage with you. When we said we were going to do it, and then just take down that list of what their requirements were, and build to that. Over the years I've learned that there was some things there that were glorious in that, "That's a really good approach," and what you're doing is table-stakes stuff when it's just a feature you have to have in order to get it in the door.

It's fine to just show up and be like, "What gets it in the door?" "We must log to sys log," or, "Thou shalt log in with active directory," and you're like, "Great. Check. Done, active directory." You don't need to innovate, you just need to do it. In some cases, I would argue around things like installation. Things like license management, things like an entitlement, things like centralized access control, software updates.

You do need to be a little innovative. It's not enough to just ask customers what they want, because what they want is probably not what you want to deliver.

Grant: Interesting. Sounds like you basically had this product that was getting pooled from enterprises. You had it, you were offering it and your early customers were more startups, and you were doing a hosted version. You were filling this pool from the enterprise.

Adam: Yep. They were using my open source software.

Grant: They're using the open source stuff and saying--

Adam: "We want to pay you."

Grant: "We want to pay you, and we want more features that we need in order to--"

Adam: Right. "But in order to pay you, I have to run it on prem, and I need the following list of features and I need you to sell me a support contract." And we were like, "I'll sell you a support contract over here in hosted land." And they were like, "I don't want that. I want it to run in my house. I am the federal government. I am an agency that requires security clearance to speak to me."

Turns out I'm not going to use your hosted configuration management platform. It's not going to go down like that. Now, maybe it's going to go down like that now if you're AWS. They might call you up and be like, "AWS. Can I just use your hosted magical AWS sauce? If you build me one for me?" And they're like, "Sure."

Grant: Turns out it might be a bit easier to get the assurance that you need against the nearly trillion dollar company that Amazon is.

Adam: Indeed, right.

Grant: Versus how many people with Chef at this point, maybe 50 or 100?

Adam: Some 300.

Grant: Yeah, ok.

Adam: Yeah.

Grant: This is early days, I'm saying.

Adam: Oh, early days of Chef it was sub-20.

Grant: Yeah. Your 20 people are probably not going to get the same level of assurance that the team at Amazon can get.

Adam: No, not even close.

Grant: So then you have these early enterprise customers who are using your software and using it because it's open source, and that's great that they even get to use it. Now they're asking and pooling more of these features in, and you find the ones that are willing to be these design partners around, "What does the enterprise offering actually look like?" And they help list out these features, right?

Adam: Yeah. There's two things. I'm sure there's other ways to do it, but the only way I know how to do it is you find people who want what you have. They want Chef and they want configuration management, and they want to use it inside their enterprise. Your product doesn't quite match what they need, so you say to those people, "Have I got a deal for you. You'll pay me for the product, I'll make it do what it needs by sitting in your house. I will get on a plane and I will come to where you are, and I will sit in your house, and we will do this thing together.

I will stick to you like glue until this thing works on the other side. And in return, or beforehand ideally, you are going to pay me for the privilege. And if it doesn't work out you don't renew. You just stop paying me. The trick there is that it's not a services contract, it's product. You're buying the product and I'm going to come to your house and I'm going to make the product be the right thing." That worked with not just the early enterprise customers, it worked with Facebook.

We went to Facebook and I sat in Facebook's house, and I was like, "We are going to make Facebook run Chef. I'm not leaving till we're done." And through that engagement model of saying to the enterprise, "Look." Because one thing you hear all the time from the enterprise, like 100% of enterprise says to you, "We are the most hard, most unique, worst place ever in history of man. We are the most garbage town of garbage towns, we are the worst human beings and the worst software place that has ever lived."

They believe, right or wrong, that they are the most complicated and worst environment.

You hear it a hundred times over, every single one you talk to you goes, "Our firewalls are the worst firewalls that ever firewalled." And like, "No they're not. Everyone's firewall is garbage. It's the exact same view of the same proxy problem that every other company that set up a stupid proxy has." It's not unique, but everybody thinks it's unique because our suffering is always personal.

When you say to someone, "You're right. You are unique. You do have unique problems, and I'm going to sit in your house until we conquer this hill. And in return you will pay me." Usually they say yes, because the one thing that they know in their heart is that they can't solve the problem. Otherwise they would do it without you.

Grant: I find part of the challenge is just getting people to even commit to that time with you. To be like, "Yes. We'll sit down with you or have you in our house, and you can come and learn about all of our problems, and build us a software that solves it." How do you even? Do you think because you were open source that they felt like, "OK. These guys know what they're doing. They can help us get there."

Adam: Yeah. For me it was open source, and it was because the way that we grew the open source community was by being out in the world. Not talking about Chef, but instead talking about what it's to be out in the world. If you go look at the talks that I have given over the last decade, very few of them are about Chef or about Habitat. There's a handful, but I talk a lot about what it's like to do this work, what it's like to be in the enterprise. What it's like to try to transform, what it's like when you're in the big web.

What it's like to run operations at speed or at scale, and because I talk about those things that gives you the credibility to be able to talk about the technology. So when you say to someone, "I can solve this for you," they believe you. Whereas if I showed up and all I did was say, "I have this technology. You've never seen it. You don't know me. You don't trust me. You know nothing about me or anybody else." In those early product stages it is more about you than it is about the software or the business.

Later on it's about the business, like Chef doesn't need me to do that anymore. I still go give talks or whatever, but that's not how Chef gets leads, it's not how the enterprise shows up, it's not how they arrive in my house. But on day one it absolutely was.

You had to go to a conference and you had to fish for a human and be like, "What do you do?" And they were like, "I'm the blah-blah-blah at a huge oil and gas company." And you're like, "Tell me everything about oil and gas. I am so fascinated." Listen to the problem and find your way in. It's the same thing we did as consultants. It might just be that's my DNA more than it is a repeatable motion, but I think it's repeatable.

Grant: Was Jesse part of the company at this point? Was he involved?

Adam: Jesse Robbins? Yeah. Jesse Robbins was the founding CEO of Chef. So yes, Jesse came in a little later on. Jesse was running, not later on in Chef. He was there at the creation of the company.

But we started creating Chef the prototype, and as consultants we tried to recruit Jesse because he was working for O'Reilly and he had worked for Amazon, and he was starting Velocity. He had written this post about how the best in the world could automate their infrastructure. I don't remember what the timeline was, it was like three months or six months or something.

He had a fake graph that he drew that made the whole thing look really official, about how long it would take you to automate all your stuff. And John Willis, people know John Willis. DevOps person, big in Tivoli Community back in the day, back in this era who had just started looking at this newfangled automation stuff. I had just been on a podcast with him where we had told the story about that customer that we did in an hour. He commented on Jesse's blog post and was like, "Dude. These dudes in Seattle can do it in a day."

And Jesse was like, "You're lying," was what he said in this blog post. I responded, "Super not lying. We can absolutely do it in a day. Here's our website. We crushed this number that you have made up out of nowhere, sir." Then we met for coffee and we tried to recruit him to our consulting company, and he was like, "I don't want to join your stupid consulting company. If you come up with a product, give me a call."

So when we built Chef we called Jesse and we were like, "I have this product." And Jesse was the one who was like, "That's a dope product. We should take venture capital and we should build a business that does that thing." Because I was a systems administrator. No one funds Adam Jacob the day that I wrote Chef. My highest title was team lead. I'm a systems administrator, I still am really. I play all this other stuff on TV, but it was Jesse who made the company a company. It wasn't me.

Grant: What I think is interesting here is that there's really two paths by which you guys were able to get some respect in the enterprise, and get in the door, and get that ability to sit down with the team and understand their problems. Number one was you created this open source product that got adoption. Number two, really, was Jesse's background. Because Jesse, if you think about it today, Jesse came out of Amazon and had created things like GameDay and a bunch of other things.

Adam: We dined out on Jesse's resume for years.

Grant: Exactly.

Adam: I still dine out on Jesse's resume, probably. It's probably weird for Jesse every now and again.

Grant: A lot of times when you see, at least in the enterprise infrastructure and a lot of software companies, the way that they get into the room is the founders have a background from Google where they solve this problem, or from Facebook where they created a similar thing, or from one of these companies where they built the internal tool at that company and now they're going to rebuild it and take it to the rest of the world.

But it's interesting that you took both paths, because you created the open source version and you did this, and then you also got Jesse and you had the background.

It's really interesting when you think about that early go-to-market, some type of thing to get you credibility and in the door, and get people to trust you with their problem that's related your problem, is really important.

Adam: Yeah, for sure. My belief is that credibility comes from your empathy to the problem, more than it comes from-- There's a business model conversation that is really interesting about open source software and the spread approach of getting as many people to use the software as possible, and then you monetize some small subset of them in a particular way. That's an interesting and valuable conversation, but when you think about, "How do I start? How do I get to a place where I get that first enterprise customer?" My belief is that you get that customer by being out in the world, and being more involved in their problem than they are.

Being more fired up about how you're going to solve whatever the thing is than they are. I don't know that me today believes that I probably could have done it without the resume. Not that I'm glad I didn't, I love Jesse., and the reason that my entire life has been irrevocably changed is because Jesse Robbins had the grace to come into it and do what he did. Do not misunderstand me, I am so thankful that's what happened. Do I think it's possible to do that where you're more me and less Jesse? I think the answer to that in hindsight is, "Yes," the thing that's required though, and it's hard to get, is the perspective that you're good at the work.

It's just really hard to know when you can't see it, that you're in the top whatever percentile at whatever the thing is that you do out in the world. There's this weird mix of ego and hubris and a bunch of things to go to a conference or whatever, and be sitting across from the person who runs deployment or security or operations, at some fortune 3,000 or global 3,000 company and be like, "I got this. Hold my beer. Let's talk." That's just hard. So you could do it that way, you could get to a place where you could take those skills out and you could engage in an authentic way in those conversations and get people fired up about what you're doing. But it's hard.

Grant: For me, it was always that I would have the hubris to go and talk to that person and they'd be like, "Talk to Mark. Mark's my co-founder who's the incredibly smart person behind everything at Replicated, so--"

Adam: Right, yeah. "Let's talk about the details. Mark's got the details."

Grant: "We could do everything you ever need. Mark's got this."

Adam: "And Mark will write the software." Yeah. It's always easier with a buddy. There's no question that it's easier to not go alone, because there's a million hard moments. Those first customers though, and still today even with Chef. I've built more product than just Chef at Chef, and taken those things into market and it's just as hard.

Even with everything that we've built and the customers that we have, and all those things. It's just as hard to build a product, figure out what it is, show it to people, figure out whether it's the right shape, figure out how to talk to people about it and how to distill its value, what features go where. It's just hard.

Grant: Let's dive into that a little bit, because it's really interesting. Remember when we were talking, when you were building the early versions of Habitat, you showed Mark and I. You were like, "Look at this cool thing I'm building." I'm sure that was, or I'm going to guess it was a fairly similar experience to building the original version of Chef.

Adam: It's exactly the same, yeah.

Grant: Just tell that story, because it's interesting and if you think about the new product discovery, feature discovery process, and then the go-to market effort that's required to build the internal knowledge and get your team fired up about this new thing that you're building. First the other execs, and the engineers, and then however you approach that. Then marketing and sales, and then your front of the line customers. There's a whole pipeline of people you have to get aligned, and then get them to do stuff and create things and--

Adam: Believe you. Not think you're insane.

Grant: Early on there's 20 people, it's a little bit easier to line up everybody and row the same way.

Adam: Yeah, can be.

Grant: When your company is the size of Chef now, talk about that process of bringing that product to market.

Adam: The risk in product development is always in seeing that your end-to-end thing is wrong. As engineers we tend to focus on the problem in layers. We look at the bottom layer and we look at the middle, and the top. So you've got the databases and the data model and all of that stuff, and then you have the front-end and that's at the top.

Depending on which kind of engineer you are you either start with the front-end or you start with the data model, and then you build all the stuff in between. Then hopefully at the very end you show it to someone, and you're like, "Do you like my thing?" And maybe it takes you, even if you're being agile or whatever.

You're doing sprints, or whatever. The truth is you can't see the whole thing from the beginning to the end, for maybe months or years in some cases. You have no idea really, how quickly if you're on or off. With Chef and with Habitat both, the process that I went through was one where I would build a sketch of the whole thing. Later on I met a guy Jeff Patton who talks about user story mapping who has a whole process for how to do this. I didn't know that, I wish that I did. It would have been so much better, especially in trying to communicate with other people.

What you would do is you would build a working version of whatever you thought was there, as quickly as you could, and most of it was fake or not very good or not very flexible, or certainly bad. In terms of the code quality, or whatever, but you could see it work end-to-end. With Chef, there was a working version of the Chef DSL that works exactly the way that it works now, in a couple of days.

It didn't do a lot, it didn't configure anything, but you could write a little program. I showed it to my co-founders and I was like, "What if it looked this? What if it was a programming language and it looked this, and you had resources, and the syntax looked like this? Should it be a colon, or an equal sign?"

You're having those conversations about the past things that feel aesthetic, but they're really the shape of the whole thing.

And then you're like, "OK. But we need to know how to package the recipes up so that you can put it together with the ingredients, like files and all of those things." So focusing in on that end-to-end was really important. With Habitat and the benefit of hindsight, we did that again in an even more intense way. I had a working version of Habitat. Like, if you go download Habitat right now, all of the core functionality in Habitat now, I had a mockup of that you could run on the command line in a week.

It wasn't the same as what's there now, because it's had a lot of refactoring and a bunch of iteration, but I spent months tweaking it a little bit, and then I would show people. I would show you, or I would go show friends that worked at Nike, or I would show people who worked at Amazon, or I would show John Allspaw. I would show whoever was nearby.

I'd be like, "Come look at this thing I'm building. What if it worked like this? Does this thing feel this way?" What you're doing is you're de-risking whether or not the final version of what you build was right. Even though I knew that what I was building was this really complicated system, you just didn't do any of the complicated parts until you were pretty sure that it was going to feel good.

And that to me is how you think about building that product. Then when you talk about go-to market and how to convince people, at that point it's about, "How do you distill what feels good into a message someone needs to hear?" Sometimes what feels good about it, what feels good about Habitat is if you're a software developer or an operations person who's had to manage the lifecycle of your application, "How do I build my application? How do I put it in CI? How do I package it up? How do I deploy it into multiple places?

What if I need to deploy it sometimes on my laptop because I'm doing iteration locally, but I also want to deploy it to Kubernetes in production and Bare Metal sometimes too? What do I do? What's that like?" Habitat takes that whole answer and goes, "It's cool. You're just going to write a little plan, and you're going to fill in basically a flow chart, and then it pops out the other side and it works. And it feels dope."

The go-to market challenge for Habitat is, how do I distill that problem? How do I say to someone in a pithy way, "Do you have a problem about managing the lifecycle of your applications?" The answer is, "Yes." "Hold my beer. Do I have a deal for you. "What happens first there is some people will agree with you, some number won't, if it's a good idea. I've never had a good idea where some people told me that was a bad idea. It's 100% hit rate where people were like, "Some of this is garbage and you shouldn't do it."

Grant: Probably if everyone thinks it's a great idea--

Adam: It's just not interesting.

Grant: Yeah, or somebody has already built something that matters. Or it's never going to get attention because everyone's doing some version of it.

Adam: Somebody has to say to you, "This is not good." Like everyone who ran Puppet. Well, not everyone. There were a lot of people who saw what I built when I built Chef, and they were like, "I'm so glad you bought Chef. It's exactly what I want." There was a lot of other people who I thought were going to say that to me, who instead were like, "You are a horrible person. You are a bad human being for doing this work." So anyway, I think about all of that coming together and then you do a similar iteration.

You put it out in the world, and you test it, and you see what people say and how they respond, and you tweak it and change it. The trick is to understand that the refactoring of the message happens with the refactoring of the system too.

You're constantly refactoring the source code, and you're also refactoring the message. You're out in the world, you're experiencing whether it lands, whether what you said was what somebody needed to hear. Over time people get convinced.

The other thing that happens though is that some number of people never get convinced, or they start out convinced and then they lose faith. The other thing that happens is any product worth having is a product that's hard to build and takes risks in its creation. In that moment someone will lose faith between evidence that you were right, and the work to create the thing. In that moment you have to not lose faith. You have to be the one that's like, "Right or wrong this is what we're doing.

I hope it works out because all the chips are in." That's the thing that people do wrong a lot, in particular in the startup world. Because you get into the idea of a pivot where it's like, "It's not working so we'll pivot." And it's like, "What are you pivoting around precisely? Because I get it, you're pivoting, but are you pivoting because you're impatient for the evidence? In that case maybe you should just do more work than be right."

Grant: Turns out a lot of people will not like your thing, and it's going to take a while and you're going to push through and grind--

Adam: You have to refactor it, and grind.

Grant: A little different here, tweak there.

Adam: Especially if you're selling enterprise software, because you'll take it to someone and they'll be like, "I couldn't possibly use it." And you'll be like, "Why?" And they're like, "Because we use this random replacement for sudo on all our Linux boxes. You're not allowed to deploy without it."

Grant: And you're like, "That's weird."

Adam: And you're like, "I guess my idea sucks. I'll pivot to that thing." And you're like, "No. Only one person ever cared. That's not a good pivot, don't pivot."

Grant: This is great. New product you're developing, you're creating it, you're talking to people, you're getting feedback, you're iterating on what it actually does. You're doing a little hand waving in order to convince people that it does the hard things maybe it doesn't do right away, and then you're changing the message and you're delivering it further and further. Now that you have a fairly clear idea, you have Habitat and you know you're going to do it--

Adam: Clear product, and it works.

Grant: Because you're Chef and you have enterprise customers, do you instantly say, "OK. It has to meet all of the enterprise requirements."

Adam: You could try, but it won't.

Grant: Is it the same iteration cycle you did for Chef, where you were like, "I'll sit in your house--"

Adam: Yea, that's exactly what it was. And I'm still doing it. I'm going to go do it again two more times this year, I did it earlier this year. I spent three weeks in the middle of America in someone's house being like, "Let's do some Habitat, brother." We cracked it out and it was so good. There was a team of 100 people that was doing some work, and we did it in two days with Habitat, and they'd been working on it for months. Months! It felt so good, it's the best part of the job. I get on a plane, go to the place, sit in their house and do the work.

Grant: Because you have the entire spectrum of how your product works, and what it does, and all the options and how you can tweak all the things. You can go in there and show them the path forward with your thing, that may be they couldn't figure out how to get there.

Adam: They can't see.

Grant: Yeah, they can't see.

Adam: You have the value of perspective.

As an outsider, the number one thing you have is perspective.

So you bring that perspective to the customer and you're like, "Hey--"

Grant: Despite all of your documentation and everything you have that's out there, and it's open source, it's hard for anyone to really grasp the full possibilities.

Adam: Again, it comes back to the go-to market. Sometimes you build a product and it just takes off. Sometimes your Facebook or your Docker, or even maybe Chef. to be honest. Chef was Docker once, for a minute. So was Puppet, and sometimes you're that. Most of us aren't. Most of the time what we do is we build some software and there's someone who likes it, and then you're like, "I need 10 more, but who are those people? I don't where--" You got to grind it out a little. Part of doing that work is getting the references that will get you to the next level. Facebook is a good example, all the work that got put into Facebook consumed my company for a year, probably. Just doing all the things you got to do to get Facebook to run Chef.

Also, I have easily tens of millions more dollars in revenue every year because I did that work at Facebook. Easily. Not from Facebook. Facebook doesn't pay me, I mean they do pay me but they don't pay me a lot. But I got to use that logo, I got to talk about that experience and I got to talk about those customers, and those references were everything in getting to a place where you had the credibility for the next thing.

It's really just, "How can I find the first thing that gets me the next thing? How do we get the credibility to raise money for Chef, while I build Zoosk's infrastructure and iLike's infrastructure when they couldn't scale and the people that worked there couldn't figure it out and we did?" So I could take that and I could be like, "I know I'm good at this because I did it for these two people." You find the first one and you just keep pulling.

Grant: Now, what's interesting is in that story you did it once with Chef and that was obviously very successful. You're doing it again with Habitat, and that process you described is very similar. Even though the company is far bigger, there's a lot more people in the company, and product heads and VPs of everything. Then you now have access to all these enterprise customers who will try your gear right away.

Adam: It's a lot easier to find those people to become references, because I can just call up my own people who love me and be like, "Do you want to do this crazy thing?" That's a lot easier than having to go to five conferences this year and hunt.

Grant: Because now you have the network of people who trust and believe--

Adam: Yeah. I'm here on a podcast. No one wanted to hear me 10 years ago. I was a sys admin, I was a team lead. I ran a tiny consulting company with a bad logo that looked like key caps with weird colors. You didn't want to talk to me. But now you want to talk to me, because I've got all this experience and there's all this stuff, and there's all this evidence.

I have fun stories, but that all happened just from the work. It sounds dumb but I can't underscore enough how much it's really just, every single day you do more work and you're like, "OK. I'm going to do more work today than I did yesterday, and how do I get more leverage out of the work I did yesterday to do better work?"

Grant: What's interesting to me is thinking about those enterprise features, like you said, you didn't introduce all of those right away into the Habitat. You spent a little time to get the actual core product right, the core business logic right.

Adam: Because when you think about a lot of enterprises, there will be enterprises who are willing to accept your software without the enterprise features, and you need to find them. Because in order to get into the enterprise I have to be enterprise ready, well then I'm never going to get to the enterprise. Because look at role based access control, software updating, licensing. All that stuff is so complicated that without customers to tell you whether you're on the right path or the wrong path, you'll just spend forever noodling on some abstract craziness.

There's an entire book, multiple books written about the algorithm for RBAC. If everybody has to do that every time before we can ever get a piece of software in the door the first time, we're done. Could you go to one customer and be like, "OK. In order for it to work, the must-have is that you can log in through active directory." "No problem. That I can do." Do I have to go all the way to the completed framework that allows me to do policy-driven configuration for multiple IDPs? No, not at first.

Grant: That might be necessary to scale with enterprise.

Adam: Exactly, and scale different problems. The number one bad mistake I see people do all the time is premature scaling. In software development and startup land, people all the time will say, "We don't want to do it that way." And you're like, "Why not?" And they're like, "Because it won't scale." And I'm like, "Is there a horde? Are they at the gates?" And they're like, "No. We don't have any customers." And I'm like, "Then who cares. Don't worry about that. Call me when the horde is here. First find me someone who cares, and then we can talk about those problems." We use those moments to shut down the conversation and the possibilities.

So you get your 5, your 20 or however many people you have in your company, and you're talking about trying to go out and get this enterprise customer and somebody says, "It's not time to get the customer yet, because before we can get the customer we need RBAC." Then you spend another six months hoping the customer arrives, and it's a self-inflicted wound. In a similar way in the enterprise, you get the opposite.

You get the enterprise saying, "We could never possibly do whatever, because usually team FUBAR says no." A really common one would be, "We couldn't possibly run your software with auto-updates turned on because firewalls, and because the network team won't allow it." And if you ask the question to those people, "What is the name of the network person who said to your face that you're not allowed to update software in the DMZ from the internet? What's their name?"

You will get the following response, "It's not one person. It's the network team." And you're like, "I know. I hear you. Can you give me a name of a network person who would say that to my face?" And they're like, "It's the network team." And you're like, "I got you. I'm here all day. Could we just take a walk to the network team and just ask? Just say, 'Why can't we?'" And they'll be like, "We've never done that before." And then you'll go, and it turns out that person doesn't exist. They've never existed. Or they did exist, but they retired 10 years ago and we don't talk about it anymore. That happens all the time.

Most of the obstacles to your software are getting in the door for one customer, not at scale, just the one customer.

It's not an obstacle that you need to overcome, it's just you have to have enough ability to stay in the room and be, "OK. Really? We have to have it? I get that you need to, and you were shutting yourself down, but can we not shut ourselves down? Let's try to have nice things." And it tends to work.

Grant: I love that. What's interesting is, in those conversations oftentimes people are using those requests as an excuse for why they don't want to buy your software. For why they don't want to implement your thing, and if they really do want it and you're like, "OK. You want it. Let's go talk to that team."

Adam: Let's figure it out.

Grant: Either they're going to walk you over to that team, or they don't want your software.

Adam: It turns out they don't even have to. In the number of times I've done this, and I've done this a lot now. The number of times where I have actually been brought to the team is zero times, because the whole thing folds like a house of cards.

Grant: They e-mail somebody and it turns out that isn't a big deal and they can get it done this time.

Adam: Yeah. Or they knew all along that it wasn't a thing they couldn't do, but they just never questioned it. It was like, if you move into a house and the walls were a color and nobody ever mentions you could paint, you never think to yourself "Why is the room gray? I hate gray rooms." You're just like, "Gray rooms are the color of the rooms, and it's just how it is."

People, as humans we just go through our lives doing what we do. As the outsider, as the person with perspective, part of the job is just flipping the perspective for someone and being like, "What if it was like this instead of like that? If you do that enough times eventually you find someone who's like, "Yeah. You're right. The room shouldn't be gray. I do want to update software in the DMZ."

Grant: It turns out that somebody painted that wall gray at some point--

Adam: You could just paint it a different color. You could do whatever you want. This whole thing, even though you work for a company that was started by Thomas Edison, it turns out they built it. Human beings, just like you, just doing stuff every day.

Grant: Made decisions the whole way.

Adam: They Just made decisions. We could make new ones.

Grant: It turns out you have a lot more information today than they ever did.

Adam: You have all of their aggregate perspective built up over all of this history, and all we have to do is fun stuff. Just come on the fun stuff journey, especially in that early product phase. I have found that to be very effective. Because when you just go to people and you're like, "Is my problem your problem? If it is, let's be dope together. Let's just be awesome together." Very few people are like, "Nah."

Grant: It also matters if the thing you're suggesting is rational.

Adam: It has to be good. It has to work.

Grant: If the thing you're suggesting is a really bad decision--

Adam: Then that's not going to work.

Grant: It obviously violates and it's like, "No. We don't actually want to send all of our customer data to your three person team. That turns out is a bad idea for us."

Adam: Not all customers are created equal. That same conversation, you don't have that conversation with the folks at Facebook that way. Because they'll be like, "We're Facebook." And then you're out. So at Facebook you have to be like, "OK. Tell me more about Facebook."

Grant: "Tell me about what I can do to get this in here."

Adam: "Tell me more about your scale problems. Tell me more about the way your infrastructure works, and then let me map that to how my stuff works and figure out if I can help you solve your problem." Sometimes it's not so much you telling someone how to better solve their problem, because you're not.

Sometimes it's you literally being like, "I just need more of your DNA to understand what to do."

Grant: I like this. So there's one part, which is get in the door and sit with the customer to really understand the business problem and how you can solve it. Create something that will be a story that you can tell and deliver to everyone else. Then the next part is, OK, now once you have this great thing that everybody wants you need to figure out what rules can be broken and what things can help you if you embrace them. You pushed back on that DMZ thing and they said, "No. That is a requirement. It's going to be a hard requirement at every other bank you work with." So you note that then as a--

Adam: Got to go do it. It was just table stakes now. A good example is, if you want to sell to the federal government at some point, the US federal government. At some point you will need to do air gaps, because there are actual air gaps where a guy or a lady takes a USB drive or a CD-ROM or a DVD or whatever, and they go through a trap with gas in the ceiling and guns and they put it on a network that's not connected to the world. It's just what happens. You could try all day long to convince them that they should change their perspective, but also, they're not changing their perspective.

Grant: Describe what an air gap network is. That's a great description of how you get software in there, but why would someone run an air gap network? What's the point?

Adam: Sure. Because what you're doing is it's a hard security barrier. You're saying that, "We'll do physical security and maybe even digital security on the media that you walk through to ensure that what goes inside of the air gap system is what we want, and nothing we don't."

Grant: That way you have access to all this compute, and all this storage, but you don't have to have it--

Adam: You could never talk to the internet. Not just the internet, you could never talk to another system that's outside the air gap. Sometimes you would see those systems on closed systems on a car, if you're building a hardened car that would be good to have a network that isn't connected to a network, for example.

Grant: Sure.

Adam: But a good example would be if you're a three-letter government agency that investigates crime or does intelligence gathering, or whatever. You would probably have an air gap.

Grant: It's hard to access your multi-tenant SaaS application from that.

Adam: It's impossible. It's impossible to access your multi-tenant SaaS application. Even in those air gap things. A good example of some of the difficult problems you face in enterprise software is that it's easy to get led into a trap that tells you that what that means is that the enterprise will take whatever version of the software they take, and they'll hold it forever. Like, "I'm going to run version 1 forever because it's inside the air gap."

But that's terrible both for the customer and for you, because you can't move them forward and it's not sticky. Eventually they'll hate your product and you'll be like, "If you just upgrade to the new one it would be better." And they're like, "I can't upgrade to the new one because it's too hard."

You just wind up in this ouroboros loop of hurt.

Instead you have to think about a problem like, "How do I install software as a user-facing problem? A customer-facing problem where you say, "What's the experience I would need all of the users of my software in the enterprise to have? That would make them feel like this software is the best software that they've ever touched?"

One good example there would be anytime they upgrade your software it will work, no matter what version of your software they started out with. I don't know what the timing is of the person with the DVD walking through the air gap, what I know is it went through one time and got working because it's still there. And I know that somebody else, someday hopefully, God-willing, will go through that same man trap in order to put my software on that network again.

When that happens it should just work, and if it doesn't just work it's going to be really hard to fix. Because the odds that anybody who works for you can go through that man trap are remarkably low. We're in California where weed is legal. So, "I don't know. Do you have a security clearance? Do you live in California? Did you put weed in your face? If so, you don't have security clearance anymore or you lied, at which point you shouldn't have security clearance."

So, "Which person who works for your company can walk through the little thing?" And you're like, "No one." The answer is nobody, and it's like you're fixing it through a straw. So, the choices you have there and often what happens is you're making a decision between the customer's comfort and your engineering difficulty.

It's much harder to build a system that can always be upgraded forever in place, than it is to say that you have major versions that break the installation process. As soon as you say you can break the installation process, as an engineer you're like, "Whew. I won't to have to go through this hard refactor, I'll just build a new one and be like, 'Sorry. It's a new upgrade. We'll do a data migration.'"

And so, "Fine. Great. Makes sense." But once you get to a place where you have those customers with that shape, it doesn't work anymore and it turns out that it's also a better user experience, because everybody wants to update the software.

What that also implies is that you're updating more frequently, because it's safe to update, because it has to be safe to update. Because if it wasn't safe to update the bad update would ruin the air gap. So, it has to always be safe to update and it can never break, so we have to do it all the time. We have to deploy to our enterprise customers not once every year, but every day.

Some number of them won't and some will, but you've got to build it that way. Because if you don't then it's worse for your customers and it's worse for you. There's a bunch of those interesting little traps hiding in enterprise software development.

Grant: Do you let your end customer decide when they update? Do you have a window of support that you'll offer them for, "If you have one of the last three versions, we'll support it, but you got to upgrade to one of the last three versions if you want to get support." How do you contract that out?

Adam: For me, I would just say that you support any version of the product that has ever existed to the latest. What I would never let you do is jump to a version of your choice. You can go from wherever you are to whatever the goods is, the new stuff. But there's no moment where you get to say, "No I want to install version 5572, not 5573. You're like, "Nope. We've moved on. We're in 5573 land now.

You can choose what day, you can pick that today is the day that we're going to update the software," which means that in practice of course they might get 5572 because they burned it on a DVD and they had to walk it through the thing and we vetted it, fine. There's always an exception to the rule, but conceptually you always want to move for that. Which also, in contract land is simpler. What you say is, "Great. As long as this is software I continue to support at all, then I will continue to ship you updates.”

Grant: What are some other features and challenges that you think that as an earlier stage enterprise software company, that I'm coming to market, what are the things that I'm going to stumble on? What am I going to hit that you're like, "Watch out for that feature, or that request, or that piece."

Adam: Definitely software updating.

It's a moment where your customers will be wrong.

What they'll tell you is everything I just said was garbage and they want you to do none of it. What the customer will say if you ask them is, "We want to vet a specific version and keep it forever and move when we want." That's what they'll say. But the answer to that is, "No. It's a worse experience for the customer, it's worse for you. Don't do it."

Role based access control is another, they'll want to be able to set rules about who can do what with your software and how. They'll want that to integrate with their existing systems of record about the identity of the people who are doing it, or the groups that they're allowing, or those things. You're going to hit that.

Grant: How do you implement that? Do you think about every CRUD action that can be taken in implementing a check, to see if they have the permission to do that create, or that update--?

Adam: It really depends on the application. It's hard to say at the level of every crud endpoint or whatever. You can do that, and that might be the right thing to do. Depends on the product. I think it's important, especially with stuff like access control, to think about one of the rare moments where the primitive matters.

Where thinking about, "What is the unit of control? What are the actors in my system, what are the things those actors can do to other things or to themselves? Who's allowed to make those changes? Understanding the landscape of what people can express is a deep requirement of building the right system. Because it may turn out that you don't actually want classic role-based access control.

This is another case of if you go to the enterprise and you ask for the feature, what they'll say is, "I want a role based access control," and there's a book and you can buy it, and in there is the algorithm for role based access control. You'd be like, "That looks hard." And it is, but you might also be able to just do IAM. You might be able to do a completely different model that's much more flexible about the definition of actors and what they can do in granting permissions and controls.

But if you ask the customer, "Will you accept an IAM system or an RBAC system?" They'll be like, "I want RBAC." And you'll be like, "Why?" And they'll be like, "Because that's what enterprise ready software does. It has RBAC. So, there's a trap you get into. You have to provide the functionality, the way for someone to express the control. But you don't necessarily have to tie your implementation to their desires.

Grant: Can you just dive a little bit into the nuance and the difference between IAM and RBAC?

Adam: Sure. In a traditional RBAC system you would express, and you'd have some actor that's going to take an action on some object, and I'm going to vet those things. Then I put those actors into roles, so I say "These are all the people who are administrators." And then I can assign that role to an object and some actions, so I can say "These people can do this with these things," and then maybe I build groups of those objects that I can take actions upon. Then I'm using and I'm saying that by giving you access to the role in the role based access control, now that role grants you privileges across whatever thing you want to go through.

The difference between that and something like IAM is mostly the interface. If you think about how you define what an object is, IAM would build a URI. An identifier that is the string of a computer that is an EC2 that's running in the US East 1, that's medium that's tagged "Poopy pants," or whatever. And that's the identifier of my object.

When I write a rule to check it, all the rules express is that identifier. So if I wanted to write a rule that was, "All servers and data center, foo, Grant has access to." All I would have to do is say, "data center: foo splat." Then everything that matches the string after that you have access to.

I didn't have to know in advance what the things were that I was going to talk about. I had a flexible rules engine that would take an arbitrary set of data and apply a yes or no answer to that arbitrary thing, whereas in classic role based access control you know what every object is and you define rules for each of the things you knew about in advance. Whereas in IAM, I don't know what they were and I'm just building you this string that I can do crazy matching and stuff on, and pop out the other side with yes or no questions.

Grant: So, in role based access control, how do you introduce new objects?

Adam: It's a new actor type. You could think of it as a new type in a type system. Each one's distinct, and a little heavy weight to add.

Grant: Then there's some type of default that you roll out, and your customers--

Adam: Right. You're like, "Here is the default set of rules that apply to these kinds of objects." "Exactly."

Grant: And you, as an end customer, can't pre-define what your defaults would be based on a similar--?

Adam: Maybe you could, but now you can think about how complex a role based access control system is. Because if I allow you to create the generic thing that I get out of IAM, now I have to provide an interface that allows a customer to find a new object type, which then defines the new actions that that can happen. It gets really heavy weight, whereas in IAM it's just like, "I don't know. Give me a URN for the object and a URN for the actor, and I can pattern match on those things and then I'll give you a yes or no answer."

Grant: Is there some type of regular expression that's used in that integration--?

Adam: Yeah exactly. AWS used IAM, for example.

Grant: That's another thing too, which is really important. When I ended up working with Mark to build features in Replicated and for our previous company that were enterprise features.

A lot of what we did was we spent time looking at other applications that we thought did a great job of implementing role based access control or audit logging.

So one, do you draw inspiration in the same way but when you see that Google did this amazingly great version of an audit log, "I should copy that and make sure that--"

Adam: Absolutely. Yeah. Relentlessly, and especially for stuff like that where I leave the product concept of a delighter. A delighter is when there's a feature that exists that you never would have asked for, but once you have it you'll never give it up.

One good one for me was in GitHub, as soon as I realized I could put a cat picture as a response to a code review request, I was in for life. I'm never going to use a system that doesn't allow me to do that. Gerrit I enjoy much more objectively as a code review system than GitHub, I would much rather use Gerrit. I'm in the minority but it's real for me, except no cat pictures in Gerrit.

I'm not allowed to do cat pictures because it's serious business over in Gerrit land. Even though I prefer Gerrit's workflow and everything about it, I will never use Gerrit because I need that cat picture, and that is a delighter. You could have interviewed me till I died and been like, "What's the feature we should add to code review?"

I would have come up with everything except cat pictures. That's a delighter. For me when I'm looking at a lot of those systems, there's the table stakes thing. It's just like, "Can you do access control? RBAC, IAM, who cares, whatever it is. Do you have one? If the answer is yes, then checkbox ticked."

Grant: Don't you think there can be a delighter in how you implement that? Like, if it's sexy?

Adam: It could be a delighter, it could be beautiful. So then it's like, "OK. What would make it beautiful? What would make it a delighter?" I'm always on the look out for that. I'm always on the lookout for the, "It was this piece that made this experience worth having." I find those sometimes in some other software, you can find them in lots of other places in your life too. Sometimes non-delighters can give you good ideas about what never to do.

Grant: Like waiting in line without any awareness around how long it's going to take.

Adam: Sure, that's a good example. The most recent one, Amazon got into health care and I went to the doctor. Every time I go to the doctor I get the same letter from Aetna, and the letter says, "Could you fill out this piece of paper and mail it back to me to confirm that you haven't gotten other insurance between the last time you went to the doctor and now?" And I'm like, "No. I'm never filling that fucking piece of paper out. I'm never going to do it. You sent me a self-addressed stamped envelope and I'm still not going to do it. No desire to do it." You know what company will never send me a self-addressed stamped envelope to double check that I don't have insurance coverage from somewhere else?

Amazon.com. Never, ever. They're never going to do it. And Aetna will be stunned. They'll be like, "But our doctor network is bigger, everything is better." And people will be like, "Why would you want Amazon.com for health care?" And the answer is, "I'm never going to fill out that fucking piece of paper." That's it. That's all it is. And it's that simple little delighter, they will remove that tiny little stupid thing and they will disrupt a trillion dollar market. And they'll be like, "Oh my God they're so smart." And it's like, "Nah. They just hate fucking letters. So do you."

Grant: Take out the little things that just annoy and terrify you about all the worst things, and make sure your products and things never have those.

Adam: Yeah, I just try not to. One of the things I see a bunch on teams that are building enterprise software, they get weird about refactoring a little bit sometimes in a similar way. The system gets big or complex or enterprise ready, and you're like, "I don't want to change how that system works even if it hurts a little, because it has to be there. It's the enterprise readiness system." And it's like, "It doesn't have to hurt and it doesn't have to suck. It has to be there, yes. But it doesn't have to suck."

Grant:

That's one of my goals in my life, is to help people build enterprise software that doesn't suck.

Adam: That is one of the goals in your life, for sure.

Grant: Make it feel amazing and easy, and like all the attention was paid to build something. Because you know that someone else is going to use it, it doesn't matter if it's the one person at Facebook that had them configure that piece of your application. Somebody has to suffer through this, and why make him suffer? Why not make their life--

Adam: Why not make it great?

Grant: Why not make it delightful?

Adam: To me, that's the core. Not to make it a Replicated pitch, or whatever. But that's the core thesis of Replicated. Like, "You should be able to focus on your application, and we can focus on making the experience of it being enterprise ready being delightful." So, "We'll bring the delight on those things, and you focus on your core application and then it's going to be easier for you to go through this journey, which I love about you. I think it's legitimate, and a deeply needed use case that just everybody suffers. And anything that decreases that suffering, I'm in.

Grant: Thank you. We try to decrease the suffering of software vendors all over the world.

Adam: Yeah, for sure.

Grant: Cool, Adam. You've been amazing. The one last thing that I really want to do is I want to have you just pitch Chef for five minutes. Just tell me all the amazing things, and why I should use your product, and just go through whatever pitch you normally do. Let's hear it.

Adam: OK. What Chef exists to do is to help software engineers, systems administrators, dev ops engineers, security people, whoever you are. Over time our objective has really become that we want to help the enterprise go through this transition from where they're learning to be technology companies. They're learning how to harness technology, they're learning how to build and run and manage their organizations in a way that allows them to adapt to the technology and the pace of change that is the status quo now in the world.

That journey to me is, it's technology and it's humans all at the same time. A lot of what we do is go out in the world, like we've been talking about in this podcast and finding a way to understand more about more people's experiences, and more of the problems that happened in the enterprise.

Then we go build technology that solves those problems in ways that hopefully people didn't expect, that are delightful, that when they use it they're like, "Wow I didn't even know that what I needed was for the world to work this way, but once it worked this way the light bulb went off. All of a sudden I felt like I could unlock all of this stuff that was latent inside me. I go to work every day and I do the thing that I do, and what I want is to be great. But what's in my way is a bunch of garbage."

Chef exists to help those people figure out how to put that garbage down, and how to get better at that motion. We do it with a couple of different pieces of software. One is Chef, which is a configuration management system. You write code that describes how a bunch of servers should work, and when you run it checks to see if they work the way you said. If it didn't we figure out how to fix it, is the nutshell version.

We have a security compliance product called InSpec, where you can write software tests that describe your compliance policy. So, rather than having a PDF that is your compliance policy and then some automation that tells you whether you're compliant, if you have that at all. Most people don't. Most people just have the PDF and then a human who does stuff. It's like if software testing and that compliance PDF had a baby. You can run the software, and the software will spit out the same report that you would have gotten from an auditor that tells you whether you're secure and compliant.

We built that product because when we were doing configuration management in the large enterprise and trying to help people ship software faster, and build their infrastructure better, the biggest blocker to our progress was whether or not you could prove that you were still compliant at speed.

Now we have a security and compliance product that helps you prove that you can do that at speed. Then we built a product called Habitat, and what Habitat does is it looks at the evolution over the last decade of how we build infrastructure and how we build applications, and it turns it on its head and says, "Historically we've thought about this from the point of view of infrastructure.

We've said, "I've got a platform. I've got Kubernetes or I've got VMware, or I've got OpenStack, or I've got Chef. And I'm going to use that platform to run all of my junk, and then I will have nice things." And what we have learned is that it doesn't really work out that way, because the application itself was what we cared about and the lifecycle of the application.

From how it's built, how do developers use it, how do you run it on your laptop, how does it go into production? What different environments does it run in, what operating systems does it run on? What dependencies does it have? How does it do service discovery? How do we reconfigure it? What happens if it goes down? Can it do clustering? What are the typologies? All of those questions about how the applications work, we pushed all the answers into infrastructure.

We said, "None of those are the application's concern. It's actually the infrastructure's concern." With Habitat we flipped it over and we said, "All of that is the application's problem, and the infrastructure's problem is just getting the thing running." If you can get to a place where the application can start, that should be the only thing you ever have to worry about ever again in terms of its lifecycle.

That's what Habitat does. Because our biggest problem after we solve the compliance problem and the infrastructure problem was, "Your application teams are not very good at getting their software to move left to right in that continuous delivery pipeline. They're not very good at even figuring out how to build the software in the first place to get an artifact you could deploy, or they're not very good at building the container. Or they can build a container, but the container only runs in one environment.

So now we build five containers that are slightly different for each environment that we ever want to run in, but then our tests aren't the same and that's a bummer. And on, and on, and on, and on. Habitat takes that problem and boils it down to a really simple method of saying, "This is how I build my application. This is what's configurable about it. This is the things it needs to know about the other systems it depends on and relies on," and allows you to just declare that at runtime, and manage its lifecycle. That's Chef.

Grant: That's amazing. Thank you very much.

Adam: Right this second, if you like the last bit of the Habitat story. One of the things I do is I get on planes, and I sit in people's houses, and I do that for you. And if you want me to do that I'm easy to find.

Grant: That's amazing.

Adam: Thanks.

Grant: Adam, this was incredible. Thank you so much.

Adam: It's my pleasure.