Going from 0 to 60

Martin Woodward: My name's Martin Woodward. If you want to send abuse my way on Twitter, feel free. It's at Martin Woodward and all the social media platforms. As folks mentioned, I'm going to be talking about the DevOps journey. Sorry, not the DevOps journey, the DevRel journey. There you go. That's my day job. Talking about DevOps, the DevRel journey that we've been on here at GitHub and how things we've learned along the way and things I've learned as the team's been growing.

Now I want to just start this talk by warning. There's actually three lies in this title, so we'll see if you can spot them all.

The first lie that I've got for you is actually DevRel wasn't zero when I started at GitHub. I started last year when I came over to GitHub full time. And while I've been a fan of a company, I've been an amazing admirer of all the work they've been doing. It was interesting that it wasn't really like formal Devra as I understood it and as I'd seen it before, but the whole company at GitHub had been doing Devra from the beginning. GitHub, it was a small startup focused on developers. It grew from sort of Naugh to 200 with one kind of way of working, and literally everybody in the company was doing Devra back then.

They were talking to developers, getting to know, doing meetups, handing out stickers. I think if you haven't got a GitHub sticker on your laptop, then we've kind of failed there.

We should have definitely got you one. Maybe next, when we come back to in-person events, in my experience, I've done some startups, done some other companies and been involved in some growth of different teams and things. When you grow a company like an order of magnitude 10 x sort of thing, you kind of need new structures, a new organisation in place, and Gil had grown from say 200 to a couple of thousand, and it kind of needed a team that helped create and nurture channels for communication, ensuring that the teams of engineers, the teams of product managers, people in marketing, things like that, ensuring that they had a connection into the core developer community. That's at the heart of GitHub. If you cut anybody open at GitHub, they bleed the community. So it's a very easy job and a very easy company to work at doing Devra.

But we needed this team. We needed to ensure consistent quality of output and we needed a team to represent the developers, to advocate for developers, and to help make sure there's this strong network between developers and the rest of the business. So that's what my team sort of set up and that's what we started creating. Now that moves us onto the next lie, really about this talk title in that my org actually isn't 60 people right now. So it wasn't zero and it wasn't 60, but nevermind, never let facts get in the way of a good story, I guess is probably the motto there. But it's actually about 38 bums in seats right now. Teams going to around about 50 probably over the next year, but not everyone at GitHub is that's doing DevRel related activities reports in my team. So let's kind of talk about my team first of all, explain that and then explain what's going on elsewhere around the business just so you can kind of understand things.

So on our team, we have developer programmes, so that's PMs and community managers who are managing the programmes. So like the STARS programme, which is our ambassador influencer type programme, managing our open source outreach, managing our international meetups and our meetup relationships, things like that. Things we want to build a programme around and scale out and where we're nurturing and growing channels back into the business they live in, developer programmes, programme managers, community managers. Then we have our docs, our learning platforms and strategy team. It's a small team focused on, it is almost like the PMs of our doc systems and our learning systems and making sure they work, managing the strategy, doing content strategy, planning out documentation, that sort of thing. We have the Docs team, which is a fabulous team of writers that are spread across the world, organised in kind of squads that sort of swarm on different bits of content because such a broad product, there's no way one person can be an expert on everything that's in GitHub.

And so we tend to have geo-located teams of experts who can help swarm on things and help get content out there and then work with the programme managers and the engineers who are building the features to help make sure we can educate people on their features. And then also working with the open source community because we, GitHub of course our docs are open source and so help make sure open source contributions come in and have a consistent voice, consistent messaging and are factually accurate and work and all that sort of thing.

So we have that amazing team of writers spread all the way across the world and they're absolute pleasure to work with as well because we've been working remote forever basically. And we are able to support a lifestyle that's quite attractive to a lot of people in the writing side rather than going into an office.

You can do some writing in Van Life and go touring around or you can live where you want to live in a world. I'm joining you here from a field in the middle of Northern Ireland, for example. So yeah, we're able to attract some of the best talents in the world and it's a pleasure to work with that docs team. And then last but very much not least is the developer advocacy team. Developer advocacy I find is what a lot of people outside of Dev think of as dev, they think of that person that gets up on stage and gives a talk. They think of demos, they think of all the whizzbang stuff and going to meetups and going out and doing conference talks and YouTube videos and tiktoks and that sort of thing.

That's important and that's vital. And again, the developer advocacy team we have here is absolutely world class, but that's not all the be all and end all is Devra as we all know.

