Sky is one of Europe’s leading media and entertainment companies and is part of Comcast Corporation, a global media and technology company that connects people to moments and experiences that matter. “At Sky, we Believe in Better. It’s in our DNA.”

In this episode of The Godel POD, our host Francesca Platten, Client Director at Godel is joined by Jonathan Lucky, Delivery Manager at Sky to discuss his journey with software delivery, where the ownership lies within a tech team as well as the challenges he’s faced.

This is an edited transcript, for more conversations on the latest in tech, subscribe to The Godel POD on Podbean and Spotify. Podcast jingle provided by the Hideout YouthZone. 

Podcast transcript 

Francesca Platten: Hi and welcome to The Godel POD. Today I have with me Jonathan Lucky from Sky. This is going to be a great podcast covering delivery. Jonathan, if you could please say hello to our listeners and give us a bit of an insight into you.

Jonathan Lucky: Yes, good to meet you, Francesca. I’m Jonathan Lucky. I’m a delivery manager at Sky. My specialty is all things agile and product and software development and really happy to be here. Thanks for having me.

Francesca Platten: Amazing. Thank you for being here as well. Will you give me an overview of your career history? Jonathan, how have you got to be a delivery manager at Sky today?

Jonathan Lucky: I’ve kind of gotten into the tech side of things in a very, how do you say wiggly wobbly way. Early on in my career, I was a sales guy, so briefly did some sales stuff for HP and then moved over to a small tech company that specialised in business intelligence, it was almost basically like a start-up Christian Stephen’s CSS. And there was just doing enterprise sales, which kind of moved into enterprise implementations of said software and I found that I got much more interested in the product than I was selling it. I became a product manager which was great. I learned not just a lot about the business aspects of building a product so branding and understanding what are the customer needs and how to shape a product road map and all of those types of things launching a product but also the engineering aspects. So working directly with an engineering team, what is it like to work as the coequal those 1:00 AM nights trying to finish off a bill. You know us trying to make things happen. At one point we realised that things were not very good for us. We were not necessarily overly happy. Our stakeholders were not necessarily happy and I guess together we were starting to make our customers unhappy so we wanted to do something fundamentally different in that business.

So we brought in a company, they basically did a whole agile transformation for us. We thought we were agile because for various reasons, but as many companies do. But after spending time with them, we realised that, whoa, we were very far away from it and it was just a mess and they basically really worked with us for a few months. And the transformation was literally a transformation of the way how we work, how we think about our product, how we do engineering, all of those types of things with such a massive sea change for us. We went from, we don’t know when we’re going to get done to. We were putting out brand new builds of the software and delivering them to customers. It was. It was fantastic and ever since then I said Ohh I want to do it. Yeah, I want to help other people do it.

Francesca Platten: Yeah I get that. So obviously that transitioned into your passion for delivery. So I remember when we first met,it was infectious. How much you enjoyed to talk about it and how you felt about it. So would you class that as kind of the where you see yourself in the future is it’s staying within that product role.

Jonathan Lucky: Yeah. I mean, for me, I look at it as, so very often organisations think you know, product engineering and design and all these other aspects are that go to make, they think of these as separate entities where the reality is not one of those groups can really deliver any value to the customer on their own and therefore they need to work together. So what I’ve found that I’ve

 dedicated my career, at least in its current state to is helping organisations understand that actually, that’s an ecosystem. And it’s an ecosystem that needs to work together every day, all day in order to be successful in order to build a product. And yeah, I’ve been really excited. I’ve been doing that for, like I’d say the last eight years. Specifically that specific aspect of It and I and I really enjoyed, but who knows where my career will take me next.

Francesca Platten: Well, obviously we’re covering delivery today and I think a great place to jump in would be what is your definition of delivery? How do you see that within the business?

Jonathan Lucky: You know, leading up to this, I was doing Googling, I’m not going to call it research because that’s a very different thing just doing some Googling trying to see what’s the official definition of delivery and there’s a lot. I mean, there’s obviously the, the oh, excuse me, the dictionary version of that, which we pretty much know what that is, but what does that mean in a software context. The famed Martin Fowler. He discusses that mainly from an engineering standpoint of things like continuous delivery and integration. Basically, all of the actions of women engineers. Coding to when they’re actually putting it in the production environment and maintaining it in that production environment. But I’ve seen another definition that was, you know, all of the activities around making a product and to live and getting it into customers hands.

