 Hello, Athens. Hello, Willie Bay. Thank you very much indeed for inviting me along to talk to you today. My name is Ant Miller and I love clients. I deeply, deeply love clients. I love engaging with them. I love other people's problems because in the agency one, I've been working in agencies now since about 1990, a while, and agencies where I'm from. In fact, so this is what the talk's called, the Fidelity Gap, yada y yada. This is where we are. That's who I am. A little bit more about me. That's me. It's a photo from Bangkok. Bangkok was such a good word count. God, that was amazing. So that's what I've been doing there. A long time, too long. That will work tomorrow. If you take a photo of it tomorrow, I'll have this talk on it with the typos corrected. I've done all this kind of stuff. Tended to work on fairly large stuff, but not exclusively. I've done freelance. I've done both sides of the agency-client relationship. These days, I'm director of client engagement at Crowdfavourite. Most of you are focused, but pretty much international. We're a press agency, but not just that. We do a lot of Laravel as well, basically doing open source bills. A bit of design as well, but mostly builds. What I'm going to talk about is, well, so you think you've got problems? You do. Let's be honest. If we're working in the agency side or a bit freelance, what are you on the client side either? We think we do have problems if we're honest with ourselves. It doesn't all go smoothly. Sometimes it goes horribly wrong. Sometimes it goes a little bit wrong. Mostly it's a bit up and down along the way. I've seen that over the years. I've seen many of these things that we quite reasonably call problems. Problems like scope creep. Everyone's fairly familiar with what scope creep is. I'm going to be a bit weird here. I'm going to tell you that scope creep doesn't actually exist. We'll get to exactly why in a bit. I'll explain how you can do stuff about that. But scope creep, for a couple of reasons, I want you to be ready to think of that as not actually being a problem. It is a problem as in it's a thing that goes wrong, it's horrible, et cetera. But let's be flexible about how we use the word problem. I also want to be flexible about how we think about another thing, which is a real problem, and that's burnout. The previous thing I was talking about was something quite commercial. This is real. This, I'll be quite honest, I think destroys lives. Professions are ground into the dirt because of this. People who were stars in their field, absolute streaking across the feminine. We looked up to them, they enjoyed the limelight and they did awesome work, have seen their capabilities really drawn down and it takes such a long time to build up again. But the way we think about this within a project as burnout as something we can fix just as burnout isn't actually useful or rather might be useful to an extent, but I think I've got a better way of thinking about it. Don't worry, I'll share that. Other problems, well, client antagonism, that's maybe all of us have had a QBR or a client meeting which has felt a bit like this. Those relationships which started out as, I don't know, almost like a honeymoon romance when we're putting the sales pitch together and we've got the kickoff meeting sometime like eight or nine months down the road because of the things we've just been talking about feel more like that and then worse, we get the survivor mentality. Now a few colleagues from my erstwhile human made days might know what I'm referring to with a mug, a little sidebar here. We had a project which had been very difficult and had all those other things which I've just talked about happen in it and we made up mugs which said I survived client X, all in client X's font and look and feel and that was a terrible, terrible error on my part. That was an awful thing to do. That's basically setting an us and them situation up. I'm telling my team and my client, well, not telling my client but they might have got wind of it, I'm telling the people that I work with that this is a combat situation, that you are there to hurl yourself into the breach and break yourself and here's a mug because you got through it. That's not a healthy way to be. And of course the clear thing behind all agencies trying to do with all this is in the end we spend more money than maybe we're getting from the client. We spend up having people who are putting more hours in than we've been scheduled for and frankly that is not good commercial sense. This problem over delivery which again if we only fix over delivery, like if we only fix client antagonism as client antagonism, burnout as burnout and scope creeper as scope creep, they are not problems because frankly the key thing to remember is they're not problems, they are symptoms. A problem if you really want to think about as a problem is something that you can fix. I told you I like clients, I like being in an agency, I love it, I love their problems because those are things that I can fix for them. I can build them a solution, I can put together an engagement, a relationship and that will deliver a solution. But everything I've just told you is that if I just deal with it at that level I'm not getting to it, I've got to get underneath it. And there is something that lives underneath all of those things that I've talked about. And it's from 20-something years of standing back and looking at all. I'm going to share with you what I think it is and you can take this and run with it and see what you think of it. I call it the fidelity gap. This is a word I've chosen quite carefully and it's a model I've thought about quite carefully as well. And essentially it's the real problem and the best definition I can come up with it or the most poetical one I can come up with it is this. It's the gap between what the client knows they need and what you as the agency need to know. And that gap is real and it is profound. And I use the word fidelity for it in a very particular way. Fidelity has got a number of different meanings. You're probably all thinking about fidelity as a word right now and you're projecting in different directions with it. Bear in mind that difference because that difference between you and the person next to you for what fidelity means is kind of the point I'm trying to make here. Fidelity means accuracy. It means it's very how specific is it, high-fi, high-fidelity or it's about having a very accurate representation of sound. Fidelity is also about loyalty. The fidelity this dog has is amazing. It's an amazing dog. It's a very good son. It's an amazing dog. The fidelity that a dog has is incredible because it's true to you. Remember the year in the United States Marine Corps motto is semper fi. It means semper ffidelis, always loyal, always true. And it also means honesty. Something which has got a truth to it. Infidelity is a lack of truth. So accuracy, loyalty and honesty are all parts of this. But I've got a really, really sad thing to tell you, I'm afraid. And that is you cannot close the fidelity gap. It exists. It is a fundamental feature of the relationship between two people. Somebody who wants something and somebody who wants to build a solution to meet that problem. It is there. It is part of the landscape. You cannot close it. And actually my contention is all the problems I've just talked about are what happens when you either ignore the fidelity gap. Or you try and force it closed. Scopecreep is what happens when we just go, oh yeah, yeah, yeah. No, that's exactly what I want. And then halfway through we go, yeah, well actually I just, that's exactly what I want still. The client never thinks of Scopecreep, do they? The client always thinks they're just giving that little bit more information, that little bit more detail about what they'd originally said. They started off with a really loose sketch plan and what you thought it was dealing with some sort of beautiful autocad diagram. That's where Scopecreep isn't a real problem. It's a feature of this gap not being acknowledged right at the start. You don't know what all the requirements are. And you can't kid yourself that you do because if you do think you've got all the requirements, then you get Scopecreep. Similarly Burnout is what happens, I think, when you have something which still needs a lot of designing doing, still needs a lot of exploring doing, but you've gone straight into delivery and your engineers have put on the spot and said, right, there you go, deliver this thing, build this thing. And then you've got a senior engineer or maybe even a junior engineer who's sitting there trying to figure out design problems day in, day out. They're not sitting there encoding. They're going back to the client and going, when you said you wanted this page to have that on it, what is that exactly? Or you took this design pattern and it's like, there's no patterns here for the video player page. How am I going to make this work? What do your search results look like? What does alphabetical look like? All those design questions, we give them to engineers who don't have design technique, who aren't given the space to do design, don't have the skills and the experience, and then we dump on them from orbit for not sitting there at the code face and making pull requests when they should be doing code. Of course, at least the Burnout. You've put them out into the wilderness with no tools to get back into the wild and it'll crush them. So we've got this problem, this gap, and I've told you we can't close it. I've got good news. You can bridge it. This is what I've got to tell you about today. Bridges. So what do we know about bridges? Turns out as a metaphor, this is really, really powerful because bridges have several features that we can map onto our relationships between agencies and clients. We can think about the problem. We can bear in mind the fidelity gap as we go and we can build successful relationships that grip risk, that grip a lack of knowledge, that grip uncertainty and build something awesome. Right. First up, bridges needs foundations. We've got to have something really solid to build our bridge on. We have got to have firm footings on both sides of the gap. Those need to go right down into the bedrock and they need to be solid. In the metaphorical world, what I'm trying to say there is each party to a relationship needs to know themselves and has to be honest with themselves. You've got to really know what your agency is about. What can you do? What have you done before? What skills have you got inside the agency and what can you stretch to safely? What can you stretch to with a bit of risk? It's okay to have foundations that go beyond what you've done in the past as long as you know what those are and be honest with yourself about it and push your client to do the same thing as well. Of course they've got stuff that they cannot do. That's why they've got an agency in. But just be really clear on both sides of the equation about what the limits are. Don't kid yourself that you can be something that you're not. It's not going to work. Eventually this glasses and that nose falls off and the pug isn't what you wanted. So you've got to be really honest with yourself at the beginning. Know thyself for that is a great foundation for a bridge metaphorically. Right. The next thing I want to talk about in this bridge model I was wondering to think about the span, the load bearing aspect of a bridge. Let's think of a classic bridge. I didn't actually do it. The new castle, the bridge. Do you know the one over the time with the big arch? Yeah, yeah, yeah, yeah. So there's a great big thing that goes over there. Joins foundation to foundation and that bears the load. You've got to think about load bearing because it's leadership actually to go back to a previous speaker. Leadership is what forms that load bearing relationship. The leadership on either side if it's senior stakeholders, sponsors and out managers, project managers and even senior engineers as well you've got to have a really good relationship to bear that load and it connects foundations of course and it also connects the people. What you want to have is really a shared idea of reasoning, of understanding the relationship has to have a shared reasoning. They don't have to be identical but it has to be a crossover in the Venn diagram of the inner thinking. You need to understand each other's reactions so when the effluent reaches the ventilation system you need to know whether the other side is going to duck or going to take some of it. All reactions are valid but you don't want them to be surprising. You need to understand people's guiding principles as well. Now it's interesting, I've come across some really really good techniques for this. This is Practical Empathy. It's a book by Indi Young who was at Adaptive Path US Design Agency. This was initially worked out as a design formula. If anyone's done active listening and mentorship that's a really cogent framework as well but the process and I do recommend to have a look at this, it's like don't worry there's going to be a little bit of audience participation in a minute to develop empathy we go through active listening and taking on board in patterns and then end up at the point where we can support people and we can build a solid relationship. The exercise feels a little bit like following someone along and I'll tell you what, we're going to do it now. Everyone ready for a bit of audience participation? I can tell you, you're buzzing, you're ready to go. In pairs, if you possibly can, one of you is going to be the researcher, the other one is going to be the subject. The researcher, I want you to ask the person about an episode of stress not necessarily a problem in a recent project and I want you to listen actively and think about the person, not the event. So they're going to be talking about the event but I want you to listen to what they're saying about themselves and their reaction in it. The subject I want you to tell that side of the story, tell about your inner experiences and think about you as an individual and your contribution rather than the overall team flexibility. We're going to do it for about five minutes which I know is going to be pushing the time thing a little bit but okay, on your marks, get set, go! Do it, chat, yeah, go on. I haven't used it so we don't trust anyone on there. Okay, stop! I have just applied to you the zygarnic effect. It's a psychological effect which breaks an activity halfway through before completion and allows you to remember something better. Thank you very much, I've just hatched your brain. Okay, moving on with the talk then. The next thing we're going to talk about, after a relationship, is a psychological effect that breaks an activity halfway through before completion and allows you to remember something better. The next thing we're going to talk about, after relationships, I told you I was going to mess with your heads, oh no I didn't. I'm going to mess with your heads. Okay, the next thing we're going to talk about as we go back to our bridge metaphor, we've done foundations, yes? Yes and? We've done the big arch, the load-bearing structure into relationships. Okay, good, the next thing we're going to talk about is decks. Bridges have decks. Those decks have to be appropriate to the thing that they are carrying. That forms for delivery. There's your deck there, that has to carry a thing. The deck of a foot bridge isn't appropriate to a canal boat. The deck of a railway bridge isn't appropriate to an HDV. What is this starting to sound a lot like? Steff will know it is. Methodologies. This is the why for your methodology, okay? I'm a big believer in agile at the very most metaphysical sense almost. Understanding what you're trying to do and putting a framework together that can support it. A framework that's defined by the team. This is not a real agile team. This is a clip-art piece. No, it's whatever it is. I bought it anyway. The key thing here is that once you've got a why, once you've not the framework of I've got my firm foundations, I know what I'm about, I know what they're about, I've got the relationship and we understand each other. We're not the same people but we've got a shared relationship and we don't set up a confrontational situation. We don't tell our teams that they've survived the project. Now I've got a context within which I can say, right, what's my methodology about? What are the criteria for a methodology to be right or wrong? One of the issues I have seen agile teams sometimes struggle with is that we're doing agile and we think it's great but they haven't got a bigger frame of reference in which to decide whether it's right or wrong. You've got all the flexibility in the world with agile. All of it. So how do you know if you're doing it right or wrong? Is it delivering your platform? Is it an appropriate one for your platform? Is it supported well by your relationships? Is it based on firm foundations? And finally, is it networked into really good communications? Communications are oxygen but I'm going to suggest back in our metaphor, they're also high tensile steel. Communications connect our span to our deck. They bear the load, they transfer the load and all of a sudden that starts to get really clear. Communications need to be simple enough to be repeatable. They need to be frequent and often they need to be habitual. And if they don't, if you start breaking some cables along the span then your deck begins to sag. You put too much load onto your methodology. You haven't got a good consistent load in your relationship and you put pinch points on there and you've got crisis emerging in the relationship and all of that puts additional stress on your foundation. Do you see how it all links together? Yeah? The bridge thing. It's a real thing. The fidelity gap is a real thing. The whole thing kind of works. God, this is mad. Okay. And so you, it turns out, are amazing bridge builders. You may be building bridges like this right now but you do build bridges. And once you've thought about that and thought about the relationship and thought about how it all fits together, maybe you can build better and better. In fact I know you can because you build amazing things. You build WordPress and you're all incredibly awesome. So go out there, build bridges, recognise the fidelity gap. It is real. You are awesome. I've been at. We're done here. Questions? I recommend playing at about half speed on the video later. There's beer in the next thing. So that could be it. All right. Thank you. Thank you very much. Thank you, Siobhan.