Anders Wallgren of Cloudbees on the Human Side of Software Delivery Management

Introductions [00:05]

Shane Hastie: Good day folks, this is Shane Hastie for the InfoQ Engineering Culture podcast. I'm sitting down with Anders Wallgren from CloudBees. Anders is the VP of technology strategy at CloudBees and has been a guest on the podcast before. Anders welcome back.

Anders Wallgren: Thank you so much. It's my pleasure to be here.

Shane Hastie: It's nice to see you again. Just in case people haven't heard the previous episode. Would you mind giving us a very quick intro? Who are you and how did you get to where you are today?

Anders Wallgren: Who am I, how did I get here? I have been working for about well, 30 years of my career, a little bit over 30 years of my career in software. And spent the last 15 years, basically, a little bit more, working on products in the DevOps, CI, CD space, release orchestration, release automation, those sorts of things. And working very closely with two teams, our product teams that are building the products that we sell to our customers, as well as helping them build those products. I still like to write code and those sorts of things. I'm a little bit of a hands-on person in that sense, although I do less of that as time goes on, sadly. But I still enjoy it. And then on the other hand, working with our customers both in terms of when we engage with them and deploy our products with them.

Anders Wallgren: And also if there's problems, or if there are challenges, or if there are new things that they want. And helping be a bridge between our field teams and our product teams. For me, it's a cool place to sit, because I kind of have this view of the people with the problem and the people who are building the solution. And yet at the same time, it's not my responsibility to make the trains run on time because I'm not the VP of engineering. And it's not my problem to, in great detail, come up with what is this feature going to look like, and all of those things, because I'm not the VP of product management. I feel very fortunate to be able to work in this situation where I get to work with customers. I get to work with technology teams and help bring the two together to where we're building the things that our customers need, and that will bring them joy. Or at least let them go home on time and have dinner with their kids. If we achieve that, I think we can call it a day and go home.

Shane Hastie: Sounds good. The human side of software delivery management is what we're talking about today. What does that mean to you?

The Human Side of Software Delivery Management [02:12]

Anders Wallgren: I think what that means to me ultimately, and this is something that if you're at all familiar with DevOps, if you're at all familiar with Agile, those sorts of things. Or trying to do organizational improvement, continuous improvement, those sorts of things. So many of the challenges that we have are people problems, people challenges. Or at the very least, I would say they are system problems. They're not software problems, they're not technical issues, those sorts of things. A lot of times the challenges are people are talking past each other or we're not in a safe space where we can express our concerns or feel free to say, no, I'm not signing up for that. I don't believe that's reasonable. Or we're not held accountable when we don't deliver what we signed up to in an appropriate way. Or we don't feel like we can trust our team members to deliver what they agreed to.

All of these emotional aspects of working in teams. Some of these things are very well understood because people outside of the software industry have been working that problem for a long time. And very little of that, I think ultimately is original or unique to software problems. But software is so dominant in our world today in terms of its impact on our lives. There's the phrase that you hear thrown around a lot, "Every company is a software company." And it's kind of true. My toaster has software in it. I never thought I'd see the day, but actually I should say just in the interest of truth, my toaster doesn't actually have much software in it, but there are toasters out there that do, and refrigerators, and all of that sort of stuff.

And if you look at things like cars, what do people care about nowadays, aside from does it burn gasoline or not? What do people care about? How good is the entertainment system? How good is the GPS system? Does it have a fancy, nice display? The softwares parts of it. And that's where a lot of companies compete against each other now. Not on the hardware, not on those sorts of things. Obviously, that's not a 100% true in all industries or in all things, but boy is it much more true than it used to be.

Shane Hastie: DevOps, Agile, all about collaboration, communication, we talk about cross-functional teams. Just DevOps in and of itself, removing the barriers, removing the silos. How are we doing at that?

The Most Challenging Aspect Often is Getting People to Work Together [04:25]