So my, my, my definition would be is. “Delivery is the act of getting the entire ecosystem of product development to align itself towards generating value for the customer.” I mean, for me, that’s what I think is.

Francesca Platten: So is that how you find delivery is best seen when it’s related to the customer, it’s related to their experience because I imagine you’ve seen both sides where that isn’t the focus. What’s the difference and how does that impact the business and delivery overall in your experience?

Jonathan Lucky: Yeah, I do think it needs to be the customer needs at the forefront about it because very often we see delivery as a function of project management or a function of engineering management. Getting engineers to do work and do it on time. But I think really you know, so as one time I was interviewing a scrum master and they were like, yeah, I’ve delivered every project on time and under budget and I go well, you can deliver failure on time and under budget. So it really has to be about efficacy like are we, are we truly generating value for the customer and is that value profitable to the business like really at the end of the day. Whether something happens on time or not on time pales in comparison to if we generate value? I’m not saying that things like deadlines and stuff don’t matter, but we need to think about if we’re not making any money, then what’s? The point it doesn’t matter if you’re in or outside.

Francesca Platten: What does it mean for a business to be delivery focused? I imagine this falls quite nicely into the, you know, businesses say ohh we’re agile but agile has a very broad spectrum. Is that the same for being delivery focused?

Jonathan Lucky: Yeah, that’s a really good question. And you know a lot of times and obviously people have lots of views on what agile is, often negative and you know some people go oh, lucky. Agile is that touchy feely stuff where we talk about our feelings and retros, and we play games and all those types of things. And I go actually inherently, agile is about software delivery. I mean literally the first line of the manifesto says we’re trying to figure out better ways of building software by doing it, by actually building it. There’s a lot of things in the manifesto and the principles about, like, collaborate with customers, generate valued customer, deliver to the customer as frequently and as early as humanly possible. So Agile isn’t literally about how do we work together in order to deliver something to. The customer, you know that that this delivery in my view.

Francesca Platten: Absolutely. So how is this different between places you’ve worked at? One business said that, oh, we are delivery focus and you’ve gone to the your next career position. And they’re also, they’ve also said ohh their delivery focused. How have you seen that differ between businesses?

Jonathan Lucky: So usually how I see it differ between businesses is. Who, so to speak, holds the reins. You know, you know. Oh, in other words, who’s in charge of delivery is often the question you get. Oh. The engineering managers in charge will deliver Oh no, the product manager is in charge of delivery. No, the project manager is in charge of delivery of the programme manager is in charge of delivery. The Scrum master is in charge of delivery, etc. And that does differ depending on the organisation. And I find a lot of that has to do with A leadership and what their view of who should be in charge of those things are and B, what’s their experience with no other negative or positive with particular groups that have been across the delivery of software. So if you had a bad experience with Scrum Masters and Agile folk, you won’t let them anywhere near delivery. If you found that engineering managers only care about writing code, then you’re not going to let them anywhere near delivery. You know, and so forth, but if you have positive experiences in any of those groups, then you’re going to want them to be at the forefront.

Francesca Platten: Absolutely. Yeah in your opinion, who is best suited to own delivery? So obviously there are a lot of different people that depend on the organisation can say right, they’re in charge delivery, etc, but in your experience is best to man the ship of owning delivery.

Jonathan Lucky: Yeah. OK, most of you are going to hate my answer. Usually right at the top level of the business, and I totally understand why, is you want a single neck terrain. So you often see it. I see a trend now these days where you have the role of the solution owner where this one person is supposed to be in charge of hiring and managing the engineers defining the product road map, managing the budget of the team, defining the schedule of the team do, managing all the ways of working, managing all the meetings in the business context, owning the business KPIs, the technical KPIs and you go, that’s a lot. That’s a lot for one person to have in their head? Sure, if you’re a small startup, you can do that, but in a larger company of an org of 1000 engineers, 2015 thousand engineers, that’s just, that’s just not feasible. And so I would argue my answer. Would be and what I and I and I only answered this because I’ve seen it work incredibly well at many teams that I’ve established is you create a kind of a triumvirate system. So what I mean by that is you have your product manager because I firmly believe that you need a business person, that is in the team or work or is a leader in a leader in the team a leader? You need some sort of technical lead, whether that’s an engineering manager or someone like that. You know who understands the technical aspects that can lead the technical implementation that understands how the platform, the architecture works. They don’t need to be the expert on those things, but they need to understand that. So you now have a business person, you have a technical person, you know. And then you need that third person. You can call them. I usually like to say an agile coach or scrum master. Sure, if companies are really firmly against that type and doing agile, fine, then maybe you can put a project manager there in that set.

