Story Time

All right, well good morning from a very wet Lisbon where I am John Graham-Cumming, Cloudflare's CTO and I am joined today by Alex Moraru who is the Lead Delivery Manager for Europe, actually for EMEA, right?

So Alex, welcome. Hi John and hi everyone, thanks for having me.

Actually, you should know that in London it's fairly sunny and nice.

No, no, I don't believe you. It is. I didn't move to Portugal for the weather to be better in London, so you know.

Well, it's just one day, so. It's just one day, exactly.

Well, we are very lucky here with the weather here. So, well listen, welcome.

Thanks for coming on this story time where we talk about, well, stories and also, you know, what people do and how Cloudflare does stuff.

And what I thought was interesting was when Jen Langdon suggested that you come on, so Jen's the Engineering Director in London, was that you actually help us deliver stuff and if you've been following along for Cloudflare stuff in the last few weeks, we had birthday week where we had an announcement every day and then last week we had Zero Trust week where we had at least one announcement every day.

Cloudflare loves shipping and you're a part of that and so let's just talk about delivery.

What does delivery mean? Yeah, so it's true that we like to ship stuff. So, where the delivery management function comes in is to help us optimize the way we ship, right?

So, this is a growing function in Cloudflare. We're currently a couple of people supporting various product engineering teams in improving the delivery practices.

So, we've set this up recently because we wanted to provide more support, a little bit more structure and guidance to product and engineering teams in order to maximize efficiency for delivering, you know, the key results across product and engineering and all other business stakeholders.

So, we work with different teams and provide kind of a tailored approach on how can we optimize, you know, the people we have in the team, the processes we have, the technologies we use in order to maximize our results.

And one sentence I like to say when talking about delivery management and delivery managers, in a nutshell, we want to increase our output with our existing resources and practices and also decrease the incidents that happen, right?

So, it's balancing these two things out for the teams that we work with.

All right. So, practically speaking, when I think about things, you know, in London, where I used to work, we have Jen Langdon, who's the engineering director.

She has a lot of teams underneath there. Those teams each have a manager.

The managers have their, you know, individual engineers. Why does this function actually exist?

You know, in some organizations, you might have the first-line manager be responsible for this kind of thing.

And so, I mean, I'm sure you're going to help us understand and argue why a separate delivery function is important.

How does it differ from what the engineering manager does, from the product manager, or even for somebody who might have the title project manager?

Yeah.

And actually, it's a really good question. And I get this from a lot of people, and it's very valid.

So, what I want to start with is to say that the delivery management in itself is the function that can be fulfilled with or without a delivery manager, with or without a program manager or project manager or anything like that, right?

So, there's going to be instances in which an engineering manager will take care of what typically a delivery manager will do, or a product manager will do so, right?

However, in order to really optimize and make sure that people can do what they're best at, it's important to also streamline some of these responsibilities.

So, to give you an example, you might have a team that has an engineering manager who is responsible of the direct management of the engineers, of making sure that they're happy in their roles, of improving and increasing within their career and their learning, and also taking some technical decisions in terms of architecture of our product and our platform.

Yeah? On the other side, you will have the product manager who will be the direct connection with our users.

So, how are people using our products? What would they like? What are the trends in the market?

So, what should we build next, right? So, between what we build and how we build it, there's this gap in this space where a delivery manager will sit to help bridge that communication.

So, you'll have what do we build, how do we build it, and then you'll have all of the detailed questions on when do we do this, who else is impacted, who do I need to work with, how do I find out some information.

So, all of this streamlining of communication, maybe unraveling some dependencies and making sure that the impact of what we're building is understood, is very important and it's something that the delivery manager will lead.

So, imagine in a team like ours, so we have hundreds of engineers and multiple teams and as much as we want all our product and code base to be independent, there are things that will impact other teams and we will depend on others to be able to do our jobs and to deliver our products, right?

So, all of that communication and connection is where a delivery manager can bring a lot of value, right?

