Episode 77: ASG on the 2020 State of Software Delivery Management Report

Brian Dawson: Hello, this is Brian Dawson coming to you with another episode of DevOps Radio. Today with us, we have Mitch Ashley, the CEO and Co-founder of the Accelerated Strategies Group. Mitchell, can you go ahead and say hello and tell us a bit about yourself?

Mitch Ashley: Hey, Brian. Thanks a lot for having us on. Mitch Ashley here, CEO with Accelerated Strategies Group. My background is, I'm both a Product CEO and CTO in cyber security as well as cloud SaaS services and all kinds of background in different industries. And then I've also been kind of on the IT side. I started as a developer, DBA architect, moving into eventually being CIO, and I've kinda tossed back and forth. So, that puts me in a hopefully unique position as head of an analyst firm.

Brian Dawson: Yeah, yeah—no, I love it. And having perfect transparency, I've spent a lot of time working with Mitch and I actually love the fact that you've come out of sort of your private gigs and you're spreading your lessons, learnings, and fantastic radio voice with the rest of the community. So, thank you joining us today.

Mitch Ashley: You bet.

Brian Dawson: Also, today with us, we have the pleasure of having Sanjeev Sharma. He’s the Principal Analyst and Co-founder of Accelerated Strategies Group. Hello, Sanjeev.

Sanjeev Sharma: Hey, how are you doing? I'm glad to be on this broadcast on this recording of your DevOps Radio episode, Brian. I'm just excited to be here. My background, I have been in the application development, application delivery space my entire career. All of my career, I spent the majority of its time actually at IBM, I was there for 15 years, and I was the first DevOps client-facing practitioner at IBM, pretty much started the DevOps practice there. For six years, I was the Global CTO for DevOps Adoption at IBM where I was working with IBM’s clients, helping them adopt DevOps. 

After that, I held various roles. I led a cloud architecture practice, I led a Data Ops practice at a Silicon Valley based startup and then, since the beginning of this year, with Mitch and a few others, we've been going into the analyst world and doing some analyst and advisory work with Accelerated Strategies Group.

Brian Dawson: I love it. Not one to sit and rest on your laurels, huh?

Mitch Ashley: [Laughter] 

Brian Dawson: And you also skipped something that, at minimum, is interesting trivia, but I think is important—you're also the author of The DevOps for Dummies book, right?

Sanjeev Sharma: Yes, so I need to clarify that, right? I've written two books. The first one was DevOps for Dummies, it was the IBM edition, which is a booklet, like a short book where you can download from IBM.com. And the reason I want to clarify that is that there is a commercial, a full commercial-sized DevOps for Dummies available in the market today. I did not write that. I have had no affiliation to it, but I'm sure it’s a great book.

The second book I wrote is The DevOps Adoption Playbook, which is a commercially available book and I'm very excited about that adoption it’s had, and it’s done very well even three years after publication. It’s actually going pretty well and a lot of people have asked me about it and have commented on the book just, you know, as recently as this week.

Brian Dawson: Well, you're gonna make that as recently as today, because I'll tell you, I've read both of them, and both of them have had some influence on the work I do here.

Sanjeev Sharma: Nice.

Brian Dawson: As a matter of fact, some of our projects I've taken on have been modelled after the IBM booklet. So, now you have one as recent as 30 seconds ago. [Laughter] 

Sanjeev Sharma: Awesome. Wonderful.

Brian Dawson: So, guys, great to have you. Now, we've mentioned Accelerated Strategies Group, which you guys are co-founders of. Can one of you tell myself and our audience a little bit more about what Accelerated Strategies Group, or ASG, is and what you do.

Mitch Ashley: Well, I guess that’s my turn to talk, because I get to tell everybody what we do and then Sanjeev gets to do it, so here we go. [Laughter] 

So, I've been, as I mentioned, I've been on both sides of the industry and worked with analysts in both cases, right, as a consumer of IT technology and creator of it. And there’s been so much disruption in our industry with DevOps and cloud and all kinds of great things. Honestly, the analyst industry, it really hasn’t changed. It’s just kinda grown, it’s doing what it did 30 years ago when I started my career.

So, Accelerated Strategies, the whole idea is to flip it on its head. Let’s do something very different. So, rather than kind of getting everybody to pay at all places around the table, around the poker table, we really work with a few companies. We work with product companies, we work with IT organizations. When they engage with us, we do analyst work—we do research, we do reports, we do advisory. We also do media events like webinars and speaking at conferences, workshops, those kinds of things. 

