Julia Harrison

Hi, my name is Julia Harrison. I work at the Government Digital Service, or GDS as we call ourselves, which is part of the Cabinet Office. I am a head of product, and one of the areas I look after is reliability engineering.

This talk is called "Leading Smart People." I want to start by quickly talking about something I hear sometimes, sometimes from the product managers I work with, but also sometimes from tech leaders. These are some lies that people tell themselves. Maybe at some point in your career you told yourself lies like these, or maybe the people you work with tell themselves lies like these right now: "I should know all the answers," or "I'll only be respected if I'm the most technical," or "I'll sound stupid if I ask questions," or "I'm an imposter here."

I've got good news for you on that last one. Unless it's your first week, you can't be an imposter. Worst case, you're an infiltrator. I don't know if you noticed, but on my first slide I had my Twitter handle, and my Twitter handle is JuliaFromIT.

I haven't worked in a traditional IT department for quite a while, but I started out in desktop support. I spent about 10 years working on support and Windows infrastructure projects. I got into IT service management, then service improvement, and from there I got into product management kind of by accident. Some years later, here I am, head of product, looking after reliability engineering at GDS. So I'm totally an infiltrator. Don't worry, I'm not a spy. I am security cleared.

I started this talk with this quote from Michael Dell: "Try never to be the smartest person in the room, and if you are, I suggest you invite smarter people or find a different room." So, okay, we know we're not supposed to be the smartest people in the room, but if the leader isn't the smartest person in the room, then what are they?

By definition, a leader is someone people follow. It's not the job of a leader to tell everyone what to do. It's the job of the leader to set direction and inspire people to follow it. Not all leaders even have line management responsibilities. A good leader is someone people follow, not because they have to, but because they want to. If you want people to follow you, we should probably know where we're going.

At GDS, we have reliability engineering teams, and we have product managers with those teams. That's not something that's common in a lot of organizations, I think. But something that having a product manager does for a product is set a vision, and they do that even when the teams they work with are reliability engineering. A vision should be an ambitious, inspiring, achievable statement about where we're going.

Here is the vision for one of the areas I look after: we transform government by making it simpler to build digital services and run them the right way. Your vision should be something your stakeholders and your wider organization can buy into. Get them excited about it because, first off, it's helpful securing funding, but also because it will come in handy getting their support in sticking to your strategy.

Speaking of strategy, you'll also need one of those. Strategy is how we get there. It is one of those things you often mean to do, but you often end up putting it off because it's hard and there are always more urgent things to take care of. But you might already have one; it just hasn't been written down. If you find it easy to make coherent decisions about what to do and what not to do because you know the direction you're going in, actually, that hints that you already have a strategy. You just need to figure out what it is and then articulate it.

Strategy should exist at all the different layers of your organization. Everyone should have an opportunity to contribute. It's not just a thing that some managers dream up.

If you don't have a written strategy right now, I started out by thinking about what is a minimum viable strategy and what should it do. I think, for me, it needs to be two things. It needs to be a communication tool, both for ourselves and for others in the organization, and it needs to be a decision-making tool. Would it help us decide which things we should be doing against which things we shouldn't be doing?

Here is our reliability engineering strategy. We want to bring things together on a common platform, and in our case that common platform runs on our PaaS. We want to promote and use continuous deployment. We want to look at serverless. We want to use the shared responsibility model, and we want to have a standard approach to how we support our services.

Hopefully, that's just specific enough to help us and other teams understand where we're going. Hopefully, it helps other teams understand how to align with us. Or if they think that we're wrong, it gives them just enough information to come and challenge us and ask us what we're talking about.

Another thing about strategy: it should be stable, not rigid. If it feels like you're doing wrong things because the strategy says so, that's a really good clue that you need to challenge your strategy. You need to revisit it. It's really important that your strategy should be serving you, not the other way around. If everyone in your organization contributes to developing it, hopefully they also feel empowered to challenge it if it feels like it's not serving its purpose anymore.

So: autonomy, mastery, and purpose. If you've read Dan Pink's book "Drive" or seen his TED Talk, these words might look familiar. These are the conditions he calls out for intrinsic motivation. That's the things that make people excited to come to work. They're not just dragging themselves to work to get paid. He mostly applies it to individuals, but it works just as well for teams.

