Originally aired on January 23 @ 7:30 PM - 8:00 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. I'm Alex. I'm the lead delivery manager for EMEA here at Cloudflare and today we're going to be talking about software delivery management in particular with our data team. So I'm joined today by Jamie who is our director for data. He comes at Cloudflare with a really rich career both in technology consulting but also in building technology products. He was CTO a couple of times so he comes with a lot of interesting experience that I'd like to talk to him about today. So hi Jamie. Thanks for being here today. Hi Alex. Thanks for including me. Yeah so I've done a couple of other sessions with some of our colleagues on what is delivery management, how does this work in Cloudflare but this is the first time that you and I speak on Cloudflare TV and particularly I want us to focus on how do we work together in data. So for a little bit of background I support one of Jamie's team which is the data team based here in London and we actually have quite a lot of crossover with the whole of data. Our colleagues in San Francisco as well and it's quite a ride because data is a really interesting team at Cloudflare both building data products and also supporting our other product engineering teams in delivering their own products. So Jamie maybe talk to us a little bit more about kind of this interesting setup of data. Well as you mentioned data is a very vague term to begin with so we have a team named after this big thing. The team has a long history and does quite a bit. It's quite a challenge so we're responsible for all the metadata generated by all the products that Cloudflare runs around the world and it's quite a bit of data. I won't go into all the details but I mean we do a lot, we do it very efficiently and we do it 24 hours a day so it's impressive. The analogy that everyone always uses is that on the data team it's kind of like turning a freight train into an airplane while it's moving. So we do some very interesting engineering things. We're always improving things but we have to do it without any interruption. Yeah it's quite interesting as you know. Yeah and actually I find it quite interesting that when I started about seven, eight months ago I started by supporting the data team. So when I joined I was told okay you'll work with two teams so with the firewall and with data. That's kind of it, that's all I knew. So I came in and I started to get to know the team and I understood a little bit about what the team does, what maybe are the challenges, what can we do together. So there was a real green field in how can I as a delivery manager support but I'd like to maybe better understand what did you have in mind. So why did you want to work with a delivery manager specifically for this team? To be perfectly honest I wasn't entirely sure but I have an open mind and I know that we can always do things better and I know as engineers, as people working closely on a project we often have blind spots about what's actually happening and what we can do about it and that we always benefit from fresh eyes and a fresh approach. So I've worked with people in delivery management before or like the equivalent in the old days and I always, I don't think I've ever had an experience where that wasn't helpful or wasn't an improvement. So it was a very easy decision for me. Yeah and you mentioned you worked with people in similar roles in the old days and it's actually true because this is my first role in which I'm called a delivery manager per se. So in previous jobs I've been a program manager, you see people who are scrum masters or agile coaches and I think it's important also to make a little note on that because I think delivery management encompasses all of these aspects, right? So it's not just focusing on a methodology or focusing on a very specific aspect but it's really taking a step back, looking at what is software delivery, what are we trying to achieve and how can we really facilitate support for the teams. Sometimes this can look very different and earlier I was telling you that since I work with various teams, my approach is always very different. So some teams need help with managing operational toil, some other teams might need help with facilitating communication, others might need help with surfacing dependencies and making sure they're not blocked by other teams, right? So at any given time there would be a very different approach that I must take depending on what the team needs at that moment, right? So I think even with data as well we've gone through different cycles like that. Yeah, I'm sure that's true. I mean I think the common thread that I've observed in our industry through my career about this role is that it takes on many forms and in each situation what you have to do is a bit different but the common thing is that it's generally undervalued. We don't realize how important this is when actually it's possibly the single most important thing is to actually produce a product that's useful and ships on time. It's incredibly important. So each situation by itself is a bit different but the overarching goal is always the same. And you know what I learned here in Cloudflare because you mentioned that this is a really important role in ensuring delivery and I do definitely agree with you not just because it's my job but because we've seen the value of that. But I also want to note that even if sometimes the work is invisible I think it's still a really satisfying role because at the end of the day you see stuff in production and you know that you contributed to it. Some people contribute by writing code, some people contribute by bringing in the customer perspective and delivery management contributes by organizing people and processes so we can be more efficient and optimize. And that's what I want to talk to you next Jamie. Maybe outlining a little bit how do we work because I think there is this trifecta in our engineering teams at Cloudflare where you have the engineering manager or engineering director or somebody who leads the engineering team, a product manager and then you'll have the delivery manager. So what do you think is a good recipe for success for a good collaboration between these three roles? Yeah I guess the fourth thing, you know we have these three organizations and these three roles that combine but the most important element is actually the culture I think. So Cloudflare has a very interesting excellent culture I think. I don't know what your experience has been but I was kind of blown away by it and I had to relearn some things about work in general after I joined Cloudflare and I think that that is the enabler for this. That you know each team or each trifecta, each combination of three like might take a different approach in the specifics. How we track our work, how we set our goals, how we communicate, that is all totally fine and great because actually people are different and teams are different and preferences can be different and the outside world doesn't see any of that and really doesn't care. Like you know like what whether we use a Kanban board or like a JIRA something or other like it doesn't really matter to anyone outside of our small group but what does matter is the end product and we want to have we want to be able to make great products quickly and reliably and the thing that the culture provides is a way for people to be open to ideas and to improving and that if we do that consistently we're we're on the path to making good progress towards having those bigger goals. Yeah and I think you're right with culture and kind of understanding how do we work together and everything and one of the good things about you know working with teams in Cloudflare as I noticed is that I am able to embed in the team. I feel part of these teams honestly like I understand what they do, I participated their stand-ups, I know kind of when somebody is happy because something worked, when somebody is maybe worried because something broke in production right so I think sharing all of these things with the team also helps a lot right and it also helps me kind of understand the culture a little bit better because there is you know this wider Cloudflare culture but every team will have their own small rituals and programs right that will differ slightly but then that means that they create their own identity and I think people are very very proud of that right and sometimes I wonder like it's a bit strange to be part of three different teams am I really part of either or of all of them so probably I'm I like to think that I'm lucky and I'm part of all of these teams and I'm hoping that this is you know reciprocated by my other colleague who works in delivery management right but it's an interesting view to say yeah culture is what leads any good relationship here because I think you are right yeah yeah it's it also is what kind of leads our productivity in a sense right because we're not relying on the process entirely we're we're relying on the culture and the people to drive it yeah I don't know if the audience out there is understanding what what I'm trying to say is like we offer a lot of independence and responsibility to everyone with the expectation that we're all trying to do the best thing for the customer and that goes a long way I mean I have a lot of trust in you and with every member of the team to do the right thing and to help us improve and I think that I don't know that it seems to make it all much easier right so when you joined our team we were all thinking hey this is this is actually going to be a real benefit to us and the customer and it was and you know this is this is actually what I noticed when interacting and talking to most people not most people all people in Cloudflare specifically in the in the engineering team because as I mentioned earlier and also in in other Cloudflare TV segments this is a fairly new function of Cloudflare so we're we're kind of trying out different approaches of supporting teams as delivery managers and what I've noticed is either people being super excited because in the past just like you you had they'd worked with this function under different hats it doesn't really matter or they hadn't done that before but they were really curious and really accepting and I really like that you know because coming in and knowing that maybe a lot of people haven't interacted with this function what if it's gonna they're they're gonna create a blocker over there but I haven't seen that at all right so I think the the fact that people were were curious and open-minded about this and really accepting help even in situations in which they didn't really realize they might need help or things could be done differently I think that had a lot of value because I think you sometimes get lost in this is how we do things it's working it's fine and then if we point out that things could be significantly better it's like an aha moment for for a lot of people right and everybody was quite quite open towards this kind of change and working with a totally new function yeah I think it was really important that there was a big driver from from your side so from from a leadership point of view to to get this acceptance as well yeah I don't I don't feel like I I contributed that much to be honest I mean but this is this goes back to our discussion about culture so for me to say here's an interesting idea let's try it like that that's pretty much all I have to say and I appreciate a culture where that that's accepted I mean and I feel like it's it's mutual so when when we have suggestions for how you guys do your part of things like every everyone seems always open to that and willing to work with our shortcomings as well yeah and talking about that because we're talking a lot about the positives and good things in the interaction in the culture what would you say are challenges when when delivering software particularly when working with with somebody who you know facilitates delivery management for your team? You know we at Cloudflare we're we're a very dynamic organization and so we're changing many things many times all the time and it can be overwhelming part of part of your role is to help us get that under control but it's it's not right and I don't know if it ever will be in a point where we will just say oh actually I know everything and when it's going to ship and it's all fine I don't know if we'll ever get there but if if if if it would be a mistake if we got there part of our success I think is is built on being able to operate without full confidence in that. Yeah and and and talking about changing things and everything so we I noticed when when I joined I noticed that in in data we we replace a lot of products and services and one of the challenges that I found with the team was managing deprecation right so I think for for most teams if they have a choice between working on something shiny and new and working on a new exciting project or product and maintaining maintaining or deprecating some older service I think it's clear what most people would choose right and also because we want to be we want to be really really fast I think at one point we we decided we realized actually we have so many things that we're we're maintaining even if they have been replaced by better services so one of the one of the things I feel very passionate about in in data is is pushing for for deprecating stuff first of all because I think a lot of people like to delete code but also because it creates a much healthier um yeah a healthier tech stack for us and even more importantly I saw how happy the engineers are Jamie so it's incredible to see oh the relief for um when when when getting into this cadence of of really recognizing we've done this better let's um let's slowly sunset and and let go of the older system so how do you see that how do you see the balance between technological improvements and new products well so you you mentioned so there's different things actually so deleting code is always a good idea and and I wish we we could just dedicate people to just go through and delete code all day because that always makes things better it improves efficiency improves reliability it improves even onboarding because there's less code to learn like it it makes things better in every way if it's possible to delete code without losing functionality we should always do that but in a way that's separate from deprecations in some setting because um we do that for us uh um the the deprecation we do like um in order to make the world better or the outside thing or the experience for the customer and and that involves I think where we've stumbled with that is to recognize that really it's a form of communication and dependent on communication with the customers and um it's possible to fall into this mode where we we're doing that for ourselves and we just say like you know we're going to do this and we're what's and that's it and um we we at our peril we forget that it's a sort of a two -way communication with the customers and the the the real reason we're doing this is actually to make it better for them because we're going to make the system more reliable this new api is more functionality it's much faster all of these reasons and where we stumbled a bit in the past is in this ongoing communication yeah I had an experience recently where I spoke with a customer and and they pointed out that we had made a change that really impacted them and they had no idea why and I felt bad and uh I had played a role in making that decision to to do the thing that impacted them and it was the right decision like we had no choice in some regards it made everything better it was the right thing to do well where we stumbled was just explaining it like why why we're doing this why it's better for them what what what they can do about it um well I see the challenge here and the you know like as heads down engineers we're not good at this like I I don't have a capability to to talk to every customer but I feel like part of our process as a team we can improve this dramatically and it'll be better for everybody yeah and actually this is this is one of my wins for from the last two weeks uh to be fair um is is deeply understanding actually what steps do we need to take in order to uh to really communicate to customers you know early uh and clearly so that they know if they need to do anything what does that mean for them exactly as you said how is this going to impact them um and and that's why I feel a little bit on a on a high with this because I realize it's not it's not as daunting as it sounded initially um so once we do once we do it uh we do the first time then it's so much easier and um and actually it's a pleasurable thing to do you know you know it's going to have a direct impact and um and a really positive one on both on our side and on the customer side so I'm expecting this to be much better and and managed much smoother uh moving forward so this is my promise for myself because uh it was hard you know to navigate through all of that process yeah it's something that was clearly you know we we haven't done as well in the in the past as we should have and we can what's exciting about it is that it it seems solvable like we can definitely make it better and and we should consider all of these things basically are upgrades I mean these these older systems they're not as good we have we have better systems uh either in place or on the way so we just need to communicate that yeah that's true um I know we have um we have a few a few minutes left um what if we reverse the roles do we have any questions for me Jamie well uh yeah so I was going to ask you um so you've been at cloud for for a while now you've been in this role here and other places like how how do you judge whether you're successful or not or or or how we're being successful as an organization yeah I think these are two things so in in previous I've had jobs in which I had really really clear objectives on metrics and numbers basically that would define my success and then would inform my performance evaluation um I think what we do what we do here is we look we look at success a bit more holistically um so the way I judge my my own uh performance is to look at okay what teams am I working with and what are the objectives there um what we want to ship and how do we do it and is it um a quality product right so we look at um first we look we look internally at what is the development experience so we look at metrics like um velocity operational friction um yeah and and cost this is something we will look at more and more to kind of understand really what are we doing and what is the value of what we're delivering um and and what does that cost us as an organization and then on the other side there are the organizational metrics which will include customer feedback so are customers happy with what we're doing are we providing value to them and then on the second side is on the reverse coin is is the team happy so um team happiness is actually um an aspect that I'm very very keen on particularly because I think it can tell us so much it can tell us a lot about people burning out about workload about career development about all of these things but I think overall we we don't particularly want to look at individuals or at least me as a delivery manager I look at the team right the team the product um and and less so as in the individual cases because I think that that's very much also the role of the of the engineering manager who has the direct reporting responsibility so I measure success when the team is happy with what they're doing and I think that that will be broken down into having challenging work that intellectually challenging work having the right tools and at their disposal to be able to do that job and also have enough control over how they do their work on the other side there's also a recognition that there will always be friction there will always be dependencies and you will need other teams and then communication might not always be perfect and that's fine as long as the team has the trust that they themselves or somebody can help them through it right so that's part of the success and then on the other side is literally what are we shipping are we are we shipping good value products that are helping uh are helping our mission right so are we helping build a better Internet at the end of the day through what we're delivering there so I look at these two aspects and then if the answer is yes the team is happy and yes we're delivering quality products I think that's successful but it sounds overly simplistic right so we also have a tendency to kind of stumble upon a lot of metrics and a lot of numbers and just break it down looking at literature because I like to I like to read about what's happening in the in the space what are the recommendations from researchers and everything there are so many metrics we could we could track but I think maybe right now for Cloudflare for the stage we're in right now it's better to start small so to really look at okay are we shipping good stuff on time are there is there a lot of pain within the within the team interaction that we need to address and are people happy ultimately I think this is how I define success currently maybe this will evolve oh I really like that I I think we we overlap quite a bit in our definitions yeah I'm not here there's this great I think it was uh John Kennedy President Kennedy misquoting Plato he said something like that the definition of happiness is the full use of one's potential along the lines of excellence and and and like as engineers we often feel that way like there's no better feeling than doing a good job on something yeah often the there's a there's a feeling which might be true that the reason you can't do a good job is because the organization is preventing you from doing that and and I think at Cloudflare we're we've done a good job of avoiding that scenario yeah I I agree and you know the first question I asked everybody that I interacted with when I joined was how do you know you do a good job and um most people actually were were quite aware of that and and I like seeing um yeah I like hearing the these these answers because it's really it really shows the what what is important for the organization and for the people within it yeah so we we started with the we're talking you know you you work with a number of teams and you and I work with a number of teams we were specifically talking about the data team and I'll put you on the spot and ask like how are we doing um I think we're doing I think we're doing well I think we're doing better so um not just recently but I mean in the last few months at least since I've observed the data team um I've seen a number of of impressive products that we've shipped a lot of interesting things um and I see people being excited about what they work on right so um in that sense I think it's it's going well and I really like the interaction with the team also on a social level um there's always room for for better and for more I think that what's what's holding us back right now is the fact that we want to do so much that it's really really hard to pick you know um and and that's one thing you know prioritization is is a really important aspect also of delivery management to really understand what where do we want to put our resources in like where do you want to put your your mind into um and make sure that you you don't commit to too many things because then it might be difficult to to deliver anything right absolutely yeah I'm even more pumped after the discussion good so Jamie you have a minute left um and I have a really really quick question for you so if uh if tomorrow you speak with one of your peers so another engineering director and you want to tell them one two things about delivery management to encourage them to work with uh with me and my team what would you tell them I would tell them that like it's it's really unlikely to be a mistake and that with an open mind you you can only achieve more um I mean I I feel like there's there's no downside there's only upside yeah oh that's that's really really great to hear Jamie and actually we only have a few seconds left so I want to really thank you for taking the time uh today to to speak to me and to us in Cloudflare TV and uh maybe we can do another session thanks so much thank you I really enjoyed it