Dimensional Data

One of the core jobs of product managers is to speak with users to better understand their needs, pain points and the context in which they operate and use our products. But not all user calls are the same. There are 3 prominent types of user calls: Discovery or problem validation calls Roadmap discussions Solution validation calls Here’s an in-depth look at how we approach the three types of user calls at GitLab. Discovery calls Discovery or problem validation calls are product managers’ most crucial conversations with users. Discovery calls are typically set up to learn about our users in a targeted way. These calls help build a better understanding of users’ pain points. For discovery, we need a recipe for repeatable, comparable user calls. For this reason, we should create an interview script and follow that script on all the user calls. This does not mean these calls are robotic and devoid of improvisation, not at all! The script should provide the backbone of the discussions. We can adjust it either during the call or in advance based on prior knowledge about the user. Good discovery calls typically take the form of a deep-dive conversation: we know the script by heart and can run back and forth around it, always asking the questions that fit the conversation. Finding the right users is one of the most challenging parts of discovery calls. Thankfully, with GitLab, this is relatively easy. We can always reach out to the most active users on issues and invite them to a call. Another technique I employ is to find users in the Cloud Native Computing Foundation and Kubernetes communities’ Slack channels and articles on Medium. This way, I can also find non-GitLab users, a set of people likely more valuable to interview than existing users. Finally, we can recruit users with the support of the account managers. They are always helpful in connecting PMs with users. Asking the users about their needs shows them that we genuinely care about them. There are at least two distinct discovery calls: PM-led or UX-led. UX research typically works on projects with a strict scope. For PM-driven calls, a great framework is “Continuous discovery” calls by Teresa Torres. With continuous discovery, we build a deep understanding of our users and get well-understood opportunities. The technique allows us to get a broad view and to dive deep into specific aspects of our problem space when needed. Roadmap discussions Roadmap discussion calls are typically initiated by sales or account management teams. Product managers are asked to join the prospect/customer call to strengthen our positions and show how much we care for the customer. To prepare for roadmap discussions, PMs should have an effective way to present the roadmap. This typically happens in the form of slides. A diligent PM might even prepare something specifically for the client. During these calls, the user/customer/prospect will typically ask the questions, and the PMs respond. Our role in these calls is to represent the truth. We might be tempted to paint a rosier picture about the current or expected state of the product than is actually true, and we should avoid making time-bound promises. What are the expected outcomes of roadmap discussions? They can help strengthen our position with the user. Remember that these calls […]

No one ever said hiring was easy. As a matter of fact, talent hiring and retention are some of the hardest aspects to get right for any software company. According to a recent article at Developer Pitstop the average engineer will only stay at a job for an average of two years before moving on, and this tenure is shrinking as time goes on. When we look at the average timeline for engineers in a new role we usually see something like: Learning and adaptation (3 / 6 months): Coming to grips with the new company, team, and their processes. Creating value for the organization (6 / 12 months): Adding value to the business by becoming a functioning member of the team. Becoming a role expert (6 / 18 months): Owning the role completely and helping to shape the direction of the team. At GitLab we pride ourselves on an outstanding onboarding process to reduce the amount of time an engineer will spend in the learning and adaptation bracket and accelerate their evolution into the creating value for the organization bracket. We do this for two main reasons: Quicker integration: We aim to have engineers ship production code in less than one week, and fully onboard them in less than three months. Reduce turnover: Engineers who have an awesome onboarding experience tend to stay with the same company longer. The bottom line is that with these benefits, investing in an amazing onboarding process gives you the highest ROI on your hiring initiatives. So, now that we know why we need to ensure we onboard quickly and correctly, let’s talk about how we do it at GitLab. Overview 💯 Before day one 💥 It’s all about the onboarding issue 🥂 Pick the right onboarding buddy 👌 Pair, pair, and more pairing 🖐 All the coffee chats 🤘 Tailor the experience to the role 🚢 Ship some code in a week or less 💬 Let’s get (and give) some feedback 💯 Before day one The best onboarding processes start as soon as the candidate has officially accepted the offer. This is done in a few ways: An onboarding issue is created with tasks for the hiring manager, their buddy, and People Experience (HR). The hiring manager selects the right onboarding buddy for the engineer and communicates expectations (more on this later). The engineer’s accounts (Email, GitLab account, Okta, etc) are created and their hardware is shipped. GitLab reaches out via email to let the candidate know what the onboarding process looks like. The hiring manager reaches out to the engineer via email to set up a coffee chat on Day 1 as the initial process might seem overwhelming. For us, the most important aspect is communication with the engineer to ensure they are set up for success. We provide them with access to their onboarding issue, helpful video guides for getting started, and a primer on how to navigate our handbook like a pro. The reason this is so important is that we know if we stop communicating with the engineer after signing, we are at risk of creating uncertainty, introducing inefficiency, or even losing them to another offer during that time. 💥 It’s all about the onboarding issue At GitLab, our onboarding issue is the most effective tool we have for […]