To look at it another way, why would you hire smart people and not give them these things? Why would you hire smart people and not give them autonomy to figure out how to do things? Why would you not want them to build mastery and carry on being smart and being better at what they do? Why would you not want them to feel that they have a sense of purpose, so they feel like they're contributing towards something meaningful and actually want to do it?

If we're setting an inspiring, ambitious vision and a strategy, we're giving people a sense of purpose. Awesome, we've already got one of these ticked off. So what next? What else do you need for people to want to follow you as a leader?

Even if you have line management authority, getting people to do things because "I'm your manager and I said so" should be your absolute last resort. You might not have line management over all the people you need to lead anyway, so being able to get people to come along with you not because they have to is a really important skill.

Real leadership requires permission, and you get that permission if people respect you. They respect you when they can see that you add value. When you work closely with a team, one of the most visible ways you can add value is by unlocking the knowledge of the team. This is by having conversations with them that help them get to answers they don't know they knew. That's coaching.

I was really lucky that one place I worked, they made all the people managers take coaching training. The first thing we learned, well, actually, it's the second most important thing. I'll come to the first in a bit, but the second most important part of coaching is asking powerful questions.

These are some of the kind of conversations you already have with teams. It's just useful to think of them in terms of coaching and raising the ability of the whole team.

If you're trying to solve a problem, maybe you're trying to resolve a difficult, long-running incident. Sometimes you pause and you say, "What do we know already? And what if we're wrong?" It's about writing down your assumptions and challenging them and figuring out which are the most risky ones.

This is a good scoping question: do we know what good looks like? There's often a temptation to keep tinkering or keep gold plating things. Often it's good at the beginning of a piece of work to articulate what good enough looks like. That makes it much less tempting to keep on working past when something is good enough and you should have released it.

This is my favorite estimating question: "Two days, is that assuming everything works first time?" The follow-up question is: "When was the last time you had two uninterrupted days of work when everything worked first time?" You find people looking at their hands at that point and starting adding days to the estimate.

Here is a nice agile coaching question: can we solve part of the problem sooner and then do more later? It may be that we have a big piece of work that we need to do, but it may be that we can deliver some of the benefits really quickly just by sequencing the work in a smart way.

There is a conception that product people are very feature, feature, feature, and personally, I tend to be the opposite. I want my teams to deliver on their promises. I don't want them to have to break their necks to get there. I often want us to be realistic about what we can deliver, and I'm usually the one saying, "Can we do less? Can we cut the scope so we can do the smallest thing in the shortest time?"

Sometimes I go too far, and I've learned through my mistakes that if I ask them this question, "If we do that, will you still feel proud of it?" and everybody kind of looks at their hands and doesn't want to answer me, that's probably a sign I've pushed them too far and I need to find out what they would feel proud of.

Finally, I said that asking powerful questions was the second most important aspect of coaching, and actually the most important aspect is listening. If you're not listening, you don't know what the powerful questions are in that moment. Sometimes what might another time be a powerful question could actually push the team to a place where they start to become demotivated and demoralized. Sometimes they need a cheerleader. Sometimes they need to feel supported. Not every time is a good time to be challenging people. Other times, if you're in a state of flow where everyone's bouncing ideas off each other, those powerful questions can be really, really helpful.

By doing all this with a team, not only do you help them solve problems, but they get better at asking the same questions. They start coaching each other, not because you've taught them, but because they see you do it and that becomes how the team talks to each other. It feels great for you because you get to walk in on a team doing this for each other. I heard a definition of leadership that it's winning when you're not even in the room, and that feels amazing when you see a team do that.

Also, it feels great for them. It means they feel like they're getting better at solving hard problems. It's not so much about building individual mastery; it's learning from each other, learning to use each other's strengths, and it's a kind of team mastery. It's a really key component in building a high-functioning team.

That's two out of three. What's the third one? Autonomy.

When you provide value to other parts of your organization, which is most often the case in DevOps, there's a danger of becoming an order taker. People come to you saying, "Do the thing." Or even worse, "Do the thing and do it by Friday." This isn't great for you because it isn't fun to feel like you don't have any control of your work, and it's also no good for your organization. If all you're doing is taking orders from whichever senior stakeholder is shouting loudest this week, where's your strategy and vision? You're being blown around on the breeze. You're not moving towards a destination.

