 Hi, I'm Sid, I'm the CEO of GitLab, and this is a training for our functional group updates. We do functional group updates every workday at 8 a.m. Pacific time, and they're meant to give everyone an idea of what GitLab is working on. Remy, could you mute your mic? The ideal functional group update is to give people a sense of what's happening in other teams at a certain time in the company. We weren't doing functional group updates. And what happened is that people said they lost touch with the company, they lost touch with what we're working on. It's to give visibility and a bit of accountability to the different teams in the company. We do it basically for every group of 10 to 20 people, so it's not sometimes it's functional like sales as one functional group update, but for example in development, we do it for smaller groups, it depends on what we can tell. What happens is that a leader in that group gives a presentation. The presentation is in the form of Google Sheets most of the time, and it's attached to the meeting in the 24 hours before it starts. There's a couple of reasons for attaching it. It helps people to assess whether they want to attend a functional group update. And if they miss the functional group update, you can just flip through the slides. For example, I sometimes miss them, but I always, always flip through the slides. The actual update is a Zoom call, and the important thing here is that it's not about you presenting the slides. People can beat the slides, and they can do that pretty quickly. So you should assume that everyone has read the slides. So what you may be doing is giving a bit of context around the slides, like why is this important? How does it make you feel? What's the highlight? What's the low light? People want to kind of follow a narrative. The thing you should not do, and it very frequently happens, is that people start reading the contents of their slides. This is absolutely unnecessary, and it makes it very tedious to basically watch a recording. So if you're saying something that is on the slides, think of something else to say, or don't say anything and skip through the slides. So the presentation part should be 5 to 10 minutes with an absolute maximum of 12 minutes. So after 12 minutes, people should say, should stop the presenter. So you should aim for 5 to 10 minutes. Now the reason for that is that people say that they stopped following functional group updates because they took too much time. And they're not talking about the questions part, they're talking about the presentation part. The questions part is actually the best part of the functional group update, because those are real questions that people have that weren't in your presentation. So that is the value that you're adding. Basically, the presentation part is like a warm-up to get questions. I think that if we just say, here's the presentation, ask questions. We might get fewer questions. However, I might experiment with that and not say anything, just say, hey, you could see the slides, do you have any questions? That for example worked really well on GitLab 101, where I first did presentations for 45 minutes, then I did a presentation of 10 minutes, and I do zero minutes of presentation. So you just say, hey, you'll review the links, let's ask questions. Because this isn't homework, and a warm-up is nice, a five minutes, we quickly flip through the slides, but please, please don't start reading them out. Of course, it has to end on time, the next thing is the team call, so you have to stop preferably five minutes before the end so people can get a quick drink or do something else before they join the team call. Sometimes it runs right down to the minute, but never, never should you go over the team call. If there's a lot of questions, just refer them to your functional channel. So if you're doing sales presentation, refer them to sales. If you're with the monitoring team, refer them to the monitoring channel. Continue the conversation there. I'm at six minutes, and I didn't have any slides, but there's a whole page of functional group updates. You can find it by googling GitLab, FG, U. Are there any questions? I have a question. In the feedback you've heard, or just from your personal opinion, what do you want to see less of in functional group updates from a content perspective? Is there content in there that you think people should already know this, or is it interesting to a wider audience, or should be disseminated some other way? Interested on your thoughts on that? Not at all. I think the more content, the better, except that I don't want the leads to spend a lot of time on assembling their functional group update, but it's good. If you have 40 slides, that's great. Just put them in there, copy and paste stuff that you think is relevant. You seem a bit serious to me most of the time. It's cool to have a funny gif in there or something like that. What's important is that you're not dwelling on them, that you quickly flip through them. That is the only thing I care about. And talking about repetition, most of the time we underestimate repetition. We repeat too little. So probably like every other company, we should spend more time on the basics and we should spend more time on repeating like, this is our team, this is what we do, these are our top three goals. Put them in the slides, don't read that aloud because the rest of the company falls asleep. And thanks for that question, Sean. Same things goes, for example, for abbreviations and stuff you use, like preferably write them out, link them to the definition, et cetera. Kristen asked in the chat, is it ever encouraged to have someone form our team deliver? It's fine. I don't have a big opinion of that. Someone can do a good job there, but that's fine with me. I do think it's good that the leader of the team is also present for if questions can be answered by the team member. But the important thing is that the FDU is on. So if you can make it, you can make it. So I had a question about the slides. Out of curiosity for maybe some other team leads that are on the call, how long are people spending preparing the slides? For me, I think it usually takes me about an hour of work. Sean says an hour. I mostly spend half an hour. Now we're 30 to 60 minutes. We're an hour, Sarah, an hour, Chad, an hour, Man, an hour, and Eleanor, an hour. So I think an hour is a good investment. Mostly 5,200 people join. So you spend an hour. They spend 20 minutes reading them. I think it's great. I don't really have a question, but I did. There's something that I've struggled with. So I'm thinking that maybe somebody else here has kind of struggled with it. I'm used to creating slides that are succinct and have as little info as possible so that when I am talking, again, I'm not repeating the slides, and people are concentrating on what I'm saying. But in the instructions, of course, for people that can't attend, we want to give them as much info as possible. But when I do that, that increases the likelihood that the things I'm going to say are going to mimic what's already on the slides because I've basically brain-dumped onto these slides. So that's something that I've been trying to strike the balance of, is making sure that I have enough information so you can just skim it and be good, but at the same time not be repeating. So more of a comment than a question. Yeah, I'm going to take it as a question, and I'm going to recommend, Sarah, you go all the way to the extreme of putting all the content on the slides, and then you talk less. So if everything's already on the slides, you have absolutely no caller to add, end in five minutes. That sounds amazingly wonderful. Thank you. And then talk about how the slide basically makes you feel. Like people are all, we don't have an office where people go to kind of get the vibe of how people are feeling. So if they join this, the thing that's much easier to communicate by talking is how you feel about this. So if your slide is like we did pretty research things and our score for the new interface is like twice as much, they want to know how does that make you feel? How does that make your team feel? So you're probably going to have the data about this is the graph of how the net promoter score of the new UITS increase, that's going to speak for itself. But you're going to say, I was so glad to see this result. And I'm so proud of Tori for pulling this change off. And that's why you probably want to do it verbally. But if you want to put in the slides, that you're really proud of Tori, that's fine too. But that's what we need, probably five minutes off. Then one, Sean asked what we should, we do more or less. And I answered that literally like I normally do. But I forgot to say one thing that we're doing currently that I think is really excellent is lots of hyperlinks. So there's lots of issues that are mentioned and they're hyperlinked to the relevant issues. I think that's what we're doing really well. I personally, I click open almost every link that's presented and have a quick look at the issue. Because this is kind of my window onto a functional group. And I can see like what issues are interesting. So I think it would do that really well. If there are no further questions, thank you very much for attending this training. And good luck which are actually used. I think they're very special. I'm very proud that we make them public and keep up the good work. Thanks everyone.