Anders Wallgren: I've split brain syndrome on that. I think we're doing incredibly well compared to where we were. And I think we are not nearly as far along as we think we are. I think a lot of times, and I say this based on the fact that I participate in a lot of conferences. I go to a lot, well, not physically these days, but soon hopefully again. I go to a lot of conferences, I attend a lot of conferences, I speak at conferences. And so you hear a lot about here's how we're solving the problem. Here's what we did. Here's how we're awesome. All true. All awesome. All great. But I also, like I said, I worked with a lot of our customers. Our customers are awesome. They're great. But they also have big challenges still. And I think it's easy sometimes when you're at DevOps world, or you're at DevOps enterprise summit, or you're at Qcon or something like that. To think like, oh, we got this nailed. But you don't have a nailed until it's in everybody's hands deployed successfully and they've done all the other work that needs to happen.

You don't deploy OpenShift and boom, your problems all of a sudden go away, or deploy, or switch from SCMA to SCMB. These are not generally tooling issues. The technology part is the easy part. And I think what's really, truly the difficult part oftentimes is getting everybody to work together efficiently. And getting everybody to look at the problem with a sympathetic and empathetic point of view, where I can truly see what your perspective is on the problem, you can see what my ... We walk a mile in each other's shoes basically. And sometimes you can look at the same data and see different things. Neither perspective is necessarily wrong or right. Sometimes it is, but not always. And also sometimes we're looking at different data, sometimes I'm that support person working with a customer.

And so I'm looking at their tickets and I'm looking at how many times they've called us or contacted us. I'm looking at are they happy? What has the feedback been from the customers after we close out their cases and so on. So, I have that perspective. If I'm the engineer working on the product, or if I'm the product manager of the product then I'm thinking of, what's the next thing I want to build for the next 1,000 customers that I want to acquire. I'm also obviously thinking about how do I keep my current customers happy and satisfied and so on. But we have different perspectives that we come at each day from. And that shows because if you have an unhappy customer or a customer with a challenge, it can take a long time. And let's pause it for the sake of my example, that we're going to have to make a product change to make the customer happy.

Whether it's a bug or a request for an enhancement or a feature that hasn't been delivered yet that's late, or whatever the case may be. But we need to engage the technical teams. We need to engage the DevOps chain and the DevOps pipeline in order to make this work. Whether at the end, that offer's going to go into a mobile device, or on a website, or be deployed in somebody's data center. Really the differences between those things are much smaller than I think we think, kind of how all of our DNA is 99 point something percent the same, even though we all look very different to each other. And I think there's so much data, there's so much opportunity out there once we start to do and knock down some of the things like automation, and orchestration, and start to be able to sort of pull from some of these data sources that we have with all this data in there.

Looking at Data from Multiple Perspectives [07:31]

Anders Wallgren: That once we get to the point where we're all wanting to work together, and we can all start to look at the data a little bit the same way and represent everybody's perspectives in that data. I might be looking at a feature, but I'm looking at it from the perspective of the product manager. Is it designed? How's the implementation going? Have we shown it to users yet? Can they start to trial it or those sorts of things. And the customer support person or the sales person is engaging with the customer in terms of, are we there yet? Is it done yet? Have you fixed my problem yet? We all come at our jobs with those hats, with those perspectives on. Very few of us, if any, are the kinds of people where we're natively capable of looking at things from all of those perspectives. Sometimes you got to be brought there in a certain way.

I think the technology thing is not easy, solving the tool chain problems, or modernizing your tool chains, or modernizing the architecture of your product to make it easier to do these kinds of things. Those are absolutely big technical problems. They are cultural, human problems usually will get in the way first. It's much more common I think to engage with an organization, even our internal product teams, because we're no different. We have the same aches and pains that all software organizations do. But I think a lot of it is communication. And I think it's interesting because you mentioned, and I think we talk a lot about cross-functional teams and I think I've seen a few times in the last year or two where cross-functional teams become a little bit dysfunctional in the way that when you send out an email with 10 people in the two line, everybody assumes it's one of the other nine people's problems to solve. We have a cross-functional team.