And so I do like to point that out when I'm sort of communicating out what Devra is to the wider org. But then across GitHub, Devra lives in the main sort of product engineering group at GitHub. And I personally, that's where I want to live with a Devra team and that's where I prefer to live, especially in a developer focused company. It makes sense for DevRel to live in different places depending on the organisation that DevRel's a part of in my experience. But for a developer tools company, a developer focused company, I think DevRel needs to live as part of the main product and engineering group so that you can make sure you are helping make the product better and helping make sure you are connecting developers with the core engineering of the business, your target market. It's what you are talking to now.

We have a few sister teams apart from all of the engineering teams, the people who build the version control features, people who build actions, people who build issues. We work with all those, we're sort of sister teams to all those teams, but we also have a couple of very, very close teams that we spend a lot of time working with. One is the education team who Gibb's education programme doesn't report to me, but it's by far the best education programme I've seen out there. It's phenomenal. The team working on that are amazing. Joe Nash, who's spoken at a few conferences was involved in starting that team. And then the team continues to go from strength to strength now as well. So yeah, it's a fabulous group to work with and they're off busy not only helping students and stuff, learning how to code and how to get into and use GitHub, but they're also busy building lots of mini DevRels and the Devra people of the future with their campus experts programme.

So a fabulous group of people, whether there now the education team has both engineering as well as community management folks because we have products inside of GitHub that are aimed at students and further education establishments like GitHub classroom. And we have the GitHub student pac, which is this collection of over a hundred partner offers and things which we do all the qualification for. And that's significant amount of operational work that has to be done and fraud detection work and all that sort of stuff that we take on. But it means we can have a bunch of partners into that student programme as well and get really good offers out to the students that are learning how to code on our next generation of developers. And then the other team that we work with in GitHub is a communities team. This trip me up immensely. When I first came to GitHub, I was a community pm, I worked in community teams previously is how I thought myself.

But in GitHub community is a feature area.

There are people building community features, there are people building discussions, there are people building that. We switched on a feature last week that makes sure the code of conduct for a repo is visible to people ensuring community best practise. There are people who put community self-service functionality in and try and help you deal with toxic people and make sure you can do moderation and all that sort of stuff. So community is a feature area and we spend a lot of time working with the communities team, but the community team, so that's worth calling out. And then we also work with some partner teams across the business. We have a marketing team that lives, and this is sort of the PR and comms folks live within the marketing organisation. So that's separate from product obviously where we live in Devra, it's a separate kind of reporting structure into the CEO.

And we have a events team, again, amazing events team, and obviously folks know from GitHub from all of our amazing swag.

We have a fantastic brand team, but even better than the brand team or as a result of the brand team, we actually have a shop. We have dedicated team that sends swag out. And as a Devra person that is just phenomenal to me that I can go create an issue in a repo somewhere and then the magic swag picks is send swag to people, no more stuffing stickers in envelopes, no more stuffing T-shirts and scarves into things and sending them all the way around the world and all the trips to the post office and things. There's a team that does that. It's phenomenal. Highly recommend it. If your company wants to invest in that, it saves definitely a lot of effort. In my experience that normally happens in the de roll space, I'm just showing off really.

We also have the revenue teams that we work with. So if it's our traditional sales organisations making sure we helping them, making sure we support any events that they do. They have a field marketing team that are running local events that are very much more revenue focused, whereas the DevRel events are much more about learning, much more about breadth, adoption, that sort of thing. And then the, interestingly, the support team doesn't live with Endeavour either. At GitHub, the support team is in a separate organisation that is focused on dealing with a day-to-day developer support, helping people on the community forums, all that sort of work. So again, sometimes that lives in Derell, sometimes it doesn't and give Abit. And then the final group that I've sometimes had in my org sometimes haven't, depending on the company, is the partner relations. So working with partner companies to do events to communicate out to customers and developers and things that partner org in GitHub, again, separate org that we work closely with.

So lots of people doing DevRel, not everybody on the DevRel team. And we kind of communicate and coordinate and work together, which is awesome. So the whole point of this conference and the whole point today really is talking about managing DevRel team. So with what, 15 minutes to go, we should probably start on that topic. So the first thing really I found in this kind of pithy management advice really is to make sure that you have a clear vision. I'm always amazed that I haven't done a good job of making my vision clear with the team and helping the team come together and explain what it is we're trying to do and why. So make sure there's a clear vision. Make sure the team are bought into the vision that they've ideally helped create that vision and then explain things to everybody and then keep repeating it.

