Product Agility

From Silos to Synergy: The Journey of Wärtsilä’s Agile Transformation (With Mauro Sacchi)

• Ben Maynard & Mauro Saachi • Season 2 • Episode 25

Share episode

Send us a text

In this episode, we have the privilege of hosting Mauro Sacchi, an esteemed leader in digital R&D at Wärtsilä, whose innovative approach and vast experience in transforming traditional industries into agile powerhouses. 

We dive deep into the transformative journey of Wärtsilä, a global leader in maritime and energy industries, as they embraced large-scale Scrum (LeSS) to overcome traditional silos and achieve synergy in their product development processes. 

Episode Highlights:

  • The Challenge of Silos: How Wärtsilä’s traditional structure led to fragmented teams and inefficiencies.
  • Discovering LeSS: Mauro’s introduction to large-scale Scrum and his transformative training experience with Bas Vodde.
  • Implementation of LeSS: The decision to transition from multiple backlogs to a single, unified backlog.
  • Creating Synergy: How LeSS facilitated better prioritisation and alignment of team efforts towards customer-centric goals.
  • Unlocking Human Potential: Shifting the organisational mindset to value and leverage the full potential of every team member.


Key Takeaways:

  1. Embrace Unified Backlogs: Transitioning to a single backlog can significantly enhance prioritisation and team alignment.
  2. Support from Leadership: Sustained leadership support drives and maintains transformative change.
  3. Foster Cross-Functional Collaboration: Breaking down silos and encouraging teamwork leads to better product development and customer satisfaction.
  4. Value Continuous Learning: Encourage a culture of continuous improvement and learning to unlock the full potential of your teams.
  5. Navigate Necessary Friction: Embrace constructive dialogue and friction to achieve the best outcomes.

Connect with Mauro Sacchi on LinkedIn: https://bit.ly/3WlJ4az

Resources:

We’d love to hear your thoughts on this episode! Share your insights and continue the discussion on socials using the hashtag #ProductAgilityPodcast.

Host Bio

Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.

Stay up-to-date with us on our social media📱!

Ben Maynard

🔗 https://www.linkedin.com/in/benmaynard-sheev/

🐦 https://x.com/BenWMaynard

💻 https://sheev.co.uk/

Product Agility Podcast

🔗 https://www.linkedin.com/company/productagilitypod/

💻 https://productagilitypod.co.uk/

🖇️ https://linktr.ee/productagility


Listen & Share On Spotify & iTunes


Want to come on the podcast?

Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80

