fbpx

Team Genius at Scale – An Interview with Ben Maynard, LeSS Coach & Trainer.

Team Genius Audio · Team Genius At Scale With Ben Maynard – Team Genius Audio TGA008

Summary

Guiding a huge multinational financial company from complicated IT projects implementing technical systems to becoming a customer value orientated using a clear product portfolio is no easy feat.

In this special episode we get to learn from special guest Ben Maynard who’s done it multiple times.

A vast array of programmes and projects, with long timelines and unclear benefits realisation also bring vast sources of tension across the organisation and customer satisfaction issues to boot.

Simply “installing” a scaling framework brings its own challenges and can obfuscate underlying systemic issues.

In this rich conversation we go deep into the subject and pull out key points from Ben’s extensive first hand experience, working across the levels of the organisations.

We cover what is required for making this successful, the impact of key staff changes, common key challenges, and some key strategies we can leverage in larger organisations with similar ambitions.

Please enjoy this special episode and share your thoughts in the comments. You can find the video, audio, and full transcript.

Full Transcript

Georg – “Hello, hello, hello. Welcome, welcome, welcome. This is a special edition with Ben Maynard who has incredible, incredible experience working across very, very large product development efforts. And today we’re gonna have him here to talk all about how we are going to make sure that the teams that are involved in these large scale efforts truly are able to unlock the birthright of becoming a dream team coming right up after this. Okay, so we are about to bring Ben on, I wanted to share a little bit about how I met Ben. It was in 2014 at a scrum coaching retreat, and since then we just hit it off. I’m very grateful that I got to do a little bit of work with him, but over the years we’ve become friends and I’ve always been impressed with how much experience he has with incredibly large product development efforts. And I am very grateful that we get to have him on here. He will share a few words very shortly with all of us about his background. So you really know the vast spectrum of experience that we have available here to us. And so we’re gonna bring him on, in just a minute. Let’s switch over and here he is. Hello Ben, how’s it going?

Ben – Hello Georg, very good. And thank you very much for having me.

Georg – You are welcome. 

Ben – I feel like a pop star or something. That’s quite a lot.

Ben – Yeah, you are overwhelmingly humble and modest about your experience. So I need to do it for you. So people actually get the impression of how big the stuff is that you can draw from. Would it be okay if you just shared a little bit about your background? So people get an appreciation of who you are. Maybe some of them haven’t heard from you yet.

Ben – Yeah, cool thing. Thank you very much, Georg. So I’m Ben Maynard. As Georg said it was lovely warm introduction there. And he’s right. I suppose I am humble, I don’t know. I find it difficult to wrap my head around, I suppose, the last decade that I’ve been spending working in product development, product delivery. I started things off as a business analyst many, many years ago, and then happened to cross scrum. And ever since I came across scrum, I’ve been working as a I was a scrum master, sometimes as an agile coach, sometimes as a fake product owner, sometimes as a director, as a senior person in an organization very far away from reality which wasn’t something I was particularly comfortable with, but all through years I’ve worked with one team. What I call singular teams, I’ve worked with multiple teams, but I think one of the defining characteristics has been that, wherever I’ve worked, we may have been 500 people, we may have been a thousand people, but we’ve been an organization of tens of thousands of people. And in many of the large organizations I’ve worked in there’s been rifle dependencies. So it’s been an extraordinarily difficult challenge to enable things like feature teams and to really help teams achieve their full potential in these larger organizations all of the baggage that comes with them, and what I’m looking to do today is share some of my successes, some of my failures and some of my learnings. And hopefully I have George throw a couple of awkward questions about me.

Georg – Sounds like my cue. Very good. Excellent. So maybe you could also share a little bit more about the industries that you’ve been working on or rather focusing on.

Ben – Yeah, sure. I’ve always worked in large financial organizations, would say always, up until recently. So I started my career back at JP Morgan where I could cut my teeth as a business analyst, At JP Morgan I was working on kind of back office solutions within the custody area. And I wouldn’t say that was large scale development, but it was very traditional style BA work which did not sit well with me at all. I was really uncomfortable. It made me really anxious being a business analyst I know Georg it’s something that we’ve spoken about in the past as being-

Georg – A lot.

Ben – Getting over that kind of perfection, this type thing, because then you realize when you’re supposed to write a requirements document it’s never going to be perfect. And it can’t be perfect. I would argue but they’re not supposed to be, so, working in that mode stressed me out. I remember being really quite unhappy. So when I was given the opportunity, and I joined the Royal Bank of Scotland, to actually join a cross-functional team and then do things other than analysis and to get involved in a lot of the database design and implementation, to be involved in sort of the testing and some of the kind of the project management as it was, it was great. We worked in increment versus iterations. I wouldn’t say we’re that incremental, but we learned a lot about what it was to work as part of a team. And the people that I met in that team, they are some of my best friends to this day. They really built amazingly strong relationships with a few people and they stood the test of time. So I’m incredibly grateful for that experience. And that was working on effectively like a reporting engine like a massive database basically. And there were about 100-150 people working in that, but I was just a cog, a cog in the machine at that point. When I was given the opportunity to run the delivery which would decommission that platform that we’d spent two years building, I kind of jumped it. And that’s when I decided to start experimenting with scrum. And we did one team and it was working very well. We proved some things which people didn’t think were possible. And there’s vendor platform. We moved from one team to two teams to three teams and in actual fact Georg, slight correction. We first met on a certified scrum product owner course.

Georg – You’re right. That was before. Yes. We go back even to 20, was it 2013 or earlier on 2014?

Ben – We were most dissatisfied with the person delivering the training.

Georg – We shall not name names. You know who you are. I joke. 

Ben – It was on the second day of that training when I got the phone call to say the business line was canceled. Everything we had done, those three teams we built up, the waiver we are working and we just began to really experiment with less large-scale scrum, not knowingly. I’ve been recommended this book. I started reading it. Thinking oh my God, like everything they’ve experimented were all of the problems that we’re having. And so we started running some of the same experiments and things were getting better and we were really enjoying it. And then they canceled the business line. So I was there as a fake product owner, learning about product ownership. When I got the phone call saying, yeah, when you come back to the office, you haven’t actually got a job particularly. But what was fantastic is that we take much credit. We’ve done so much good stuff and people really liked what we were doing, that whilst two of the teams the people were dispersed around the organization. 

