Episode 95: Søren Pedersen on managing and leading software organizations

Brian Dawson: Hello, this is Brian Dawson with another episode of DevOps Radio. Today with me, I’m excited to be speaking with Søren Pedersen, who is the Co-founder of Building Better Software, but has also had a varied and interesting career in business to consumer products. Hello, Søren, how are you doing today?

Søren Pedersen: Hello, Brian. It’s a pleasure to be here and I’m doing really fine.

Brian Dawson: Fantastic. Thanks for joining us, and you’re in Denmark right now, right? So, you’re actually joining us at almost 10 p.m. your time.

Søren Pedersen: Yeah, almost.

Brian Dawson: Wow.

Søren Pedersen: It’s getting pretty dark outside. [Laughter]

Brian Dawson: Miracles of modern technology, right? You’re joining me at almost 10:00, it’s almost 1:00 my time, and then we’re gonna have thousands of people listen to us chat at all kinds of times.

Well, I’m excited to talk to you, Søren, but before we get started, I was hoping that you can help give our listeners an overview of what you do today at Building Better Software and a bit about your career background. How did you end up where you are today?

Søren Pedersen: Yeah, for sure. I’ll start with my career background because that makes better sense of where I ended up. I trained as an engineer in software development quite a while ago, and I spent a bit of tine engineering, I spent quite some time in process and process improvement, in tooling, and actually in the very early stages of DevOps, and those parts were part of some of those implementations in a company called Bang & Olufsen before we kinda knew it was DevOps, maybe.

And then I moved on, later on to be a manager and continued that track in LEGO, a big toy manufacturer in Denmark. And there, I ran, the team was actually called a System Team, but it was really the DevOps Team in LEGO for all the marketing, and bridging the gap to ordinary IT operations in LEGO.

And later on, me and a partner founded a company, Building Better Software, and essentially, the idea is that we want to bridge the engineers and the management liaison organizations because we saw a lot of cases where this misalignment was really interfering with the implementation of agile and DevOps. That’s kind of the root of it, and we believe that software can be graded really effectively and really good if you know how to do it. That’s what we want to help companies achieve.

Brian Dawson: Awesome. That, I think, very much resonates with, I think as our listeners know, CloudBees sponsors this podcast and one of our mantras is helping you build stuff that matters, right? Unlocking the power of software development to actually do something that makes a difference. So, I can very much appreciate that.

I’m gonna want to dig in on your challenges that led to Building Better Software, some of the lessons, and some of how you help people build better software. But before we do, my 5-year-old in me has to talk about LEGO. My teenager in me has to talk about Bang & Olufsen with you.

In terms of LEGO, so, I actually live in San Diego, I’m about 40 minutes from LEGOLAND, and I know there’s a few of them, I believe this was the first. I’m curious, in working at LEGO, did any of the work that your software teams worked on, does that land in the LEGO theme park? Like, is that used for animatronics or what have you?

Søren Pedersen: I think the most, the best example is actually the LEGO House Experience they built in Billund. I know that’s a local thing to Denmark, but we were heavily involved in doing that project from—maybe I should explain. My physician was in what’s called the consumer marketing agency, and that’s actually a kinda cool place in LEGO, because that’s where they invented NINJAGO and it’s where they do all the branding and the kids’ testing—they don’t test kids, but the products on kids, obviously. [Laughter]

Brian Dawson: [Laughter] The kids need some debugging sometimes, but that’s another episode.

Søren Pedersen: Exactly. So, that was really the beating heart of LEGO in many senses, and we had some contributions to some of the theme parks, the NINJAGO Experience, some guys helped out with. But mainly, we were focused on doing LEGO.com online, the IT services and a lot of stuff behind really delivering on those parts and also for the app product line. So, you probably know—what’s it called, the LEGO app? I can’t remember that one. But that’s the key deliveries we were part of.

Brian Dawson: Well, I’m a parent of two young adults who were entertained with LEGOs over the years. I thank you for your contribution in keeping my kids occupied.

