When we think about large companies undergoing a digital transformation, we often think about it literally; the digital change of the toolchain, and applications. However, it takes both technology and people skills to perform this change. Jörgen Lindberg, a DevOps and Agile coach consultant and Sofus Albertsen, DevOps consultant and the Eficode Academy headmaster discuss “digital transformation”: what does it mean, how to prioritize the problems to solve, and how to make it a successful project.
Hello, and welcome to DevOps Sauna. My name is Lauri, and I'm the chief marketing officer of Eficode. When we think about large companies undergoing a digital transformation, we often think about it literally, the digital chains of the tool chain and applications. But if you do not accept the fact that it takes both technology and people skills to perform this change, you are doomed to fail.
We had a chance to invite Jörgen Lindberg, DevOps and a job coach consultant with experience for multiple transformation projects and Sofus Albertsen, DevOps consultant and the Eficode Academy headmaster. Jörgen and Sofus discuss about digital transformation, what does it mean, how to prioritize the problems to solve and how to make it a successful project. Let's dive in, and we are on. Welcome Jörgen. Welcome Sofus. Just glad to have you here.
Good to be here.
Whoever that was, but they said that you have to enjoy the journey as much you're enjoying the outcome. You could say that when we sat down and worked on this interview with you, for me it has been a journey. Getting here, it's like, what is called, anticlimactic even. Like, okay, I know what we're going to discuss. Something like that.
Well just like a kitchen chef, right. You have prepared everything and now you're going to show what you've prepared. It's going to be awesome because you thought about it, right?
Yeah. Yeah. So why don't we start by giving both of you floor to tell our listeners who you are, where do you come from, what brought you here in rough terms. Then once you two have introduced yourself, then I suggest we go right into our first question, which is what does this digital transformation mean? Where do companies come from to get into this situation when they make a decision to do a digital transformation? Maybe we start with you, Sofus, who is going to participate intently in this conversation with Jörgen. Then we give floor to Jörgen after that, and then he can get right onto answering the question.
Yeah. Thank you, Lauri. Yeah. So, my name is Sofus Albertsen. I am from Eficode, the same as Lauri. I'm the academy headmaster. So, I'm the one centralizing my work around knowledge sharing and all our training, both internally and externally. So knowledge sharing is really my number one thing I'd like to do and I like to talk about. For me, the digital transformation is also a lot about knowledge sharing because we get new tools and we get new ways of working. The only way that we can be good at that is actually get new knowledge. So Jörgen.
Yeah. Thank you. I'm mainly a software guy that's been doing some hardware. Really passionate about developing people and organizations. I started out a while back doing transformations. I've been doing four successful bigger transformations so far. So that has become what I mainly do in my own company. I've been doing these transformations with completely different businesses. So, they're quite agnostic. Thanks for having me.
Glad to have you. Jörgen, would you like to continue by just giving us a context for what the digital transformation is in those cases or the DevOps transformation where you have been involved. What is the background where companies start doing that?
Yeah. The backgrounds have been a bit different, but either it's that you have a problem in your organization that you've identified yourself that you want to improve. Or maybe that you have a competitor that is better than you in doing something and it's a must for competing basically. So that's the background why doing digital transformation. Then the context of it, you soon realize that it's not so much or digital is one thing, but it's usually a bigger scope than that. You need to take all aspects into account, not just technology.
Yeah. Because when you take the word digital transformation, there is of course the digital one, the electronic part, the technology, but there's also the transformation. Every time you do transformation where people are involved, you need to transform the people as well. You need to change that.
Yeah. So, when we are doing these digital transformations, do you then think that the focus should need to be only on the tools or is that a holistic approach? How can you see this step going?
No. I mean, may be a common mistake that is the tools, but it's so much about the people. It's about the incentives. It's about HR, finance and everything. I mean, at some point in time, everybody's going to be or all companies are going to be a software company. So yeah.
So when they call you up, when they find out that they have a problem, what is it normally characterizes that problem? I know, I mean, it's difficult to say well they all have this particular problem, but there must be some characteristics around it.
Yeah. Like I said, either it can be internally identified that they want to be faster. They want to be twice as fast. They realize that the organization is not keeping up. Or they have a disruptive competitor that they need to be faster than or they need to increase their quality because they have a lot of customer issues.
So, we're at back again at this kodak moment where somebody else have made a change. Now you are either sticking with your old and then slowly going to, what's it called, fate in the past of the history or you're going to change.
Yeah. Amazon Bookstore or Apple Watch.
Your experience from transformations is when the management has made the decision that this must happen and then you get called in. Or do you get called in when the management is still sort of, or if it's even a management, but the company is still thinking okay, should we go into this or not? When is it typically that you get called in?
Usually management have made some decisions, but the reasons can be both very clear and very unclear. It has been also we heard about agile. This seems nice. It's something we should do more. It can be more well-motivated or agile just being a means to an end for achieving then double speed or something like that. So it's a bit different, but I mean, the importance of actually making that decision and being firm in the transformation and really believing that it's needed is really important. That's a key to being successful, I think, is that you have a commitment from maybe not top, top management always, but you need a good sponsor. You need somebody, a champion in the right position. That's crucial for a transformation to be successful.
If we try to illustrate the situation for our listeners in that let's suppose that that tough conversation has taken place. Then a high enough number of people have come to their realization that this must happen now. They call you in. Then you probably form a virtual team or a working group or whatever you want to call it to get their change going in a concrete level. You get into this room and everybody hears a briefing from whoever is their executive sponsor. Then you have 90 minutes to make the best out of it. Like what happens? How does it start to get from high-level level management desire into something concrete?
Yeah, that's difficult. I mean to be successful, you need to determine the critical thing, what's in it for me? That's a question everybody in the room will ask themselves because that's the way to get them on board basically. Since it's not just about technology in IT, it's actually about all the aspects of the company, that becomes difficult. You need to take all those into account. People have incentives and bonus plans and whatnot that can be counterproductive, of course. So, you need to start figuring out what's in it for them, and perhaps identify a couple of easy or quick wins that you can get done so that you get some more people on board.
Yeah. Usually, it's “Houston we got a problem” moment where they call up and say, "We need some help." But at least in my experience, it's also a lot centered around the tools. So, we got a call saying, "We can't deliver fast enough. I think we need to change our build system," or "We have problems with testing. So therefore there must be some tools that we haven't installed yet." What I can see is that, of course, tools can be one thing, but as you change these tools and as you go in and look at the organization in general, you find out that it's not only the tools that needs to be changed. It's also the processes around it and all the people, the way that they communicate. I mean, the whole pipeline that is not the technical build server pipeline, but the pipeline of the value stream I think is... What's the correct term here? The value stream of the software and the product that you're releasing.
Yeah. I mean, it's really difficult to make improvements to the value-adding activities in a process. It's usually much more efficient to remove the waste in a process.
So when these companies come in and ask for help, how do you see it? Do they go in and say, "I want a transformation. Can I please buy one piece of transformation?" Or how should they grasp if they can see they need to change, but should they do it themselves from the ground up? Should they buy everything outside, outsource it, or where's the middle ground there?
Yeah. I mean, you need to take into account exactly what kind of organization you're going to have after the transformation actually. What are you going to keep doing? If you don't have that competence today, then you need to acquire it and build it up. Then I would hire and get that service in there and get consultants to teach me and then hand it over. So, everything that needs to remain afterwards, I secure that.
Are there things that you shouldn't buy outside? Is there things that are too vital for the transformation that you need to have internally?
I mean, whatever is your core business, you should have a stake in I guess always, and not leave too much to consultants in those areas, of course. But it can be a transition as well where you start from zero. You get some consultants in to build a competence or something. But again, take into account whatever is going to be there when you're done and make sure that you secure that and get that turned over from the consultants.
And if we look at it from the other side, is there then some things that you would recommend them never to invest in themselves and just buy from a vendor or from a technical consultancy firm?
I think doing a digital transformation, if you haven't done it before, get some help for sure. Call us up. You can have my number afterwards.
But I mean, this is quite difficult and there are many pitfalls. If you haven't done it before, you most likely aren't going to do with very often. So, it's better to have consultants do it. You just have to be sure that it's what you want to do and make sure that you dedicate the resources to it that's needed for it and so on.
So you say that it's rather difficult to make at least a successful transformation. What are the key factors for making it a success?
I touched on it a bit before. I think with a top sponsor. That's really key that that person or the individual is in the right position. That it's not about just technology. That it's diverse. You need to get finance and HR in there as well, not only if it's the CTO or whatever. Then that you have a possibility of incentives that are counterproductive and that you have a chance of maybe getting rid of those so that you don't have something that's working against you all the time. I think the last thing is that you have either a vision or a really high ambition for your organization, and that you know where you want to go and what good looks like.
Yeah. Because when you're doing this unique to deaccelerate for some other things because you're using a lot of resources on making the transformation itself on meetings, on communication, on people skills as you say as well. Therefore, you can't say, "Well, I want 100% throughput of the normal regular value streams and pipeline that I normally have and I also want the digital transformation on the other hand." So you need to be willing to pay extra resources and extra attention to it while also going a little bit slower pace doing the transformation, right.
Right. Exactly. There is a cap on how much change an organization can take at a given point in time. You should make sure that people don't get tired of change and have too much on their plate. So yeah. That's a good point. You need to balance that.
And in agile, we're talking about having these very small increments of work. Can you do a traditional or can you do a digital transformation with the same approach saying, well we're changing one little bit, teeny tiny bit at a time? Or do you need to have some kind of substantial volume in the change in order for it to be realizable?
You want to start small so that you get those quick wins, so that to get more people on board. But of course, since it is involving all the aspects of the company, you need things to move forward together at some pace so that you don't leave some parts behind. But I mean of course you want to start the smallest you can and build up from that based on successful wins. That's I think the best approach, trying to find the minimum viable product of the transformation and go from there.
What happens when you're during the minimum viable product to see that, okay I thought that I could change only this team. Then the entire value chain otherwise will be unaffected. Then you can see, well there's spill over here. We need to change further. Should you then try to isolate or try to integrate the changes to spill over to the other teams?
I think that that is difficult and it will vary. So that's again where the experience comes in and where you should have consultants that's done it before so that you can make different calls depending on the situation actually. It's really difficult to give advice on how to treat those situations actually.
Speaking about doing a big, big transformation that also touches the culture of the organization, I could imagine that sometimes the company has a very heavy reliance or they are thinking it in a sort of waterfallish way, traditionally. So, just by bringing in transformation means that you are teaching the organization to move away from big planning and big changes into more iterative planning, smaller changes and then sort of learning from them. It sounds to me like a chicken and egg. That it's very hard to do transformation in an iterative fashion because the company has gotten used to doing everything in big releases. So, how do you cope with this challenge where just by doing the transformation in the right way seems to be challenging to comprehend for your organization that you are trying to do the change?
Yeah, absolutely. I think you're absolutely correct. But if you tried to draw the parallel to adjunct way of working, that it's not possible to pre-think everything and make waterfallish plans because you cannot imagine every possible future. You can make that parallel to a transformation and get some understanding that it's actually true for a transformation as well that you need to do it in a iterative fashion because you cannot imagine all the ways that it can go. It's better to take learnings from and adapt your plan accordingly all the time. But yeah. Of course, if you're from a waterfall organization to begin with, you probably want that rock solid Gantt chart of the entire transformation. But that's not going to happen.
Well, you can produce it. Then you can revise it and revise it and revise it.
Yeah. Exactly. Yeah.
So to me, there's also a thing called big enough because I mean you can most certainly change a small thing here and there. But for example, if you're changing your version control system, which again is a very technical part, but there's a lot of things tied into that. So, you can't just say, "Well, okay now for this small team over here, we're changing things." But if they have tight closed collaborations with others, then they also need to know the new version control system. They also have integration with their build service. So, we need to make sure that they're build service work. We need to make sure that their release pipeline is still intact for all of this.
So, for me, it's really about starting small, accepting that it will get bigger. That every change will have spillovers to the next to the next. Then find out okay, when can we say this is big enough? This is good enough in shape and size in order for us to say, "This is the change that we really want." You can't say see that to begin with. Just like you say, well you can try to make the Gantt presentation and the project report two years in a row and then say, "Well, this is going to happen." But it will never be that that is going to be executed at the end. It really depends on when you start to shake the entire system, what is falling off and what is sticking together.
Yeah, I completely agree. We know for a fact that our crystal balls are not very good. So, imagine the future is really hard and it's much easier to try and do something and learn from there. Then build on the learnings that you actually gained that are real learning.
So if I put my self in the position of the company owner, and I have ordered you to make one piece of digital transformation for me. Oftentimes, I would say that that would be something that you would start working with immediately. Yet, I can see when we're doing digital transformation, a lot of the first couple of months maybe, it's not that productive in a way that we are changing anything because we are serving the entire landscape of the process. Do you see that as well that we need to make sure that what the management think is the reality is also the reality down on the workers floor, if you in quotes might say that?
Yeah, I agree. You also need to poke around a bit and see where it hurts actually. When you find that place where it hurts, you poke around more and usually you have a problem to fix. I think you can be a bit upfront with management on that it's going to change in shape and size over time. That they will have to adapt as well and accept that it's not a very fixed thing, the digital transformation.
So there's the very evident piece of change where you rip off the old build system to the new build system. But that is just a result of a lot of things happening underneath, right. There's a lot of processes that are changed, a lot of things that need to be prepared beforehand. So you even though you can't see that there is, what'd you say? That you would lay the bricks for the next coming change, you really need to pave the road in order for us to change.
There's something similar to what you're describing when you renew marketing. I just want to bring this up just to point that there are so many things in transformation that can be applied across different disciplines. They don't only apply for, let's say, software development or R&D. In marketing, we like to think that you go to the part of the... you try to imagine how does the system look like when it's big if your scale today is more. You try to imagine where is the choke point when your system is going to be big. Then you go and look at that choke point and say, okay if I'm going to put load on this side or stress on this side of the system, it will expose burden on this part of the process. You have to proactively go and make sure that that part doesn't break.
So, let's imagine that you want to increase the number of customers that you're serving at the same time. You don't want to get a lot of customers in and then start to worry about how to serve them. You have to go back and think, okay how do I serve 10 times more customers than I have today? Then imagine where that will break with 10 times the load. Then go and make sure that part doesn't break. Then you go back and start increasing the load. Then you see, okay, does it break there or doesn't break somewhere else. But there in the same way, and what you said Sofus, you don't see those changes. You're rebuilding the foundation to make sure that when you start to do the right thing, your house doesn't collapse under the load.
Yes, and you do a lot of small experimentation so you have a hypothesis that you want to do this and this. Can you actually do that with the new tools? Okay. Then you go in and test just that. I can see that that's one of the approaches that you need to do in order to build confidence in the change. So you can go out to the people that you're working with and say, "Well, I can see here that we can do this change with your code. We can do these transformations with all of these things. It will work," before actually turning the key and switching over to the other tool that you are introducing without it hurting in production. So you need to take it away and put it into a sandbox or a lab and do these kinds of tests.
Yeah. In marketing, the change is not that okay, it's a big change to go make changes with those systems. I mean, once you have figured it out, it's quite straightforward. The big challenge is the cultural revolution that you have to get people behind the idea that actually have to go back and make those hypothesis. You have to go back and test those hypothesis instead of just going and making the system changes. I could imagine that digital transformation is as much of cultural revolution than it is about the systems itself. But again, my experience is not where yours is. So, I'm just bringing a parallel here.
That's where I think having really, really high ambitions and knowing what good looks like it becomes really important. Because if you set goals that are quite close to where you are today, it will not promote thinking in new ways. You need to set really, really ambitious goals to rip out all the bad old thinking that you have in the organization and change the culture a bit. That ambitious goals helps a lot in changing the mindset. You have to look at completely new solutions instead of shaving seconds off a bit of time here and there. You need to do something really disruptive and change the way you consider things and so on.
And when doing these big transformations, Jörgen, because I completely agree with you that that shaving off or making it 2% faster is rarely what a digital transformation is about. That's tuning the machine after you've made the transformation or if you're satisfied with what you have. Normally, when we're doing a transformation is because we have this Houston. We have a problem moment where we are simply not good enough, and it's not tweaks here and there that needs to do it. But this comes at a big burden to the employees of the company, right. They're going to change everything. So, how do you make sure that the transformation is not only seen as a way to cut cost or a way to get the old people fired and get replaced by new ones? How do you make sure that you have this psychological safety in the transformation as well?
Yeah, great thing. This quick wins is again important so that people are a bit more motivated and engaged because everybody wants to be on the winning team kind of. So that's important that you get those and that you prove that this is actually a working path forward. So, I think usually you want more for the same kind of resources that you have, if it's people or money. You can learn new things and get into new roles and transform the company that way. So that possibility is always there and that of course you can communicate and get out there in the organization that there are going to be new roles for people.
And when we were talking about that we also, in the beginning, are poking around in the system trying to figure out where things hurt, you can also say that we're knowing everybody's pain points so that we can address them. Because I mean, a quick win can be good for you or good for one team, but very bad for another. If you're always making progress on the expense of a certain team, then at some point, they will probably tell you that they don't want to be in the digital transformation boat anymore. They want to get off.
Yeah. That's of course true.
But making sure that you know that everybody, like to tackle everybody's pain points. Or if not, then at least be aware that you're saying, okay now this team is taking one for the entire company by doing more manual work or by doing this and this. Resuming these responsibilities for a certain given amount of time and making sure that they are okay with it.
So talking about these transformations, a lot of things is changing and a lot of things is changing along the way as you say. It's not going to be a document of 400 pages that you're just going to distribute to all the employees and then saying, "This is the new way of doing things and now you have changed." So, communication becomes a very important part of it. How do you normally tackle this?
You have to try and use all the channels that you got at your disposal and try and use them as much as you can basically. Try to get as much feedback as you can in communication so that you make sure it's not one way communication but two way. I don't think that it's possible that there is a thing where you communicate too much. You're usually on the side of too little always in a transformation.
So, having this marathon of change that you need to make sure that just because you are very good at communicating the change in the beginning of your marathon, doesn't mean that at the end when you're hitting the wall and you're thinking that all these things are finally coming together, but all the energy in the organization is about to be spent. That you don't neglect that you still need to communicate, and you still need to make sure that everybody is aligned. What happens if you don't communicate?
You lose people's engagement, of course. You start getting counterproductive actions taking place and all sorts of things. People moving back to their old ways of working because they know them and feel comfortable with them. I mean, the last kind of step of any transformation is making it stick for real and making sure that you don't have any going back to the old ways. That's, of course, difficult. It can take time and requires a lot of effort. It usually takes a bit longer than you would imagine. The people driving the transformation and being engaged in it, usually those closest to the transformation, they go through their change curve before everybody else. You shouldn't neglect that people have their own change curve and needs to go through it. They're not at the same place as you are in the transformation for sure.
So, it might be that the technical transformation actually happens before the cultural or the individual transformation.
So, when you're doing this, there's a lot of cultural aspects as well. Can you say whether or not there is a type of company or a thing that a company should focus on before doing these digital transformations from the cultural perspective?
From a cultural perspective, the values and the principles that are behind, if you're doing an agile transformation in this digital transformation is, of course, not always aligned with company values or the company values that actually rules. Meaning the company values that are shown when you see who gets promoted and who gets a salary raise or whatever. The real company values might be very much command and control and really difficult to get to work together with employees that are highly educated white collar workers that probably know the work that they're doing better than their managers. So, you need to make sure that you're either prepared to change your values to be the same as works with these highly educated people, or you're going to have a big problem actually.
Yeah. We had somebody joining from OP, which is a Finnish bank who are in progress of their transformation at large. We discussed about this sort of interplay between culture and tools. Henri Helakari who I had an opportunity to talk, I can't remember the exact phrasing, but he said something akin to tools exposing shortcomings in the culture. So when you put those tools in place, you will learn something about the culture that you then have to go and address and vice versa. That once you start addressing those challenges or addressing the symptoms coming from the culture, you will realize that okay, that is a requirement for a tool or it's a requirement towards the tools. Then you have to go and it's like a constant interplay between okay, how do we get the culture right? Okay. How does that influence the tools and how does the tools then influence culture? But it's about one revealing the shortcomings in the other, which I think it's a pretty smart way of thinking about it.
Yeah. That sounds really interesting. Do you have any example from?
I do not, but we should go back and get Henri to talk with us again. Maybe we could get a deeper dive in sort of iterative development of culture and tools. We do have a recording though, so we could... Well, I'll definitely be linking it here.
My thinking regarding it, I mean if you don't get the decision making to be on the right level together with the tools, then it can become very challenging. So if you have this kind of command and control old style decision-making where you have to promote all the discussions up to a higher level, then you will have difficulty managing it in an efficient way. You will be very slow or you'll have other problems related to it.
And all the pain points that are the everyday pain points saying okay, if I get new tools, I won't be able to do this, this and this. If you don't have the psychological safety in the company to say, "Well, this is going to be a real problem for me. I am not able to carry out my work if we're changing it in this way," if you're afraid to say that then the change will fail at some point. At least after a couple of months after you have made the actual technical change because something will just break in the entire value chain.
I remember in our pre-call for this podcast, we talked about that the value chain reflects the power struggles inside the company. That you can look at it and say, "This is very weird. Why do you have three teams that are all doing sort of the same thing in very inflated flavors or fragrance?" You can almost see that that's because there were three managers that at some point parted ways or all got promoted, but they still want a piece of their old cake. That is a thing you need to tackle when you're doing the transformation again as well because if you're just reinstating the old evolutionary failures or changes that are not logical, but are bound by power instead, then you are not releasing the company from the struggles that they're actually having.
Yeah, that's true. I was thinking actually on the previous topic also that we need to consider those people that actually are saying and not following it. Like you said, Sofus, that they actually have a point probably. Based on their viewpoint, they can be useful in getting more information about what we need to do in the transformation. All feedback is important and that you have that psychological safety is, like you said, extremely important to be able to gather all that feedback so that you make the right choices.
So when doing this transformation, we're talking about how much of a toll it takes on the organization as a whole. But what we're really also saying is that it influences all the individual people that are affected by this transformation. This can make people, what's it called, drained of energy and going into some kind of dismay where they're just paralyzed by the change. So instead of being enthusiastic, they're just not doing anything at all. How do we feed energy and enthusiasm into this change because I mean it is a thing that really needs to get pumped up to come over the burdens and the challenges that digital transformation will uncover.
These quick wins are important. Again, you need them really to get people engaged and get on board so that they see what's in it for them. Like I just mentioned, also that you actually listen to people and take into account what they need to be able to do their job. Show that you are listening by making the right changes and not forcing through changes just for changes sake. Like you mentioned, being more for power or politics instead of something that is logical or actually it has a real need in the organization.
Then of course, in some things, like I mentioned, it's very important. You can, of course, make sure that you get HR on board and actually make changes to those incentives early on so that they can help you in the transformation instead of being counterproductive. That might give you a small motivation and a boost. But yeah, long-term incentives are also difficult. Research show it's not very motivating over time actually. It's better to pay people what they're worth every day of the year than delaying for years in some retention plan or something.
I mean, coming back to what you say is that all transformations needs to have a strategy, needs to have a vision. We need to be able to verbalize and illustrate where it is that we're going to because otherwise, we won't be doing this. If somebody is telling you, "Hey, if you change, you get a 3% salary raise this year." Fantastic. But if it's only this year and it's only for that, then the whole energy to do the transformation and to be curious about what does this transformation, what does this change mean to me will probably go away. Because if you're inclined to say yes, then you're also just inclined to say, "Yeah, I will take the salary increase for this year no matter what consequences they're on." Then the next year I can say well, this is not going to work at all. Then I can get another 5% salary increase by doing something different or by reversing back to the old one because that worked better.
Yeah. I mean incentives and KPIs are extremely difficult to get right. It's you get exactly what you measure. You have to make sure that you measure the right things. Otherwise, you get something else.
So, how do you avoid the situation where the team facilitating the transformation either it's measured in a way that it becomes detrimental to themselves. So that not only talking about that the results of the transformation, but also looking at the progress of the project itself. That you might make a unintended error in selecting the wrong metrics and then it will become to your disadvantage. Or even further than the world is moving faster than you are and therefore, even though you make progress, that your benchmark is going to advance faster. Then you're just going to miss your targets.
Yeah. I think the goals cannot be on transformation activities or transformation objectives. They are not themselves important. They're only a means to an end. So, the KPIs or the metrics that you use should be based on some kind of a business need that you have shorter time to market or whatever. Then you need to find the right activities or things to do in your transformation to meet that. But the goals on the actual transformation or the activities is those are the wrong metrics really. So, basing it on the business needs that's I hope to get it right. Again, Sofus mentioned psychological safety. I mean, you need a team also that will tell you that this is the wrong metrics to use. It's driving us in the wrong direction, and actually help you change it in that case and not let any prestige or anything go into that. Just changing the metrics when needed.
So the old adage is true here. Do not measure outputs, measure outcomes.
And those outcomes are then agreed with basically the overall business owner. You have mentioned speed as one, which can clearly be one of the similar. Actually, as it happens, we ask our own people who come to interact with us one way or another. We ask them, what's your biggest problem? Here's the list of problems that we think you might have. One is the speed. One is the overall cost. One is quality. So, there's maybe five or six options and invariably speed comes on top. So if there's one thing to do, in our case, with DevOps and sustainable software development, if there's one thing to do it is make us faster. Help us become faster. That is the overall metric that seems to come on top of everything else.
Yeah. I usually categorize my metrics in faster, more better, happier. You need to cover all of them. But yeah, I agree. Faster is usually the overarching one.
When hearing and talking about KPIs, I really come to think of this fable with the genie in the bottle, right. Be careful what you wish for because you tell the genie, I want a fast car, and then you get transformed into the fast car instead and you got what you asked for. You weren't just precise enough. It seemed like that KPIs is sort of the same thing. I mean, it's great powers to steer people, but if you're not specific enough, if you're not genuine enough, then you get what you measure, but what your measure is wrong.
Yeah. But then you need to establish the right feedback loops so that you get the right information if you're on your right trajectory or not. If you get indications that this is not the right thing, then change fast or just remove it, the KPI, until you figure out something better to measure. It's better to remove a bad KPI than to keep waiting for something else.
But that kind of courage that you're presenting there because then you're recognizing that okay, what I did was wrong or what I thought I was measuring is not what I'm actually measuring right now. The impact of my goals are not aligning with what I actually want. That's, to me, at least exactly the same when you're doing the transformation because you are going into the unchartered territory. You don't know what is going on afterwards. You have a hypothesis that by changing these and these things, you will be better, faster, stronger, happier, but you don't know that yet.
So if you come into a situation where you can say. "Okay, I can either stick with my vision here and just go full frontal on it and use all my energy because I think that there's a vague chance that this will work." Or be honest with yourself and honest with the transformation as well and say, "Okay, I can see this is a problem. I don't have an answer right now, but I will get to the bottom of this. I will research and I will come back and find out whether or not this is the right place for us to be, or we need to change."
Yeah. I mean, courage is a big factor in successful transformations I think because there was going to be, for instance, like we spoke about the dip in performance while doing the change. You need to be able to build enough trust in the organization to cope during that tough time and make sure that you're going to get out of it at some point in time. But yeah, courage is needed. The culture is really important. Having that, I really liked that term, psychological safety that you used, Sofus.
Because at some point you're hitting, again if you're coming back to the marathon thing, you're hitting the wall, right. You are lower in performance than were before. So your customers will notice or at least your customer representatives will notice, your sales department will notice. You have tried to change things already. So, you are also in a way where you have shaken the tree. Everybody is waiting for the change, but it hasn't materialized yet. But they can just see the people are getting information over and over again.
That's where, as you said Jörgen, you need to have courage to stay on track or to accept that maybe this was not the right way of doing things. It doesn't need to be that you then just scrape everything away, but that you tackle each and every one of the issues that you get in an honest way saying, "Okay, yes, I can see that. There's a problem." I've come to a number of time where my idea of the future was not the right one. Then you need to change because all of a sudden, you find a restriction in their system that just can't do the thing that you envisioned. Then you need to say, "Oops, I can see that we need to change. I haven't gotten the right answer right now, but I'm sure I will work on it right away and get back on track."
Yeah, absolutely. I mean, it's happened to me. I've had the situation where I actually put in a bad KPI on my teams. We tried it for a while and they came and told me, "This is a really crappy KPI. It's driving us in the wrong direction. We should remove it or find something else to measure." We did remove it, and we didn't find actually an alternative. So, we just did without.
But there you showed the courage to say, "Yes, I can see this is a problem. I don't have a solution right now." But the solution is not to just put the KPI where it is and let it stay because it's actively working against us. I have a thing that I want to do, but I can't do it right now because I can't figure it out a KPI that can resolve to this. And that takes courage because then you're saying, "Okay, I hope that you know what we're trying to achieve here, but apparently I can't measure it. So try to help me out."
So when we're starting these transformations, these digital transformations, when we're starting the start of the journey, what is the good advice for, let's say, a project manager knowing right now that they need to change? They need to do this journey, whether or not it's a new build system or whatever it is. What kind of advice can we give that person?
Give us a call. I mean, if it's a bigger scope, a bigger transformation you haven't done this sort of thing before, actually get helped to do the transformation. If you need to do it several times in the future, then you can build it by learning during the first transformation. I think that's really important because it is difficult to get it right the first time for sure. You also need to really have a goal. I mean, I've worked with organizations that have a lot of money. They are doing great already. Their motivation to do the transformation has sometimes being a bit shaky. So, you need to be sure of what you're doing and really mean it and put the resources that it's needed for it. It's going to take time and resources in your organization. So you cannot pretend like it's going to be for free. I think that's the real important part.
Then, like I said in the beginning, secure that person in the right position that can champion the change and help out in the change. And will take the hit when it becomes a bit windy and people start doubting and so on. I think those are the advice I would give somebody that's about to embark on a transformation like I've been through a couple of times.
You said give us a call. You may not want to practice transformation with your own company. There's a Finnish expression on building houses because in Finland, it's not rare that people decide to "build their own houses." Which basically means taking care of the project management for a bunch of professionals who is doing it for them. Then there are people who put in more of their own sweat equity into building their house with their own bare hands. The expression goes that when you do it yourself, it turns out to be the way it happened to come. You cannot influence the circumstances. It will just turn out the way it happens to turn out, and that's going to be the outcome of your own work of your beautiful hands.
So I can only subscribe that if you really know what you're doing, yes then that is what you should be doing yourself. I think you said it earlier there that you have to assess where you are good and where you are not, and then decide to take the plunge on those areas where you are good. Then those areas where you are not that good, then maybe you shouldn't allow things to turn out as they happen to turn out rather than seeking for help with somebody who has done that before.
Yeah. A very good analogy.
If I take my academy hat on, it's all about capabilities, right. So as you say, Lauri, it's about what do you have and what do you need. What you have and need as well, well fine. You have that. You don't need to worry about that. If you need new capabilities and you also need it afterwards, after the transformation, well then you need somebody that can upskill your people. That can be a consultant that comes in and upskill your people while he or she are working with you or you can do training or whatever it is.
But something you don't really need as a capability, the capability to change from one version control system to another, unless you have thousands of people that are doing this or hundreds of team that need to do it, well then you're right. Then you can have this kind of airlift team that can go team by team and do the same transformation over and over again. But if you're just doing it once or twice, then you don't need to build up that capability internally. Then you need to just buy it from the outside. Buy it from somebody that has been doing this as an airlift team over and over again.
It's always a pleasure to listen to the experts talk from the experience. You know that the textbook information has been tested in the real life and the outcome is something that doesn't only work once or only in theory. Thanks again for listening, and don't forget to learn more about the transformations from the content linked in the show notes. Now I say you goodbye, stay safe and keep zero-day delivering.