They kind of kept the core nucleus of the team together and saw what we were able to work without an official business line knowing that there was another thing coming on the horizon. The team did a fantastic job, dropped down to one week sprints, formed massively well as a team. And it was one of those situations I’ve seen numerous times since where it was a good collection of expertise and experience. And with that came a lot of over increasing amounts of humility and appreciating that actually we are dependent upon each other and then that we were going on a learning journey together and they built these beautiful relationships. So when the opportunity came to then start again and we really wanted to start it properly. So we flew people over from India. We got heads of business together. We spent a week doing a traditional kind of full on planning thing. We brought up this roadmap, we had what would certainly be a confidence that we could get the platform out there in production within the timeframe they wanted. But with only 2% of the clients they wanted.

Georg – Wow.

Ben – We knew no one could do it a hundred percent. We didn’t see any way. We are pretty confident we can get it out. And we’ll support basically these five clients who have got really simple needs. But once it’s out there, then we can do some interesting stuff. And then all the stuff which the vendor hasn’t finished maybe will be finished by then. And they said that’s great. Never gonna happen. What if we gave you 50 people?

Georg – Yeah.

Ben – I would say, well, it still won’t work, right? This is the right plan. So then they pulled more people and put more people in. And it was my first large-scale scrum adoption, it’s what I wrote my LeSS case study about, to become a LeSS trainer. But it was one of the hardest, most educational and I have no repeatable times in my career because it was really hard, but we learned a lot from them. But for me, what I really enjoyed doing after that, actually, is why I met a particularly very, very good friend of mine out in Jersey because I ended up being poached from my area I was working in RBS and started in internal consultancy. I’m talking to loads of people who want to learn about agile. Let me send you around the world, talking to people. It was lovely. I was able to travel the world delivering various different agile training, doing coaching, mentoring, spent quite a bit of time out in Jersey where I met my friend, Nadia, which was great. And I’m still great friends with her now. Probably one of the best scrum masters that I’ve worked with. And she does have some great stories, but it’s always been the challenge of working in these larger organizations. 

It’s almost as if you are this tiny… there’s always so much external pressure, you’re one part of the small system, and it’s difficult to feel like you’re successful, I think, which is where some of my lack of perhaps willingness to talk about it and go in depth because I don’t honestly feel at times that it’s a success I want to shout about. Yeah. I learned a lot, and yeah I think it positively affected many people’s lives but it also made lots of people uncomfortable and made things really hard for people. So it’s a difficult balance to strike. I’ve always found. I try not to delude myself, I’m not at the pied Piper of happiness because change is hard and large change is even harder.

Georg – Of course, of course. Yeah. So this sounds like we’re already getting into some areas where you could give some tips of things that people should bear in mind who find themselves in similar situations. 

Before we do that, I wanted to say hello again to everyone who was watching live. Thank you very much for joining us today. And also thank you so much for the likes. If you do have a comments field that you see there to drop a note, let us know where you’re watching us from. And if you have any questions pop them in the comments as well. We are here not only to have our conversation, but also to pull in what you’re curious about. So please let us know where you’re joining us from. If you like, what you’re hearing, give us those likes. And if you’ve got any questions please put them in the comments also. 

One thing you said just before you talked about the move onto RBS was that even though you got that horrible phone call when he said, actually when you come back tomorrow, the work is gone. They actually left you together as a team. So that surprised me. I probably heard about that story before, but I forgot it, but it’s so incredibly rare that organizations do that, right? It’s one of the things that we advocate to have long lasting teams because it’s a great investment and dispersing teams and reassembling is actually throwing a lot of that investment out of the window. So, that’s a really good thing that they did. 

Ben – I think we were as surprised as anybody else, They stayed together as a team, they picked up another piece of work and the interesting thing was, though they had picked up another piece of work in addition to – well what we had said was that we would have ended the platform, it was a bit rubbish. What we really wanted to do was to kind of get to a point where we could do one-click deploys to production and it was just like trying to carve a statue out of jelly. It was so hard because it wasn’t designed to do that. So we had a couple of really, really bright, experienced fantastic people who helped us along. 

So what happened was the team was working towards that one-click deploy, which we never achieved, but we made strides in that direction but we also picked up another piece of work related. And what they did when they picked up another piece of work was that they were employing everything that we had been doing and they had taken a lot of the different techniques. And even the senior people that were involved in it, we’re trying to use some of the stuff that we had proven could be beneficial. And it was lovely to see, but I think this is kind of a challenge, it’s very easy for a single team to be really successful. And it’s even easier when that single team has very few dependencies. And I think it’s one of the common mistakes I always see organizations make and feel free to interrupt me and take this off in a different direction. And if you don’t want me to say all of that-

Georg – No. This is what we want to learn about, right? So that as people who are joining us might be product owners, might be change agents, might be coaches. Those are the things that we might’ve seen. But if there is reassurance because it’s not only what they see but also what someone like you has seen that is a wonderful thing. So what is that challenge?

Ben – So what do you name things? When you start something, do you call it a pilot? You call it a pilot building as a one-off, pilots don’t scale, pilots are pilots, generally speaking, very, very few come across situations, we had this recent successful pilot and now the whole organization works in that way. Because oftentimes they pick a delivery which has very few dependencies where they’re able to build relationships closely with the customer and it works really well in isolation. And then these pilots are really successful because of the hard work people put in, but also because of the nature of them, they haven’t got many dependencies. When I go into organizations and you say I’ve had a recent really successful pilot and you look at it and you realize actually they had so few dependencies elsewhere, they were able to create their own little system and deliver it which is fantastic, but it doesn’t prove much from a scaling perspective, and people call them pilots, people call them experiments. I mean, think of all these different labels to call these initiatives. 

And they’re all flawed in my experience. I’m yet to find a label which works well, but at RBS, we obviously had Deutsche bank, we said we won’t use pilot. So let’s say chapter, like a chapter in a book, this is the first chapter and we’ll move on and do subsequent chapters. But we didn’t put enough effort in to make a shared understanding of what we meant by chapter. So it got bent and skewed and became other and different things. So I think it’s really difficult if you’re looking to kind of do like a parallel organization. So for example, what it recommends in LeSS is that if you’re in a situation where you are in a big organization you do have a deeper narrow slice and you get say 50 or so people or 50 or less – fewer, and you start there, you master it, and then you can grow it from there, but what you label that as, what would you call that deep narrow slice because people want to label it with something and it’s hard to deal which is why I think there’s a lot of merit in saying don’t bother doing a lot of that to begin with, just find some good stuff that’s happening and just amplify it.

Georg – So why wouldn’t you just label it based on what that customer value is that these 50 people or so are looking to realize might be a feature set name, or a service name or a product name?