Now, I do want to ask a really interesting thing as we talked earlier—so, you spent nearly eight years at Bang & Olufsen. And it was kind of right smack in the middle of where, just like we’re seeing with software development and delivery in these modern practices, where audio and the music field, the test of audio was undergoing a significant transformation. As I had highlighted earlier, for instance, you know, Bang & Olufsen is high end audio, but we have a generation of consumers that consume things in quick, small digital bites where fidelity is not a key thing.

I’m just curious to know one of two things, right—do you see any parallel between what Bang & Olufsen encountered in the change of their market and what we’re addressing and/or encountering in the software development space today?

Søren Pedersen: Yeah, I think so. So, obviously, B&O, as you stated, is a very high fidelity audio product line, also video products. And they’ve been in the market for a long time when the audio services and so on started coming in, and that was a bit of a challenge when you’re very dedicated to creating quality products with quality audio and then switching to something else, that becomes an untrivial thing.

Fortunately, we had some quite clever people in the company and quickly adopted a lot of the formats and provided opportunities for customers to tap in. So, some of the things would be to implement Spotify, InTune Radio and so on, on the devices in that timeline.

Brian Dawson: And so, did that have impact on, so, you oversaw R&D, or you were leadership in R&D, and you were definitely squarely in the technical—excuse me.

So, to dig into that a little bit more, you had a leadership role in Research & Development at B&O and, you know, a technology leadership role. Has the market changed, the landscape of the audio products market changed?

Søren Pedersen: Yeah.

Brian Dawson: Did that, did you in the technical domain have to react to that? Did that reach y'all on the technical domain? I think what we’re seeing in software and business today is that people rely more on software because the way we consume it has changed. All of a sudden, there’s a spotlight on the engineering org within a lot of our traditional businesses. Did something similar happen there at B&O?

Søren Pedersen: Yeah, yeah, for sure, because there are two parts that really stuck out in that process. So, first of all, we had to consume audio sources from outside, so you had to be Internet capable and streaming-wise capable of handling that part, and that actually, B&O is not that big of a company when it comes to reality and negotiation-wise. So, we had to start, rather than just accepting CDs and LPs, we had to start having dialogues with companies that actually would move us around. Apple was also a good challenge, I’d say, when that started coming in.

And secondly, Sonos came out with some really cool products in terms of distributed audio. We had been doing that a while on cabled connections, but they're actually wireless, and there we had to take some really big technology steps to try and keep up with the pace, and they were really fast at getting out stuff, right?

So, that changed the whole pace. We used to have quite a long time to develop products and we had to turn around and do platforms instead and be really quick about that, so that’s a great engineering challenge.

Brian Dawson: Yeah, so very much—it seems like there’s a lot of parallels between what you now know and are helping people overcome at Building Better Software and what you kind of have gone through in some of your previous ventures.

I’ll be interested in digging in more to that, and actually, let’s just jump in and do that. So, you’ve gone from an engineer to an engineering leader, and you’ve now taken a leap and founded a company called Building Better Software. Again, I know you hit a bit on it earlier—can you tell me what is Building Better Software’s mission and what led to you taking this leap and building this organization?

Søren Pedersen: Yeah, for sure. So, I’ll just put it a bit in context of my past. So, in B&O, we did some early automation, we did a lot of build systems and so on and we were pretty ahead of that. But we were often bumping into, on the middle layer management, we could often argue that we should do this stuff and that’s how I got into the management track. But we often came into a position where the whole concept of agile and thinking a bit different about how to do ________ was challenged. And also, through the course of my time at LEGO, I came to the conclusion that there was a mismatch between the layer’s managing companies and the way they were structured and how engineers thought things should be.

And that really led to the idea that connecting the grassroots and the whole movement going on in the DevOps part and the agile part on the lower layers really need to be connected to the higher level management strategies and deployment methods going on. And that’s kind of at the heart of what we do. Because fundamentally, we believe that good quality software comes from really skilled people doing things right, but they need the frames to do this in their company.

Søren Pedersen: And we continuously, when we consult companies, see that it’s a really hard discussion. So, I usually have long, engaging discussions with managers on what it means and how they should behave, and often a term like servant leadership comes up, which is very different from being a manager, in my world. [Laughter]

So, that’s really driving it.

