Transcript
Gillard-Moss: There's two words I really want to reclaim, and the first one is expert. For those Brits here, expert became a bit of a dirty word over the last five or so years. A few things have happened since then. We've had COVID, and the prevalence and the importance of experts really came to the front during COVID, where trust in experts was much higher than trust in politicians. Then we've had some wonderful success in our sports.
Again, what you see is managers and leaders of those sporting teams, who themselves were players and got the experience of players to become successful coaches and lead teams. That's number one, it's the importance of experts. The second one is reclaiming the word manager, which, again, has become a bit of a dirty word, especially in our industry, where we don't really like the idea of managers and the idea of being managed, so we choose other words like leaders. That's COVID and that's football and that's medicine.
The other thing is the importance of engineering as well. I've chosen Star Trek as the theme, because basically the whole goal in Star Trek, To Boldly Go, relies on this ship. It relies on the enterprise. To get that ship out of all the scrapes it gets into to get everyone everywhere, you need a great engineering leader and engineering manager. Through all the series, the original really sums it up for me, and that is Scotty. Here Scotty is who I choose as our role model, because Scotty was an expert. He knew his ship inside out. He inspired his team. He inspired his engineers. He had the trust of the other leaders like Spock and Kirk and his colleagues on the ship.
For me, this is the role model to look up to. Of course, Scotty would have been a manager as well. He would have had to have organized shore leave. He would have had to recruit people in. I'm sure he would have had to have sat down and done the odd performance review, or made sure that people got to sick bay on time when they were ill, and he could cover them. It's just that stuff probably doesn't make it into the TV series because it's not quite as exciting as trying to get to warp whatever, under incredible circumstances, but he would have been a manager.
Background - Engineering Manager
I'm Peter Gillard-Moss. This is about my story and what I've learned over the years on that journey of being an engineering manager, and being an expert engineering manager as well. It's really hard. I failed probably three times. It wasn't till the third time that I really got it. The reason for that was a few things. First, there wasn't really any role models of what a good manager looked like. A lot of the role models we had were very negative. We've got the Dilbert which came from the software industry as well, the Dilbert manager. Dilbert's about the pointy-head boss. Dilbert is a software engineer. I've put Gordon Ramsay here. This happened to me early on in my career, I had an engineering manager, and he was vile. He was really horrible to a new graduate, and really upset the new graduate in his first week.
My colleague and I felt so bad, and we felt such a duty of care for this poor 21-year-old who'd just come out of university into his first job. We went and spoke to the engineering manager, and we said, "You can't behave like that. This isn't how you behave". He said, "I'm really sorry. I've been watching too much Gordon Ramsay". Gordon Ramsay was his role model for being a manager. Then we've got the Donald Trump type manager as well, which takes no crap, and you're out on your first mistake, you're fired. These are not good role models for managers.
The second problem we have in engineering management is this tendency to put people who are not engineers into management positions to manage us. This comes from office space, but if you remember Jen in the Crowd, it's the same thing. Engineers can't talk to people. Engineers don't do people. We need a people person who can step in and manage the engineers. I was in one company, and this is fairly recently, where your average team would have seven engineers and three non-engineering roles, so product, design, project management. When you looked in the leadership team, it was quite a large engineering tech organization.
Of the 20 leaders, only one was an engineer at the leadership level, because it was project managers who were promoted into those roles. It was BAs. It was everyone but engineers being put into those roles and given those responsibilities. The third one, which is the one that relates most to me, is the job description just looks so dull. It's just all these bureaucratical things that you have to do. It's hardly very exciting. Then there's all of these words that come up that you're supposed to do as a good manager. These words are not like test driven development or continuous delivery, where you know what they are, and you know, am I doing test driven development? Yes. Are we doing continuous delivery? Have we got microservices? Yes. How do I know I'm doing good delegation? How do I know if my stakeholder management is good? What does good look like? These words make the world of management a bit more confusing.
On the third time round, I was head of technology at Thoughtworks, and I was really struggling. I was attending all of these meetings. I'd just become the head of tech, and actually, I felt like this was a whole load of theater. I didn't know what was going on. I was just turning up to these meetings, and I was talking, and people would ask me questions, and I'd say stuff. Then I'd go to the next meeting in my next calendar, and I'd repeat, and things would go on. Anyone felt like that? I thought someone was going to catch me out. This isn't imposter syndrome. It wasn't like I didn't feel capable. I literally thought what I'm doing is just turning up and blabbering on and nothing's really happening. If anyone looked at my paycheck, they'd go, "We can strike that out. What's that person doing?" I confessed to my coach at the time, his name was Ryan.
He said, "Think about it differently. You were an engineer, what did you want from your manager? What would you want from your head of technology? What do you think your colleagues around you in other disciplines want from you?" That was a really good start. I really thought how I thought about the role of management. That's what I'd like to share with you. Number one, and this is the simplest thing, your goal as an engineering manager is to build a high performing team, or a high performing team of teams. Most of us, when we're working in our tech departments or in our businesses, the teams are majority engineers. There's a much bigger burden on us as engineering managers to ensure that those engineers work together in their teams alongside their other disciplines to be high performing.
We have a lot more of that management responsibility than, say, some of the other roles like product or design do. The second thing is, it's your responsibility as an engineering manager to show what good looks like. This was something that occurred to me about 6 months ago when I was out and I was interviewing and I was talking to lots of people, and this came across again and again in companies. They'd hire people in into senior positions, and they'd done everything, they'd done microservices, they'd done data mesh or whatever buzzword, but they were still stuck in the same place, and they said, "I need someone who knows what good engineering looks like". This is what we bring as engineering managers.
Getting To Good
How do we get to good? How do we do that? There are three things that I really focus on. How do I give direction to the teams? How do we give a direction to engineering so they know what good looks like? How do we enable them to pursue that independently, and that's really important, without us involved every day? How do we represent engineering, both to our engineers that we're responsible for, and also to the other people in the company who we have to make decisions with? It's not this way, let's be clear. This is a general manager's way of trying to manage people you don't understand. Let's give them some target. Let's measure them. Then we'll tick off if they're improving. This is not the way. These were the mistakes I made first time round.
I thought first, number one mistake was, if I make a load of decisions around technology, I'd come up with a technology strategy, and I'd get all of the buzzwords in there, and I get people to move in that direction to this new, great world. That's how I do engineering management. I made loads of tech decisions. I drew the target state we had to get to, and I thought, all I need to do now is motivate everyone to get to that target state and we're done. That's not how we do it. The other mistake I've seen is, we're all at InfoQ, we go and see these talks, and then we go, "I'd really like to do that at my company. I've seen someone from Spotify talk about how they've done their architecture. I'm going to copy that because they're successful".
We blindly copy others. Or, we bring experience from our previous company. I've seen a lot of this in my time, where people have come from a big tech company, and then they come into a senior leadership role, and they say, this is how we did it at big tech company. I want to transform this new startup or this new scaleup to work exactly the way I did at my big tech company. That doesn't work either.
What we have to do as engineering managers is make sure that the direction we give is business relevant. Every business is going to be different. It's going to need something different and a different approach. If you're working in finance, it's very different to if you're working on the wiki solution we were talking earlier. There needs to be a completely different engineering strategy. It's not just about what tech we use. It's about how we organize teams. It's about how we define engineering from a perspective of career ladders and things like that, and what good engineering practice is. It's about how we work together. It's lots of things beyond just the tech decisions. It has to be a shared idea of good. We are notorious as engineers, about arguing over the smallest things, tabs versus spaces, Scrum versus Kanban.
If we don't have a shared idea of what is good, and as an engineering manager, it's our responsibility to work and listen to our engineers and help understand what they believe good is, and get to consensus. It continuously improves. It's not something where you've got a target state, and when you get to it, you've won. It's changing every day, and you're trying to move things forward and improve every single day. How do you do that? You've got to be the coxswain. Your job is to be at the front of the boat while your engineers are doing the rowing, and you're giving the direction there. How do you do that? You've got to understand the territory they're in. What are the conditions they're in at the time. I made this mistake.
I was doing a strategy session about how we could get to a new event driven architecture with the team, and we did the classic down the mountain. Has anyone done the down the mountain exercise? You draw where you want to get to, and then you say, let's take all the steps back down the mountain of how we're going to solve this problem. One of the members of the team just put their hands up and said, why are you telling me about getting up this mountain, right now I'm stuck in this forest and there's fires everywhere. Understand the territory. They were swamped with tech debt. They had no good talking about this great, new architecture that they were going to build.
This is the next right thing, what they needed was the next right thing for them was not a golden ideal state. It was how to manage their tech debt. Good for them was just getting management of their tech debt right then. The other one is frequency equals importance. Another mistake I've made many times is I get distracted by the next thing, the next idea. You need to stick to your message and keep on it, bang the drum like the coxswain. A few years ago, security was a big issue in our teams, basic mistakes like checking in secrets into source code or leaving ports open. The way of fixing it was not to give one talk to the engineering department and say security is our priority. There you go. We're done. Say it once. Don't need to say it again.
Instead, I had to, every single meeting, every single one to one, every single town hall, or all-hands, I started with security. How are we doing on security? How are things going? It was like that for about nine months. Everybody knew that the first thing I was going to ask them in their one to one, or when we had our engineering meetings, was, how's security going. It was no surprise they knew that that was the top of the mind, because that repetition meant that they knew that that was the priority, and that's what we were working towards. You've got to be the coxswain.
This was another thing. I had got into a bit of a habit, as an engineering manager, coming off with a long list of things that I wanted to solve, but I would say, "This needs to be fixed. This needs to be fixed". My coach said to me, "You're the head of technology. No one's coming to save you. You have that responsibility, and you are in control of that. Why are you expecting everybody else to come in and solve these problems for you?" This was when I realized that, as engineering managers, one of the things that we can be guilty of is creating these cultures of helplessness, where our teams believe that they need us to solve every problem, or they need a leader to solve every problem. The mistakes we make, and I'm sure we've all done this, we do everything ourselves.
My father-in-law, he's a proper engineer, like does mechanical and electronical engineer stuff. I'm not very practical, but I want to learn, and I want to do things myself. When there's a leaky tap, or I've got to plumb the dishwasher, or something, I want to be able to do that. My father-in-law, I'll ring him up, because he knows how to do it, and he'll watch me for about three minutes, lose his patience, shove me out the way, and get on and do it himself. What do I learn? I learn nothing. I'm just the lackey then just handing him tools. I'm not getting any experience. That's sometimes what we're doing in our teams. The reason we do that is because we're not willing to tolerate mistakes. It can be really hard when you're up against a deadline, and you know it's going to take three times longer if you sit and patiently coach or let your team learn how to do it themselves.
The temptation is to come in and do the hero. Some of you may be fortunate enough that you've gone through that experience and you've realized you've got to free yourself up from being an executor on the team, so then you've still got all of this pent up, how do I keep this managed? You get into this improve and inspection model, which is, "Before you work on anything, let me see the tickets. Let me see the architecture. I'll tick it off before you do it". Then once you've done it, I want to inspect it. This doesn't work either. It just burns you out because you're on the critical path of every single design decision and execution decision. You realize very quickly that you put forward a proven architecture that doesn't come out the way the person thought it. Then you inspect and you say, this has got to change. This has got to change. They go, yes. It's got to get out to production, hasn't it? It's too late. It becomes pointless.
What do we want to do instead? We want to build independence. What is independence in our teams? Is when the teams can be proactive in making their own decisions. This is really important. I think this is on the track later about decision making and decentralizing it. There are thousands of decisions we're making a day. If every single decision has to come to you as an EM, it's going to slow things down. It's very ineffective. You want intrinsic motivation. Everyone's come to QCon here to learn. People want to learn. People want to get better, and they want to improve. It's our job to enable them to do that, not to use carrots and sticks and targets and measurements to feel that that's the way to motivate them. It's this bottom-up ideas as well.
One of the best things is when you realize that the people in the team are going to come up with better ideas than you ever would have come up with. This was a big part of learning for me, my job as leader is not to come up with ideas. I am not the ideas person. The best leaders I know have no ideas.
Circles of Control
What do we do? This is a thing that my son came back from school once, and there was problems in the classroom, and all the kids in the classroom had to fill this out. Has anyone seen one of this kind of things before, circle of controls? What's in my control, what's outside my control. My son came in, and he'd filled his in, and inside his control was like, he shouldn't shout out. All of the things you'd expect. Outside his control were things like, I can't see the board, or, there are children shoving and pushing, or they're shouting in the corner. When I read it, I realized that all the things he'd put outside his control were the responsibility of the classroom teachers, and yet, here he was being told, no, focus on the stuff that's inside your control. Ignore the stuff that's outside your control. It became this victim blaming. This is the same as managers.
A good manager removes what is outside control and they amplify what is inside the control. That's what we're trying to do. This is a really good exercise to do with your teams. Listen to them when they're speaking. What do they feel is outside their control? What do they feel is inside their control? That's one of the things to really keep an eye on. Here, you've got to be the gardener to do this, to achieve this. Bob Sutton has recently written a book, I think it's called, "Good Friction, Bad Friction". It's about how the best leaders are friction fixers, and they remove friction. That's our job as engineering managers and engineering leaders to do. Look at the frictions the teams are experiencing and work to remove them. The other thing is to create boundaries and let teams understand where the boundaries are. Rather than giving them solutions, give them the constraints.
An example I had was a team that was putting an architecture together, which I thought was wrong because it was batch based. I could give them a solution, or I could give them conditions under which the architecture needed to prove itself. For example, what happens when this scales to 10 times the amount of users? What happens when we need to make this faster, or we need to make this cheaper? Giving them that information made them change the solution to one which was more appropriate and better, without me ever giving them an idea or a solution. Then it came from them, and it was their own creativity.
The last one is constructive dissent. If you're always pushing your ideas on the team and they don't feel comfortable pushing back on you, what they're going to do is get into a state where they're just managing you up because they don't feel safe saying this isn't going to work because they don't feel you're going to be on their side. When your manager isn't on your side, you're always going to give them the good news, you're going to manage up. Make sure, listen, see if people are disagreeing with you, see if people are giving you a bit of pushback. Because if they're not, then you've got stuck in a managing up. You're being managed up at that point.
Engineering vs. The World
The other thing that I made a big mistake on, and this is about represent and how we represent engineering. I got stuck in a bit of an engineering versus the world type thing. Every problem that was happening, it was someone else's fault. It was product wasn't giving the right direction, or their requirements were wrong, they were giving us too many solutions. Or, the business had no strategy. Or, design were giving high fidelity stuff that couldn't be broken down iteratively. It was always someone else's fault about why we were working. This just created conflict between the disciplines.
The other thing is, I would just speak in engineering terms. I hear this a lot from a lot of people. We think it's our job to educate the other disciplines around tech debt. We think, if we can convince them to understand tech debt and the decisions they're making around tech debt, then they'll make better decisions, and it'll all work out. It doesn't, because they turn around and go, but that's your responsibility. Why did you do that? It backfires. The last one is, we try and maintain a black box. This is the, "We're engineering, trust us. We'll make our own decisions about how this works. We don't need any visibility of what's going on, just trust us to do it". Let's have a secret bit of capacity that we use for our own stuff, and then you don't need to see what's going on there.
I had to turn this around and realized, and this was that question, what do the other disciplines and our other stakeholders want from engineering? They want an engineering that is relevant to their business and to their needs. What are we doing that's relevant to what they're trying to achieve? They want engineering that's aligned with where the business is going, or what the challenge of the day is. They want to trust us. They need that trust that we're going to deliver and we're going to do the right thing. How do we achieve that? This is about role modeling, and the importance of, coming back to Scotty, being that role model engineer. There are a few things we can do here.
The first one is about how we make engineering visible. That doesn't mean metrics like McKinsey's developer productivity. It means we've got our own goals in engineering. If we believe that it's important to do something like continuous deployment because that derisks things and makes getting code out the door and getting releases and delivery smoother, then we need to talk about that and say, this is our goal. This is what we're trying to achieve. This is what we're trying to improve in engineering. Share that with our colleagues in other departments, so they know what progress we're trying to make. Allies share goals. One of the really important things here is like, the other disciplines are trying to achieve things, and if we can talk to those other disciplines in ways where they can align what we're doing, we will have success.
This isn't my anecdote, this is Rebecca Parsons, who was the CTO of Thoughtworks. An example of this was, there was a tech lead, it was a retailer converting to online, and he was really struggling to get performance testing prioritized. He kept going in, and he was getting really frustrated with the stakeholders and the business people that they would prioritize a feature and not prioritize the performance testing. Rebecca went, I'll go and I'll talk to them and see what I can work out. She comes back, and she comes back to him, and she says, "I've got it. It's prioritized. The performance testing is prioritized. You've got your time to do that". She said, "How did you do that? What did you say?" She just said, "I asked them, when is the most critical time of year for them to have their website available". He said, Boxing Day, is what the business person said. She said, "How many users do you expect to be working on the website on Boxing Day?" He gave a number.
She said, "Do you want to make us to make sure that the website will not go down during Boxing Day?" He went, "Yes, of course I do. Yes. That would be crazy. That's half of our revenue for the year". The goals were then aligned in a way that they understood. The last one is, show, don't tell. I made a lot of errors, which was, I thought if I just lectured people, wrote documents that were pages long about how things should work, and say, we're doing this wrong, we should do it this way. I thought that that was how I influenced and moved people.
Actually, it's much better to show, and then forgiveness over permission. If you think a team can be sped up or improved by changing their process from Scrum to Kanban, or whatever, find a team where that's safe to work with and then show that that makes the improvement. People will trust you more when they see the actual results. Try and find the opportunities, rather than just coming up with the theory and telling people about the theory, where you can actually demonstrate it in the small in your teams.
Another thing that's really important. There's a lot of ideas around what we should be as leaders. A lot of people will push us towards those ideas. One of the things that was really personal for me is the number of people who've said, through my career, "You spend too much time with the teams. You shouldn't be detail orientated. You're like a VP of engineering now, your job is to be strategic", but that's not me. I love spending time with the teams. That's how I keep my finger on the pulse. That's authentic to me. I know that's not the same for everyone else, but I have to be the leader that leads the way I do. I'm not a very good organizer. I wouldn't ever confess this in an interview, but project management is way on the other side of the sphere for me.
I once organized a Christmas dinner and it nearly burnt me out. That's how bad things are. That's not where my strength is. I can sustain it for a very small period of time, but it will burn me out and it will stress me out. Be who you are. Don't try and be a fake. The other thing is, look to people around you for those strengths that you don't have. I did it by accident, I always find the person who's a bit more of a project manager than me, and I partner up with them because I know they're really good at getting stuff done, and I'm not so good at working through the checkbox and to-do lists of things. They'll keep me on track. Find the other people around you who can support you up.
What is an Engineering Manager?
Really, what is an engineering manager? I've learned over the years, you're a researcher. You're going out, you're listening to your teams, you're researching your business. You're a designer. You're a sociologist, a psychologist. You're a bit of an economist as well, understanding how business works and things like that. You have to be a writer and a presenter, because you have to do talks, and you have to go up in front of people in your company and convince them. You've got to be a negotiator. You've got to be a diplomat. The most important thing is you've got to be an expert engineer.
Questions and Answers
Participant 1: What would be the amount of time you allow to hands-on code, or reviews, and management?
Gillard-Moss: When I started, and I was engineering managing closely to a team, I got much more opportunity to be hands-on. I think it's how close you are to the team and how many people you're responsible for, is the right answer. That was one of the hardest things, was not being hands-on. When I was at Thoughtworks, I was head of tech, the department was about 500 big, so being hands-on was really hard. You've got to find the right way for you. I'm not a very good hobbyist developer at all. I really need a purpose to motivate me. What I started to do was try and find ways which worked for me. I'm a big fan of Lean, and there's an idea in Lean called Gemba walks. What I do is I try and schedule time with the teams, where I find opportunities where they're doing the work, and I observe them, or I get involved.
When I was at Thoughtworks, for example, it was nice, they did remote pairing sessions, and that was a really great opportunity. I would go once a week, I would join a remote pairing session for like an hour and a half, and I would just go off video and stay silent. Then at the last 10, 15 minutes, I would just play back to them what I was observing, like, I noticed that there was a long gap between a check-in, and I saw some opportunities you could have checked in in between, or things like that. Hands-on is not just code. It could be attending a standup, or it could be attending a planning meeting, or something like that as well. That's how I do it. The right answer has to be based on your teams and your context and how many people you're responsible for.
Participant 2: You talked about leaders at the beginning, for example the Donald Trump meme and Gordon Ramsay one. How do you deal with assertiveness, especially when people are lacking commitment, and, for example, being late to meetings or rolling their eyes up when the client changes scope and stuff like that. How do you deal with assertiveness in that case?
Gillard-Moss: These things happen. I remember speaking to someone, and she was really frustrated because none of the developers would ever turn up to the standup on time, which I think is probably a common problem. Number one is, you've got to make the expectation visible. There's lots of tools we have for that. We can use retrospectives, or we can use direct feedback. This is part of the manager part, rather than the leader part. There are expectations, and there are, this is the boundaries. If there is a standup and we expect people to turn up to the standup, then we need to set the expectation.
However, we should go and talk to people and say, what's not working here? Why are you not turning up to the standup? Or, why do you not see the standup as a valuable thing? More often than not, people go, "I go to the standup, and it's a waste of time. Everyone just talks, and I'd rather just get on with doing the work", or something like that. In one case, it was in India, and the standup was at 10:00. In India there's a culture of working quite late into the evening, and the person trying to run the standup at 10:00 was getting more frustrated, but there were lots of young people in the team, and they stayed out till midnight and stuff like that. That was really early. The solution was just to move the standup to a time that accommodated them. It's definitely a thing. Make sure the expectations are clear and then understand why people can't meet them, and give feedback.
Participant 3: Talking about the things that are out of your control and in your control, when it comes to budget cut, and you have to let someone go from your team. I experienced this myself, and I blamed myself after I let someone go. I gave him the PIP, performance improvement plan, but unfortunately, they couldn't stay longer, for more than a month. He could improve, but he needs time, but the budget cut. What is the best thing that I can do here, out of your control and in your control? This is something like, I don't know what to do.
Gillard-Moss: I imagine a lot of us have probably gone through that recently, over the last few years, and it's been really tough. What's out of our control is the business situation. Like, if that's the business situation, there's not a lot we can do. For me, and this is about your authentic version of yourself, the idea of being fair and fairness and transparent and not trying to spin the company yarn a little bit too much, that's what's really important. I think there's still a human level to those kinds of things. There's still someone's going through that at a human level. While that is the situation, the fairness is in your control, making sure that person understands and making sure that person gets the right feedback if there was a situation, and treating them like a human being, really. For me, yes, I went through that last year. It was the toughest, most horrible time of my job.
Participant 3: It's different, because there's different cultures. I came from the background, from a U.S. company, so they don't do like, best performance improvement plan. It was like, how do you convince them that you need to wait for this person or this developer, he might be good. In other cultures, we can wait longer.
Lichtensteiger: It always depends on the business. I've had to do it a lot in my career, and it's making sure you see the human. Regardless of what culture, it's about supporting them with dignity, because that as a leader, is in your control.
Participant 4: What soft skills do you think give engineering managers credibility?
Gillard-Moss: On the soft skills one, I'll put it slightly differently. Has anyone ever seen the people, process, tech thing? That's how I think my brain worked through engineering management. I started with the tech, thinking it was all about the tech. Then I moved to the process, and thought it was all about the process. Then I realized what every manager ever said, which is, it's actually all about the people, becomes true. The faster we learn that, the better. Those soft skills are really about how we work with people. It's things like motivation. It's things like change management and things like that.
If you put it down, like get a certain type of behavior, or get people to behave in a certain way, and then it's, how are we incentivizing that and creating co-ownership of that? I don't think there's a fixed list. I know you can go to the top 10 management skills, which is where I got that list earlier. Even something like delegation is totally different in different places. Using a word like delegation as a soft skill, my approach to delegation is always to motivate people, and I learned this early on. If someone wants to do something, you don't have to delegate it. It's the easiest way of doing delegation, like people will do it, and then you don't have to delegate. If you give up control, you delegate. It's not always just about writing down something.
Participant 4: What do you see the difference as being between engineering and architecture disciplines? Because I think in certain units, they're quite blurry those lines. They have a different value for different stakeholders.
Gillard-Moss: I think people and architecture can't be decoupled. That's what it comes down to, over my experience. It's great, things like team topologies and stuff like that had come out, and that really resonated with me. Conway's Law is absolutely true. People will design architectures based on the way they are structured and based on their team. I'll give an example. If you've got a frontend team and a backend team, you will find the frontend team developing architectures that enable them to build stuff on the client side, because that's what they're in control of, even if the best architecture was to build something on the backend.
Again, you can't really separate it, because your role as an engineering manager is to understand how teams work together and how teams are structured. That leads to architecture. At the same time, you got to see the flaws in your architecture and then work out, what was the people factor that led to those flaws in architecture? You can't decouple them.
Participant 5: How do you communicate well to the teams what you're actually doing, and prevent them from feeling controlled, observed, judged by you being there in your position?
Gillard-Moss: You got to make your own role visible for others. One of the tricks I've learned is there's this idea in Lean called, Leader Standard Work. I quite like this as a technique. I've got outcomes I'm pursuing, and then I've got ways of how I pursue those outcomes. Some of that is strategic, and some of that is just day-to-day. What's one of my responsibilities is to make sure that I'm growing the engineers in the team or growing my direct reports. How I do that is through one to ones. That's just part of your Leader Standard Work. Being able to say, these are the things that I'm doing, these are the things I'm focusing on, and being transparent about that is really important.
The other thing is if you're trying to do something strategically, and you've got your goals that you're trying to pursue. The other thing I think is really important is, your goals need to be in response to what other people want, and making it transparent about what you're doing and what action you're taking. I'll give an example. Most people have probably got this, like, what leadership wants is for engineering to go faster. That's what everyone's always saying, how do you go faster? Your responsibility as an engineering manager is to know how fast engineering is going, and come up with ways of making that go faster. Make that visible to your teams that that's what you're focusing on, and that's what you're trying to do. It goes back to that coxswain thing. You've got to keep banging the drum on those things so that they know that's what you're doing.
Participant 6: I got a hint from you that you were a bit against measuring engineering productivity. You showed the McKinsey slide. At the same time, we're trying to build high performing teams. How do you grow an understanding of whether we're achieving that goal? Do you do some kind of measurement? Do you do DORA? Do you do DevEx? Do you do any of the other ways?
Gillard-Moss: I'm not against measuring, I'm against targets. This is the way I put it. If you're trying to get a person on the moon, and you're putting them in a rocket, who needs all the instruments? It's the person in the rocket. If you don't put any instrumentation in the rocket, the astronaut doesn't know how to land the moon lander. Our job as managers, we're like mission control. We want that wide lens. We want to give the support to that person landing on the moon. You do need metrics, and you need metrics so people can diagnose problems, so people can see what their own progress is.
Number one, the metrics are for them. The metrics are for the team. We want transparency, and we want visibility so we can see what's going on in the teams. As managers who are managing across teams, we're looking for trends. We're looking for things in common. Are we seeing a number of teams struggling in the same area? We're looking for systemic problems, rather than problems individual in the team. My preference is to empower the team with the metrics, get them to own the metrics, use those metrics themselves, and then they're making them visible to managers for those systemic things. I'm very pro measurement. I'm very anti-weaponizing measurement.
See more presentations with transcripts