Ben – Yeah, because the challenge then that you get with that is then they say, well, okay, so when this delivery ends then what happens to that group? You can talk about normally as teams but let’s say it’s delivery X where delivery X is coming to an end. Do you feed more work into that? Or do you take the learnings from that and spread it out? How do you manage that? And I’m surprised. I’m surprised that throughout the years I’ve seen so much of an issue with this in many different situations. And I’ve been arguably better at finding a suitable label. And it shouldn’t really matter in all honesty, but there is something that it does to people’s minds and you want to create a shared understanding of what you’re trying to achieve. So absolutely, name after the feature set, but then I find that people would then say, so what next? What have we done here? Is this a parallel organization? And will it only ever be about delivery? Or do we add in more, how does that work from a product backlog perspective then I’ll be saying, but if it’s delivery X, Y, Z but that’s going on somewhere else. And the rest of it, it’s an interesting and probably maybe trivial challenge. I’d love to hear other people’s opinions on it.

Georg – If we only look at it from the product development side, it’s probably a little bit simpler, but what I’m also hearing is that there is something about the group identity of the set of teams, right? So if they actually have an identity of their own and they are called the white dragons, whatever, for example, and this group of 50 people or so, they’re all separated in cross-functional teams and they are the whites dragons. So if we start to entertain the idea that it’s this group of people that we’re gonna keep together and then it is more a question of, well, then it’s easier for us to see whether we’re also shifting the way that we are handling work, right? Because traditionally you pick up people from across the organization and then put them on a piece of work, and we’re trying to turn it on its head, right? Where we’re keeping the people together and bringing work to the teams also in a scale environment. Right?

Ben – Yeah. It’s a great point and it’s helped me kind of think through it a little bit more because if whatever you label an area it has to kind of make sense in the broader system you’re working in. So, if your organization is built upon customer journeys or something and you name it after customer journey, and then the new era isn’t actually working on customer journey it’s working on something else, because if you decide to take a different view of it then you can’t name it off the customer journey. So, you want to call them something else. So if, say for example you would just relabeled the whole organization as different color trackings. Then I could see that probably would be better because it doesn’t really differentiate, they are all in it together. It’s an interesting challenge particularly from a large-scale scrum perspective, because it says if it is special work, if there’s extra work to be done it isn’t a special team that does that. It’s the feature teams that do that work. And yet we say do a deeper narrow slice of 50 people and who have not mastered this new way of working. And we’re effectively saying here’s some special work for some special people to do to the rest of your organization. 

So, when I go into a client and they say, can you just kind of give us some advice and recommendations I’d spend as much time as I can do, talking to as many people as I can finding out all the good stuff that’s happening and all the problems that people think need to be fixed. And then my challenge is to bring those together into something that’s meaningful and they say we’ll do a pilot here. And I say, that’s great, but you need to feed everybody else. You can’t do one thing. You have to feed everyone else. You have to give them something. That has to be a path for people, I think it’s some of the challenges that you find, which is why it’s nice if you can just do change in a slower, more relaxed, evolutionary pace, where you just kind of get some good guiding principles, you have a clear organizational goal, and everyone just begins continuously improving towards that vision of perfection.

Georg – So, what have you seen works that puts organizations in a position where they want to do that and they’re committed to persevering with such an approach?

Ben – There has to be a motivating goal that everyone can get behind. And there has to be a high degree of alignment between the senior person, let say the CEO, CIO, whoever that may be, and the people that are reporting into them. And there has to be a high degree of alignment there. I would say to increase chances of success that’s when you take a look at the structure, because if you’re reporting to the CIO you’ve got your development organization and then a project management organization and a testing organization. And then you were saying, “Oh now teams get together and work, multi-skilled, ignore these organizational boundaries”, but then those managers want to know what’s happening with their people. And you see, you always have to kind of say at that leadership level if you can do that deep and narrow slice what I’ve seen work well is when you say take a slice through the leadership team as well and take one person from the leadership team to look after this slice. And then everyone reports up to that person. So then magically all the different infighting and all the different handovers begin to disintegrate because there’s no longer that organizational construct within that deep and narrow slice.

Georg – So, there’s this executive sponsorship?

Ben – Yeah it’s executive sponsorship and a high degree of alignment. I wouldn’t underestimate the price that teams pay for a lack of alignment at a leadership level.

Georg – Yeah. I’ve seen that regularly.

Ben – And it’s hard, but-

Georg – Yeah. It is hard, right? Because we were talking truly enterprise scale, right? Something that I always like to invite is a consideration of what are the types of behaviors that senior management would like to see in their own organization and then self observe? So, they look at how they are actually interacting and behaving inside the senior management team. And more often than not the structure of the organization is actually reflected in the behavior in the senior management team and for better or not so good. I think it’s because it’s interesting from a systems thinking perspective.

Ben – Right? It’s all about relating with the behaviors, or related behaviors within the system, if the leadership team are behaving in that way, then other people will be behaving in similar ways, if not the same way, just in different contexts. So you can always, I’m terrible for it, historically. Always chastising people for the way they behave and I would hold them to that. It’s just me, I’m basically annoyed at myself and there’s a lot to take on board there. A friend of mine modified me with something called behavior stories which he uses with leadership teams, to talk about what the behavior stories they need to tell themselves, how they want their behaviors to change and he’ll then coach the leadership team to stay true to those behavior stories which they have designed for themselves. But then it always comes back to saying, here’s the singular goal we’re going for.

Georg – Yeah. Alignment around the cohesive mutually agreed and developed goal.

Ben – Yeah. I mean, systems speaking – a system needs a goal or a purpose and critical process control, plan, do, check, act. Anything in lean all needs a vision for what you’re working towards and then pick one improvement framework which says “just use this framework and you’ll get what you need without defining what you need.” How do you continuously improve if they don’t know what they’re continuously improving for?

Georg – Yeah. What are you optimizing for?

Ben – Yeah.

Georg – That makes sense. Absolutely. So these sets of teams, let’s focus a little bit more on them. So as they started what is it that really helps those teams shine? What are some of the elements that you’ve seen work really well for that to happen at such a scale?