But the unique thing about—a couple unique things about Accelerated Strategies is, we take kind of an open source version of the analyst business. All of our content is free. We give it away for free. We don’t charge you to download it. We want it to be as widely available and used as widely as possible. So, you can go to our website and download our reports, you can watch our videos in a number of places, DevOps.com as well as Accelerated Strategies site, which is A-C-C-E-L-S-T.com. 

Another unique thing about our business is, you know, we're a group of 10 analysts, but when you look at our lineup, if you can pardon or allow me to use this expression, it’s kind of a superhero approach to it where we have people who have their own powers, their own superpowers, their own strengths in their experience. Like, take Sanjeev, you heard his background—he has extensive experience. He’s been there, done that, he made the T-shirt, in many cases, right?

Brian Dawson: Mm-hmm.

Mitch Ashley: So, there you go. He’s got one on our video, here. [Laughter] So, all of our analysts are like Sanjeev. They're people who have been in the industry, who really built a strong reputation because they've been there, done that, became authors, you know, we've got people like Gary Gruver, Helen Beal, Marc Hornbeek, Bob Reselman—a number of folks who don’t come out of the traditional analyst role. They come out of roles of been there, done that, know the technology, know what it really takes to use it and have had to play leadership roles, and those are the folks that are doing our research. Those are the folks that you talk to when you get on a call or you do an interactive session, you know, like on a webinar or something.

So, those are just a few things that make our firm unique, but we're out to turn the analyst business on its head and do a 180. And so far, you know, we're making some good progress.

Brian Dawson: Awesome, awesome. Thank you for that. And I can appreciate that, having interacted with you guys in your team for a bit over time—just a really, really strong staff of people. And what I do love is where your approach aligns more with software development of today and the DevOps movement with the open sourcing of content, the value of real practitioners, right, and then I happen to know, personally, the collaborative approach that you take, so I appreciate that.

Mitch Ashley: Excellent.

Brian Dawson: Real quick before we move on—Sanjeev, anything to add to that? Do you wanna share what your superpower is or add anything to what Mitch said?

Sanjeev Sharma: So, I think the superpower we all bring is that we are practitioners, right? Currently, we are engaged with actual transformations going on with clients we are working with. So, this isn’t, for lack of a better term, a bookish knowledge or knowledge which has been absorbed by observing people from afar, but actually knowledge which we have gained by actually doing it, right? You know, we want the scars to prove it.

Brian Dawson: Right.

Sanjeev Sharma: And we can point to organizations where we help them improve not by advising them, but actually, you know, getting your hands dirty with them. And, you know, of course there was advisory work involved, right? I mean, a lot of us have worked for companies where we were embedded into end clients or we were independent consultants. But it is all practitioner level work where we actually have our hands on the keyboards doing work and helping companies go through the journey and learned from the lessons—learned from the successes and from the failures.

Brian Dawson: Awesome, awesome. So, thank you, guys, for that introduction. Now, to shift to the topic at hand—recently, ASG, under the guidance of, you mentioned, Sanjeev conducted a survey around the topic of software delivery management, correct? 

Before we dig into the survey, which I'm really excited about, because this is really close to me, can one of you tell me a bit about what is software delivery management and why was this survey important to take?

Mitch Ashley: Let me set a little bit of context around what is software delivery management, and Sanjeev, you can really help fill in some of the details.

I think the ultimate problem that all of us struggle with, whether you're creating products and technology or you're a consumer of it in the software or virtual infrastructure world is, we are trying to respond faster to threats, changes—whether it’s from COVID and the financial crisis or simply competition and disruptive business models. And we want to produce, we're in a software enabled world. We're in a software powered world. That’s what’s differentiating everybody. That’s how you create the Ubers and all the companies that are driven by apps.

And so, part of this idea is—well, creating software is great, doing it faster is better, but doing the wrong software and creating the wrong stuff at the wrong time doesn’t help. So, how good are we, how mature are we as organizations at software delivery? Stepping back, not just from one part of the software process, but looking at, if we put a dollar in on the left side, do we get a dollar and a half worth of value or more out of the software because it hits the button the first time, we got what we thought, but maybe even better. 

And that’s what software delivery management is really about is understanding the management of how we work, not just what work we do. And so, Sanjeev’s really architected a brilliant research project that we think is really gonna tell us some insightful things. Because if you're in a situation today figuring out how do you respond to contactless services or we're reprioritizing and now all of our digital projects are accelerated—no pun intended—and need to happen more quickly. Is it gonna happen, and how do we know? How mature are we at doing that?

