Creating Value and Reducing Risk with Strategic Work Slicing (With Anton Skornyakov)

In this episode, Ben Maynard sits down with Anton Skornyakov, a distinguished Agile coach and author of "The Art of Slicing Work." Anton's extensive background in mathematics, physics, and successful startups provides a unique perspective on product development and organisational change. In this conversation, Anton delves into the crucial concept of work slicing, explaining how to create value and reduce risk by strategically breaking down tasks. He emphasises the importance of behaviour change, the hidden complexities in product development, and how to navigate unpredictability with effective slicing techniques.

Anton on LinkedIn - https://www.linkedin.com/in/antonskornyakov/

Key Highlights:

🔍 15:00 - Product Vision and Roadmap

🔍 20:29 - Agile Efficiency vs. Flexibility 

🔍 33:32 - The Power of Negative Feedback


You will gain invaluable insights into how to overcome common barriers in large organisations and implement effective strategies for enhancing product delivery and customer satisfaction. Join us as Anton shares his extensive knowledge and practical tips, equipping you with the tools needed to achieve unparalleled success in a competitive marketplace. 

Reflective Questions for Listeners:

How can you apply work slicing to achieve better results in your projects?

What steps can you take to ensure quality assurance in shorter iterations?

How does your current approach to feedback and change support or hinder your success?

If you enjoyed this episode, please leave us a review and share it with your friends, colleagues, and network. Subscribe to the Product Agility Podcast for more insightful conversations with industry experts.

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

🔗 http://bitly.ws/GFwi

🐦 http://bitly.ws/GFwq

💻 http://bitly.ws/GFwz

Product Agility Podcast

🔗 http://bitly.ws/FdVJ

🐦 http://bitly.ws/FdVT

🤳 http://bitly.ws/FdW9

🎶 http://bitly.ws/FdWj

🎥 http://bitly.ws/FdWy

💻 http://bitly.ws/GFuS

👤 http://bitly.ws/GFvy

Listen & Share On Spotify & iTunes

• Spotify - https://spoti.fi/3XzuzND
• iTunes - https://apple.co/3YvTX8p

Want to come on the podcast?

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

Transcript

0:00

