 Okay, thank you very much for coming along today. Don't get into the light. My name is Peter Brown Elm. I work with one of the co-founders of Code Positive, a Drupal agency based in London. And, yeah, I'm here to help you learn about saying no. A small disclaimer on this fact is I don't think I'm very good at saying no. I think it's one of those characteristics that I have very slowly had to develop. And so this talk today is as much my learnings over my time as a developer and manager as it is any practical understanding. I don't claim to be an expert at this, but I am actively trying. And most of what I plan to cover today is related to work that we've done for various clients, some of it more successfully than others. So I hope you're better with me. You're welcome to ask questions as we go, although I've made a rather ambitious talk for myself now, so hopefully we'll get to some proper questions at the end. And then, you know, I'm around until Saturday morning. We've got lots of time for questions if we need to. So there we go. Yes. I've been a developer for about 30 years, professionally for 20. I helped found the UK Drupal community more than 10 years ago. I've been part of a few startups over the years with various degrees of success. I've tried to give up being a programmer and focus on the organizational process to actually, you know, design software and get good software design, well, good software planning done in the first place. I still get around to doing a fair bit of programming now and then. My company is Code Positive. I'm one of the directors, Robert, my co-founder is in the audience over there with his camera. We've been working for a long time in various fields from London. We've worked with many charities, including Greenpeace and Save the Children and Christian Aid. We worked with government and a number of enterprise clients like SagePay and WorldPay. And WorldPay is one of our current clients. It was the largest IPO in the UK in the last year. So they're not an easy client and we've learned a lot from them. One of the specialities of us as a team is that we build things at last. We've built things a lot for a long time. And building Drupal sites at most last in practice for about seven years has meant that we had to work quite hard at this idea of saying no. And we've now realized that the whole process of saying no and building good things at last requires that we get involved and change the organizations rather than just designing the software. Over the years I've done a lot of training. When it comes down to it, pretty much all the training we've done to help anyone understand software has only had one important fact. And that is say no. That's it. Summarize my guidance to anyone wanting to build some technology. It's always been just say no. That makes life much easier. But there's more to it than that. But I will get some backup. So your job really, if you're going to build good software, especially good software that lasts, is saying no. And you have to say it over and over again. It really is the most important thing you need to learn how to do. And Steve Jobs has said that many times and it was for him one of the foundations of Apple's success. Apple says no. And you say yes only when you have to. There's a problem with saying no. And I was reading about this while planning for my talk. Humans don't like it. We are psychologically, perhaps even physically biased against no. When approached with different options, some negative, some positive, with the same level of intensity, humans are afraid of no. Our brains focus on the negative. It means that if you have to say no a thousand times, you've got a lot of work to do to help yourself not be seen as a blocker, to not be seen as the one who gets in the way. And you have to try somehow to not be negative. Saying no and being negative are quite different things. And so perhaps that's the art. And that's the process of saying no with the second half of the title of the talk, which was without saying no that much. And really you've got to do some sleight of hand. You have to follow the process of saying, you know, pick any card, but then making sure they choose the card you've chosen for them. And I had planned to actually try some sleight of hand magic for you tonight. The last time I practiced my sleight of hand magic was when I was about 10. I would have embarrassed myself. But I did spend some time practicing card tricks. I have decided to, you know, take a different route. So if you're not going to bother with the rest of my talk, I'll give you my summary now. Although we can learn to say no as a personality trait and just say no straight to someone directly, really in practice saying no is a gem. You have to start with yourself, start with the tech team, and then slowly move out through the entire organization. So we have to say no because people are asking for the wrong things. So you're a German and a long run. To slowly reduce the amount of no you have to say is to start changing the way in which your clients and your organization thinks about technology and thinks about what it wants to achieve with technology. It's quite a long process. But there are a few steps to it. Each one feeds into the next and each one feeds back into the previous one. But you said in my story today, I'll take you through the various steps that we have to go through to achieve a level of reducing the amount of no that we have to say as technologists in some form. So I had planned when I originally presented this talk and when I proposed this talk again here to have a rather technical presentation. I had a number of graphs. I had some pyramids of decision making structures and that sort of thing. But in thinking about Steve Jobs as a thousand no's and realizing and saying our negativity bias, I realized that the process of saying no is a universal one. It's not just about tech. It's about any endeavor, anything we want to achieve that is big and requires focus, requires this art of saying no. Staying no pisses people off. It always will. It will make you enemies. It will make you opponents. And you have to really work at that and you have to accept that that is going to happen. So when you are the doombringer, the naysayer, the one who says you can't have that shiny thing on top of your website. The one who says no, we have to actually stick to the patterns and stick to the rules. People will get frustrated. So I realized that you need more than just a plan. You have to actually be a hero. You have to take a whole hero's journey that's far more than just a few actions, a few techniques you have to learn. It requires consistent persistence to get success. Perhaps like Dries' keynote. I'm going to rephrase Dries' keynote as the hero's journey. So one of my favorite books was Joseph Campbell's Hero with a Thousand Faces, which is an amazing story about how, well, published in 1949. It's not really a story. It's a story about the stories. It's the mono myth, the fact that if you look at all the major myths in society, you can possibly boil them down to a single story that begins and goes through a series of events that ends. And you find the same story in many religions and many myths and most famously in Star Wars, which is very explicitly based on the hero's journey. So I have done a number of talks with the Star Wars theme. I'm not going to stick with Star Wars for long on this one. I'll move on. So here we go. I'm going to change my talk. The story of my talk, the title of my talk is no longer How to Say No, but becomes The Hero of Thousand Knows. And so I'm going to reboot and go back. Instead of giving you a nice set of triangles and practical, technical analysis of why no works, I'm going to now tell you a bit of a legend and a story about some characters and a good adventure story. I am immediately breaking my Joseph Campbell journey of the hero and mixing my archetypes. And I'm going to jump and use a lot of tarot archetypes in this one as well because it also tells an archetypical journey. I've fitted more into my talk for today. So here we go. You have the great evil in software, in technology, in any big endeavor, in any great story. You must have the grand villain. We shall not even say our villain's name. The villain is there. This is the villain we must fight and so you defeat. This villain rules our world today, especially in a technological environment. So, yes, bear it in mind, we have to defeat the villain. And we begin in the wasteland. This wasteland is the place we're ruled by the grand villain. When we have a technological environment where the villain is the one in charge, where everything is possible and we just continue to add new things in and we randomly change our scope and we randomly add pieces to our spec, we end up with this incredible wasteland. We end up with ruins and half-complete things and traps and dangers and trying to fix something means you break something else. And it's this horrible place where everyone assumes that if you're a coder or you're part of the tech team, you're a bunch of monkeys because everything you do breaks something else. And, you know, why don't you do this? Come on, it's easy. You said it was easy and now you release it and you broke all those things. That's what happens if you just allow the great evil to win. Technically, that technological state is known as the big ball of mud. If you add great evil word after great evil word on top of your plans and you keep evolving, you simply get a great big tangled mess and you can't fix it, you can't adjust it, you add more to it, you can paint it, you can make it look pretty, you can put some facades up, you can add some shiny trinkets and maybe some, you know, whizziness here and there. But it's a big ball of mud and it gets you nowhere. So we have to fight the great evil and our hero's journey begins. We have to understand the power of no. And we begin with our hero, someone, a lone person in the tech team deciding to face the great evil, to head out and change the way the world works. And so this is the hero who has to now not be seen as negative, but take charge and say no. And there's a process for establishing credibility and a process for saying no, is that first of all you have to have your own power. And if you represent the tech team, if you represent a project manager, you've got to go out and be able to say no, because this is how we do things. You have to start the beginning process of establishing some kind of credibility, establishing some trust, because a lot of the time when people fight you and people are asking for these random things, they don't really trust the techies. They don't really trust that the developers are already able to get what they want. They just think that they're in charge and they're going to tell you what to do. And you have to do it. You have no power. You have no ability to actually manage your project. You have no skill for doing it. And so the first step to saying no is establishing your own power. The tech team, project managers, whoever is in charge of some tech project must be able to very clearly say these are our tools and this is how we work. If you can back up your no with practical reasons that say, well, yes, we're going to work in this way. We're going to make sure it goes to the development environment. Then we're going to test it. Then we're going to release it. We have a testing process. Here you can see our backlog. We've got analytics. We can watch what's going on. You can first establish a level of competence. And people need to see that the tech team is competent. And too many times I'm going to bring it up again because I thought I could give up on it. And every time I go visit organizations, I keep finding this reason's head. The first thing that a tech team needs to do, programmers need to use get. Use some form of source control. And unfortunately, I keep discovering programming teams and companies where no one actually manages their source. And so I'm going to bring it up again because it's a major peeve. And the fact that these basic tools are often not there. And there's no way you can establish any kind of credibility if people don't trust that you can deliver anything. And if you don't use the basics, you're never going to get there. The next challenge that a tech team needs to face is you have to not be the grumpy techie that sits there and says, ah, can't do it. Give me a proper spec. It's not clear. You have to manage the interface saying no cannot be this frustrated technical response. So if possible, you need someone who can understand both the business and the tech and the users to be able to act as an interface. You've got to have a clear way to communicate and make sure that you're not responding with pure negativity. When someone comes along and says, can you do this? They generally personally believe that's important. It's something that they already want and they feel will benefit the company, the project, whatever. And if you just say no, you immediately hit the negativity bias who is important to them, you throw a no in their face, they get frustrated. And then if you keep saying no a thousand times in a grumpy, unempathic way, you're going to create a scenario that means that the organization hates you, you will be kicked out. You'll be fired, you'll be replaced. Something will happen. You cannot exist in that environment where you are defending everything against an organization in a negative way. So you have to understand the basic empathy of saying no. And the first step that if it's your responsibility to handle this interface is you need to understand how to respond. Simply first empathize. First say, yes, I understand. I see why you need that. I'm sure someone may find that beneficial. But it's not going to happen right now. We'll add it to our backlog. You have to be able to manage some kind of de-escalation and keep away from confrontation whenever possible. And so there is a bit of a magic that happens when someone takes on this task and they're new. And the magician is about being able to begin, well, the magician in the tarot, is about beginning something new. And the power of actually entering an organization without any knowledge of the complexities of what's there and just saying, no, we're not going to do that. It's obvious. And if you're not new and you're still trying to take control, it really makes a difference if you can actually tell people in some nicely written email with a clear proposition, things are going to change. We need to do this. It's going to help us achieve our goals. I need you to start following these steps now if you want to start interacting with the tech team and adding new features to our software. It's just a basic assertion. As long as you have your team in order, it will allow you to make a very big step and change the culture with a bit of an initial push. But that only lasts for a little while. You can fake it. A lot of that beginning might just be pretending that you can do it, pretending your confidence, faking it to make it. Because there's no way you can get your tech team house in order in an instant. And the only way you can actually get your team in order is by having the space to actually think about things and actually do things right. And if you're in a situation where you have this great big ball of mud and all sorts of requests coming in all the time, there is no time to think. You're just stuck in a firefighting mode. You're constantly responding. Everything just perpetuates itself. You buy a little bit of time by now saying, we're going to change this. Here's a new process. But I'm not going to last that long. People slip back in the old ways. So you have to get your defense in first. You've got to actually dive in there and start planning for the future. And so our magician, our hero, has to go and find the priestess. And the priestess has the gift of foresight. She can see the future. And one of the key tools you need to be able to manage the no process and by not saying it by sleight of hand is the roadmap. There's lots of time we talk about agile, not medium roadmap. We're just working with backlog. We're going sprint by sprint. But if you just have a backlog, especially if you're working in an environment where people and the organization you're working with doesn't quite understand what they're asking and you're shoving everyone's request into a backlog. You just have a giant mess. And what I've seen and what I've done many times is a kind of January the first day back of work, find all those tasks, you never go around to doing last year and delete them. That's generally the way you manage your backlog if you don't manage your backlog. So it's the nuclear option. A roadmap is a different story. A roadmap helps you see the future. It helps you get people thinking and get their ideas out, make them feel that they're being listened to and you collect their ideas. It can be as simple as getting people in a room, post-it notes on a wall. It can be more advanced. You can use the story mapping. You can have some techniques to it. But really, in practice, your job is to sit down and to listen, to understand the state of your organization or your client, to understand what their vision is and to show them that things take time. We are generally promoting agile methodologies and time matters. We're going to release and evolve and update. If you just have a ball of mud and you're never going to update it, you can just paint it. It doesn't really matter. No one's going to look any closer. The facade is fine. But if anything needs to last, you need to be able to take time into, well, yes, to actually plan for time. So ask why, collect ideas, get down to the reasons, layouts, a thematic roadmap if you can, group ideas together and say, ah, well, we can think about this and this and this. And let people see that they've been listened to, make your roadmap visible to the organization, and then have a very clear process by which ideas come in from someone who's quite excited about something and they say, ah, yeah, wouldn't it be great? I saw our clients had this or our competitors had this and let's add this. And you have to guide them carefully to understanding time, scope, and the effects on the business and all the other consequences. And so being able to clarify a request process makes a big difference. And we found that we're using product management software now. We sort of teach our clients to say, think about your website as a product. It's something that actually does for your business. We separate our tech backlog from the client's ideas list. My little QR codes that I've scattered throughout my talk, if you want to try them out, we'll take you to various locations. There are a number of different product management tools you find online. We use one called ProdPad. There may be others that are better. And they just help keep the conversation about new ideas and possibilities out of your backlog. And so we can talk about things that really welcome ideas and slowly evolve them over time. We don't have to go to a separate breathing room, so we don't constantly have to fight back and push all the time. The basics of metrics get very become important. We talk a lot and people have lots of ideas about what metrics and analytics should do and that sort of thing. But really, if you're starting from scratch and an organization doesn't understand it, it's very hard. It takes a long time to establish a culture where you can measure things and get beyond bounce rates and hits and that sort of thing. But when you can start getting people to show, to say, okay, this feature is going to be measured by the number of sign ups, by the number of things over, the number of people clicking this button, you can start to actually get people thinking about how they will affect their, well, how your metrics will affect their plans and how their plans will affect the business. And that's a very important process to buy yourself time. So in our hero's journey, the magician works with the high priestess and the two of them use their powers to now start taking on the outside world. And the first thing they have to work with is they need to get a major ally. And the first ally they need to work with in the great myth is the Empress or the representative of the natural world. And if you're running a project, a website, particularly one that must last, you've got to start managing the no process, managing the resistance by limiting the options. In the natural world, which the Empress represents, there is constant change. There are always new things, but there is also consistency. So your job is to start establishing consistent foundations and allowing the process of no management to be constrained so that people aren't asking for every possibility. They're asking for realistic possibilities that you know you can cater for. So you can take them through that pick a card, any card process that reduce the number of possible options they have. So the first step that we found we need to tell people to do is to think about their users. They're coming to you with all these ideas because they're thinking about features. And that's where you always have to counter things with saying no. So turn it around, get them to stop thinking about features, start thinking about what their users are going to need to do. And so start teaching the people you're working with to follow a user-centered process because that means you can ask the kind of question that's saying, that's nice, who's going to use it, why do they need it, how important it is to them. Lots of organizations seem to be afraid of personas, they think that they have to hire an agency that's going to charge them thousands of pounds to come up with these personas and they can have posters on the wall and do market research and stuff. Maybe that's a very valid process for creating personas for some kind of organizations but in practice to start with just sit down and write down a few notes about the people who would be using a website or any other bit of software. I don't quite get why we've made personas such a hardcore, scary thing that almost every client I've dealt with seems afraid of. You just got to make it something simple and say, let's get them done. Once you have personas, then you need to start working on a style guide. You've limited the kind of feature request and the practical functionality you're trying to build by telling people to focus on their users. You're trying patterns and limitations visually because when you have people coming along and saying, I want this new page or I want this new feature, most of the time they're thinking in terms of pictures. If you're not a techie, if you're not a programmer, if you haven't worked much with websites, you're still thinking in terms of something visual. So a style guide gives you the ability to constrain the design process and to work with someone in a way that they understand. This is hard work. We've only half managed to get them done for lots of our clients, but they still make a big difference. And the more complex one you'll find a few talks on here is Pattern Lab, which talks about atomic design, which if you can get right, allows you to take your designs from tiny little pieces up into ever more complex elements so that when someone says, I want this new page on the website and you feature, you don't ever go back to a designer. You just pull together pieces of a puzzle. You have all the pieces. You just assemble them. And so someone says, I want this. You say, great, choose a page layout. Good. Choose the design styles that you want for your teasers. Choose this, choose that. Often if you've got a style guide with semantic rules, they don't even have those options. They can just say, we're going to, you want to do this, you're linking to these things. You have rules that say, our website will always link to this kind of content in this way. Then they have all the options they want, but they only have one or two, really. You can very quickly constrain the kinds of options people have, and they can very happily feel that they have some kind of power and control. Sometimes they'll be grumpy and say, ah, but I want this and that. But really with a little bit of practice and people realize that you are really empowering them to design pages without you, especially if you give someone a style guide in a format that they can play with. Our clients can go and they design the pages themselves, come back to us, and there's no designer work. It's all done from the pre-designed pieces and the puzzle set that we have given them. So style guides are very important. Having consistent building patterns. When you display a listing of a certain type of content, when you display a certain kind of teaser or a relationship with things, why do you want to reinvent the wheel? You want to just have a standard set of patterns? Say, alright, that's called directory. A directory works like this. We're going to have a new kind of content. We're going to have a listing. We're going to have relationships with them in these ways. So standard patterns work pretty well. The way that we found has made sense for us to start building patterns as we've learned to the team to use BAHAT and other forms of testing is we found that specification, by example, is a way of bringing your testing into a human language upfront and slowly writing out our build patterns at a technical level as a series of assertions that we can then build automatic tests from. So it's a long process, but it has been very powerful for the team to slowly start being very consistent and having your testing done upfront in a language that's understandable to the client. So BAHAT is very useful. Specification, by example, is one of the more complex or the higher level implementations of something like BAHAT or any kind of behavioural testing. Once you get to this point and if we've established some metrics before, we can begin to optimise the patterns and style guides. You then have the ability to actually measure whether a change in the layout of some page will have a positive or negative effect and you can adjust your style guides accordingly. So you can slowly evolve and optimise a project. Even if you've spent your time getting yourself aligned with a natural order of things and you've put all your effort into style guides and good processes and patterns and you have the impress on your side, you're still going to have to deal with Hippo. So if you don't know what Hippo stands for, Hippo is this incredible decision-making system used by most organisations called Highest Paid Persons' Opinion. And that's how most decisions within a software project get done within a large organisation. And when Hippo's rule, you as the tech team at the bottom are going to have no way to say no. You can't say no. The boss has said, we're going to do this. We're going to launch on Friday afternoon with this whole new feature that we were only told about two days ago. The boss says it, no matter how much we complain, it's going to happen. So you have to get past the Hippos. No matter what you do technically, the Hippos will take you down. So your job now is to get the Hippos on your side. You've got to go and start talking some management speak. You've got to talk to the emperor. He's over here. And the emperor likes to make rules. And the emperor feels powerful because he's in charge of the rules. So you have to start working with those who might be the managers, who might be the bosses, who might like working with the rules, and tell them that now they have the authority to make some new rules and to really start achieving some return on investment and some major technical achievements. But they can only do it and if we establish some rules, and they're the ones who should lead that charge and help you with some processes. This is generally another task of manipulating egos. But often you'll find that people really do want to build good software. They just don't know what it means. And your job, as you slowly evolve outwards from solving technical problems to dealing with aesthetics, now becomes dealing with the way in which the organization as a whole chooses what they want to do with their software. How do they make decisions? How do you say this idea goes in? This one's more important than that. And so you have to look at decision-making processes. And then you can say, great, I like your idea. We have this nice process that helps you flesh it out and the boss has said you must follow this process. Within a large organization you need to get these processes in place for any kind of asset that must last. You've got the governance of the images that an organization will upload into its repository on your site. It really should be in place. Otherwise, in a year or two's time you have this giant mess of digital assets that no one can properly manage. And so data management and data governance is something that you'll find referenced all over the place. Lots of people will talk about it. It's very easy to talk to your clients about governance. Actually getting them to introduce and adhere to governance is much harder. So we are definitely expecting our hero to be much stronger and far bolder to be able to take on the hippos. A very useful tool. And in fact, many of the tools and books I'm referring to now have been advanced and pioneered by a man in the UK called Paul Bogue. And he has been one of the people behind the UK government's digital service manual. And I admit to being a bit of an anarchist and having spent a lot of my life fighting against the powers that be. But in the last few years I have generally been recommending the UK government's documentation on how to build agile software as the best I've found and the best way to deal with your clients. So the digital service manual is, well in this case, a process whereby you sit down with your organization, with your client, and you write down what the website's going to do, who the team is in charge of it, how they're going to work. And you produce a manual and a guide that will establish your organizational boundaries as a tech team. And you go and you say, all right, when you want something to happen, these are the people you're going to speak to. Just be clear, really start working within an organizational framework and establish this policy, make it written down, make sure any managers know about it and get them to buy into it. If they see you as an authority around the website, you are then able to say no and start working with management in terms of peers. They feel that they've helped establish a center of power and then it's much easier for you to stand up to them because they have ratified and approved the various rules that you've put in place. They've seen your guide, your manual, and the company starts to know that this is the way in which things get done. Again, I've stuck my, I've tried to be clever and stick all my links in this talk and work into my QR codes on the bottom. I may have failed because I did realize that my attempts to use my camera to photograph something with two QR codes meant that I didn't get anything working anyway. I have a link in one of my QR codes there to Paul Bogues guide for creating a service manual if you want to try to find it. The next thing that you have to work on, and this is something that we ourselves are now actively trying to learn, is how do you convince an organization? How do you allow an organization to understand what testing and optimization really means? Because although people will go and say, yes, we want to test it, yes, we should optimize that, if the management doesn't buy into that process, the management still feels that they can just make a choice and it'll happen no matter who decides what, no matter what your evidence says, you're not really getting anywhere, you're not really able to establish any kind of real optimization process. Well, yes. So working with management and working with the tech team, creating some kind of alignment that allows you to go back to people who have these ideas, going back to management and saying, let's test that idea and see. When they say, I think a pink banner will work better, they say, hmm, let's come up with an experiment, let's see if it works. Testing can be trickier if you have, you know, low traffic websites, these kind of tricks work better if you have more and more traffic and that's the thing. But there still are ways to try things out and there still are cultural changes that you can put in place. They allow people to see things as hypotheses and experiments so that you're not randomly making decisions and that you don't have to go and tell them no all the time. You can have a process that allows them to come up with ideas through a limited style guide driven process ideally and pushes them towards actually optimizing things. We've been looking at Optimizely's testing toolkit. If you Google for that one, they've got a handy set of guides that say, you know, he has how to make an experiment, he has to formulate your experiment. Little tools that you don't have to use Optimizely for, but the process of being, of experimentation and coming up with AB testing and optimization is something that requires education and if you can get an organization to understand that, you've got a long way to managing the nose. So, the next step, once we've managed to get processes and policies in place, we've dealt with the emperor. We now have to deal with the high priest and the high priest is the powers that be those who are in charge and are connected with the underlying values and the morals of society or just the CEO and the board. And if an organization's main management of the CEO and the head of sales and head of marketing, wherever they are, don't actually care about what you're doing and they feel that the website is simply something that sits outside of their actual business and is, you know, it's a marketing thing but isn't really tied to the core of the business. You're never really going to, you know, solve this problem. They will still come along and come up with conflicting requests. Priorities will, you know, switch and your beautifully crafted tools will be ruined by the great evil because some even bigger boss changed the organizational plan and all your carefully laid out future comes falling down. And so here what we have to do is start helping people see that the business itself is now being influenced by your methodologies. Agile is one of those, well, the Agile methodologies and the way they do things is contagious. If you start building your tech and your tech team works in an agile manner and it starts being effective, the organization then starts to benefit from this and sees how it works, you start training the organization and they start responding and understanding how you need to do things. So at a business level, the startup guides, there's startup philosophies are very valuable here. Lean startup lean startup process, the movement of using optimization and theoretical experiments to design your business is very valuable. We've learned a lot from strategizer.com and their books on business model generation and value proposition design, really taking the tech ideas and now fitting them deeply into the business and what the business is going to need to do. We've had some success with clients and helping them and the charities, this one's a bit easier because charities often have a real mission statement and they spend a lot of time writing down what it is they want to achieve and if you have a kind of client that has a good mission statement, getting them to write the digital version of that statement that says how they will apply their mission statement in a digital manner is very effective and had a significant impact on the organizations that we were working with. The idea here is that you've got to get people to see the website and the digital ambitions of you've got to get the digital ambitions of your client or whatever organization you're working with to align with its business ambitions. Only when you bring them together can you really get to the point where first of all you start getting real return on investment. The company starts understanding our investment in our digital platforms is something that really means something to the business. They understand time, they understand the details and the deeper value of it and you start getting a website and the software which is a real platform. It's something that influences the business. They'll change the platform, solve real business needs by adding new functionality to the platform and then that will change the business and you'll have this really energizing loop and it'll go around. Once you get to that point once you get an organization to align its business with a digital process and to see digital as being part of the business then suddenly the great evil isn't there anymore. You can say yes because you're not fighting a system that's constantly trying to undermine the quality and the value of what the tech is trying to bring. So we now have the card that follows the hero fan or the high priest is the lovers and you're now able to combine the ambitions of the digital and the practical and you can bring all these different areas together and you can start really building an organization that works with but not against its tech. You are building a symbiotic technological system that changes the business but then changes the technology and that process really starts accelerating the way in which the business works and changes. There's some great work that Paul Berg has done here a very handy book that we recommend and make all our clients read it's called Digital Adaptation and it's actually aimed at tech people who have to convince management and other parts of the organization what they have to do to change an organization to deal with technology and to use technology effectively. So when you can work at this level when you can get to the level your story can get rid of that great evil and you're able to see this process of saying no actually being one of building up to a bigger and bigger yes then you have an organization that can actually become agile that can really welcome change which is our agile manifesto line number two it's welcome to change and really work with it and yes then the organization can start really asking the right questions and your need to say no starts to fade and once we've done that we move on to the next level in Tarot the next car is the chariot and the chariot is this ride into the unknown because once you've transformed an organization and you have an organization aligned with this digital strategy and it's moving forward suddenly those old power structures start to struggle and you can't have this command and control hierarchy because it can't adapt fast enough and so we now have the arrival of new forms of running the organization new forms of decision making if you look at the book of reinventing organizations by Frederick Lailou he's brought out this concept which you'll find a number of talks here today on this conference on teal organizations and how do we really take the idea of these decentralized agile organizations and make them very effective and very powerful and the interesting thing here is that when you start dealing with decentralized organizations all this process of fighting against the system which we've had to do to this point starts fading away and teal organizations really have to start dealing with personal change and personal transformation and so the idea of us actually not wanting to be in a situation where we're in control of our lives and able to properly work in a self-managed, self-organized way is the main thing that gets in the way of these organizations that try to get rid of their management which is kind of what you feel you have to do when you really want to start using technology and real agile says Scrum Master is not the boss Scrum Master is that servant leader or someone who just appears that's helped to clear things out of the way and then the entire organization gets rid of its bosses and who knows where you end up and this really rapid energized organization that's transforming all the time really is taking us into that so-called fourth industrial revolution which was Andres' keynote last year about the real social changes that are coming about from these organizations that are able to transform themselves to really work with a digital environment in an effective manner alright I'm approaching the end of my time so I'm going to go back tell you what I've told you the story of this hero of the Thousand Nose doesn't end here unfortunately it's just the beginning it keeps going it just becomes something far more different the middle part the trilogy gets much darker the next phase once you reach the end of part one means you've got it well yes it comes another time but for now let's stick well with a happy ending of part one where we realize that no is about boundaries about having clear scope about having vision and understanding priorities so you can start getting things out of the way and not focus on being negative Thousand Nose really is about saying yes and it's really about innovation and really focusing on what matters quick summary of my process so far is that you can't say no if your team doesn't know what it's doing if your team is not feeling competent and not seen as competent you're not going to get anywhere if people just undermine all your decisions because they think literally in some organizations one of the companies I worked with the development team was called the Monkeys our first job was changing the terminology used so that people started respecting their decisions a bit better people within the organization must feel that you share their vision and they must share yours road mapping and that process of listening is very valuable consistency within software at every level at your design level, your build level is vital and consistency is a tool to fend off those random requests Governance, no organization can really manage its tech without proper governance and those governance and decision making rules will remove a huge amount of that organizational friction that tries to push you to do things that have no business value they just seem like they're nice to have eventually the organization that you're working with needs to see digital as one of the if not the first thing it does a very key part of its actual agenda as an organization there are very few organizations that can operate in the coming let's say decade that do not really approach that can survive without taking on a digital first approach they must say how do we sell this online and how do we do this using tech tools first and that will mean that they care about the quality of your work and they care about the quality of website and the need to say no should vanish because by that point your organization has adapted to the digital age it's able to really take on the right systems and solve them in the right way and then you can begin the second part of the adventure there's a big library that has gone into the various ideas around this there are a few of them there some more technical than others then some word from our sponsor the slides that we need to put in sprints on Friday get to know them feedback thank you for coming, I appreciate any feedback the first talk I've done Drupalcon that hasn't mentioned Drupal which is an interesting change for me having done Drupalcon for 10 years so any feedback on my random esoteric meanderings will be useful and if you are interested in any other conversations I'm available the QR code may work I don't know if they've worked no, it didn't, fine I thought I'd try, there are various Easter eggs in the talk but if the QR codes aren't working then I'll try again some other way thank you yeah, good we have 10 minutes I can take some questions now in public or just hang around afterwards yeah, good, alright side with the books okay, I'm going to quickly get back there there you go