Building Trust and Forming a Real Team Takes Time [09:02]

Anders Wallgren: We have all the stakeholders, not necessarily in the room at the same time, obviously not now. But not necessarily in the same room at the same time, but there are all these problems out there that need to get solved. And a lot of times it's sort of like, well, now that's a product management problem. Well, no, no, that's a support problem. Well, no, it's a ... And I think the more people work together, and the more we build the trust in each other, and the more that make a mistake and we learn from it and we get better or we do something really well and figure out how to do it even better. You're not cross-functional on day one. Even if every organization is represented, is that the table, to build the thing that you're about to set off to build. You're a cross disciplinary team at that point. You're not cross-functional because you're not functioning yet. And I think there's that phrase, and I don't know who to attribute it to, so I apologize for that. But as a team you're forming and then you're storming and then you're norming.

I think I got that right. You're getting to know each other. And then once you get to know each other a little bit, now you start to oppose each other a little bit and you feel comfortable to push back and you're storming a little bit. And then at some point you norm and you sort of figure out, I hope I'm representing these right?... But then you're starting to work through that a little bit. These are the ways that we work together and these are the ways that we work together well, less well, those sorts of things. Unless you're in a very small organization or something like that. Until you get the functional aspects going, the cross part doesn't really apply. You're only cross-disciplinary on day zero. It takes a while before you're cross-functional, you might be cross-dysfunctional.

The Software Industry is Maturing Through Cultural Changes [10:27]

Anders Wallgren: That's not good either. And you see a lot of that obviously because we're human and we're flawed beings, it's culture, and psychology, and safe spaces, and listening well, and all of those things are just so incredibly important. And it's really good and great I think that in the DevOps community, in the Agile community, in the CD community, I think we know these things, we've named them, we've said culture is important. Now we've got to go fix it. And that takes work and that's difficult. And then I think we know a lot about how to fix technical problems. And new tools come along all the time and new ways of doing things and so on. That is an ever evolving thing. And I think where we're building maturity in the software industry in a meaningful, sustainable way is on the cultural side.

We have to do that, right? Because without that, we don't have secure software, without that we don't have quality software, without that we don't have software that does what the customer needed it to do. Even if perhaps they didn't know how to express that, or we didn't know how to hear it. And so that's good and exciting to see, we've got a lot of work to do there still though. We're circling back to where I started as I think we're doing a lot better than we did. And I don't think we're probably doing as well as we think we are. There's still a lot of help to be had out there and to be given out there.

Shane Hastie: You mentioned, you talk with your clients a lot. And so you're getting insight into this. What is it about the organizations that have got this culture thing right, that you could point to and say, here is something that people might want to not copy, but be inspired by?

The Importance of Feeling Safe to Push Back [11:52]

Anders Wallgren: I think a lot of it is psychology, I think. I'm unqualified to speak in clinical terms obviously. But everybody feeling safe to express their opinion. I can't count the number of times that I've interacted with a team over my career and when we're having the big meeting, everybody signs up. So yeah, well, I think we can build this in the next N number or X number of sprints. And then you break up the meeting and the technical team goes off or some subset of the technical team goes off and go, oh my God, what did we just sign up for? But I didn't feel comfortable pushing back. If I had a dollar of any denomination for every time I heard, like I didn't feel comfortable pushing back. I would have hundreds of dollars, thousands of dollars.

Anders Wallgren: I wouldn't be able to retire on it, but it'd be a pile. And I think that's in some ways the biggest thing, because if you're not listening to when people are uncomfortable, if people don't feel comfortable pushing back this can very quickly turn into where all software engineers don't like to do estimates and don't like to do schedules, and those sorts of things. Which I believe is a true statement. Every software engineers just wants to sit down and write code. But it's really more about, look, we have to engage with each other so that the paragraph that you've written for your idea, Mr. or Ms. Product manager, I need your help to flesh that out into what that means. Because I can't just go dump that into a file and compile it. It's not source code. So, we need to engage so that I can translate what you're saying to me, what you've written down into code.