Ben – It was a pattern that we tried heavily in one of the places where I worked and the first time we did it, it was a resounding success. And basically we said, okay, well, we know we’re bringing together people from different technical skill sets, historically they were split between basically front-end and back-end. We got them together and we spent six weeks focusing on building them as a strong unit. Given the opportunity to, we did a ___ charter over a series of days. We did a market of skills as part of that kickoff, which was phenomenal. The market skills was probably one of the most enlightening and kind of bonding moments for them. It was wonderful. We had a great mixture of complementary skills. They were able to define their own clear purpose within the broader organizational purpose. They were just good people by and large, who we just gave space to. 

One thing we did say to the product owner, and we agreed, was that they were allowed a twenty-five percent learning budget. Say for the first three or four sprints they could put aside 25% of that time just to learn whatever they needed to learn. So they did loads of more programming and they spent loads of time pairing up. They learn about all the different parts of the system they’d never seen before and making that investment in them building their relationships and building a certain degree of trust. The scrum master did a great job of getting them involved in extracurricular activities like volleyball, for example or to get them to go out for a beer which helped hugely for that. And it really bonded them. And by the time we started the first sprint they were a pretty high-performing team. And even though it got bumpy for them later on and it was challenging. They were just a very strong team, they were extraordinarily resilient. And when I was scrum mastering them for a while, towards the end of my time with this organization, it was a joy in many respects because they reacted so well to having their behaviors reflected back at them or to becoming aware of something they weren’t aware of before, and they dealt with it very well. A lot of it is down to the effort we put in and what didn’t work so well is that it was okay when it was seen as a one off with them. But then all of a sudden when we say, boy, every new team that joins to work on this backlog should go through this kind of six week period of team forming it. Also of a sudden it didn’t become very palatable. And ironically, the area that could deliver the most, where there was the highest number of new starters who could have really done with that time to really bond and form a strong team and to kind of realize, yeah, to create some space and increase their capability. We’re never given the right opportunity to actually do that. That’s a shame. It set everyone back and it wasn’t something which I don’t think they ever reached the true potential as a result.

Georg – All right. Hey Thomas, thanks so much for dropping in and yeah. Thanks. Thanks for the comment. What was the difference between them agreeing to this six week multi event kickoff time for the first set of teams and then not wanting to do it for the second, when they probably have seen what the impact was of doing that in the first place?

Ben – If I was gonna be diplomatic I would say pragmatism. I would say that it didn’t seem like the practical thing to do. If I was being honest, I would say, but it was a lack of alignment on the goal and the lack of the desire to keep control of an empire and to shape it in a way that they thought was the right thing to do. I think it showed a lack of understanding of what we were trying to achieve. And I think that was one of the main issues. I’m obviously biased about this because I have my own opinion, but I do think that if we’d been highly aligned and if we’d been giving people adequate time and adequate support, and we’d have proven that it was beneficial and that was there. I think that the lack of alignment, the lack of kind of seeing people as equals “Oh that works with them because they are them, but it won’t work for anyone else because they are not them.” But then no one was ever given the opportunity to actually exercise that, so they never knew. There was a big focus on goals which were probably the best system optimization goals, but we need to have a hundred people in this timeframe. So, they were very much focused on hiring people and then under the promise that they would be effective very quickly, but it takes a long time for people to be effective. So I think they brought people in, they needed to get them delivering, you know, let’s just get them delivering, but it didn’t gel.

Ben – So, that’s yet already another key takeaway. Whether it’s one team or a multi team kickoffs are important and it’s not so much that the product gets kicked off it’s that the team gets kicked off in the right way. One of the things I’m yet to see, not work very well when done properly is as part of that kickoff doing an impact mapping session. When they are run well they are magical I would say, it’s a huge deal to get the teams really close to the users, to talk about everything from a user’s perspective, but what do you need to do differently to have a really clear, measurable outcome and understand that you don’t have to achieve it all, but how much of it do you have to achieve in order for you to then reassess and say, do you want continue investing in this. And impact mapping sessions when they run well are really, really effective as part of a team kickoff. And it’s also a great way to build your initial backlog.

Georg – Right. Absolutely true. Very good. So, for those of you watching this live thank you for sticking around. If you do have any questions please put them in the comments. We are very happy to take them on and we’re gonna keep our conversations for another 15, 30 minutes or so. And we’re gonna go on to a few more questions now. So the first one Ben would be, you spoke about starting with a deep and narrow slice of 50 people when adopting more large-scale scrum type patterns, but then you would gradually scale it up, right?

Ben – Yeah. That’s the idea. And the way I view it, is that it’s less huge. So large-scale scrum the less huge area where you had to actually have collections of their requirements, which are correlated heavily in some way. So they have the same user, they all are in the same part or maybe not part of the same platform but they uniform whole features when we see it from this perspective. The way I see it is that 50 people is almost a maximum you’d have in an area in LeSS, it’s huge. So, it’s just a case of saying, “great, so, we’re going first in this area and then let’s find another set of requirements for the second area and then the third area” and grow-

Georg – So it’s multiples of 50, roughly.

Ben – Year, 50 or less. I mean, what we’re saying in less is that an area backlog would have four to eight teams so you can do the maths on that. If you look at an eight person team, eight being the upper number because after eight, it gets hard, I’m looking for some controversy here. And I want people to educate me a little bit because I haven’t been able to fully get my head around it. But we had mentioned Dunbar’s number, which is so present.

Georg – I was just about to bring it in because you kept mentioning 50. So, I had Dunbar’s number pop up in my head and well I don’t know whether you’re going to get much controversy from me, but when you were thinking about Dunbar’s number, what were you about to say? Let’s see what we’re thinking about this.

Ben – Yeah. If I’m in one room of 150 people and that’s my social connections I don’t think I can leave that room, walk into another room and then magically get to know an additional 150. So, I think there’s a number of social connections. I can do 150. I can see that’s feasible, but then when I’m walking to the office there’s not magically another 150 people.

Georg – Yeah. So I’ve got to disappoint you and those viewers who were here hoping for more controversy. But I happen to agree with that. I think this number has been abused for those of you who are not familiar. The Dunbar number suggests that for a human being, there is a set number of relationships with other people that we can roughly keep in our mind and not necessarily all to the same strength or depth or level of connection, but overall the number of connections. And it’s been used in the business world as a goal for organizational sizing. And yeah, Ben, I fully agree. It does not make sense the way it’s been applied because as a human person, I can only retain a maximum of 150. And I’m not one of those people actually. So for my scale is a lot smaller I think with meaningful connections that I can keep. But yeah, as a human being, as you said, you made it more tangible by using the room analogy. For me, I don’t stop being Georg outside of work, when I get to go into the office and then I’m the work Georg and I have a new set of 150 people that I can have connections with. It just doesn’t work.

