Webinar replay: Characteristics of high-performing software organizations with Lande Castberg and Marc Dillon

We are replaying our recent popular webinar as a podcast episode. This webinar helps you learn how organizations are able to scale their business to the next level and drive growth in new and ambiguous situations.

Lande (00:05):

Empowerment is one of those words that sometimes means something and nothing in a way. You hear when we're talking within an agile sort of environment, et cetera, we use the word empowering teams and empowering people all the time. And sometimes it can feel a little bit empty because it's like, well, what does that mean? How do I empower people? I mean, a 5,000, 10,000 people organization, do I have to empower everybody? How do I do that?

Lauri (00:40):

Hello and welcome to DevOps Sauna. Delivering software quickly, reliably and safely is at the heart of technology transformation and organizational performance. But what are the essential characteristics of high-performing software organizations that set them apart from the rest? This is what Lande Castberg and Marc Dillon from Eficode addressed in one of our recent webinars with Atlassian. Lande and Marc examined how organizations are able to scale their business and how they can drive growth in new and ambiguous situations. Lande Castberg is a country director of Eficode in Norway and runs the agile transformation practice at Eficode. Marc Dillon is a lead consultant in Eficode in Finland. He is interested in how people work together to build products. Let's listen to Lande and Marc talking about the characteristics of high-performing software organizations.

Lande (01:37):

So let's get into sort of the nitty-gritty, really, of the topic of the conversation today, which is like high-performance organizations. I mean, essentially what we see in the work that we do as consultants is pretty much summarized in this slide. What we see high-performance organizations doing today is they're able to exceed their own goals. They have satisfied employees. I mean, they're up there in terms of customer satisfaction and pretty much cornering the market within their specific area. And this is not sort of, how'd you say this proprietary information, this comes from the Accelerate book, which I'm sure most of you are familiar with, but I'd like to hear, Marc, what you think about this? We've seen this sort of level of high-performance in different organizations, but what's your take on that?

Marc (02:51):

I think one of the great things, like the research that was done in Accelerate we're going to refer to a couple of times here is that we're setting a standard for tools and processes. That high-performance organizations are using very similar toolsets, are using very similar practices and their abilities, as you can see here, is they are outperforming others. And I think it's even really, even most important here in this book on this right side, 2.2 times more likely for their employees to have a positive net promoter score for them to tell their friends, "Hey, we want to come." It's a developer's market, so it's really, really important to be able to attract top talent and retain them in high-performance organizations with good toolsets like we get from Atlassian is a big part of that.

Marc (03:39):

But what I'd really like to know now is what do you guys see? We have a question for you. You can open the Q&A, and we have a really important question. We'd like to ask, what do you think are the main characteristics, the most important characteristics of high performance in a software organization? I'll give you a moment. We've got a few coming up. I'm seeing some of my favorites already. We've got a couple of interesting ones here already. The number one closest to my heart, psychological safety. I'm so glad that you brought that up. I don't know if you know this, that's actually, those words were at the top of the DevOps report for 2021 that Eficode published at the beginning of the year. And those two words brought me to this company. So I'm really glad that that was brought up.

Marc (04:43):

We've also got clear goals, flexibility, autonomous teams, contextual leadership, clear communication, and another really, really fantastic one, short feedback loops. I have to tell you, I think that you're all pretty much on point and I think we're going to talk about a lot of these things today. We also got agility, trust, and cooperation. Lean product management, experimentation, understanding the ways that products and service are developed to make end users’ lives better.

Lande (05:27):

I mean, we're just walking into a pandora now, aren't we, Marc, here?

Marc (05:30):

It's great, but we're all on point. So Lande, what do you think is the main characteristic of high performance in a software organization?

Lande (05:39):

I agree with everything. I mean, I agree with everyone and how they describe it. I do like the psychological safety. I term it differently because I feel sometimes that wording, psychological safety, can sort of rub some people up the wrong way, but I totally get the point. I think that's key. But for me, the thing that rings true, the two things I always come back to is just like people, people. And then the second thing, because I said people twice, is actually focus, organizational focus.