It's important you can't repeat your vision often enough. Why are we here? What are we doing? What are we trying to achieve? Now, one of the topics that comes up in basically every single Twitter space I've been involved in around DevRel and come up already in the conference is around OKRs and metrics and all that sort of stuff. So there's been some topics on this already during the past couple of days and there'll be some more tomorrow and things. The important thing is that for me, we use OKRs. So objectives and key results, the OKRs should be focused on impact not activity.

So you don't measure, I did 20 blog posts, it's what impact did those 20 blog posts have or what impact did your hackathon have? They should always be tied to business goals as well. So if you're trying to achieve something as a business, that's what your OK R should be aligned towards.

And your goal as DRE is I treat it very much as a service team. We're out trying to make everybody else shine. We're trying to make the product and engineering features shine. We're trying to make the events team trying. We're trying to make the people who appear in our content shine as well.

And yeah, it is just incredibly important to focus on this impact rather than activity. Remember, your OKRs are for internal alignment, so it's helping your team understand what it is they're doing and why and how we're tracking and pushing and they should be ambitious. If your OKRs are all green, then you're not trying hard enough. You should have some amber and some red OKRs. You should be always be trying to do a little bit harder than you think is slightly possible to see how far you can get and you should be learning and you should be measuring that's what they're for.

They're also very useful for communicating with other teams like this is what I care about. This is what's important. What OKRs are not important for is for justifying your team's value to management.

If you are hoping your OKRs are going to convince management of your value, you've already lost. We're DevRel, we thrive, we thrive on influence and we thrive on people being excited, people talking about us. Every business unit in your company should want to work with the Devra team. Every part of the business should be raving about the Devra team. And if your leader or it's the CEO or wherever it's one level down or whatever, if that leader is hearing lots of great feedback from across the business and lots of people wanting to work with you, people saying, oh my goodness, what amazing work this team are doing, that sort of thing.

You find the OKRs, people don't care about them as much senior, they're still great for communication, you still need them, but people above you tend to be like, yeah, you're doing a great job, you're lovely. Would you like some more resources? Would you like some more headcount?

It's always like the same thing with a contract. If you start to have to dig into the details of a contract with a customer, it's probably not going in the right direction. And the same truth with OKRs and management in my experience. So use the OKRs of the business to help align your activities, but don't be thinking if I have amazing OKRs that's going to justify 29 headcount. You need to work on your influence better, right? Important that we have a clear vision and that we repeat it. I can't say that often enough, so I'll make sure that we remember that and that you set those goals with your team.

When you are talking to your team, it's important to give feedback, give feedback that's timely, that's appropriate.

So when things are done that's actionable, that's prompt and that's heard. So an example, if somebody's wanting some feedback on a document or on a positioning paper or on a talk, they're proposing to take the time to give them the feedback but don't, oh, I don't like it, or, oh, it's okay. Or even that talk is fantastic, this feedback is no good. It needs to be actionable feedback. Even if you think that thing is the best thing you've ever seen, why is it the best thing that you've ever seen? What is it that makes it good, that makes it better than other things that you've looked at in the past or other things that they've done? Make sure that there's action in place and make sure that it's understandable.

Also, make sure that you levelling that feedback appropriately to the person that you are talking to.

So if you're talking to a very senior, very experienced person, you can obviously take a bunch of shortcuts, you can give them that next level down of polish type of feedback or that sort of thing. But if you're talking to a brand new enrol dev advocate who's just started out, give them a little bit of improvement feedback. You no need to completely go through absolutely every little thing. Make sure that the feedback is appropriate and tuned and that allows 'em to hear it. It allows 'em to understand, it allows 'em to take action, and then you can iterate and improve and keep getting better each time. My biggest advice when working with people is always to play to people's strengths. So that's super pithy, but what are they good at?

What do they suck at?

Stop trying to manage people into doing things that they suck at. Try and manage the work and manage the people into the things that play to their strengths and create work and organise work in a way that plays to your strengths as a team as well as the individual's strengths as people. And then recruit, fill in gaps. Get people to fill in gaps where necessary. Understand that it doesn't have to be perfect all the time and that things don't have to be amazing straight away, but what do you need to grow in the future over time so that you can build up skills and start filling in these gaps is important as well. But always be thinking about what do we do really well? What did somebody excel at? What are they doing good?

And try and tweak the work to focus on people's strengths is my biggest advice.

