MOD: Masters of Data

Bringing the human to the data

Rob Zuber: The Data of Releasing Software

CTO, CircleCI



You can't self culture with [tools and data], but you can definitely enable a great culture and great teams.

Rob talks about how data is essential to innovating faster and make better software faster.

Ben Newton: Welcome to the Masters of Data podcast, the podcast that brings the human to data. And I'm your host, Ben Newton. If software is truly eating the world, then software release management determines how quickly it can chew. For better or worse, just writing code is not enough. Software engineering teams have to manage large, complex code bases with lots of dependencies all while trying to move fast. Rob Zuber, the CTO of CircleCI knows this world inside and out. CircleCI helps companies get innovation to the market faster and with better quality, and Rob is passionate about how data is a big part of that picture. So without any further ado, let's dig in.

Ben Newton: Welcome everybody to another episode of Masters of Data podcast. And I'm lucky to be here in San Francisco with a great view of the Bay Bridge and Treasure Island out there, with the CTO of CircleCI, Rob Zuber. Thanks for having me here, Rob.

Rob Zuber: Thanks for taking the time to come over and join us.

Ben Newton: Absolutely. I mean if I had this view, I don't know if I could get much work done. And as we always do, and you and I were talking a little before, but I'd love to kind of tell us a little bit definitely about what CircleCI is, what you guys do and why you exist. I think we can definitely talk about that and also, kind of what's your story? Where'd you come from? Unless you just emerged fully fledged engineer from the womb. I'm assuming that didn't happen.

Rob Zuber: That most definitely did not happen. That most definitely did not happen. I'm pretty sure I'm still not there.

Ben Newton: You and me both, buddy.

Rob Zuber: It's a journey, right? That's what makes it fun. Yeah. I'll start with that and then I'll talk a little bit about CircleCI. So actually maybe I'll just mix them together a little bit. So here at CircleCI, we do continuous integration, continuous deployment for software teams all over the world. And we do that primarily within a cloud offering, but we also have an onprem or behind the firewall solution that our customers run for themselves. So I'll talk a little bit about my journey in CI and CD and how I ended up here.

Ben Newton: And I guess there's probably some people in here, they're not real familiar with that term. So that's basically getting engineer's releasing code faster and getting innovations out to their customers faster.

Rob Zuber: Yeah, exactly. I mean we're aiming to take the process of CI and CD, which I'll describe in just a second, and make it accessible and easy for everyone to give them the confidence in the software they're delivering, but allow them to focus on their core business value, right? Unless you are a CircleCI, your business value is not building CI tools, it's shipping whatever you're building for your customers, right?

Rob Zuber: And so it's a very valuable process and it helps customers or helps software developers, whatever, deliver effectively with confidence, but it's not the thing we want them to spend all their time on, right? So that's what we do on their behalf. And specifically continuous integration, the process of basically, we're working on a team, we're each individually building some software and we want to merge that together as quickly as possible, multiple times per day and determine that all of our software is continuing to function effectively.

Rob Zuber: I've been around long enough that I've worked in places where we would build for six months and then try to merge everything together and there would be another three months of merging, which is, I mean, to think about that now is comical, but at the time it seemed perfectly reasonable. What else could you possibly do? And then continuous deployment is basically extending that even further to just pushing your stuff into production.

Rob Zuber: When we talk about continuous deployment, we often think in terms of SAS, right? Where it's, I want to say simple, it's relatively straight forward to be able to update regularly if you have the tools and the confidence, doesn't work quite as well in mobile apps and stuff like that, but we also talk about continuous delivery, which is always having something that could be deployed, right? You've always got a package that's releasable and then you just say, "Oh, today's the day. Let's ship what we have. We'll push it to Apple to do their validation and put it into the app store," or whatever.

Ben Newton: Well, I mean, not to put words in your mouth, but tell me if this makes sense. I mean, sometimes the way I've explained this, companies can't innovate if they don't get this right, right? Like you can't get whatever it is you do, if you make a mobile app for a farmer or you make a game on an iPhone, the longer it takes you to get something innovative to your customers is very dependent on being able to get this process right.