Lande (06:11):

And I think someone else mentioned that, which is the ability to be able to, for an organization, to hone in on what they're trying to achieve without any of the wishy-washy language, but set in a way that everyone in there knows what we're trying to achieve. And then we focus, we have this kind of like a laser focus on what we want to try and achieve. And the only way you can do that is with the people that you have. So it's all about people. So those are my two key things that I'm quite sort of like passionate about, shall we say. Okay. But that was good. That was quite nice. I enjoyed that.

Lande (06:46):

So then moving on, this is what we were thinking when Marc and I were talking about this and so we put down, okay, what would we say high-performance organizations do or what they're like, we saw like four things kind of like stood out a little bit. The first one, the ability to operate at a high standard or at a high speed. And I think that's quite important because this is like setting the scene. We're setting the context, what do we mean throughout the rest of this presentation when we start talking about high performance, right? There's also a dictionary definition as well. And then the other one that I quite like as well is having a better financial and non-financial results than those of your peers over a period of time. So that's quite key. The ability to consistently deliver at a high standard and at high speed better than your peers. That is what makes you high-performing. Marc?

Marc (07:48):

Yeah. And then celebrating failures. This is something that on the extreme end of the scale, you've got the shoot the messenger kind of culture that forces people to hide information and it forces people to change information to try to kind of dismiss the failures. There's a quick story. Like the guy that made the mistake in the laboratory and he spilled the rubber on the heating stove and it turned hard. His name was Goodyear. It's like you never know what's going to happen from having a culture that embraces and celebrates the failure. And by the way, the other extreme from shooting the messenger is training the messenger. So training the people on how to bring the information, even if it's not the most flattering information at the time. Allowing people to be vulnerable when they bring information instead of feeling shame about it.

Lande (08:45):

Absolutely, yeah.

Marc (08:45):

And this really cool thing that leads to the bottom right here. We used to say good, fast, and cheap, and you only get to pick two. But high-performance software organizations today are getting all three. They're getting high availability, high reliability, and high speed at the same time. And a lot of this comes down to of course it is focused on people, focused on the business, but it's also if you don't have the basic tools and processes in place, then it's going to be a lot harder to get there as well.

Lande (09:18):

Absolutely. And I just want to circle back quickly to the celebrate failures because I have this thing. I think sometimes when you hear this, for me it sounds a little bit of an oxymoron in a way. And just to sort of bring it down to earth, it's not really about popping a bottle of champagne and going we didn't do what we set out to do or anything like that, but it's really sort of like making sure we create that culture, like you make a mistake and you learn from it. That's the key. And I think sometimes when we talk about we should celebrate failure, we miss the important part. We celebrate it because we learned from it. If you don't learn from it, then the celebrate failure as a term in itself sort of falls flat, doesn't it?

Lande (10:02):

Okay. So, then we move on to some of the key characteristics. We've got a couple of areas. We've said a bit in terms of like behaviors of high-performance software organizations, et cetera. We want to sort of like hone down and drill down a little bit into some of the practices that make an organization high performing, but not just sort of... We'll talk about the practice, but also we'll give you a little bit of how we can do this and also why it's difficult because it ain't easy. If it was easy, we wouldn't be doing this webinar in the first place.

Lande (10:43):

So looking at some lean management practices, together I think we decided, okay, let's focus on this space. There's quite a few others as well, but talking about limiting work in progress, simplifying change approvals, visualization of work. I'm sure these are all terms and phrases and things that some of us, some people in the pool practice and they're really familiar with, but let's sort of lift this up now into a bit of a more business type context. When we talk about limiting work in progress, what comes to mind? For me, I think to myself, well, why? Why am I limiting work in progress? And I think to myself, as humans, to be perfectly honest with you, I know we think we can multitask, but quite often we're not terribly good at it.

Lande (11:32):