It may be that they will use it, it will be handy, but it will not deliver the value that they hope for. May create some unwanted consequences making other things complicated that you don't know. People may find completely other users to what you offer that you didn't know. This is just a list of what typically happens when you try to change people's behavior. 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, I am your host and today we are joined by Anton Skornupon. Anton is a gentleman who I met I don't know how many years ago. I've got a feeling it could have been. A lot of years ago, I mean, I can't remember, I want to say maybe in Amsterdam. It was in Amsterdam at the first ever less conference, God, over 10 years ago properly. I don't think it's quite that long, but yeah, almost God, Jesus anyway. And it's so nice to have you here. And that was really amusing for me when I got an e-mail from one of the various kind of podcasting marketing agencies saying, oh, we have this author who's written this book. I was like, oh, this is interesting. It's always nice when you get approached with these by these people. And I looked and I was like, oh, that name looks familiar. And lo and behold, it was Anton. So it's awesome to have you here, Anton. And we're going to be spending some time talking today about the art of slicing, which is the art of slicing work, which is the title of your book, and also exploring various other really, really relevant product and and draw related themes. But before we get into the meat of it, Anton, I'd love it if you could introduce yourself to my listeners. Well, thank you. Thank you for having me, Ben, for this warm welcome. Right. So I'm Anton, living in Berlin, Germany. I think what you need to know about me is that I used to be a mathematician and a physicist. I tend to hear from people, they teach that that. Kind of they understand that this is a kind of a quite high up meta perspective. I've found a couple of startups, some of them with some success that it was big enough that to have a lot of employees and to try things out and to ask for money and to also be some somewhat successful with it. And at some point I turned to coaching and helping others be successful. In the beginning it was actually just with products. And because of my personal interests, I'm moving on and my focus is not so much on products, but actually helping different kind of organizations do well in the general way projects that are unpredictable. But most of the time everything with that I'm dealing with is changing people's behaviors, just not only with products but also sometimes with. With rules that you set up in in your organizations to change some kind of quality assurance processes or that rules that you may set up in a public entity to deal with constituents and things like that. And really, I think that's the the subtitle to anything I'm going to talk about today is behavior change. And we're talking about this today, or at least initially from the perspective of your book, the art of slicing work, which is a great book. And I think if anyone's interested in the topics that we raised today, then please do go and have that book down. Anton, if anyone is already get wondering, oh, what is this book? Yeah, the best way they can come slicingwork.com slicing word go Thomas the website. There you'll find everything fantastic. So the art of slicing work. We were talking about how maybe best we start this conversation and we had a lot of different ideas and waving ways in which we could start it. But it's important to me, I suppose, to help people understand. I think that the whole idea of slicing sometimes gets a bad, I was going to say bad rap. I don't know how well that translates. It has a bad taste that comes with it sometimes. So I think it's lumped together with lots of other things like user stories and etcetera, etcetera. And actually, you know, I don't think conceptually and you look at the impact that slicing could have, it doesn't necessarily have to be with any of those other techniques. I think that comes with loud and clear in your book. What we're talking about here, Anton, is having a real focus on the results of what you're doing other than the activities. And how can we get results which have a behaviour change either with a product, physical or digital, or with perhaps some process change or some rules that we're putting in place. What we're talking about here then is how can we get those results? And Anton, I think what I'm curious about is in your book, how do you propose that we begin, right? We want to get results. We have something which is big. We have something which is unpredictable, it's complicated slash complex and we want to break it down and have an impact by delivering something. Small balloons will change how how do we start that journey? Well, what we typically set off right when we start, we have this big hairy idea most of the time, like we can have any kind of product vision set up and it's full of hypothesis. And you know, if you if you've dealt with products, you know, huge amounts of hypothesis, how do you start? And the idea is that most of the time when you do something for the first time, you are unfamiliar with what you start off with. And so the intuitive, the standard thing to do, the obvious thing to do is to. Break your idea apart in different parts and start to build it right and that's when a lot of things go wrong because the surprising matter of doing something for the first time, the surprising part of it is when you don't know what's going to surprise you. You don't know where the dependencies are because you know, there is this very typical exercise that we do with people when we talk about prioritization. You take a lot of different pieces of your project or product development endeavor and, and then you put them, what is the most valuable and what is the most risky part and what do you start with? And I, I do this with, in all of my trainings with product people and I asked them, where do you start? And almost all of the hands always go up with the low risk, high value things. Everyone starts with the low risk, high value things and I tell them, well, it's wrong guys. If you start there, you will build all the high value, low risk things and then you will move on to the risky things and then you will find out what the risk is telling you. All of those unfamiliar surprises will surface and suddenly everything that you've done before that is in danger is is maybe has to be completely redone or or maybe is is even you find out it is it was useless because you found out people want something completely different. And all those things that you thought are high value low risk were actually dependent on the high risk high value things. And this non obvious part of it is that we think we know what the dependencies are. And I'm not talking about technical dependencies. I'm, I'm talking about like, you need to have an e-mail address of someone before you tell, send them a newsletter. Like, like logical dependencies, like things are dependent on each other. And when you don't know what's going to surprise it, you don't know what dependencies is going to be. That is the most important part. And so, so the question and, and now we, we go back to the title. The question is, when you have a huge, large endeavor and you're doing it something for the very first time, how do you break up this journey? And, and, and so as, as you said, like there's a lot of splitting Cheat Sheets and a lot of stuff out there, a lot of techniques. And most of those techniques are, are useful, but they are as they're kind of in, in the woods, you can't see the forests when you are doing that. And, and what I'm advocating and what I'm trying to, to help people with with my book is to kind of keep the big picture because that's, that's the main perspective you want to have whenever you are set out to change people's behavior, whether it's with a product or with a changed regulation or something like that. And, and for that kind of examples are useful. In my experience, whenever I'm talking to people like that, I need to bring things down to real examples. And I think before we started our recording, we had this conversation. You posted something about this, this renovating job of the house, right? This renovation project. I like this one because it's, it's similar enough to product development, but it's also not really product development. So the story is there is a family. It's story of a participant in a training of mine. He he bought a house outside the town that needed a lot of repairing. It was very cheap and the idea was to have a kind of vacation home for his family. And then he started off he went to an architect and he said, well, what what are we going to do to renovate this house? They created the whole plan which looked. Very sequential, right? First people will take care of the walls and stuff like that. And then they've done this for 1/2 a year to find out there is a huge amount of surprises. So once they thought everything is done and they start to doing the wiring, they realize, oh, the wires do not run where they are supposed to run. The plumbing is not is not the way it's supposed to. The plants, though, there's a lot of surprises. And suddenly they have to, you know, call back the person who was reinforcing the walls and it didn't work out. It's like half a year. He was paying a lot of money. It didn't work out. She changed it. He found a new contractor who who would bring him people that could do everything. And they would start working and renovating this house one room at a time. And suddenly, after a month, already they could have, you know, a kitchen, a bathroom and one bedroom. Where the family could stay and suddenly kind of the product was useful and while doing that they uncovered all kind of surprises and, and, and and you know room by room they, they created and renovated the whole house. Do we mean with the, the slicing work when you renovate the house, you know activity by activity only only do the only do the walls only do the wiring or only do the plumbing that is breaking up work, right. But it is horizontal in activities versus the slicing work, which is slicing it in vertical parts, meaning one room at a time for this renovation of a house or one behavioral change changing feature in your product, one at a time and and then learning from it. I like the connection between the rooms of the house and then the behavior changing feature. Yeah, that kind of makes a lot of sense. And if we just take it back to what you're saying earlier about riskier start with the start with the risky things. And also, yeah, I think you mentioned surprises. And the definition of a surprise is that you can't predict it. Otherwise it wouldn't be a surprise. So if we think about the types of risks that you were thinking about. And then when you're teaching people particularly like product people, product owners about how to prioritize, I mean risk is a really broad term here and you mentioned dependencies which come up things. But could you give us a bit more of an insight then and said when we talk about the risky things like what risks are we talking about? Yeah, yeah, that's, that's good that you are pointing this out that the risk is, is, is a broad word. What I'm actually end up using most often is familiarity. I'm I'm asking you, what are you unfamiliar with? Like when when you do something and you've completely done the same thing before, then you are maybe not familiar. I mean, if you've done it only once, maybe you are only repeating it for the first time. Maybe there's still things that you know, you, you didn't know we're risky or, or or you didn't know we're tricky in the first time. And then those, those things will surface when you do it the second time. But when you do something 10 times, you know how it how it's done. However, when you are doing something for the first time, like you are using maybe some technology that you already used in hundreds of different environments, but then you applying it to a new environment, then there is something unfamiliar about that, right? And look for those unfamiliar parts, what is the thing that you're doing that is new? And whenever you you're doing something new, there is typical sources of surprise to happen whenever and when you're building products, you are you're changing people's behaviour. So how people typically? You know what, what are things that typically go wrong and and again, this is not an exhaustive risk is it's gonna be surprise. You know, we cannot the unsurprised here people here with this podcast, but people will, you know, not notice something. People will notice but not understand. People will understand notice and understand will will not use it will be unhandy. It may be they they will use it. It will be handy, but it will not deliver the value that they hope for. It will make even. It may create some unwanted consequences, making other things complicated that you don't know. People may find completely other users to what you offer that you didn't know. This is just a list of what typically happens when you try to change people's behaviours and when you have something when, when you have competition in your system or when, when you are, when there is kind of other systems involved, other human systems involved, it gets so much messier. So one of the examples in the book, because I'm trying to make this topic wider and not talk just about product development. One of the examples in the book is about a government entity that is helping refugees. Right, a huge topic now in times of war. And there was one example of what they tried, right? Because because they're trying to make sure that those families that arrive, that especially the kids that can be integrated, they go to school, they can learn. So they thought, well, many of them, they don't have, you know, a good, good lamp to read. They have kind of a big lamp, but they, you know, it's, it's not a good environment. So, so they thought about people providing people with little lamps for their tables. Now, now they've done that. It was a long thing, long planned. Next, huge amounts of lamps were there on the on the little markets, on the street, at the little Sunday markets, a huge amounts of lamps. So what will happen? Well, if people don't have money, well, guess what they got they got, they're gonna sell some of it. So, so the question is, you know you've done something right, but what happens when you offer something in the best with the best intentions? Something surprising will happen, right? Something surprising will happen. And I think the one thing I think that product and agile people can generally agree as a decent idea is to work in small batches and to try and get some kind of feedback on that thing that you've done as quickly as possible and meaningful feedback. And I, I know that we could now go into talking about, well, if it is activity based and you can still get feedback and what are some of the differences in the, in the feedback. But the, we will come back to that cause what everybody was wondering then was that we wanna go small. How much do we, you know, how much does the, the art of slicing work then correlate to our ability to plan longer range or not? So that's a very good question. I've, I've tried to find, so that's something I'm trying to find in my book. I tried to find another example of, of where is something like that happening. And I'm basically giving, I think the metaphor of imagining putting yourself into the position of a navigator of a ship in the 18th century is a good one because, you know, So what is the situation? You know, you want to get, you know, over the Atlantic Ocean. You have no idea what the, what the ocean is going to be like. There's definitely going to be places you, you want to omit, have the stars to, to, to kind of more or less understand where you are. And you have a basic map. A very general map that you know later on people will will find was not very accurate, but was accurate enough. So you are in the situation and you are with your product. So what does it mean? Like you want to get, you know, to Cuba or something, right? So you know, this is your your goal for you as a product developer. It's or, or a person it's, it's, it's your product vision, right? So I know I want to get there. I want to build something that will help people get medical care without getting out of their house. All right, good. OK. That's, that's your vision. Great. Now you can't just, you know, break it up from there, the whole way from Cuba to Britain. It wouldn't make sense. It wouldn't make sense to think about what will you do 200 miles before you're there? It it doesn't make sense because you don't know. In the end, you will be, you will not, you know, take that route. So you need to know where you want to go. You need to have a general map, but then you need to have a process of deciding so where I where am I right now? What are my options? What is what are the 2-3 different ways that I want to go And you know, do this little step and then again, find where am I right now on the stars? What is the next step? What does the ocean look like to the north, to the southeast? And where do I go? And what is the wind like right now? And that is basically what I'm, what I'm arguing product development should be like. I should have a map and it's much more detailed when it comes to my options that I immediate. I should have a goal. Because if I don't know that I want to go to Cuba, I will end somewhere, right? I still need to know where I want to go and I need to have a process of the feedback loops. This is in the product development. The feedback loops is us looking at the stars and saying we are there. This is our position. People don't like what we offer them right now. They are not understanding this and that. So we need to move to this step. And so your question was how detailed should it be or how far ahead do we plant? We need to have a general direction that's very important, but the closer things are, the more detailed should we look into the possible options. So reassuringly, and I kind of did deviants to this, but I thought I'd I think what we're not saying is, and I'm not, and this is based on my own kind of previous mistakes here, is that by by slicing work in a different way, by focusing on have on the effort and the impact. What we're not saying is that we can kind of break things down to lovely kind of small pieces and plan things out into the future. Because they're small. We should be more predictable. We're saying it because because they're small, it doesn't affect our ability to predict the future right now, but it does affect our ability to change direction when the future surprises us. Because we haven't wasted time planning like miles in huge amounts of detail, miles and miles into the into the future. Because we know that in these environments where we're going to be surprised, we're going to be surprised and we're going to want to change that. There's huge, there's huge value in doing that. So even if we think back. I ask you the question, how do you know what is a, a small enough slice of work? Well, I would love to to kind of build it up a little. There is this, there's Daniel K Kaneman, this very famous professor of economics who I think died a couple of weeks ago with his book Thinking Fast and Slow, but but he's done much, much more than that. And he very clearly says in, in from his research, we do not learn things if the feedback is delayed for too long. And it's very important that you can you can connect easily with it. If you just try to learn how to play guitar and think that the sound that you're going to hear is just going to come an hour later, it's kind of obvious you're never going to learn the guitar this way. So the faster the feedback comes. So that's going to be the question like, right, So how small are the slices or how small do we, you know, make those parts need to be small enough so we get the feedback fast enough so we can learn. And that means the more unfamiliar you are with the territory, the more change there is, the smaller you need to slice. And typically, you know, it needs to be somehow, you know, doable. So I would say we're definitely talking about at least at most weeks. We're definitely not talking about months. I mean, if your if your organization hasn't been slicing and has been only delivering like every 10 years, maybe already go into one year already is is good enough. But I'm not sure any organization like that would still exist today because there's too much change. Can't have times of 10 years to test one idea that you have. No, maybe we'll find that in 10 years. Yeah, maybe someone has this tremendous. Foresight they've and they're just working on it in the in the stealth mode and it reminds me of the theories on time travel. I can't think what it was. There's some lovely little things about you know if it was time travel then and it was like lays it all out as to why. But yeah, anyway, that's a separate conversation now I think that when we think about breaking work down precisely work in whichever way. I mean one of the things which is really prevalent in many organizations is the desire to break it down on the activity. The house example, it is maybe not even as broad as say like all elements of plumbing. Maybe it is particular types of piping as done by one person in particular for joints and piping is done by another. The taps with these handles than by that person, but the taps with those handles one, there's a more twisted type handle best about that person, the person these persons do these plugs and these persons Suvi and that type of thing. Like really breaking it down to that. And my if a desire to then make things predictable and to manage it because it seems like, you know, we hate complex, complicated stuff. We always want to break it down the simplified so that we understand it. And then we break it down to a point and we look at all the pieces and if you this is a really efficient way to manage what we're doing here. This is really great. And if I keep things vertically sliced, sliced in such a way that we're focusing on the impact, that makes it a bit messy. I can't figure out who's doing what. I prefer to have it broken down by the activity. That's really, it's a really efficient way. I can plan it or I know it's going to change and I'm fine with it changing because I'm an experienced project manager. I can deal with that given that scenario. And what would you say to that person who's explaining their world in that way, who is perhaps willing to have their mind change? A little bit. Well, that's, that's a good one. It's not an easy I, I guess, but most of agile people hearing us will have been in this situation. I'll, I'll be honest, I think if the person is just doing it for the very first time and they hope that they, and, and they have been successful in, in doing this before, I don't think I will be able to, to, to, to, to say anything to convince them otherwise. But the good thing is the reality is, is different. So typically when you are, when you're doing what you just described, you are, you're focusing on, on needs for controlling, for increasing efficiency. And the more you do that, the less flexible you are. So what I would do is when in a conversation with such a person, I would ask for impact. I would try to figure out and to ask questions, just coaching questions about the impact that the actual, you know, what is it that you want to achieve with whatever with with your product and so far. And have you, you know, have you done projects like that before? And tell me about when did you find out that you were able to achieve what you set out to do and did everything work out or what worked well, what didn't work well and typically in in a run of such a conversation? What people realize is that the things that worked out were things that they ended up testing quite early on. The things that did not work out were things that they could have found out that they don't work out much, much earlier. And when, when I'm in a, you know, in a trustful conversation like that and the person starts understanding that, then they kind of open up to the value of having slices, the value of going step by step, the value of getting feedback. But, you know, I, I always like to also have an understanding for the people that, that I think I may be wrong in a particular situation. And my understanding is that I go to a hairdresser and I tell them, well, I'd like to have this haircut and they tell me, oh, but this is, this is a risky thing, my friend. I'm sorry. I will, I will just have an, an hour to go at it. You'll have to pay me this amount of, you know, 100 bucks and then we'll, we'll have a look what your head looks like. Like if I hear this from my headrest, I was like, Oh no, my friend, that's I'm going to the other guy. I don't think that's the way it works. So I think it's fair to for people to not immediately jump on this. Let's let's be iterative. Let's, let's try it out and get feedback wagon. That's, that's, that's also fine. We have a lot of space in our lives where this is completely adequate to not do that. Yeah. And it's, that's the thing, isn't it? So there's what you're saying here with the slicing work in the way that you're espousing is that you need an environment which will support that. And there are maybe things you can do to influence or to help guide or fill some knowledge gap that people have. But if you haven't got the right environment and if people aren't motivated to do this, then this as compelling as slicing the work in the way that you you talk about. And which I also kind of agree to. It isn't going to make that change happen if people aren't motivated to do it. And or if the environment isn't there to support those changes, as compelling as it may seem to the to to us to people providing this option for a different way. Yeah, absolutely. And, and the question for us is like, and us, I mean now agile coaches, I guess, right. So that's not only trainers. So when we come in touch with people like that, the question for me as as an expert is what do I help my coachee with? Where do I ask them to put their attention to? Because when you are dealing with unpredictable projects or unpredictable matters using techniques like you just mentioned, like trying to figure out exactly what activity is going to be done by whom and, and focusing on specialities. When you do that, you will have a mess in front of you. You will have so many different topics. You will have so many different questions like, but who's responsible for this and that? But when do we deliver? But who will schedule this? But who coordinates that? And, and those questions are typically like a lot of these questions I'm facing when I'm dealing with an organization And it's for me. And that's maybe if people can take this out of this conversation of ours, that'd be great. Like if you are, if, if you are as a coach helping people or or as a product person helping people to focus on what matters the the final result that we're going to deliver that we then look, is it actually having impact, the impact? On the behavior that we wanted, this is what matters. If you try to answer all of this other process questions without the context of one particular result, concrete result, you will end up in an ideological discussion, right? So how should this team of handyman that are working on this house generally organize their work? I don't know. But when it comes to this one particular room that they are renovating right now, the plumber should just help the wiring guy because there's not no plumbing to do in this room, right? The answer becomes very clear once it is asked for the context of one particular result. And, and that is something I believe we, we need to do as coaches because the, the only resource that we have, the limited one is our attention. And at least for me, when I was in my startup times, I didn't know really what to pay attention to if I had someone with me who would just guide me. OK, very important questions, but let's take this one. And from there we'll move on to the next step. And that's, that's actually all I want to do with if you, if you've read the book and you understand how to pay attention to the one thing that it actually matters, you will create a great organizational structure coming out of that, you will have motivated people, you will have results, you will it will impact your bottom line. It will do everything and that's kind of thing. Well, there was a, I think there was a, there is, there are many great little quotes in your book. I really liked, and I was just scanning through it and there was a, I came across this one which I really loved, which you were saying, optimizing for efficiency minimizes the effort and resources needed to achieve a fixed goal, whereas optimizing for effectiveness maximizes the impact achieved with a fixed amount of resources. And I think that's such a lovely, eloquent way of putting it because, you know, for what we're talking about here is we're going for efficiency. Maybe we are doing that task breakdown. Yeah, we're going for it to be as efficient as possible, but there's no guarantee. Then we're actually, yeah, we're managing the effort rather than the impact. And what we're saying is if we can find ways to focus on the thing that's value, then we can kind of manage for the the impact yet rather than the effort. And your book is full of those lovely little snippets and the great, yeah, your great key takeaways at the end of each chapter as well are really, really useful and I think really summarized the sentiment really well. Thank you. I'm not sure how much time we have, but if we have, I would love to go into this efficiency effectiveness thing because it was a bigger hammerman for me very early on in my agile life. Because before, before going in there, I've done an MBA study. So they basically it's some business thing. And, and I think it was one of the first some, well, it was a particular anyway, it doesn't matter that much. What I want to say is one of the first days they told us this very basic thing that there are two economical principles. There is one principle that is the maximum principle, the minimal principle. The maximal principle is achieve the most impact with given resources, right the maximize the impact with given resources or the minimal principle is achieve a given impact with a minimal resource. There's a two things, right, two general things, both economical principles, both make sense. But then when you talk and you think about what's going on in organizations, it's almost always the minimal principles. We're almost always trying to achieve a fixed impact with the minimal amount of resources. There was and, and when I understood what, what, what, what scram or agility, I actually teaching people is actually, oh, so this is basically how to professionally do the maximal principle. It's just that we're not taught that that's just a whole part of all of the business studies that that is just almost always left out. But I would, instead of calling it agile, I would call it, well, how to follow the minimal principle and how to follow the maximum principle. Two very important. You know, it's very fundamental things. And that's what we do, to be honest, that's, that's actually what we do in product development or, or in, in other parts where it's where things are unpredictable. We're teaching people to follow the maximum economical principle and, and, and we're doing it because we found out that the other things don't work are painful and, and just that delivering the results. See, what would you say to people that are listening who are in organizations, in environments, this all sounds marvelous. They just can't see how it's going to work because they're arranged for efficiency. I know we did touch on this before, but I wonder organizations where people may be saying things like this all sounds marvelous. And I understand why we should be doing it, but it is, I think, to your point, yeah, more of a philosophical debate for me because, yeah, when my managers, when the. The leadership of my organization considers something like this. They see, they do see it as a loss of control almost. And they're not rewarded on actually having an impact because their function, their department, their silo, whatever we want to call it, is optimized for getting the results of their thing. And the most we can hope to get feedback on is does the thing that I've made kind of maybe fit together the thing that that next team are making? But then when it gets to the 6th team in the chain, you know, we, we, we never know whether or not that. But let's take a classic example. That piece of data that we brought in is actually used or involved in anything to do with the user or customer using. I just do with data side. Is there anything over and above some of the tips and the coaching questions you were mentioning earlier which you can pass on to those people to give them some, some hope? Maybe I want to 1st admit to that, that if you find yourself in such an environment and you and, and it's overwhelming, maybe you can't do anything in this environment. So there is also a chance that you are just not able to make an impact in an environment that is set up to not make. Fact, if you want to try to do that, let's assume you take on this perspective on the product that you are working on and you actually realize, oh, what I'm doing is contributing to this, is contributing to this, is contributing to this. And in the end, if we are all successful, we will know whether customers behave differently with this feature. Like, let's assume you were able to take. This point of view, one thing that I want to tell you is be sure on on the top of the chain and maybe not on the very top, not just the CEO, but but below him. There are people who actually worry exactly about that. If you talk about this, there is going to be people who will be listening and those people who will be listening are going to have power because otherwise they wouldn't be in those positions. You are working. If you are hired by a large organization, you getting salary with so many other people, there is money coming from somewhere and so there is someone who is worrying about that. So be sure your opinion is valuable to someone even maybe it is not, even though it may not be valuable to the people in your immediate environment. And then the second thing is the question that I would ask to other people in my environment or even to my superiors. If I, if I realize I can't change something is, is always well, whom, whom will it benefit or how? Who should know about it if it fails, or who will celebrate something if we are successful? Like if you ask these questions to your superiors, that will typically help them realize who else is involved. And what the bigger thing it is that they're contributing to and, and it let it. And if if we assume that they are not just thinking about the power and political, political powers, but they're actually also interested in the in the success of the product. With this question, you may open up a conversation, a fruitful productive conversation, if it works. So. So this is at least my experience. And and again, if you're, you know, if there's five chains of command between you and the people who actually care who that's going to be hard. Yeah, no, they've been there. Well, I've been there. Yeah, most definitely. And I know people at listing have been there and are there right now. And so your tips, if I summarise them, tip number one was basically follow the money. See, like ultimately I remember, I think you might be my friend Saloni said that to me years ago. I can't remember. But I mean, what we're saying is like, find out, you know, they follow the money, find out who is ultimately responsible, who's made the promise and then they make the promise and it gets then I scattered through the organization. Vaders don't have their promises being met. You know, I think what's interesting is some of us thinking about over the weekends and and before that, I'm looking on head for a while, which is there all the time that people are asking for, Is your bit done? Does it fit into the plan? Are we on target? That's just proxies for are we going to be successful? But until we can actually start talking about this is how we are going to be successful, we're always going to want the proxies. That's a great way of putting it. Yeah. This proxy measures it is the best we can do. So I'd love, I'd love the idea, you know, getting to that, you know, finding out, you know, who is going to, to your point now, who's going to complain? Who's going to celebrate, you know, the successes and the failures and thinking more systemically, understand it all comes together. And do you know what is sad? But if people can't see that, people can't see that you can't motivate somebody to believe in something if if there's nothing going to change in the environment and they're going to be rewarded for doing what they're doing anyway. Is this a harsh, harsh fact? So yeah, thank you for those. And it did make me think, you know, about relative impact of the work that we do. We were talking about bullshit. One person's bullshit is another personal solution before we started recording. And I think it's about impact as well, isn't it? Sometimes we want to have the impact because it's working for us. We have an impact. Doing it one way doesn't mean it's going to work in another function or another part of the organization. But when we're thinking about the situations and say we put ourselves in this great context where things are looking like they're going to change and we have managed to motivate some people and things are beginning to shift, but how do we deal with resistance to feedback? You know, yeah, sure, we're giving out some lovely kind of day decisive things a different way. We can start to see people are turning on to it and we're getting, you know, feedback is coming, but all kinds of feedback from different angles that we maybe weren't expecting. How can we deal with some of that to interface in your book some of that emotional resistance to feedback? So, so there is, you know, two parts of, of feedback, right? So there is a feedback receiver and feedback feedback giver. Like if, if we put it simplify it this way. So the resistance of feedback receiver is very often shown showing itself by not asking for it or not really asking for it, right. So for example you are a team and you are having a product a a a Sprint review or a review of your product. Only internally, like without anyone ever or, or it's a demo like where you, you, you show a nice PowerPoint, right? You're not giving it to the hands of anyone to actually try it out. So there it is actually like if, if, if you are the person who understands this, who has the systemic view and understands the need for the feedback, you need to make sure that valuable people who people who have to provide, who have a valuable perspective. That's not valuable people, people with a, with a valuable perspective are present and get the results in their hands. However, what I find in, in at least in my practice, what, what I find is the second hardest part is actually, and I'm not sure whether it's a cultural thing,'cause I, I almost only work with, with German organizations is we have a lot of fake harmony. We have a lot of fake harmony. And and that shows itself that, you know, real criticism is rarely is rarely spoken and in the most effective tool I know to teach the value of feedback and, and understanding it is, is ritual descent from Dave Snowden. It's it's it's this format where you basically show or let people try whatever you've created. And then you either turn around and put a mask on so that they cannot see your face. You cannot know anything what what is happening to you and you just overhearing their. Conversation about your product, but not just the conversation not while they just talk about it. You give them the actual task to destroy it. They, they have to find all the arguments that they can to destroy, to completely take it, you know, waste it to take it to waste. So, and, and, and by you listening to this conversation for 6-7 minutes, typically what will happen, you will get a lot of ideas. You will hear things that you wouldn't have heard otherwise. And after that, and that's the most important part to me. After that, you need to reflect with them. Like, So what does, what just changed by us turning around and giving you this task and what, what has surfaced? Because the first time you do it with anyone, is it it there is a lot of resistance like people, especially if we're a fake harmony. Like what you're asking me to destroy something that's completely counter to what I wanted, right? I would never have destroyed the idea of my boss. I would have never done that. That is really dangerous. But then reflecting on it and saying, well, realize what just happened, What just happened with the person who was who turned themselves around? What? What thoughts and ideas did they have? What happened with the group? What did you surface? How else would we have gotten this information? How hard would it be to to do this? And then and because it's ritual and when, when people understand that this is a ritual, when people understand it's, it's a little bit of a game, it, they get comfortable with it. And in my experience, once people get comfortable with it and they have one place to do this, it enters all also other conversations. People realize, Oh yeah, right. We've been a little bit too harmonic with each other. So this is kind of, this is, this is one of the best tools that I know to, to give to an organization to teach them the value of feedback and, and to overcome this emotional resistance. It's, it's like, similar to like Troika consulting, isn't it? Liberating structure. It is different cause Troika is just, I, I, I, I'm not sure whether people know it or not. Like you also turn around and you also don't, don't, don't hear them. But it is it it it has a lot of similar advantages. But the thing of destroy the idea it's making it because the trucker consulting people actually very, very most of the time very constructive right then they're trying to destroy. But but here the this invitation to be negative, to give negative feedback, is essential. Yeah, yeah. And then when Dave Snowden taught me rich lies to send, he was talking about wearing a mask. Yeah, but well, yeah, I sometimes have a mask. Candy. Yeah. It it works 80% with people just turning around and, and when you're online, you can just turn off your video and and, and mic and it works like a charm. People, people forget that you are existing within 1/2 a minute and you, yeah, you think you make it an impact on someone's life and it turns out you just turn your camera off and you don't exist. Yeah, no, I love that. Thank you very much for sharing. It's a great, yeah, great, great suggestion. And now, Anton, we are getting towards time, which is sad 'cause I still feel as a lot we could talk about. But what we need to do, my friend, is meet up at a conference at some point somewhere 'cause it be great. Great to see you in person again after all these years. That's not just wrap up just yet. What is the most challenging concept do you think that people are going to take away from your book? The most challenging? Yeah. What what is it in your book you think is going to be the like, if you had a pace of bet, say, like people gonna find this the hardest thing to really get their head around. Like what? What is it? Quality. I think, to be honest, I find that this is a hidden thing. We we almost never talk about it, but it's it's the hardest part. And I'm I'm you know, I'm talking about it. I'm making it explicit. But this is this is hard when you used to build a build a results in a year or three months and suddenly you try to build a result in two weeks. The hardest part is to get the same quality level as you used to. And it is not about changing management. It's not about changing how things are called. It's actually about changing the actual practice of work. It's about taking a long list that you used to do quality assurance and reducing it to something that is doable. It is about automating processes. It's about creating templates in Excel that help you do stuff like like doing the little things that are needed. To deliver the same or almost the same quality within a short amount of time. That's in my experience, the, the actual challenging part, That's that's where I see kind of most resistance in the adoption of, of these practices. Well, because people don't think that they will be able to get to sufficient quality in the time frame. Well, most of the people just don't think that, don't understand that this is it. Because most of the time when, when people get an agile training, it's all about roles and events and, and all the big meta stuff. And, and then the people who understand that, that they are managing the process, but it is the, the, the change that needs to happen is actually on the level of what the work with the work that that we're doing. And, and that's why it was important to kind of to also edit and to, to be explicit about it. Guys. There is something about our work that is going to change. That is the matter of, you know, how we actually do it. It it has implications on your every day, every hour of your work. Yeah, just getting flashbacks to a long time ago. Uh huh. When when we were really fortunate, we were trained by specification, by examples. We had a team who were really willing to do whatever. They wanted to do whatever they could do to get to get something out frequently to the highest quality we could do. It was massively flawed. There was no way we could do like everything we would have loved to have done. But it was, yeah, by far and away superior to what the the alternative was. It's because we had people who were willing to invest in making sure that we had ways of verifying what we were producing. And that's what made a huge difference. It was because we had people who found their ways to let their roles blur, to have fuzziness in between things. And there's enough fuzziness, they were able to achieve some really interesting stuff because it wasn't about and it's your turn to run the button now. And you were sometimes you weren't quite sure who had the button. But one thing we all knew is they were all heading towards in the finishing line and that was what was important. Anton, thank you so much for this. I've, I've loved it. It's been great to hear you talk. I've made so many notes and so many questions I just didn't go around to asking. And maybe those listening now have also got questions or ideas and things they would like to challenge perhaps. So what I would say is if you do have questions or you do have challenges, then Anton, I hope it's OK if I say to be able to get onto LinkedIn, perhaps sure. And make those known like, you know, tag, tag Anton, tag myself, tag the podcast, put your questions out there. And that way if you tag us all, but we'll find it and we'll let people, we'll let each other know if we miss it and we'll make sure that we get some answers because this is a great topic and one which I think they deserves a a lot of renewed focus. I think as Agile struggles with its identity somewhat, and this is a concept, this is a mindset which kind of strikes back to what Agile was and should have remained to be, rather than perhaps the perception of has become. And I think this is something which kind of works fantastically well. Where every work in digital, physical or other kind of product development, there's a lot, there's a lot of fantastic stuff to take away. So Andrew, if people did want to contact you directly or if they wanted to just connect with you, is LinkedIn a good place for them to do that? Yeah, I think LinkedIn, especially in the post is great because then if you have a question, expect 1000 other people to have the same question. But if you are the one to actually ask it that, that'd be a great place. And then we can have a public discussion and then people can learn. So not so information is actually spread. That's much of A modern way to learn than just an e-mail. I know it's great, isn't it? So please everyone get on LinkedIn and do do tag us, do ask the question. Oh, if you fancy trying something a bit different, What you can do now is sounds weird saying it, but we can now accept fan mail via SMS. So on the podcast and platforms, on Spotify and iTunes, there's a link that says send fan mail at text message to show. And you can actually click on that link, open a messaging app, and for the cost of a standard text message, you can text in and I will get the questions. So if you fancy giving that a go, feel free to text something in and then I'll turn that into a post or I'll let Anton know and we'll pick up the conversation from there. So please do feel free to text us any comments or questions you have or just some feedback for the show. We'd love to hear from you because we don't do this for ourselves. We do this for you. Anton, thank you so much for taking this time. I know we had a couple of false starts on this because of a number of life events on my side here and there, but it's been brilliant to actually take this opportunity. So yes, thank you very much. Thank you, Ben, it was very much fun. Good. Good. And everyone, thank you very much for listening. Do make sure you follow us on your podcast platform of choice because we'll be back again next week with another guest who knows who that will be because I tend just to record these and then decide the order later because I'm not a priority. You never know what's going to happen, man. So this episode will be out and there'll be another episode after it. And I think also there'll probably be an episode before it. Anyway, thank you, everyone. Thank you again. Anton, this is a Protest Jersey podcast and I'm your host there. May not see you again soon.