 I'm going to talk about secrets of growing and innovation culture, which is a bit of a ridiculous title, but this talk was essentially sparked off by a conversation I had with a senior architect type person at a large company that you've probably all heard of. And this guy pinged me because he wanted to hire the next John Allsport. So for those of you who don't know, John Allsport is the head of Ops at Etsy, fabulous brilliant guy, and he said, you know, we want to hire someone like this. And my initial thought was the fact that you have to go outside of your company to try and hire someone like this demonstrates that you've failed as a company to actually be able to grow these people internally. The next person like that should be coming from within your company. And if that's not true, you failed as leaders because part of the job of leadership is to be able to grow the capability of the people within the organization. So I'm always profoundly depressed by LinkedIn, all these people trying to hire. It's all about trying to hire in talent. And I think that demonstrates that we're doing things wrong because we shouldn't need to always be hiring in senior people. We should be growing those people. So how do we do that? Well, this talk is just a number of thoughts and things that I've put together and read about in the course of my research on how we actually do this. So I don't have the answers. I just have some thoughts. And the purpose of this talk is to hopefully spark some thoughts and discussions and ideas on how to improve the culture of our organizations generally. So we often think that our job is to build systems and products, but that's only one part of what we do. Our work has two outcomes. Firstly, it has the outcome of the systems and the products we build, but it also is creating knowledge. I mean, we always talk about IT as knowledge work, but normally we talk about knowledge work in terms of kind of in this transactional way as consuming the knowledge of the people doing the work. So the kind of model that's at play in terms of knowledge work is two-fold. Firstly, there's kind of a bank account model of learning. So there's a book called Pedagogy of the Oppressed that came out in the 70s in Brazil by an educator who basically criticised the dominant educational paradigm, which was that we treat children in our education system as empty bank accounts who we aim to fill up with knowledge. We kind of pour the knowledge into their heads and their passive receptors of knowledge. And what he noted in this book is that when we teach in this way, what we basically are doing is trying to create a system where we preserve existing social structures and social power and controlled by the elite. And real education happens when the people who are learning participate in how they learn and are responsible for helping decide how they learn and what they learn. And so if our education system follows a bank account model of filling our empty young children's minds up with knowledge which is decided by the people in power, then a lot of our companies behave as if we have filled up bank accounts that we're draining of knowledge in the service of profits and of building products. And so I think we kind of lost, I mean when we talk about, you know, a knowledge culture, we need to think differently about that. The job of companies is to help grow knowledge and grow the capabilities of people, not just to suck knowledge out of the heads of employees. How do we innovate? I mean this word innovation, one of the things about innovation is that when we innovate, we cannot know in advance what we're going to produce. Because if we knew in advance what we were going to produce, it wouldn't be innovation. And this is a really important point when it comes to thinking about how we actually plan innovation. If you could plan what you were going to produce as the end products completely in advance, it wouldn't be innovation. And this is one of the reasons that I think there's a serious problem in a lot of even agile development methodologies where the first part of the process is breaking everything down into small little bits and then feeding those small little bits, you know, stories or tasks or requirements, you know, into the development kind of process and then assembling the results out the other end. Because if we're doing that, we're not innovating. I mean innovation isn't just in the, you know, breaking down of little bits and pieces. We innovate in the course of actually doing our work. If we don't discover new things in the course of building products, we're not innovating. So innovation comes from the people doing the work, experimenting and improvising and trying things out. And in as much as our development process doesn't allow people to experiment and try things out and feed back into the process of what we're building and actually cause us to change what we're building in reaction to what we discover in the process of building it, we can't innovate. True innovation comes from people being able to experiment and improvise and tinker as we build things, not by creating a process and planning out in advance what we're doing. Innovation culture requires that, well, I mean first of all in order to be able to experiment, it needs to be safe to fail. So most experiments in an innovation context will demonstrate that our hypothesis was wrong. Again, that's one of the hallmarks of innovation is the ideas that we have, many of them will turn out not to be good. And so if it's not safe for those experiments to fail and we punish people for getting things wrong instead, then we can't innovate. And that's one of the biggest problems in large corporations is that people have punished for getting things wrong and it's not safe to get things wrong and in that situation that's what causes people becoming passive and not wanting to try out new things because they know if they try out new things and it goes wrong, management's going to slam down on them and tell them you messed it up, don't do that again, follow the process. Another problem with innovation at scale is that a lot of organisations try and implement innovation in the form of a change programme or some other transactional mechanism and all of these mechanisms have an end date. The one thing you can say about truly innovative organisations is that in organisations which really sustainably innovate and can manage to sustain innovation over decades, the improvement never stops. Anytime you see an innovation effort or an organisational change effort with an end date, you know that there's no real desire to actually create a true capability for innovation within the company. And then the other thing we need to think about is actually to some extent measuring how well we do at that. So who has a review process in their company? You have an annual review or some kind of review. Keep your hands up, keep your hands up, put your hands down if there's no focus at all on the kind of amount of knowledge that's been created or how well we've done at growing the people who work with us as part of that review process. So you can keep your hands up if that's actually something that people care about, how well have we done at growing knowledge, at growing the capability of the people we work with. OK, so a few of you, that's really good. That's really important. The job of leaders and managers is to grow the capability of the people under them and kind of make themselves replaceable. And what we notice about high performance companies is they're really good about talking about what they do, about blogging what they do, about simple things like having lunch and learns and mentoring people and helping people out. That's a really important characteristic of high performance companies is that there's a focus on trying to measure and improve how well we do at cultivating knowledge and capability within our organisations. So things that are not very effective. Classroom training is a very poor way of actually creating, of actually changing things. I actually make money out of being classroom training and I'm kind of conflicted about this because there's a high demand for training but my observation is that classroom training in and of itself doesn't create change. I was talking to Jason Yiff about this the other day and he made the point that the best that you can hope for in training is to spark someone having an epiphany or an idea which may lead to change. But you go through training. People in a day or two days cannot hope to develop a real habitual understanding of what you learn in that day. Buying tools is a really horrible way of changing your organisation and it's very, very common. My company builds tools including project management tools and often the people who are our customers they want to go agile and so they want to buy an agile tool so they can go agile and that's one of the first things they do and then what happens quite often is that they come back about a month later and say so we've noticed there's no way of measuring the time that everyone spends on these things and being able to track that and we say well no because that's actually a really bad thing to do and they say no no no but that's our process and we kind of say well actually maybe part of the change effort is that you want to change your process as well and they say no no no we want to keep our process and have a tool that conforms to that and then there's never any change so people always jump to buying tools it's very common buying a tool and implementing a tool is neither necessary nor sufficient for organisational change and improvement adopting methodologies is another very common way adopting scrum or having programme based approaches to change again with end dates are very common but again not very effective we'll explain why adopting methodologies is problematic a bit later on but we see so many people say oh we tried scrum and it failed or we tried agile and it failed and the essence of agile is not the things that you do the essence of agile is constantly adapting and improving and so obviously if you take something and you try and implement it as is that's one step and that's going to produce one outcome but the goal is to produce a continual improvement in our ability to change our outcomes in response to signals from our environment and then finally hiring people a lot of organisations try hiring people in order to grow their capability and that can be part of a change effort but it's not going to fix things on its own if you take a messed up organisation and hire really great people into that organisation what's going to happen is not that the organisation is going to change but it's going to break the people and make life really unpleasant for the people and they'll probably quit you can't just hire people and expect that to change an organisation in its own right a big problem we have in our industry is that growth tends to kill innovation start-ups are well known for being the hotbed of innovation and then what happens is start-ups if they're successful grow and become bigger and we see a number of forces at work firstly as organisations grow the business domain they work in becomes more and more complex and the systems they build become more and more complex cation as well I think so the improvement cutter is basically an iterative process for moving towards a goal in a complex system step one is for us to understand the direction in which we want to move where do we want to go what are we trying to achieve and then the next step is for us to grasp the current condition what's the current situation right now step three is to establish the next target condition where do we want to be in about a month two to six weeks and then once we've set the target condition the people doing the work will run experiments to try and achieve those outcomes because we're innovating we're operating in conditions of uncertainty we're working in complex systems we don't know how to achieve those outcomes the only way we can find out how to achieve those outcomes is to run experiments and learn the problem with everybody believes in continuous improvement you'll never go to an organisation and they'll say oh we don't believe in continuous improvement it's one of these things that everyone says they do but continuous is one of these words that means a lot more often than you think if continuous improvement at your organisation is having a retrospective every month that's not good enough continuous improvement every month is unacceptable one of the things that Mike Rother says is that these experiments should be occurring every day every day we should come into work and ask ourselves what's the target condition what's the actual condition now what obstacles are preventing you from reaching that target condition and which one of those things are you addressing now and then what's your next step what experiments are you going to run so PDCA is called the Deming Cycle Plan-Do-Check Act and it's basically a statement of the scientific method we come up with an idea for an experiment we plan, we run the experiment, we do, we check we look at the results of the experiment and compare them to what our expectations were and then we act based on what we find and that may in most cases lead to another cycle of plan-do-check act so what experiments are we going to run to try and move towards the target condition that we're addressing right now and then when can we go and see what we learn from taking that step and so the improvement catar is something which is iterative we go through this loop of stages two, three and four pretty much every two to six weeks and so it's iterative in the same way that Scrum or whatever is iterative we have these one month sprints you can do this in monthly iterations if you want grasp the current condition establish the next target condition as a team where do you want to be a month from now and then don't plan how you're going to do that instead the people doing the work out how to achieve those now those target conditions they could be in the improvement catar as written here those are process target conditions it's how we want the process to look instead of getting good builds once a day we want to be able to get good builds ten times a day instead of it taking us a week to fix critical defects we want to be able to fix critical defects within a day those are examples of target conditions you might have in the process level this can also be used for product development what are the user behaviors we want to change maybe people we're getting a conversion rate of 2% now for our products we want a conversion rate of 5% instead of writing down you know epics and breaking them up into stories and tasks and giving them out to people doing that a great way to run a program at scale is for the leadership to state the target outcome they want to achieve in the next iteration and then rather than telling people how to achieve that let the people doing the work run experiments to try and work it out for themselves and that's the input to you know a hypothesis driven delivery type process where we specify a hypothesis and then you know run an experiment to try and actually achieve that which is what I was talking about in my talk yesterday and then the other thing to bear in mind is that as a result of doing this we may realize that the target conditions were the wrong target conditions if the target conditions produced the wrong behavior and within the organization then that might have been the wrong target condition to set and so we're constantly evolving our target conditions in response to what happens in the iteration and this is called double loop learning and it's the idea that we change our goals in response to what we discover in pursuing those goals and then that will cause us to update the direction periodically as well so I want to give you an example of an organization which followed this Hewlett-Packard so some of you will have heard me talk about the Hewlett-Packard laser jet firmware team in 2008 this team 400 people distributed across 3 different countries had this problem and who was here for the keynote where I talked about this okay a few of you so I'll keep it brief the HP laser jet firmware people in 2008 had this problem where they were spending all this time on non-valuad activity and they were only able to spend 5% of their time actually building features for customers and as a result of this they decided to completely redesign their software so they could work on trunk they independently reinvented continuous delivery so they came up with continuous delivery just by working out how to achieve better goals and they actually achieved a massive change in the economics of their development process massively reduced the amount of time they would spend on planning activities on porting codes and product support quality went up and they were able to massively increase the amount of time they spent actually delivering value to their customers these are the economic numbers so what I realized when I read this book and I read the Toyota Cata is that the way they had achieved this was by following the improvement Cata they independently reinvented the improvement Cata as well so this is a team that independently reinvented both continuous delivery and the improvement Cata which is pretty astonishing their direction they wanted to achieve was they wanted a 10 times productivity increase they had no idea how they were going to do it but that was their goal and the 10 times productivity increase and actually if you look at the numbers 3 years on what they achieved was in fact an 8 times productivity increase so they went from 5% of time spent on value added activity to 40% of time spent on value added activity so 8 times is not 10 times but it's still pretty good and the way they did it is the leadership did not know how they were going to change their process in order to be able to do this and after what they did is they followed the improvement Cata every month on the sprint boundaries they would not just look at the features they wanted to develop over the next month they would also think about process improvement and how they wanted to improve the process over the course of the next month and if you actually look at the book it's a really good book, really worth running really well worth reading this is actually a table of their sample mini milestone objectives so they called their sprints mini milestones independently reinvented all the agile practices they wanted to use but here's a list of their mini milestone objectives they wanted a quality threshold where priority 1 issues were open for less than a week level 2 test failures were fixed within 24 hours their rank 1 priority outcome was a quarterly bit release with final P1 change request fixed and when you look at this these are nothing other than target outcomes as the improvement Cata specifies and what would happen is that people within the various teams would get together and work out what the highest priority objectives were and then they didn't specify the methodology that the teams should use this is 400 people split into a number of small teams the standard approach to adopting agile within large organisations is to take the teams and teach the teams scrum or something like that and then we put structures over the top this is exactly not what they did at HP they did not tell the teams what process to follow the teams could follow scrum or can ban or waterfall whatever they wanted it didn't matter they didn't care whether they did stand ups or had burn up charts or any of this other stuff it didn't matter all that mattered is as a programme as a division as a whole were we able to achieve our objectives at the end of the sprint how you do that doesn't matter it's not important we don't change over time because we're constantly going to be evolving our processes and practices in order to be able to better achieve the goals I think the fabulous thing about the HP case studies is that they wrote it up in a book and it exactly fits what the improvement cat would be so this is, I'm out of time so I'm just going to make one further point which is that this is not just about improving your process this is fundamentally about growing your people because by following this process what the leaders are doing is helping the workers to learn how to solve their own problems and if you have an organisation where everyone is aligned on the direction they want to move in and the job of the leadership and management is to create a model which supports the people doing the work working out how to solve their problems and how to improve processes all the time continually so that they never stop that's how you build a learning organisation maybe we'll take one or two questions it was a huge investment but ultimately what they did is you're spending the same amount of money over here as you're spending here so the overall investment doesn't change what changes is what you're spending the money on on the left here we're spending 95% of our investment on non-valuad activities like detail planning like porting co between branches this is where your money is going and in most organisations this is invisible because most organisations don't actually divide up their costs by activity this is called activity based planning most organisations look at their costs in terms of oh we're paying for 50 testers and 40 developers and 20 analysts and we need to cut costs so maybe we don't need as many analysts or maybe we should fire some people because we have this cost based mindset in financial management and financial planning that's how we think we don't think in terms of doesn't matter how many developers and testers we have what matters is what are those people actually doing and how much of the stuff they're doing is actually value added so the investment might not necessarily change but what changed is everything else I mean they changed the systems architecture they implemented completely different processes and practices they invested in test automation they massively reduced the amount of time spent on upfront planning but the overall investment in the team actually didn't change at all it's just that they became much more effective at what they were doing instead of spending all this time your main cost in technology is people your main lever is staff costs and so you've got to start asking the right questions what are the people actually doing where's the non-value add activity how can we change our investments and change other stuff in order to improve that and the problem is most people's response to that is fire people, outsource stuff buy tools, adopt a methodology none of those things are effective that's why it doesn't work and that's why people fail at implementing agile I'm going to be around in the Thoughtx booth outside my content details are here please feel free to get in touch thank you very much for coming today