Challenges of Communicating Estimates [13:20]

Anders Wallgren: And that's a process. And that means that the technical side of the house, probably shouldn't even be talking about in terms of sides of houses, but the technical aspect of this that we think in terms of what's possible, we think in terms of where the state of the art is, we think in terms of what's mechanical, easy. What I've always done with teams when there's conflict or tension around estimates and accuracy and those sorts of things is, well, let's do one thing at least. When we give an estimate, talk about our confidence in that estimate and the nature of that estimate. Is this one of those things, for example, where this is mechanical, I've done it five times before there are 15 of these things I have to do. They will each take between two to eight hours.

So, let's do the math. And so that means I probably have a fairly high confidence in my estimate, assuming that I control my time. If I don't control my own time and somebody can yank me off the project then forgot about it. That's one kind. And then there's the part where, okay, this is the space where we're innovating. This is the space where we need to come up with a new way of doing something, where we need to have some architectural cleverness or move the ball a little bit there. Those things are by their very nature are much more uncertain and you can go down dead ends in those things. And the teams that have done that for a while, and especially if you really get into the agile processes and little a agile in this case, scrum or Kanban or whichever flavor you prefer is fine.

I generally talk in little a agile in those terms. It's really all about how do we learn to communicate in those terms so that you believe me when I tell you that this is a firm estimate, and you believe me when I tell you that this is not a firm estimate. You can do that through ranges, or you can do that through kind of here's a time and a confidence estimate. Once I worked at a company where we built a system out of that for our own use, where we basically use the confidence estimates as a multiplier on the time estimates. If I had high confidence, it was this multiplier, if I had low confidence or mechanical or in inventory, sort of things that in the end, things average out a little bit that way. I think that's the space that you have to be in.

Look for Full-Stack Teams, not Full-Stack Engineers [15:19]

Anders Wallgren: You have to be comfortable from the technical perspective. You have to be comfortable asking for example, your product managers. Look, I need more specificity here. That two sentence description, I can build a million different things out of that. Probably only two of which you will look at and recognize so let's dig into that. And at the same time as the technical person on the side of that equation, you've got to realize that the person you're talking to isn't necessarily a software engineer, doesn't necessarily understand the architectural aspects of this and it shouldn't. I mean, a few times you hear back that phrase, ahhh, well, you need more unicorns. Well, unicorns don't exist, they never have. And the full stack engineer is a little bit of a myth. Luckily I think most people these days talk about full stack teams, cross-functional teams. Not full stack engineers, they exist.

There are definitely a few unicorn looking type things out there. But you're not going to go find a hundred unicorns to build this out. That won't scale. Let's put it that way. I think it's really about engaging in that collaborative cross-functional space of tell me a little more about that. Tell me more about what you mean by that. One side draws out the other one. Okay, that's difficult to implement. What do you mean about that? Does that mean that you've never done it before? Or does that mean that nobody's ever done it before? Because that would be a big difference. Or when you say, oh, well this is really important for our customers. Well, does that mean every customer or this kind of customer? Is there a segmentation around that?

What Good Collaboration Feels Like [16:41]

Anders Wallgren: And really drawing each other out on these things so that we all have the perspective that's necessary so that when we inevitably go off in our own corners to do our own individual work, even though we can collaborate all day long and we can do extreme programming and all of those sorts of things, but in the end, we're up here in our own headspace when we're making good progress on this stuff. Not all the time, because the collaboration is hugely valuable of course, I don't want to tip the balance there. But we have to understand if we're going to go off in the right space, in the right direction, we have to understand each other. And we have to make sure that we've communicate it effectively what it is that we're trying to build, and how we're trying to build it, and what it should look like, and what it should do, and when, and in what order, and all of those sorts of things. And I think the safe space aspect of this to where we can feel okay to say, well, tell me more about that.