Brian Dawson: Yeah, we’ve had—I recently got a chance to have a conversation with Jocko Willink, who created a book called Extreme Ownership which, it’s based on a Navy SEALs experience, but interestingly enough, as much as we see that as being a command and control top down structure focused on not only leaders having ownership, but leaders empowering ________ with ownership and therefore freeing them to make decisions that they need to make for their own domain.

I’ll bring out a stat I was just looking at today. We’ve run some surveys, this is in line with it. When we asked, when looking at governance regulation and compliance maturity in organizations, we found that managers are more likely to think that their governance and compliance capabilities are mature than their leadership is. And I often find in these surveys that when we segment by practitioners, management, and executive leadership, they have notably, if not starkly, different views of their maturity and the state of the world.

Is this your experience? I think now, so you’ve taken your experience that you went through at your previous organizations and you’ve brought it forth in Building Better Software. How often are you seeing that technical practitioners and leadership are just viewing the world in a different way, that they're viewing the state of the world differently? Is that a common kind of root cause for the friction in the development process, or is it something else?

Søren Pedersen: Yeah, I’d say it’s—I don’t want to be too categorical, but I see a lot of differences between how you observe phenomena in organizations, and how they are considered by management and development teams. And obviously, as a manager, you have a certain level of distance to what’s going on and you’re only observing the peaks of what is happening in most cases, whereas engineers are much closer. And that’s also one of the things we really try to pull in.

So, we tend to have my partner really, really deeply engaged with the engineering teams and then me with the management layers and then we really bridge that and have a continuous, flowing dialogue on what are we observing, what should be brought to which firms, when do we need to tell the developers to take more ownership and when do we need to tell the managers to do something different to give the space for ownership in the teams? And I think that’s nontrivial to establish in organizations, because it’s—

Brian Dawson: I’m sorry, I think you were gonna go there—I was gonna say it’s nontrivial, and I’m assuming one of the reasons it’s nontrivial is because it overlaps with a need for culture change, but maybe you can expand more on what makes it so difficult.

Søren Pedersen: Yeah. So, I think one of the really personal experiences I had when I moved from being an engineer to a manager is, all of a sudden, you have to start to care a lot more about structures in organizations. So, you need to care about hierarchies, you need to care a bit more about politics, you need to care about budget allocations and staff considerations and so on. And when you get into that track, you get a bit distanced from what’s going on on the floor, and I think that’s really what’s creating the gap.

Søren Pedersen: And then, if you extend that into the higher level layers of management, for instance, economics in companies, you might see that it’s a very structured budget process where you as a middle layer manager are really trying to create that agile framework and space for your teams to work.

Brian Dawson: Mm-hmm, but the structures above them don’t necessarily work in concert with an agile framework.

Søren Pedersen: Exactly. Fortunately, we are starting to see some really good movements in some companies, but they're still a bit like unicorn scenarios.

Brian Dawson: A couple of threads I wanna pull there, and yeah, it’s interesting that you said that, because I think one thing we need to get a better picture of or be more realistic about is, while we learn from and celebrate the unicorns, to use your term, right, or the magical ponies or narwhals that are just behind the unicorns, I think there’s a reality that we often forget, and that’s that there’s still a lot of traditional transforming companies trying to figure this out.

Again, are you seeing—what is your take on the industry and where we measure ourselves, actually, speaking about maturity, do you feel we’re almost there, 50 percent of us are there, 90 percent of us are there and now we’ve just gotta deal with laggers that are trying to figure it out, or what’s the reality that you’ve experienced?

Søren Pedersen: I think we are maybe a third into the road, but that’s just a rough estimate. So, we’re seeing a lot of frameworks coming out, we’re seeing things like DevOps really getting some good traction now. We’re seeing things like SAFe building up and less ________ and so on, but my concern is that we are perhaps pitching, holding these models a bit too much. So, trying to grasp for control and structure, we’re taking up something and we are forgetting the heart of the agile part, which is to adapt to your situation and your context and your staff. And that’s why I put us a bit in the start of the curve and think we can mature quite a lot from here on.

Brian Dawson: That makes sense. And maybe that’s a good place to bring in culture. You and I had talked a bit about what we’re frequently calling the human element of software development and delivery. What role does culture have in unlocking the relationship between practitioners and management but then moreover, ultimately unlocking the ability to build better software?

