Originally aired on November 24, 2020 @ 8:00 AM - 8:30 AM 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
Okay, we are live on Cloudflare TV. Welcome everybody who's tuning in. We're here to talk about delivery management at Cloudflare. So just before we get started, a reminder to everybody who's tuned in, if you have any questions, please do forward them to livestudio at Cloudflare.tv. We won't be answering them live as we go, but we will be looking at them afterwards and coming back to you in due course. So without further ado, we'll get into the session itself. I'm Abida, I'm a delivery manager here at Cloudflare. And I'm here to have a chat with Michael, who is a product manager at Cloudflare. And Michael and I work together. So this whole chat is about kind of what's the experience like for a product manager working with a delivery manager in a software delivery team dynamic. So Michael, tell us a little bit about you and your time at Cloudflare and kind of which team do you work with? Sure. Yeah. Hello, everyone. Very happy. Thank you, Abida, for inviting me on today's show. I'm excited. So I've actually joined Cloudflare quite a while ago, about five and a half years ago. I didn't start as a product manager, I actually started as a solutions engineer. So slightly different role and sort of moved across. I had the lucky experience of moving across several teams and getting exposed to a lot of different processes and environments at Cloudflare. But as you said, I've more recently joined as a PM team. And I think we've been working since July. So just over about six months now. And specifically, within the product organization, we're focusing on the manage rules team, which is part of the security services offered by Cloudflare. Awesome. So let's get into a bit about how does delivery management fit into the manage rules team? And what's your experience been like so far? Right. Well, I guess to provide a little context, the manage rules is we are a core engineering team and at Cloudflare, Cloudflare is a software as a service business. So we're sort of releasing new features along the way every single day. We're trying to have a very high product velocity. And this is my first experience with a full delivery manager role working with me. I found it to be extremely helpful in terms of how it fits within manage rules team. But I think some of these things are also general to most of the other teams at Cloudflare. It is very difficult for us given the so many moving pieces, always remind ourselves of connecting and speaking and making sure everyone in the broader team is aware of what we're doing. And I think that's one of the core things that you've helped us a lot with, Avita, of course, is making sure that, yes, we're aware within the engineering team what we're doing, but what does the other firewall engineering teams are doing? Are they aware of our product roadmap? Do the design and product teams, are they aware of what's going on? Are we all well connected and are we sort of speaking to each other so that deadlines don't slip or things are not a surprise? So I think that's been one of the main things I'd like to call out, I guess, in terms of delivery management within the MR team. The other thing I found very useful as well, there are a lot of moving pieces in the rules realm. We are actually a subset of a broader firewall and security team. And due to, I guess, historical reasons, a lot of these teams are working on the same software components. And as many of you know that might be working in software development teams, when there is more than one developer working on the same code base, very often you start getting friction. A pull request needs to be approved by someone by the time a pull request is approved. Maybe some other changes have been merged and there's all sorts of delays and issues that come out of that. And as part of delivery management, sort of identifying what those dependencies and issues are as soon as possible, I think is really useful. Especially from my perspective, as a PM, I need to sort of bubble up what our roadmap is and what the timelines of certain deliverables are to senior management. Being aware of those issues sooner rather than later and trying to smooth them out is vital to how we operate as a team. And then, I guess, the flip side of the coin of that, especially within the managed rules team, is the planning aspect. Yes, we give ourselves goals and we try to make sure things are smooth and all the blockers are removed. But at Cloudflare, especially in the engineering teams, we try to follow a quarterly planning process. So at the start, well, at the end of the prior quarter, we try to sit down, and actually, we had a meeting about this today, we try to sit down and plan out what we're going to be delivering and working on over the next three months of the following quarter. And there's a whole lot of things we need to think about and making sure, me personally, I don't forget all of those steps, is of great help. And the output of that, of course, is a planning document where, as a team, we identify we're going to be delivering X features by Y, and we also need to make sure as we plan that we go back and figure out what those dependencies are so that there's no surprises and we can forecast as well as we can. The other thing, I think, I don't know if this is general to all delivery management roles. Rita, you can give me some insights on that. You've been helpful, and I think delivery management as well has been very helpful in also doing retrospectives. And by that, I mean, once we finish the quarter, it's always good for us to look ahead to see what the next thing we're going to be delivering on. But also, questioning the status quo sometimes is super useful. And as a product manager, the two of us work very closely with an engineering manager as well, and we're naturally focused on what's next. We very rarely start asking the questions, out of the things we did for the past quarter, for example, what went well and what went wrong, and what could we do better to help us increase the product velocity. I don't have a lot of experience with delivery management, but I think these items have been super useful, especially within the context of our smaller managed roles team. I think that's the main things I'd like to mention. I don't know, Avita, if there's anything you'd like to add to that. Yeah, no, you mentioned the reflection piece that we do. It's all farewell planning for the future, but they're reflecting on how previous quarters have gone, or previous planning sessions have gone, is a really key important part to getting the team to think about the right set of problems. And also, we're not perfect. Things can all go wrong. And it's about creating that safe space and transparency within the team to talk about those things and actively address them moving forward. Because if you're not learning throughout the whole process, you're probably not doing it right. Right, right. No, absolutely. And then as well, I mean, I guess you're not the only delivery manager we're working with closely, right? So even the neighboring firewall team works with Alex, who is another delivery manager with us. And I assume there's a lot of learnings, even if we make a mistake, there's no reason why, and we learn from it, we can not transfer that knowledge over to them as well, right? Especially when it comes to team retrospectives. Yeah, totally. So talking about things that can go wrong. Of course, many things can go wrong. What have been some of the challenges that you have experienced that we faced as a team? And of course, you know, you can reflect on kind of challenges that we faced as PM and DM. Yeah, I don't know. I don't have solutions for all the challenges. I guess we're working through a lot of these as we go along. I think I sort of implied a little bit what one of the big challenges we have is within, you know, the broader firewall engineering team at Cloudflare. I guess for a bit of product context, the firewall engine, which is, you know, one of the core products we provide to our customers is essentially a rules-based engine. And given that Cloudflare itself is a proxy for the more technical folk of you listening to us today, the firewall sort of becomes more of a platform over time compared to just a single product and a solution we deliver to customers. And this has caused, you know, a lot of engineers writing and contributing to the same code base. And sometimes, you know, identifying those dependencies and, you know, what steps are required to get a release out and deployed is challenging. That's one thing that comes to mind. But also, not only focusing on the software development part of it, even simply, for example, making sure that our UI and our design components are well built in time is quite complex. Even because, you know, from a Cloudflare perspective, me as a PM, I'm very happy to be aligned with you as a delivery manager and with Andrej, who is our engineering manager. However, all the engineering teams and product teams at Cloudflare are relying on a, for example, for now, a centralized design and product design team, which is a perfectly fine way of doing it. But of course, we need to make sure we communicate what our dependencies are early so that it's all well planned out. And things are going quite well. But we need to remember to do that communication. At the end of the day, communication is core. And sometimes, maybe even for my lack of communication, some things may have slipped. And that then causes sort of a knock-on effect to all of our deliverables, right? So there's definitely challenges in that regard. I guess the other part is communication to the broader team, even to senior management of what we're delivering and how successful we've been within the quarter. It's never easy, right? I don't think there's always space for improvement. I think we do a pretty good job at Cloudflare, especially within our smaller team. But communicating even outside of senior management to the broader, for example, customer-facing team is something we need to... There's always space for improvement. We need to communicate that. And then eventually, there'll be even the customer communication itself and announcements are a big part of delivering a product in the hands of our users. Yeah. And one of the things that we've been exploring last quarter, so Q3, and something we've been continuing to do more of in Q4, is improving the visibility on the team's productivity. Are we doing the things that we said we were going to do at the start of the quarter? So, and that's one of the challenges that we did face, is how do we show what we're doing and how is it valuable to the business? Now, that question posed has brought us to think about delivery metrics. For delivery managers out there that are working for software teams, even in the industry that are probably familiar with delivery metrics, we're looking at things like velocity, our output, the quality of our code. Are we constantly doing operational stuff? What's our workload like in terms of operational improvements, as well as project-based on innovation and our future solutions and what the managed rules is going to be as a product in the market. So, all those things have allowed us to reflect as a team and create that transparency with our senior stakeholders and demonstrate that this is what we're doing, and also has allowed us to reflect consequently on if we're not doing the things we said we're going to do, why didn't we get to them? What were the broad blockers? What were the issues? The interdependencies you talked about, you know, the bigger firewall products in the code base. And I think it's also that the delivery metrics are, I think, become even more so important when not every project we're working on necessarily has a customer-facing announcement or deliverable. And therefore, you know, from many parts of the organization may be wondering, you know, what have we been doing? What improvements, quality of life for our end users, you know, the work we're doing on is impacting, right? And I think communicating that clearly, like, for example, last quarter, a lot of the work we did didn't necessarily result in a customer-facing announcement. However, we basically laid the groundwork, especially for the managed rules and web application firewall, we laid a lot of the groundwork of things that are going to be released in the coming quarters, as well as cleaning up a lot of our, you know, technical debt and migrations that we're starting to plan on and get experience on, which will definitely be extremely useful moving forward. So, yeah, no, definitely the delivery metrics point is extremely, extremely valid. You mentioned you haven't worked with a delivery manager outside of the project, you haven't had the experience. So looking back on that, how is it better or worse having a delivery manager than not having one? Right. No, that's a great question. So I guess for a bit of background, I do come from a software development background. I was a software engineer prior to Cloudflare. I babble with code outside of Cloudflare even today. I have worked with roles that could be considered very loosely related to delivery management. However, my experience with Vue and, you know, within Cloudflare is a lot more, you know, the core delivery management aspect, which is very different from what my experience was. Specifically, I've had a lot of experience in sort of more agency client work where I've been aligned with or worked with project, more broader project management term. And, you know, for project managers, probably a component of that is making sure the customer receives their, you know, what they're basically purchasing, what they've asked for. But the, you know, looking back at the difference between, you know, the delivery manager role itself in its more pure form, I do think, you know, it definitely would have helped in a lot of my prior experience having a delivery manager around. The one part is, you know, slipping deliverables or not being able to identify the bottlenecks, which we spoke to earlier. It's something I've really seen the value of that at Cloudflare. And having said that, my experience at Cloudflare is probably the bigger software development SaaS business that I've had. I've not been working at companies as large as Cloudflare. And probably the value of delivery manager becomes greater the more complex environment we're working in. So, you know, I cannot imagine a world without a delivery manager at a company like Cloudflare today. So there you go, I said it, I said it. I think without a delivery manager, and in the past, I've also seen myself attempt in my prior experience to perform some of the tasks that you help us with delivery management helps us with. The problem is, unless you have, you know, experience in identifying what are probably common pitfalls across many software development lifecycles, you're likely going to not do the job well, and probably miss on some very easy quick wins that are that would result in great benefits, right? So, yes, when I've worked on client projects in the prior life, we have had, for example, team retrospectives once in a while, and then find out what went wrong, what went well. But sometimes, those exercises have always been very superficial. And the with debatable sort of benefits, right? Because you sort of move on to the next and you forget, you know, you may have had identified, even if you have identified some pitfalls, you may not have then implemented what the actual changes should be that come out of them. Whilst, you know, in our case, I feel we're doing a much better job, for example, now, within the managerial team, in identifying those things and sort of fixing and driving those motions forward, so that next quarter, we get better. And then the following quarter, we then get better after that, right? Yeah, totally. I definitely found that when I when I first joined Cloudflare, almost two years ago, time flies when you are having fun, right? I did find that engineering managers and product managers were kind of kind of wearing the hat of a delivery manager. You know, they were doing the things perhaps, you know, that you mentioned some of the things that do drive, you know, efficiency within the team. So like mini retrospectives, and some sort of, you know, agile going on in the team, you know, they're running standups by themselves, or having ad hoc planning meetings, there's not necessarily a regular cadence. For me, agile delivery, I think one of the one of the key things was really important, driving that home, and I joined is, is it's change over time. And agile isn't something you can just chuck at a team and say, here, it will fix all your problems. It's it's a mindset change. So there's no point kind of giving a team a little bit of stability by doing these ad hoc, like ceremonies, and then taking it away from them, and they don't become self organizing, they don't have that consistency, they don't have that regular cadence. So what we've what we've really done in managers is establish that foundation. So no matter what, what changes in terms of, you know, the three key areas of management we have is product, engineering, and delivery. If you know, the three, the three, three, three, three managers do leave the team, the team will have the core fundamentals that they report around that these are our principles, here's our way of working. And this is how we, you know, communicate with the rest of the business. So that I feel like we have definitely established within the team. Yeah, yeah. Yeah, no, that's a very good point. It's sort of becomes like a second nature to follow certain processes or working methodologies that make make the team productive and better, right. And then I guess the road sort of becomes over time. I guess you've made you've made me think about this now. It's the first impact is probably a lot of education in terms of like changing the way a team works. And based on prior experience, especially on what has worked before, of course, every company is slightly different, no. And then I think, though, the you know, the challenging the retrospectives and the challenging status, the status quo, like, what can we do to make it even better? Maybe over time becomes like the the main focus, I don't know, maybe maybe I'm looking at this slightly wrong. But I feel that that continuous improvement is is super valid, right? Because people get comfortable in the role, we've been doing something for so long this way, why on earth should we change it? Right? But that's that's just the wrong mindset from the from the beginning. Yeah. Um, you talked a little bit about some of the things that perhaps you were doing yourself. But you know, I'm helping helping you in the right. What are some of those things that you might you might have found yourself doing before? Yeah, so the, you know, as a in my prior lives, again, the estimation, I think of how long a project should take, I think that, you know, most companies, even if you don't have the delivery manager, helping supporting that it's something even I found myself doing, it's just such a necessity to get those estimates, right, in terms of, you know, especially if you're working on a customer facing project, the, and we all try to put our best hat on in terms of estimating how long writing a piece of code is going to take. And we all try to pad as much as we can, to set the expectations, right. And inevitably, we always get it wrong, to some extent. And so that's something that I found myself doing pretty often, the and of course, you know, over time, you do get better at it. And I think that's a core component as well is like experience, okay, this has worked, this is not what how can we make sure our estimates are as good as they can be. The other part that I found myself doing a lot, but mainly where my software development hat more than other is trying to figure out what's the quickest way to essentially deploy and make, you know, that the development team productive, so that recurring repetitive tasks are not blocker, and that sort of become like smoothened out to then allow for more time for actual creative software development, right, actually writing business logic, or whatever, whatever it is that needs to be done. And that in smaller teams, I find that becomes very often a bit of a backburner and gets neglected, neglected a lot more than it should. And I'm definitely a bit of a guilty of that as well. As you know, we might be, I've been working on customer projects, and then we realized that actually, between having a staging environment with, you know, the code working to actually get getting it out live, there's a bunch of steps that we repeat and do every single time. Why are we doing it this way? Why don't we actually what is the value of fixing that process so that we all save ourselves two hours every day, and we spend it on better things to work on. So I've, I've worn a couple of those hats, I don't think I've ever done a good job at them. And that's why dedicated focus, I think, is, you know, actually does help a lot with this. Totally. One of the observations I've made, and correct me if you think otherwise, but one of the observations I've made in you as a product manager is, is the, the, the, you said something about freeing up some of your time, which has allowed you to spend time, more time with customers. And we've, what we've been doing, what it's allowed you to now do is get customer feedback, which has been really, really important for us as a team. So, and, and also the the estimation part you mentioned, mentioned, it's not so much estimating how long it's going to take us to do something. It's the estimating the complexity and breaking that complexity down to have phase set of developments with our customers, which has allowed us to do to deliver things to them in smaller bits, get quick feedback before we, you know, we go, we, we go live or GA with a, with a product or feature. And that is, that is, that has been a real, real key. Yeah, plus one, plus a hundred to what you just said. The, you know, as a product manager now, I, I find the product management role is very much a customer facing role. To some extent, we are the voice, actually not to some extent, we are the voice of the customer within the organization. Right. So the more time I can dedicate to that, of course, there's things I need to do within the team, such as, you know, making sure the, what, what, what we're building is well-defined at least from a product functional perspective. And those are all extremely important things, but the more I speak to customers, the better and the more free time I have to speak to customers, then it's, it's even better. Right. I I'd like to pick on what you said in terms of breaking things down in terms of the complexity. Indeed. And I think that reflects as well to how product management is carried out at Cloudflare. We have this context, context internally, I guess, for the broader audience, we call ship tickets, which are implemented within our JIRA ticketing system and product managers are responsible for defining and creating those ship tickets. Normally when you first create a ship ticket to when you deliver it, the scope has, you know, changes drastically, but that is, you know, that is part of what you said, you know, there's, there's a conversation between me and you, Abida, and Andre, who's our engineering manager to sort of break that down into let's say, well -defined chunks, both from a customer perspective, but even in terms of internally to help our, you know, development life cycle. Right. Yeah. So I guess we've got a couple of, couple of minutes left and I have perhaps one or two more questions for you. Okay. One is the, the dynamics you're, you're mentioning between product manager, engineering manager, Andre, you've mentioned and myself, what, what is that dynamic like? And if you have to pick kind of, I guess, three benefits that dynamic brings to the team, what are they? Yeah. So we, I find myself very lucky, I guess. So the three of us are, you know, we, we need to work together very closely and I find there's a lot of value we're getting out of that. The, it is important, of course, that we know what, what the responsibilities of each one of us are and to make sure that's clear, you know, the communication is extremely important. But then again, you know, the fact that we're working together and we're communicating a lot, sort of the benefit that comes out of that is first of all, everyone's aware of what's going on. Like we actually speak very frequently, like for, again, for the broader audience, we, we do have daily standups and it's not something only the delivery manager with the engineering manager joins. I actually, as a PM, try to join pretty much every single delivery standup I can. And getting that communication going, make sure everyone is in the loop. And I think that's extremely vital, even for the engineering teams themselves to know, you know, what is the broader plan? How does what I'm doing as an engineer fit into the, to the bigger, you know, vision of the product. The, the other part, I guess, is the, you know, I guess I said this already, us being aligned and us communicating clearly does ultimately result in, in, you know, better workloads across the board and also increased productivity. I do think though, if I were to pick one thing, the communication aspect, making sure that, you know, you're aware of what I'm thinking and vice versa. And then we have recurring sessions where we plan things out is, is, is sort of vital to, to get, to get, you know, the whole process working correctly. Yeah. Awesome. Do you, I guess, do you want, do you want to ask me a question? Yeah, yeah, yeah, sure. I, I was, you've been asking me a couple of questions. I was wondering, have I missed anything out of that last question you asked me? Do you, do you feel that, you know, we're, I feel we're speaking pretty often and keeping, you know, the communication going is, is a core aspect, especially when it comes to delivery management. Is that, is that fair to say, or do you feel there's this amount of aspects which are core or at least that are working really well within, within our team? Yeah, no, you, you touched on all the right points. I think it's one of the, one of the, one of the key things to do, you know, at the start of such a partnership is where you have this dynamic of a delivery manager, a product manager and engineering manager is making it quite clear from the start what the roles and responsibilities are. And we did identify that, you know, right from the start. So Andre and I already had the experience of like working together, you then joined the team. And then we sat, you know, the three of us sat down and we're like, okay, who's doing what and who's responsible for what. And that really helped the team understand how, what they can expect from us and, and who to go to for, for, you know, different sets of problems. And also just the, aside from just the regular cadence of like communication with our teams from, from the different aspects, you know, you bring the product requirements. If there's anything kind of happening outside of the team, you kind of fill them in. But we also do planning together, you know, and that's a, that's a weekly cadence that we have, where we sit down, we review what the team are doing. Are we on track? You know, what are some of the, some of the dependencies we need to consider, who else should we be talking to? And all those things that are really important and weekly, we've identified like that's enough for us. And that's something, again, it's just based on communication that we identified, we needed that. So for me, it's been a, it's been a great partnership and a real, real joy working with you. Thank you very much. Thank you everyone.