Double-click on that for me, giving me some more details because I don't understand you. Or no, I don't think we should build that, here's why. Or no, I don't think we can build that, here's why. Or no, no. I think we can. I think that's actually easier than you think. Or what if we do it ... You know what I mean? So, that you can have those aha moments. Because every once in a while you have one of those meetings where really are cross-functional, where the team gets together and you walk away from that going, okay, wow, I think we get it now. And I think we all have the same picture in our heads. And I think we understand what we need to do next, maybe not every step all the way to the end. But we're going to go off and we're going to do the next sprint, two sprints, three sprints, whatever the case may be and do something. And for teams that have worked together for a number of years, you figured out how to do that or you probably wouldn't still be a team.

The Value of Effective Reteaming [18:13]

Anders Wallgren: But as you're forming and reforming teams and unforming teams, you might not have one, say, security person or one DBA, database expert that's able to work with every single team so that you can bed them permanently. You're always going to have skill sets that you need to bring in for a period of time. And then they sort of float away to their next project or product that they're going to work with. It would be nice if we had five to seven people cross disciplinary, working on every single microservice that we have dedicated. But that's not the truth, because I might have 500 microservices in my company, but I may not have 2,500 people to work on them. I may have 250 people to work on that. So, I'm not going to be able to dedicate people to that.

So, you have to be able to move around and be flexible. And I think the more comfortable you get with the forming storming parts of building a team and getting to know each other and building trust and those sorts of things, or the quicker you get to where you're actually being productive and putting stuff out. A little bit of a meandering answer to your question there. But those are the things that when teams start to get that right, you see the gleam in their eye, you see that they enjoy it, you see that they have fun. Because everybody loves being excellent. Nobody loves being mediocre. And oftentimes what ends up happening when we're not communicating is we feel mediocre, because I didn't build what you asked for, because I didn't understand what you asked for. Or any one of a number of different ways that that can go wrong.

But you see it in people's eyes when they're enjoying it. So, that's goals. You want that gleam in people's eyes when they're like, okay, I get it. Let's go. Let's do it. That's what everybody lives for. Well, we all live for our families and all that sort of stuff. But in the space of what we're talking about, that's what we live for is when you get to that point.

Shane Hastie: One of the points that you've made when we were chatting earlier was the future is in features. Tell me, what do we mean by that?

The Future is in Features [19:57]

Anders Wallgren: There's two ways I talk about this. The future is features, which is a reference to the movie, The Graduate, the future is plastics. For those people who are not of a certain age to have seen that movie and have internalized that the way I did. But the other way I put it is the goldilocks problem of software, which is really where I get up this. If you think about where we were say 15, 20 years ago and beyond, we lived in a world of releases. And releases at that point was a 18 month slog. It was waterfall, death marches, whatever analogies you want to bring into that. That death march might be a little dramatic, but slog certainly is not. But we have these huge things and they were monolithic and we couldn't break them up.

And they were all delivered, all at once or not at all. And then we pivoted a decade or more, well, more, a decade and a half or a couple of decades ago, to continuous integration to where it's all about the build. And part of the reason for that is we were very dysfunctional in the mechanics of how we built, tested, qualified, and released our software. That was necessary. But the problem with the build is that's a very small thing. This is where the goldilocks part comes in. We used to have these huge things called releases. And we had these tiny things called builds and what we really ought to be and are starting to focus on in the industry is features. And I use the word features in an imprecise way to mean either literal features, or a bug fix, or a vulnerability fix, or an enhancement, or something that when the customer gets it, they go, thank you.

And they derive productivity, or joy, or revenue, or whatever it is that they're looking for to get help with from your software out of that. A customer obviously doesn't care about a build. That's a no brainer. But a customer also doesn't care about a release. I only care that you fix this one bug. That's all I'm asking for. All I want is this one feature that let us stop doing so much of X and start doing more of Y or Z. That's the level, and yet what we're still kind of stuck in a little bit in terms of what our systems are capable of doing inside of the software organizations, is we're thinking in terms of bug tracking issues, or stories, or epics. Now stories and epics start to get to where we're a little bit closer to what I mean when I say a feature, I think. That much is clear.