Rob Zuber: Right. I think that's exactly right. And I think it's true in kind of two ways. One is, one thing that slows you down is just spending your time doing these kinds of things either manually or kind of building your own tools or whatever. And the other is your competitors, right, even if you just had this idea, someone else has had it somewhere else. Right. And so the first person to really get that into the hands of some potential customers, learn from those customers, adapt, adjust, find product, market fit and grow from there. Like getting through that cycle as quickly as possible, is about delivering iterations of software as quickly as possible, and that's what we're helping customers do.

Ben Newton: Well, great. So what was before this?

Rob Zuber: Right. So, I didn't do a very good job of intermingling my story.

Ben Newton: No, no, it's good, you're bouncing about, it's good.

Rob Zuber: Yeah, exactly. You can tell that I spend some time thinking about this particular issue. Yeah. So I mean, I've been in software since the late '90s. What I like to refer to as the first .com boom. I feel like we're probably in the second somewhere. No one ever knows where you are exactly in that. And so I've been doing this a long time and I've been through a lot of different cycles. I mean, I've worked in almost every kind of software, consumer electronics, telco, really long build cycles, sales cycles, writing documents for six or nine months before I even started writing code sort of thing. I've definitely seen the dark side of how software gets built and through that time, evolved kind of my own thinking and saw changes in industry and that was all very cool.

Rob Zuber: And in 2011, started working on a company that was in a consumer space, but that was the first time that I started using continuous deployment. And actually my co founder of that company, we'll get to how we got here, is the CEO of CircleCI now. So, we were building a consumer product, we had some great experiences but we didn't find product market fit in the end and we started iterating on ideas around it and we built a bunch of mobile apps around late 2013, early 2014 when everyone was starting to focus on mobile first as the approach to the market. And we found building mobile apps really challenging from a tooling perspective and felt like there were some gaps. So we actually built a iOS and mobile CICD platform at the beginning of 2014.

Rob Zuber: And then in mid 2014 realized in order to build mobile apps effectively, you also need to build a back end. And we had no solution for the back end. And we met the folks from CircleCI who were basically building CI for everything else but didn't have a mobile solution. And so we were acquired basically into CircleCI in 2014, the company was pretty small and we were under 20 people then. We're about 300 now. And so, Jim and I have been here ever since, growing and the company has grown but we also grew and took on bigger roles inside the company.

Rob Zuber: And so yeah, it's been a very interesting kind of ride for me going from very consumer oriented, honestly working on a product where I didn't understand the customer that well, to one that is so focused on my own day to day needs and experience, has been really fun, really cool. And just solving that problem, that core problem of just shipping software faster. I mean, as someone who's done many different startups over time and to your point that you raised earlier, just being able to get stuff out in front of customers faster, learn faster, iterate quickly, all of those things really speak to me in terms of both what I like to do in terms of building products to solve customer need. And also what I like to do in terms of just building software, right?

Rob Zuber: And taking away some things that are less exciting, I have some dark memories of staying up all night mashing buttons, trying to get bills to go through to get stuff out into production because we had to build all this stuff ourselves and it was all kind of held together with duct tape. And so being able to solve that problem for people is really fun for me.

Ben Newton: Yeah, no, that's really interesting. Yeah. And I think there is sometimes even people that are closer to this problem, there's a lot of assumptions about how hard it is to do this. And I think some people think you just put a bunch of engineers in a room, start writing code and you'll be all good. But getting this whole release process down, it's not easy.

Rob Zuber: Yeah. I think, going back to having done this, and you said before that you were around the same time in the industry. Like we've been through a lot of change, right? And every year, every few years we find a new way to kind of stand on the shoulders of giants, abstract ourselves a little more from the complexities of building software and we're in a world where you can learn some basic kind of JavaScript development and go build a really cool product and that's based on a lot of blood, sweat and tears that has kind of gone by in the past.

Rob Zuber: But a huge part of what allows us to do that is tools like that. I mean, not just the things that we do, but being able to deploy servers in the cloud, I mean click a button and you've got a computer and a data center somewhere. Right? I mean, I've gotten on a plane and flown to a data center with my tool kit and racked boxes and put in cables and I mean, you just don't have to think about that or understand that anymore. So it's a very cool, I love saying it, it's a great time to be alive, but it's a cool time in terms of the development and also seeing all of that as you have in terms of where we've come from and then trying to think about, okay, so what does the next 20 years look like in terms of how we build software?