I think that’s fundamentally a bit different, but really you need one person that owns the product itself and the prioritisation of value one person that owns the technical excellence around that product and the third person that knows how to get those first two to synergize together. And that’s I think and I’ve seen that work incredibly well, think of it like in the US. You have the Supreme Court, the White House, which is the president, and then Congress, and they are co-equal units that have cheques and balances with each other. Those 3 need to work together all day, every day as a team leading the engineering team towards building and delivering value to the customer. Those are the three people that we go after and they have key accountabilities that we would yell at the specific individual, if those accountabilities are not being fulfilled. So that’s my view, those three.

Francesca Platten: What we’re seeing delivery as is that it’s not on one person’s shoulder. You think it can actually be split into 3 fundamentals that individuals can pick up, but as long as they work together, you do get the outcome of really good delivery and meeting timelines, etc, is that a fair assumption of what you’ve just said there?

Jonathan Lucky: Yeah, exactly. And they need to negotiate with each other. And the reason why is that each has this particular focus and those 3 overlap with each other, and that’s intentional. So that ensures that nothing falls through the cracks because sometimes we’re like that put firm boundaries between but that means when you come across an issue or a project or something that doesn’t fit in one particular, then all three of them just shrug their shoulders.

Francesca Platten: With having those kind of three individuals in an ideal scenario. What challenges can you expect to pick up? Obviously, I imagine you know personalities can clash and things at that point in terms of as a business, what challenge would there be to set up that kind of situation or that dynamic?

Jonathan Lucky: The 1st is often money. You know, these are three budgets always there. Those are three. One is leadership roles. So they’re going to probably be compensated along those lines and you might not have the budget to do it. The second thing would be talent. Each of those roles requires a specific kind of person, and it’s and it’s really hard to find those people. And so you may not always be able to have all three of those seats filled. And then the 3rd is just straight-up politics. It just comes down to an exact level, who wields who? Who has the greatest amount of influence? Whether that’s your chief product Officer, your Chief Technology Officer, your head of delivery, or whoever. Whatever the politics happened. They will likely inform the shape of that of that of that triumvirate, basically.

Francesca Platten: Yeah. And I was expecting you to say those three, the only one that kind of surprised me is that that not surprised me, but I wasn’t expecting was the talent but of course, you can’t just fill a seat for the sake of filling a seat. There are a lot of things that go into team dynamics, and everything which it does leads me quite nicely to my next question, which is how do you become one team? So you’ve got these three individuals say budgets there, the talents, right, politics, so hopefully all nicely going on and everything. When we first met Jonathan, you told me that you go across different countries quite a lot to go to be part of workshops. You’re big on kind of being team-oriented and being present. How do you get a business to back that ideology and also be equally as enthusiastic about being one team?

Jonathan Lucky: Yeah, it’s hard and it takes time. The first thing is getting the business to try it because most organisations have never experienced that kind of bottle and to create kind of the true sense of a team, they’ve only seen semblances of it. So you got to firstly, get them to actually try it. There’s lots of evidence out there that both academically and anecdotally that shows it works, but you just need to somehow convince people to try it. Once they try it, that’s when the work begins. These are groups of people that are going to have egos. They’re going to have pressures. So because these are different groups that have, you know, technical people who are very different, pressure that from product people and so on. So you need to get them to understand and recognise the pressures that each other are under, you need to get them to negotiate with each other and learn how to learn the needs of each other so that they can actually work together as a team. And most importantly, you have to show results like and. I would say working tested product is the only measure of progress. It doesn’t matter how good your design is, your requirements, or how the shape of your code is, none of that really matters unless you have a working, tested product that’s in the marketplace that customers are paying money for. If you’re going to form a group like that, that needs to be the first priority. Not processes. Not all these other things.

Those things are important, and we need those things, but we need to get that group collaborating together with the goal of needing to generate some result ASAP, because if they don’t, then you know, execs are going to go, what am paying all these people.