So, with that kinda setting the groundwork, Sanjeev, if you wanna take software delivery management and really tease that apart?

Sanjeev Sharma: Sure. And you know, again, to kind of dovetail on what Mitch just said, right, every organization we talk to today is undergoing some kind of a transformation, right? Either it’s at the business end where they're doing a business transformation and they want to improve customer experience, they want to improve their operational excellence, they have operational processes, they have—maybe they're experimenting with new business models which, you know, with COVID, a lot of companies had to do, right? 

From an operational process, they had to change from all, everybody is collocated to everybody is distributed. From a business model, they had to go from people come to me to buy stuff to me, I have to now somehow remotely get to them. You know, from a business end, you know, things—and this description, I know we are talking about in COVID because of the time, but this is valid irrespective, right? Transformation is happening all the time, it’s just that we've got a shot of adrenaline to say, “You've got to act now on that transformation.”

On the other end of the spectrum, if you look at the transformations which are happening on the IT side, you see three major vectors. One is modernizing applications. People have legacy applications, they can’t renew it fast enough. We've got to modernize those.

The second one vector which is driving change today or transformations today is cloud. How do I adopt the cloud? How do I move to the cloud? How do I leverage the cloud? I mean, I can lift and shift to the cloud, but I'm not leveraging the cloud by doing that. All I'm doing is going from capex to opex. How do I fully leverage the cloud to be, you know, manifest all the values cloud brings to me with cloud services.

And the third is this whole AI and machine learning space, right? How do I enable my application to become data rich and growing, for instance, and outcomes from the data I have?

The common factor between all of these, no matter which thing you are trying to do, all six of these is the ability to delivery software.

Brian Dawson: Mm-hmm, mm-hmm.

Sanjeev Sharma: Effectively, efficiently, and without killing your people or hurting them really bad. You know, killing is a bad way to express it—but without burning them out, right?

Brian Dawson: Right.

Sanjeev Sharma: What, you know, in the DevOps world, people like Gene Kim call, you know, a happy organization, right? How do you maintain the happiness in the organization? And that’s the cultural aspect of it, right? 

So, whichever vector we might—whichever variable we might look at, right, whether you're trying to deliver software faster, cheaper, higher quality, without burning out people—it all matters down to, in my software delivery pipeline, in my ability to deliver software, where are my inefficiencies? Where am I making money, where am I losing money, where am I getting value, where do I need to invest to increase my value? 

That, to me, is software delivery management. Looking at it from not just do I get flow, you know, one of the metrics a lot of people use is how frequently can I deploy? How often can I deploy? Can I get flow? Whatever many, you know, how much of a backlog am I retiring?

All that is irrelevant if it doesn’t produce any value.

Brian Dawson: Yeah, yeah, yeah.

Sanjeev Sharma: It’s totally irrelevant how fast are you going—you are going faster, but if you're going in the wrong direction, you're just getting there faster, it’s going to cost you more to get back on track.

Brian Dawson: Right.

Sanjeev Sharma: That, to me, is the essence of, you know, especially what we focused on when we talked about software delivery management in the context of a survey in order to make that connection between flow and value, not just flow. Because flow without getting—without getting the right value results in software nobody uses.

Brian Dawson: Yeah, there’s—well, first, thank you, guys, for those explanations. That’s great. I think that adds a lot of clarity. There’s a couple of things I'm gonna want to steal from you, so don’t sue me if you hear me say it later. But yeah, I was gonna say, you know, there’s this attitude—wipe my hands, I hit commit, I saw that the build succeeded, it landed on a server, I'm going home, I'm done, right? That’s what software delivery is. But I think you guys are calling out that—no, just getting code from a repository onto a server doesn’t mean you've driven ________, right?

Mitch Ashley: Mm-hmm.

Brian Dawson: And I almost hear from you, Sanjeev, that I hadn’t really thought about is—you know what, the ability to go fast without managing it such that we're ensuring we're developing the right thing may just help us screw up faster, right? [Laughter] It may just help us make bigger mistakes at a higher frequency, right?

Sanjeev Sharma: Right, and that’s okay in the early stages where maybe you are experimenting, right?

Brian Dawson: Right.

Sanjeev Sharma: But once your software is a bit mature, then the cost of an experiment goes up very high. Maybe you are experimenting with a feature, that’s fine. You know, should the button be on the bottom left corner or the top right corner—those kind of experiments, we are not talking about.