Ben Newton: Yeah. No, you're absolutely right. Because, I mean, I feel like, like you said, my first job was at a company called LoudCloud and I remember we were doing a lot of this stuff early on, but we had no idea. I mean, we were trying to make it work bigger, better, faster and look at the kind of stuff you can accomplish nowadays, it's pretty amazing how far the industry has come.

Rob Zuber: Right. And the things that have gone from sort of innovative, right, this is a really cool idea, let's do continuous integration to basically I'll just buy that off the shelf now and focus on the next problem and the next problem. Right? I don't know if this is a common expression, but we talk about tech, right? Like we work in tech, but I look at companies like Lyft as an example. I mean, in a lot of cases, let's not talk about self driving cars, but ultimately they took some people with phones and connected them to some other people with phones, right?

Rob Zuber: All of the technology work had been done. GPS and cameras on phones and mapping and turn by turn, all this stuff had been solved, and they just said, "Oh, if we take these two people and put them together, there's a marketplace here." And that's really cool. Right. So if you think 20 years ago, would you have thought to yourself, Oh, you know what we should do, we should just get these two people with phones together and one of them can drive with the other or whatever. Right. I mean, that's... Yeah.

Ben Newton: Yeah, no, you're absolutely right. And one thing too, as we were connected earlier, I mean, one of the things I notice about the way you guys approach things, you are a data driven company. It seems like, and that's really important for this industry in general. But it seems like that's a big part of driving a really CICD process that works as well. So, I mean talk a little bit, because I mean, you guys had a report that you did and talk a little bit about that. I mean, how do you think about data in that process?

Rob Zuber: Yeah, absolutely. So I think there's multiple levels to that. First of all, just as what I often refer to as single player mode, meaning I'm just here using the capabilities. I have a software project, I'm using the capabilities of CI and CD. I can get useful information in data just about how I'm operating. Meaning things like, how long does it take my build to run? Because the time that I spend doing that is time I'm sort of waiting for my build to complete, as opposed to focusing on the next thing. Right? So the shorter that can be, the more work I can get done in any given day and the more I can sort of stay focused on the thing I'm trying to do. And so just that kind of feedback, Oh well, your build is taking a lot of time. You could try doing this instead. Or here's where the time's being spent, so maybe you could optimize that part of your process, like those sorts of things.

Rob Zuber: Again, very focused on an individual project, but what's really interesting, and personally for me and for our customers at CircleCI, is we are doing this for so many people that we can then see trends across teams, across the industry and then partition based on people using particular language stacks or particular approaches or the types of things they're building meaning, basically build time is one of my favorite examples because it's so simple. Everyone talks about it and people have a very broad spectrum of views about what is reasonable, right? And so, just being able to say, "Hey, you know what? This takes you this long. Did you know that 90% of the people actually do that in half the time? Maybe there's something you should be looking at there," or, "Your tests are flakier than other peoples."

Rob Zuber: Just really basic but interesting stuff like that. And seeing that big picture view is really interesting for us. And then trends over time, again as a team, right? So as an engineering manager, it's interesting to me to know that we're failing more often, so maybe people aren't paying as much attention to what they're doing or we're getting more conflicts. Maybe there's more complexity in our code as it evolves. Okay, so that's the symptom, we should dig down into that a little bit and understand it better. But also again, going to that kind of industry benchmark, people talk a lot about how often are we deploying, right? So being able to say, "Okay, we as a team are deploying five times a day."

Rob Zuber: Or it takes us this amount of time to get from when we actually implement some code to when it gets deployed. I mean, these are things that people are trying to reduce or manage around just as a sense of their own throughput, their own delivery. Right? So we talked about earlier just CI and CD being an enabler for effective software delivery, but really being able to put some numbers around that, and understand are we allowing it to enable us? Right. And I think that's something that we've honestly often struggled with in engineering, not necessarily just around CI and CD, but if you look at estimation and point velocity and stuff like that, we're always interested in understanding our process. But at the same time always struggling with the fact that the process is a little inconsistent, right?