So limiting work in progress helps us to be realistic about our expectations. What can we reasonably achieve within specific timeframe? And I think it also helps us to drive focus, helps to improve the flow of work, and I think it increases speed. So these are some of the things I think about when I'm talking about limit work in progress, and I know we've also done it. We've got that Kanban board there basically. And that's the picture we all have. We all have like our Jira board and we have the in-progress. We put our WIP limits and then boom, there we go. We're limiting work in progress. But I think there's a heck of a lot more to it than that, isn't there, Marc?

Marc (12:18):

Yeah, there sure is. There was a story that I was going to tell, which is that I was coaching in a startup center here in Finland, in Tampere. Each of the startups, they have their little room and they have their stickies on the wall and they have their ideas and all of their energy and their bright eyes. I walked into one of the rooms and they had this Kanban board sign at the top. And then I kind of looked around and I was like, "Is the whole team here?" And they're like, "Yeah." And I'm like, "So five people?" They're like, "Yes." I was like, "Well, you've got like 10 items in the work in progress area. That's not a Kanban board. What are you? You're not doing Kanban here." We talked a little bit. I came back a little later to check on them and they had fixed it. They took the word Kanban off the board. I was like, "Okay. All right, guys."

Marc (13:12):

So then quickly they came back and they put the Kanban back and they moved a couple of the tickets to stuck and they moved a couple of the tickets to done. Aha! Okay. One of the reasons that we limit work in progress is because when somebody gets stuck, let's rally around it. Let's help them. Let's do everything we can to get that work unstuck so they can move through the chain and generate value. If you're doing Kanban, that's what it means. That's why it's there like that.

Marc (13:46):

Another thing about work in progress is that, and this actually kind of leads into this change approvals, which is that if a team is looking at a backlog that they feel they're never going to complete in their lifetime if they're having difficulty achieving their sprints, then obviously you should reduce the planned work going into a sprint. But you should also have a look, is the backlog so big that they don't feel like they're ever going to get a feeling of completion of things? So that's another reason that limiting not just work in progress, but limiting the inflow of work can also it creates more psychological safety, it creates a better feeling that, "Hey, we can do this, guys."

Lande (14:30):

I mean, I'm totally with it. It can be overwhelming content in terms of like where do we even start? So yeah, I think I love the story about the Kanban. I'm going to use that actually. Let's just remove the word and then they... But I think it's good to lift these phrases because I think sometimes they're too often associated with low-level tasks. If you think about it from an organizational perspective, that's the focus I was talking about earlier on. The less you have to focus on, the more probability that you're able to achieve the success that you're looking for.

Lande (15:11):

So then we move on to simplify change approvals. I'm going to ask Marc not to start frothing at the mouth now with this because what we're really talking about now is like change approval boards. I have a theory. I used to be in information security. My theory is this: In typically large corporate organizations, you typically have a separate department, shall we say, that is responsible for technical change approvals, and their job is to make sure... Well, let me rephrase it. They're incentivized differently. So there's the people who are making the changes, they have one incentive, and then they have the people that are making sure you don't mess with the production environment and they're incentivized differently.

Lande (16:00):

Their incentive is they get a pat on the back if they stop something going into production that they believe, or based on their fact sheets or whatever, will potentially take down the production environment. And then they're sitting there in opposition, shall we say, to somebody else, a developer who's incentivized to get a change into production as soon as possible so we can start earning value, and they're both working for the same organization. Tell me, how does that enable these two teams to walk in the same direction or focus on the same goal? What do you say to that, Marc?

Marc (16:42):

I'd say there's so many legacy pathologies there. One of the things about high-performance organization-

Lande (16:49):

They still exist, you know?

Marc (16:50):

Yeah, I know. One of the things I just want to point out a few times here for you today is that that's legacy pathologies. So new companies that are using state-of-the-art tools and practices from the beginning, they start building the test automation and the toolchain such that there is access from the developer to production either by making a commit at the highest end of things or by the developers directly maintaining production like you have in all the social media companies, for example. This kind of thing, it's also moving into other types of companies that have different even certification concept levels of things.

Marc (17:28):