When you start talking about how you are going to engage a customer, how you are going to charge a customer, when you are talking about how you are going to change your business model—those experiments, if they are not done properly, you can invest a lot of money going down the wrong path. And if what you're focusing on is deployment frequency and how quickly you're retiring your backlog and getting code to production is your measure of success—

Brian Dawson: Right.

Sanjeev Sharma: Whether somebody uses the code or not or it adds business to the customer or not or the business value to the customer or the business, then what’s the point? Right? You just got their—you know, you have to retrace all the way and start, you can lose a lot of money, a lot of investment can be lost very quickly if it is not invested properly.

Brian Dawson: Okay. Now, I'm gonna, to go off topic for a minute, before we dig into the survey, I wanna challenge you guys with another question, okay? You gave me the response. I heard about value, business impact, money—and I know that’s not the summation of what you said. But one of the questions that I'm wondering here is, looking at the survey and the survey questions is, why does all of this matter to an individual practitioner? Does software delivery management, the questions and the lessons from this survey, or do they offer value to individual practitioners, developers, engineers? Any thoughts on that?

Mitch Ashley: Go ahead, Sanjeev. I'll jump in, too.

Sanjeev Sharma: Yeah, absolutely, right? First of all, if the company is not succeeding, you know, you—

Brian Dawson: You don’t have a job.

Sanjeev Sharma: Right. You don’t have a job, right? So, you want to make sure the company is succeeding. Secondly, all of us want to deliver value. I think the days where somebody said, “I'm going to go and punch the clock”—or whatever its equivalent today is—“sit in my cubicle, water my little plant on the cubicle”—I shouldn’t talk about cubicles nowadays. Nobody is in a cubicle. Whatever—at home.

Brian Dawson: Right. [Laughter] In your open work space, yes.

Mitch Ashley: Feed the cat.

Sanjeev Sharma: You get what I'm saying, right? And, you know, I have a checkbox to check and it’s a set of tasks I need to do, and I don’t care what impact it has down the road. Those days are gone, right? Those days, that whole mentality of, “I'm gonna live in my silo and put blinders on,” you know, agile was the first salvo to kind of try to break it and then DevOps totally broke it and said it cannot work any more that way. 

People want to be engaged, people want to add value and see where their value is going. And that is not only from an individual perspective, from a company perspective, also—you want everybody to have responsibility.

And I'll give you an example. I was doing this engagement at an insurance company maybe five, six years back. So, I really think those guys are forward thinking. They had this T-shirt which everybody got. The T-shirt said, “Everybody is responsible for delivery business value to the customer.” That’s all it said. No design, no logo—that’s it. 

What is more important is who they gave it to. Obviously, they gave it to all the engineers, all the testers, developers, the IT folks. Then they went and gave it to the CFO and said, “You know, if you delay approving budgets or I have to furlough a contractor because you didn't do your job, you are now delaying delivering business value to the customer.” They gave it to the coffee repair guy and said, “You know, if the coffee machine is broken and somebody has to walk to Starbuck's, right, you have now certainly delayed delivering value to production.” They gave it to the janitor and said, “During office hours, there can never be a sign which says, ‘Restroom Being Cleaned.’ So, if somebody has to go to another floor—dang it, you just caused a delay of delivering business value production.”

The mentality of joint ownership is what really creates the right environment of end to end software delivery management, where everybody has a part to it. And you know, I don’t want to jump ahead into the survey, but one of the things we found was that that’s not true today. Not only have silos not been broken—they are better than what they were five years ago, but their practitioners don’t have the visibility into the data which the management has.

One of the things we did in the survey was segment people who responded, you know, and this kind of attaches to your question—practitioners versus non-practitioners, managers—and we found a huge gap in the assets. The management seems to have a much rosier picture of what things are, what is going on, than individual contributors do. 

That can mean one of two things. One, the managers are looking at everything through rose colored glasses.

Brian Dawson: Rose colored glasses, yeah.

Sanjeev Sharma: Or things are actually better and they have access to data, but the practitioners don’t know it because they're not being—they don’t have visibility into the data they need. So, they feel cut off, they feel lost. They don’t feel a part of the solution. They feel a part of the problem. That discrepancy between the responses we got from individual contributors versus management and leaders and the entire spectrum of management all the way from first time managers to CXOs, that was actually quite telling to say practitioners need more data, they need to be more involved than they are today.

Mitch Ashley: You know, a way, I think, Sanjeev and Brian, to make it super tangible—I've been around the merry-go-round a few times and one of the things that’s happened to me is, you ever been on a project that gets canceled, maybe months, maybe even a couple years into it?

Brian Dawson: Yeah.

