Trust, tooling, and a no-blame culture with LogDNA

Liesse:

Tucker Callaway is the CEO of LogDNA. He has more than 20 years of experience in enterprise software with an emphasis on developer and DevOps tools. Tucker fosters a DevOps culture at LogDNA by tying technical projects to business outcomes, practicing extreme transparency, and empowering every person in the company to contribute.

Welcome to DevOps State of Mind, a podcast where we dive deep into the DevOps culture and chat with friends from small startups and large enterprises about what DevOps looks like in their organizations.

I'm Liesse from LogDNA. Join us as we get into a DevOps state of mind.

Hey Tucker, thanks for joining us for the first episode of DevOps State of Mind. Before we dive in. Can you tell us a little bit about yourself and your journey to becoming the CEO at LogDNA?

Tucker:

Yeah, sure. Well first, thanks for having me. Excited for the podcast series and excited to be the first one on here. So yeah, a little bit about my journey to becoming the CEO of LogDNA—I guess, as it relates to DevOps, probably what was the most important to me is that I spent four years at Chef Software, which was formerly called Ops Code and we changed the name to Chef Software. Chef Software was the steward of the Chef open-source product. And so it was one of the early pioneers and enablers of the DevOps movement. And, when I was there, I had an opportunity to work with—I was on the sales side, so I ran sales there—but I had an opportunity to work with some of the best minds in DevOps like Dr. Nicole Forsgren was there, who's at GitHub now I believe, Jez Humble, Adam Jacob, and a number of our customers were early on, like Etsy and others that were early in the early stages of DevOps. So that was super formative to me in terms of my knowledge of DevOps. And not only how to apply that to development teams but how to apply it to a way of thinking and a way of working in general.

Liesse:

Awesome. Today we'll talk a little bit about how we practice a DevOps culture at LogDNA, but also I think it's a different scenario because we are creating a tool for developers and DevOps-oriented teams and so, your experience has kind of influenced how you think about our users now, which is awesome. Can you tell our listeners a little bit about LogDNA and the problems that we're solving?

Tucker:

Sure, yeah. So LogDNA is a comprehensive platform to control all of your observability data. What it does is it enables teams to ingest, process, route, analyze, and store massive amounts of unstructured log data. The capability fuels enterprise level application development, delivery, security, and compliance use cases.

Liesse:

Awesome. We won't talk too much about LogDNA in this episode, but great for our listeners to hear the kind of problems that we're solving.

Okay, so I think DevOps is a really broad term and it can mean a lot of different things in different organizations. So, as a level setting question I'll ask, what does DevOps mean to you?

Tucker:

Yeah, so good question. So, it does get construed into a lot of different ways. Having that history from, you know, over nine years ago when DevOps was a weird term that people didn't know about, and then during that time, transitioning it into a common term. The foundation of DevOps to me is really just a way of working. It's like a style of work and how do people collaborate together across an entire organization. As I mentioned earlier, it's not just the development teams, but it’s like, how does a group of people come together to deliver capabilities for their customers? So for me at LogDNA today, or as I apply it today, since I'm not supposed to talk about LogDNA—

Liesse:

It's okay, I'll let it slide.

Tucker:

I can make reference? Okay, fair enough, fair enough. So tying projects to business outcomes is really important, but really more than anything, it's the incremental approach and creating a culture of collaboration. One of the things that I believe strongly, as you know, is transparency, and that is kind of really throughout the organization. So we focus a lot on working on trust, as you know, at LogDNA. But to me that means focusing, not just on the business outcome, but removing a lot of the unproductive concepts that have a tendency to creep their way into the operations of the company. “No blame” is a commonly used term in the DevOps world and I love that one and I've held onto that one pretty strongly throughout the years, just because I've always felt like the kind of concept of blame or fear has really—as it creeps into these organizations—it's just really nonproductive and it keeps people from communicating effectively, it keeps people from taking chances, and it really is the conservatism that comes with it that is a barrier to greatness actually. And so I really like to try to focus on, you know, no blame environments.

Liesse:

I love that. I think it's also really hard, especially in today's world, to not operate from a place of fear. Like not only are you taking all of the things happening at work into consideration, but people have a lot of uncertainty in their lives outside of work, too. How do you approach that and help people feel empowered not to come from a place of fear?

Tucker:

Yeah. It's a challenging time in the world to create a safe space. And I think the safe space is the most important thing. For me, it has been a fascinating challenge because I took over as CEO of LogDNA in the middle of a pandemic, in the middle of a racial reckoning, in the middle of—I don't know, there's probably a bunch of other things happening, but those are the two big ones. And going through that and trying to create a safe space for conversation and all that at the same time, it was a real challenge.

I guess thinking about it, probably the most important thing is consistency, right? I think you can't—it's interesting—you can't say this is a safe space, right? You have to demonstrate that it's a safe space and you have to—the trust for that space has to be earned and it's earned incrementally and you have to make an example of it, you have to make an example of yourself, you have to extend it to people and you have to celebrate when those safe spaces are created. So I think just like anything else–it's incremental, it's earned over time.

Liesse:

Totally. To dive a little bit deeper on that one, how important do you think it is to create an environment where it's okay to fail and where you push yourself and encourage your team to push themselves, to this kind of DevOps culture, or way of work?

Tucker:

Yeah. So, one of the things I like to tell people is that I'm not done failing. So, I think it starts there. I have a deep acknowledgement of my own failures and when I'm wrong it's good to just say you're wrong because that starts to help set the example. But, if you have this environment where people are protective of failing, then you have an environment where people are trying to work within certain confines or safe confines. And you just—like I said before—you just can't do anything great. And so, I just try to really dig into that every day, I think it’s the most important thing.

Liesse:

Also I'm reminded of it because it's on your laptop right in front of me, but you say this a lot, “no one is coming, it's up to us.” And I think that's a good thing to remember too. It's like, we're all responsible for the work that we do, how we contribute to the company. If we try something and succeed, that's amazing, we did that as a team, we can own that. If we try something and we fail that's okay, too, because nobody else was even gonna try.

Tucker:

Right. Well, so it's a really interesting backstory on that too. I've done some work with the Navy SEAL Foundation helping some of the Navy SEALS as they come out of the teams into the industry, helping place them into the industry. So I've done a number of networking events with them, and that's where I got that phrase from. And, I actually just got that sticker yesterday because I had it on my old laptop and didn't have one on my new laptop, but it's a phrase that really means something deep to them, you know. And obviously, they operate in different situations than we operate in, but the phrase can be used in so many different ways to just remind us that if we don't try, there's no one else trying. And it's so important in a small company, but I think it's important in any situation to remember that you're in charge of the situation you're in, you're in charge of making that situation better and nobody else is.

Liesse:

Yeah. Awesome. Well, I'm glad you have your sticker back. Not that you need a reminder, I feel like that’s burned into your mind.

Tucker:

It’s pretty pervasive.

Liesse:

Yeah. For those of you listening, this is a phrase that comes up a lot in team meetings and company all hands. So, it's definitely part of our culture.

Okay, so in your experience, working with customers and partners at LogDNA, what are some of the tools or processes that you've seen really be helpful for an organization that’s adopting, kind of, a DevOps culture? That can be pretty broad—obviously right now we're talking about taking ownership, cross team collaboration, operating without fear—you can talk about that, or you can talk about software tools.

Tucker:

Yeah. I think there's probably two levels to it. I mean, specifically on the software tool side in DevOps we increasingly see the need for DevSecOps, which is actually bringing three distinct disciplines together into a common framework for collaboration and delivery, and taking control of business outcomes. And so with that, whereas these teams used to be very siloed and specific, they now have to collaborate and they need to have common language to do that. And a common language we find in many times is data. Which, of course, log data provides this common framework for understanding. But when you look at these tools, you now have what used to just be the IT operations team using log management—you now have three different teams using log management. And so the tool needs to be approachable enough. It needs to be simple enough. It needs to be easy enough to set up and get information out of, and it needs to not require training so that these teams can engage and get the information they need at the time that they need it and then move on with their lives.

Liesse:

Yeah, you've talked a lot about security and operations shifting left—developers having to think about them. That's a pretty central concept to DevOps. But, you've also talked a little bit about the development mindset shifting right. Can you talk a little bit about that?

Tucker:

Yeah that's one of my—thanks for bringing that up—that's one of my favorite ones, because I think that the industry has really focused on shifting left. And when you're shifting to the left, that means your orientation is to the right ‘cause that's the perspective that you're coming from. And that is, in the kind of supply chain of the application or software delivery life cycle, shifting left from the right essentially implies that you are taking operational constructs and you're pushing them on the development teams. And the development teams are teams that are already taxed. They're extremely hard resources, they're extremely valuable resources—as they all are, but that one is especially today. And so what I believe we need to do is to start to think about how do we shift right? Which means, how do we give the devs the tools that they need in the environment that they work in that allows them to take on some of the disciplines of the right versus taking the tools of the right and pushing them on the left.