But one of the things also here that this pathology describes is I don't want the developers to be working on something unless it is exactly what we want to add value. So why would I want to stop that at the last minute? The developer has already done the work, why would I want to stop that before it gets to production? I want to enable it to get to production and I want to move the complexity left to the earliest part of the process where we focus on delivering the right stuff. And that's another thing, limiting the work in progress allows us to understand what are we really focusing on, and this little bit of stuff is the right stuff and we want to get it through production as quickly as we can with good quality, which means good toolchain, good visibility, good test automation, and ultimately none of these official quality gates should be required from the point that we decide to do a piece of work.

Lande (18:20):

Absolutely. I mean, I do people. Then what would you say to heavily regulated industries because I think for my background, one of the things that was quite key was sort of like working in a financial institution and implementing the four-eyes principle, this is something that is quite key. I mean, four eyes doesn't necessarily mean that it needs to be an external set of eyes, for example. It just means that you need potentially like a peer review, et cetera. But these kinds of organizations, they do really struggle with it because the regulatory rules that they have to comply with, they're not necessarily moving with the times.

Marc (19:02):

No, no. And by the way, four eyes is any two people can decide something together, can decide just if we have glasses or not. But there's still this term called quality gates. Let's take an example that there's software that's certified in production. How do we then, the term is bake in compliance. If we have something that requires a certification and is in production, then at the very beginning in Jira, then we make it clear that this change is for software that require certification and we try to take care of the approval there. And then we trace that ticket through the system to make sure that, okay, this is something that does require certification, so there's a certain kind of ticket that's coming that's going to potentially have a quality gate.

Marc (19:50):

And then what we want to do is because what a company will say is no, we have such rigorous certification practices that we can't possibly have automation. I'm sorry, but you can. What you can do is you can automate to make sure that you have all of the approvals before it gets to the developer. And when it gets through the test automation, you make sure that you have all of the quality information that's necessary. Who requested the change? Who approved the change? Who did it? What are the test results? What is the software release? This end-to-end kind of configuration management items. And then if that results in a ticket for the certification responsible person to approve that has all of the information required for them to do that approval, and when they review this information or do whatever's necessary, they move the ticket to done, and then the automation takes it and puts it into production.

Marc (20:41):

That's baking in compliance. So we try to do as much as we can at the beginning before it hits the developer, and then we try to have a pipeline that allows the developer to do the work and efficiently get it to production.

Lande (20:53):

Excellent. Automation. Sounds good. And then let's talk a little bit about the visualization of work. Oh, I love this. I think in not past lives but very recent past lives, this has been the bane of my life because it's trying to get every level within the organization to understand why we're doing what we're doing, but also to have it visible. I mean, we talk about, I worked for an organization, for example. You have this slight high-level strategy that we want, which is presented to you and it could be something like we're going to be the most socially responsible organization. I mean, I can think of a phrase. I don't want to use it because if I use it, you'll know the company that I'm talking about.

Lande (21:43):

But you have something so high, we're going to be socially responsible. And I'm a sort of like a systems analyst or whatever. My job is, I'm responsible for the supply chain module within SAP. That's my job. And I'm sitting there looking at this, “you want to be socially responsible” strategy, that's nice. How does that affect me on a day-to-day basis? How detached do I then feel from the high-level goals of the organization? And that's something that I see, I think, that a lot of organizations sort of struggle with when we talk about making work visible because we're not just really saying: okay, the work that you're doing in your team, what are your tasks and make sure everyone can see them, we're really actually talking about connecting all the dots so that you can see the end-to-end. What do you think, Marc?

Marc (22:40):

I look at this, so like I can take a customer service perspective like if we're using Jira for our call center, and then we have a dashboard that shows that the call center is getting an abnormal amount of traffic today and that customers could very likely be backing up then. I can use the tools, use the dashboards to see that there seems to be some kind of incident going on. And then I try to drill down and understand okay, is there something that we could handle in by making a quick change to our website or a quick change to our application? Or is there an error that is causing people to call in or is there a missing feature or something like that? So the visualization kit starts at whatever the customer interface feedback loops start with.

Marc (23:32):