And so I think from the Agile perspective, we've got our head wrapped around this in terms of think big, decompose, get to the point where something is small and well understood enough that you could put an estimate to it. And you can't always be accurate. You can't always decompose it that way. Sometimes you have to be wrong 10 times before you're right once. All of those sorts of ways that we have to learn and work through these things. But not all of our systems think in those terms. And it's often very difficult then to say, okay, well, how far along am I on that future? How many pull requests have I done on that story or on that epic? How many bugs have been filed by customers or by turning people against that feature, or that epic, or that story? What are usually my cycle times and this area of the code? Whether it's a deployment cycle time or a meantime to recovery cycle time, or a building a feature from scratch cycle time, or fixing a vulnerability by updating to a later version of a dependency kind of cycle time.

All of those things. The customer cares about features. Most of the tooling that we use cares about all of the individual low level things and helps us manage the low level things. With RCM systems, it's commits, or it's merges, or it's branches, or it's pull requests. With our issue tracking systems it's bugs, epics, stories, tasks, those sorts of things. With our support systems, it's tickets. With our sales folks, it's pipeline, and it's forecasts, and it's customer doesn't want to renew because X, Y, Z kind of reviews. And really once we're able to start to pull a lot of that data together more effectively with products that we're building products that other people in the industry are building. Once we're able to start to synthesize this a little bit, we'll start to be able to answer the questions in terms that are more useful to the customer.

How far along is this feature? How long did it take us to do this kind of thing last time? How long does it typically take to do these kinds of things? What's blocking this feature? This ought to have taken less time. Why has it not? And start to be able to pull the data together a little bit more. One of the things that I talk about is, from a cultural aspect, we've done a pretty good job. Again, there's that sort of, we're doing a good job, but not as good as we need to kind of thing. But we've done a good job of breaking down a lot of cultural and organizational silos. Dev talks to Ops and Ops talks to Dev. QA and Dev talk a lot more and interact a lot better. Product management and engineering talk a lot better.

DevOps has Helped Break Down Work Silos – We Now Need to Break Down the Data Silos [24:27]

Anders Wallgren: We've spent a lot of effort and I think gotten fairly good returns on lowering the walls, breaking down the silos culturally and organizationally. What I think we still have, or now have even more of in fact is data silos. I have my issue tracking system with a ton of really useful data in it. And I have my SCM system, which has a ton of useful stuff in it. I have my customer support system, my sales tracking system, and probably a 100 other systems. And pity the poor product manager, or engineering lead, or customer support manager that has to answer a question that requires traversing those systems to derive an answer, because you're probably going to be asked that question quite often. And that means you're going to have to put on your wetsuit and put on your snorkel, and your mask, and dive into the data and swim around a little bit to get the answer, because you can't ask the question of a single system.

And so I think what we're seeing, and this is not necessarily, in fact, it's specifically not saying, just to use one system for everything, because that I think is not realistic. And in fact, in most cases, people want to use best of breed tools for every aspect of what they do. And they want flexibility in what tooling they use, because they may not have one type of problem to solve, or one tool is going to solve that problem for every part of the organization. But that we have at least one place where that data can live. Where we can query it. We can look at it… We can look at it over time. We can look at it for one specific feature. We can look at it for one specific team or product, one specific customer, one specific prospect, those sorts of things, without having to spend the entire morning or the entire afternoon logging into eight different systems. Some of which I may not be able to log into by the way, because if I need some salesforce.com data, I don't have a sf.com login in my organization.

So, when I need that kind of data, I have to go get it from somebody else and vice versa. There's a lot of people in sales that don't have access to our issue tracking system. You don't even always have access to the system and anyhow that could be for organizational reasons. That could be for financial reasons. It could be for security reasons. It can be for a number of reasons. But what we can do is start to sort of pull the data out of these systems and put it in a place behind functionality that allows us to start to answer these questions on an ongoing basis, and maybe even start to be helpful and even slightly predictive of where things are going to go wrong. Now I'm speculating a little bit, because I have a feeling that once we start to throw machine learning at some of these things, once the data is in place, that we'll see some interesting things.