And when you're doing this, it's very, very, very important that people understand what your vision is and that it's clear and that you repeat it when your performance managing folks. You need to make sure. That's very tricky in the DevRel world, especially if you're dealing with very publicly visible people. As a manager of people with large Twitter followings, that can be quite exciting at times when you're trying to encourage different performance and things. And sometimes you see a bit of subtweeting going on, people are not happy and stuff, and there's a significant corporate reputational risk there because we are deliberately putting people in the public eye. And then again, if those people need to go through some feedback and need to be performance managed, this could be very, very tricky. So you need to get good at performance management if you're going to be managing a large team in the devra space or in any space, it's publicly facing.

So you learn how need to get practise on holding people accountable and helping them find the right path. But I think when I've been talking to other folks, my biggest advice is always to help people take ownership of their own career paths and then you enable those career paths and you help them get better at those career paths and find the right roles for people and all that sort of thing. So it is tricky and it's doing it. I lose sleep about all the time, but yeah, performance management is definitely something you have to work on.

I've got an amazing team right now, but yeah, but it's definitely something that's concerned me in the past. And then my biggest mistakes as a manager have been to focus too much time on performance management and sort of helping people who are underperforming and not time boxing that not constraining the time, but also really the emotional energy I spend on it so that I don't forget to spend lots of time with the people that are doing the best work. I said here, invest time where you get the most return and you should always do that. Limit the time on where you're getting little return and invest a huge amount of time in the people that are giving you great results and help them grow more.

There's nothing worse where you lose somebody you really didn't want to lose and you could have spent more time with them, you could have helped them grow quicker and you could have helped them understand that you valued them as much as you do.

So let people know why they're awesome and help keep them growing is my biggest advice. And then when you are, that's great for when you're growing people and that's the funnest part for growing people. Remember though that what is right for you and how you work isn't always the right thing for them to always be looking to, how can I find this person a mentor that will suit their work style? How can I connect them with role models that are following a similar career trajectory or similar career path to them, but it may be five or 10 years further down the line. And remember, you're going to need junior people coming into your team as it starts to grow to keep the senior people on your team happy, especially in reux. People love educating people love to grow people. That's why we're in this job.

And so you need people in your team for people to grow as well. And so make sure you make room for junior people to come on board in the team because that not only helps them grow and helps you grow as an organisation, but it also helps keep your more senior people engaged in the business, engaged in the company and happy and growing themselves. It helps them learn by teaching is oftentimes what we find with DevRel folks know, but when you're growing these junior folks, they're probably not going to stay with your company their entire career or they net team the entire career to figure out how you can still win if and when they move on to the next role. Make sure that if this person that you are growing is amazing and they're just the best person ever that if they decide to move on and move on to a different team, that's fine.

That's part of natural career development. How can they do that in a way that they still have a great relationship back with your organisation, that they're still giving value back into your team and that they turn into one of your biggest advocates when they leave and move on to their next role. When you're growing a team, the only way I really know how to grow teams that do similar things is to grow them organically and then divide, grow and divide, grow and divide. You can grow a team that's doing different functional roles by bringing in new people, but quite often if you're trying to have a team that's functionally the same like a tech writing team or something like that where you're trying to have a large number of people that do a similar role, then you need to make sure you grow and divide those teams organically over time and understand you can't just go from Naugh to 60 overnight if you want to maintain the culture that you've built up in that team and you want to maintain the kind of work patterns.

This is classic kind of textbook stuff, tuckman stages of team development, but I'm always surprised at how many people kind of haven't been through this yet, the sort of storming, forming, norming, performing kind of thing. Teams go through these natural stages of development, go look up Tuckman stages of development if you want to learn more. The key thing is that performing stage, that's where teams are doing their best work when they've been together a while, when they've been through performing storming and norming stages. So I always try and keep my teams in that performing zone for as long as possible. I will often keep a team together as a unit, as a cohesive kind of squad and change what they work on rather than reorg people in and out. The team reorging people in and out of team is always quite disruptive because they've got to go through their team stages.

And what's amazing when you have a bunch of performing teams is then when they're in an agile organisation or when you see it working correctly or in teams that are doing DevOps, that sort of thing, you see these groups of performing teams swarm, so performing becomes swarming and you see them getting together and do amazing things. We had a universe conference a couple of weeks ago, GitHub Universe, which is our major sort of annual developer conference, and it was just phenomenal to see these teams from across the whole organisation teams within my org, but teams across all the other orgs in GitHub come together and really swarm on an issue on this conference and just knock it out the park and produce some of the best content I've ever seen and some of the best outcomes I've ever seen in my entire life.

So that was a very proud moment for me.