Mitch Ashley: And everybody on the project knew two months into it, like—this thing’s gonna crater. Just how long is it gonna last? And you wasted—it’s like a crime against humanity. You wasted all these people’s talent and resource. I never want to work on one of those projects. I never wanna lead, be involved in leading a project more or less.

So, this whole idea about value and speed is, we want to be able to execute very quickly and figure out what works and doesn’t. Adjust, move, respond—adjust, move, respond, deliver software very quickly. We've got to be able to measure value if you're gonna do that. It’s not just speed.

So, if you're an individual contributor and you're just hammering out on a project, you want to work on projects that are gonna succeed, and this is why this value is so important.

Brian Dawson: Yeah, that’s great. Well said. Yeah, you just got me thinking—look, time is one of the most precious commodities.

Mitch Ashley: It is.

Brian Dawson: And yes, we have to work. Yes, we have to earn. But six months of my life on a project that could've succeeded and failed is still six months of my life gone, right?

Mitch Ashley: Yeah.

Brian Dawson: So, yeah, I think that’s really powerful. And I love, this is a great segue into the actual survey feedback. And, you know, I wanted to ask, from the point of view of ASG and you two as individuals, what were some of the key findings from the survey? Sanjeev, you know, you covered some, right? But what were other key findings, and in those, were there any big surprises, big “ah ha” moments that you can share with us?

Sanjeev Sharma: I think being in the field and being engaged as a practitioner, I personally was not, did not have an “ah ha” moment, it was more of validation, right?

Brian Dawson: Okay.

Sanjeev Sharma: So, I did not see anything which went, “Dang, it’s bad?” No, I know it’s that bad. [Laughter] Trust me, I can see it, right? I've been there, you know? I've been a part of those organizations, right? I call some of these organizations soap opera organizations, soap opera projects or, you know, you can go there and go back three years later and the story is exactly the same where you left off three years ago. The characters have changed—“Oh, you are the new Brian?” You know, the actor has changed, but the character is the same. You know how, not that I watch soap operas—

Mitch Ashley: Right, it’s like Groundhog Day all over again.

Sanjeev Sharma: Exactly. And you know, like—still? You're still trying to figure out what methodology to use? I mean, you're still, you're celebrating you went from 29 days to build a server to 22—that’s what you're celebrating?

Mitch Ashley: [Laughter] 

Sanjeev Sharma: So, it was not a shock, but it was validation, right? So, first, let me talk over kind of the headlines, right? The number one headline is that I don't think organizations are anywhere near extracting maximum efficiency from their software delivery pipelines. Anywhere near it, right? I would say most organizations—almost every question where we asked in the survey an example of, “Are you improving?” or, “Are you able to do X?” which is a positive factor, in ever scenario, more than 50 percent said, “No, we are not.”

Brian Dawson: Hmm.

Sanjeev Sharma: Which tells me we are nowhere near efficiency. Even if it was 50 percent, I would say, “Oh, good. We are fine.” So, from that—or at least we're moving in the right direction, right? So, organizations are nowhere near, in my opinion, not yet anywhere near maximizing the efficiency and the value they can get out of their software delivery pipelines.

Organizations still have silos 10 years after DevOps, the movement, started. They still have silos, and they're still struggling with breaking down those silos and they're improving. Everybody says, in the services, they're improving, but it’s nowhere near where we would want it to be 10 years in.

Brian Dawson: Okay.

Sanjeev Sharma: And the biggest impact of it is, which is one of the key takeaways here, is that it has resulted in a significant lack of flow of data and information from the people who have the information to the people who need it.

Brian Dawson: Right, right.

Sanjeev Sharma: It’s not just a question of, “Hey, I'll open a ticket and now to wait three days for somebody to create an environment for me or ________ a database for me to do some testing.” It’s, even when I am done with something, even when I am done, although I need that information to do my next task, I can’t get it. I have to jump through hoops to get the information.

So, the cross-silo, functional silo information flow is still really bad, and as we discussed already in your previous question, the flow of information—

Brian Dawson: Up and down.

Sanjeev Sharma: vertically

Brian Dawson: Right, yeah.

Sanjeev Sharma: From layers of management is also still bad. So, information flow is a major problem in most large organizations. And if you look at this from organization size, small startups are doing great, under 50 people. Companies over 10,000 are doing great. Everything in between, they are hurting. Because companies over 10,000 probably have had enough, have not had the capacity to invest in fixing some of these challenges and hire the right talent. I think it’s the companies in between which are really struggle.

I know I've hit on a lot of things, so I'll let Mitch jump in, also.