So, I think in the new trends in software delivery management, particularly, you will see more and more people talking about the value stream.

So, the value stream is not something that you'll have something very defined with products, something very defined with engineering and then it goes to users.

No, there's this fluid approach where there's multiple teams involved, multiple decision makers as well.

You'll also have to make sure that the end-to-end product is understood internally and also externally, right?

So, this is where the delivery manager will come in with this holistic view and also tailor their communication and their support to each of the different teams that they're working with.

So, this morning, I had the chat with customer support and then maybe they need some further guidance on how a product is functioning, maybe a new feature or something that we're resurfacing and then they will need a very different style of communication rather than going directly to engineers and asking questions and distracting them from the work that they've already committed to.

This is where the role of a delivery manager can come in and that was just one example, right?

So, you'd also ask me about the difference with a project manager and it's true that I've seen this role represented with the various titles.

So, in a previous job, I did something very similar for a B2C company but my title was program manager, right?

So, it's making sure that... Sorry? Yeah, right. I mean, that's another title that gets used, right?

So, it's interesting to unpack how these things differ slightly.

Exactly, but I think it depends a lot on the organization in which you're in because I was a program manager in a logistics company, right?

So, it had nothing to do with our ability to deliver software but it had a lot to do with our ability to improve processes and deliver physical goods to clients, right?

Because it was a large logistics company, right?

But slowly moving into software delivery requires very different skills.

So, project management, yeah, at the core of it, definitely you need to have some of those skills.

However, it's not enough to be able to do project plans and write down the milestones and then check in with people if they're doing what they were committed to.

It's much more to it when you think that we've moved very much.

And I don't know if Cloudflare has ever had this very strict project approach.

I would believe not. It's more we're a product-led company at the end of the day, right?

So, we're delivering that value to customers directly.

Yeah. That's right. That's right. We're very much about shipping features and products to customers.

It was not like a waterfall kind of thing where I was like, we've got all this stuff set up, we're going to deliver this one thing.

It was like a constant.

A few years ago, we would have said agile. That was the fancy term way of doing things.

But yeah, it's definitely the case that we were not project focused.

We're very much about delivering something to the end user. Yes. Yeah.

But you would be surprised actually, I was mentioning earlier to you that we're hiring in the team.

And I see a lot of applicants actually from all of these backgrounds, people who were maybe technical project managers or service delivery managers.

And there's still a lot of organizations who are going through this digital transformation, moving to agile practices.

And it's really important also to understand these practices, even if they're already embedded in our engineering teams.

I wouldn't dream of having a conversation of what is agile? How do we do this?

Because I think that the people that we attract are very much experienced in this way of working.

So the delivery manager won't be an agile coach necessarily, at least not in Cloudflare, but we will come in and actually help improve the existing processes.

So I hope I'm not too bold when I say that we can be very, very good and very fast at delivering everything and maybe we'll be 98%.

I think that having a focused role of delivery management will bring us and will make the difference between that 2% and 100%.

And I think that for the bottom line, it makes a really, really big difference.

Yeah. Just to go back to the hiring thing.

So one thing I was thinking about asking you, which is, this job obviously contains some sort of what I think of as technical stuff, which is tracking things and figuring out what's happening in the interconnections, but also a lot of soft skills because you're dealing with a lot of different people across different departments.

I'm wondering if someone is listening and they're thinking, I wonder if this is the right role for me, how would you sort of talk to them about what it is every day and the sorts of person who might enjoy this job?

Yeah. I think one very important skill, and maybe it's not a skill, maybe it's an ability, it's or a mentality, is managing uncertainty.

And I think this is a lesson I learned a few years ago.

For this role, to be successful in this role, you need to know how to manage uncertainty and actually you need to be comfortable with that.

If you're the type of person maybe who likes things very well established, to have very clear guidance, to be kind of told what to do, what good looks like, it's maybe not the right type of role, at least not right now in Cloudflare.

There's a lot of things that are unexpected. There's a lot of initiative to be taken.