Francesca Platten: This ecosystem you describe as, which I really quite like defining those 3 roles I imagine is difficult, but it has to be clear and concise because otherwise you’re going to get people crashing, but we need that overlap. So how do you ensure that’s clear consistent across everybody and that they’re able to communicate effectively to ensure that delivery is the priority? How would you manage that?

Jonathan Lucky: Well, I mean, there’s lots of frameworks out there that help with that. You know, the most popular out there is scrum. And I think a lot of people think of Scrum as a process. But really what it is, is a framework or really a platform to create the right kind of conversations and negotiations, right? So there’s all of those scrum ceremonies you hear. Sprint Planning, review, retro and all exist for very specific purposes, and that’s to have the right kind of communication at the right time, there are specific accountabilities in Scrum that help ensure that the right things are being handled or at least can be surfaced if something’s not going right. So management is the same thing, you know, the same kind of ideas are there, just presented in and differently. And there are many others, XP and so on, but most importantly it’s about using those frameworks to create the outcome that you want, which is for these people to community collaborate.

So what I mean by that for example is the product backlog. In the product backlog, whether using Scrum command or whatever, that is a representation of the direction of the team and each product backlog item. Whether that’s forgetting about user stories, tasks, or whatever those labels are, they are, are, are specific conversation points of here’s the value we’re trying to deliver. So then the product manager has the accountability to ensure that we are doing the most important things to the business and strategy. The most important thing and the scrum master and the engineering manager’s role is to ensure that keep them honest and to challenge it right where it needs to be challenged. The rolling engineering managers to make sure that it is that that product backlog that we are making sure that the right things around technical excellence are there and that we’re executing on that in the most technical excellent way, you know these things are really important to the way how getting that level of communication going day-to-day happens. Things like reviews or doing regular reviews. It’s not about just did we delivered this thing good or not? And if it’s not, what do we need to change right now today about what we’re doing so that it can be good?

You know, there’s no point in waiting till the projects are done. Let’s try to fix the problems right now.

Francesca Platten: Makes sense. So in terms of, obviously you’re at Sky now, a huge organisation and you’ve been at some smaller business. Says comparing the two, obviously delivery will change naturally as the size of the organisation increases that’s clear. But do you find that having either a large organisation is better for delivery in terms of structure because they’ve got, you know, potentially bigger budgets and they can afford to have that, or is there also a like a nice sweet spot? Where in a small organisation, where one person wears that hat but can wear really well, what have you found?

Jonathan Lucky: Yeah, working at a smaller startup-type company. You know, you just wear mini hats. Like, you know, I was a product manager there. So we’re normally bigger companies would have an army of product managers that each one looking after a particular feature set of features and then product marketing would be its own separate kind of business somewhere else, you know, in a smaller company, you’re all of those things. Whereas say with engineering perhaps, in a smaller company, you, the engineers are the architects and they’re the principal. They’re the principal. They’re doing all of those things all in one group in a larger company, you’re going to have architects and principals, and you’re going to separate the front end and back end. And the separate work and all those types of things, right? So the key Is, I think, whether you’re big or small, is you want to maintain, I think Jeff Sutherland calls this practicality.

What I mean by that. Your body, right is made up of billions of individual cells, yet your body still functions, right? These cells are self-sustaining and they’re literally organisms in and of themselves. They have hearts inside of them. They are born, they live and they die. They carry out a function. And they do that and it’s the same thing that we want to try to create. As your organisation expands, is to create the same level of practicality. You want to try and ensure that. You know, just as a start up where you might have just one engineering team and that one single group of people or that leadership group, you want to try. And now figure out how you replicate that many, many times across your organisation.

The hard part becomes this. Let’s say you have lots of those. Then how do you get them to A, collaborate and B operate cohesively towards the same goal? So you have to have very you have to have two things. I think is A, a strong set of principles and philosophies whatever they are, I have my view of what I think they ought to be, but I don’t want to be prescriptive in this, and you have to have two very strong goals and direction and everyone in your organisation needs to be able to quote those goals in that direction and with their eyes closed all day long. Everyone should know we are heading towards this. These are the things that I’m contributing towards that. If you try to do it in a very top-down way, it’s not going to work, or at least well it’ll work. It will work very slowly, but you need people to understand. Here is the direction we’re going as an organisation, here are the key goals we’re trying to achieve. Now you all need to tell us specifically what you are doing to achieve towards achieving that goal. What are you doing to move the needle on that? And even if those things don’t work, what’s your plan to do something else if it doesn’t work right? So that’s really key as you maintain the practicality where you have a relatively small group of people that can move forward and do their things, but they understand exactly what the goals and the strategy are as a unit and they are able to carry out those goals and strategies as it relates and they’re empowered to communicate and collaborate with other smaller units. And that’s really key. That’s hard to achieve. There’s a bunch and we don’t have enough time to go into detail about exactly how to do that, but I think in principle, that’s what you gotta try.