When you're building your teams, I'm a massive believer that healthiest ecosystems in nature are the most diverse, and that's especially true in DevRel teams. You need diverse representation, you need diverse viewpoints. You need huge amounts of inclusion in the team to bring in people from all across the community that you are trying to represent and remember, I get really, really, really annoyed with some folks on comments and social media and things, Hey, who knew people on the internet were wrong? But you have to work just really super really hard on finding people. It's not about learning any bars, it's about working harder as a hiring manager to go find the right folks and find amazing people because it is because people, especially from underrepresented backgrounds, are underrepresented, so it's harder to find them and it's harder to get people into your team. So it is harder to make 'em welcome. You have to build an environment where people feel welcome and safe and you have to build a good reputation, not lose it.

Look at your job specs as well. Everybody. Do you really need all those requirements in your job specs? What is it the person's going to do? What are the results are they going to achieve? And make sure you are being inclusive and using inclusive languages in your recruiting.

I want to have a quick chat about team safety and then we'll go over to questions. So for team safety, I like to make sure this is something I use with the teams quite often when I'm talking it's kind of like a fist of five sort of test on psychological safety.

So how people are feeling, how are they working, that sort of thing. You also need to build spaces that people can experiment in. So maybe it's rather than the main social media handle, maybe create a sub handle that you can experiment and tweet on. Maybe create channels, use personal channels and things like that for experimenting in production. Make sure you measure, learn and report back when your team make mistakes. Own it. If somebody on the team messes up, it's your fault. So own that.

Work with the people who have got the issue, figure out what the issue is, figure out how you're going to work it, but it's your fault.

You haven't set the right guardrails in place, so you own it. Give the feedback privately to the individual, report back learnings and make sure you're building guardrails for the team rather than building kind of friction rather than building turnstiles. The thing I also worry about is a lot of times is around trolls and all that sort of thing and doxing and sort of safety of the team. Remember that the way that trolls win is with emotional DDoS attacks. They're trying to consume time from you. So don't waste too much time. Set clear guidelines as to what's in your expected in your community.

Delete ban people without worrying too much. It's not an irreversible decision, but always acts calmly, act quickly. One of the things I quite often jump to, in fact I have a printed out card right next to me with this on and keep it in my wallet, is some steps or incident management that I think you should follow.

You should totally come in, figure out who, why, establish the facts, identify and prioritise your risks. Is this a risk reputation to life safety? I've had bricks thrown through people windows. I've had people docked or that sort of thing. So serious, actual life safety risks or is it a reputational damage?

Is there an asset damage to something to the resources? Money? Things that are money can be replaced. Things that are about life safety or about reputation, it's much harder to build those back. So yeah, identify what the issues are, what the risks are, build an action plan, assign it, track it. Do you need to request help? And then I repeat. And the usual when you know, need to treat something like an incident is when comms is starting to get confused when multiple people are pinging you and you've got multiple people reporting issues and all that sort of stuff, right?

We're finishing up. Last thing is to scale. Remember, you have a finite number of breaths in your body and a finite number of keystrokes in your hand. Let's make them count. Let's build channels that we can do. Let's think about how you amplify or the content that you create rather than doing one, two things. How can you do it to a hundred, a thousand, 2000, all that sort of thing. And that takes me to my final lie of this conference and that is that I know what I'm talking about.

I really don't making it up as we all go along. That's why Dev recon is so important to me just to be able to learn from all the great work everybody's doing. But it also helps when you've got a fantastic team around you. So I encourage you to check out some of their work docs. github. com, go to the YouTube site, youtube. com/github, which is some amazing content there from the latest conference. Or check out our GitHub stars, which are our influencer kind of NDP style group.

Check out them as well for some amazing people doing some amazing work, right? I'm going to hand back and talk to the folks. So thank you very much for your time. I really appreciate it. And there's also the discord for q and a and questions, so thank you.

Brandon West: Awesome. Thank you, Martin.

Martin Woodward: Hopefully that was okay.

It's not often I talk, I'm normally talking about the technology rather than how I work, so it's always a very odd experience. So yeah,

Brandon West: I certainly related to a lot of what you mentioned. I really appreciated the mention of the stages of a team. I've been in tech for over 20 years and I think I've spent maybe 10% of that time on a performing team. If people don't know the theory, I think they might think, oh, teams that are performing. But it's pretty specific and it's really challenging. If you've got any movement on who's on the team or what your goals are, then you slide back a category. But yeah, I think one, I got to say, awesome, that GitHub, you don't have to justify the value of your team.