You must be very proactive in your approach, very curious. And also, you need to not be shy and ask questions and just probe, the idea of the five whys.

Why is this happening? What is behind it? Why, why, why? To actually get to the root cause.

Because only when you're bold enough to ask these questions and without making any assumptions beforehand, will you get to actually the root cause that is causing maybe some challenges in the team or some frustration or that are causing some blockers that are stopping us from advancing as fast as we want.

So that's one, the idea of managing uncertainty. The second one probably seeps from it is the idea of not making any assumptions about anything.

But also, there is an element of being organized.

And I spoke to a few of the product managers that I work with, and they mentioned that they really need help with getting the teams organized in the sense of, I mentioned documentation as an example earlier, or as you said, tracking, what are we measuring?

What is important for us so that we can capture what we want to optimize?

Everything from facilitating conversations and actually being organized enough to do the follow-ups for those.

These activities help the team a lot because it takes away from kind of the operational burden of having to do it themselves.

And I mentioned facilitation. The ability of putting people together and having them speak to each other is really important.

I've seen in previous experiences, a lot of situations in which if you hear the one story or situation from various angles, you'll hear more or less the same trending complaints.

And this is also because sometimes people don't think of speaking to each other and addressing a conflict or an uncomfortable situation head on.

So I think that this is an important skill to have, not be afraid of having difficult conversations.

Because it's all nice when things are going well, when we have no problems, we all get along.

But that's not always the reality. However, there are simple solutions to that.

And providing that level of communication is really important.

And I know I'm talking very much in abstract terms, John.

So you mentioned, what does it maybe a day-to-day look like? So I can talk to you about what does the support of a delivery manager look like?

So for example, we look at what is the team structure currently?

How can we optimize it?

How are we currently delivering the key results? How are we communicating these?

So ensuring that transparency within the team. Measurements. So for example, the KPIs that we're focusing on are team velocity.

I mentioned earlier the idea of increasing output and decreasing incidents.

Obviously, with velocity, we also look at the kind of issues we're causing.

So if we have an incident, what can prevent it?

How can we streamline that process and make sure that whenever something happens, we have a good process and a way of addressing the root cause?

Introducing a structure of revising the KPIs.

I mentioned velocity, but we also look at, for example, team happiness and removing operational friction, which happens a lot.

The bigger the organization, the more it will happen. So having come into Cloudflare, having been here for a while now, now you see how the Cloudflare sausage is made.

What were the things that maybe they surprised you, or maybe you have a long enough experience, you're like, well, this isn't really a surprise.

I would have expected this at this level of maturity. But I'm curious about what were the things that when you came in, you observed where the delivery function could really make a difference?

And how did you go about altering things within the organization?

Maybe one thing that surprised me, it's not a good or a bad thing.

It was just different than the way that I was working previously.

So a very interesting thing was that how embedded our QA function is in the day-to-day life of our developers.

So we don't have a separate quality assurance or testing team, for example.

So we leverage a lot automated testing.

However, one of the things that we're bringing in more and more, particularly for product-led work, is working more with UAT.

So working closer with the product owner and let's say the beta users of a new feature to really test it out.

I'm going to briefly interrupt you because you've used an acronym, and then maybe you're a listener who doesn't know what you mean.

So UAT is? User Acceptance Testing. Yeah, sorry. Yeah. So what does that actually involve?

Just so that people get a sense for what actually goes on. Yeah.

So that means that whenever we have a customer-facing product or feature or a change, let's say, we want to talk directly to the users of this new feature to test it out.

Obviously, maybe we're too much into the middle of it to understand and see if the usability of the product is good, if maybe there are other ways of implementing this.

So we do that in collaboration, obviously, with our product management team.

And then they select some customers who can play around in a sandbox environment with this new feature and provide some extra feedback.

Because we'll have clear requirements and then the code runs as it should.

However, maybe there are some changes that we ourselves don't observe because we're too involved into how the product works or how we think it should work.

We're typically not our average user, and it's OK to accept that.