Ben – You switched your brains out. And what I find disappointing is there’s at least one framework and one book I can think of, where a large proportion of what it espouses is based upon Dunbar’s number. But now, I could have misinterpreted it. And I don’t know if Dunbar is still alive. I keep trying to reach out and maybe just ask the question, have I misunderstood this? Because I’m happy to be proven wrong, but we do think that we have this idea of, really, what we’re saying is like 64 people tops ish for an area. And even then I still that is still a lot of people, you’re asking a lot of teams to work together. And that’s given in LeSS where most teams are feature teams and we don’t have dependencies. So you don’t even worry about managing dependencies. You’re putting a lot of that down into the build servers and new tier code. So, even then that’s still a lot of people, people may kind of move away from getting 80 people in a room. It’s interesting, actually and this is something I wanted to bring up with you offline, but we’ll do it now. Because we have reasonably strong views about product backlog refinement.

Georg – Yeah, we do.

Ben – That we do represent product backlog refinement because as much of the act is soft product creation as the actual writing of the software, for example, and yet people shrivel up when you ask to get maybe two teams to do refinement together but will rent a marquee and get caters to do PI planning. What’s the difference between them? “You know, if it’s planning it’s okay.” So we will get everybody and plan, but it’s not okay to get two teams together to understand what they’re going to do.

Georg – Yeah. Funny that. What are your theories on what it might be?

Ben –  I think that people love planning. I think we still got a long way to go. We’re still trying to break our organizations and our work down into a mechanistic, manufacturing style analogy. I don’t think that by and large a lot of people have really understood the complexity of it and that we can’t reduce it down. I think of Dee hock, the guy that created Visa, his book “One for Many”, which is a fantastic book. He got this in, like, 1958 and did his best to create Visa in this mode to try and ignore what he would call the Newtonian reductionist view of the world, trying to understand the cause and effect. And you just can’t do it. And yeah, I think that’s what we still try and do. So I think when we talk about planning we’re happy to get together because “obviously” if you fail to plan, you plan to fail.

Georg – Right. So you’ve got to have some planning…. we’ve got a lot of planning and yeah. Make a good planning. You’ll be fine.

Ben – The only failure of planning is that we haven’t spent enough time on it apparently.

Georg – Yeah. So, then wouldn’t it become transparent during such a planning event, if it’s difficult, that they haven’t done the required pre-work which is usually accomplished in product backlog refinement?

Ben – Yeah, I mean it would make it even more difficult, but also I think that, and I’m not bashing PI planning or anything, I’ve only been in probably five or six large scale planning events. But what I’ve seen in most of them is they were time pressured. You’re expected to exit with a plan, and many people say, people don’t want to plan, if people want to plan it’s because they don’t trust us. Everyone knows when they’re going to get what they want to get. And if they wanted to have a breakdown on the plan they are going to trust us on that. So they want to see that we thought it through. So, you’re in this kind of time box situation where you spent a lot of money to get all these people together and there’s a high degree of pressure and you go through and you try to make a plan. And then I think of the last three or four PI plans I was involved in, nothing that came out there was actually done. I’m not saying that’s a failure of PI planning, it’s probably a deficit in the way that they approached it. And think systemically of how out of date it might be once everybody goes back to their own area.

Georg – Yeah.

Ben – And I don’t know how much work they’ve done beforehand to prep for it. I don’t know how much is required for people to do beforehand. I know there’s certainly lots of conversations happening in the moment, but a lot of that was that the teams were involved within. They weren’t structured as feature teams because if you are a feature team, by a strict definition, you have zero dependencies.

Georg – Right. On the strict definition. Yeah, yeah. That brings up the image in my mind of although as you know, a Fantasia, so it doesn’t actually come up. But I remember seeing it, I remember having seen it where they do this dependency mapping and they use a lot of red string which is a wonderful indicator of the dependencies. And in some cases, yeah, I can definitely see that the systemic reason is that they’re not actually feature teams, but component teams.

Ben – Yeah. And I think part of the problem is that we ask teams, oh, this happens all over the world, not just here, but we ask teams to make individual plans. And then we try to retrospectively, systemically optimize all of the locally optimized plans.

Georg – Yeah.

Ben – You can’t take a lot of stuff being optimized for an individual or a team and then put it together and optimize as a whole because you’re always going to end up with something which is suboptimal.

Georg – Right. So, you mentioned essentially that we’re looking at multiples of these areas structures each with roughly 50 people or so. So, what would you say is crucial to bear in mind in order to keep up good teamwork and keep up the team spirit in those groups and across those groups?

Ben – Have a product owner really focused on building the right relationships. So not being an in-between person, a proxy, but actually focused on building strong relationships between the customers, the users and the teams, so that the teams are getting the benefit and the users are getting the benefit from working together. I’ve seen that when they are set a good, clear goal. We have a period of time, we’ve made a commitment to a regulator or somebody, and we need to get this done by this time. But how you do it is up to you, here is the outcome we’re looking to achieve, by way of making this much money or saving or protecting this much cash. And then the teams get on and work within that clearly defined boundary. So, we’ve got a goal that is motivating them. They can see how it’s affecting the bottom line. They know who to speak to. If they know that the product owner has got their back, that will build the right relationships. Having the product owner building good relationships with higher management, ensuring that whatever happens, however many product owners you have, that they’re supporting the organizational direction. 

So, if you say to the organization we’re going to be agile, fantastic, but there are buckets of it and we’re going to do servant leadership but then your product owners start behaving like autocrats and dictators and not supporting organizational strategic direction. So you have to make sure that as a product owner you are supporting that direction as well and I think having people move around based upon what they’re interested in learning and balancing that with having people work on what’s most valuable, I think is also important because one of the big issues is we talk about the people that do the work as the bottom and the people who are the leaders as the top when actually I kind of think it’s the other way around like it’s kind of saying that you’re on the bottom of it, so you are the least important when actually are the most important. So I think respecting the teams, as your engine, as the people that will drive your organization forward, are the people that are gonna innovate and the people that are gonna build the strong relationships and deliver you fantastic outcomes for the output created. And I think that taking your eye off of that and just trying to view it as a mechanistic machine with the people at the bottom of it, I think is wrong. So you have to keep that strong people focus and find ways to measure people’s engagement and monitor that and talk to people, go and see what they’re doing. And if you can keep doing all of that, and as someone who is a manager or a leader, or a scrum master or coach who is supporting the people that are doing the real work, doing that remaining humble, I think you can achieve a lot.