Francesca Platten: And that should be from smaller organisations to large ones and that you can always implement exactly what you’ve just said. But as you grow, increase the practicality functionalities, right? Yes. So it was a great way to answer that question actually, because it’s a small business. You start as that one small unit. But as you said, as you grow you can increase you know those number of units, just making sure all communicating consistently and at the end of it, make sure delivery is the focus.

Obviously, in terms of managing delivery, how in your opinion, do we best manage delivery?

Jonathan Lucky: And so I guess when you’re thinking that’s managing in terms of knowing what people are doing?

Francesca Platten: Knowing what people are doing, but also kind of hitting those deadlines, making sure we’re delivering value, how do we manage that entire process almost, which might maybe have to split up into different sections. However, you best think?

Jonathan Lucky: Yeah, we should. We should split it up because I think some of it is, I think it through and there is an information radiation piece. So intelligence, how do we make sure management, especially in large organisations, they understand and can view what is the plan and what’s going on because they need to be able to communicate that to their stakeholders, whoever they are so that there’s an element to that. So there’s information, radiation intelligence. There is a decision-making piece, I think like how do we make decisions, who makes decisions and when do we make decisions. And then there’s just the doing of the work itself because that’s often what we forget about. You know, we’ll have all of these gazillion meetings of planning and strategizing and documentation, blah, blah, blah. Then we forget, like, oh, yeah, we need to, like, do it. You have to do it so I think the key is you need to have the right to manage delivery. You need to have the right feedback loops for all three of those things. And those feedback loops need to happen relatively frequently, as it makes sense for that group.

I’m intentionally not being prescriptive about specific frameworks because many of them have the idea of these feedback loops but obviously we let I’ll let the rest of the universe decide what they are. I have my opinion on what they should be but the feedback loop is key. So in terms of information radiation, we need to think about what’s the feedback loops for that and what kind of information we want to disseminate, quote unquote upwards and also quote unquote downwards. And we need to make sure that it’s useful enough but and is not and that. We’re also not just. creating unnecessary work, right? Who wants to sit around writing reports all day? No one wants to, but we still never did. Nobody wants to sit in the status update meeting nobody but. That you do need to at some point tell people what’s going on. So, you know, think about how we do that. So we need to go. Let’s maybe in a team you want to have a daily feedback loop that’s daily standups for example. Maybe you want to have wider feedback, but you talk about a wider organisation. Maybe every couple of maybe every three weeks, you want to have some sort of feedback, maybe every week you need to do you need to provide a status update. If here’s what we’re working on, here’s what we need, you know, blah, blah, blah.

The key is to find the right amount of information that is going to be necessary for us to make that decision.

I think the second part of that is so we said information, the feedback loops around decision making. So again, going back to practicality. We need the team the smallest unit in the organisation, to be able to make as many decisions as possible. We want to shift as much decision-making to them as humanly possible because they’re at the gimba, which means the place of work. You know, they can make a decision right now, right? Then at the place of work, because if they have to wait for someone way up here to make a decision, now it’s going to take time and it has to go all the way up and as it goes up the chain, the decision-making loses context. So we need to create a system where the people who are writing the code doing the work, make those decisions right then and there, and so that way that frees up the senior leadership to make the most important decision.

Francesca Platten: Yeah, I agree.

Jonathan Lucky: You know, do we spend, do we spend 1,000,000 bucks on this infrastructure or 1,000,000 bucks on that infrastructure, whether the button should be red or blue? Sounds like something that we should just let the team decide. So that’s the difference in the scale we should, we should try and say big scale decisions need to be handled by the big scale people get the small scale decisions about. Should it be? Blue or red? Should we put the button to the? Should we, you know, write it and write the code in this way or that way that should just be something that the team should just make. If you have product people and engineering people and delivery people in kind of that same unit, then they can make those decisions and they can just do it. And that frees up the senior people to make the big heavy calls and it frees them up to think very strategically about the direction of the business.