Rob Zuber: Estimation amongst engineers is sort of a classic discussion point, right? Like why are you even bothering to ask me? I don't know. I won't know until I'm done, how long it was going to take. Right? But being able to get a little bit tighter and say, "Oh, well if we're really bad at estimating all the time, that could be a sign that our software is too complex." Right? What is it that's preventing us from being able to understand what it's going to take to get this delivered that's therefore driving to these wildly inaccurate estimates.

Rob Zuber: And I think that there are similar analogies in CI and CD. Why do we always have broken builds, right? Why do we keep breaking the master or default branch? It's usually a sign that people don't understand enough about the software to be able to confidently introduce a change, sort of thing. Right. So, I think seeing that from an analytical perspective like that is really eye opening, enriching for all of us in the industry.

Ben Newton: Do you think is there an openness to that? Because I mean, I totally get what you're saying about the whole game of estimation is a perfect example. But do you feel like teams are craving that and don't have it or I mean, what kind of feedback do you... I mean, for your own customers and what you've seen, is that something that they're looking for?

Rob Zuber: Absolutely. I think who is looking for it is a really good indicator of engineering culture. Do you know what I mean? And by who, I mean upper management versus the team, right? And so I think that's one of the most interesting dynamics around engineering teams and culture as a whole is being able, and we're certainly not perfect at this, but being able to get to a place where you're helping an engineering team, right, sort of IC's, people working directly on a piece of the product, see how they can use data to think about and improve their own experience.

Rob Zuber: As an engineer, just personally as a software developer, I find rapid delivery of value exciting, right? Saying, "Hey, I woke up this morning and I thought of a thing and I wrote it and I put it in front of customers by this afternoon and now I have feedback." Maybe the feedback is they hate it, but now I can change it and do something else. Right? That rate of delivery, especially again as someone who wrote documents for nine months before they were allowed to write the first line of code, I mean, that is exhilarating, right? And rewarding. And so sort of getting a taste of that, for lack of a better expression, and being able to see, Oh this is actually really fun, now how can I use this information to improve my process? Right?

Rob Zuber: As we have retros as a team, sit down and discuss and say, "Hey, we didn't move a lot of stuff out this week. What does that tell us?" Right? Did we invest a bunch of time in technical debt? Were we held up because we couldn't get the documentation? Or we have some dependency on another team and we should have a discussion about why are we so dependent on another group to be able to get our own work done? It exposes a lot of interesting stuff and being kind of mindful of that data and thinking about the data in that way is really empowering.

Rob Zuber: But it can feel the other way, right. Which is, someone's looking at me and measuring me and they're looking at how many times I deploy this week and that either feels like they're really trying to help me because I mean, as a manager, if teams are struggling to deploy, I want to know why that is because I want to fix those problems so they can get more work done and enjoy that exhilarating experience of delivering value.

Rob Zuber: But as a developer who's maybe not deploying as much, I'm thinking, Uh Oh, am I in trouble-

Ben Newton: Like an intrusion.

Rob Zuber: Right. Maybe I should just deploy some unimportant things to get my numbers up. Right. And that's always the challenge. I mean, it's always the challenge with data, is do people end up feeling measured and therefore game the system or try to just move the number and it ends up being the wrong number. Right? Like I will do unnatural things to move a number versus I'm just using that information to inform myself and my team so we can be better at what we want to be good at in the first place.

Ben Newton: Oh, that's really interesting, the way you describe it, because I'm always trying to think about the right way to describe it, but data's [inaudible 00:19:14], it's the oil that makes the functioning machine work better. But the culture is still what drives it.

Rob Zuber: Yeah.

Ben Newton: Because I know having been around when dev ops apparently emerged, I think you were doing it before, but all the discussions, people always talked about the tools. And said, "Oh, I can use chef, I can use puppet, I can use this and use that." And even today I feel like sometimes we get lost in, Oh I can use this widget where it's really like, look, you do have to make those cultural changes. You have to think about, it's still people doing stuff. Do you see that? Is that what you see?

Rob Zuber: Absolutely. I think that you're really onto something. From a culture perspective, if you can build a great culture, then you can enable those teams and magic will happen. Right? But if you just throw tools at a bad culture, you just have a bunch of people distrusting the tools and the other people around them. Right? You can't self culture with tools, but you can definitely enable a great culture and a great teams with great tools, and with great data.

