 a full hour here. So I think I'll start. Hi everyone, welcome to the functional group update for build. I hope everyone can hear me. Yes, perfect. We had a functional group update only three weeks ago. So this, we usually have the five week cycle. But because of some changes in the schedule, it's only been three weeks. So in order to not have one minute group update where I would say, well, everything we said last time we were working on it. So bye. I decided to talk a bit more about something that is more related to the organization of the team than the actual work that is being done. But I hope it will be interesting for everyone to hear. And it might turn philosophical at some point. So bear with me. So let's start first. We're going to talk about work. And I'm not going to read the definition of work or anything. But I can say that effort to accomplish something and that's something, is something that defines the company. So that's the actual work that we want to do as a company. How do we achieve that? By scheduling tasks that will deliver certain results. So I asked myself in the past three weeks, since the last functional group update, why did the build team deliver only two scheduled tasks? If this is how we actually measure the result of success, like if this is successful or not, why did we only deliver two things in three weeks? Is it because we have very complex features? Probably. We do have features that have multiple layers and really difficult to find the start and finish. But we have been delivering things before and they've been similarly complex. So I thought maybe because our development cycle is not matching GitLab milestones. So everyone works from seven to seven. But build team kind of needs to scramble around the release date. So maybe that was it. And I know that we did work on something. So we worked our butts off in the past three weeks. And I was wondering maybe we can monitor work as well. So before the previous functional group update, I created a work issue board that has only four lanes. These lanes are used to explain how tasks come into the build team. So we have one lane that is for scheduled tasks. These tasks are the work that we agreed on before the milestone started. So this is the measure of our results. If we achieve all of the things that we scheduled, we are successful. But we also have unscheduled work. Unscheduled work is the work that also needs to happen in the milestone. But it is not something that we agreed upon before start of the milestone. So unscheduled work varies. It can be some task that came from another team. Or it could be a bug that we need to fix right now because it would break the release. But in any case, it is marking all of the work that we didn't anticipate. We also have internal work. Internal tasks are usually tasks that are not visible to anyone outside of the build team, even to our customers. Think of it as issues with technical debt or the infrastructure. So for example, if we need to create a server that will be used to build our packages, the end result is only visible to everyone else. The work that goes into debt is visible only to the build team. And finally, we have the maintenance tasks. Maintenance tasks are very tricky because they are very simple to do in theory. That means, for example, only upgraded inversion of the software that we ship. But that work is a silent killer because it takes a lot of time of you. For example, if you upgrade a version of software that we are shipping, you also need to test that change and test it in two cases. For example, installation and operate from the previous version to make sure that it didn't break something. And the screenshot I included is just the top layer of the issue board. And the numbers in there do not show the actual number of tasks that we had. Our issue boards only show open issues. I already created a request that we change our issue board to allow both open, closed, and all work that we have. So I collected some stats in the past three weeks. And the numbers are very telling. So we had scheduled nine tasks and we delivered two of them, like I mentioned. But we have had 20 unscheduled tasks that came in and we delivered 19 of them. We also had to do six internal tasks and we delivered all six of them. And finally, we had two maintenance tasks that we both delivered. Keep in mind that this is during one cycle. This is during one milestone that we had to do. So if you are simply looking at these numbers, and if you keep in mind that the schedule work is how you measure results, we failed as a team quite simply. However, luckily life is not that black and white. So I would say we are very successful. But we need to do something about the work we do. Can someone mute themselves? I hear someone is unmuted. Thank you. So how do we resolve this issue? So simplest resolution would be throw more money at it, hire someone. Sadly, our positions for the build engineer has been closed. We no longer can hire anyone and that is going to stay like that for the foreseeable future. You might want to say, well, just deliver what's agreed, right? But again, life does not work like that. So if we do that, everyone else will suffer, including our users and customers. We cannot say, okay, this is unscheduled. We agreed on this move on. One thing that we are doing, if something became a priority, we need to prioritize something else. So talk to the product manager of the team or the build lead. But that also is not okay because we just end up deprioritizing everything because everything else is more important. So one suggestion is to have some more capacity to handle unscheduled work. And this is actually valid, but that would mean that you have to have someone from the team who is able to handle all of the work that comes in. And what happens to the tasks which come from other teams that are completely unannounced, unforeseeable at all? Let me give you an example. One of the other teams last week asked two of the engineers in the build team to join a meeting. Both of them spent 30 minutes of their time in the meeting and they ended up agreeing to work. That is going to come by the end of next month without any consultation with everyone else. So you might ask, why did they even accept that unscheduled work? Well, first of all, because we at build team are super helpful. So we needed to do that. But ultimately it comes down to efficiency. Those two engineers are probably the only ones in the company that can handle the task that was asked from them in an efficient manner. Anyone else could have handled that task probably, but not in the same amount of time. They would probably spend days helping out the other team. And this is where I started thinking, wait, if I cannot give any task to anyone from the team, or if anyone from another team cannot handle the task that is in the build team, that sounded very familiar. And then it hit me, silos. We already created silos even in a very small team like the build team. And shameless plug, those silos are something that I go by every day. They're in my neighborhood. They're trying to figure out what to do with them. It's actually a really cool story, but more on that some other time. Anyway, how do we make sure that everyone within the team can actually do everything that the build team stands for, but also how do we help out everyone outside of the build team, so everyone in the company to help us out? So we came up with beginnings of something that should be very simple, I think. First of all, we decided we are going to have training sessions. If you deliver a feature as a build team member, your final task is going to be train everyone else in the team. The merge request I linked there gives you more detail, but the training is going to be a summary of the challenges that you encountered, the technical details that you had to implement, and it's going to also be a summary of the documentation you've written. So it's not only, it's not going to be replacing any of the tasks that you currently have. It's just going to add a bit more extra that is going to help everyone else in the team. What that also means is once you deliver the training, you are no longer the owner of the feature. You are the tutor for everyone else in the team, and it is completely expected from everyone else after the training to be able to handle the task. Maybe at the beginning with your help, but afterwards, you are no longer the owner of it. How about the rest of the company? Well, first of all, we added how to work with the build team in our build handbook. So if you take a look at that merge request, you'll see when you need to contact us. This is not a comprehensive list, but we try to be as descriptive as possible. If you're working in engineering, go there. And if you notice that any of the tasks that you are doing are covered in the handbook, talk to us. And finally, we started working on delivering packages and images on demand. What that actually means is everyone who works on community edition or enterprise edition project will have a button in their CEI that they will press and it will trigger a build of a package and the Dock Room image of the branch they just made. So this is the work in progress, and I really do expect us to finish this within the next two weeks. So in two weeks, I really do expect to have everyone come back to us and say, hey, this is awesome, or this is really bad, I need more. But ultimately, once you're working on your feature, you will have a ready production package that you can test out and that you can ultimately find out whether there is additional work that needs to be done by the build team. And ultimately, you can help us by proposing a solution while you are working on it. So with these three simple tasks that we did in the past three weeks, or are doing at the moment, we expect to break all the silos completely. Thanks for listening.