Georg – Yeah. And how regularly do you see all of these things practiced in those larger scale efforts that you’ve been privy to observe or shape them?

Ben – I think, not as much as I would like, there’s talk of engagement. And I think loads of scrum masters do a great job at looking at their teams’ engagement, like, how am I doing? I think that “go see” is always a sticking point. I think that managers, leaders / managers, whichever they class themselves as, find it very difficult to know how to approach “go see”, what it really means because you kind of asked them to do something that maybe they haven’t done for a long time and it’s kind of alien to them. And then I think people struggle because they haven’t got the relationships. I mean, I know when I was a director at Deutsche Bank, there was a time that I was definitely losing touch with the teams. I didn’t have that trust and respect. So my ability to rock up and ask them questions and inquire and say to someone I could help them was massively diminished. Because I would turn up and they’d be like “oh here we go, what does he want? What’s he after?” My intention was that if I didn’t have that trust and respect we were going to fail. So, I say there are sporadic applications of the things that I believe can really help. And I think a lot of it goes down to time and trust and building a relationship between everyone in the new organization.

Georg – Yeah. Thank you. What would you say are some recurring challenges that you find as you go now from organization to organization in their curiosity or ambition to adopt these ways of working at scale?

Ben – I think a reoccurring conversation I’ve had with most if not all places I’ve been, is on what is the role of a manager. And being able to correlate the bureaucratic aspects of the managerial role in large organizations with then taking a more lean, let’s say, management 3.0 perspective of management. And I find that it is a reoccurring challenge, less large-scale scrum sees, very much like with lean, managers as teachers in there to improve the capability of the system. But for many they want more prescription than that. Because what we are asking people to do is to shift from managing the work on behalf of people and dealing with the effects of organizations that are based upon technology architectural lines, to saying, well, those architectural lines are now disappearing and now you’ve got whole teams that need to grow together. How do you now engage with those whole teams, now that you’re not the person in charge of the big data organization? What are you in charge of now? That’s a big challenge. It’s a big pattern that I see recurring.

Georg – So, if I am not mistaken, some people would describe that as the frozen middle, which makes it sound rather horrible. So, I personally think I’m very curious to get your views on this. I think there’s a huge potential for middle management and for organizations, because if for those of them who are up for it, if they can withdraw from the management of the work and I’m paraphrasing, what you shared go more into developing the people and clearing the path for value creation by optimizing the organizational structures processes around them. That is an amazing advantage for any organization to have, right? Because the managers don’t have to concern themselves with the work anymore. So their creative potential can be allocated to actually making the organization a much more lean and improve the flow of product value. Is that roughly along the lines of how you’re seeing it? Or what would you say?

Ben – Yeah, it is, but it’s also, I’m aware that I’m probably too negative about these things a lot of the time but as I say, but it’s also very, very difficult because if you’re on a team for example and you’ve been a front-end developer and then you’re asked to get involved with selenium, it’s a small little tweak to what you’re doing, you’re still gonna be developing a lot of the time, you’re just going to learn some new complementary skills. But what we are saying to the management is, “Hey, you’re going to do a job you did not apply for. You weren’t interviewed for this. We don’t know if you’ve got the skills to do this, you can go do some training. You can go do a great course and maybe feel patronized by someone because you don’t see/know if you want to go down that path.” And that’s really tough. This isn’t something they signed up to. It’s not something they’ve ever been rewarded for. And I think what compounds that is when the people in those positions have never actually been on a software delivery team. So they don’t know what it is to be involved at the coalface and do the work. So, in Toyota they summed it up quite nicely in lean, saying that you should be able to look at your managers and believe that they could do your job better than you. I don’t think in many organizations that’s often the case because people haven’t been at the coalface doing it. So it’s hard for them to empathize. And I don’t think some people can or want to learn those skills initially.

Georg – Yeah. So, this is where we would need to introduce more nuance, right? Because it comes back to what you mentioned earlier as a Newtonian intent and reductionism where we’re just trying to over-simplify things that just by definition, aren’t simple because you’re talking about people systems. So, what if for the next couple of minutes we kind of put our heads together and suggested what a good program might look like that really helps middle management through such a transition?

Ben – First of all, may I say it would be understanding the “I can’ts” from the “I won’ts”. So some people will say “I won’t change” and that’s fine. Like they’re probably not for this role, I’m not saying they are not for this job but probably not for this role in the future. If they’re saying I can’t change then there is a coaching opportunity there. They work with the people who say I want to change starting now, and with the people that say I can’t change and focus on them first of all.

Georg – Yeah. So there’s an element of choice of course. And the element of working with those who are willing to explore options and something else that kind of keeps coming up is the difference in how people end up in management positions. There are some who are actively pursuing management positions and they have training and management training and leadership and a background in that practice. But then there are a lot of people who have started as practitioners and because they were really good practitioners, the only way to recognize them later on is to then promote them into a management position. And of course those are fundamentally different sets of skill sets. And so I think it’s a good program. Would you say that it needs to be open to kind of remedy some of those errors from the past and just make different options available for them?

Ben – Yeah. I think breaking the link between seniority and being a manager is wise and I see this everywhere. I think this isn’t assigned to any one particular industry. There is this perception that in order to be senior you have to manage people. And I think will break that link. So you can be as senior as, you can be any level you wish, and you can just be a specialist. If you’re growing people and you’re investing in the teams you’re working with or in then you can be senior, you don’t have to take on the management responsibility and that’s a great thing to break. Because it helps people maintain the things that they’re already fantastic in?

Georg – So, how often have you actually seen that in the world out there? The world of work? 

Ben – I’ve never seen it. No, I have, I have… I’ve been fortunate where I’ve been that person where I have been a senior person and have no management responsibility. That’s been most of my career in large banks. So it is possible.

Georg – Yeah. But it is not common is it?

Ben – No, no it isn’t. And it’s one of those things that until a few weeks ago, until I started talking to my wife about this actually and some other people, I didn’t realize I was that fortunate to be in that position like numerous times, numerous times. And I love being a leader. I love giving, I love being in situations where you can be suggesting different and arguably better ways of doing things and then people follow you. I like being able to do that. I don’t like to be having to do the line management aspect of it. I find that a bit too stressful. I’ve been really fortunate with that. I think there are a number of LeSS case studies where this has been the case, but I can’t recall many instances where I’ve seen other people that have been senior without having that management responsibility. So, if you are talking about a program I think it’s how to approach it. It separating the “I can’ts” from the “I won’ts” And understand you won’t coach the “I can’ts” work with the people who want to change. Have them try and break that linkage between seniority and management. So people are freed up to do the things that they actually are good at. And then they can do a lot of the things I suggest the managers should do, and that you were suggesting, just from being that senior person, being a specialist, there’s a lot of knowledge that has to be acquired to understand some of the frameworks and different ways to approach things. So having people go on education, good quality interactive, engaging education delivered by people that have been there and done it, not professional trainers, but ex practitioners or current practitioners, like soon, only soon the ex practitioners, or current practitioners. And then have support on the ground to help them translate that knowledge into real understanding through practice.