The Value of Having a Consolidated View of Data from Many Systems [26:47]

Anders Wallgren: But I think the future is in features because that's really what the customer cares about. It's really the level at which they engage. It's why I hate every single mobile app release notes that I read because it always just said we fixed some bugs and improve some performance. Which I personally think that both Google and Apple should reject any app release that has only that as the release note. And that seems to be about 98% of them, but I digress. I think that as technologists, and as engineers, and a software developers, as we come up for air from our CI systems where we live the build, and we have our product managers, and our engineering leads who have live the release, whether that is a release that happens 10 times a day, once a week, once a month, once a year, whatever's appropriate. But as I'm fond of saying, even though I do not have a pace maker myself, if I had one, I would not want the software on that thing to be updated once an hour. That doesn't seem like a good idea to me.

Continuous delivery of software into my body is probably not something I'm looking for, but I digress. But whatever the process is and whatever the, say regulatory environment that you're in in terms of governance and audit controls and all of those sorts of things, we want to meet in the middle here around features where we can manage delivery of features for our customers in a more sane, and predictable, and straightforward way as opposed to the, well, I think that bug was fixed and then I think the code was checked in and was built in this build. But I'm not sure. We'd just go test it, just go log in and test it. Because I can't really tell you whether that build actually contains the fix for that bug that the customer is asking for.

The Danger of Islands of Automation [28:22]

Again, if I had a dollar of any denomination, every time I had heard that I would have a stack of them. That's the kind of stuff that I'm excited that we're building at CloudBees. Not to turn this into an infomercial, but that's what gets us up in the morning, building product and functionality around those sorts of things. And then obviously all of the automation and orchestration that we need to do still in many organizations to be able to get to the part where we have all the richness of data in our systems, that we can answer these questions. Because it's pretty difficult to answer questions about manual processes and have them answered accurately, and frequently, and over time, and all of those sorts of things. I think we all know that, but of course we still in many, if not most organizations suffer from some form of either manual process or what I call islands of automation.

Like this part is automated and then there's a manual handoff and then this other part here is also automated. And then there's a manual handoff. And if you look at any sort of studies on this stuff, the manual parts of where the cracks are. That's where the mistakes are made. The balls are dropped, however way we want to put that. And so I think bringing more automation and orchestration to bear on the problem is a good thing. Clearly that is not sufficient to make us good, well-functioning, cross-functional able to deliver wonderful, exciting, joyous software experiences to our customers. But it's definitely part of the solution. And then you layer a good culture on top of, and you layer reasonable, efficient, evolving, continuously improving processes on top of that.

And now you got something. Now you got a really good chance of success. I think that's where I get excited is when we start to leverage the fact that we've torn down some of these walls, where we've dropped some of these silos to where now we have a new problem. It's always good to have a new problem. Now the problem is bring all the data to where we can answer these questions and start to look at it through the lens of features, functionality, because that's what our customers care about. Not releases, not builds. That's my goldilocks story about software.

Shane Hastie: Anders thank you very much indeed. If people want to continue the conversation, where do they find you these days?

Anders Wallgren: Cloudbees.com of course, in terms of finding out more about us, on Twitter you can find me at Anders_Wallgren, two Ls, one E. Unlike the drug store here in the United States. But yeah, I mean, those are ways to reach out to me. And of course LinkedIn, if you want to reach out to me in particular. And then hopefully in the not so distant future, I hope to be seeing all of us together in the same room, raising a beer or the beverage of your choice to having worked through, as people seem to be euphemistically fond of saying “the current situation”. That was how the airline that I flew on a few months called it. Due to the current situation. Can we just say pandemic? Can we just use the word? But yeah, no, a joy to talk to you and a joy to talk about this stuff because it's fun, it's exciting. I think we're all making a difference in the world with this stuff.

Shane Hastie: Thank you so much.

Anders Wallgren: My pleasure.

Mentioned

• CloudBees
• Anders on Twitter