I know a lot of folks out in the audience don't have that.

Martin Woodward: I'm a very privileged position, so yeah, that's true.

Brandon West: But yeah, I think there's a couple questions from the audience. Some of them are talking about measurement, which I know there's a lot more talks on metrics coming up standby by for that. But the first question comes from Akil Sharma and they're asking, have there been iterations to the team structure since you started? So did you inherit all of that hierarchy or did you build that out?

Martin Woodward: Yeah, I built that out. The team started with, I want to say I should know the exact numbers, mostly dev advocacy didn't really know what people were doing, if I'm honest.

People didn't know themselves what they were really doing. And so we had people who very clearly were dev advocates and then people who were very clearly community managers and they're two very, very, very different roles. But I don't think it was clear to them that they were those two things and that they were focusing on different elements of DevRel. And so putting in some of this formal structures and kind of saying, this is what you do, this is what your job is, this is what a career path looks like for somebody doing community management or programme management versus somebody doing developer advocacy versus a docs writer or a docs content strategist. Each of those things still needs a career path.

If you are a docs writer, you want a path that takes you all the way up to the highest levels in the business as an IC writer, because heck, I really want you writing on my product amazing and so much stuff, and so I need to make sure there's career ladders for everybody and all those sorts of things. And previously it kind of been a bit more ad hoc, and especially with startups, people there isn't really kind of like a promotion ladder and sort of reward systems and reviews and things. So all that kind of stuff is fairly new.

But yeah, that's kind of how it went.

Brandon West: I

Martin Woodward: Know my team are in the chat as well, so they can probably jump into Discord and argue that I didn't do any of that stuff and I dunno what I'm talking about. So yeah, I refer you to line number three.

Brandon West: Yeah, I think that's one of the challenges, especially with a lot of companies that are trying to add DevRel to what they're doing right now is they don't have a very clear sense of what it's going to be and they focus on, okay, let's get someone in here that can get it up and running or continue what we're doing. But that thinking about the future, that path, that career ladder, all of that is super

Martin Woodward: Important. Well, so many people here are one-man DevRel teams or one person DevRel teams often, and that's super hard. And so you've got to figure out how you focus your time, and that's a very, very, very different role to be a one person DevRel shop inside a marketing org than it is to be a larger DevRel team inside of a developer focused company. And I know every company wants to be developer focused.

Every bank could go speak to now says that they're a software company with a banking licence and frankly, GitHub's a swag company with a developer tool on a sideline. But it's very, very different. And the people, what they fundamentally care about and what they fundamentally understand is very different. But I still say that if people want, the majority of feedback senior management get is from what people are talking to them about and what they're hearing from people elsewhere in the org.

We have an amazing position that we get to generate a lot of excitement and a lot of interest in things. So if you are using that to build energy and excitement around the organisation, don't be taking credit for it. Always be giving the credit elsewhere to people and making everybody else shine. People want to then work with you and they're always campaigning, oh, we can't get enough of XY Z's time because of such and such, and so the managers, how do we get you more type?

I need more people. And so it often works like that rather than the okr, how much DevRel generated leads I brought in, what my pipeline is, all that sort of stuff. It is good to have those numbers. It's good to track them for internal measurement. Are we doing better justification wise? It's usually the conversations that people are having with senior management and how much people want to work with you, I think.

Brandon West: Yeah, I agree and I appreciated that you mentioned the safety aspect. I've certainly been on teams where people have been doxed and you're getting emails from legal parts of the business asking if the tweets that people on your team are sending are problematic or not.

So I think it's certainly important that people be aware of that. So I just wanted to say thank you for mentioning that. Someone in the chat also mentioned that those notes about psychological safety, we were very important, so just thank you for including that.

Martin Woodward: Yeah, it really is. That's the thing that worries me the most if I'm honest, is the safety side, not so much the psychological safety. Definitely we have to create that on the team, but it's also, I'm asking people to put themself in the public eye, almost putting themself in harm's way. Are we providing as a business the appropriate security measures so that if something does happen to this person, especially if they're a woman on the internet or if they're from an underrepresented minority on the internet, you know what I mean? They're more likely to get attacked because of those reasons.

And so what safety measures do we have in place? What reporting mechanisms do we have in place so that person can feel like they can do it and that we can get them through this? Sometimes you can't always bring your best self to work as well. It's hard. We are professionally perky for a living and sometimes you're not feeling it and sometimes you feel under attack. And so you've got to make space for when those people are going through those things and help 'em through it.