Georg – Right.

Ben – Because of the utmost importance.

Georg – Yeah. So, training combined with ongoing support mentoring coaching to actually get the support to apply and integrate the new skills and behaviors.

Ben – But all of this is around alignment on a meaningful goal for everyone. Not five different goals, one for each member of the leadership team, but one goal that brings everyone together.

Georg – Yeah. Right. So, I’m going to attempt a very brief recap on some of the key things that we would want to pay attention to in larger scales and recapping them. It’s occurring to me that they’re not all so different compared to one team. So, we had a clear alignment around a shared goal. We had invested in the team at the beginning to help them form in the process of teaming and not skip on that because of the huge dividends that pays. We talked about skilled product ownership where they have good relationships with the team and good relationships with the stakeholders around that. We talked about the acknowledgements that we want to actively work with management in order to help them. Revisit what the role is going to be? How best their particular skill sets can be leveraged in order to support the teams and support the organization. And we touched on the fact that simply training on its own will not be fruitful. We want to pair it up with ongoing support, mentoring and coaching. Would you say those are some of the key points that we covered?

Ben – Yeah, I would say so. And I don’t think I’d add on that other than to eradicate dependencies.

Georg – And the dependencies, right?

Ben – Eradicate what you can, manage what is left, but if you’re choosing a framework, let’s say scrum, you’ve got your organization here, don’t bolt scrum on the side, but keep all of the rest the same. That bolted on the side is better to succeed, because scrum can replace a lot of what you’ve got. So, if you look at scrum and say, well, what can be replaced and what have we got? How do we restructure? How do we create feature teams? How do we eradicate the dependencies? Then you will create a lot of higher order problems to solve but it’s the dependencies which will really, really slow down these organizations. It reduces transparency, decreases flexibility and erodes trust because it’s very difficult to deliver.

Georg – Yeah. Absolutely. So, one more time. Thank you very much to you watching this live. If you do have any questions, please pop them in whereabouts to wrap up. So this is pretty much the last call for any questions that you might have. Share them in the comments. So we can have them here. If you’re watching this later on, feel free to put your questions also in the comments and Ben and I can come back and pick some of those up hopefully, but definitely now is your time while we’re both here to get them live answered while we’re together. So, maybe my last question to you, Ben, would be, you’ve recently made the move from permanent, it was a fixed employment with one organization to become an independent, and which is a wonderful move. I congratulated you at the time and I’m still happy that you’re thriving in that in a new area. So, what I’d like to know and share with everybody watching is what is it that continues to inspire you and your work?

Ben – Learning from the past, if I am going to be honest with you. I think I’m mostly inspired by going back to books that were written a number of years ago. And I realized actually that everything we’re trying to do people have tried before in the past, and they haven’t succeeded, but there’s a lot to be learned from the history. So that really does inspire me and working with great people, working with great people who are passionate to really improve things. As cheesy as it sounds I like doing a bit of systems modeling with a group of people who are trying to improve something and seeing them join the dots that they couldn’t have joined before and seeing things with different perspectives, it inspires me and it and it does keep me going and yeah, my kids. My kids obviously.

Georg – Obviously. Very nice. Very nice. So we do have a question here. So this is coming from Christianne. Hey, Christianne. She is a loyal follower of what we’re doing and sharing welcome back Christianne. So what would you suggest instead of the quarterly PI planning as Christianne’s question?

Ben – That’s a good question. So, and I think it all depends upon your organizational context and how much of a planning horizon people are expecting. I think that having a vision for what you’re trying to achieve and they goal based roadmap which is articulating points in the distance and just something to work towards is a nice alternative to getting everyone together to plan on a quarterly basis. I think shorter planned horizons, doing planning as you go in scrum, you can say that you are planning towards a goal, but you’re doing it every two weeks. Now you may have planned a few weeks ahead of that individually as a team. And that gives you a certain degree of confidence because when things get a bit complex because we’re humans and we make things complex, planning for three months is pretty hard anyway. Is that really what we want to do? Do we want to plan three months ahead? Or are we just doing it because people have asked us to produce a three month plan?

Georg – Or because it’s part of a specific framework that the organization needs us to follow because they’ve chosen it.

Ben – And they paid a load of money for the framework so that’s what they’re going to stick to. But what I would say is that there’s a huge degree of value in the beginning of delivery getting everyone together.

Georg – Beginning of delivery, but then the purpose is not exactly planning, right?

Ben – No. It’s understanding and you can create a roadmap and you can plan out and do some commitment based planning and just say, we think we can kind of fill up the sprints in this way but things will change. If you can successfully plan on a quarterly basis and it’s serving all your purposes and it means your optimization goal, then fantastic but not with the people I’ve worked with, they may have a desire to do longer range planning but they also have a desire to change when they need to change. I think that an alternative to getting everyone together to plan for three months is to do lighter planning for that three month point. Set a clearly articulated goal and make sure you’re putting enough effort in as you go. So you’re not making this big investment and increasing your work in progress.

Georg – So, more of a road-mapping level planning together rather than a feature level?

Ben – I think so. And I’m sure that there’s a good amount of challenges that can be added to that. I say it all depends upon your organizational context but I’ve been reasonably successful throughout and we’ve never come together and planned for three months ahead because stuff always changes too quickly anyway.

Georg – Yeah. Yeah. Great. Thank you firstly, for the question Christianne I hope that was useful. We have another one here from Nadia. Hey, Nadia. Thank you very much for watching and thanks for sending your question through. So back to PBR, is it harsh to say planning gives people dates, they can focus on, build more plans on and importantly to them, hold the teams to. Perhaps they view PBR to give them nothing.

Ben – Yeah planning gives you a nice contract, it gives you a stick to beat people with. PBR doesn’t really give people sticks as much. So is it harsh to say that PBR gives people dates, they can focus on? No, not at all, whether or not you actually meet those dates?

