Profit is, for businesses, like oxygen is for humans – we need it to exit, but it’s not the reason you exist. In this talk, Clarke will show you three ways tech leaders can make more money for their businesses by thinking.
On 11 November 2021, we hosted our first virtual conference with a great lineup of speakers, here is the first session Cash Cows make the best burgers by Clarke Ching.
About Clarke Ching
the bottleneck guy
Clarke Ching teaches leaders how to turn their teams into cash cows. He is the author of “The Bottleneck Rules”, “CorkScrew Solutions”, and “Rolling Rocks Downhill” and has been powered by the Theory of Constraints for over 25 years, and Agile since 2003.
Watch on:
The transcript for Cash Cows make the best burgers by Clarke Ching
Nader Talai: Good morning. Good afternoon and good evening. And thank you for joining us, great pleasure to have all of you with us, and thanks to our speakers as well who are giving up their time to be with us.
My name is Nader just in case you don’t know me and this conference started with one of my colleagues suggesting back end of July. It’s a good idea for us to do a conference and we said, yeah, okay, that’s good. And then you realize what you let yourselves in for. I’ve organized conferences before, I’ve been helping with other conferences, but we’ve never ran our own conference. So, this is the very first conference and there’s quite a fair bit involved. You go through the highs and lows. The excitement is turned around with ooh, what are we going to do? How have I got this? Oh, I haven’t got that. No. Do we know who’s going to be there? No.
So that’s how things started and we got together and then I reached out to the people I know, not just because they’re my friends or colleagues, but because I value their insight and the knowledge they have, they’re all practitioners, they’ve got good experiences that they want to share and you will see the line-up is all male.
I did reach out to some of my colleagues that I know who are female. Unfortunately, the timing wasn’t working for them.
So, if you need any help, just [email protected], will get to our organizing committee. And I guess that’s the other thing I forgot to mention. I should thank my colleagues who’ve been working hard to make this happen. Vishakha and Reshma, thank you for all your hard work and contribution. And I know you’re going to be doing more today, so it’s not over yet, but thanks. And the other thing to remind you is, of course, these sessions are recorded and also, we need, and we love to have your feedback. So, after each session, we have very short feedback, should take you a few minutes. That will help us and it will help the speakers because all the feedback is shared with the speakers. It will help them to see what things have landed, how they can adjust the messaging if they need to do any adjustment, because it may be perfect as it is. Also right at the end, we’ll get some feedback on the event itself, and that will help us to see what can we do better, what would you like to hear about more for the other sessions.
Today is 11th of November. For those of you who know or don’t know it is Armistice Day. So, we acknowledge and we are proud for the contribution that the people in the armed forces have made for us, past and present and continue to make and help us lead the kind of lives that we have and the privileges that we are all benefiting from.
So, at 11 we’ll take a minute to just respect our armed forces. So that’s just to remind us that at 11 o’clock we’ll do that.
Without any further ado, I’m going to pass over to Clark. Clark is an author, speaker all round guru. He’s got a lot of experience in theory of constraints and he’s applied theory of constraints to agility in helping teams, managers, and leadership to apply that. He has written a few books. I was introduced to Clarke by a colleague of ours, Rudiger Wolf. So, he gave me a manuscript of his “Rolling Rockstar Downhill” PDF, which I read and made some comments and sent back to Clarke. Obviously, I’ve been following his work and that was somewhere around 2005 ish because the book wasn’t published then. And then of course I met him in Lean Agile Scotland. And here we are, I’m going to hand over to you and I’m going to be listening and learning about why Cash Cows make the Best Burgers.
Thank you for the nice introduction. Yeah, I’m not sure how much hard work goes into putting these sorts of things on, so thank you for inviting me.
Today I want to talk about a topic that I actually think is very important in all times not just turbulent times, but especially in turbulent times and it’s where money and the commercial sort of side of all of the stuff that we do comes into it. Cause I know for a lot of people who are in the agile community, money is almost a dirty word.
And if you look at it like a pyramid of all of the people that work in there, the ones that actually care about money. So, the pyramid of all of the people that are working in the organizations that we all work with, it’s a few at the top and maybe a few that own it, they’re quite happy to care about the money they get in wages that they’re not so fussed about how much money the organization makes until it starts to go broke or starts to have a few bad years and costs get cut. So, money is really important. And I think I came from that background, but over the years, I’ve helped businesses make a lot of money using agile and TOC. And I’ve had to do a bit of thought to square away these sorts of beliefs I’ve had about, maybe money not being the best thing on earth, the root of all evil that maybe I grew up with, and actually turning it into the realization that organizations that don’t make money don’t survive. And that’s not good if you’re an employee and I’ve been in that situation a few times and I’ve helped turn around that situation a few times.
And I’ll tell you it’s much nicer to have a job or to have a job and a place that’s actually making money than one that isn’t. But that said I’m not a raving capitalist. I like to think of what I do as value as like software engineering or civil engineering. It’s just that we engineer the making of money.
And agile is just perfect for that. If you’ve read any of my books, if you’ve read any of those, they’re all about the idea of actually doing good logistical, logical sense of all stuff and being nice to people and making money. It all goes together. You can have all of those things together if you want to. But you can also have them competing with each other if that’s the way you’re inclined as well. So just if you’re interested and you want any of those books that are there, they’ve all done reasonably well over the years, you can check them out on Amazon if you’d like, but if you’d like a free copy, track me down on LinkedIn and just say hello, or just connect and I’ll send you a copy of any or all of those. I’d be delighted if you had the pleasure of reading them. I had the pleasure of writing them. There’s nothing nicer than having someone read. In a way it’s nice to leave a little bit of the legacy not that I’m going anywhere for a while yet.
Agile plus TOC. So, TOC is the theory of constraints. It came from the seventies in a book called “The Goal”. ” The Goal” has sold millions and millions of copies. It’s my favorite book ever. And these days I struggle to get anyone else to read it because it’s a big old book and it’s a bit outdated, but it’s wonderful.
I’ve applied the idea and the theory of constraints and I’ve melded it with the ideas from agile. So, what I do is I do TOC on top of agile. I also do agile on top of TOC because they actually worked both ways, both are better with each other than they are by themselves. So, I’m going to talk about agile plus TOC, and I’m hoping that you will just go, this is just amazing and then go away and read all the books in the world that you can about this stuff. Cause I find it just so interesting and so pragmatic and useful, and it just creates wealthy happy working environments. But I don’t want to talk about the nitty-gritty of that. I’m going to share some stuff in here, which I think you’ll find interesting and hopefully a little bit illuminating and differently new, but I want to just imagine here that this thing that you’re seeing here, is a very poorly drawn iceberg floating most of it underwater and then the bit that’s sticking at the top is agile TOC. I think there’s a lot more depth underneath it. And there’s some stuff that we can do with agile, you’ll see when you combine them which is just wonderful.
You’re already doing agile, adding TOC even makes it more wonderful. So, you can, for instance, which is pretty cool, you can make more money. And when we do agile, we do try to make good products that sell well, that make more money, that serve their customers, all that good stuff. And if we use them and if we turbocharge them with TOC, we can make even more money. And this one might be a little bit surprising. I need to show it along with the other one there. You can also create a work environment that is both calm and buzzing. I’ve chosen those words. I’m going to show you a framework that I built up over the years, and I’ve chosen all the words very carefully, but I’d like you to maybe think about those three things there and just imagine that you’ve got one of those old round beehives I think that Winnie the Pooh used to look at. So you’ve got one of them near, the bees are flying in and out, or maybe it’s a wildwood beehive that’s out there. So if you think of the profitable beehive, we’ll be making lots of good honey, which is really good. That’d be buzzing. Busy bees, there’d be busy bees being productive, hardworking bees in there, you’d have a lovely buzzing workplace. And if you stopped and listened, you’d hear the bzzzzz of all the bees hard at work, but you’d also have a sort of a certain sense if it’s good times, of serenity, you’d have a calm that goes with that buzzing.
So, they’d be making money, that’d be profitable, which is brilliant, they’d be buzzing around but they’d be calm, and the calm might fade away very quickly if there’s an attack, I don’t know, maybe the wild bear rushes up and attacks it. It wouldn’t be calm then, the buzz would turn into an angry calm and in a workplace, you can tell a nice workplace, when you walk into it, there was a buzz about it, and there’s also a calmness and you might think of buzz and calm as being opposites of each other, but they’re not, you can have both of them at the same time. And for me, these are the three things that I’m aiming for when I work with people. When I look back on all of the jobs that I’ve worked at, probably the profit was there, but it was almost invisible because I didn’t care about that. The buzz, you could feel that, but I’ve worked in places where there wasn’t calm where there was anger, customers were arguing. Sometimes face to face argument, it wasn’t calm. It was angry. I’ve worked in places that were being closed down and had to make people redundant. And that wasn’t a nice place. It wasn’t calm. People were stressed and they were becoming more and more competitive and they were leaving and it wasn’t calm.
So, I’m just presenting here. There’s three outcomes that I think we should all be aiming for, which is a profitable business, a calm business and the buzzing business. And they’re all good together, but there’s this iceberg, there’s more depth to it than this, that’s reasonably deep, maybe more deep than some people will think, assuming you agree with it. Could be complete nonsense as far as you’re concerned, but there’s another level to it. And this is where we’re thinking about leadership. And I think there’s something: I’ll show you the words. I believe that all tech leaders, all caring tech leaders (and their teams) deserve genuine commercial respect.
And I think if you frame what we’re trying to do in our technical world, in our IT departments and our software development teams and so on, and when we’re doing agile and we’re trying to sit inside of a bigger business, since two of our customers, I think we deserve, as the leaders and as the people who come here executing the work, to be treated with genuine commercial respect. Because we make a big chunk of the money. But it’s not always this, if you look at it in other places and IT, in our language, we got the business and IT, it’s them and us. We’re seen as the supplier, we’re often seen as a black hole and money just gets poured in, where everything’s late where we chase all of these exciting new feds and things. And then we’re still slow and sluggish to deliver stuff. We’re not seen like the other departments, you don’t see the head of accounting, people don’t think of the accounting area as being separate to the business. But for some reason, at least I hope for historical reasons, we, especially in the leadership area in tech, have always been seen as it’s not part of the overall business leadership.
And I think we need to do something about that. And focusing on those three things in the middle there will help us do that. But more than anything else, it’s actually something that we need to start to make happen. We actually need to make this happen. And then we know we’ve got it right when we are actually regarded as a genuine heavy lifting part of the entire business, and we’re treated with genuine commercial respect.
So, I’m going to unpack this and put it in a different shape. I have this little manifesto that I’m working on in my head and it really starts with “I believe that caring technical leaders and their teams deserve genuine commercial respect”. That’s the peak of what agile and TOC is about for me. So, we have the three things here, profitable business, a calm business and we have a buzzing business.
Now I want to talk about the first lever, the first leverage point that we got, there are three of them here, this one is snowballing benefits. There’s two others that will come. And then we’ll drill into a little bit of detail on each of them here. But snowballing benefits is where this all starts. And what it is, it’s a move from the mindset that the paradigm that we are building software and features for users. We’re actually engineering value, we’re making money. So I’m going to pop into my little drawing mode here. I’m just going to show you what I mean by snowballing.
So, could you just imagine an imaginary universe. In fact, two parallel universes, and they’ve got this funny thing that in these universes, they’re run by software teams and they do exactly the same project over and over again. And at the end of each project, once it’s done, they only do one at a time, each of them sequentially. The business that they work inside makes £1 million pounds extra per month. In universe one, each project takes four months. So that goes for 1, 2, 3, 4 months. Let’s just look at universe one and its delivering format. So, if this was a year, this line here, after four months and four months, so you’re going to get three projects each year. So, four months each, so four there.
And then, when that one releases and it’s published, let’s say it just produces a new product it’s going out in this imaginary world, we might make 1 million in the first month and then another million in six months and then another million and so on. And then when this one release, we start making another million and another million and so on. There’s nothing tricky about this. But universe two is a bit different. Every project there, through some magicalness, only takes three months. So, it finishes there, there and there. Three months, three months, three months, three months. Every time I present this to people they’re surprised and if you’re not, that’s brilliant. I think it’s a really good sign for you. But for me, I’ve found it’s counter-intuitive what I’m about to show you. And it just surprises people, but it’s really, really obvious, there’s no trick to this. This is the benefit of snowballing. I want to compare universe one with universe two and just see how much more money each of these projects makes.
So, if you look at this one here, this takes three months versus four months. Clearly you have one more month of value coming because it starts earlier. So, I hope that makes sense. So, call that 1 million. So, there’s 1 million extra for project one. If you’re in the chat, could you just pop into the chat and project two takes one month at least as well.
So, can you tell me how much money you think extra project two makes? And it’s not a trick question, but you may get it wrong.
Could you actually put it in as how many extra million? So, project one finished one month earlier, made 1 million extra.
2 million per month says Ellen. That’s good. So, if you see the numbers there, this is probably really blindingly obvious but the second project makes 2 million extra because it started one month earlier and it took one month less. So, it’s delivered two months earlier.
How much extra does the third project make? That’s 3 million. And the fourth project? 4 million. And the fifth project? 5 million. Everything has been shuffled back and back. So, there’s a snowball effect here because I think the reason why a lot of people are surprised by this is because we tend to think about what’s right in front of us.
And the first project finished soon and you get the cost today for that project is 1 million, but it’s potentially much, much more than that because the cost of delay is the delay for getting the value of that project plus the delay for all of the projects that came afterwards. So, it’s like this snowball effect, starts small and every turn, it gets bigger and bigger.
I think, from a commercial point of view, although that’s hugely simplified, that’s what we need to be aiming for. So that’s the snowball effect and that’s what we should be aiming for every project or every initiative we do.
Most of what we’re doing is trying to be more productive by being more collaborative, by being logistically smart and doing all sorts of things. And if it means that we can deliver stuff and get it out earlier, then we can make more money. And that’s just by thinking. Of course, these universes are imaginary but in the real world, how can we finish this sooner and get the profits and the benefits and the value engineering. So, it snowballs and gets bigger and bigger and bigger and bigger and bigger over the time. We make more money and if we’re competing with someone else, if we are in universe two, and our competitor is in universe one, then we are evolving much, much, much more quickly than they are. And we’ll soon outpace them and they’ll never catch up with us.
So, the snowballing effect is really important. And I hope as you’re watching this, that you actually think is really obvious. It took me ages to think about it. I think it actually means that the cost to delay stuff, that we usually think about, only tells a tiny part of the story.
So, moving on, the snowball effect. I’m moving back to these circles here. If we have snowballing benefits, that gives us two things there. It gives us profitable business and a buzzing business. So, the profitable bit is clear, we make more money because we’re more productive, we ship more often and we get this lovely effect that everything ripples forward and we get a buzzing business because we make progress.
If you’ve never read this book, is really lovely short book. I totally recommend it. When I’m coaching people and mentoring, it’s just usually the book that kind of drives on how I’m helping them and is called “The Progress Principle”, it’s written by a lady called Teresa Amabile. And it’s the idea that, when you make progress, you feel good. You go home at the end of the day and your partner or a loved one says to you, how did you feel? How was work today? It was great. And then you might explain why, but it could be we’re saying is we’ve made progress. If you didn’t make progress and you get blocked, you’d come back home, you feel a bit glum. How much progress you made the day before and how you felt about that, determines how motivated and how much progress you can make the following day. There’s this really lovely buzz of being clever working together that comes from, the way we would nowadays, the nice agile rhythm that speeds things up with TOC, just really gets that buzz. It creates a lovely profitable and just joyful kind of environment.
Now: predictable projects is the second lever that we have here. And that gives us profitable business and a calm business. And this might surprise you cause I know in some agile circles you can’t say the word project and you have to refer to an initiative.
I know in a lot of areas, it’s actually a misunderstood area. So, what I mean about predictable projects is give you an example. There was a company I never worked with them, but I was close friends with people that worked there and I did a few chats with them years ago. They built audio chips and the audio chips got put in an early version of the iPhone, which you can imagine was just wow, amazing for them.
Then, the next release of the icam phone came out and they missed the window to be selected by three weeks. There’s three weeks. And so all of their projections, the profits fly up amazing. They shot down within a few years, we were bought by a competitor. Timing is really important for some things and, giving a date and actually hitting it, it’s really important. So, you take a lot of companies at the moment that are exporting. They’re not doing software stuff, but, if this stuff doesn’t get into the shops, by Christmas, because of all of the problems that we’re having with shipping and so on, they’re gonna lose a lot of money.
So sometimes, when I’m talking about projects here, it doesn’t exclude the just to notice, the comment projects, products continuous value delivery. That’s the stuff that happens in snowballing. You’re already doing that. When you’ve got a date that’s really important and getting something live before Christmas is really important. Otherwise, you make a lot less money. Then the dates are more than important. So having predictable dates is hugely important for making money. It’s also important of having a calm business. If you’ve ever worked somewhere where you’ve got a project and it’s running late you’ve got to hit this state. It’s really important.
I had a project I worked with at a local government, here in New Zealand.
I’m looking at the the comments here. And I’m just cautious. I’m just worried that I may have mentioned the word projects and caused outrage. But I think projects and data are really important if you want to survive as a business and make money and, the mechanism you use, continuous delivery, whatever you like, products, just call the same thing. If a day is important and you miss it, you won’t make money and your calm levels will go down.
Can you imagine being in that company where you’re all excited, you’re going to get the chip into the iPhone, and suddenly, boom, you miss it. It’s not calm. It’s not a calm place to work. Suddenly everyone was terrified they’re gonna lose their job. I’ve worked with a big American company a few years ago, and before I got there, they had spent three years delivering a project that was supposed to take a year. And then, when they delivered it, they were very buggy and their business tumbled. And we had to get that back on track and basically just most of the HR stuff was just getting rid of bugs and getting predictable so that we could deliver.
There is a financial aspect to that because we wanted the customers to buy the product. But, more than anything else, when they started making money and went from being a nasty, unhappy, stressful, long hours work, weekends work, everyone feeling horrible because they had to cut corners to get stuff out, to suddenly returning to a level of calm.
And from a financial point of view, the financial folks loved it because the cash flow thereafter, when they could start releasing products again, all the time, every three months, they would just give a release. Release the cash flow, not only shot up, but it was really smooth. So that’s the two things you’ve got there with predictable projects: you can make more money and you have a calmer business because you get far fewer surprises.
And that’s the key thing here. Is, with the predictability, the surprises I like going up to that beehive and chucking a stone at it and knocking it sideways and terrifying the bees. And then suddenly they will swarm out and start chasing you because it’s not calm and you don’t want that.
The third area it’s quite counter intuitive for a lot of people. But it’s quite changed. This is enormous because if you think about calmness, one of the things that causes so much stress for people working in a business, whether they be on the business side or in IT, is when there’s a lot of change.
I’m sure you’ve maybe been in transformation projects where they actually start with a lot of buzz. They start with a lot of cheerleading, a lot of excitement, they’ve got big ambitions, they go along and then there may be, get a quarter of the way through, they’ve got all of the people who love new stuff on board.
They’ve got their converts that were really pre converted. They all love being here, then they hit cynics and they hit the difficult but, at end, it just slows down. What started as a wonderful transformation with so many good intentions and great ideas suddenly gets stuck and dies. Or worse, doesn’t die, dies very very slowly over time.
I think that checking that kind of big bang, that very loud shotgun approach at people and turning their lives upside down is wrong. I think that’s a disgraceful way to treat stuff. Even if a quarter of them are really enraptured and love the idea of it, I think that’s a terrible way to treat staff to put them through all of that change and turmoil.
If the theory constraints that the fundamental idea is how to focus, on the one area where you need to change. The one area: where do I need to change? There’s so many things I could change. Where do I need to focus? And if you combine, if you use the theory of constraints, can focus that various tool that are there.
And if you combine it with an agile, iterative and incremental way of rolling stuff out where you pick your battles carefully and you prioritize them, you can have a nice quiet change. That’s very effectively just to fix the things that need to be. Just leave everything else alone. If you do that, you actually end up with a calm business because things keep getting better on data, just nice and quietly.
There’s no cheerleading or overexcitement around it. It just gets better and better. People are aware that things are getting better, but more than anything else, they’re not being turned upside down and losing time to do the snowballing delivery of value and software engineering. They’ve actually got that time to enjoy the buzz and actually just get on and do their jobs.
So, the fundamental belief of TOC is that you need to focus and find the few areas that you need to change at any one time, whether that’d be a bottleneck or something else. All of TOC tools. No, not all of them. Most of them are around the idea of figuring out where to focus so that you could tweak and make the world better without anyone making a big fuss about it. So, these are the three levers that I use and, what I would love you guys to think about here, in order to change, to improve, to make more profit, to deliver more value, to get the buzz of being productive and proud of the work that you’re doing as when there’s profitable, but at the same time, just nice and calm because you’re getting on with things.
It’s lovely to have your customers, whether they be internal or external, looking and thinking, but with the predictable project side, that you’re a safe pair of hands. And I want to just point out one thing about the predictable projects. It’s more than one, it’s plural projects, but not everything.
In fact, most things don’t need to be a project. Only things that are really important, need team’s focus. Really serious stuff where you’ve made a really serious commitment needs to be projects and managed as projects.
Now I’m going to go a little bit further here. There’s each of these circles, I’ve managed to find the three little accelerated pedals on each of them. And I’m going to start with the one will probably resonate the most is the easiest for me to describe.
It’ll probably be the hardest for you to believe but you would deliver so much more value when you believe this and start to do it. If you know, the theory constraints at all you’ll know this about bottlenecks but just what that means is that in any flow system, which is just probably where you’re working, there’ll be one point, one resource type, which is when companies convert from waterfall to agile, it’s usually inside, it’s usually testing. And that’s why we’ve put so much effort into automating testing and getting the developers to use some of the capacity to actually help and do testing. Not black and white that rule, but it’s just so common. In the old days, when most people were converting from waterfall to agile, rather than from a broken agile up to a new agile, it was almost that I’ve always had cases there.
We didn’t have enough testers. We could build code faster than we could test it. And a lot of people kept building code faster than they could test it and actually created a huge mess of untested code, which was worse than being productive. It just created so much rework, but anyway, the bottleneck is the narrowest point in your flow system. So, these lurker and eight timer, and in my accent, there was a big IGG as EGG for the rest of you, the egg timer. That’s the bottleneck.
I want to show you this, because this, for me, is the cleverest thing I’ve ever done and I suspect you won’t find it obvious, but please, if we sat down for a couple of hours and I drew stuff out and I’ll show you how it works in the real world, you would go: “wow, that’s amazing”. And then you go away and you go: “no, but it can’t be true”.
I’m going to just draw this out. I think this is the most clever thing, is what I spend most of my time doing. So, I wanted to just put a green pen here and I call it the U shape team, and then it’s not lined up quite correctly there, but if you were to map out the capacity of everyone with the egg timer, if you were to map it out, you could dip it there, has the least capacity, right? This here obviously has more capacity. And this bit here has more capacity as well. If you were mapping them out and you sit, what is the absolutely ideal way to structure a team with respect to capacity? Because we know we’ve got to have a bottleneck. We know that. We don’t want one, but realistically, you’ve got to have a bottleneck otherwise you would have infinite capacity and that’s impossible right? So where would you want your bottleneck? When I tell people this, ” we don’t want that, we want the opposite”, but the answer is you want your developers to be your bottleneck. And you want everyone upstream.
This is the product only here. So, the analyst, you’ll have other people there. Say typically to have scrum masters. You have all sorts of other people and resources, and you want the ones upstream to have more capacity from the developers. Because if they can’t, they haven’t got enough capacity to feed good stuff to them and what they’ll do?
And I swear, at least 90% of the teams I come across, no matter how ahead engineered they are, they end up not having enough capacity to feed the hungry developers and they keep feeding in lower value or half ready work. She has to keep the developers busy and it gets worse and worse because most teams think that the way you go faster, if you’ve got a software development team, is adding more developers. But I want to show you the exact opposite and the opposite of the U-shape team, the in-shape team, I would say that 90% of software development teams have too many developers. So, place the bottleneck is figuring out how to move there from there to there. And back from there to there. If you find that obvious, that’s brilliant. If you don’t find it obvious, you’re probably going to think I’m a bit nuts.
But trust me, this is how I earn my money, helping people. If you’re going to a smallish team and you can work with us, you can figure out how to get your developers to help flip this over. You’ve got spare developer capacity. How can you do that? How can you flip the capacity profile over? It’s really easy on a small team, if you’ve got control over that. I’m working with the team at the moment, with between 250 and 300 people, and there’s one person, the person here. Effectively isn’t the product owner cause she has a team of about 15 product managers and product owners, this one person who was the bottleneck for this entire team.
So, we could go get more developers, that’ll just make things worse. We could go get more testers. That will make things worse. What we have to do is figure out how we can get that one person’s capacity up. She’s the leader of the team, of the division, the 250 people. How do we offload stuff from here so that everyone else’s can go faster?
I’m going to move on a little bit now. The second thing you want to do to get snowballing effects: there’s two obvious bits with the snowballing effects that if you get the bottleneck in the right place, you’ve got good inputs, so you’re going in the right direction and you’re managing the bottleneck, so you’re going fast. So it then goes the two brilliant things, good inputs, so getting the right direction, and we’re going as fast as we can. Combine TOC, bottleneck thinking with agile, and you’re just turbocharged. In fact, TOC should stand for tur-bo-charged.
So, you’ve got the bottleneck. That’s job number one. The second bit is to curate what you’re working on for cash. And I’m not going to go into the details of this, but there’s a lot more that you can do to make more money and to make more joy and have all those snowballs working really well beyond what Agile does.
If you don’t know me, I’ve been doing Agile since 2002. I’ve been doing TOC since the mid-nineties and Lean and Quality before I hit Agile. I love agile, but a lot of Agile teams, for instance, focus on the product and a user. They’re not actually answering the question “how do we make more money?”
And you might think you are and it might well be that you are, but they’re not the same thing. And if you want to make more money, especially if you need to make more money, then figuring out how to curate the work that you work on in a way that makes you more money, is the very first thing you do.
Now, the third bit about this. So, we’re getting a good efficient delivery system here and the snowballing benefits, right? We are still building software, but we’re actually also value engineering. When you build this U-shape, when you curate and when you do a few other things around it, and then you get a new manager to come in and look at it and they think it’s just crazy. Cause they see these people who’ve got speed capacity. And what they do, inevitably, is that they flip things upside down. The number of times I got a U-shaped teams and then I come back a week on later and I saw that they’d been just mentored by well-meaning managers, who I hadn’t been around to educate about it.
So the last bit as you have to protect it ,it is the most unstable thing. Someone would say, look, we need to go faster. And they’ve got a lovely U-shaped team. They’re going to hire more developers and the flip it over and turn it into an in-shape team or from a smiley face if you’re like into a friendly face.
So, protecting that shape is just hugely important. It’s just so easy to go backwards.
Now, did you see how tense I was when I was talking about projects? I’ve been taken aside before, as someone who’s written books, being hired to do stuff and a reasonable level of competence and told off for using the word project in the office. Projects, as you would’ve heard, I think they’re really important, but I get tense cause I think they’re misunderstood.
And that’s why at step 4, which is the first of three things you do with the] projects lever is to actually confront the elephant in the room. And the biggest elephant in the room is the business. And IT, all the software team, aren’t working together, they might be at functional level, but that busy negotiating and the customer is busy trying to force more scope in while IT is busy, trying to fend off getting further dates if they have dates and negotiation. It’s like they are two football teams, two soccer teams, playing with each other, but really, they need to be on the same side. So that’s the first elephant. And that’s probably the hardest thing on this, this whole bit is actually to get those people to sit down and get them around, sitting on the same side of the table, solving the same problem.
But when they do that and you’ve got them there, you have to change the nature of the problem. Agile is set up wonderfully to deliver projects on time. It is the best mechanism, but it requires that you sit down with your customer and you make a promise around variable scope and a fixed date.
And ideally, actually, this is going to shock you. You actually start with an aggressive date and make it more aggressive. So the discussions around scope get even more and more intense and people stop thinking about scope and thinking about value. We don’t have time to go into that there, but these are hard.
They’re the six, but they drive for delivery. When you’re doing this as a whole lot of things, but you’ve also got a lot more elephants there that you have to talk about, the elephants in the room, you have to talk about them. And when you drive for delivery, you do all of the obvious stuff that you know from Agile about, if you’ve got risky stuff, either get rid of or, land the airplane at the beginning of the runway so you’ve got time to fix it when it’s cheap. You’d need to try delivering, the area where you need to most drive delivery is making sure that you’re chasing financial benefits or other benefits that are at that same level as financial. Not just trying to build the biggest, best products. You want outcomes over features, actually, I think you want benefits and Pound signs or Dollar signs or Euro signs over benefits.
So, driving it to deliver on time starts by having some hard conversations. Just one moment here. I’m nearly there. This one quite change. It’s a similar to the predictable projects, it actually starts with harder conversations. But they’re around building trust. If you try and change an environment, people’s resistance will be really up when they start, they’re going to resist except for the Neophiles I spoke here or things like this. We tend to love new stuff, everyone else is gonna be distrusting. So, you need to start by either building or rebuilding trust. It doesn’t work if you don’t do that. The rest is sensible logistics, but if you frame everything in terms of how can I build and rebuild trust, how do we behave in a way that we are trustworthy and respectful of each other?
we go to step eight, which is pick your battles. When you pick your battles, the important thing is that you pick the right battles and you ignore everything else because it’s really only one thing. This is this focusing mechanism that TOC gives you. You need to focus and pick the right battles, and you also have to need to pick the battles that you think you can win.
And ideally, you’ve picked them in a very focused sniper way, and then you treat them not with a chainsaw, with a scalpel, mixing a lot of metaphors here. And then finally, because we’re doing change, and the method of change is effectively a combination of TOC’s focus and Agile’s incremental delivery and a nice loop that states: are we going in the right direction or are we winning the war? So, you got to keep that big picture there because you’re always executing incrementally, but you’re always asking yourself, what’s the next thing that we need to think of, what’s the next thing we need to focus on.
I genuinely believe and I’d love for you all to just go to:” is this actually something that I should believe as well?” I believe that all caring tech leaders and their teams deserve genuine commercial respect, but I also believe that something that you create by solving the problems of your colleagues and customers that you work with and not just focusing down on that good technical stuff.
So, if you’re doing Agile, that’s awesome but you’ve also got to be thinking of this bigger stuff here. And I’m sure you already are, but I think you should set your goal, if you want to chase genuine commercial respect. And that’s me.
Nader Talai: Thank you, Clark. So, I guess we got time for possibly two maximum questions. Thank you very much.
Clarke Ching: What to do with people treating project with iron triangle?
That’s why you start with the elephants in the room. But then there’s one of the other big elephants. If you’re negotiating, what are you negotiating over? Fixed scope, fixed date and fixed budget and maybe flexible quality. So, you need to sit down and make those promises around.
Hey, look, the promise we’re making is that we’re going to deliver you the most. We’re delivering on cash flow. This is what we’re doing here. We’re trying to deliver the benefits, that’s for we’re engineering value, and we want to chop stuff up. This research, you start by having those hard conversations.
That’s probably the hardest bit because most people have been electing a little civil war, where the business is in a civil war with IT, and they don’t have those collaboration skills, they have bargaining skills. And so that’s why the elephant’s in the room, you need to sit down and discuss: “Look, this is how we work. We are two teams competing with each other. Two rugby teams, the All Blacks, that always has a little advantage competing with each other, but we’re actually on the same side. So, we need to sort that out.” And the best way to do that is to figure out what’s our mutual purpose. We’re all chasing good commercial outcomes. Plus, we actually want predictability and we want a buzz about the place. So, it all comes back to the conversations, unfortunately, cause that’s the really hardest thing.
Nader Talai: Thanks, Clark. Thanks for joining us from New Zealand. Of course, there are loads of books and blogs and Clarke also runs a lot of meetups sessions. So please look him up on LinkedIn and you’ll get a lot of good, valuable information from what he does.
Clarke Ching: Thank you very much. If you want any copy of these books just LinkedIn is the easiest way to get a hold of them. Thank you very much for the invite. Enjoy your day.
Nader Talai: Thanks, Clarke. Bye.
