Originally aired on January 26 @ 3:00 PM - 3:30 PM EDT
Join Cloudflare Delivery Managers in conversation with Product and Engineering manager about their experience in working together to Build and Ship products.
English
Product
Engineering
Hello everyone. Good evening from London or good morning wherever you're watching us from. I'm Alex. I'm the lead delivery manager for EMEA here at Cloudflare and today I'm joined by Richard Boulton, one of my colleagues who is leading the engineering side of our firewall. Richard comes with 20 years of experience having worked in open source consultancy, having worked with startups, also having worked with the UK government particularly on the digital government services on transformation processes. So today we're going to be talking about delivery management here at Cloudflare and also outside of Cloudflare. So hi Richard. Hey there. Nice to be here. Thanks. Yeah. Thanks for accepting my invitation. I know that I'd asked you a couple of weeks ago if you would be willing to do a 30 minute segment on Cloudflare TV with me, kind of showcasing how we're working together from a delivery management perspective. So how do we ship stuff at Cloudflare? So why don't we start by you telling us and everybody who's watching, how does delivery management fit with our firewall team at Cloudflare? So perhaps it's best to start with a quick bit about how sort of teams work in Cloudflare. So we have a lot of small teams in Cloudflare. So generally it's maybe five engineers, that sort of scale. And a lot of the teams have an engineering manager and a product manager. So the engineering manager is in charge of essentially what are we building? What's the architecture? What do we need to do to build it? And the product manager is in charge of what are the needs we're trying to meet for customers? What do we need to achieve? And there's a lot of lots of things you have to do to get something built and shipped and delivered. And something that I found in my career is that it's very hard actually to keep those two things in one person's mind at the same time. So the architecture of what you're building, all the ways you could go about it. And here are all the dependencies we have. Here are all the things we need to have in place to do it. Here are the timescales we're working to. One person can do it, but it's very hard to do that on complex projects or particularly as the company gets bigger and bigger and more complex to make sure that you are keeping an eye on what's the situation as well as the internal. So that's really what delivery management is doing for the firewall team is we have lots of projects going on at the same time. We have lots of dependencies that other teams have on us. We have dependencies on other teams. And the delivery management role is really about planning out the work, making sure we know what we're doing, making sure we have what we need to get things done to make sure that the needs of other teams are being prioritized correctly on our list of work and making sure that we are doing things in a good way where good can mean so many different things. So I think that's probably the summary. Yeah. And I like how you mentioned this and you emphasized the fact that looking at dependencies, which is indeed a big part of what we want to do in delivery management, smooth those out. They go both ways, right? So in many situations, we will need support from other teams, but then there will come a time when we must return the favor. So the way that I look at it is not necessarily quid pro quo, but we need to have more as delivery managers, at least we need to have this more holistic view on what do we need to do in order to be able to deliver the roadmap, even beyond the teams that we're directly supporting, right? Because ultimately we're all working towards the same goal of going towards achieving this mission that Cloudflare has to build a better Internet, right? So absolutely. So it is, how do we get people working together effectively? That's really, there's another way of thinking about this as well, is that there's a lot of technical complexity involved in building efficient, scalable systems that are high performance and are highly secure. There's a lot of technical thinking to do, but then there's also the, what is the experience of the people in the team? Essentially, if you are an engineer on a team, do you have the tools you need? Do you have the information you need? Do you have the contact with other people who are working? Do you develop something to find out that actually this conflicts with something that someone else has been developing, or do you know in advance so you can work together on it? So those are the things which it's really important to have, if you want to have an efficient team, you have to get those right, but they're kind of different head spaces. And when I've been an engineering manager on a team without a delivery manager, I find myself sort of literally flitting between those two head spaces. And you can do it, you can't do it as well as if you have someone focusing on each of those skills. And it's really a different, it's a different set of experience you need to be able to do each of those well as well. Yeah. And it's important that everyone can do parts of that, but it's also, like many things, I think delivery management is a specialty. It's something where you can, there are a lot of techniques you can use for helping people communicate well, for being empathic towards people, and everyone needs them, but that doesn't mean you don't need specialists. Yeah, exactly. As you say, this is a specialty and it's a, in Cloudflare, it's a new function, but it's a growing function, because I think that, as you've mentioned, we've recognized that we need to be able to focus on all of these elements in order to be able to ship better. So I know that previous to Cloudflare, you've worked in various organizations and you've had other experiences working with this function of software delivery management. Tell us a little bit more about that, Richard. So I've been at Cloudflare for a number of years, but before that, I spent four years at the Government Digital Service in the UK, which is a very interesting organization. So it was set up in 2010 in order to try to get essentially good digital technological skills into government. So if you're familiar with government IT in most places, and certainly historically in the UK, then a lot of the work is done by consultancy companies. So you will have very little expertise actually in the directly responsible civil servants or in the directly responsible government, very little technological understanding, very little digital expertise. And the way that projects in that sort of situation tend to work is that you put a big tender for maybe 10 million pounds is a small tender, and two or three large consultancy companies will bid between themselves on this. They will probably actually write the specification for what is needed. They will then go away and build it, and it will take two, five, 10 years. And by the time anything is delivered, it doesn't meet what's needed because the world is changing quickly. So there was a movement, and it's interesting, but I'm probably not the best person to go into it, but there was a piece of work to try and fix that in the UK government, which resulted in the creation of this organization called the Government Digital Service. And at the time I joined it, it was about 100 and something people. It grew to be quite a lot larger. And essentially what they did was to say, how should a project be run, a technological project to build government digital systems? And one of the things that they they did from the beginning was say, well, we need small agile teams. You have to be able to get user research and feedback loops into the system. And in order for the user research to be useful, you have to have some way to be able to iterate on things. So very much following agile development principles and practices, not following any rigid methodology, but saying what you need to be is able to adapt to circumstances. You need to be able to measure. You need to be able to iterate and make changes based on that. So the project I joined initially was working on the gov.uk website, which is essentially a central website taking all of the different pieces of information published by different pieces of government and pulling them together. And in order to make a system like that work, you again have to coordinate with many, many different projects and different sources of information on what's needed and prioritize. You can never do everything. No one person can understand it all themselves. So the way that the teams there were run, they had a product owner or product manager, someone who is essentially responsible for understanding what are the needs or gathering the needs that we're trying to meet. And they would work very closely with user researchers and quantitative analysts to get data on what are the needs. And so it's not just making it up. And then you have a delivery manager, which some of the history of that comes from sort of agile coaches and agile practitioners. But a delivery manager isn't an agile coach. I think they're very different roles. A delivery manager is a much wider thing. An agile coach is essentially helping a team to follow some kind of agile methodology. And that's fine. But it's kind of a very limited problem you're trying to solve there. What a delivery manager is doing is, how do we get the right thing delivered? How do we balance the constraints and the problems against the needs and against the technical constraints? So you end up with that third part of it, which is the technical leadership. So a team works well when you have the product needs, the delivery needs, and the engineering needs all in a sort of healthy conflict in some ways. So you might have a product manager saying, I want to get these 10 things done. A delivery manager says, well, you've got time to do two. And the technical side saying, well, if we do these two, we can unlock all the other potential much better in the future. So those kind of conversations happen well. And you can have one person thinking all that. But it's very hard to have arguments with yourself and come to a good conclusion. So really, it helps to have people focusing a good deal of attention on that, each of those sort of angles. And this sounds really familiar, Richard, because the way that we're growing this function at Cloudflare as well, we also see a really important relationship between these three different functions. So you'll have the engineering manager, people such as yourself. You'll have product managers. And then you'll have the delivery manager. And then the relationship between these three needs to be really tight. And they must be very aligned if they are to deliver anything of value and communicate back to the teams. So why don't we talk a little bit more about what do you think makes, what is important to make this relationship really work between these three different roles for a team? Well, the easy answer is, like any relationship, what you need is trust and respect. You need essentially to know that you're all working towards a common goal. You have shared understanding of what you're trying to do, but also an understanding that each of you is coming at it from a different angle. So just because I may say something feels really important, that doesn't mean I'm going to assume it's going to be the highest priority thing. Because there may be customer needs, which actually, I don't understand why this is a real big problem for someone else, because I haven't had the experience of talking to that customer and hearing the feedback and understanding the problem in that depth. So it's a real balancing act in that sense. And the other answer is, it differs for every team. So if you put even the same three delivery product and engineering managers, if they're working on a different problem, the relationship is going to be different. It may be that someone has particular expertise in some areas, so they're going to naturally fall into having a much stronger ability to represent certain parts of the problem. But I think what I found with the various different teams I've worked with delivery managers on is, it's always a different area of responsibility. The lines are drawn differently each time, and it's probably actually worth every few months stopping and saying, so who is responsible for which parts of this? Nothing stays the same. Every time someone joins or leaves a team, it's essentially a new team. That's one of the ways I like to think about it, is that the team dynamic will change very quickly. And therefore, it's always worth sort of stepping back and saying, have we got the right balance of responsibilities? Are we doing things in the right way? And the other really nice thing about that is that when you have changes in staff, you can easily look at what are the processes we're following and challenge with an uncritical eye, saying, well, actually, we've always done it this way, but do we need to track our dependencies in a JIRA ticket? Can we do it better by having a list of a regular conversation? Or maybe there are other ways of doing things, and they might not be better, they might not be worse, but changing the way you communicate often finds things that you were just missing due to the structure of your communication previously. I see. And you make a couple of very good points, but I wanted to go back on this point of having really clear responsibilities and trying to understand who does what, who is teached to do what. And I remember when I joined the team, one of the first things we went over is this small document we have, actually, with the three columns. What does the engineering manager do? What will the delivery manager be responsible of? And what does the product manager do? And it's very interesting to have these responsibilities very clear in bullet points and everything, and it's good to always revisit them. But the way that I imagine them, Richard, they're more like a Venn diagram, so there will always be a little bit of overlap between each of these roles. Also, because I think it's important for the team to understand who to reach out to for specific types of challenges or questions. However, sometimes you really need to land on your feet and sometimes even fill in for your counterpart. And that takes me back to maybe it's a culture in Cloudflare, because as you said, you've worked in teams in which there was no delivery manager or perhaps in teams where there was no product manager, so on and so forth. And sometimes you need to step into those shoes as well. Did you find that as well? So I think the ability to, it's interesting to think about how do you handle when someone's unexpectedly away or someone's on holiday? And we like to make sure that people take ideally at least one sort of two week holiday each year along with other shorter periods. So there are going to be periods when people are not available and they shouldn't be disturbed. How do you make that not be a problem for the team? And it's one of the things which is kind of much easier to do is if you have people you can hand over to. So I took a nice long holiday in October and one of the things for that is how do you, what prep do you need to do? What do you need to hand over? The ideal answer is, well, I don't need to do much because we've already got that shared context. So it's just any projects, you don't have any context which is hidden from the other managers and indeed ideally the rest of the team. But I think it's, as I say, it's something every team is different, but for some of our teams in Cloudflare, the product role is a lot less strong because it's a much more internal facing team. It's something where actually we have a lot of internal needs that we need to map out, but it's not quite the same as gathering customer needs. So you might maybe need a very different type of experience to do that role. And then we have other teams where the delivery side is a lot, maybe not easier, but a lot less complex because there are fewer dependencies on that team. They have a well-defined product. It's got a well -defined interface and we know what the requirements are. So it's a less complex thing. And then you have platform teams, which the Firewall team to a large extent is a platform team. It's a team where we are building a system that many other teams can build on top of to build new security products and new configuration products. So in that kind of environment, then there's an awful lot of context which you depend on the delivery management side for. Yeah, that's really interesting. And actually this idea of providing enough context and making sure that your counterparts are really aware of what is the situation and what they're doing reminded me of when I joined actually, and Firewall is the first team that I started working with when I started at Cloudflare. So I remember that you were very open about your time and very generous with that to make sure that I'm on boarded, I know what's going on, I get to know the team. And I think that it really, really helped that you introduced me into the team and set up those expectations towards your team members. And I was wondering, would you have some particular advice for engineering managers or teams that haven't worked with delivery managers before, but who now gets to get this kind of support? So what do you think they should do in order to set this relationship up for success? So I think the point about giving a lot of time to you, I can describe it a different way, which is that I was handing over as much responsibility as I felt I could as quickly as possible, because that way, so if it takes me two hours a day for two weeks, but then I suddenly have 30% of my role freed up, that's a massive win for me. So it's kind of a very selfish giving my time to you. But I think that's the way to think about it is you can't do all these things yourself. What are all the areas where you are constantly coming back to worry about something? What are the things which are nagging you at the back of your mind that you haven't had a chance to maybe go through properly? What are the things you would like to get organized, but never have got around to having time to do it properly? Those are the things to dig into first. Don't try and pretend that things are working perfectly. Nothing is ever working perfectly on our teams. There are always many things that you would like to do differently or better. I mean, if you're telling yourself that things are perfect, then you're kidding yourself. There are always ways to make things work more smoothly, make them work more efficiently, make things a better experience for people inside the team or better experience outside. So identify what are the things you're unhappy about and be honest about them. Say, these are problems that I have. These are things where I haven't been able to make this work the way I'd like it to. Can we find a way to make this better? Or maybe it's not a problem, but raise that these are concerns you have. If you're worrying about it, you're probably right. It probably is a problem. So be open about the things which are difficult and which worry you. And that way, a delivery manager coming in can help and know which areas they can focus on. Yeah. So talking about being honest about problems or things that could be improved, what do you think are in general challenges of working with a delivery manager or with the delivery management function? So I think you touched on it a bit before, but it depends on what the experience of the teams of working with delivery management are. So one of the things you said was it's important to be clear who to go to for particular things. So if you've got three managers in a team, that's a lot of managers. You might have five engineers and three managers. That sounds ridiculous. But actually, the way it works in Cloudflare is typically our delivery management is spread across multiple teams because that seems to also help gather the context of what's needed. Sometimes engineering management is spread as well. And product is typically spending a lot of their time focused on bringing stuff to the team rather than telling the team what to do, giving the team information. So there's a lot of other areas in the company where the product management is spending a lot of their time working with the customer-facing roles and the sales and the solutions engineers and those sort of roles in the company and the customer support teams to understand what's going on. So once you've got all those different managers, it may be clear to those managers what's going on and whose responsibility it is. But is it going to be clear to the engineers on the team and to the people outside the team who to go to for a problem? And to an extent, they shouldn't have to learn. It shouldn't be the engineers have to learn who to go to. The system should be set up so they can actually go to the right person. So if it's, I need approval to do some kind of release, it's the engineering manager in our teams. If it's, I need to know who can I talk to in one of the other teams about storing an extra piece of data, it's going to be delivery management because delivery management is exactly suited to knowing what are the constraints and which teams are responsible for different things. I might be able to answer all the questions, but I'm not going to be able to answer it with confidence. So one of the things I do consciously do is I may answer a question, but I will typically say, I think this is the answer, but Alex will be able to tell you that definitely who you need to talk to or our product manager, Daniele, will be able to tell you the right answer for, is this a thing we need to release now? And to a large extent, if you do that frequently, very quickly, people just naturally learn what are the right lines to go to. So I think that's probably one of the important things is if you've got this structure there, people need to learn it. But if you essentially assume that they don't know it, but gradually point them in the right direction, it very quickly becomes second nature to go to the right place. Yeah. And you mentioned this, and I think that actually one of the, I don't know if it's a skill or an attitude, one of the things that I encourage everybody that I interact with to do is if you have any question, just shoot, let me know, because even if I don't have the right answer, at least I have the tools or at least the curiosity to go ahead and find out for you, because I think that this is definitely a big part of my job to remove all of these blockers and to answer any questions on behalf of someone else. Even if, as you say, they could answer, they could find the answer, but probably they would struggle in the process. So what we want to do is make sure that people get the right tools, the right information, so that they can actually do their job instead of feeling the pain of struggling to do their job. And I think that this is also an important part of what the delivery manager needs to do at Cloudflare. So having said that, what other aspects, what other skills do you think a delivery manager brings to the table for your team, Richard? So we've kind of talked a lot about the mechanics of how does a team work day-to-day, but actually a lot of the area where I think delivery management can bring real benefits is in the longer-term planning, in the working out, do we have the right priorities on things, do we have the right understanding of the problems now that we should try to fix and which ones actually aren't as big a problem. So to give a concrete example, if we have a team maybe constantly talking about how difficult it is to make a change and to deploy it safely, that's something which generally you want to know, is that something where if we invest a bit of time now, that's going to pay benefits within a month, we're going to have recouped our time and then it's going to be all improvement and happiness and a generally better system, or is it going to take two weeks of work and we're going to gain one hour of time back a month so it's not really worth making that change. So that's the kind of thing with getting data to say what is the level of pain. So it might be that we know there's something which people are unhappy about and sometimes it's worth priorities and work just to essentially make people feel able to be more productive. There are some things which you can't measure with data directly, you can't measure exactly what's the impact of a slight unhappiness with a system, but a lot of the time you can measure it. A lot of the time you can say actually people are spending two hours a day deploying stuff and instead we could spend one week making that better and then they're spending five minutes a day and therefore it's really worth making that investment very quickly. So that's exactly the kind of looking at data thing that delivery management can do. Essentially you can have the time and the focus to say well what are the metrics we need to gather, what is the data we need to record those metrics. Sometimes it's essentially digging through sources of data like Jira tickets or through build logs or something like that or it can even be sort of synthesizing a lot of quick survey responses from the team. But gathering that data takes a non-trivial amount of time and effort and thinking through what does that data mean is the even harder part of it. So you can get some numbers but understanding they actually mean something and then using that to pull into the prioritization process. I'm glad actually you're mentioning this Richard since indeed we're looking at this and as you know we've introduced delivery metrics at Cloudflare wanting to look at how quickly we ship. So what is our output, how can we improve that output and then two other important things we're looking at is our operational friction which goes back to talking about dependencies, talking about blockers, answering some questions for the engineers and then the other one is indeed team happiness. So at the end of the day is as you say investing a little bit of time, a week's work for making people happier whenever they come at their job. That's totally worth it and this is an exercise that we're running right now. So I do agree with you that actually a delivery manager needs to be able to understand looking at data, putting it together, draw some conclusions from it but an important aspect is also what data should I look at because we could look at it from various different perspectives and maybe draw different conclusions. So we need to be careful about that as well that's why we need this agreement. So it's not just about looking at sort of standard metrics and saying so here's my burn down charts therefore I'll do this. That could tell you information but you need to know a huge amount of context to understand that correctly so it's about using data and understanding its context and meaning not just about saying here's a methodology I'm applying. So it's absolutely about understanding the context and applying a whole array of tools which as I was saying that's a huge specialty because it's hard for an engineering manager to learn as well as doing all the engineering and apply it nearly as well as a specialist. Exactly and it also takes time to be fair and I know and I probably am lucky myself because I like digging into JIRA and looking at the data and everything and even if I struggle sometimes and making it look nice it doesn't really matter because I think that it can tell me quite a lot about what's the situation where we're at and then it's just a question of putting the right data together in order to consolidate an idea that we have and to just give us the confidence that we're doing the right thing. And Richard I just realized we only have a few seconds left. I wanted to to wrap this up by saying thank you so much for joining me today and for sharing all of this experience with you and for anybody who's watching I hope you've enjoyed this segment. If you're interested in delivery management we also have a few positions open so you can check us out at Cloudflare Careers. Absolutely thank you very much Alex, it's been great to talk. Thanks.