And then I need to be able to visualize if we've limited work in progress and we have simple change approvals and I have the ability to see what my teams are working on. If I do see that I have an opportunity that I've visualized to one of the tools to make a change, I can weigh that against whatever the current plans are and then decide if I want to interrupt some work to update the website to allow a feature to be there that could slow down the call center traffic by letting them use the online services, things like this. So then how this ties into an SAP person doing work on supply chain, if there are supply chain issues and there's a component that's not available or there is a software component or a hardware component that has some kinds of challenges, then I want to be able to see quickly that something abnormal is happening in that department.

Marc (24:28):

And then I want to be able to cross-check with other departments that can support it and see what will the cost of a change be to if we're now going to have to deal with a different processor or architecture or component or something like that. So by having the simple configuration management interfaces that go end-to-end, oftentimes we can see where a problem is, we can decide if we want, using real-time live data, if we want to make a change in order to help our customers get through whatever issues at hand.

Lande (25:00):

I think that's an excellent and interesting point because I think what you're alluding to for me is really that sort of making that information also relevant. So it needs to be of a certain quality and of a certain level that allows you to be able to make business decisions. It needs to make sense, doesn't it?

Marc (25:26):

Yes.

Lande (25:28):

I mean, for me, it's quite a tough one to implement because you are talking about a whole set of tools, in a way we're trying to make sense of the information, trying to turn it from data into information. I mean, from my perspective, I think it's time for another poll. It's time for audience interaction, because Lande thinks that this is something that's quite difficult. That's not true, but we've seen that this is something that a lot of organizations struggle with. We'd like to sort of put up a poll which is sort of ask the audience what problems do you face in your organizations with making work visible.

Lauri (26:13):

If you are in the middle of DevOps transformation, or if you are considering launching a DevOps initiative, we have a webinar recording available for you. In this webinar, we discuss how key metrics can help you better understand the progress of your DevOps transformation and how to use them to shape the right behaviors within your organization. We start from why key measures are such an important part of any DevOps transformation journey. Then we dive into which specific metrics are most beneficial. You can find the link to the recording in the show notes. Now let's get back to the show.

Lande (26:50):

Look at this. Yes, the leader silo teams and information. What do you think? Is that in line with what you're thinking, Marc?

Marc (27:02):

This is one of the biggest ones that I have helped many times to try to work through and it depends on organization culture. It depends on having information. There was one of the questions that came up that I'll kind of stick here too. So visibility is being able to see where the value is flowing in your organization. And the work is oftentimes creating that value or supporting the creation of the value. But yeah, this is right in line with what I see as well.

Lande (27:40):

Yeah, totally. And I sort of, I mean, this is going to segue into the next slide. I know this, but I can't resist it because I am so glad that this is the number one thing, because in my experience what has been so difficult is just like it's not... You have silo teams, everyone has their own way of working. We all have a certain level of autonomy. We all have I call it a spade, you call it a digging implement. By the time we try and put it together, it's really difficult to make sense of it. So yeah, I mean, everything is an issue really. When it comes to visibility, all of these things are correct. Cool!

Marc (28:22):

All right.

Lande (28:24):

Yeah. So moving on to the... Let's talk about people and culture. We've looked at two sets of things. Sort of like two big buckets. We've spent some time now just talking about lean management practices where we focused then on three of the key lean management practices; making work visible, limiting work in progress, and simplified change approval processes. So that was just kind of like one bucket. This is the second bucket now that we think is quite key for high-performance software organizations, which is looking at the people and the culture that are needed, shall we say, to be able to implement or work with lean management processes and practices, et cetera. So I think you can't have one without the other, sorry, if you like say.

Lande (29:26):

So when we look at the different aspects here, we're talking about empowerment, we talk about learning opportunities, understanding the mission and communication style. I'll just pick on empowerment and we will go through each of them. But empowerment is something that sort of stands out a little bit for me because empowerment is one of those words that sometimes means something and nothing in a way. So you hear like when we're talking within an agile sort of environment, et cetera, they use the word empowering teams and empowering people all the time. And sometimes it can feel a little bit empty because it's like, well, what does that mean? How do I empower people? I mean, a 5,000, 10,000 people organization, do I have to empower everybody? How do I do that, Marc?