Ben Newton: Yeah. No, and I think it's, well it's one of the things, if you have a great culture where people are willing to ask those questions but you don't have the data to actually help them make informed decisions, they're not going to... Yeah, that makes a lot of sense. And well, I guess that's part of the thing with a platform like yours. Do you feel like having the platform actually helps in that maturation cultural process? I mean, what kind of interactions do you have with your customers in that sense? Because I guess in some sense, you have to a, I don't know, we use a science term with somebody, you have to have the substrate to grow your culture on, but you've got to have something that kind of drives that right culture. Do you find that having a tool like CircleCI actually helps that?

Rob Zuber: Yeah, I think there's a few things that kind of combine together, right, like having the culture, the curiosity to try to improve. Sort of a mindset of continuous improvement and then some automation to support it. And then that kind of feedback loop goes around, right? We get a little bit better culturally, we build a little bit of trust, invest in some automation, some tooling. We get some feedback on how that's working. And then because we have trust, we have open conversations and say, "Hey, you know what, that was actually terrible," right? We all made a mistake.

Rob Zuber: And that's fine because now we have that information and we can do something better. Right. But again, tying in culture there, if we just deploy some tools and it doesn't work and it didn't really improve anything but someone feels like they really put their reputation on the line by making that decision versus Hey, we're all in this together. Let's just try some things and see what works. Then you become defensive about that decision. Whatever we're talking about tools or data or whatever it is that you're trying to change, and then you get locked into that decision versus being kind of experimenting and trying to see what works. Right.

Rob Zuber: And I think that you see the same thing at a product level, when you talk about, I talked earlier about sort of rapid, Oh this was before, but about rapid iteration and trying to discover a product and find product market fit and those sorts of things. If you don't have that kind of openness and trust in that world, then you end up sticking to bad decisions, right? Rather than saying, "Well, the data is clearly telling us that our customers don't want this, let's go figure out what they do want." It's like, this was my opinion and therefore I'm going to stand behind my opinion.

Rob Zuber: I, for completely other reasons, have been talking a lot recently about data versus narrative, and being able to kind of unwind narratives, right, because those are expressions of people's opinions and say, "Let's just put all the data on the table and come to an agreement about what this data means," right? Whether you're product planning, analyzing your market strategy, looking at how your CI and CD stuff runs. I mean look, we have real data. Let's put it down, discuss the data. If we can agree on that, then we should be able to form an opinion together versus you and I are just sitting here debating my opinion versus your opinion and then it's sort of like whoever's loudest wins.

Rob Zuber: And then again, if it turns out I was wrong, but I was the one who won the argument. Now I'm going to stand behind it even though I'm clearly wrong. Right. So, I think in all senses when you have the culture that drives that open conversation, then whether it's data or tools or process or whatever, being willing to just put it all on the table and say, "How do we think it's working? What could we do better?" I mean, that is really empowering and without the culture to support it, none of it works.

Ben Newton: Yeah. I think that's really good because I've definitely, I haven't been in this industry myself. I think that's always kind of a discussion you get back into. I think there's a, definitely when leaders are thinking to try to push the organizations forward, there's a tendency to think that if I buy the right tools and I invest here, invest there. But if you don't actually encourage that really fragile culture, it's very hard to see success.

Ben Newton: So, one thing, making a little bit of a switch here, it's part of what you guys are doing in this report it sounds like. So maybe tell us a little bit about the process, because it sounds like you guys looked at some of the things that your customers were doing and kind of pulled together some insights out of that. So tell me a little bit more about what the process was.

Rob Zuber: Yeah. So, I mean, we sit on a treasure trove of data, if you will. I mean, from a process perspective we have the opportunity to just look at stuff internally, in aggregate across our customer base and say, "What is interesting to us?" And there were some things that were interesting, some things that were expected and some things that were surprising, I think, as we sat down and looked at stuff. Like we actually found that the rate at which people's stuff flows, we talked about build time before, right, that it was actually pretty fast. And because we notice outliers, I think when you're operating a system like ours, it's like trying to read the matrix, right? There's a lot of stuff going by at any given time. So, you notice the things that really stand out, we obviously have lots of customers with jobs that run for hours because that's what we notice, right?