The alternative is to be a trusted partner. What comes to mind when you think about a successful partnership? Hopefully it's not one person directing the other all the time. Partnerships that really work, whether it's personal relationships, business partnerships, or sporting partnerships, are where people build up. They get to know each other. They get really good at communicating just enough about what they need. They build this really deep understanding, and they trust their partners to support them and to always have their back. That's where you want to be with your stakeholders. It's easy to say. You don't get it just by saying it. So how do we get there, and how do we keep it once we get it?

Building partnerships is also a big part of what good product managers do. I'm going to share some tips from the product managers that I work with.

The first one is: don't build things, solve problems. Of course we build things, but why are we building things? Hopefully, we're building things to achieve something. Somebody might come to you and say, "I need a dashboard." My first question would be, why? Or more respectfully, what will the dashboard tell you? Or even more specifically, what action will you take in response to the things you see on the dashboard?

That might elicit a response like this: I need to know in advance when I should add capacity to my platform. Brilliant. Already, by framing the requirement as the problem being solved, not the thing being built, that means you're free to find other ways to solve that problem. Let's say there's some reason right now where it's really difficult for you to build the dashboard they need. But if there's this urgent need to understand capacity, maybe a daily email would fill the need until you can build that dashboard.

As we talked a moment ago about coaching, by asking these kinds of questions of your stakeholders, you're coaching them, and that's fine. It's fine to coach your users, your managers, your manager's managers. It doesn't matter how senior somebody is. If you're asking them these kinds of questions often enough, they will start to get familiar with how to frame requirements in a way that's really helpful to you. They start getting better at telling you what they need, not what they think the solution should be.

Here is another lesson that product managers know in their core because we deal with it every day pretty much: everything is a trade-off. We're not unique in that. Having informed conversations with your stakeholders is often about articulating the trade-offs. Sure, you can have that thing that you want right now, but here's what's not going to happen in order for us to do that.

Or maybe you could have the exact thing you want, and we think it will take us about three months, but we understand the benefits you're trying to achieve. We think we could get you 80% of the way there really quickly by building a smaller thing first. Then the whole thing might take a bit longer, but you get a lot of the benefit much sooner. Would you like us to start with that?

By having these conversations in as open and constructive way as we can, and by giving information to our stakeholders and empowering them to make good decisions, it helps make better choices, but it also helps strengthen our partnerships and build trust with those stakeholders.

Here is another thing we talked about before. Strategy helps you decide what to do, but also what not to do. Once you've got your organization really enthused about your vision and strategy, this is especially important getting out of that order taker role. Any time you're taking on new work that doesn't advance your strategy, it's delaying you getting there. It's delaying you getting towards your vision.

That doesn't mean you never do work that contradicts your strategy. It's kind of a bit like tech debt. You could call it strategy debt if you like. Just like tech debt, if too much of it accumulates, you get overwhelmed by it, and it gets really, really difficult to move forward. That doesn't mean you never do it, but when you do, it should be a conscious choice, acknowledging what it costs you and acknowledging what it's going to cost you down the line as well.

We're thinking about solving problems rather than building things, and we should probably think about how we measure progress. You might be skeptical of how we can do that or how it would even help, so I'm going to run an example.

Let's say somebody comes to us, and we write down the obvious objectives. Our business wants us to migrate all their applications to a new Kubernetes platform. Where I work, we use objectives and key results. The obvious key result here would be: we migrated all of the things. That's not great. Apart from anything else, this could be a months- or even years-long project. Okay, we'll have a party at the end, but how do we measure the value we're adding along the way? It's not just enough to track progress towards that goal. We want to check that we're actually adding value and not just saving it all to the end. How do we choose which things to migrate first? What does this tell us?

I'm going to iterate on that objective and come up with a slightly better one. When we think about what the real objective is, we're not doing it because we love this new Kubernetes platform. We're doing it because we want to eliminate some legacy platform costs. That's usually a big motivator for why you do migration projects.

I'm going to express our key results as migrate 100% of the applications. The reason for that is actually, yes, there is value in migrating 20% of the applications. There is value in migrating 60% of the applications. You can show that along the way because you're reducing costs as you go. That's the second result here, reducing the platform costs. Eventually, we want to reduce it by 60,000 a month in this example. You might be able to reduce it by 10,000 a month by switching off just your biggest couple of applications. That will also help you decide what order to do things in.

But what else? It's not usually only cost that makes us want to get out of old platforms. We'll dig a little deeper. Maybe our objective is to reduce the cost and risk of the application components on the legacy platform. We've got our key results. We've got migrate all the things. We've got reduce the platform costs. But what else? We talked here about risk, so maybe we want to reduce our risk score from critical to low.