Søren Pedersen: I think it probably is the most important factor in what’s going on out there. So, I see a company’s culture as what they do and they say. So, if I come into a company and they're asking me to kind of get a grasp of what’s going on, I’ll assist the culture on those parameters.

The culture of some engineers are that they're really leaning forward, they're really eager and driving, and if that meets a culture where the management is a bit more risk averse and sticking to the old parts—and I don’t want to turn this into a management versus engineers thing, it’s just an example—

Søren Pedersen: I think that’s unfair. Then you have a problem, right? But if you come into a company where the leadership is really leaning into this and know what this means to a company, then you can see the opposite as well. You can see management pushing engineers who are really not comfortable moving on. And I think having that disparity between the layers of the organization is really what we need to align and where we can get the most benefit from what’s going on.

Brian Dawson: I’d like to bring up another subject for us to talk about and then we can get more into, you know, a little bit more into Building Better Software and some of your recent works. So, what I used to do when trying to help an organization start a transformation or implementation of continuous delivery; i.e., automation across functional areas of the org, that I would do what I now kinda coin a DevOps inception workshop.

So, we go around, we do some individual interviews, kinda getting the lay of the land. But there would be a point where we would have a two-day workshop. We’d get in a room, we’d lock ourselves in a room with a wipe board and some food. But what we would do is, we would bring in an executive sponsor, we would bring in management of an Application Development team, Quality Management, and Operations or App Deployment, and then we would bring in a lead, then we would bring in individual contributors from each of those areas.

So, you really had a left to right voice and you had an up and down voice, and then we’d talk about our pains. We’d try to find where was there a common root cause to shared pains? “Hey, I’m tired of being up all weekend on a phone call orchestrating deployments.” Or, “I’m frustrated with getting builds that break when we deploy them into our environment.” And then maybe a developer is saying, “Well, you know, we’re tired of getting our backlog blown up. We’ve made a commitment to management, we’re gonna deliver X. But every time Operations feed blows up, the platform blows up.”

So, as an example of, there’s separate things that have a common root problem. And I bring this up because we bring them into a room and usually, it was successful. But in talking about culture, it can only be successful if the culture supports people speaking freely and having a voice. So, I’m sure you’ve read Accelerate and Nicole Forsgren and Gene Kim and Jez Humble and their focus on psychological safety.

Søren Pedersen: Yeah, yeah.

Brian Dawson: Yeah, it sounds like you have a comment on it. And now that I did that long cue up, I’m curious how important that is and how you address that.

Søren Pedersen: Yeah, and I think what you’re doing there is a really cool thing to get going and get everybody on board, so that’s really nice. Depending on—so, I like the term candid as well. How candid can people actually be in the organization without feeling backlash from different parts? It can be colleague to colleague backlash. There are a lot of implicit hierarchies in organizations, but it can also be hierarchy backlashes, right?

And I attempt to see that, to get the real truth out in terms of what is up and down, you really need to go into individual situations as well, where people can open up in a, I wouldn’t say a safe space, but in a more psychologically secure environment. And then, from there on, start to build the trust in the organization.

And I also find, when you step into that space, you often find out about different narratives in the organization. There may even be myths, if you follow.

So, people may have a perception that something is prohibited or it’s wrong or we shouldn’t do it, and it gets to the bottom line when you talk to both sides of the party and you can do that in an inception meeting as well. They figure out that they're actually both wrong. [Laughter]

Brian Dawson: [Laughter] Right. Three sides to every story, right?

Søren Pedersen: Exactly, and the best case I have is some management parties telling me that they really thought the engineers liked the agile, too. And vice versa, the engineers said, “Oh, but this is because management likes this tool” and I’m like—yeah, none of you guys like this stuff. [Laughter]

Brian Dawson: That’s hilarious. That is hilarious.

Søren Pedersen: But that’s kind of what you get when you get to that point of stage. Culturally, I think, in Denmark, we’re pretty privileged, because we don’t have too much of that going on, but in other companies and abroad, that may be a bigger issue.