Rob Zuber: What we don't notice is the thousands and thousands of jobs that are running by really quickly and all the people that are just getting their work done all day long. And so when we sat down and looked at time to build, that was much faster than we actually expected on average. One of the things that was kind of interesting and stood out was recovery time, right. And we talk a lot about that in terms of, I mean you hear about this everywhere, particularly on default branches, or master branch I think [inaudible 00:25:44] terminology is what you'd normally call it.

Rob Zuber: And this expectation that people, as soon as there's a breakage on a master branch, everybody drops what they're doing and fixes it. And that's usually what happens in a great culture. But we see a broad distribution, right, sometimes because the project is not important. I mean, it's a little bit difficult to read into the minds of your customer and say, "Oh, maybe this isn't important." Right? And many people have their production code, but are also building tools and side projects and things where they can say, "You know what? I was just working on that all day. It's fine. It's broken. It's five o'clock. I'm out. I don't need to stay here all night and make sure that's working again."

Rob Zuber: But we also see some differences in behavior in terms of how teams operate, from that respect. Like if something's broken at the end of the day, are people sticking around to make sure that it's up and running? I mean, this is now conjecture, but we talked before we started about how distributed the CircleCI team is, right? And we have engineers all over the world working on the same code bases. And so, there is no end of the day, right? If I create an issue, like break the build at the end of my day, I can't rely on the fact that no one's going to work on that until tomorrow morning kind of thing, because there might be someone in Europe who's going to get up eight hours before me. And so I have to make sure that I've got that fixed.

Rob Zuber: And so maybe some teams, I mean I've worked in also entirely co-located teams, right, you look around and everyone says, "Yeah, don't stress, we have nothing important that has to go out tonight." We can all agree on that really quickly, but I can't do that in a team that's maybe distributed around the world. Right? So I would say there were some surprising things that came out in terms of just how people behave around master branch or whatever.

Rob Zuber: But overall, what we found was very effective software delivery. I mean, it wasn't totally surprising to us, that's what we believe in. But customer's using our platform and delivering software effectively all day, every day. And it's cool to see that in aggregate. But then again to see kind of some of the outliers and see, I always talk about build time because it's simple to get your head around, but the range from like minutes, even seconds, to hours and then interesting to dig a little deeper in that and think, what are people working on in a way that it's so critical to them that they're working so quickly and able to get that done. And then, what kinds of things are people working on where a couple of hours is totally fine. Right. And some of-

Ben Newton: And you see that even within, I guess [inaudible 00:28:14] word, but like an organization or a customer. Do you see a lot of variation even within one customer of CircleCI?

Rob Zuber: Yeah, we do. And we're looking at most of this stuff in aggregate, but might say, okay, what does the distribution across customers look like? And I would say yes, prior to this particular thing, there was a separate data set that I pulled, I think it was a couple of years ago now for a conference talk, I looked at behavior patterns and then said, "Is this specifically associated with organizations? Do organizations behave in a particular way?" And it didn't really prove to be the case. And so I think that's, again, many organizations will have tens, hundreds of repos that are building on CircleCI and some of them will be like, this is our production system. And there's like 50 engineers that work on this and if anybody breaks anything, 49 other engineers are stuck.

Rob Zuber: And then there's, I'm building a little tool to try to automate something and I haven't even pushed it into any system yet. And if it's broken right now, who cares? And I only work on it once a week or whatever. And so, you kind of get this sense of what are the really important projects within an organization. And then everybody has this distribution that's like, we behave differently around this because it's a side project, or a 20% time or something like that, or there's only a few people working on it, those sorts of things.

Ben Newton: Oh yeah. No, that's super interesting. So over time you'd be able to almost predict what something is based on the behavior around it, to a certain degree.

Rob Zuber: Yeah. Yeah. I mean, we've never spent time on that, but it is interesting. When we try to look at data sets, a lot of this is about us trying to understand how to better serve our customers, and we look at all this stuff in aggregate and say, "How are our customers behaving?" And then look for patterns that might be like these particular customers are struggling, right. There's something about the system or about our product that's not enabling them the way that we've enabled these other customers. Right. But then we would zoom in a little bit and say, "Oh, this cluster actually just looks like people are goofing around."

