 Hello! So, yeah, I'm Sam Beckham. I'm here to talk about lessons from leadership. It's got nothing to do with WordPress. I actually haven't used WordPress in... I haven't used a microphone in a while either. I haven't used WordPress in about 15 years. So forgive me for not understanding the rest of the talks today, but hopefully these lessons I learned from when I worked alongside the leadership at GitLab, how I applied them to my usual role, which is not working alongside them, and hopefully how you can apply them to your roles and your lives as well too. So as I said, my name is Sam Beckham. You can find me on the internet at sam.beckham.io. This is where I would usually put my social media, but that's a hellhole right now, so there's no social media. We're going old school. This is a website. There is the full version of this talk on there as well. This is a little bit condensed to fit in at the 20 minutes, but there's a transcript of the full version, which has a little bit more details, but there's time for questions at the end as well. As I said, I work at GitLab. My usual role is that of engineering manager. I manage the foundations team, so we do anything that sort of spans across all of GitLab. So things like the navigation settings, we look at the design system, that sort of thing. We've just redesigned the navigation, which is a fantastic and terrifying experience because people have opinions, but yeah, that's what I do normally. But I'm here to talk about when I was the acting chief of staff to the CTO. This is something I did last August to November. It was a three month role. It was deliberately three months. That's what the acting part means. I only did it for a short period of time, and then somebody else picked it up after me. Chief of Staff, that part, basically means it's not an assistive role. It's like a strategic role, so you're working alongside them. You're working with them. You're not sorting out their calendars. You're not running errands for them, that kind of thing. I was actively working with the Chief of Staff and the VPs of all the different engineering departments as well. To the CTO is there because we have a Chief of Staff at GateLab, and that's the Chief of Staff to the CEO. This is all unnecessarily complicated. The point is I worked alongside the Chief of Staff for three months. I learned a lot of things. Here's what I learned. I'm also going to call it Chief of Staff going forward because it's much easier to say. Not technically true, but that's, again, much easier. As I said, here to talk about what I actually learned. I've split this into six different categories that not coincidentally map to our GateLab values. These are not exactly what they're written down as, but they make a little more sense if I word them this way. That is collaborate effectively, drive results, be efficient, include everyone, iterate continually, and be transparent by default. All of these come together to show that communication is crucial. If you get communication right, and this applies to everything. If you're getting the communication right, it's 90% of what you're doing. When things were communicated well, they generally went well. When things weren't communicated well, that's when things started going a bit wrong. Something Eric, the CTO at GateLab at the time, taught me very early on, was that for a message to be repeated, nope, to be heard, it should be repeated three times in three different places and in three different ways. The three's fairly arbitrary here. The point is you should overcommunicate. You should feel like a broken record. He also said, if you don't feel silly repeating yourself, then you're not doing it enough. If you don't feel silly repeating yourself, then that's an awful joke. Let's move on. Into the lessons. The first lesson I learned was use a single source of truth at GateLab. That's our company, Handbook. I've already had one person talk to me about this today, so great. We're doing something good. This is at GateLab, a totally open source public Handbook. It's a statically hosted website, so the website itself is public, the repository is public, all of the issues, merge requests, which is what we call pull requests, and all the discussions and things, mostly public, right? This is where we keep everything to do with the company. If you want to know how a team works, it's in the Handbook. If you want to know what the parental leave policy is, it's in the Handbook. If you want to know what our company goals are for the quarter or the longer term ones, it's all in the Handbook. Because it's a publicly hosted repository as well, you can dive in, you can see all of the, like who added certain things, you can see why they added it, you can see the discussions around it. It's super helpful to have not only let people self-serve and get the information they need, but get the reasons behind that information as well. This is what we do. It's not for everyone. It works for some people. Some people find it trickier. The point isn't have a publicly hosted repository that builds a static website. The point is have one place that at least your employees can go to that has all the information they need. One place alone so there's no conflicting information. Announce everywhere. This is another part of collaborating effectively. The Handbook is great, but it's static. It's not easy to figure out what's changed and when it's changed and why. This is where we overcommunicate. This is where we say one thing three times in three different places in three different ways. We will put things out on Slack. We will send emails. We will tag the people that need to know in GitLab. We'll make sure that managers are telling their reports and if they have reports they're telling theirs. We tell everyone and it goes everywhere essentially. But we always make sure we link back to the Handbook so we're not creating multiple sources of truth by changing the wording slightly when we message it to people. We say, hey, this thing's changed. This is what's changed. You go read the update in the Handbook. This reduces the telephone effect where if one person changes something then that message can be very different by the time it's gone through several different people. Announce everywhere. Looking at results. How do you know you're achieving things if you don't actually measure what you're doing? We do this in several ways. How we do it isn't as important as just actually doing it. We have OKRs, which are objectives and key results. That's a whole talk in itself, but essentially company goals for the quarter. We have KPIs, which are longer term goals. Things like reduce the number of security issues would be a quarterly goal. But keep that number below a certain number would be one of the more long term goals. These things you want to keep measuring once you've hit that goal. You make sure it doesn't go back to where it was. Again, that could be a whole talk in itself. Apologies for going very quickly over these things. Another part of results is measuring opposing metrics. If you're measuring something, make sure you're measuring the side effects of that as well. Mergequest rate is one of the things I measure as an engineering manager. This is where I look at how many merge requests on average my team is producing. It's not to look at individual people and say you're not merging enough code. It's not what it is. It's just a baseline to see like are we shipping roughly the same amount as we were last month, last year, last quarter, whatever it is. But one way to make this metric go up is to just care less about the quality of the code you're writing. Or to just phone in some of them things. So we also measure quality. We measure the other side of this. As I mentioned, we look at the number of security issues. We look at number of regressions that came in. We look at all sorts of other things. So we make sure we're not gaming the system essentially and making sure that people incentivising the wrong things. There are opposing metrics for other things. We measure engineering, so we'll measure things like number of diverse candidates. But we'll also measure pay equality at the same time as well. So we make sure we're not increasing a pay gap whilst increasing diversity. That would be bad. Let's not do that. There's all sorts of other things. But the point is make sure you're catching the side effects of the things that you're measuring and not incentivising the wrong things without realising. Being efficient. Now this is one of my favourite ones. So starting with the decision, this is something we can all do. This is something that I've used a lot in my daily life as well now, right? It's subtle, but it's super helpful. So when you're going in with discussion, it's really good to do your research and say, okay, we've got this problem, we've got x, y and z that could potentially solve this problem. But instead of going in with that, say, we've got this problem, we're going to do x. We could also do y and z, but we're doing x. And then start the discussion from there. And then you've already got a decision. So if somebody comes in and says, no, no, no, y is far better, be open to that. You've got that discussion, you've got that person who maybe wouldn't have spoken up otherwise, speaking up because they're like, oh shit, if I don't speak up now, x is going to happen and I don't want that to happen. If you speak into someone who doesn't really care how you do it, they just care it gets done, grit, you're there and you've got that decision already. I've been told 10 minutes, I'm moving on quickly. But start with the decision. You'd be surprised how quickly this, how much this can help you with lots of things. Be a multiplier. So this is something that is especially true in leadership. The more people that report to you, the more you need to become a multiplier and not just an adder. So what this means is do things that help more people in a smaller way than would help less people in a bigger way. So instead of doing something yourself, that's being an adder, do something small that helps several people do that thing quicker. So an example would be creating or to be fair, a better example would be removing a process that slows people down, removing one extra required round of reviews from the merge request review process or pull request review process, or creating a tool that helps loads of other people get their job done just that 1% quicker. Like it's far more efficient to make everybody else 1% more efficient than to try and stretch yourself to be 100% more efficient. So be efficient, be a multiplier. This is a very ironic slide to give halfway through a talk, but shut up and listen. Something I'm obviously not doing right now, but I will when the questions come. This is the bigger part of communication that a lot of people just kind of brush over and forget. You don't want to just talk at people. You want to shut up and you want to listen to people. You'd be surprised what you can hear when you actively listen and you create a platform for people to give you their opinions on whatever it is, on things that you've done, decisions you've made. We're all human. We all make mistakes. We all do things wrong. If you shut up and listen, you catch these fairly early, right? At GitLab, we had office hours with the CTO where anyone could come along and talk about anything. It was sometimes really quite fun when they'd made a particularly interesting decision and people would come along and be really blunt about why this decision is bad and then watching the CTO take that on board and listen to them and actively do something about that. It was really helpful to see that, right? Because it encouraged more people to speak up because they knew they would be heard. So shut up and listen and be very deliberate about this. This is very, very similar to the previous one, but include everyone. Don't just shut up and listen to the same people all the time. Include everyone, regardless of who they are, where they're from, they're standing in the company, all of these things, right? Make sure everyone feels like they can come speak to you, right? Don't feel like they have to talk through their manager to you if this is kind of where you are in the company, right? Get opinions from everyone and make sure that, again, you should have been listened to them and they are heard. You'd be surprised what you hear from people that you wouldn't have expected to have ideas because they're kind of very far removed from what you're actually doing, but sometimes that really helps to have that outside perspective. Moving on from the communication side of things, shipping and iterating. Again, something we do fairly often as engineers. This is built into a lot of things that we do with agile practices and things. We ship the smallest amount of code. We ship a MVC and we iterate from there. That's pretty common, but we would do this with messaging and process changes and things like that. We would sort of ship the smallest version of it first and then go from there because it makes it so much easier to do, as I said before, and shut up and listen and actually change things if you've not actually tried to change too much at the beginning. Start small, make a small change, make a small iteration and continue from there. As I say, if you need to change that, you need to pivot from where you're going. It's a lot easier to do that when everything you're doing is incremental and small. Not waiting for perfection is against something that makes it a lot easier. Don't get it perfect before you ship it out. If that's your code, if that's the messaging that you have out there, if that's a process change, don't try and make it perfect before you put it out there because, again, you're more reluctant to be able to change it when people have their opinions, when they have their thoughts. It's going to take longer to get that initial thing out there. When it's good enough, it's probably good enough. Don't wait for perfection. Get it out there. Get them opinions and get that feedback in as soon as you can. Work? That didn't pretend internally he's not there for a bit. Work in the open. This is something we do at KitLab. This is something that the WordPress community is really great at as well, which is why I'm happy to be sharing this here. We are transparent by default. We are open core, which isn't quite open source, but it's close enough. As I said, we have our handbook out in the open. We have our meetings recorded. A lot of these are on YouTube, so you can go watch some... It's bizarre, but you can do that if you really want. You can go watch our meetings. It's great for us because we have people all over the world and we say, if you can't make a meeting, that's fine. All our meetings are optional. There's an agenda ahead of time. You can go back and watch the recording. There's definitely times when I've not wanted to go to a meeting, so I just didn't, and I watched the recording at two times speed later on and skipped all the bits I didn't care about. There's a lot of benefits to being transparent and being out in the open. Internally pops in. This can be difficult for some people, right, because being that transparent and having all of these things available to everyone is sometimes just legal reasons where you can't do that, right? Ironically, since GitLab went public, a lot less things are public because we're not allowed to put things out there inside the trading rules. So work internally in the open, at least. Make sure your teams can self-serve. They can see the decisions you're making. They can see why you're making them decisions and they can jump into their meetings that we were talking about before and they can share their opinions and their ideas. Internally is not as good as totally open, but it's a lot better than doing things behind closed doors and just going, is the decision we made? Deal with it, essentially. This slide is intentionally left blank. This is where I would take a sip of water, but I forgot to bring more water. So lessons learned. Summing up, I realise I've gone through this very quickly. As I said, there's time at the end for some questions. There's transcript and a little bit more detail on what I actually did while I was there and a little bit more about GitLab's side of things on my website, sam.beckham.io. But in summary, if you collaborate effectively, drive results, be efficient, include everyone, iterate continually and be transparent by default, you'll be a much better communicator and communication is crucial. This is something we can all do regardless of our role, whether we are leaders of huge organisations, whether we're the engineers doing the work or whether we're just doing things at home. All of these things can... Well, not all of these things. You don't want to be measuring results at home, but you get the point. A lot of these things, or maybe you do, a lot of these things are applied to all of us in various different ways. For a message to be heard, it should be repeated three times in three different places and in three different ways. Thank you. Yes? What does that mean for you in a position of leading an engineering project? Is it in terms of contributions in the community? I'll heavily caveat this when I'm the wrong person to answer this question, so this may be wrong, but essentially we're open source in all the places that we can be. There's certain bits with licensing and certain features and things that aren't inside the open... So we have an open source repo and then we have a secondary one that's not quite fully open source. It's complicated, I don't fully understand it. The point is it's open source, but not quite, really. Yes? Hi, so thinking about, we are a very transparent organisation and how do you deal with it when someone joins and they've not worked enough in that sort of way. When you talk about shipping and iterating, especially when it comes to processes and getting that MVP out there and building on it like I'm totally there with you, but people who are not familiar with that often go into sort of... A, I need to do the whole process, all of permutations of all of the different things and not only that, but I have to get it completely right before I share it with the world and then they do that and then they share it and then they get loads of feedback on it and they're like, oh my God, so how do you deal with that sort of mismatch between what people are used to in the past in traditional organisations where people would do that and this sort of new, much more iterative, collaborative feedback driven way of working? Yes, it's very difficult. We call this the get lab fire hose. It's this torrent of information that comes at you so when you're on-boarding it's like there's an on-boarding issue that you have and when I joined it said, read the handbook, which if you've seen the handbook is impossible, it's like by the time you've finished reading it it's changed enough that you need to start from the beginning again and keep going. So I think a lot of that is on the management and on the teams to make sure that people know his way you can go and self-serve but if you can't speak up, give us feedback on where we're letting you down in your role as well. To be honest, after a little while the feeling of everything being transparent you don't even realise it's there, you don't realise what you're doing is in the open a little bit, right? So I was working on a merge request before and somebody from, I don't even know where they were from, they just came from nowhere and were like, oh I think you should do it this way. I'm like, who is this? What's going on here? And then you start to realise that people can't see what you're doing. But the main thing is just being there and supporting them and making sure that they know that it's a big shift and that you know that it's a big shift as well, right? Eventually it clicks, it does take a little while. Some people more than others. Does that help? Yes. What is the biggest challenge you face with being a robot and how normally... Two big challenges. One is exactly the question that Siobhan just asked, right? How do you see that someone is struggling when you don't see them, right? Like they're the other side of the world. So I have one of my engineers is in Sydney, so we have like no overlap at all. So meeting with him. Half of the year I meet him really late on and then the clocks shift and then I meet him really early on. It's a whole thing. So that's difficult. But again with practice it feels... It has to feel normal, but the thing I always say is going to be the most difficult thing about this level of remote work for me is if I ever had to do any other job where I sit in an office I'd go completely mad and hate it. It's that disconnect from people which is why things like this are great. I don't see people and I'm technically still working today. So that's good. Thank you very much, Sam.