Marc (30:25):

Well, simple question, I'll give you a simple of an answer as I can. This goes for life. One thing is clear boundaries. We can call them constraints. There's a book called Management 3.0 that talks about minimal constraints. There's also we use the term in Eficode called guardrails. One of the simple things is that, like I do this with tools all of the time. So I use the tools in order to empower the people to work within a certain set of guardrails or a certain set of constraints. So empowerment can be allowing a developer to take whatever work they wish from a prioritized list, perform the work and deliver it to production. And this means that they may have to contribute the quality tests, unit tests. Are there other test automation in their system or synthetic testing or load testing or any other kind of tests that they need to take into account?

Marc (31:29):

Many of the biggest online services in the world are doing this kind of thing that developers have, all the Facebooks and Twitters and all this kind of stuff. The developers have access to production and they work within constraints. Allowing the people also. One of the few things that you can do with culture to try to affect the culture of an organization, many say that culture is an emergent property, but we can use feedback to empower people. Many companies get this wrong because they try, they do the survey, they ask the questions and then they try to get feedback from the employees. And then they say, okay, we will now take this to the management team and we will decide what the important ones are and we will then create an action plan and we will then have this approved by the board of directors. And then next quarter, we will take your feedback and we will begin to improve. And it's like, no.

Marc (32:28):

So you empower employees by asking them, by gathering feedback and acting on it quickly. And then this creates what's called a feedback loop that then allows you to constantly try to get feedback from inside the house and even of course you do this with your customers, and then steer, show that you care. Take the feedback and act upon it as quickly as you can and use this in order to build trust in the organization, steer the organization and steer the culture.

Lande (32:57):

I mean, cool. Yes. I agree with most of what you said there. I do. But I think of course, again, I'll make that phrase again. If it was easy, we'd all be doing it and we wouldn't have to distinguish between high performance and low performance. But I think the thing that I liked, what you mentioned and which is quite key is the guardrails. So it's within the context, it's within the context of the organization. I think teams need to understand, the organization needs to understand what the guard rails are and I think that in itself is empowering because then you don't actually have to keep asking for permission.

Lande (33:40):

But the thing that I found the most difficult one is the feedback loops. I keep coming back to I'm in an organization with 10,000 people or 5,000 people. Fast feedback, I struggle with that, with those two words put together in the context of that organization. We could talk about that for quite some time, but in the interest of time, I will move on to the next one, learning opportunities. I mean, this is quite key. This is where we're talking about making sure that within the organization, in order to increase that NPS score we talked about. So this is the I want to work here and I want to work here because I get to learn, I get to do new things. I have an environment that is sort of nurturing enough for me to get better at what I do and I can contribute. So this is what we mean when we talk about learning opportunities. That's quite key, not just going to courses but the ability to sort of like put what you learn into practice.

Lande (34:38):

And then we move on to understanding the mission. And I think this sort of speaks a little bit to the example I gave with the poor SAP guy down here and this highfalutin sort of like strategies. We all need to understand where it is we're going and what we want to be able to do. And then finally, we talk about communication style. Now, for people who know me, this is something that I think is difficult and I find it a little bit difficult because I think your communication style, it's kind of difficult to have that devoid from your personality. Now put it into an organizational context and you think about what are the potential consequences of communication styles? What does it actually do to an organization when you have the wrong communication style? Marc, I'm going to throw this at you.

Marc (35:38):

Yeah. It's a skill that can be developed. This is one thing that many people don't understand. It's like if you look at every situation as in how am I going to get the best out of this person and what communication tools can I use to get the best out of a person in a situation? There's so many learning opportunities, I'll tie it back to this one. How many of you have gone to a course on conflict resolution? There's so many tools that you can have in your tool belt and so many things that you can learn in order to be a more effective communicator in a corporate environment. So training the messenger is a huge thing. I picked the coach guy for this slide because I think that like when I'm working with people and I have a strong opinion, the stronger the better about something, then the more I try to ask questions to understand somebody else's instead because if I just tell them, I kind of get them to double down on whatever their position is.

