It has been just over 10 years since I was first introduced to a team process called “Golazo”. It as developed inside the company and there wasn’t much information available on it publicly… until recently. I’ve been spending time gathering various documents and recordings about it, attempting to remove any internal jargon, and then publishing it on GitHub. Today I also made a blog post on the official Azure Compute blog.
It’s a bit difficult to get people excited about a team process, but this one has had such an enormous impact on my job trajectory and satisfaction that I’m happy to get to share it externally. I won’t go into the full sales pitch, but here are three of my favorite parts:
- I’m limited to working on two things at once. Context switching and multi-tasking is not only proven to be inefficient, but personally it also adds a lot of mental weight. Focusing deeply on only one or two tasks at a time keeps me from feeling like I’m getting buried and also lets me do better work because I’m not having to reload all the context.
- It’s hard to get people to write documentation, but writing down what I’m doing, how I’m doing it, and why I’m doing it does amazing things for not only helping me sort out my own thoughts but also for getting feedback from others, teaching newer team members, and keeping a written history of our decisions. We do this for every task (where a task is something that takes between 1 day and 2 weeks.) It has made the code reviews at the end much more enjoyable because we’re not having architecture arguments after someone spent a bunch of time writing code. Plus, we have a huge knowledge base of information that has just grown organically. I don’t have to waste brain space trying to remember it all because I know I can look it up at any point (and increasingly, I can ask AI questions about it.)
- We succeed and fail as a team. Generally this is fun. Sometimes it is awkward. But forcing yourself to take shared responsibility for everything on the team improves design discussions up front and encourages more ideas about how to make improvements to avoid problems in the future.
This is by no means the most common method of working inside the company, but it’s the best one I’ve seen. There have been a few points in my career where I’ve had the unique experience of starting up a new team or working by myself for a while, and even when I’m working on my own, I still follow this process. It helps me visualize the work that needs to happen, stay focused, and keep a log of my past decisions.
While I tried to organize the GitHub docs into something consumable, I know that it can be intimidating to try to make sense of it all so please feel free to contact me directly for more information!