And the third way for the decision-making feedback loops at the last bit of just doing the work is that there’s not any formula for that. People just need to sit with each other and work through things. There’s no process that is going to save you. You’re just going to have to talk to people. Unfortunately, you just have to work with each other. Just got.

Francesca Platten: Really, management of delivery is very complex. Obviously we spoke previously to recording this Jonathan and we broke delivery down into three different sections, but we’ve also broken the role down into three elements and then managed it as well into three different elements. So there’s a lot that goes into it. I think a lot of businesses have a look for that element or try and squeeze it all into one or two of those sections that we’ve discussed today. It’s interesting to hear from somebody who is heavily involved in delivery, how you’ve seen it work, tried and tested.

In terms of translating business requirements into something you can actually deliver. How do you do that? Talk me through that process. What considerations are there and how do you go about it?

Jonathan Lucky: This is where I can be a little bit more prescriptive. Here’s the technique that I use. I’m not going to say that it works universally because I haven’t worked everywhere, but what I find and, and I’ve just learned this over the years from various mentors and trainers and also experimentation, myself. So I mean, first let’s say we want to do a thing, whatever that thing is, we want to build something, we want to improve something or solve some sort of problem. Whatever. The first thing we should do is have a meeting of the minds. We need to have. And when I say this is the people that are going to do the work and if we are being fractal. In our organisational design, that means we shouldn’t need 150 people to sit in a room to do that. We should probably only need like maybe 10 core people that are actually doing the work, including a product business person like a product person and then maybe another 10 supporting people. You shouldn’t need more than 20 people to. You have this thing. Some people call it PI planning. Some people call it iteration planning, increment planning or whatever. Just a simple session. I usually call it agile release planning because that’s what my original mentor always called it.

In that session, your goal is to do three things. First is to understand what the elephant looks like. So as the old saying is, how do you get 8 blind men to see an elephant? You get them all to touch a piece of it and then describe it and that’s the key there. Our goal is to do this thing or to increase churn to increase revenue by X per cent or to keep people on the platform whenever. It is and you say. OK, well, how do we do that? How do we do that? Everybody writes down. Let’s ignore user story formats and all that stuff. For now, we’re gonna set that stuff. Aside from just right now. One of the things we need to do, and the engineers are doing this, the product people are doing this delivery, people are doing this architecture just while writing these things down in this session and we just put it all down on paper on super sticky notes and put them on the wall. And from there, we eliminate the duplicates and all that kind of stuff and we emerge with basically our kind of initial pass in the backlog, certain techniques like journey mapping or story mapping depending on the situation, right to build a visual view of what that looks like, right. And So what would we understand what are the categories of what we’re trying to do and deliver and what needs to happen? You can colour code these things off here’s the engineering things that need to be done, here’s the product. Things need to be done, here’s the testing things or you know you can colour code it, tag it, do all those kinds of fun stuff.

The next thing is you prioritise these things. You prioritise in this session and then you also estimate, I’m not going to go into estimating, that’s going to take up so much time, but you estimate it. The key is I would recommend just don’t estimate in time. Just don’t do it. There are many reasons why we can avoid that. But just think, but we do. But often the business wants to know a duration, so you can give a very broad duration and there’s ways to calculate that duration. And we can always go. That’s a whole thing in itself too. OK. So now then we can go, what do we we’re clear what we want to build we’re clear on. Well, coming out of that session, we should be clear on what we’re trying to build, and what we’re trying to create. The first thing is then I’m going to do is draw a little line to say OK, in the next few weeks, we need to have something usable in the next few weeks. It’s not going to be perfect. It’s going to be ugly, but we need to get something that we could actually use on the phone or your keyboard or with a computer by the end of that. And we draw a little line and say OK, that’s that. Alright, so now, the next thing we do is we actually do it. We try to have lots of different meetings to try to plan on all of these different things. No, we need to have this session.

The reason is that we’re going to fail, so we might as well fail immediately at what we’re doing because everything that we’ve done up to this point is an assumption and when we spend too much time trying to plan things out, we end up burying ourselves in a lot of unnecessary things, and then we don’t realise any failure till later on. So let’s hurry up, and build it. Let’s start that first. And we’re going to discover a billion things that we did not know about in the beginning. And that’s OK because we only spent a few weeks planning this out or less, actually a few days planning this out. Now we know what to do next. We refactor our big board of our journey map and stuff based on what we learned now, OK. Let’s go again. Let’s take another few weeks and the idea behind this and this is the core thing with agile that we all forget is. It’s not about. Here’s a million things.