Brian Dawson: Yeah, yeah, over to you, Mitch.

Mitch Ashley: Well, you know, I think part of the message here is, there’s been improvement, but we've got a long ways to go. And if I add—let’s just put things in context of where we are today. We are in a situation where companies may live and die by their ability to react quickly but still act strategically in line with where they're heading and reprioritize, reallocate dollars creating software going to solving business problems and creating either offensive or defensive strategies and making a difference in market. And that ability to measure value or understand the life cycle of value through the software creation delivery process, that’s what this survey is about.

So, what I would encourage is, every person—by the way, our mantra is knowledge wants to be free. We don’t charge for our content. You can go get it. This was a research project that we did with CloudBees, it was sponsored by CloudBees. We're happy to be working with them. We did it so we can—we do all of our work so that we can share it as broadly as possible. We’d like everybody to go download this report and say, “Here’s where I think we are. Okay, if these are the questions we should be asking, what do we need to go fix?” Kinda think about the DevOps process, where is the bottleneck? Where is the bottleneck in that flow of information? Where is—where are we losing it in being able to share data across all these functions in a flow process, in a workflow?

And this can be super valuable and you don’t have to go do your own analysis, you can take this and step back and say, “Let’s quickly benchmark ourselves. In this environment, we gotta fix this problem right now or we're gonna—we're in danger of missing the mark,” and delivering the right software at the right time at the right place, that’s what this data can mean to an organization.

Brian Dawson: Phenomenal, phenomenal. And I would—to lead in on that, I would hope or suspect that if you bring this survey back into your organization, it could prompt necessary discussions across the silos that are part of the inhibition of flow of information. So, you know, I'll expand on what you say and just, and I know it’s one thing for me to digest data and then just put it out over Slack. I usually get more power when I can facilitate a discussion I wouldn’t normally have, based on the data. And from what I've seen in the responses, again, there’s some really interesting stuff, here.

So, you know, pushing forward a bit, Sanjeev, you had raised earlier that there’s a difference in responses between management and practitioners or individual contributors. And in fact, you said management often has a rosier picture. Now, you threw out some possibilities. Is there anything else in the survey or in your experience that would lead to an educated guess or analysis of why this is the case and how organizations resolve that discrepancy?

And the answer can go to either of you guys. I was referencing back to Sanjeev’s answer, but love to hear your thoughts, again, on what you believe contributes and how we might solve it.

Sanjeev Sharma: I think, from a contribution perspective, it is, again, a question of access to data and visibility. Most management tends to believe that this data is for their eyes only, and tries to control data and tries to, maybe if they are reporting upstream, they try to clean up the data, sanitize the data. You know, we see over and over again, PowerPoints being made with data which has been sanitized or cleaned up.

To me, the solution to this is to make data freely available and accessible to anybody who needs it via the right kind of dashboards. Of course, have access control; you don’t want to be totally open. You know, control what data is available to whom based on their role. There are certain things like budgetary information, you don’t want that to be available to every practitioner and contractor who might be working on a project. Maybe you do, I don't know, you know, but there might be certain information you don’t, right? You know, you don’t want to scare off people who are saying, “Hell, my budget is running out three months before the project.”

Brian Dawson: [Laughter] 

Sanjeev Sharma: You don’t want to scare people, but at the same time—so, the data you need, any practitioner needs to have full visibility into the application delivery pipeline and know where, you know, what impact they are having, right? Or once they open—let’s say they have to open a ticket where somebody else has to do something. They have handed off an asset and they're using ticketing to track it. In so many cases, the ticket has gone into the proverbial black hole where—nope, the practitioner who opened the ticket doesn’t even know who’s working on it, what are they doing, because the other team is using some other system to manage their workflow, right?

Brian Dawson: Yeah.

Sanjeev Sharma: Call it a ticket, call it an issue, call it a task or whatever it might be.

Brian Dawson: Right.

Sanjeev Sharma: Having a certain standardization of workflow, standardization of the metrics you're measuring to measure value and progress, so that—and giving visibility to people beyond just management and trying to control who has the data. I think those are the key things people can do, organizations can do to truly democratize that data which is available. And secure it—of course, have access management and guardrails to control who has access to it and who doesn’t. But don’t—you know, most people, I think, go overboard and say, you know, “Why would anybody on my team need this data? This is my data which I need to report to my management.”

Brian Dawson: Yeah.

Sanjeev Sharma: You know, and that to me is kind of cultural attitudes which are creating that problem, that us and them between, you know, the leadership and the Joe Blow practitioner shouldn’t be there, right? At the end of the day, people who need the data should be able to get the data.

