How Grafana Labs is reorganizing for growth
Growth
As you most likely know, Grafana Labs is growing. Growing like crazy! As Goutham Veeramachaneni noted in his blog post, “~30 people in March 2018 and now, in August 2020 we’re 180+ people. That is 6x growth in 2.5 years.” And we have no intention of slowing that growth. Matter of fact, we’re hiring as quickly as we can — and on top of that keep hiring specialists just to scale out hiring even more. It’s insane, it’s fun, it’s a good place to be in — both as individual humans and as a company, especially right now.
One direct result of this growth is that what makes sense today might not make sense tomorrow, and vice versa. Our culture is one of incredible adaptability, and we’re actively and constantly re-evaluating a lot of things. Yet, obviously, bigger changes happen less often than smaller ones. And one of the biggest changes you can make as a company are the dreaded reorgs. But to scale and to grow, we needed to reorg the R&D/engineering side of the company. Sounds scary, right? Well, it ain’t.
As Goutham noted, this didn’t involve layoffs. It didn’t mean someone consolidated their power. It didn’t mean that someone needed to make a bang. It simply meant rebalancing workloads and allowing for more growth and even more feature velocity.
Reorganization
I want to talk about one aspect of this reorg that might intuitively sound like A Bad Thing to all FLOSS veterans out there: Grafana Labs’ internal management structure pivoted from a project focus to a product focus. Why is this a good thing? Let’s talk about governance and project structures for a bit. :)
You will have heard of Prometheus by now and might know that I’m the designated janitor and cat-herder of the project. And I tend to think a lot about processes within a given community, about how to encourage collaboration, about how to grease the social wheels. While I won’t claim that Prometheus is perfect, it’s a successful project that has been chugging along quite nicely for several years now. And while Grafana Labs may be employing the highest number of Prometheus developers, it’s very much a project built on mutual respect, bringing the intentions of many different people and companies together under one shared project. No single company has control over Prometheus, and all of us take the standalone properties of the Prometheus project very seriously.
Standing on the shoulders of titans
In Grafana Labs, squads are groups of people working on one thing, orthogonal to teams, which are groups of people reporting to one manager. I spent much of the last quarter adapting the Prometheus governance model to the various Grafana Labs projects and their squads. Not just copying a file over and declaring my work done, but explaining the reasoning behind it, showing the advantages of this model, and answering many questions about best practices and corner cases. Basically dry-run the governance with each project-specific squad. We also externalized certain internal mechanisms and implicit social contracts, e.g., WORKFLOW.md.
And that is, in part, the basis for this reorg, and it’s the reason why the reorg is not making me concerned, but making me excited!
Truly open source
To explain why, I need to jump back to the “products, not projects” bit. Before, internal and external requirements related to a project would be put onto the backlog of a single project squad. Now, if a Grafana Enterprise customer needs a feature, the Enterprise division needs to provide the resources to implement this feature. Same for Cloud, and so on. But not only that, they also need to coordinate with all other project members.
And that’s what makes me excited. We know these processes work for complex projects. Not only are they in a long, long history and tradition of successful FLOSS projects, but they are literally adapted from a project many of us are actively working on. We’re living these processes, so we know they work and we know they scale. We can help our peers, inside and outside of Grafana Labs, fill these processes with a life of their own — or rather, with their own lives.
Open source model even for our internal closed source code
Treating external software in Grafana Labs like any other FLOSS project means we’re adapting means of cooperation that scale almost endlessly. So we’re not bottlenecking around a specific thing; we’re massively parallelizing the main motor of our innovation.
And we’re using the same mechanisms for our internal software, be it Enterprise offerings, deployment tools, or service configurations. Even when we can’t make it visible to the public, we’re applying the same underlying mechanisms.
Join us
We will be employing more, not fewer, full-time engineers dedicated to those open source projects. For moral reasons because open source is A Good Thing(™) and for business reasons.
If this sounds nearly as exciting to you as it is to me, we’re always hiring. What use would it be to reshape our company to allow for growth and parallelized development if we didn’t fuel this motor with some of the best and nicest people I ever had the privilege to work with?