Brian Dawson: Excellent. So, to shift a bit, you recently wrote a LinkedIn article and as we prepped for this, we came across the article and the article was on the impact of bad software. And you had covered three shifts to increase quality and improve business outcomes. But really, that appeared to focus on this idea of quality as an attitude. I’m wondering if you can elaborate on that for me and the listeners.

Søren Pedersen: Yeah, of course. I would like to do it by an example, and it actually stems from my LEGO time. In the company, there’s a narrative or a story which is coming from the founder, and they were doing wooden toys quite a while ago, back in the ‘30s, perhaps, and the owner, back then the founder, had decided that these toys would be given three layers of lacquer. And at some point in time, they were behind schedule and they really needed to sell more stuff, one of the successors decided they would only do one layer. And the owner found out, or the founder found out and made the statement that only the best is good enough.

So, that is, you can do a lot of stuff in terms of engineering-wise, tools and checks and everything going in there, but really, the attitude that this has to be a quality product and we really have to do our best whenever we’re doing anything. That is more like an attitude that I’d like to see instilled in cultures, and you would actually find the same coming out of B&O back in the ‘70s and ‘60s that they don’t care about the price point as long as the quality and the design is just excellent and really meeting customer expectations.

And I think if you really want to do a good job, you need to find people who have the attitude where they won’t leave things in the codebase. So, if you need to do refactoring as part of your breakdown of your monolith, they really have to prevent this, and they need to have an attitude, where they don’t accept the second best.

Brian Dawson: Mm-hmm. Let me—and forgive me if I’m jumping in on a point—I’ll ask how? How do you either find or instill that attitude? And I’m thinking ahead, I’ll even phrase another avenue for that question since I like to cram six questions into one.

Søren Pedersen: Yeah. [Laughter]

Brian Dawson: One is, how do you either find or instill that attitude, or I suspect in a lot of cases, that attitude is the negative version of that attitude—lack of concern for it can grow over time if you don’t take the right steps to mitigate that attitude? So, I’m curious, yeah.

Søren Pedersen: I think there are two parts of it, really, and it speaks into the whole DevOps concept. So, giving people the ownership is allowing them to actually care about things. If you’re going to come from the sidelines and tell them, “You can’t do this” or, “We don’t have the time” or, “We don’t have the money” then you'll quickly get people in a position where they stop caring, in that sense.

But vice versa, I also find that leadership needs to have the—yeah, how do you put that? They have to have the courage to call out when they see behavior they think is outside their principles, right? So, if they're seeing an attitude where people are being lax, it’s probably okay to go and say, “Guys, this is not what we do at this company. You have to do a quality check.”

Søren Pedersen: So, that’s about instilling it in a company from two angles you could say, give the headroom and the direction. But I also think there’s a lot of weight in the hiring process, and I have a good feeling when I talk to people if they're going to do a quality job or not.

Brian Dawson: Okay, okay. So, yeah, you’ve gotta filter, you’ve gotta maintain it internally. There’s roles on the individual contributors or the technical team members—

Søren Pedersen: Yep.

Brian Dawson: - as well as their own leadership, they both have responsibilities. But then it also sounds like, as you grow teams and as you hire, you could absolutely be filtering for that attitude.

Søren Pedersen: Exactly, and probably a bit relentless if you get in some bad seeds.

Brian Dawson: Yeah, yeah, I know it’s painful. I’d heard years ago in some HBR podcast just the term, I think a lot of us know but it’s hire slow and fire fast.

Søren Pedersen: Yeah.

Brian Dawson: Yeah, I think it behooves us to be careful bringing people in because the cost—or at least tend to what your key attributes you’re looking for are right away, right?

Søren Pedersen: Yeah.

Brian Dawson: Yeah, this all still sounds a lot like—I assume you’ve read Radical Candor? You mentioned candor earlier—have you had an opportunity to read that book?

Søren Pedersen: No. I’ve listened to a lot of podcasts, and I really love the way Ray Daniel puts it in some of his stuff. Yeah.

Brian Dawson: Oh, sorry. I did not mean to step on you. What I will say is, if you get a chance, do read that book, because I love what you’re saying about management’s role to call it out, what you said about feeling comfortable to practice candor. It sounds key to what Building Better Software kind of leans in on, and this book, Radical Candor, has a great lens on it.

