Delivery Management at Cloudflare

Thank you for tuning in to Cloudflare TV. Today we're having a conversation about delivery management and delivery managers here at Cloudflare. Whether you follow the Cloudflare blog or log into our dashboard and are surprised by something new in the products, all of that comes down to Cloudflare taking on new challenges that your team has about how you serve your audience or serve your organization and building that into products. But there's a core responsibility and that is to get those products delivered and released such that you can use them and such that you can use them without bugs or issues or distractions. We want to take everything that we're building here at Cloudflare and make it easy for you to take advantage of that. And that starts with delivery. And we're really fortunate here at Cloudflare to have a team of delivery managers who make that possible. So we're going to be learning a lot more about what they do and how this works at Cloudflare. And I'm so excited to get to be part of this conversation. My name is Sam I work here in our Elizabeth office on our product management team. And just a reminder before we get started, if you have any questions during the session, you can post them and we'll get pinged to those questions and we'll try to get to them at the end of the conversation. So today we have Abida and Alex. I'll let them introduce themselves. Abida, do you mind going first? Yeah, sure. So I'm Abida. I am a delivery manager here at Cloudflare. I work out of the London office, currently at home though. And I work at Cloudflare with the managed roles team. Fantastic. And Alex, what about yourself? Hi, I'm Alex. And I'm also working in the delivery management team here at Cloudflare. Very excited. I'm also part of the London office typically, but obviously we're all working remotely. Funny, funny story. I started with Cloudflare during the pandemic. So I've always been remote. And it's a great experience so far. My focus is to work with the data teams, which provides a very wide service internally to our engineering teams, and also with firewall related products. And slowly we're starting to pick up support for wider cross team projects, which is where kind of delivery management also can shine because of being able to eliminate roadmaps and helping other teams in better communicating on what they're delivering, when and how. Yeah, there's so much coordination, especially with how much of Cloudflare's product set depends on other products or depends on the network. I guess to that end, maybe Abida, since you've been here a bit longer, and then Alex would love to hear your take on it as well, especially since you've been started after the pandemic. But Abida, how do you define delivery management? Where does that fit within all the other moving parts about the clock that is Cloudflare? Yeah, cool. So the role of a delivery manager at Cloudflare has been new. So historically kind of started off at me joining. So actually it's been quite an exciting opportunity, completely green field to define how the role of a delivery manager fits into Cloudflare. The typical kind of like team structure in products and engineering you have, you have an engineering manager in the industry. You'd hear roles like tech leads, perhaps that are leading the engineering efforts for a team. And then you have product managers, product owners in the industry, perhaps that are the visionaries that lead the forward look of what the product should be in the market, also within the business. So the role of a delivery manager sits quite nicely between the two. And how we've tried to define the role of a delivery manager here at Cloudflare is kind of bridging the gap between that product and engineering and helping the teams in delivering what's required from them from a product standpoint and also an engineering standpoint. And bringing those engineering managers and product managers together to bring their priorities together from what's required by the business of the product and engineering team. And also kind of what's important and how do we achieve it. So the three elements, the role of a delivery manager plays is ensuring kind of team health and happiness, making sure all the engineers are working together. And they're kind of, I guess, the moving parts of a vehicle. And in order to make that happen, kind of applying the right methods and practices in place. We typically, the role of a delivery manager consists on agile and lean practices. We try and do that at Cloudflare. However, sometimes it might be various different methods and techniques and not all one method fits all. So you might have a team working in a completely different way, perhaps not entirely agile and lean than another team. And the third aspect is providing delivery support. So bridging the gap between product and engineering. And we're embedded in teams. So we're part of the team. You know, we do have a delivery management function now where obviously Alex has joined with our team, which is amazing to say. Fantastic. And, you know, so we will have our own function where we kind of, Alex and I come together and make sure we're supporting each other and we have each other's backs. But essentially, we are embedded in the teams that require the support. And as Alex said, we're taking on more and more as teams, you know, find out about what's working for them and what's not and kind of, you know, reach out for that, asking help. Yeah. And you mentioned kind of bridging the gap between product and engineering and balancing some of the prioritization. Where have you seen it be successful to kind of bridge that gap? Where do you think those gaps exist or the prioritizations need to get merged? What does that look like between product and engineering? Typically, it's about, you know, we do planning on a quarterly basis. So, you know, product managers kind of have their own set of requirements. You know, they're hearing from customers, they're hearing from sales, they're hearing from prospects, all various different channels, internal and external stakeholders. And engineering managers have the same thing. You know, they are responsible for kind of what can be technically made possible from what an ask of a product manager is. And, you know, they're responsible for the technical roadmap, you know, the technical landscape, the architecture of like what Cloudfire has built historically and how do we innovate on that or whilst kind of managing, you know, feature requests and things like that, that product manager is bringing through. And both of those can be equally possible hand in hand, but they have to be, you know, they come with various different factors that need to be in a controlled environment, like dependencies. You know, one thing is not going to be self-sufficient, it might depend on other parts. And that might be within the team, that also might be across teams. So, you know, delivery manager, what we do between Alex and I is kind of uncover those dependencies and build that cross functionality if it doesn't already exist. So, if a team is on another team, and they aren't communicating and necessarily two parties aren't aware that this dependency exists, then we kind of like cover that. And it's also about making, you know, the most viable products. So, where I said kind of what technically can be made possible, it's about making engineering managers and product managers working together. So, that education piece, you know, the bridging the gap in the middle, I said is like that education piece can happen from an engineering registered product manager, doing actually great requests from a customer, but technically it's not possible or technically it is possible and allowing that conversation to happen. And, you know, that builds for kind of the most viable products, but also, you know, it drives efficiency. And kind of, I guess, bringing that loop back and closing it is like one of the things that we really emphasize on is customer feedback. So, bringing back the customer feedback and saying, okay, well, we've now demoed this or you're using this feature, what do you think? How can we do better? And that actually is a really important loop to close. So, the engineers know kind of where that effort's gone and deliver management is in the middle, kind of facilitating all of this and allowing it to happen. Just all of those, I think, demonstrate what, you know, when a new feature appears for a customer and it's, oh, this is exciting. There's so much thought and so much effort that goes into it. And then you mentioned something that I think is hopefully everyone watching this feels like they can do is that when customers at Cloudflare share feedback, we really do listen because that's what's going to make it better. Alex, I know you're, like you mentioned, you're newer to the team. Where did you join Cloudflare from? What brought you into being a delivery manager into this now function we have here? Yeah. So, my background actually is, I started off working more in process improvement. So, project management, process improvement, making sure that businesses have the right roadmap to deliver what they're committing to customers. So, slowly I've transitioned from that background, much more aligned with the business into working directly with engineering teams. I worked for a couple of startups that were actually building this delivery function. So, my journey has been quite interesting, right? Because my background is not in engineering. However, throughout this journey, I've decided to learn more and more about how engineering organizations work, particularly because I had a keen interest into DevOps and actually how can this function of delivery, may it be accomplished by somebody with the title of the delivery manager or a program manager or an engineering manager, it doesn't really matter. But it's about the responsibility, right? Because at first sight, delivery managers spend a lot of time identifying and facilitating the removal of bottlenecks, of inefficiencies, of blockers, of issues that actually stand in the way of delivering value to at the end of the day. So, what I decided to do, and I think this is one of my skills, I like to solve problems and help people do their best work without having to worry about extra issues that they might not be able to control, but they are affected by. So, I think this is also a good place where a delivery manager can support because then you can spread out all of these escalations and make sure that they are addressed quickly. Because otherwise, you might reach a point in which you're fully, fully blocked in delivering anything. And this is what we want to avoid. Blockers, dependencies, they will always happen. And part of our role is to make sure that we're aware of them and we have a plan B on how are we going to address them if needed. So, that's kind of my background. And this is also what I'm working on together with the team here at Cloudflare, trying to increase the transparency and increase the communication between teams. Obviously, in Cloudflare, we can't claim that we are siloed or that we have the problems that traditional businesses actually have because we're born out of a desire to use technology to help people and create a better Internet, right? So, everybody here is very technically savvy. However, the regular challenges that people have when interacting with their colleagues or with other human beings can be boiled down into challenges with communication because we are very diverse or challenges with understanding each other because we come from different perspectives, right? So, this is a big part of our role to make sure that we actually facilitate this communication so that it doesn't reach a point in which we're really, yeah, in which it's very problematic. I know that I've never, especially working across teams, the encouragement to communicate more rather than less has always been so powerful. You said facilitating communication and that. I think we take for granted just that we assume everyone else is thinking about the exact same problem or thinking about solving that problem the same way. And oftentimes, all it takes is 10 minutes of walking through it to realize, oh, we see this completely differently. So, that communication, having people who are focused on that is so valuable. What kind of with that background brought you to Cloudflare? What excited you about joining the team and then joining this organization? I think one of the things that excited me, and it's good to mention that most of my background is in services in B2C. But right before Cloudflare, I worked for a couple of years. No, sorry. My background is in B2B. Apologies. But for a couple of years, I've worked directly in B2C and I can tell that I've learned a lot about development and products. However, I think I'm learning at a very, very different level working with B2B and product development and management in this kind of environment. I was very excited about the products of Cloudflare and I was actually very curious about them from a business perspective. And also, because I, honestly, looking at cybersecurity and tools to improve the quality of life, let's say, of Internet properties is something that I found very real. It's a problem that, well, we can always innovate into it. And I wanted to be a part of this. And then, secondary to that, I believe that working with a small team that is actually growing and setting up this function is also very exciting because, as Abida mentioned, it's a very green field and it allows us the freedom to try new things and actually tailor the approach very much versus being in an organization where you already have all of your processes, everything is a system and there is a little bit of bureaucracy there. We don't have that and, obviously, we're trying to set up the right approaches for each of the teams that we're working with. Yeah, this is where Alex and I actually connect really well because what Alex said about wanting to solve problems, that's exactly the reason why I wanted to come on board and why I wanted to go into delivery management. It's like, we want to solve problems. Like Alex said, we don't have the bureaucracy here that most businesses might do where you're one in a hundred people. There's a lot of organizational hierarchy or structure where you have to fit in or you have to do things a certain way because a lot of processes already exist that you have to adhere to or fit into, whereas we don't have that. We just get on with it and solve the problems. We identify something and we have the freedom and the support and the championship here at Cloudflare to be able to just identify a problem, go ahead and fix it, go and work with that team. That's just the most exciting thing that every day you're solving more and more problems and you're getting excited for the next new problem to solve. This is where it's amazing to now finally be a team. Two people, but it's still a team feeling and it's great. That team feeling is so important. One thing I've always loved, one thing I think is really fortunate about working in a place like Cloudflare is how willing people are to work across those teams. I remember a couple weeks ago, I was trying to do something to update an internal tool and I made just an egregious mistake in someone else's tool. I pinged them and said, very sheepishly, I was trying to make this update. In the next course of 10 minutes, they said, don't worry about it. I'll fix it for you, even though it's not necessarily something that they were planning to do that day. 10 minutes later, they just said, hey, this looks great. Thanks for asking about it. It could have, in a lot of organizations, it could have felt like either, how could you interrupt my day or how could you make this mistake? That someone was willing just to say, hey, let's work together. I understand why you're trying to do this. That's such a privilege to get to work at a place that facilitates that. To that end, I'm thinking about the high-level goals. You mentioned quarterly planning and executing on those. In just a single day, what is the day-to-day life for delivery manager look like at Cloudflare? Maybe Avita, I'd love to hear from you and Alex from your perspective as well. Day-to-day, typical things engineering teams might have, the regular cadence that's set up for them to be able to do the communication piece. Things like stand-ups in the morning, where the engineering teams get together, update each other on who's doing what that day and who needs what from who that day. If somebody's blocked, getting all of that out of the way first thing in the morning. Then various different meetings. Managing all the various different stakeholders that we have and we have to update. We might have meetings across the day with them. We might be facilitating collaboration across two teams. There's meetings happening there. There might be project reviews happening or check-ins, rather. How are things going? How far are we to our end goal? Are we on time or on schedule for we've got a due date coming up for a delivery to a customer, for example? Checking in on those things. Most of our software cycles have a cadence of doing things in a scrum way. We have everything going on a two-weekly basis. We might be having weekly reviews between EMs and PMs and DMs. That role of delivery manager, product manager, engineering manager, having a weekly cadence or perhaps day-to-day check-in saying, how are things going? Everything all right? Then various admin bits as well. I find myself lost in Jira most of the time. I'm not a guru. I do find myself once I get into something in Jira, I'm lost. It's like Internet scrolling through videos of cats or something. I'm just locked in from ticket to ticket. I'm finding out about some JQL. I'm like, oh, this is a cool graph. What would this do? Jira is a whole different black hole that I get lost into sometimes. Maybe some other admin bits as well, write-ups and things. Mostly meetings, right? Alex, mostly meetings? It's true. It's mostly meetings. If I try to think what would be a better day, maybe not today, because I'm very back-to-back. I think you will hear a lot of delivery managers saying that they're back-to-back, particularly the more initiatives you're involved in, the more you will need to stay on top on what's happening and actually get updates from teams and actively listen to what they're saying to try to draw the right conclusions. Okay, maybe some people will just be shy in saying, actually, I'm blocked by something, or I need help. You need to poke through and get to the bottom of it, because a lot of people will just try to solve the problem by themselves. That's a fantastic attitude to have, but sometimes it's important to just say, I need somebody else's overview on this. Maybe there's a different result that we should be looking at. As Abida said, there's the admin part of things, because I think it's really important. It goes back to offering transparency, right, and making sure that we communicate properly, because you can't expect all of your stakeholders to always be in all of the meetings. That's why you're there, to be able to disseminate the right information at the right time to everybody who's supposed to be involved or informed or impacted. Yeah, so you'll have that communication matrix to take care of as well. Yeah, I actually, I'm a bit opposite of Abida, because I really like to play around with data and JIRA and stuff like that. I'm always like, Alex, what's this? Can you help me with this? That's why it's great to have a team, to combine strengths. You learn when you're forced, because in my previous job, I was the JIRA admin, and then I had to figure out all of these things, because everybody was asking me questions, and the secret is, I just Google it. Yeah. It's the secret to a lot of things. Talking about the day-to-day and facilitating that communication, bridging those gaps, all in, what makes a successful delivery manager? Both the traits and the skill sets, but also when you look back at it, and how do you determine that was successful? Maybe Abida, I'd love to hear from you on that. Yeah, of course. For me, it really, really differs, based on what the initiative is that you're working, or what team you're working with. I think it's really important for teams to define what good looks like for them. One of the key things that I think delivery management focuses on, something Alex and I are starting to focus on with our team, is delivery metrics. When we say things like, oh, efficiency, what does that mean? What is efficiency, and how can we demonstrate it? Can we give it a number? Yes, we can give it a number, and that efficiency can be measured as a delivery metric. You can measure velocity of a team. How fast are we working through our issues? We're defining delivery metrics for each team to try and start having these, I guess, these conversations with teams to look at how we are performing. That's going to show us what good looks like. Once we've got data to have that informed conversation, we can define thresholds and metrics for each team, and they won't be the same across every team. This isn't a competition between teams. It's not to just give a team a number against their velocity, and then be like, okay, team A is faster than team B, so they're not good enough. That's not the point of it. The point is to drive that conversation within the team, and that feeling of self -organizing, making sure I talked about team health and driving that happiness. That happiness is also a metric. We do team health checks, like the Spotify squad model. You go through, how happy are you? Do you feel like you're learning? If you're not learning, what would you like to learn? We go through these things, and happiness is an important metric. Some of those things can come through exposing that data to a team to show them what their work looks like, rather than them constantly feeling like they're churning it out. For me, as a delivery manager working with a team, that's what I'm looking for. I'm looking at delivery metrics at the end of a sprint cycle, and I'm looking at how many bugs did we get through? Was it all bugs, or was it project-related work? If it was all bugs, that's not good. That's not progress towards our quarterly planning. How do I take that back to the team and start having a conversation about workload balance? How do we balance bugs and improvements versus project improvements and innovation, and let's not let any one of them fall? Those things, for me, are key indications. I can point to something, and I can provide data, and we can have an informed conversation rather than that assumption piece, and have better communication and transparency within the team. Alex, you mentioned coming from your background with a lot of process improvements and metrics. How do you communicate the metrics that you all are gathering with both the team that you're working with, but also the rest of the organization? Yeah, so this is actually an effort that we've recently started. So, what we're actually doing, we're measuring and trying to understand what's the result there before we actually set up a benchmark and trying to define, actually, what would look like this or like that? So, currently, we're just capturing this information, and that's actually the focus that we have in this quarter, and then by the end of the year, we will be able to further communicate to the rest of the organization. The team that we're working with actively are aware of what are these metrics, what are we measuring. They understand what are we actually looking at and why, and as I mentioned, by the end of this quarter, we'll be able to say right on. Now we have the full set of metrics. We understand what we want to look at, and that is, as Abida was saying, we want to look at velocity, we want to look at efficiency, and then we will want to look at cost so that we can have a comprehensive overview of what are really the efforts that we're deploying and what's the value that we're delivering, and I think that it's important to involve not just the direct stakeholders, but also distilled information and transform it into, let's say, trends for the organization, so you can look at basically two things, what you're delivering and how much value you're delivering to clients, but also what is the quality of that, and then the quality definitely will be broken down into how many bugs you have after you've launched the product or I don't know how many incidents happen, and we don't have that many, but there's always a risk, right? How are you tackling all of those risks, and that's all also concerning quality and the way that our product is experienced by our users. Yeah, yeah. I think one of the, I don't know, Alex, correct me if I'm wrong, but sometimes the misconception on a role of a delivery manager is like, oh, they're just here to put process on us, and it's not. Actually, it's really important for me that people come before processes, like something that is changed in a team or implemented in a team, introduced, whatever the word, it's a team effort. It has to work for us, and if it doesn't work for us, let's talk about it, and let's improve it, and let's find a new way that works for us. So it isn't about making processes work for people. People have different learning styles. They work differently. Engineers are engineers because they're really good at coding, and they don't want to do the other stuff. So we have to work together to find a way that works for an engineer, and yes, there is, I'm not saying process completely out the window, but there has to be some process, but that has to be an understanding within the team that is in place so that we can, so people know how to work with us, so that somebody looking in from the outside can say, okay, team A is about X, Y, and Z. It's clear to me how they work, what they do, when they do it, and what can be expected of them. If I want something from them, here's how I fit in my request. Do you know what I mean? So the process does play some sort of role for it. And we're all, I think, having that process and having that focus on team communication is so important. We are exactly out of time. Thank you all so much for walking us through this today. This is so fascinating, and we're really happy to have you on the team.