How do we then break it down into sprints and deliver it? It’s what is most important to the business.

What’s the first step that we need to take to that and then let’s try to get to the working bit that we can satisfy the customer value as early as humanly possible, as we repeat that cycle and we constantly review it and nine times out of 10 we find that about 30% of what we thought we needed going into this was not was not valuable, was unnecessary. But you only find that through the journey, you rarely find that out before you start. So that’s, I think an important thing. There actually go into more detail about each of those things, but I don’t want to put you to sleep.

Francesca Platten: I really love how you break things down. I’m not super technical. So like for me, Delivery, before coming into this, I had an idea and an understanding of it, but actually, as we’ve discussed today, you’ve broke it down into things that make sense of what delivery should look like. Actually, 20 people get it done, get the planning done as quickly as possible and just jump in and see where we go. And I think as I speak to kind of a lot of different businesses delivery gets translated very differently, but you’re all trying to achieve the same thing, so I find it interesting that the so many different ways to look at delivery, but actually as you’ve just described it, if we if we broke it down logically, I think it could be a bit easier to manage especially.

Jonathan Lucky: Yeah, absolutely and obviously I oversimplified a lot and especially if you’re trying to do this for an order of 1000 engineers, that’s incredibly hard. But you have to figure out how you repeat exactly what I just said. You know, across 100 teams. And you repeat that and really the key is you need to both organizationally and architecturally ensure that each of those 100 are capable of doing exactly as I’ve said without needing all 100 of them to all talk all the same time. So, and I won’t lie to you, that’s really, really hard. But I think in principle, we need to keep that principle that low in mind at all times.

Francesca Platten: Yeah. Amazing. Well, Jonathan, I’m all out of delivery questions for you, but I have one more that’s not quite delivery-focused, but I think you’ll enjoy it. So for everybody listening, Jonathan is from New Orleans, aren’t you?

Jonathan Lucky: Yeah, I mean not, originally I’m not, but my mother is.

Francesca Platten: Yes, sorry, that was it. What is your favourite thing about living in England?

Jonathan Lucky: It sounds really silly, but as an American, this is a very novel thing. Unless you live in New York City. I like the fact that I can just walk outside of my house, walk around the corner go to a cafe and have a coffee. That sounds really, really simple.

Francesca Platten: That’s not what I expected at all.

Jonathan Lucky: You expected me to say Europe’s at my doorstep. I could just go to France for a day trip. I mean, one time I went to Luxembourg on a whim. One day I just went and happened to plan and went to Luxembourg, which was cool, but I think fundamentally I just like the fact that there’s a kind of sense of closeness about things here and where is in America. If I wanted to do that same thing, I would need to warm up my car. If it’s the winter time, hop in the car, and drive. You know, 5 miles down to someplace to a Starbucks, sit in the driveway and then drive back. Or I just enjoy the fact that there is a sense of a third place in here. The place you can just go and there’s just people and you can just have a coffee and sit and reflect and enjoy the world around you, and unfortunately, you know, and I do truly love my homeland. Unfortunately, you know, you don’t see that as much and I think that’s one of the things that I really, really enjoy here. New Orleans does have that sense of thought that you cuz you were just there, right?

Francesca Platten: Yeah, literally just there. So I felt like you could just kind of pop out and things, but I do understand exactly what you’re saying, like anywhere you go in England, you can just walk somewhere was obviously with you. Just in America, everything’s up pretty much a drive or a commitment to kind of go, you can’t just pop out. So I do get that your answer is a lot better than mine. Mine was going to be a lovely Sunday dinner.

Jonathan Lucky: I mean, I do like a Sunday roast.

Francesca Platten: honestly, I love Sunday dinner.

Jonathan Lucky: Yeah, Sunday roast is good.

Francesca Platten: Yeah. So good. Well, thank you so much, Jonathan, for being on our podcast today. You’ve been amazing. I feel like I’ve learned a lot and I’m really looking forward to sharing this I look forward to seeing you again in the future.

Jonathan Lucky: Yeah. Thank you so much, hopefully we can do more of these if you ever have me back.

Francesca Platten: Absolutely. Thank you so much.Jonathan Lucky: All right. Thank you.