Open core is obviously a horrible approach to creating a product with an ecosystem of extensions and integrations: There are no proper protocols and interfaces. Instead, anyone can just add their integration to the code base and even adjust said code base to their needs if it doesn’t fit. So why have we been using the “Worse” approach at GitLab for many years now, with great success? Because Worse is Better (a term conceived by Richard P. Gabriel). Of course, it turns out that “Worse” is actually even better than Worse is Better suggested. Gabriel’s original argument was that (slightly) intrinsically worse but simpler and easier to implement software has better survival characteristics than better-designed, more complex software, and thus will consistently win in the marketplace. At GitLab, we have found that this is basically true, which is why we, for example, favor “boring technology,” even if it might not be the best possible solution for a given scenario. But this doesn’t tell the whole story: It turns out that such software is not just more successful, it also ends up being qualitatively better in the end. Worse is even better It is important to note that Gabriel’s original argument was not that bad software wins out. In fact, both his “worse” and his “better” have the same qualities: Simplicity, of interface and implementation Correctness Consistency Completeness However, his “worse” and his “better” have slightly different weights for the value placed on these characteristics, with the (worse) New Jersey school favoring simplicity of implementation over simplicity of interface, whereas the (better) “MIT” school favors simplicity of interface, even at the cost of a more complex implementation. If a simple interface can be achieved with a simple implementation, both schools agree, the difference comes when there are tradeoffs to be made. What makes worse even better, and what Gabriel didn’t take into account even in later versions, is the tremendous value of feedback loops. Being early doesn’t just let the New Jersey approach win in the marketplace, it also allows it to collect feedback much, much earlier and much more quickly than the MIT approach. Paul MacCready won the first Kremer prize not by initially setting out to build the best human-powered aircraft, but by building the one that was easiest to repair in order to gather feedback more quickly. While other teams took a year or more to recover from a crash, his plane sometimes flew again the same day. And so it was exactly this willingness to lose sight of the prize that resulted in him winning it. In much the same way, it is these quick feedback loops that a “worse” approach enables, started much earlier, that eventually lead to a better product. The problem with plugins At least since the success of Photoshop, a proper plugin interface has been recognized as The Right Way to make software both more compelling for users and less easy to leave behind by creating a third-party ecosystem that provides useful functionality without the vendor having to provide all of that functionality themselves. It was so successful that systems like OpenDoc took the idea further to be just a set of plugins, with no real hosting application. None of these systems succeeded in the marketplace. One of the reasons is that good plugin interfaces are not just hard, but downright fiendishly difficult […]

GitLab was founded 10 years ago on Git because it is the market leading version control system. As Marc Andressen pointed out in 2011, we see teams and code bases expanding at incredible rates, testing the limits of Git. Organizations are experiencing significant slowdowns in performance and added administration complexity working on enormous repositories or monolithic repositories.  Why do organizations develop on monorepos?  Great question. While some might believe that monorepos are a no-no, there are valid reasons why companies, including  Google or GitLab (that’s right! We operate a monolithic repository), choose to do so. The main benefits are:  Monorepos can reduce silos between teams, streamlining collaboration on design, development, and operation of different services because everything is within the same repository. Monorepos help organizations standardize on tooling and processes. If a company is pursuing a DevOps transformation, a monorepo can help accelerate change management when it comes to new workflows or the rollout of new tools. Monorepos simplify dependency management because all packages can be updated in a single commit. Monorepos offer unified CI/CD and build processes. Having all services in a single repository means that you can set up one system of pipelines for everyone. While we still have a ways to go before monorepos or monolithic repositories are as easy to manage as multi-repos in GitLab, we put together five tips and tricks to maintain velocity while developing on a monorepo in GitLab. 1. Use CODEOWNERS to streamline merge request approvals CODEOWNERS files live in the repository and assign an owner to a portion of the code, making it super efficient to process changes. Investing time in setting up a robust CODEOWNERS file that you can then use to automate merge request approvals from required people will save time down the road for developers.  You can then set your merge requests so they must be approved by Code Owners before merge. CODEOWNERS specified for the changed files in the merge request will be automatically notified. 2. Improve git operation performance with Git LFS A universal truth of git is that managing large files is challenging. If you work in the gaming industry, I am sure you’ve been through the annoying process of trying to remove a binary file from the repository history after a well-meaning coworker committed it. This is where Git LFS comes in. Git LFS keeps all the big files in a different location so that they do not exponentially increase the size of a repository. The GitLab server communicates with the Git LFS client over HTTPS. You can enable Git LFS for a project by toggling it in project settings. All files in Git LFS can be tracked in the GitLab interface. GitLab indicates what files are stored there with the LFS icon. 3. Reduce download time with partial clone operations Partial clone is a performance optimization that allows Git to function without having a complete copy of the repository. The goal of this work is to allow Git to better handle extremely large repositories. As we just talked about, storing large binary files in Git is normally discouraged, because every large file added is downloaded by everyone who clones or fetches changes thereafter. These downloads are slow and problematic, especially when working from a slow or unreliable internet connection. Using partial clone with a […]