Subscribe

What I learned at GitLab that I don't want to forget

After a little over 5 years, I'm going to be leaving GitLab for my next adventure. It's no surprise to those of you who have been following me that I have absolutely loved my time there. I'm so proud of what we built—and I'm still proud and awed by the remarkable people there. GitLab's values are the gold standard for what it means to be a wonderful company—for the team-members, for the community, and for the shareholders.

I hope that I can take even a small portion of that to my next adventure—but I wanted to be more specific to both myself and all of you about the things I think are most important to remember. It's hard to pick a "favorite" value or sub-value, so I've tried my best to summarize those life lessons that I've learned in three categories here:

  1. Write down everything
  2. Give and accept: ownership, agency, and responsibility
  3. Be transparent with a low level of shame

If you want to stay up to date with the rest of my journey, please subscribe to this blog, as it will contain the semi-irregular updates along the way 😁

Subscribe for free

Write down everything

How many times in companies or organizations you work with do you hear (or say) "I wish we wrote more things down" or "we should make decisions and document them" or "we should do more documentation for X or Y." When you work closely with other people, it is easy to not write things down - humans are made for person to person interactions...which is fantastic. As an extrovert, I love person to person interactions. But when it comes to processes and memory, people are very inconsistent...that's just human nature. That's why we invented writing to begin with.

The superpower that is just writing things down is often overlooked or regarded as a task for "later." But if you instead flip that on its head and start with writing things down - collaborative meeting notes in real time, the why's of a decision, the process you are following - you gain super human abilities. A single source of truth for everything allows you to more easily collaborate not just with other people - but with your past and future selves. And doing so transparently enables people to fit their work into their lives instead of the other way around, enables remote working to be actually better than in-person/in-office working. You can also reduce the number of meetings required to get things done.

In addition to these benefits, favoring asynchronous communication over synchronous communication means that when you do meet in person - virtually or otherwise - those meetings are MUCH more effective. Instead of spending half the meeting getting folks up to speed, you're able to hit the ground running and make decisions much faster. And when you say "why" not just "what", you enable everyone to reduce the back and forth that can come from not understanding a decision.

Give and accept: Ownership, Agency, and Responsibility

Starting with an example

I am a strong believer that in order for a business (especially one in a field like software that is 99% if not more knowledge work) to be successful, you have to hire adults and then treat people like adults. And what I mean by that is that many times businesses - especially large ones - think that the right way to think of people is as resources. And resources must be managed in the sense that you have to create policies that bend them to your will. This never works, is an old style of management, and is one that has really no place in the 21st century.

The number one example I always shared from GitLab's massive handbook was the policy on spending company money. That policy, of course, has the usual items about travel, expenses and reimbursement. But the first line item from the policy is:

1. Spend company money like it is your own money. No, really.

Many companies will have massive policies to try and get you to conform to what they deem as "correct" at a perfect point in time. But exceptions arise to that - when a customer needs you or nothing is available that is "in policy." Instead of crafting the perfect policy to fit humans into, hire adults and expect them to act like it. If someone can't reign in expenses and stays at the Ritz-Carlton every night, the answer isn't to have a policy that prevents it, the answer is that person shouldn't work for your company. They aren't a good fit.

DRIs and decision-making

While that is a small and really insignificant example, it is indicative of a larger attitude and expectation that enables you to move fast and make the right decisions. You should expect people to all be managers of one - responsible for their time and actions in getting the job done that needs doing and that you hired them to do. Couple this with a bias for action over inaction and measuring results and not hours worked, and you have a recipe for success.

When it comes to decision-making, you have to balance the need to decide with the ability to weigh opinions on that decision. While on the surface this seems like a hard thing, there are two practices that make it clear to everyone how to do it. First, every decision needs a clear DRI (directly responsible individual) who is responsible for the final decision. If it is not clear who that person is, the first job should be to clarify that, thus clearing the way for the decision to be made in the first place. Decisions can't all be made by committee and thus need to have a person who makes the judgment call.