Brian Dawson: Yeah. Okay.

Mitch Ashley: And to your point, Brian, you know, you talked about having the data, sometimes the value, oftentimes the value of a consultant or an analyst or somebody with data is, takes the, you can’t argue with the facts. That’s a discussion we can have instead of who looks bad or who looks good.

And this is something that Sanjeev and I and you bring from your experience as well is, you know, the data tells part of the story. The other part of the story is, why does this happen within organizations? And you can ask this as an individual contributor, you can also ask it as a leader. If management, if leaders have a rosier picture of what’s really happening, it’s because, I suspect, they've created the conditions for people to tell them the rosy pictures and give them the data to support the rosy picture. Why? Maybe there’s punishment for delivering bad news. Maybe there’s unsuredness—we just don’t know what’s gonna happen.

So, take this to the next step in how to apply this data is, if you believe you need to be able to fail fast, you have to be able to fail.

Brian Dawson: Right.

Mitch Ashley: And that has to be okay, you just have to do it on smaller scales, much quicker, and learn from it very quickly. So, I think this data all goes fundamentally—and I'm not pointing to that as the only cause or the only issue. Oftentimes it is—we've all worked in organizations where, probably, that’s happened. And I think for leaders to look at this data, ask why. If this is—if we're matched similar to what this research found, ask yourself the tough questions and be willing to share, be vulnerable, share it with the organization and say, “This is what we need to be good. I've been failing you because I've not been supporting telling me the bad data. That’s why you're holding it from me and I have a rosier picture.”

So, one path, but I’d encourage us in this world, there’s no time to mess around. We've gotta move fast and do the right thing for us, our customers, our business, et cetera, our employees, and this can be a big source to help you.

Brian Dawson: Yeah, and I can appreciate that. To prepare you guys, I'm gonna assign a DevOops moment to one of you and a resource reference. But before I do, I want to underpin a couple of things that I heard from both of you, which were, you know, very insightful, right? And I think we're all aligning around this idea of unlocking potential and performance through collaboration and empowerment, right? And I think—and silos inhibit that. 

Data that’s not shared across silos, from management down or across inhibits that, and I like to—I think, really personally, but I've also found it that engineers and developers, we wanna solve complex problems. I say “we” because I still think I could wear the hat a bit, right? And to solve those problems, we don’t wanna just be fed—we don’t wanna be people that are running punch cards through a punch card machine, right? We wanna be understanding the context of the problem and empowered with the data; i.e., the insights to give us the context to solve it to the best of our ability, right?

And that’s why I think, Sanjeev, to your point of unlocking the power of the data; Mitch, to your point of having a culture where you're sure that the information that you're getting is actually accurate and representative, I think, are all powerful. So, thanks for that, guys. 

The listeners here probably get tired of hearing me say it, but I literally could talk to you guys for hours. I know I can’t, because you're both very important people and we gotta get you moving on to the next thing. So, I want to move to a standard aspect of the podcast, I love hearing this from people, and that’s to ask what is a DevOops—O-O-P-S moment, not DevOps; i.e., a software development challenge or failure that you experienced or witnessed in your career, you overcame, and you learned from.

I'm thinking, and no biases here, I'm thinking, Sanjeev, Mitch, but either of you, if you're compelled to answer the question, please jump in.

Mitch Ashley: How do I choose? [Laughter] 

Brian Dawson: Rochambeau. Rock, paper—yeah, well, go ahead. Give it a try, Mitch.

Mitch Ashley: You know, I made some, I was on a project one time that was delivering—we were building a wireless management system for WiFi in corporations. And I was all bent on, we have the product right, we've got it figured out. And we had gone down this, and I was, you know, advocating for it, getting everybody on board.

And finally, I had a conversation with a potential customer, somebody we were interviewing and testing some of our concepts, right, in this whole active design part of developing software. And he very quickly said, “You know, actually, I don’t need that problem solved. We've got ways around that, and is there a product today that does exactly what I want? No, you're kinda working on the wrong thing. My whole problem”—and this, by the way, wasn’t this year, this was quite a few years ago—

Brian Dawson: Okay, right.

Mitch Ashley: "My problem is people working from home and the security of how they're connecting into my network. How could you solve that?” And I'm like—man, I missed the boat.

And that was one of those I got to, you know, I was drinking my own Kool-Aid, believing in the solution and not believing in the problem. And it really wasted a lot of time, a lot of my time, and I had to apologize to folks and say, “Look, I missed the boat, here.” And it turned out the real answer, which this person helped us get on track for, was our best selling product. We sold it all over the federal government, the Defense Department. It was awesome.