Liesse:

Yeah, that's great. I think obviously we're biased because we think and talk about this all the time, but log management is a great example of doing exactly that. So, considering that you have experience from the startup perspective as well as with our customers who are huge enterprise companies, and you've seen DevOps in both of those different environments—and for some of our customers, they’re early in their adoption of DevOps methodologies and some of them have been cloud native and practicing a DevOps style of work from the beginning—what advice could you give to a larger organization to help them on their adoption?

Tucker:

Yeah, one of the best pieces of advice I ever got on this was actually from Nathan Harvey, who is one of the developer advocates at Google today—but he also worked with us at Chef—it's interesting, it's just like any approach to change. And it doesn't matter if you're small or big in terms of the company size, but the answer is always start small. Like, that's how you affect change. Change doesn't typically come through big, massive changes and these transformational organizational behavioral roll-outs. It usually comes from the people doing the work, having a desire to make the change. And so, early on we’ve always focused people on putting together a small team of like-minded individuals, having them do the style of work that they want to do, in the way that they want to do it (in the DevOps style), and then sharing that out with the rest of the company. And when you do that, it has this by-product of being incredibly infectious, where it starts to spread (terrible right now, sorry) and it has this byproduct of really catching on and permeating throughout the organization in a way that it starts to organically take root. And that's where change really happens. It's not when the executives come in from the top and say, “you're going to do the DevOps.” It's when a team starts to see the power of working in this way and they see someone deliver and then they become interested in delivering that way too. So, that has just been such a powerful tool. And it's amazing with all the time and energy that's been spent on it, it seems to always boil down to that—just simply getting a team of six people together, people always refer to them as like “two pizza teams.” Kind of depends on how much pizza you eat, I like to eat a lot of pizza. But, depending on how many people you have and how much pizza you can eat, whether it's a 4, 6, 8, doesn't really matter, but it's a small group of people working together and learning what it feels like to operate that way. Right? It's so hard to switch from your current construct to a future construct, you have to experience it. You have to get all the way into it to experience it. And we found it with our own company, even the last few months, that’s the change that makes the biggest difference.

Liesse:

Yeah, absolutely. That feeling of, “I did this thing and I moved really fast. I accomplished what I thought I would accomplish, or maybe something different than I initially thought that I would, but I feel good about the end result.” That's so powerful and I feel like that's the thing that keeps people engaged and interested in their work and keeps them excited to come back to work—or come back to their home office—and do it again.

Tucker:

Yeah. And then oftentimes you find when you're operating that way too, that you might've been wrong to begin with—your premise might've been wrong. But recognizing that in two to three weeks versus two to three months is a very rewarding process, actually. You actually get that early validation that you get a chance to take it and to change and to adjust and make it right for the customer.

Liesse:

Yeah. This is kind of a polarizing statement or a thought, but how do you feel about the phrase, “move fast and break things?”

Tucker:

I like it, in general, but I think it's—well, it's funny I have a couple of different DevOps-type experiences on me. I have the Chef [experience] which is, of course, driving infrastructure as code and being able to deploy using that as a means to be able to deploy quickly. But after that I worked at Sauce Labs which is, of course, testing for DevOps. So, I think that move fast and break things is a great construct, but I also think that you can do it safely and that's something we had at both companies. We talked about it a lot, like you can safely do that so long as you're running tests and so long as you're injecting quality into the process. And that allows you to move fast, break things, but maybe break it before a customer knows that it's broken. Right? So, let's move fast and break things and fix it so that we can get the right thing into the customer's hand at the right time.

Liesse:

Tucker Callaway, CEO of LogDNA, thank you so much for a great conversation about tools and mentalities that help drive DevOps in organizations. On the next episode of DevOps State of Mind we'll discuss why trust is essential in a DevOps culture. Joining me for the conversation is Sean Tierney, DevOps lead at Athos. I'm Liesse Jones. Thanks for listening to this episode of DevOps State of Mind, brought to you by LogDNA.

If you'd like to hear more about the DevOps culture, subscribe to the show and then pop over to LogDNA's website at logdna.com to learn how to be more productive in a DevOps world. Links and information from today's episode are in our show notes.

DevOps State of Mind was produced and edited by Pamela Lorence from Studio Pod Media. Thanks for listening!

Share Episode

Shownotes

Transcripts

Follow

Links

Chapters

Video

More from YouTube