Rob Zuber: And it's not that we haven't enabled them or their usage dies off and we say, "Oh, those are sample projects." Like some people will join CircleCI, take some simple sample project they have, run it for a couple of weeks until they figure out how CircleCI works and then go use it on the real project. And we're looking at that sample project thinking, where did they go? But where they went was they put a bunch of people using a big project and actually getting their daily work done. But they don't want to start by testing it out with the main project of their company because they're going to be breaking stuff that other people are trying to get done.

Ben Newton: That's really interesting. Yeah, I mean, [inaudible 00:31:01] nice because when I, some previous things that I did at Sumo Logic, I remember we would analyze, trying to find those clusters of behaviors and see how people evolve over time. I think that kind of stuff is fascinating. Yeah. So, everything we talked about, one of the things I always love to ask my guests is what are you excited about next?

Rob Zuber: Oh my gosh, there's so many, I mean the whole realm of data is really fascinating. I feel like we're just scratching the surface in terms of both enabling our product, like improving the offering that we have through everything that we're learning about how our customers use it, as well as giving customers access to more of that themselves. Right. To be able to take it and then use it for whatever. They might find things that we didn't think were particularly interesting but are interesting to them as a customer. Right? So there's a lot around data that I just continue to be excited about in the platform.

Rob Zuber: The rest of what excites me honestly in CI and CD is, we've been at this for eight, nine years now. I'm not even sure. I mean, I've personally been doing CI and CD for a long time and the company's been around for a long time and then we joined together. But part of what's made this always interesting, and we've always had the same goal, right, helping software developers get their products into the hands of customers, deliver value, learn quickly, do all that with confidence. But the actual world of software development has changed so much over that time.

Rob Zuber: I mean, Docker is just a perfect example, that didn't exist when CircleCI started, right? So, we've changed software development that much, right? Kubernetes was unheard of. So we were still baking AMI's back in 2011, 2012 right? And so now we're doing containers and orchestration and into serverless and a world where people don't even think about computers at all. And so their perspective of how software is being delivered is changing. All of our customers are growing their use of data. So, how they integrate and think about really large data sets is changing.

Rob Zuber: Machine learning actually hasn't changed that much, but we finally figured out what it was. And so now we're all using it. We were talking about it when I got into software, but no one knew what to do with it. Now it's accessible, right? So much is changing and evolving in this space and just how we think about validating software. People figuring out how to run things in a production scale, but even tests in that environment. So there's so much evolving about how we deliver software that our role in that is evolving constantly.

Rob Zuber: Whether we like it or not, I guess is the best way to describe it. But because I personally love software, I love the idea of more interesting, better ways to deliver it, being in a role where I get to think about how that evolves and then how we evolve in it, is constantly exciting I guess for me.

Ben Newton: No, that's cool. I think what you guys are doing is really interesting and wish you all the luck, and thank you for taking the time. This has been a great conversation. I enjoyed it.

Rob Zuber: Yeah, thanks for coming by and taking the time as well.

Ben Newton: Absolutely. And thanks everybody for listening and as always, rate us, review us on iTunes so other people can find us and look for the next episode in your feed. Thanks everybody.

Speaker 3: Masters of Data is brought to you by Sumo Logic. Sumo Logic is a cloud native machine data analytics platform, delivering real time continuous intelligence as a service to build, run, and secure modern applications. Sumo Logic empowers the people who power modern business. For more information, go to For more on Masters of Data, go to and subscribe and spread the word by rating us on iTunes or your favorite podcast app.

The guy behind the mic

Ben Newton

Ben Newton

Ben is a veteran of the IT Operations market, with a two decade career across large and small companies like Loudcloud, BladeLogic, Northrop Grumman, EDS, and BMC. Ben got to do DevOps before DevOps was cool, working with government agencies and major commercial brands to be more agile and move faster. More recently, Ben spent 5 years in product management at Sumo Logic, and is now running product marketing for Operations Analytics at Sumo Logic. His latest project, Masters of Data, has let him combine his love of podcasts and music with his love of good conversations.

More posts by Ben Newton.

Listen anytime, anywhere

Available to stream or download via these and other prodcast apps.