Insights From Gitlab Values

Gitlab has inspirational values and product principles from which I took away the following:

Freedom

You should have clear objectives and the freedom to work on them as you see fit. One symptom of mismanagement is not telling people who report to you what results you want. But don’t go too far in the other direction, by micromanaging how people should deliver those results.

Collaboration is not consensus: You don’t need to ask people for their input, and they shouldn’t ask you “Why didn’t you ask me?” If you did ask them, you don’t have to wait for people to provide input. It’s important to have permissionless innovation, small teams moving quickly.

Prefer cleanup over sign-off: Waiting for approval slows things down. Prevent this with automation or clean-up after the fact, but try to ensure that people don’t need to wait for signoff.

Most decisions are easy to reverse: In these cases, the directly responsible individual should go ahead and make them without approval. As Jeff Bezos explains, only when you can’t reverse a decision should there be a more thorough discussion. This is why Move fast and break things to be such an inspirational credo.

Better wrong than indecisive: There are things that we don’t know about the work we’re trying to do, and the best way to drive out that uncertainty is not by layering analysis and conjecture over it, but rather accepting it and moving forward, driving it out as we go along. Wrong solutions can be fixed, but non-existent ones aren’t adjustable at all.

Responsibility over rigidity: Give people the responsibility to make a decision and hold them accountable for that, in preference to imposing rules and approval processes.

Speed of iteration > quality: In fact, when you iterate fast, your initial version may have low quality, but you will build a quality product soon. People who iterate slowly may think they’re building a high-quality product, but they’re not.

Planning

Accept mistakes: Not every problem should lead to a new process to prevent it. Additional processes make all actions more inefficient; a mistake affects only one.

Make a proposal: If you need to decide something as a team, make a concrete proposal to get the ball rolling. Instead of saying, “Let’s all meet to discuss <problem>” say, “What do you think about this proposal?” Every meeting should be a review of a proposal. Don’t worry that the proposal is bad; it’s there just to get the ball rolling. In fact, one team I worked in called them strawman proposals to remind everyone that the point of the proposal is just to start a discussion, and if we agree on a different path to the same goal, that’s fine.

Under construction: We should always optimize for the long term. This means that users will be inconvenienced in the short term, but current and future users will enjoy a better product in the end.

Do things that don’t scale: First, optimize for speed and results. Only after it’s a success should you figure out how to scale it. If you scale a useless product, it’s still useless. And it takes focus away from building a good product.

Assume you’re wrong: Human intuition is often wrong. To fight this, have a hypothesis and try to invalidate it quickly.

Launch a Minimal Viable Change (MVC), which is the smallest possible solution that offers value to users. It should be bug-free and highly usable, but need not address all user needs. This forces everyone to look for a solution that does 80% of what’s needed in 20% of the time. Launch this solution, and then drive further improvements from actual user feedback, which is better than intuition. Feedback prevents us from shipping the wrong feature, or going in the wrong direction. Doing the whole thing at once seems more efficient, but it isn’t.

You’re doing it right if you’re slightly embarrassed by the minimal feature set shipped in the first iteration. This is hard because you may have worked in an environment where you’re looked down upon for shipping unpolished stuff. Shipping unpolished sutff is painful. It should be, if you’re doing it correctly.

Bias for action: If you have a 10-step plan, execute the first step, and then write another 9-step plan. It will be different from the original plan. So have a bias for action. Don’t write a large plan; write only the first step. Trust that you’ll know better how to proceed after something is released.

Velocity over predictability: Things always take a different amount of time than estimated. If you want to fix this, you should either a) invest more time in estimation or b) Have a reserve of time with unscheduled work, but that only causes work to expand to fill this empty time. Both are inefficient. Accept bad estimates.

Deadline pressure causes a) working longer hours, leading to burnout b) shipping half-baked stuff c) reducing scope d) missing the deadline. Only the last two are acceptable in general.

Document everything in writing, whether issues, design documents or meeting notes… This is necessary to work remotely. It takes hours, more if you’re not used communicating in writing, but it’s worth it, because it can save days of other people’s time.