Søren Pedersen: I’ll have to have a look.

Brian Dawson: So, I want to ask a question, kinda going, we’re talking into management leadership hires, right? How do you develop a quality attitude, how do you bridge this disconnect between management and leaders? I’m gonna go back to ________.

Søren Pedersen: Mm-hmm.

Brian Dawson: So, what can an AppDev engineer or a shared services engineer, engineering manager, DevOps manager listening to this podcast, what can they start to do now, today, to help bridge that gap to help instill—you know, bridge that gap with management and move towards more of a quality attitude and mindset?

Søren Pedersen: So, I think the first part is that—and now I’m going to be pointing fingers, but that’s how it is.

Brian Dawson: “It’s their fault!” [Laughter]

Søren Pedersen: Some managers need to get out of the endless list of back to back meetings every day. So, my principle has always been to be available at least half of my time at my desk where people can come in, open the door, and have a discussion. I never sat in a closed room, per se, but they can come in, they can bring up topics, and that opens that ________ up.

It also gives you a direct view into what’s going on, really, in your context and what you’re doing. I know if you have a spread outside or multiple engineering sites, that’s a bit challenging, but then probably you should look into how you do that stuff.

Brian Dawson: Virtually or remote.

Søren Pedersen: Yeah, yeah, for sure. But I see too many people too busy being in meetings where they're not really producing anything, and that time is probably well spent in being available.

Brian Dawson: Have you been poking through my Google Calendar, Søren? It sounds like you’re talking about my calendar.

Søren Pedersen: [Laughter] I’ve been in the industry for a while, right?

Brian Dawson: Okay, alright, alright.

Søren Pedersen: What was the second part of the question?

Brian Dawson: Well, I wanna go by role, right? You kinda talked about what can managers do—let’s drop down. What can individual contributors, developers, and engineers do to better connect with management?

Søren Pedersen: Yeah, that’s actually quite a tough one.

Brian Dawson: I didn’t mean to stump you.

Søren Pedersen: No, no—that’s okay. I’m just considering. I think what I have seen time and time again is that you get into an organization and people, they get into a position where they come with a statement like, “Oh, yeah, but we mentioned that like two years ago, right, and nothing ever happened,” right?

Brian Dawson: Mm-hmm.

Søren Pedersen: I think what people have to come to is an understanding that—yeah, but saying something doesn’t make it happen.

Brian Dawson: Right.

Søren Pedersen: So, they need to get in the mindset where they actually assume the responsibility. And that’s a really tough transition, but I’ve yet to see many managers that will become really frustrated if people do something good or if they at least try their best. And that is a big change in mentality, and I do see why people get stuck at that position that they feel drained or they don’t feel they get the attention they would like to have.

Brian Dawson: Yeah, so you said—and it’s a bit of going back to your word from earlier. You know, developers take some ownership, right, I think? And that sounds a little harsh to say people don’t take ownership, right? “Take ownership!” [Laughter] But ownership is important

Do you find that—I think sometimes when we talk about transformations in companies, and forgive me, my peers, with this broad brush. But oftentimes, for various justifiable reasons, our technical contributors end up shifting into a defensive posture and attitude—promised to do more than there is time to do, asked to accomplish the impossible, asked to turn this art of software developments into a predictable science.

I think oftentimes, we default to a can’t instead of can attitude, right? Which then means—yeah, that didn’t work three years ago, we can’t do that again. Instead of reaching out, embracing, trying to understand the why are we doing it and taking a more optimistic approach to engaging to solve that problem. Are you finding—you know, as you get to go across organizations, are you finding there’s a bit of that syndrome, that there’s a can’t?

Søren Pedersen: Yeah, yeah, and I think if it’s a company that’s been in a very good position for a long time, they haven’t had a lot of reason to move on or develop, necessarily. And then you find a lot of this attitude in the company.

What I tend to do is, when I get in, is that I look for some easy wins, right? I went to put in or put back the observation that people can actually move and get some cases flowing. Because when you get the first movers, the people who are actually, they will do something right away, then they’ll start showing the path and then champion those around in the organization to build in a can attitude instead. And then it might require some tough discussions with people and telling them, “Yeah, maybe, but we’re going to do this stuff whether you like it or not.” [Laughter]