Georg – Yeah, but I think what I always want to stress is the normalization of product backlog refinement. It is just as normal as everything else that is happening in the normal product development activities, right? It’s as normal as designing, as normal as coding, as normal as user interaction, plotting and user research. It’s part of it, it’s part of creating a shared understanding and working out which solution is best for which user need. So, if that’s not happening then everything else in the life cycle of the team or rather in the cadence of product creation gets ever so much harder.

Ben – What I like about large scale scrum is that it says refinement is an event. It isn’t an ongoing activity. It’s an event. That’s a formal event in LeSS. So you can’t escape from it. If you’re following LeSS then you have to do refinement and you have to put the effort in.

Georg – Well, to be harsh, inspired by Nadia to be harsh. Even when we look at one team’s scrum more often than not I don’t really see a healthy refinement practice. And it’s as valid on one team as I presume if you’ve seen in much much louder scales, everything’s harder.

Ben – The most enjoyable product backlog refinements I have ever been to, have been where we’ve had people from two or three different teams get together. One person’s presented a big, chunky thing they’re delivering. And then everyone bounces ideas off of each other and then they model it out and they say, “we’re thinking about breaking this big feature down in this way” And someone says, “well, hold on, a few months ago we did something similar. We did it this way.” And then “how did you do it that way? Because wouldn’t surely having access to this thing over here wouldn’t work?” And they say “Oh we got around it by…” and then they’re learning and they’re enjoying it. And you’ve got people who’ve got the software engineering expertise as well as the analysis expertise and the testing expertise. And they’re all coming out from different angles and then you can come up with something really interesting. And then what you’ve got actually is a chunky feature which is understood by a high percentage of people from different teams. So that work could potentially go to any one of those teams now. And that gives you a high degree of adaptability. If you don’t focus on increasing that learning then you’re not going to be able to adapt quickly.

Georg – Yeah. So, I think it’s really a conversation. Maybe we can summarize that what PBR gives teams is actually flow of creation and they’re reducing the risk that they’re tripping up in planning and they’re increasing the risk that whatever work they pull into the sprint, they’re increasing the chance of being able to complete that because they’ve done the necessary preparatory alignment and understanding beforehand just to a enough level.

Ben – So I would say, when I’ve been working at scale. One thing I have found useful quite often is creating a board to show, like a refinement board. And say “Okay this is the stuff that needs to be prioritized that we think it’s going be at the top. This is the stuff that we’re finding now.” And then bring it through. So people, so the teams are actually putting up the backlog as a whole board and just say “this stuff that is nearly coming in.” And then you can see it kind of coming through and the teams know “Okay. Right. So in refinement, next time we got to pick up these items” and then looking at the whole flow because sometimes one of the things that slows people down is that they don’t manage their work in progress for their refinement, and they try to refine too much. And as a result, it gets a bit slow and not a lot gets done. So I think visualizing that is really great. And from a product owner perspective in working at scale do the same at an Epic level.

Georg – Excellent, great chat, great chat. Good. So, we had aimed for this to be around 45 minutes an hour. We are a little bit over that. It’s been a wonderful conversation. Before we close down are there any other key things that you would like for people to know some top tips?

Ben – Read Edgar Schein’s work on humble leadership, humble inquiry, humble consulting. I think they’re great books. There’s a lot to learn that. I think don’t bite off more than you can chew. And remember that if you’ve got an elephant and you split it in two it is still an elephant, it’s just in two separate halves, so you don’t make things less complex by making it smaller and just making it easier to deal with. So deal with it in smaller pieces. But don’t forget that you still have got to keep a view of the whole [elephant].

Georg – Beautiful. Excellent. Thank you very much. So now we are at the end. What are some things that you have available that can help people learn a bit more about large scale product development?

Ben – So, I’ve got a number of talks coming up, which can be found on my company page or LinkedIn, “Dreams of feature teams” is a good one we’ve got coming up in a few weeks which is gonna be very interesting. Maybe it could be quite contentious. It is going to be good fun, we are talking about how achievable are feature teams in large organizations. I’ve got a lot of training coming up. So I’ve got a certified “LeSS basics” coming up in December and then an online, “LeSS practitioner” in January. Both courses are really well received. We spend a lot of time particularly on the online “LeSS practitioner” going really deep on the topics that are of importance to those people that turn up. So we do lots of systems modeling and we explore lots of really important topics. We get philosophical when needed. But the goal of all of the training is to have people leave with their questions answered and maybe some new questions to go and explore themselves. So yeah, the training that I offer is the best way to kind of get more of a insight and learn a little bit more about large scale scrum in particular

Georg – Sounds fantastic. And at this point for everybody And at this point for everybody who’s with us a little bonus announcement. Ben and I have actually started to collaborate on putting something together, a program that helps people learn about becoming really effective in a product ownership role at scale. So if you are interested in learning more about that we have a little page, a waiting list if you will because we are not quite ready to share what we’ve got yet. And I’m gonna put that And I’m gonna put that in the comments and also in the description down below where you can add your name and email address. And as soon as we have this available we’re gonna send it to you and you will be one of the first ones to know. And with that, what would be your goodbye words Ben now as we’re closing our session?

Ben – Stay optimistic. Just in life, stay optimistic.

Georg – Absolutely. Yeah. These are interesting times and yeah. Keep learning, stay optimistic. Let’s be kind, continue to be kind, wonderful. Okay. Thank you so much for joining us Ben, it’s been absolutely wonderful to learn a lot more from your background, from all the things that you’ve seen and at a future juncture I’m sure I would be delighted to have you back for any updates that you’d like to share.

Ben – Happy to come back, George. Thank you very much.

Georg – Wonderful. Thank you very much, Ben. And thank you everyone for watching live and for your questions and the likes that have come in. It’s been a pleasure to share this with you. If you do have any follow-up questions please put them in the comments. And I hope to have you join in a future team genius live. Thank you all very much for joining. If you liked what you saw here give us a like. If you want to get updates on these types of videos please consider subscribing to the channel. And with that we’re gonna say goodbye and roll the outro. It’s been a pleasure to be with you. We wish you all the great end of the day and of the week. All the best for the practice with the teams and goodbye.”

==end of transcript==

Watch the Video

Quote Cards

Photo of Georg Fasching

From the desk of Georg Fasching, passionate purveyor of Product Flow, and seasoned executive, team, and organisational change coach.

For his high-leverage, curation of methods and instruction, visit https://get.teamgenius.eu/.

Please share your thoughts and queries on the content above in the comments below!

Leave a Comment