Brian Dawson: Wow.

Mitch Ashley: I call those moments 2x4 moments—konk! [Laughter] Okay, I got a little bruise, but it’s worth it.

Brian Dawson: Right. You learn not to bump that part of your head again. Well, thanks. And actually, we may skip the research, because Sanjeev, I'm so curious in hearing your version of DevOops as well. Do you have one that you're comfortable sharing with all of us?

Sanjeev Sharma: Sure. I think, I've been trying to make sure I don’t give away any information to protect the guilty.

Mitch Ashley: [Laughter] 

Sanjeev Sharma: And so, trying to sanitize it, but this is a client I was working with where, you know, they kept having outages, right? And we had put together a pretty well, what we thought was a very well defined monitoring regime in place to be able to run synthetic transactions and find where there were issues.

But at the end of the day, you know, it was broken. We just didn't have visibility into the entire end to end network, right? And it required sending human beings to their end point, their point of sale, and having them run actual transactions. “Okay, go there and go buy this,” right? That was the only way to really figure out what was happening in the real world. And I think it goes to the fact that, you know, as developers, we didn't realize, we—I was on the development side—we didn't realize how noisy the production world is. We didn't have true visibility, we didn't have true data to understand how noisy it is, what network latency really is like at the end of the day at the end point, right, the final few feet, you know, inside a very noisy network environment. And we had to measure architectural changes to our system to handle that, which we never expected. 

And to us, that was a DevOops moment to not go and fully study the environment in which the system would be running, and as you are releasing more and more systems to improve better monitoring to understand the health of what it is we were delivering, how as it performing? You know, how was the code performing under these noisy conditions and high latency conditions of the real world. Everything works in the lab, right?

Brian Dawson: Yeah.

Sanjeev Sharma: You can try to simulate noise, you can try to simulate data using synthetic data, but nothing replaces true production, right? People say don’t do tests in production—there will always be, a final test is always in production, no matter how much you test beforehand, because you cannot replicate production. You can simulate production, you can have a production like environment, but eventually, the truth comes out in production. You need to be prepared for that. You need to have the ability to monitor and observe what’s really happening in production—we dropped the ball there.

Brian Dawson: Awesome. Alright, so, great, great, great story. I appreciate that. So, first, I appreciate your guys’ time here today. I gotta go through some of the data in the survey, it prompted a couple of hours of questions and commentary, and I look forward to digging further into the final results. Everybody that’s listening, I absolutely suggest you do.

Before I let you go, Mitch and Sanjeev, do you have any final thoughts that you’d like to share with our audience around the survey or otherwise? Mitch, we'll start with you.

Mitch Ashley: I'll just leave one parting thought is, in our work as IT and technology professionals, let’s design our goals and our measurements around business outcomes. Then you're almost always gonna be guaranteed to be pointing the ship in the right direction—and guess what, you'll build great trust and great belief in what you do. If I could suggest that, I think that’s the message behind software delivery management.

Brian Dawson: I appreciate that. And I’d actually like—and I'm sorry to jump in, but as a young practitioner, a developer, hot shot developer fellow, I was the center of the universe and business was a bad word. As I've grown and I support kids in college and a mortgage, I understand business is not a bad word. [Laughter] So, I appreciate that wisdom.

Sanjeev, do you have any final words for our listeners?

Sanjeev Sharma: Yeah, I think make sure that people who need the data and the metrics, they need to have access to get it, right? There is, the data should be freely available and accessible to the people who need it. You shouldn’t need to jump through hoops. An informed developer, an informed engineer who has all the information they need to make the decisions they need to make is a much higher performing engineer than somebody who is the quote-unquote proverbial 10x engineer but it operating in the dark.

Brian Dawson: Phenomenal, phenomenal—well, gentlemen—

Mitch Ashley: Knowledge wants to be free.

Brian Dawson: Yes, [Cross talk].

Sanjeev Sharma: Absolutely, absolutely.

Brian Dawson: I almost said it five times. I'm gonna say that in my sleep, now—knowledge wants to be free. So, gentlemen, thank you so much, I appreciate it. I'm glad that Accelerated Strategies Group is here to help the industry move forward, and I wish the organization as well as you two the best on your journey.

Mitch Ashley: Same back to you. Thank you.

Sanjeev Sharma: Thank you.

Brian Dawson: Alright. Have a great day.

Sanjeev Sharma: You, too.