Wardley mapping of Gitlab Strategy.
Gitlab is an integrated developer productivity, infrastructure operations, and security platform. This Wardley map explores the evolution of Gitlab’s users’ needs, as one component in understanding the company’s strategy. In particular, we look at how Gitlab’s strategy of a bundled, all-in-one platform anchors on the belief that build and security tooling is moving from customization to commodity.
This is an exploratory, draft chapter for a book on engineering strategy that I’m brainstorming in #eng-strategy-book. As such, some of the links go to other draft chapters, both published drafts and very early, unpublished drafts.
Reading this document
To quickly understand the analysis within this Wardley Map, read from top to bottom to understand this analysis. If you want to understand how this map was written, then you should read section by section from the bottom up, starting with Users, then Value Chains, and so on.
More detail on this structure in Refining strategy with Wardley Mapping.
How things work today
Today, managing build, deploys and security are somewhat custom endeavors. The kind of work that even small technology companies dedicated teams to operating smoothly.
The value chains across users are highly coupled: there is no value chain that doesn’t overlap across users. For example, debugging a failed build is important to both the developers and to the developer experience team. Similarly, understanding attribution of costs is essential to both the developer experience team and to the finance team.
Because of that bundling, teams that buy best-in-breed solutions rather than a bundled stack spend significant time integrating them together to work properly. It’s not uncommon for teams to spend a day a month on just the finance and developer experience integration. This sort of customization is unique for each company, but is rarely the company’s special sauce. Rather, it’s the result of poor interoperabiltiy between many tools in the people systems and developer systems space.
Transition to future state
It’s fairly clear that more and more components of this map are shifting from custom to product. Gitlab has a clear point of view in these ecosystem standardizing, evolving up from custom implementations and toward products and commoditization.
These shifts will bring an increasingly large number of companies into Gitlab’s addressable market, including annoying but low value problems like storing build and deploy logs for future access. Most markets vacillate between pursuing “best of breed” (you buy a number of specialized vendors) and “all-in-one” (you buy one, comprehensive and highly integrated solution).
Gitlab has placed a clear bet on being an all-in-one solution by solving for both the traditional developer and developer experience users as well as the security user. This appears to reflect a belief that security tooling is quickly moving towards becoming a commodity solution, an interesting view, and one whose validity we’ll see negotiated in the market as Gitlab competes with companies like Wiz and Snyk for marketshare.
User & Value Chains
Gitlab describes itself as “most comprehensive AI-powered DevSecOps platform.” This is a broad ambition, and consequently there are quite a few users for the platform. For this mapping exercise, we are going to focus on four users:
Developers at the company. The product and infrastructure engineers who are using the Gitlab platform as a tool within their workflows. These are the developers responsible for creating and running the company’s product.
The value chains they’re focused on are deploying software, debugging failed deploys, and optimizing the speed at which builds and deploys occur. Underneath those needs are a number of infrastructure components performing the actual deploy, collecting logs for debugging, and so on.
Developer Experience who are responsible for selecting, onboarding and operating the deployment infrastructure in the company. More broadly, this team is responsible for the overall productivity of the company’s developers.
They don’t have any value chain that is unique to them, but they are tightly involved in every other users’value chains. This creates a unique broad view of the map. Further, the developer experience team is generally the expert on each value chain, having the deepest view.
Security & Compliance who maintain the security infrastructure and compliance postures for your company. They require vulnerability scanning to detect supply chain security attacks, as well as identifying common issues in developed software such as the OWASP Top Ten.
The value chain they’re focused on is software vulnerability scanning, which in turn depends on a database of package vulnerabilities and a scanner for detecting those packages and other common vulnerabilities.
Finance who monitor the cost and usage of your platform. They’re most focused on the projection and attribution of costs represented by the platform. For example, they would want to model the infrastructure costs of hiring an additional 50 product engineers in terms of the additional builds, deploys, and so on they would consume.
The value chain they’re focused on is understanding attribution and usage, which in turn relies on an ownership graph mapping each piece of software (and each build, and each test run, and each security issue, etc) to a concrete team within the company.
There are more users we could dig into, but these are the four most important customers in evaluating Gitlab’s strategic approach.