Brian Dawson: Exactly, right. There’s another phrase from ________, “Disagree and commit,” right?

Søren Pedersen: Yeah, yeah.

Brian Dawson: And then the third role that we have to get into, because we talked about managers, it was about available and engaged and not getting caught up in busy-ness. We talked about developers and it’s taking ownership and being open to helping solve the larger order problem. What about executive leadership? How could executive leadership help achieve this necessary alignment?

Søren Pedersen: Yeah, I think that’s the part we’re still struggling to solve in many of the companies. We touched on it briefly a while ago, a bit earlier in this pod already. They need to create the right frames for the company to execute.

So, for instance, if you want to have an agile organization but you insist on running a yearly budget process, then you’re really not setting your organization up for success, and they really need to look into how to structure the budgets and the frames people are working in to deliver on this promise or this way of doing things. And that’s pretty much a huge challenge in my world.

There’s a guy who wrote a book called Beyond Budgeting who takes that into a sterile context in a ________ company and gives some advice on how to do that. And that’s one of the main parts, I think.

Brian Dawson: Okay. Beyond Budgeting—I’m taking notes, because I’m gonna ask you about books again in a second. But now, okay, Søren, so you said, “We’re really not blaming anybody and we don’t wanna blame,” but come on, tell the truth, which one of these people are most responsible for this disconnect that’s holding us back? It’s the executives, right?

Søren Pedersen: No. We’re all in the same boat.

Brian Dawson: [Laughter] Alright, alright, I tried.

Søren Pedersen: Yeah, that’s a good attempt. [Laughter]

Brian Dawson: [Laughter] Before we get into our standard, I wanna talk about DevOoops, I wanna get some of your final thoughts. But I do wanna ask a bit about your experience in a different type of company. So, you moved from LEGO, you did some consulting, of course, but you were in a B2C business. Now, you’re building a B2B business dealing with a range of companies. Now, you’re getting to see not only what you did at LEGO in software dev and delivery, you have to have a level of technology and IT management software dev and delivery for your business, but you’re also seeing a wider view, right, of people’s software dev and delivery practices.

Any differences in experiences that you can call out between B2B, B2C, and across the variety of organizations that you’re engaging in?

Søren Pedersen: Yeah, yeah. I think being part of a B2C company, you have a very clear picture of who your customers are. So, you have archetypes and you have identified what are the preferences and so on. When. you step into the B2B area, in my experience, you have to do a very different approach. It becomes a lot more relationship-driven in your engagement with the companies, but you also have to consider that you’re not just selling a product—you are, but it’s not like a box of LEGOs, right? You can’t characterize an entire organization like that. You have to have a much broader ________ and insight in the company. And secondly, you need to have a quite wide understanding of the full value stream. So, if you don’t know anything about marketing, it’s going to be kinda hard to bridge that into an agile setup, right?

Brian Dawson: Yeah, right.

Søren Pedersen: And that’s a huge change in my world. So, the span and the approach to the customer is very different.

Brian Dawson: Very insightful. Thank you for sharing. So, you had a couple of things in there that kinda leant themselves to DevOoops, so now is our DevOoops segment. This is not DevOps, this is DevOoops, O-O-O-P-S, “Oh, smack, I made a mistake.”

I am hoping that you can share a technical or personal or other challenge that you experience in your career, a mistake that you made that you learned from and hopefully our listeners can learn from as well.

Søren Pedersen: Yeah, let’s see if this is relevant, but I think one of the biggest mistakes I did, and I think that’s something you kinda tend to do when you’re really getting into this is, I bought a really expensive tool and it cost us a lot of resources and nobody would use it at all. [Laughter] And that is a huge problem, if you ask me. So, that caused me, actually, to turn a bit around on how I perceive tools and how I do that kind of work. Otherwise, I’ve had a lot of bloopers in terms of products getting out and stuff not working.

Brian Dawson: Well, let’s dig in. I like the tool and it’s great, it’s different. What did you learn? I’m thinking and I’m gonna throw out that there was either, I thought a tool would solve the problem, but the problem was elsewhere or it didn’t, or was there just—you know, was it a miss in evaluating what the tool could do for you or was it a miss in the rollout of the tool? What did you take away from it?