Also, there's a real problem when you're super familiar with something you've been building, where you can't see the things that others will see.

It's very hard. It's a very special skill to be able to step back and actually see that and see what's missing or what doesn't work so well.

OK, so that's great.

So that's the UAT part of it. Sorry, I interrupted you. That's fine. And obviously, we want to do more and more of this because, as you said, we like to ship a lot of stuff and very quickly.

So we have this very iterative process of releasing very often in small increments.

And this is good case practice, I think, in many software organizations.

Coming back to what surprised me, I mean, I was positively surprised by a lot of things.

And I don't particularly think that the role of a delivery manager is necessarily to just bring on change.

I mean, I'm here and my colleagues in delivery management are here particularly to support the teams ship better, maybe in a better way.

And that will depend on the type of feature that they're working on, on the way that they communicate with the rest of their colleagues, and how actually we're monitoring even after deploying in production.

So we're looking now at having that, I call it hyper care, but maybe this is from my background.

Once we launch something, obviously, we'll monitor and we want to make sure that we have the right systems in place to notify us in advance of something happening.

So having that mindset is also something new. We can always improve on it and make sure that we have the right dashboards, but also we play around with our own product and make sure it works.

Right, right. So, you know, you obviously really like this job, doing this kind of work.

Let's just talk a little bit about how you ended up doing this.

And in particular, what it is you love about it, because it comes across that you really do.

So let's just talk through that.

Yeah, it's good that it comes across because you're right. I really like what I do and how I came about this.

So my background is not in software delivery management, obviously, because probably, you know, 10, 15 years ago, when I started working, I was looking into something else.

But I did start working a lot in project management and process improvement.

So what bothers me very much in general in my life is inefficiency, John.

This bothers me to a level that it's funny, actually.

I'm really, really happy that you can't see my desk here. I'm surrounded by crap all over my desk because I'm the worst person for efficiency.

So I'm really happy that I've got this background and we're here. I appreciate it as well.

Trust me, it would make me a little bit anxious, probably. But this is what drives me.

So I really like looking at situations and trying to understand, oh, how can this be made better?

So for a while, I actually, because, you know, Amazon is an example of a company that is trying to improve a lot of things.

So I did send a lot of unnumbered emails to the CEO, telling them, actually, I think you should be doing this better.

And this is how. And that's just taking from my time.

So coming back to my experience, this is what drives me a lot.

I like to help people do things in maybe a better, more efficient way. And with a background of project management and a lot of process improvement, I mentioned I worked in logistics.

So looking at how we can optimize the processes there, you know, in a warehouse, which was quite exciting for me.

But then when I moved to the UK, I actually started working with a technology research firm, right?

And that is what got me into how can we optimize and improve the way that companies work, you know, from a technical perspective.

So it wasn't just working with software companies, but a lot of actors in the market.

But my interest was specifically in delivery management.

So everything on DevOps, application development.

So that's how I kind of started shadowing more and more the analysts who are writing about this and who are advising customers on how can they improve their practices.

And from that, I actually started working with tech startups.

So I had a startup that actually believed in my ability to come in and learn fast enough and then use my existing skills to help organizing their team, their delivery practices.

Obviously, they were doing much more custom work. So there was a large element of customer engagement there.

So that's how I actually started working with software delivery management and kind of building software and delivering it to the end customer.

But now I'm very happy that slowly I've transitioned through a B2B company as well, a B2C company, sorry, doing this.

So being very, very close with the engineering teams and focusing a lot also on mobile, which I know that we do less of here at Cloudflare, but it's a different beast.

And now I'm quite excited to be in a company that is really focused on engineering practices and delivering value to customers through technical work.

Right.

Did 2020 change things from a delivery perspective or is it just, well, we keep going and we keep delivering?

I think I'm tempted to say that, yeah, we keep going and keep delivering, but I think that the reality is very different in each and every team and every company.

So again, I haven't seen Cloudflare before 2020 because I actually joined in the middle of the UK lockdown.