If we look at the risk profile of the applications and how much of that risk is associated with them being on that platform, maybe we're going to do a really counterintuitive thing and migrate some of our risky applications first, which intuitively we sometimes tend to avoid. Also, once we start looking at what applications we're running, and this is taken from a real-life example that I was close to recently, maybe we notice that not all these applications require 24/7 support. If we sequence things so that the ones with 24/7 support are migrated earlier, maybe six months before the end of this migration, we can actually stop having to provide on-call support for the legacy platform. That's a win. It's a cost save, and I'm sure people love not having to be on call for the legacy platform.

You've now got different things that you can use to look at and make smart choices about which order to migrate things. This is all part of having some autonomy, getting your team to use their expertise to suggest things by thinking about things in terms of the real objective and the real key results. Hopefully, it drives that kind of thinking.

Finally, the last tip I'm going to share is: get comfortable with uncertainty. This is the hardest one of all. This is tough for all of us. Setting objectives this way, we do it because life is uncertain. By knowing the objective and not the thing we expect to deliver, it gives ourselves flexibility to change how we do it. To do that, we need to get comfortable with uncertainty. That doesn't mean surrendering to it. That doesn't just mean existing in a constant state of "Dunno." Accepting that we don't know the answers is where we start out in order to find them out.

There are some really strong reasons why your great idea or your stakeholder's great idea might not work. This is from a book by Marty Cagan called "Inspired," and he talks about four different kinds of risks that might mean a thing is not going to work. First off, feasibility risk: can we build it or can we migrate it? Is it technically doable? Value risk: will your stakeholders go for it? Will they buy it? Will they choose it? Will they fund it? Will they agree to it? Then there is usability risk: if you're building tools, for example, will they be able to use it? Will they choose to use it? And then viability risk: does it meet our goals? Does it take us towards our strategy and vision?

At GDS, we're quite lucky. Our RE teams, or SRE, are cross-functional teams like any other. We have access to product managers, interaction designers, content designers, performance analysts. We have people who are specialized in each of these kinds of risk. You might not have those people in your teams. I appreciate it; we are quite lucky in that respect. But if your organization has a product management community or a design community, for example, they might be happy to help out. Even if it's just an informal chat about what it is you're trying to do, they might be able to give you pointers. If these are challenges that you care about and want to learn more about, think about how you can connect up with those communities and get them to help. Also, a lot of technical PMs come from engineering as their background. If you really love these sorts of challenges, maybe think about a career in PMing.

Getting your stakeholders comfortable with uncertainty is often easier than you'd think. We don't just say we don't know. We talk candidly about the cost of getting it wrong, and then we set out the steps to reduce that risk by learning more. You recognize this because it's the heart of Agile: how do we do the least to learn the most to reduce the risk?

We start out by stating what is our biggest unknown, and what is the cost of getting it wrong. If you've got two ways forward and you actually think maybe one's 5% better than the other, maybe, and it's really difficult to choose between the two, if the cost of figuring out which one is better is bigger than the cost of getting it wrong, flip a coin. Don't waste your time. But look for the ones where the cost of getting it wrong is big. Then the next question is: what's the cheapest and quickest way to learn more?

By having these more transparent conversations, by learning the real needs of your stakeholders, over time you get to a place where you understand each other better. It starts to actually feel like a partnership, and you and your team can stop being an order taker and become this trusted partner. Hopefully, you get to a place where other teams come to you with problems to solve, or even when they don't fully know the problem, they just want to bounce ideas around. That's the kind of thing you get in a partnership. Your teams can use expertise to advise them to figure out how to solve these problems. You build a relationship, and you also get more autonomy for your teams.

You've got your team of smart people. They've been given the autonomy to use their expertise. They've got the coaching techniques to get the best out of each other and build real mastery as a team. They're inspired with a sense of purpose from having a clear strategy and vision. If you create those conditions, people will want to follow you. That's leadership.

I'm going to come back to this image that we had at the beginning of the session. It can feel like a really daunting responsibility being the leader, but hopefully, you know now: you don't have to know it all. You have the knowledge and the skills of the team behind you, and your job is to set direction and give them what they need to get there.

Thank you. Thanks for sticking around. I'm going to be in the Slack channel. I'll be able to answer questions, happy to have a chat, and I hope I'll see some of you there. Thanks very much.