Søren Pedersen: So, I got some really strong signals from the organization that they really needed an insight to go into the production so that they could monitor, and that’s really what we want to do in DevOps, right, and be productive and all that stuff. But the misjudgment was in how much effort it actually took to get the organization used to using this tool. And in the end, people found it too complicated. Even though we had trial sessions, we had long demo sessions and so on, that it really never gained any traction and we canceled it shortly after.

Yeah, and I think that’s the magic bullet thing. I have a pretty rude saying about it, but a fool with a tool is still a fool, right?

Brian Dawson: Yes.

Søren Pedersen: I was the fool in that sense. [Laughter]

Brian Dawson: There is—yeah, I always say, one of the reasons I really like that is, we oftentimes make the mistake and look, I’ve worked at software vendors for, now, the back half of my career. But I will be one of the first ones saying, “You can’t buy a tool and become a DevOps organization,” right? You can’t just buy a tool and become—we can help you get there.

Søren Pedersen: Yeah.

Brian Dawson: But it’s just an enabler. It’s not the magic bullet itself. I actually loved somebody I spoke with, Bob, I’ll attribute him, from IHG, I believe is the one that had the statement that everybody wants change until you actually ask them to change, right?

It’s like, we all want insights, let’s get insights—but hey, guys, you know what? To get insights, you’re gonna have to learn how to use the tool, you’re gonna have to change the process, we’re gonna have to integrate, and now, all of a sudden, it’s not as exciting.

Søren Pedersen: Yeah, for sure. But I also think, and also, you guys have done—there’s been a lot of, lot of progress in the tooling and what we can do nowadays. I think it’s become amazing. Coming from a world of Subversion and BuildBot for like a decade ago into what the modern tools can do, it’s just amazing.

Brian Dawson: Yeah, agreed.

Søren Pedersen: It is doing so much heavy lifting for the companies out there.

Brian Dawson: Agreed. Alright, I know I’m gonna have to let you go as I have to eventually let everybody off of the podcast. A couple of closing questions for you.

Søren Pedersen: Yeah.

Brian Dawson: What is a book, a podcast, or resource that you absolutely recommend our listeners go out and consume?

Søren Pedersen: I’m really—and this is going to be a bit boring, but I’m really a huge fan of Accelerate and how that’s built. If you want to get a bit into the management part and you want to get on that journey and you’re wondering, “Is this something for me?” then have a look. I think you'll see a bit of eye-openers there.

Brian Dawson: Okay. Phenomenal, phenomenal. Yeah, I mean, look, it’s an awesome book. I know, like you said, people have noted it, I’m not calling it boring, but the reality is, is they did a phenomenal job. When I look at now only my view of it but the converts of Accelerate, I’d say it’s Jez Humble’s CD, continuous delivery, book or the new era and for a wider audience.

Anything else? Any other podcasts, resources, or people you follow?

Søren Pedersen: I’m not too much into that, unfortunately.

Brian Dawson: Okay. So, everybody, Søren Pedersen says you absolutely have to listen to DevOps Radio if you want to be a better software developer.

Søren Pedersen: For sure. That’s the way to go. [Laughter]

Brian Dawson: [Laughter] So, any final thoughts? Do you have any final guidance, considerations, predictions, et cetera to share?

Søren Pedersen: I think people just need to get their toes dipped and get going on this journey. There’s a lot of stuff that can improve, and especially in the slightly more traditional IT world, that can become amazing if they want to do it. And I’m really excited to see what we can do with automation in terms of business processes, the whole RPA area is really growing strong. That’ll be a huge change for many businesses.

Brian Dawson: Awesome. Well, Søren, thank you for your time. I appreciate you taking a moment to share with myself and our listeners, and I look forward to talking to you again some time in the near future.

Søren Pedersen: Likewise, Brian. I appreciate the opportunity.

Brian Dawson: Thank you for listening to DevOps Radio, all. Please retweet, reach out to us with comments or suggestions. We appreciate your listenership. Thank you, Søren. Bye bye.