Second, enable a culture of disagree, commit, disagree. Everyone should be able to contribute their own perspective and experience to a decision. That may lead to them disagreeing with the path you are taking, but that doesn't change the DRI's ability to make the decision. And once the decision is made, you should all commit fully to the decision, as you've already agreed on whom the DRI is. However, you should also still feel comfortable internally continuing to disagree and discuss if the decision that has been made is the right one.

Agency & Family and Friends First

When you combine the concept of writing everything down with DRIs for making decisions, you come to a powerful place where folks can work asynchronously yet always "in sync." You can have the best of all worlds: collaboration that rivals an office job and flexibility that makes remote work a dream come true.

Once you have established these norms, then giving individuals and teams agency over working on what the most important things are is extremely beneficial. Gone are the days of needing a "command and control" management style, and now teams are freed to do their best work when they see fit.

This enables things like a non-linear workday, creative thinking, exploration and invention, and extreme focus when needed. Coupling all of those things with an attitude that family and friends have to come first, work comes second builds trust and loyalty in a way that is unable to be replicated with any other incentive - money, equity, time, benefits, titles, pizza parties. Simply by caring about people as individuals and not as their work, allows them to actually do their best work.

Be transparent with a low level of shame

So, I have to admit, I've saved the “best” for last – and by “best” I mean both the largest force-multiplying superpowers and the hardest ones to really embrace. If you thought that canceling meetings, writing things down, and putting family and friends first was hard…buckle up.

One of the key concepts to discuss here is that everything is in draft. As often as possible, you should ship something rather than wait. At GitLab, one way we talk about this is the concept of “MVC” or minimal viable change. Put out of your mind the minimally viable product or even the minimally viable feature. Those things are too large and complex to reason with – that's why we end up with all the jokes around estimation and shipping late in software. You can, however, reason about a minimal change—and if it makes the product better (even if you know the real feature needs a lot of work) then SHIP IT. Shipping early, frequently, and on a cadence allows you to shorten the time to feedback and accelerate getting you to where you really need to be.

But this concept—iterating on small changes frequently—can be extended well beyond software. When you're already writing everything down, you can now iterate on everything the same way: presentations, policies, procedures, and the company as a whole. To do so, you have to ship all of these things early too, which requires a low level of shame. Instead of being scared to show your boss something that isn't done or perfect, sharing it early and often allows the final product to be even better, typically faster as well. And even then, remove the term I just used—final product—from your vocabulary. Everything should be in draft and thus always be able to be improved as things change.

Doing all of this allows you not only to deliver better software faster, it allows you to manage your company in much the same way. This is especially critical in high-growth startups, but there is another concept here that is even more universal: focusing on increasing decision velocity. Decision velocity is one of the main things we mean when we say “big companies can't operate like a startup.” But you can reclaim some of that decision velocity by implementing the various techniques we've discussed. Having a DRI, treating everything as a draft, writing down decisions. These all enable it – and lastly, you should also recognize the difference between one-way and two-way door decisions.

One-way door decisions are when deciding to go one way or another isn't easily reversed. Think of removing a tier of your product or changing your pricing model. While you can, of course, change those things again, you want to be fairly confident in them as going back will be painful. But not all decisions are like that – many could be easily changed, especially if you're shipping on a consistent cadence. For those two-way door decisions, team members must feel empowered to make them quickly, without delaying for a committee or fearing reprisal if the decision is later shown to be “wrong.” If your culture allows for adjustment and treating things as in draft, this will greatly decrease shame and worry and increase decision velocity—which is directly tied to product and company velocity.

More Reading

If you've gotten to this point, congratulations! And if you're still looking for more, let me recommend a few more things to read on the subject. Also, this serves as my set of links that I don't want to forget about after leaving GitLab - that seemed like the appropriate meta way to end this discussion.



Comments ()