Marc (36:49):

So I've had to develop this skill over time to ask instead of telling as much as I can to try to get the best out of the person, and maybe I'll learn something I had no idea about. But this is something that if you're not getting it within an organization, you can try to work within that organization and you can also understand that perhaps there are other places that have a communication style that suits you better as well, but building it within the company is something that you can train, you can develop, you can skill. And a lot of it still comes back to what I said about empowerment, which is communication is about getting feedback and honoring that feedback by taking it into use quickly.

Lande (37:37):

I think that's an excellent point actually. I think we have this, one of the things we talked about earlier before we started the session was really sort of that constant, I say, as this constant ongoing dialogue between business and IT in the majority of organizations. So where we haven't quite got to the point where IT is business and business is IT and we're still sort of like separating ourselves. I think that communication, I mean, we could do a lot there. I have a fundamental belief that you have two sides that are speaking completely different language but they're talking about the same thing and they don't understand each other. We're using different languages. So yeah, totally with you in terms of we almost need coaching in how to be able to communicate in a manner that helps us to collaborate towards a common goal. Absolutely.

Marc (38:36):

I'll say one other thing about the mission. There's another true story although I've often said this like it's a joke because it's so humorous. Somebody told me that they brought together their management team and they worked on a strategy and they had workshops for days and everybody was really committed and really contributing. And then they approved the strategy and they're like, "All right, cool, so now let's go get everybody on board. Okay." And then they brought everybody together and they communicated the strategy. And then the person I was talking to, they said, "But it's like the rest of the teams they never really understood. We could never really get them to commit, but we really believed in it."

Marc (39:26):

And it's like, "Did you ask them to contribute to the strategy?" And then it's like, "Oh, are you serious?" It's like you gave me the answer when you told me how you created this strategy. It's like the people that contribute were committed and understood. And yeah, you've got 10,000 people, so you-

Lande (39:46):

You knew I was going to say that, didn't you?

Marc (39:48):

Yeah, I know. So how do you do that? And it's like you have to really figure out how to get the feedback loops down into the organization, rise the things to the top and really honor it because like I said, it was a half-joke about communication. I'm going to remind you, it's a developers market. So the developers are going to go to the high-performing organizations. And many of these things are so well understood that we know what they are.

Lande (40:18):

Absolutely. I mean, we've got a lot of catching up to do, so I'm going to move on now to the next slide. I think we don't have that much time left, but I think this is a good slide that's sort of worth explaining a little bit because it's really just emphasizing, yes, Marc and I are having a chat here. These aren't puzzle wisdom from landmark. This is sort of like known fact. This is information that is out there that is available and there's research supporting all of the stuff that we've been talking about. Marc, I don't know if you wanted to say anything additional on this.

Marc (40:57):

There's another story. This one is not my story, but I picked it up recently, but I'll tell it quickly.

Lande (41:01):

You have a lot of stories, Marc.

Marc (41:03):

Yeah, I know. I alluded to it before, but I'll just kind of repeat it really quickly, which is when you have state-of-the-art tools and process in place and you have reasonable visibility, and the Atlassian toolchain is a very good one for that, that you have the ability to get from the value into the developer, into the customer's hands very, very quickly. So if you think it's 440 times faster lead time from developer to deployment, that means today it's called zero-day delivery an awful lot of the time. It's not your next monthly release or your next quarterly release. Then if you screw it up, you also have the ability to have faster recovery from downtime, 170 times faster according to this pretty well-known research, which means that sometimes mistakes happen and we recover from them quickly, but we have five times lower failure rate with these changes even though they're 440 times faster.

Marc (42:04):

None of this is a conjecture. None of this is rocket science. This is using state-of-the-art tools and practices today to be able to deliver value quickly to your customers. There's a lot of companies that... I have been in software for 30 years and we dreamed about a lot of the things that now are standard and commonplace.

Lande (42:26):

And we're talking about this now, and this research was done three years ago and probably took about a year to pull together as well. So here we are three, four years later.

Marc (42:35):

