London 2020
Leading Smart People
Michael Dell tells us to "never be the smartest person in the room". But what if we're in a role where people look to us for the answers? How do we create positive change in a domain where the team are the experts?
This talk is aimed at anyone who needs to create credibility in order to influence ways of working. I'll talk about ways you can help teams use their collective expertise to move towards the right outcome. This is true even if you don't know what that outcome is yet.
JH
Julia Harrison
Head of Product for Technology Operations, Government Digital Service
Transcript
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'm a head of products. And one of the areas of the cafe is reliability engineering. And this talk is called leading smart people. And 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. And these are some lies that people tell themselves. And maybe at some point in your career, you told yourself live like these, or maybe the people you work with tell themselves, live like these right now. And these are things like I should know, will be answered, 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 impostor here and I've got good news for you on that last one, unless it's your first week, you can't be an impostor worst case.
You're an infiltrator. And I don't know if you noticed, but on my first slide I have my Twitter handle and my, my Twitter handle is Giulia from it. I haven't worked in a traditional it department for quite awhile, but I started out in desktop support. I spent about 10 years working on support and windows, infrastructure projects are going to it, service management, then service improvement. And from there I got into product management kind of by accident. And some years later here I am head of product looking after reliability engineering at GDS. So I'm totally an infiltrator. I mean, don't worry, I'm not spying. I am a security code.
And 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? Well 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 loan management responsibilities and a good leader is someone people follow. Not because they have to, but because they want to. So if you want people to follow, you should probably know where we're going at GDS. We have reliability engineering teams and we have product managers with those teams.
And that's not something that's common in a lot of organizations, I think, but something that having a product manager does do for product, um, for that managers often set a vision and they do that. Even when the teams, they work with a reliability engineering and the vision should be an ambitious, inspiring, achievable statement about where we're going. So here's the vision for one of the areas or the CAFTA. We transform government by making it simpler, to build digital services and run them the right way. And your vision should be something your stakeholders and your wider organization combine to 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 and speaking of strategy, you'll also need one of those. So strategies how we get there. And it's, it's 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 that easy to make coherent decisions about what to do and not what, 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 and 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's the manager's dream up. So if you don't have a written strategy right now, um, I started out by thinking about what is a minimum viable strategy and what should it do? And 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. So would it help us decide which things we should be doing against which things we shouldn't be doing?
So here's our reliability engineering strategy. So we want to bring things together on a common platform. And in our case that common platform runs on our path. 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. So hopefully that's just specific enough to help us and other teams understand where we're going. And 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. Um, another thing about strategy, it should be stable, not rigid. So 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 round. And 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, and these are the conditions he calls out for intrinsic motivation. So that's the things that make people excited to come to work. They're not just dragging themselves to work, to, to get paid. And he mostly applies it to individuals, but it works just as well for teams. And 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 and carry on being smart on being better at what they do? And why would you not want them to fill it out? A sense of purpose? They feel like they're contributing towards something meaningful, actually want to do it. So 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 techs off. So what next, what else do you need for people to want to follow you as a leader?
So 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. And 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 and real leadership request for permission. And you get that permission. If people respect you and they respect you when they can see that you add value. So 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 answer. I don't know. They knew and that's coaching. I was really lucky that one place I worked, they made all the people, managers take a coaching training.
And the first thing we learned, we 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. So these are some of the kinds of conversations you already have with teams. It's just useful to think of them in terms of coaching and, and raising the ability of the whole team. So if you're trying to solve a problem, uh, maybe you're trying to, uh, trying to resolve a difficult, long running incident. Sometimes you pause and you say, well, 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, right?
Uh, this is a good scoping question. Do we know what good looks like? And there's often a temptation to keep tinkering or keep gold plating things. So often it's good at the beginning of a piece of work to argue or to articulate what good enough looks like. And that makes it much less tempting to keep on working past something is good enough. And you should release that. This is my favorite estimating question two days is that assuming everything works first time. And then the followup question to this is, and when was the last time you had two uninterrupted days of work when everything works first time, and you find people looking at their hands at that point and starting adding those to the estimate, uh, his knife, agile question, I've agile coaching question. Can we solve part of the problem sooner and then do more later? So it may be that we have a big piece of work that we need to do, but there may be that we can deliver some of the benefits really quickly just by sequencing the work in a smart way.
Uh, there's a, there's 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. Um, and I don't want them to have to break my next together. Uh, so 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 do less than we cut the scope, cut the scope so we can do the smallest thing in the short time. And sometimes I go too far and I've learned through my mistakes that if I ask often this question, if we do that, will you still feel proud of it? If 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.
And finally, I said, the asking powerful questions was the second most important aspect of coaching. And actually the most important aspect is listening, because 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, they start to become de-motivate in the more or less. Sometimes they need a cheerleader. Sometimes they need to feel supported and they don't. They don't want to, you know, not every time is a good time to be challenging people. And another times, you know, um, if you're in a state of flow where everyone's bouncing ideas off each other, those powerful questions can be really, really helpful.
So 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. And it feels great for you because you get to walk in on a team doing this for each other. And, uh, I, I heard the definition of leadership is 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. So 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 a team mastery. And it's a really key component in building a high functioning team.
So that's two and three. What's the third one autonomy. So when you provide value to other parts of your organization, which is most often the case in dev ops, there's a danger of becoming an older taker. Uh, 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 not good for your organization, because if you remember the strategy and vision we talked about and why it was important to get the wider organization really enthusiastic about them. So if all you're doing is taking orders from whichever senior stakeholder is shouting loudest this week, where's your strategy envision. You'll being blown around on the breeze. You're not moving towards a destination. So the alternative is to be a trusted partner.
So 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, whether it's business partnerships, sporting partnerships, even it's where people build up. Um, they get to know each other. They get really good at communicating just enough about what they need. They build this like really deep understanding and they trust their partners to support them and to always have their back. And that's where you want to be with your stakeholders. And, you know, it's easy to say, right? 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? Well, building partnerships is also a big part of what good product managers do. So I'm going to share some tips from the product managers that I work with.
And the first one is don't build things. So problems. I mean, of course we build things, but why are we building things? Hopefully we're building things to achieve something. So 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? So that might elicit a response like this. I need to know in advance when I should add capacity to my platform. Brilliant. So already by reframe, 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. So I don't know, let's say there's some reason right now where it's really difficult for you to build the dashboards 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. Um, and as we talked a moment ago about coaching, but 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 managers, 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. And they start getting better at telling you what they need, not what they think the solution should be. Here's another lesson, the product managers, uh, knowing that call, cause we deal with everyday, pretty much everything is a trade off. And you know, we're not unique in that, right? So having informed conversations with your stakeholders is often about articulating the, trade-offs sure you can have a 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 can get you 80% of the way there really quickly by building a smaller thing first. And 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? And 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, but they also help strengthen our partnerships and build trust with those stakeholders.
Here's another thing we talked about before. So strategy helps you decide what to do, but also what not to do. And once you've got your organization really infused about your vision and strategy, um, this is especially important. Getting out of that order taker role, anytime 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. And that doesn't mean you never do work that contradict your strategy is kind of build a tech that, you know, you call it a strategy deck. If you like, just like tech that if too much of it accumulates, you get overwhelmed by it. And it gets really, really difficult to move forward, but it doesn't mean you never do it, but when you do it should be a conscious choice and acknowledging why it costs you and acknowledging what's going to cost you down the line as well.
So we're thinking about solving problems rather than building things. And we should probably think about how we measure progress. So you might be skeptical of how we can do that or how it even help. So I'm going to run an example. Let's say somebody comes to us, um, and they're going to give we've we've. We write down the obvious objectives. So, uh, a business wants us to migrate all their applications to a new Kubernetes platform and where I work, we use objectives and key results. So the obvious key result here would be, we migrated all of the things that's not great, right? Apart from anything else, this could be a month or even years long project. Okay, we'll have a party at the end, but how do we, 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 and how do we choose which things to migrate first, but what does this tell us? So I'm going to iterate on the objective. I'm going to show I'm going to come up with a slightly better one. So let me 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. And that's usually a big motivator for why you do migration projects, right? So I'm going to express our key results as migrate a hundred percent of applications. And the reason for that is actually, yes, there is value in migrating 20% of the application. There is value in migrating 60% of the applications. And you can show that along the way because you're reducing costs as you go.
And that's the second result here, which is reducing the platform costs. So eventually we want to reduce it by 60,000 a month in this example, um, and you might be able to reduce it by 10,000 a month by switching off just your biggest couple of applications, that'll also help you decide what order to do things in, but what else it's not usually only costs that makes us want to get out of old platforms. So we'll dig a little deeper. I actually may be. Our objective is to reduce the cost and risk of the application components on the legacy platform. So we've got our key results. We've got migrated, all the we've got reduced, the platform costs, but what else, which we talked to her about risks. So maybe we want to reduce our risk score from critical to life. And if we look at the risk profile of the platforms and sort of that the applications and how much of that risk is associated with them being on that platform, maybe we're going to do a really counter-intuitive thing and migrate some of our risk applications first, which intuitively we sometimes tend to avoid.
Right? But also once we start looking at, um, 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. So 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. So you've now got different things that you can use to look at and make smart choices about which order to migrate things. And 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.
And finally, the last tip I'm going to share is get comfortable with uncertainty. And this is the hardest. One of all, this is tough for all of us, um, 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 us flexibility to change how we do it. Um, and to do that, we need to get, we need to get comfortable with uncertainty. Uh, and that doesn't mean surrendering to it. That doesn't just mean existing in a constant state of denial, um, accepting that we don't know the answers is where we start out in order to find the male. So there were some really strong reasons why your great idea or your stakeholders, 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, I think it's not going to work. So first off feasibility risk, can we, can we build it or can we migrate it? You know, is it technically doable, um, value, risk, this is where your stakeholders go for it. Will they buy it? Will they choose it? Will they fund it? Will they agree to it? Then there's usability risks. So if you're building tools, for example, would 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?
So at GDS, we're quite lucky our Ari teams or SRA, um, their cross-functional teams like any other, and we have access to product managers, interaction, content designers, performance analysts. So we have people who are specialized in each of these kinds of risks. And you might not have those people in your teams. I appreciate it. You know, we're quite lucky in that respect, but if your organization has a product management community or design community, for example, they might be happy to help out. Um, you know, 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. So if these are challenges that you care about and want to learn more about, think about how you can connect with those communities and get into help. And also a lot of technical PMs come from engineering backgrounds. So if you really love these sorts of challenges, maybe think about a career in PM-ing.
So getting your stakeholders and getting your stakeholders comfortable with uncertainty is often easier than you'd think. Um, 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. And you recognize this because it's the heart of agile, right? It's it's how do we do the least to learn the most, to reduce the risk? So we start out by stating what is that biggest online 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 best, is bigger than the cost of getting it wrong. Flip coin, don't waste your time. But look for the ones where the cost of getting it wrong is big.
And then the next question is what's the cheapest and quickest way to the more so 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. But that's the kind of thing you get in a partnership and 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, for your teams. So 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, build real mastery as a team. And they're inspired with a sense of purpose from having a clear strategy and vision. And if you create those conditions, people will want to follow you that's leadership. So I'm going to come back to this image that we had at the beginning of the, of the session. And 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, 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. And, uh, 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. Yeah, thanks very much.