So I was one of those first generations onboarding online.

So for me, it doesn't change much because I'm used to interacting with distributed teams, for example.

So anyway, whether you're in the office or not, you're still going to be on a Zoom call.

So from that perspective, I don't know.

I think, however, it's important, probably 2020 made us a bit more mindful about how some of our colleagues are coping with the situation because on a human level, everybody is impacted, right?

So remember, I mentioned earlier when talking about metrics, the team happiness, I think it's really important to acknowledge and to also track that because we might have surprises with team members who need a very, very different approach of management and communication while they are remote versus then when they're in the office.

So that's what changed. I think the human interaction changed a lot. I wouldn't be able to say if strictly our ability of delivering on time has changed particularly because we've adapted.

And I think in Cloudflare, we've adapted really, really well with this.

And some people who watch the show will know before that I've mentioned this before, that Cloudflare is not going to go back to offices until at least July of next year.

So we're in for this video-led world for quite a long time.

Are there trends in delivery management in 2020, 2021? What's happening in that world that we should know about?

Interesting. I was recently reading a report on software delivery management, the state of report.

And then in terms of trends, I think that we'll see more and more organizations adopting this function and providing legitimacy to this function.

So not just the activities themselves of doing the work of a delivery manager, but hiring or looking to hire delivery managers to focus specifically on how we ship.

I think you pose a really interesting question on how does kind of the global context influence the practices.

And we're probably going to see a lot of changes and trends. One thing I will say is that one of the things we've had to adapt to a lot is the way that we communicate.

And also some of the practices we have when scoping new engagements, new features.

We were used to having these two, three hours discovery workshops with flip charts and post-its and colorful markers.

Right now it's very hard to lead these as much as we want to.

So we have to break it down. And this is, you break it down maybe in various sessions, or you become a little bit more efficient on how you're doing that, how you prepare for this, the kind of information you provide to the participants beforehand and asking them to actually prepare.

It's not just a brainstorming session where you just come in without thinking about it before, but you need to be very, very focused.

And the role of the facilitator there, which sometimes can be the delivery manager is really important.

And the same with the follow-ups from that, because otherwise it would just turn into, instead of having a three-hour discovery workshop, we're just going to have maybe a one-hour session.

And then we realized actually we didn't do anything.

And then you keep wasting time doing this without the preparation. So a lot of thought ahead of these kinds of sessions is going to be probably more important than it was before.

Whereas before it was acceptable to not prepare, now it's not the case because you won't get anywhere.

I think that's a very interesting point.

I think I've seen that in other situations where there's something about people being remote on video that you really need to be ready for the thing because it somehow compresses the time and compresses people's patience.

You need to be well-prepared.

Well, listen, we're actually going to run out of time fairly soon.

You've got a team of, what, one right now in London? Is that right?

There's you and Aveda and you're hiring two more. Is that right? Right now we're focusing on immediately hiring one and hopefully in Q1 next year to replicate that.

Brilliant. Well, if anyone wants to find out more, it's Cloudflare.com slash careers is where you can find things.

You'll find the job on there. Based in London, of course, we're all remote right now, but there is a large office in London which actually has a big chunk of Cloudflare's engineering in it.

I think one of the unknown stories of Cloudflare is how much is not done in San Francisco and the Silicon Valley.

There's a big, big, big chunk in London, including many of our core products.

Well, we're going to run out of time. Alex, thanks so much for coming on and talking about delivery.

This is one of those functions that people don't realize exists, is very vital.

It's a bit like oil in an engine, I think. Made things run efficiently.

Well, hopefully you'll be back on in a year's time and you can tell us all about what got more efficient, what were the other surprises after a year.

But it's very good to have you here. I personally think this is a very important function and I'm really glad that we have it and welcome.

Thank you for joining during the pandemic.

I'm sure that was an unusually stressful thing to have to do, but good luck.

Cheers. Thank you. Thank you for having me, John. Cheers, Alex.

Bye.