Yeah. We're just starting to solve some of the mythical man-math problems that were written in the '60s.

Lande (42:41):

Yeah, absolutely. Okay. So just in conclusion, if there's one thing I would want people to take away from this, at least for me, where I keep coming back to again and again, and I love tools and I love experimenting with different things, but every time I come back to the people aspects. People work for people. Yes, you're in an organization, but it's like when they say you don't leave a bad job, you leave a bad boss sort of stuff. It's kind of that sort of phraseology here that I'm focusing on. People work for people. The best tools or processes is not a guarantee for high-performance unless everything that we have just said now doesn't mean anything if you don't know your customer. So it's important to emphasize this. It needs to be taken for granted that your priority is understanding who your customer is, listening to what they have to say, what they need, anticipating, being anticipatory. Being a little bit ahead of the curve in terms of trying to anticipate what they need.

Lande (43:55):

And then we talked about, and I think, Marc, you've alluded to this quite a few times now, moving towards a more generative organizational culture. This is pretty much taken from the Western's organizational cultures definitions where you have pathological, bureaucratic, and generative. And all we're really saying with generative here is more sort of like collaborative learning. I think you said train the messenger. All those positive things that we've been talking about that high-performance organizations do, we need to be able to move towards that type of culture within our organizations.

Lande (44:37):

And then the last two, I mean, using the information you have to get better. I love this. If the data tells you that it ain't working, it ain't working. Don't try and fudge the results and slant it so that your department or the stuff that you're doing doesn't come out looking so bad. That was the whole point. So let's take the data for what it is and implement the necessary changes.

Lande (45:04):

And then we have the last one, using best practices and using state-of-the-art tools. Not every organization is a special case. There's a lot of information, there's a lot of best practices, known practices, good practices, whichever way you want to term practices. There's a lot of state-of-the-art tools out there that you can use and adapt to your organization. There are very few special cases out there. There are some but most aren't. So I think there's actually a lot of material information out there to support as well as our very own Eficode consultancy services there to support you throughout these types of transitions.

Marc (45:53):

Is there anything else that comes to mind?

Lande (45:55):

Nope.

Marc (45:56):

Nope? Okay. Thank you Lande and thank you for all of our participants.

Lande (46:02):

Thank you, Marc.

Lauri (46:03):

Thank you for listening. You can find links to the social media profiles of Lande and Marc in the show notes, alongside some related materials that I believe could be of interest to you. If you haven't already, please subscribe to our podcast and give us a rating on your platform. It means the world to us. Also, check out our other episodes for interesting and exciting talks. Before I let you go, I give floor back to Lande and let her introduce Eficode and our relationship with Atlassian. All I say now is take care of yourself and remember to simplify the change approvals.

Lande (46:39):

Just to say a little bit Eficode, our organization and what we're about. We're a consultancy company primarily based in Northern Europe but with recent acquisitions in Switzerland. We are in over seven countries I think now. We've been around for quite some time, over 15 years. We have 400+ awesome consultants, professionals, both within Atlassian and DevOps. Yeah, we're really doing quite well and we're very happy about it. Our core expertise is in the DevOps consultancy as well as the Atlassian products and we also have our own Eficode with DevOps platform as well which we use with a lot of our key customers.

Lande (47:32):

One of the main things, as well as I mentioned earlier on is we are an Atlassian platinum partner in a number of countries, in Finland, Sweden, Denmark, Norway, Netherlands, and Germany. We've been working with Atlassian since 2008. So quite a long relationship with them I would say. And over the last four years, we've won quite a number of awards from Atlassian, from DevOps competency services, service management, et cetera. We have approximately about more than 600 customers across all the Atlassian services that we provide services to. We have a main hub in Sweden and then a recent acquisition in Switzerland. So yeah, we do know a fair bit about it.

Lande Castberg
Country Manager, Eficode Norway
https://www.linkedin.com/in/lande-castberg-72941a1/

Marc Dillon
Lead Consultant, Eficode
https://www.linkedin.com/in/marc-dillon-70709137/

Webinar recording: Measure your DevOps Transformation