We did it one go in order to have a meaningful critical mass to really make a dent in in agility and directing the far power to the most valuable item. We decided to go in in in one Big Bang. All the previous backlog had been merged into one backlog. We elevated implicitly the role of the product owner because you are absolutely correct. The product owner is not a requirement analyst. Welcome to the Product Agility Podcast, the missing link between Agile and product. The purpose of this podcast is to share practical tips, strategies and stories from world class thought leaders and practitioners. Why I hear you ask? Well, I want to increase your knowledge and your motivation to experiment so that together we can create ever more successful products. My name is Ben Maynard and I'm your host. What has driven me for the last decade to bridge the gap between agility and product is a deep rooted belief that people and products evolving together can achieve mutual excellence. Hello and welcome to the Product Agility podcast. My name is Ben Maynard and today we are going to be exploring a topic which this podcast has not delved into for quite some time. When the podcast was founded many, many years ago, it was called Less Matters because I watched a really weighs the awareness of the usefulness of large scale Scrum as a system, as a school of thought, not as a framework per SE, but something which provides a brilliant way for to have all of your teams remain incredibly customer focused, right? Or achieve that customer focus if it doesn't really already exist. And over the years we've rebranded and we've rebranded because we've wanted to get more voices into the ears of our listeners because we felt that Les was constraining us a little bit. So today it's really nice to be always becoming full circle and welcome somebody onto the podcast who has an experience of large scale scrum because he has been working with the Co creator of large scale scrum, a gentleman named Baz Vodder, who is a friend of mine, has been a friend of mine long before I became a large scale scrum trainer. So who is this person? I'm sure you're keen to know. Now this person is Marrow Marosaki and he joins us from. Finland. That is correct. Ben, first of all, thanks for having me here and for pronunciating my name correctly. My name, yes, this time, yes, I am calling in from Finland, where I'm located on the other end. I guess my accent betrays me. I am Italian indeed. So I can. I cannot think so. Yes. And I joined from a company named. And thanks for having me. And indeed, we have a common friend. Yeah. So Vansilla or so in English as it spells what Silla, isn't it? I don't think I'm the right person to pronunciate correctly. The company been working on for 20 years because I'm not a finner and I'm trying my very best. It's called. Yeah, like, like Godzilla. But that's how I'm going to remember it. It's such a bad joke because it's the name is intriguing. Well in a naturally first of all it's 190 years old company. So it has a lot of history and it's strength. It operates in two industries, one is maritime and the other one is energy. So it's a heavy industry and two relatively conservative also industry that are very global and very needed by mankind. In this industry what we do, we specialize in equipment that is necessary to create to generate power. So equip both in marine and in energy, as you can imagine those equipment, so engines, combustion technology are going through a very interesting journey called decarbonizations and that's what we do today and that's what makes our day very interesting. Yeah. So decarbonization was what you mentioned there, wasn't it? I mean, that is correct. The all industries are going through a decarbonization journey dictated by the Paris Agreement and that translates in a lot of compliance and a lot of shift on infrastructural changes. So that are requiring a lot of technology development in all domains, mechanical, electrical and software. Well, this is what I was going to say because you're talking about maritime and energy. What we're not talking about here is some nice kind of like B2C kind of web-based products. Here we're talking, like you say, heavy machinery, we're talking hardware, we're talking software, we're talking everything in between and LED on to that the decarbonisation agenda, which for the record, I think is the right agenda. And I hope that it accelerates a likelihood that, you know, we become a wonderful futuristic, joyful world rather than some grimy old dystopian 1. So your role in Vatzilla, given this great introduction you've given like what is if it you do in the organization? I'm in charge for the digital research and development for our life cycle business. So basically as many industrial players, we are having a role in providing equipment to generate power and even a stronger role in supporting our customers in the life cycle of this product, which as you can imagine is relatively longer. It goes to 3040, even 50 year when you're talking about energy and plants, purple plants, installations. In order to deliver these services, we need to develop a lot of solutions that are enabling us to monitor how the equipment performs, how it complies to the regulations, how it efficiency serve the customers. So my role is to I'm the leader of the digital and the organization that is developing these solutions to enable our lifecycle services. And as the name goes digital RND sometime you know, you use this word a little bit as a password nowadays in corporate work digital, but the fact that what we do is a lot of software development and hardware development joined to deliver these kind of services. So you team, so it's your partly organization, your team is focusing purely on the on the software, but also all looking at the hardware as well. They all hardware, they're all infrastructure that basically goes from an asset on the field. So either a ship or a power plant, the integration with the product, with the equipment, so the automation and control whatever edge you need with computing, with data processing the old data pipeline, so connectivity and data pipeline until the cloud structure and the application in the cloud to help our people around the services for the customer. So we take care of the old infrastructure, the software and the hardware that is needed to deliver and also we take care of so activating the service and life cycles keep it up and running, which is not to be underestimated. Since you have an installed base of a lot of customer using your product then you also need to maintain it properly. Yeah. I mean, I think memories had the little pre recording chat a few weeks back. I think I mentioned, I asked, did do your customers own the hardware or do they lease it like you know, like airplane engines, like Rolls Royce, do they own the engines and they lease them out to people. But your customers, they physically own these pieces of hardware. And what you're then providing is this monitoring and compliance and kind of element to making sure that the life cycle of that product, that your products are effective for your customers for a long time, which is interesting because a lot of the time and some organizations to deliver just kind of digital products, you know, that's where things breakdown is that they just deliver it and it's done. And then actually there's customer support who maybe deal with the pain, but they're not actually actively monitoring it. I suppose that's what the hardware aspect to your products that says that's where that element that need comes in. Yeah, that's correct, Ben. I mean we do not lease this equipment for two reason. First of all, in the energy sector, this is critical infrastructure from any country when you're having power generation for electricity for example. So the customers, sometime even government entities want to own the asset. In maritime it's very difficult because it's so custom built that it will not have any so-called residual value if the customer will be coming. So many would have to use it on another ship. So it's usually a sold equipment which creates also the complexity then to deliver such services because you do not own the equipment. In only very rare case in energy sector, we help the customer to operate it. On the other end usually we don't. So we need to be able to provide the service where all very often we by the way commit on the reliability. So the up time of our product sometimes even the efficiency of this product without the factor owning it, not operating it. And that drives the need for having a very solid digital infrastructure and solutions because if you wouldn't have that, it would basically blind or deaf to how the product is utilized and at the same time committing and promising to the customers on certain reliability or efficiency without anything whatsoever control on how to deliver it. So that's that's the nature of the business. And and that's why this domain became more and more critical. Really fascinating. I'm not going to indulge myself any further on this. I'm not sure listeners like how fascinating you find out the deep dive into it I. Just a nerd. So we'll move on. How did you end up then, I suppose at Vaxilla using less, like what was your and say less for those of you that don't know less was something that was devised. Oh my God, 15, maybe 20 years ago, like a long, long time ago, around the same time that's was originally conceived. Ken Schraber, I think they worked with Bars father and Craig Larman around the same time they work at Nokia Ericsson. Craig and Bars wrote a white paper, wrote some fantastic books, which has described a way to help organizations understand what that product is and how to get their teams. Having really accurate, empathetic understanding for their customers and and work really closely with the customers to deliver the right thing in small pieces and get feedback on it as a system, as an approach, less has been run for many years and it is seen as increasingly seen as a great option for companies who want to find a way to get multiple teams or aligning on a really clear purpose. So Mara, how did you end up in this situation where you're using less? Let me tell you the story. First of all, I have to admit that I didn't know less until roughly three years ago when I took this specific role where, by the way, I've worked for 20 years and I've been a scrum practitioners for poof, I don't even remember how many years since roughly 2007, I've applied the scrum in pretty much all organization. What I've done development work not because I'm obsessed about implementing Scrum or having agility that serves always a purpose. And the main purpose is the flexibility that you get to reroute your far power to what is truly valuable. And three years ago, I received the opportunity to lead the organization that I described to you earlier. And when I joined this organization and my predecessor told me that this organization was founded on principle of less with the Spotify model. And as I say, I admitted that OK, I've been exposed to Scrum for quite many years. On the other end, I learned from literature about Spotify model. I only heard about lesson but frankly speaking, I didn't have enough knowledge. So what I is every other person, I hope when they don't know about something, they go and study. I bought the book and especially I signed up for the first variable bus training and that was November 2001 if I'm not mistaken. And that training was a revelation for me. It opened my eyes not because I'm fanatic about frameworks and I'm easily lured into something that can be seen as theoretical. I yet. Two challenges at work that I recognized in the organization I'm responsible for. The first one was that we had the inability to direct our firepower to the most valuable things to do for our customers because we were very fragmented into silos. And the second thing is that the human potential of our organization was somehow diminished by the hierarchical nature of the organization itself. And I'm keen about saying that because when I took this training, I came back to the office with two revelation, as I said. The first one was that the approach to product development prioritization based on value is perfectly reflecting the concept of one product and one backlog. And the second one is that people are at the center of the value creation witness. So it's not the framework, it's these two principles that definitely attracted me to this way of working because I had two concrete problems that I wanted to address. Yeah, it's so interesting you say some of those things because I think it's really easy for people to talk about Scrum and say, well, it's, you know, it's, it's one product backlog per product. But that's when all the problems of Scrum started in many respects because no one actually really looked and said what, what is my product? And said, you could look at your organization and have it structured in such a way where you have lots of silos which are based upon the technical domain. And so each one of those technical domains is a product. You're going to end up in a world of pain if when you try and use Scrum in that way because it was never designed to be used effectively in that way. And then that you are not customer centric at that point. And this is worth it. Less opens up eyes. And it opened up mine many years ago. So well, no, actually maybe they aren't your products. And this is where less gives you a great opportunity to say, well, actually, first of all, let's figure out what your product is. And then we'll say, actually, now you can have one product backlog and prioritize on value. And magically you can actually then prioritize on customer value. Then what you're saying about the inability to direct firepower due to the silos, when you say direct firepower, was that about guessing the right number of teams, right piece of work like Spain that a little bit for me. It's agility that you have in an organization to prioritize and focus the effort of the people on what's most valuable for the customers on a broader scope than typical silos that many companies are built around. So if you connect a little bit with what I try to describe very briefly about our our business and what was. We take care of his organization. We treat it now today as one product. On the other end, when I joined this organization, it was divided in over 10 teams. Each one of them had its own backlog, right. So when I say directing the firepower, very concretely speaking, I came across a situation where one of the team was working on something extremely valuable from the customer, where we had really even complained from from customer on the field that our development was not up to speed with our promise. And we were having difficulty to to prioritize the work from other teams to help this one team those having challenges. Why? Because the other teams had their own backlog and their own priority on the other end, this priority were less valuable if compared to the one that this one team had. So it was as simple. I mean, now I make it simple, as simple as removing those barriers and and putting all the firepower of the organization to work against those items that have highest in value. This move requires, in my view, not a process. This is not about the process and especially if I belong to a corporation, many corporations are tempted to jump into methods, frame or principle that are very process driven because that's comfortable. It gives this kind of false sense of control and it's more in line with what probably a big corporation in the way the big corporation work. It's not about the process. What we needed was that necessary friction to bring all the requests from the customers on a comparable way in order to really decide what is the most valuable one we should work on. And that friction in my view is very positive because it forces you to think where you should direct your pie power. On the other end, in multiple organization that we have been, that friction is uncomfortable. It requires a lot of leadership from especially from product ownership. It requires people to have an open mind to understand what's best for your customers. And it requires also to give up on certain belief or something maybe that it's internally generated. And many organization prefer to solve this by divide and conquer. So prioritization by organization I think must calls it, which means create silos so that we don't need to have that friction. We don't need to have that conversation. That conversation not having it is a missed opportunity for value creation. So it's not the process. Well, so I think that's hard for people to get over though, you know, by playing devil's advocate, Scrum in many organizations, to your point is, yeah, I think you alluded to this. Really, it was just another way to control our people. And it wasn't about achieving a valuable focus. It was about constraining people and getting them to work from a controlled list of stuff and making sure that they were all done by a certain date. And yeah, let's look at their velocity. Let's make sure that, yeah, look at the percentage of Sprint completion. And so I think I forgive people for thinking that's what this is all about when they hear particularly the word scrum. So what you were saying there about this necessary friction, this is a necessary friction that comes from saying we're not going to prioritize 10 individual lists. What we are going to do is we're going to prioritize one list or reprioritize constantly one list of work and make sure that as many of our teams as possible are all working from the most valuable pieces of work on that list. That's a fair summary of what you were saying there. Absolutely. And it also goes back to the way you treat customer requirements. So what you usually when it is a customer requirement, there is at least a perception there should be some value behind it. In our industry we don't have millions of customers. So the customer and fuel and they have a lot of weight. So sometimes customer request becomes almost a dictate you have to do it and that can lead you very easily in heavy customization. So you're not anymore doing product development, you are doing IT service providing the factor which is what you want to avoid. So it goes all the way from having that uncomfortable conversation that I think I mentioned it to our organization sometime in remember that a customer request does not necessarily mean that this is the most important value item that mean to develop. Also, a customer request is often a user request. Meaning that you are talking to a customer, but the factor you're talking to an individual person at the customer organization. Those requests need to be validated with multiple users from the customer, maybe other customer before you draw into conclusion and you jump into develop something. And when you start to question and challenge and especially when you start to put item in competition with each other, you create that friction that we discussed so far. In my view, and I'm a strong believer of this, that friction is absolutely positive that it's a dialogue that you need to have to do proper product ownership. It requires lots of guts though, because in a big corporation you might be digging your own political grave if it's not done in new manners. Sometimes you need to compromise, sometimes you can, how to say, raise the volume of your voice. So it requires a bit of a balancing act on the other end. I'm a strong believer of this principle. So one product, one backlog, thinking what is your product and not make it too small. Remove the silos and and go for one backlog that creates. It's a perfect platform to create that conversation, that friction that we discussed so far. You stole my question because at the very top when you're kind of talking through things I did write down here, you're not going to end up with lots of customization and very bespoke products. And you've kind of you've helped with that. And what I loved about your answer, what you shared of us, then I think everyone listening would also appreciate this was the product ownership in many organizations. When people think about it, it's just that team level, you don't have the opportunity to have those conversations. You're not in any position organizationally. And I use the word hierarchically because often that's what it comes down to, to stand up and have that fight. You don't even, you're even aware some people can't even go and talk to the customer. And then when you started talking like that, you know what you sounded like was a very experienced product manager and then you did the bait and switch at the end and say that's what takes to be a good product owner. And I think this is really interesting in your mind then for what you do at Varzilla, well, maybe even just generally, do you see a difference between a product manager and a product owner? This is frankly speaking, I have difficulty to respond this question to you because it's, I would say it's a domain where we are still learning. We do have a product owner who is owning the product with developer and de facto mediating across multiple organization and customer requests in order to find that one prioritization for that one backlog that then we we used to direct our firepower. On the other hand, we do have a lot of product managers from various organization that are requesting or proxying, sometimes also customer requested to this one product owner we have. So yes, there is a difference. And I said that difficulty to describe to you because it's a bit of a learning process for us too. If I try to summarize it, the product owner as we have it, I would say it reflects very much the role of a product owner in a less organization. So is that one person who wants the product and has the authority to prioritize the product management organization? Are those organization in our company that are developing the business that this product is sometimes part of And then maybe this is a bit of a different comparing to a company that where these two role might be one? So our product is not sold stand alone it, it does not play a role by itself. It's part of a bigger ecosystem of services. Usually it's an agreement that we sign with the customer where the product we have is only one of the parts that goes to custom internal by nucleation. And I know it might add some complexity. This is the reality of the business we're in. I suspect that many other companies especially big corporation with a long history are similarly placed because they won't do that. They want to develop their digital product in usually in a synergetic way to avoid application. And this side effect that we discussed on the other end, they have a lot of go to market solutions that might reutilize that one product in multiple different ways. So there is that in internal push and pull and friction that we discussed so far. I hope I try to respond to your questions as I say that I don't have easy of life in responding because this is a topic that we are learning along the journal. It's a topic people are interested in and it's a question that's always thrown out there and it isn't one where there is a definitive answer it which applies correctly to every context because it does differ wildly in organizations and you just can't save as a unifying truth of it. One thing that does seem to be a common pattern is that product managers tend to spend more of their time looking out to the customer. Where's product owners balancing their time looking out and looking in to the organization as well and having his hard internal conversations is one pattern which you see is reasonably, I suppose, consistent, I found. But even then, there's always going to be differences in times when that isn't the case. And I think you find the smaller companies, maybe there is one person there who does them both. But at the same time, lots of companies, they don't start off using Scrum from a less perspective and they and they're on that journey and on that journey things will change and they're probably going to be actually having an existent incumbent product organization or product managers already exists. So yeah, obviously it does depend hugely, but Lester's ask for a much more serious kind of approach to product ownership. Now what you were saying about the they can get back to necessary friction for a second. It reminded me when we used less huge at Deutsche Bank and we walked in and I was told everything because we had 45 projects and we looked him OK, this is crazy. Why is there 45 projects? And we looked at understanding what the product was and deep down my heart of hearts, we knew there was one product, but we went for free because the friction between getting. Person from product one stakeholder and product two stakeholders, actually, they wouldn't be in the same room together. And we thought we have enough of a challenge going from 45 projects to free products, let alone trying to deal with these two people that just can't stand the sight of each other. So what? Yeah, we. So I think that was a big lesson for us, you know, and I admire the fact that you went from those 10 backlogs to one and did so did you do that in one move? Just kind of one day all flipped and you were just on one backlog and then you created that necessary friction and dealt with it. Or was it more gradual? We did it one go. And first of all, we were not an incredibly big organization. We had roughly 10 teams. So we're not talking about 45 projects or a hundreds of teams. And two, I would say too much small fragmentation to take it step by step in order to have a meaningful critical mass to really make a dent in agility and directing the far power to the most valuable item. We decided to go in, in one Big Bang or big but Big Bang anyway. And that's what we did. So all the previous backlog had been merged into one backlog and that necessary friction started and we elevated implicitly the role of the product owner because you are absolutely correct. The product owner is not a requirement analyst or or I've seen a lot of interpretation of product ownership. My career in, in an organization that is adopting less principles. Product owner is a serious role and it needs to be respected, needs to be. It's not, by the way, a nice role or they're all can be nice, but it doesn't necessary to be always a nice person because there are hard decisions to be made. And I think, sorry, I want to rephrase this. It's not about being a nice person, but it doesn't necessarily need to be a person who is only making himself or a self popular. It's actually the opposite. Often. Oh, you won't get anywhere if you just want to be popular. It isn't. I thought I might certified less training that I give. They've got a slide. When we're talking product owner, it says that says don't be nice because it can't be about being nice, because if you're not, if you want to be nice to everyone, then you end up and nothing. Nice is a very subjective thing. But what we're saying is that no, or at least saying not is an incredibly powerful thing to do. And there's a product manager we had Uncle Jenny Sarger, who said, yeah, she spends probably a good proportion of her day every day saying no or not yet to people. But that's what being a good product person is about. Yeah. And in our domain, because I want to really give you the reality flavor, it also means, as you also said before, understanding what is politically doable because there's no point to theoretically push to the most idealistic scenario. If that would be a suicidal move, then nobody achieves anything. So you need to compromise sometimes. We decided yet to go for one backlog and and we secured also that we would have our upper management leadership to back it up. So you need to be able to calibrate what you can do because somebody would be disappointed and some organizations, some customs that are going to be disappointed means also that they're not going to be able to harness business value as you say, not yet, maybe later, but this later, especially for stock listed company means my maybe missing 1, two quarter or even the whole financial year and that has a financial impact. Yeah. And this kind of thing you need to take into account. So the senior leadership support to go for one product because there is a synergetic value to it as versus the drawback of maybe failing on some of the shorter term deliverables for some of the businesses. At the end of the day, it's a business case. So you need some time to compromise in order to not basically suicide politically and then actually nobody has anything to gain into it. Nevertheless, in our case, we were able to go for one product, one backlog and I have to say a couple of year of very good three to adapt to that way of working. And by the way, that feature will never end because if that would end, it would be a bad sign in my view. Yeah, why? Why would it be a bad sign? Because if you don't have friction, it means that you don't have dialogue. If you don't have dialogue, it means that maybe you don't need to have that dialogue because you are more independent and independence usually means silo for me. And if you have a dialogue, it's unavoidable that at times you will have friction, especially when it comes to the time, not yet for some time. It's also clear not that nobody, not everybody's happy. And that of course creates a friction. So as long as there are signs of friction, it means that we are having a good conversations that is the best for the company and our customers. I have a quote. In other words, it wasn't a quote that was in my head about if it's things aren't uncomfortable sometimes and you're probably not trying hard enough. Like if it's all too easy and all too happy, then it's like at some point that's gonna bite you on the ass. As we say in the UK, you need a bit of that uncomfortableness to keep people at the edge of trying something new. Trying something different isn't a conversation about OK ours. If you looked at OK ours as an example, they work when it but it forces people to stretch and when there are very, very few of them. Yes, it one and this same much of it like a road map set really clear goal, make it a stretch, get people challenged. It's going to feel uncomfortable, but you're going to get there. You can have uncomfortable conversations to remain that focused, but you're going to get there and hopefully it's the right bet you put on and it pays off. I can give you a word that I learned from many training that I do, you know many leadership training nowadays, we are supposed to always use the positive terms. OK, challenge is not uncomfortable. These are courageous conversations that are very nice. I think I'll stick to uncomfortable. There was a CTA that I've coached for a while and they were phenomenal. But for what? One thing I I, I learned a lot from this person. And they said that all of our career and their life, they'd avoided having what they would always see is the difficult conversation. And they found that one simple. And it's one of those classic click baity things like one simple hack solved it all for them when and they they just got it from a title of a book. They said they'd stop seeing those conversations as difficult and just saw them as crucial. There you go. And the moment this person decided that they're crucial conversations, they thought to themselves, well, I can't, I can't avoid that, can I, if it's crucial, but I need to step up and have this conversation now. And I think that's part of a difficulty, isn't it? I think with some of the words that we use and I think the one thing that a good mindset, a good product mindset, one thing that a good or something like less will provide that is that opportunity to have those crucial conversations frequently because that means that you're trying something. I love that now I want to loop background because I'm just keeping out of time and it is slipping through our fingers. You said about the human potential being inhibited by hierarchy as well. The other reason why can this is the less cause kind of structure of you. Like in what way was human potential inhibited by hierarchy? This topic is very close to my heart. Well. There is a big difference between if you look at an organization that does agile development is so often associated to software. As I said, we don't only do software and I also that I like by the way, from the space where we're doing product development and in our case we also deliver it. The cycle. There is an approach that tends to look at this type of organization as IT service providers. So they provide an infrastructure, they provide the software, and they're usually told what to code. And you know, this mindset is hard to change. Especially keep in mind that many of the people who are operating in our industries are very sorry with a very solid background in mechanical electrical engineering. Software is a an emerging domain and software in this company has been exposed to people who have a primarily mechanical background primarily as software needed for internal purpose. Like you know, for example, you need to develop a report from your CRM solution and then usually you outsource that because you tell what you want and there is an external company that does the work for you and then you get it. So now instead the software, the software element and also the hardware that is needed to run the software become the product or part of the product. And, and all of a sudden they are not anymore something that you can just outsource and delegate to an IT service provider. They become a critical using or the critical engineering discipline, but they should be put on the same table next to other very needed discipline like mechanical, electrical dimension. It's a huge mental step though. And when I joined this organization, I found a lot of super clever people, people with master degree in physics, PhD in advanced mathematics, you name it. And I said, OK, and how are we working today? What we are asked things to code. Don't you have anything to say about why are we coding this and what are we trying to achieve? Of course I do. On the other end, organization we are interfacing to are most of the time simply cascading down requirements that many of the developers didn't have any idea where they were coming from. So there was too much hierarchical gap in between the problem. That usually is all the opportunity that you want to seize with your customer and at the end what a person who is doing product development gets on the table. And that's what I mean miss opportunity because you have a lot of capable people who are not utilized under full potential nor even motivated to, to, to really express their full potential. And and this is for me is the cultural shift that needs to undergo corporation that do not have the the software element in their DNA today on the other end, they should have it down the road. It's about elevating the people who are doing software engineering and put them around the table with the other engineering discipline to work together around the problem of the opportunity. That's product development. me, and that's the human element that I loved in less because in less a lot actually is asked to the people and to the teams a lot. And let me tell you, I also a lot more than what I estimated. I underestimated this aspect. It takes time for the organization you belong to to shift the minds and also for the developer themselves to actually start to, hey, wait a second, I can actually grow into this. The question is also, do I want to grow? Some people don't necessarily want to grow. Some people instead really want to seize the opportunity and then you need to give them time. Well, that's the human element I'm talking about then and that's why it's very close to my heart because it's about getting really the true potential of people and getting the motivation from people to to express themselves. So do you feel that you are now closer to untapping all that potential? Yes, and I am confident about it because I see a lot of individual and a lot of them flourishing. I want to also though, to be very open about this. It's not a walk in the park. Some individuals, some people don't necessarily like to to work in an environment where a lot more is demanded from them. Some people really, truly just want to code and be told what to do. And that's probably this is not the right place to be because we expect more and we all suspect that people will be curious and learn new things, help their team belong beyond their comfort zone. So we are in that trajectory. We are far better than than three years ago. Definitely. It's not a short term journey. It's about creating a culture, it's about creating a mindset and it's in for the long term. It's for the long term. And that's also one of the challenges, I believe if you want to use this world that wants to engage in a transformation, less principle needs to take into account, you need to play the long game. There are, of course, quick wins. And nevertheless, creating an organization and and with this culture, it takes, it takes a long time. Yeah, I think it's always so vastly underestimated. I think particularly when you're a senior person in an organization or dare I say, someone acting in a coaching capacity to sit there. Why wouldn't they want to sit around the table? Why wouldn't they want to speak to the customers? And do you know what? Lots of people don't initially. I think it's a real problem that we have where we assume that other people are gonna think like like we do. And we need to remember, I'm talking about myself here. Absolutely. I've been guilty of this. Think I I didn't really appreciate what it was to be a engineer, a developer, programmer, whatever we want to label these great people as you know in the modern digital organization. I hadn't done it for a long time so I didn't really know what it was like to my assumption that everyone wanted to do it was just flawed, but there were people that did want to do it they just needed opportunity. But even then, it still took a long time for them to want to take the opportunity because they were fearful for many reasons, whether it was because particularly first English was like their 4th, 4th, 5th language or something and they had to go and talk to somebody in in English And they were a bit like, I don't a very senior person in the bank or something. I don't want to appear sitting in front of them. Once it started, it's fine. No one ever looked back. But it takes a long time. It takes a lot of dedication. They say when you have people in your organization that don't fit this mold, have you found that people have left or have you kept people on but put them in a different, give them some kind of, I don't know, free pass so they don't have to get involved with these types of situations? No, no, no. We, we are quite adamant that people who are belonging to teams, they need to do the best to make the team successful, even if it means working, for example, on a domain or an expertise that they don't have. We stress the fact that we are a learning organization. Sometimes learning is and should be a deliverable person. So it means that if you are picking up worker that is not in your comfort zone as an individual or a team, maybe you need to dedicate a Sprint or two to learn that domain with other teams that are proficient in order to learn. So we didn't create anomaly. We, we try to avoid them as much as we could because if we thought it would be, it would prevent ultimately the shift to this kind of mindset, it would make it even longer. So. And I can tell you this was also a necessary friction. So, and frankly speaking, one that I have to admit I underestimated because I thought that an individual who is offered to have more freedom to give more even opportunity to question the why, to contribute, to define the how to do things and, and speak directly with the customer, with other colleagues rather than be told what to do. I thought people would love that because it puts them in a much more exposed role learning situation where you are really understanding why you're doing certain things, etcetera. Not everyone likes that and I was surprised personally. So maybe there's a bit of a blind spot of me. I was surprised. And on the other hand, many other people, of course, do love it. So that's but we were not creating a normal. It's not where we we try to minimize that as much as we could. Yeah, I admire that. I think you're going to go on this type of change journey. You got to understand what I hate the phrase, but what the card rows are what are your what is called red lines? And my old CEO used to explain it in by saying that. You've been playing your game for a long time in the organization, and let's say your game is tennis, and we're coming along with a new version of tennis wherever the court is a different shape and the rackets are somewhat different and the balls a different way. I need to find a way to kind of play our game of tennis. You can't, OK, watch the ball go out and say that, oh, that's in because it used to be in. The lines have moved now. And so now you're playing this game. And if you don't like the game, then we'll help you find somewhere you can go play a game you're more comfortable with. If you want to learn how to play this game with us, then we'll give you the right support, the right coaching, the right education so that you can then develop the right muscles and the right attitude to play this new version of a game. And we understand that if you don't, then that's fine, and we'll help you find somewhere else. Yeah, that's exactly what we did. And also we try to be as frank as we can with everyone who's coming in also that we are trying to bridge also two cultures that are coming closer with each other. So the domain, the software domain or the IT domain in general as a different dynamic, different different life, life cycle, speed and cycle than the mechanical world for obviously it's much more dynamic. And there is also, let me be very, very open, there is also a generational gap. There are many more youngsters in the in the software domain that are emerging and they are they're colliding at sometimes also with people who are from previous generation. And so it's it's about blending in two culture in terms of domain. So software mechanical at the different pace and also different generation in terms of really age, talking really about age, Yeah. And when we, when we get people on board, we explain them of course that this friction will be there. And it's a lot to ask to the people because we are asking for the older people who are maybe more rooted into the history and the mechanical history of the company, which is absolutely super valuable for what we they need to accept. Also that these youngsters are coming up with a lot of new ideas. Some of them will make sense, some of them will not make sense. On the other end, they don't want to sound arrogant. So it's just that they need to ventilate and express what they come up with. Otherwise they would be just told what to do. And on the other end, the youngster needs to also respect and accept that some of the colleagues who are coming from the mechanical world actually know a lot. Now, what I usually say, because I came across both cases by the way, is that I told some time to our guys. Guys, you cannot go into a meeting with the customers and mechanical engineer attending that you know about combustion technology because you read it from Wikipedia yesterday. You need to respect that this is another job and we have people who are very experienced in that. At the same time, I tell to the mechanical engineer from other organization guys, you cannot go into a meeting with customer and us pretending that you know about software because you you made an Excel yesterday. That's the not software engineer. You need to respect that this is a different profession and we have people experience with that. So it's all the time, this continuous bridging effort to bring to community and to generation, to work together to get 1 + 1 = 3 rather than -1 that's bad math. You don't want that. I know I'm Italian. Poetic license. Oh, yeah, that's lovely. I love it. So we are, we're kind of almost a time. But there was one question I wanted to ask you. We focused on some of the kind of negative aspects here. But then you did say that some teams flourished. And I was just wondering if you could give us a brief and insight. Yeah. Invokes of the for you person is a senior person organization. When you say that a team is flourishing like what you see great question. I love it. First of all, I see different dynamics in the team. The teams take ownership, the team care about the what they do, they care about the product, they care about the success of the team and helping each other. Irrespective if one guys who know him likes more doing back end tomorrow needs to do some front end or that a scientist or even go and interview the customers. So people who are truly going beyond their comfort zone and with a good smile also so, so I've seen teams that are having excellent positive dynamics because they embrace the simple principle that we are doing product development. I'm a team member. The success of my team is the primary objective for value creation and I do whatever it takes in my team to help that team succeed and therefore deliver value to customers. And when the dynamic creates and by the way, it does not go to technical skill only, it's a lot of so skill, leadership and attitude. Then you have the perfect mix. And I've seen it in few teams really. Like when it clicks, it's a pleasure to the eyes. Lovely. Thank you so much. My road now. Yeah, we're we're at time. Unfortunately, I'm trying to get really good at keeping episodes like 45 minutes and we're just a tad over. Thank you so much for your your time and your energy. You know, I'm a, as I mentioned couple of times, I'm a large scrum trainer and I'd have my courses in London a couple of times a year. And the people that come along, I don't think anybody leaves with what they thought they were going to leave with when they come along to a less course because it isn't about Scrum in my opinion. It's about. So much more, so much, so many things that are useful for people in product worlds or in kind of engineering roles. I think it's and so it's really great to hear your perspective on all of this. I think you give it a really honest and compelling account for people. Honestly, I think just to go and learn more about less, whether that's from me or whether it's from somebody else. So I think, yeah, thank you so much for coming on and making this time. It's been a joy to have you on. But if people wanted to connect with you and ask you a question about something you've brought up on the podcast or just interested in researching you, I take it LinkedIn is a good place to find you. Absolutely. You can find me LinkedIn. You can contact me directly there and then we find whatever means of communication he or she wants that. Then I can continue there. Absolutely. I would recommend, by the way, not only product developers or people who going to coaching to go to a less training. I would actually recommend organization leaders because the less training for me was primarily about principle on how to design organization to succeed from the human aspect and from the principle on how to design it. So it's and that was also an eye opener for me. I know you're right, you're right. I think this is where there's a course with the certified less executives, which is like a it's bit less scary. Even a three day course is a 2 day course, But I almost Ioffer them publicly, but I don't run them publicly anymore because what I find is that people will come along and ask about it. And when you speak to them, actually what's much more valuable for me just to go in the organization for a couple of days. It probably ends up being a similar price if they're going to Chuck a few people on the course, but then you actually get to really go into that organizational design element. So yeah, no, that's that's the bits of large scale scrum that I like. If people are interested in finding out more about less, OK, you can go to www.lesssoless.works WORKS. If you're interested in looking what I do when it comes to less and head to www.she, that's SH EE v.k.uk. And there you can see my less courses and some other courses I deliver. With that said, thank you everyone for listening. It's been a fantastic episode and really nice to kind of just hear about large scale scrum again. Marrow, thank you very much for giving up your time to come on on the podcast and share your insights and your expertise with our listeners. Anything you'd like to share, Mario, before we head off? Don't give up. It's worth it. And thanks a lot, Ben, for having me here. And thanks for the audience to listening to us because Barry, you are a listener of the podcast at times. Yeah. So yeah, that's I don't know. I'd love to chat afterwards. Let's know what it's like. Came from listener to to interviewee. Everyone again, thank you so much for listening. This is the Productivity Podcast, and we'll be back again next week.

People on this episode

Head Shot

Ben Maynard

Host