All companies have different ways of creating new products and services. Despite that, there are a few patterns that show up consistently. At Jump, we like to call those patterns the different "cultures" of innovation. One such pattern has to do with execution. Great executors (like GE and FedEx) are masters of sharp focus and efficient machine-making.
Many of the Fortune 500 companies that we work with do their best innovation this way. They've built infrastructure that excels at launching products globally, coordinating thousands of employees and operating at massive scale. These companies often ask us what they can learn from what's going on in Silicon Valley. There's much to learn, of course, from the startups and entrepreneurial ecosystem here.
The important question is not "How do they do things in Silicon Valley?" Instead, it's "What can I learn that would work well in my organization?" It's always exciting to come across a startup that's doing what these big companies do best – execute at scale – and doing it in a completely different way.
GitLab is one such company. They're an open source software company powering many of the world's largest corporations. They've developed a surprising – and strong – culture of innovation. They're a remote-only company. There's no physical headquarters or office space for their 200+ employees located worldwide. They proudly admit that they value "boring solutions." Their entire business strategy is available for the public and their competitors to see. They're respected for their product, their culture, and their results.
Many companies pride themselves on their ability to iterate quickly and answer yes/no decisions rapidly. Even they might be surprised at the scope and scale of GitLab's efficiency. GitLab drives high-efficiency innovation through a culture of rapid execution. They weave speed directly into the fabric of who they are and what they do. Do you want to learn how they do it? I recently shadowed GitLab's CEO, Sid Sijbrandij, and his team for a day.
Here's how they make it happen.
When the answer is clear, build for speed. Speed wins.
Why build a culture of rapid execution?
With such a unique team culture and set of business practices, the first thing I wanted to learn from Sid was why GitLab operates the way it does. What became clear was that it's all very intentional.
A few key beliefs are central to the decisions they've made:
Belief 1: The solution required to win is already super clear to everyone.
They're operating in a market called DevOps, which is about creating platforms and tools for software developers to use in their work. It's a market where both the unmet customer need and the ideal solution are clear to everyone.
They were newer to the game than some brand name and legacy competitors, so they chose to prioritize speed over invention to get to the finish line first.
Belief 2: If you don't do anything new, you can do things faster, bigger and better.
The folks at GitLab believe that it's better to be boring. They value "boring solutions." It's not because boring is better in and of itself. It's because boring is efficient. It's faster. And faster can become bigger. And when you add in collaboration with a global open source community, bigger can become better.
If there's a market standard, they don't try to create something different. They get on board. As Sid says, "It's about convention over conviction. We make sure everyone [in the open source community] is enticed to participate. If the rest of the world is doing it in some way, we should be doing it in that way."
Belief 3: It's OK not to make everyone happy.
It's hard for most companies – and most people – to change to what made them successful in the first place. For GitLab, making those kinds of changes is critical to achieving the growth they seek. So on a daily basis, they choose to act quickly, make mistakes quickly, and learn from those mistakes quickly.
That can lead to decisions – big and small – that might not make everyone happy.
When they launch a completely new version of GitLab (they're on version 10.6 right now), they always add some things that will frustrate some existing customers, and they often take away things that other customers love.
"There's way more people not using GitLab than that are. So we should always optimize for those future customers, not your current ones. That's why companies slow down. They start listening. Engineers want to fix the current bugs. Sales wants to keep the old deck that works for them. You start listening to your customers and what they need you to maintain or fix. The natural motion of any company is to slow down. So as CEO you need to get the company beyond that."
So what does high-efficiency innovation and rapid execution look like at GitLab?
Here are a few examples of the pace at which they operate:
- They release a new version of GitLab every single month.
- Everything is in draft and subject to change. It's always under construction.
- They don't repeat themselves. GitLab documents how it does things in a handbook. It's 1,000 pages long. If it's in the handbook, don't repeat it.
- Every conference call starts on time. No wasted minutes. Sid checks 15-30 action items off the list in each of his 25-minute 1-on-1 meetings.
- They trust their team to multi-task appropriately. If you want to check email during a meeting, it's probably more important than the meeting is to you.
There's a final, often-overlooked value of speed: it's exciting. Workplaces that manage to pair speed with evident progress allow their teams to feel accomplished, motivated, and on the edge of their seats. It's an easy hack for maintaining employee engagement.
Don't sacrifice long-term vision for short-term speed. Be accountable for both.
What is GitLab is rapidly executing on?
Many companies who prize execution do a great job at sustaining and growing their existing products. They're often quite efficient – though they could learn something from the speed at which GitLab operates. But they're more likely to struggle with thinking far out into the future.
To paraphrase Stephen Covey, there's a big difference between efficiency and effectiveness. A jet flying 1,000 miles per hour is efficient; a jet flying 1,000 miles per hour in the right direction is effective.
So if GitLab as an organization is a jet built for speed – where is it going?
Sid wants GitLab to help multiply the potential for progress that humanity can drive into the world. "Our mission is 'Everyone can contribute.' That's a long-term vision. That's 10 years. It means changing all of our culture to read-write. Think Wikipedia. They allow everyone to contribute. Imagine if we can do that. You release a lot of progress. You 10x the progress. [Multipliers like that are] thrown around so easily in Silicon Valley that you have to be cautious. But if you look at 100,000 companies using GitLab, and really being able to get their out software faster. I'm willing to stand behind that."
That means that not only is GitLab thinking about efficiency and effectiveness, but it's also thinking about impact. Impact on the scale of human progress and global culture.
That's pretty big and pretty far out. So how do they make sure the pilots keep looking way out there on the horizon while flying at supersonic speeds and maneuvring around today's obstacles?
First, you set the mission and vision. Everything starts with that mission in mind. Everyone knows it, and Sid talks about it every chance he gets.
Next, you draw that vision back into today's actions with cascading plans. Create a three-to-five-year strategy about how to get there. Craft a yearly plan and product vision – one that's concrete enough that you could show screenshots of what it will look like a year from now. Define quarterly goals (GitLab's OKRs are public), monthly targets, and smaller sprints to get you there.
Third, you make each of these regular goals highly ambitious, close-in, unambiguous, and concrete. "Setting high goals pushes people beyond their comfort zone," Sid told me. At Y Combinator, he says they taught GitLab that "20 percent is the new 10 percent." That's 20 percent growth, every single week. It's a high number, and it forces them to make completely different types of decisions.
Finally, because the short-term goals are incredibly high, you focus on iteration. Iteration is one of GitLab's core values. They define it clearly: "We do the smallest possible thing and get it out as quickly as possible." And they don't just ask developers and designers to work this way. "We put the whole company on that diet. It made sense for the product. But for marketing, sales, etc., we've gotten them there. If you say 'Grow XYZ in the next two weeks,' you do completely different things. I don't know why that is, but you do."
Encode culture and values to keep the company moving faster.
How does GitLab do what they do?
It was GitLab's strong culture and values orientation that first drew me to them as an organization. I'm often on the lookout for how leaders drive values through their organizations – from Jon Stewart on "The Daily Show" to the frontline teams at Starbucks and Zappos.
The best values-oriented organizations draw explicit links between their values, their competitive advantages, and their daily activities.
Here's where GitLab stands out.
In just one day of shadowing GitLab's staff, the team talked about values during a product meeting, two interviews with prospective employees, an analyst call and a 1-on-1 with a teammate. The whole team is drawing causal links between what it does (its business activities) and how it does them (the values they live by).
The whole team is drawing causal links between what it does (its business activities) and how it does them (the values they live by).
So how does that work? It requires leaders choosing to identify not just the values that matter, but also how to organize around them. Sid told us "I didn't do a very good job coding GitLab [when he and his co-founders all started back in 2011]. But I think I'm doing a good job coding GitLab the company."
As a remote-only company, "coding the company" means (1) writing things down, (2) referencing back to what's been written and (3) reinforcing it through rewards.
All of this "GitLab the company" code is captured in its handbook. The handbook is referenced in almost every conversation. The handbook consists of over 1,000 pages of text. It's a tool that GitLab uses to capture and detail out decisions that have already been made about all of its core business practices – marketing, sales, product, team operations, finance, and more. It's a constant practice for Sid and the team to reference the handbook in meetings, and to send people to look there first before continuing the conversation.
The values take a prime place in the handbook. There, values are defined, not just described. Words can mean different things in different contexts – and these values indicate a particular thing at GitLab. The definitions are brought to life with 5-15 concrete actions that employees often take for each of the six values. As Sid says, "The culture got stronger because it is written down. And because it improves and is edited over time." And then they're reinforced every day through hiring, coaching, performance reviews and casual conversations.
It's rare that companies think about linking their values with their competitive advantage. It's rarer still that a company brings its values to life through the day-to-day work. What GitLab has unlocked with its values orientation is not just good and meaningful work. It has also opened the most important competitive advantage in its business model – speed.
It's rare that companies think about linking their values with their competitive advantage. It's rarer still that a company brings its values to life through the day-to-day work.
It says it right there in the 'Why have values' section of the handbook: "Values are a framework for distributed decision-making; they allow you to determine what to do without asking your manager." By encoding values deep into everyday activities of the company, everyone on GitLab's team can make decisions faster.
In DevOps, winning is about getting there first. GitLab coded values right into its organizational design to make sure it could always be the fastest to market.
Parting thoughts: Will high-efficiency innovation work for you?
Although they weren't thinking about large corporations, the oracles of Delphi were right. The most important maxim is to "know thyself." The GitLab prescription isn't right for every company. What's most important is to build a culture of innovation that reflects your strengths and your values.
GitLab is a company of executors, of coders and of people who aren't afraid to work out in the open and make mistakes. They see clear problems. Then they attack. GitLab built a method of innovation that works well for them, but it's not a one-size-fits-all approach. It won't work for everyone, but it might work for you.
Here are the questions you should ask:
- Is the problem you're facing clear to you and your competitors?
- Would the people on your team prioritize efficiency over novelty if it'll get you there first?
- Do you know how to make trade-offs between what works for your existing customers and what might work better for future customers?
If you answered yes, pay close attention to what GitLab is doing. Their unrelentingly quick iterative process might be just what the doctor ordered to scale your innovation.
If not, the GitLab system isn't the right fit for you. You'll want to organize your innovation in a different way.
As one example, we built Jump to handle an entirely different type of highly ambiguous problems. So it makes sense that some of Jump's values (Passion, Curiosity, Enthusiasm, Intention, Acuity, Initiative and Play) look very much the opposite of GitLab's values (Collaboration, Results, Efficiency, Diversity, Iteration and Transparency).
Jump and GitLab are both deeply values-oriented companies with rich and collaborative cultures focused on innovation. And yet we value different things, have different org structures, hire different types of people and work on very different types of problems.
So what if you're like me and your company's approach or market situation is quite different than GitLab's? Take this as an opportunity to learn from seeing your mirror image.
First, test parts of their approach. See what works for you and your team. Then, consider the polar opposites. Find the points where you value distinctly different things, and ask why. Learn why their method works for them, and why it wouldn't work for you. Then flip the script – what's an approach to innovation that GitLab would never do that would be a difference maker for you if you did it?
Either way, take note of what GitLab is doing and how they're doing it. It's amazing, effective, growing like crazy and a great place to work. And ask yourself – should my team be innovating like that?
About the guest author
Jay Newman is Director of Strategy at Jump Associates, a leading strategy and innovation firm. Learn more at jumpassociates.com and connect directly with Jay on LinkedIn.
Photo by Karsten Würth on Unsplash
