How to scale a company from 70 to 500 people: Doug Hanna of Grafana Labs, part 1

Most advice on how to scale a company comes from someone describing it years later. Doug Hanna is describing it from inside, roughly 24 months into taking Grafana Labs from 70 people to more than 500.

Hanna is chief operating officer at Grafana Labs, the company behind Grafana and Loki, the leading open source projects in observability. At the time of this recording the company had just raised $220 million at a $3 billion valuation. This is part one of two. Here the subject is scaling the organization. Part two covers the commercial side, taking enterprise SaaS to market.

An unusual path, even among unusual paths

Hanna started in technical support, which is where he and Michael first crossed paths at Automattic. Most of his early career was in web hosting and adjacent companies, moving from support leadership through consulting and eventually into running things.

He ran A Small Orange for about four years and sold it to a private equity backed conglomerate that went public while he was there. He stayed two years through the earnout as general manager of the company he had sold.

Then he founded Help.com with the same investor. It ran about 18 months before he concluded the combination of team, space and timing was not right, which is his honest summary of why early stage companies do not work out. He notes the team he built there was excellent, and one of those people later introduced him to Grafana Labs.

Zendesk came next, four years. He led the platform for about half his tenure. The other half is where he got his closest look at the COO job, working for then COO Tom Keiser, who went on to become CEO of Hootsuite. Hanna was Keiser's right hand on business operations, strategy, special projects and operating cadence, while Zendesk grew from roughly 1,000 to 4,000 employees and from about $150 million to just under a billion dollars in revenue.

Tech, TAM and team

Hanna evaluated Grafana against a three part test he picked up somewhere and has used ever since: tech, TAM and team.

On tech, the product was widely loved, widely adopted and growing quickly. He admits he had not heard of Grafana before a former colleague joined, and calls that his own failing, because every engineer and site reliability engineer he asked already used it. The detail that got his attention was hearing about the deals being closed. A company of 30 or 40 people was signing Fortune 50 customers, which told him something real was happening.

On TAM, observability is enormous. Essentially any company with infrastructure needs it, and the tailwinds of cloud and containerization all run in the same direction.

On team, he enjoyed his time with Raj, the CEO and co-founder, the other two co-founders, and the early go to market people, and concluded he could work with them.

The last factor was simply appetite. Being a bigger part of a 70 person company appealed to him more than being a smaller part of a 4,000 person one.

Why open source, honestly assessed

Hanna describes himself as relentless about laying out pros and cons, and applies the same treatment to open source. It is not all upside.

Where it works, particularly for software adopted by developers, is community growth and mindshare. Grafana Labs has roughly 750,000 active instances of Grafana, and the business model is to monetize a low single digit percentage of them and build a large sustainable company on that base. He points to MongoDB and Elastic as companies with a comparable open core approach, and contrasts it with Automattic, which he understands to have moved further toward managed services, where the value is in hosting and what you add on top.

A COO who is closer to a CRO

Hanna's scope is not the standard one, and the way he describes it is useful for anyone trying to understand what a COO title actually covers.

He runs all the revenue teams: sales, marketing, customer success, support, professional services, customer education and solutions engineering. He also holds several operating functions including revenue operations, IT, business operations and the rhythm of business, plus special projects.

What he does not own is product engineering, where the CEO is closely involved, and the general and administrative functions like finance and HR, which have their own senior leaders.

Michael's observation is that this inverts the usual arrangement, where G&A sits under the COO and go to market is sometimes added on top. Hanna agrees his role is practically closer to a chief revenue officer with additional operating functions attached. What separates him from a pure CRO, besides not being a career sales leader, is that he is responsible for how the company works as a whole. Goals, how they are communicated, how the business and the team operate.

He is matter of fact that this is company specific. He has met COOs with similar scope and others who are entirely G&A focused.

He also draws a sharp line under a distinction operators should note. At Zendesk, sales strategy and analytics reported into his team, so he worked closely with the revenue organization for years. Supporting sales and owning the number are not the same job. Being in deals, carrying the target, is a genuinely different experience, and it was new to him.

Hiring is the whole problem

Asked what is hardest about this pace, Hanna goes straight to hiring and stays there.

More than 400 people have joined on a net basis since he started. His framing is that every one of those hires is either accretive to culture and business value or dilutive to it, and at that volume the difference compounds fast. He built most of his own team, much of which did not exist before he arrived, running functions the company was standing up for the first time.

The advice he draws out of it is for any leader inheriting a team into a fast growing company. Take stock of who you have, then form a view of where each person is today against where the role needs to be in 12, 24 and 36 months. Then have the conversation, which is the part most managers avoid. Tell people directly what they will need to do to scale with the business at this pace, and be honest that the alternative may be bringing in additional leadership above or alongside them.

His framing softens the message without dodging it. This is not a judgment on anyone. It is what happens in a company that is effectively new every six months.

He offers an image of what that speed does to a leader's own visibility. He used to meet every new engineering leader personally and introduce himself. Now there are cases where he does not know who their manager's manager is, not from disengagement but from sheer volume, amplified by a pandemic that removed the incidental contact.

Distributed by default, with limits

Grafana Labs is distributed, and Hanna is refreshingly unromantic about what that costs.

At the time of recording they were beginning to gather again, supporting travel for anyone vaccinated and comfortable. The plan was to bring the whole company to Whistler for a week in May 2022, an event they were calling GrafanaFest. His own direct team had met twice in six months, and he emphasizes deliberately leaving space in those agendas for people to know each other as people rather than filling every hour with content.

Between gatherings, his intervention is a reminder. When someone is frustrated with a colleague or another team, he encourages stepping back to notice that they have never met in person, and that some of the friction is a shortage of empathy rather than a real conflict. His formulation is that there is an actual person on the other side of the Zoom window or Slack message, and they are not waking up to make your life difficult.

The rest is mechanics: time zone friendly meeting schedules, working asynchronously where it fits.

On asynchronous communication specifically, Hanna pushes back on the purist version. He describes himself as a broken record at work, because when he sees a Slack thread running 40 messages over two or three days, he tells people to get on a call. What they do invest in is writing things down and keeping notes transparent. Every customer has a dedicated Slack channel, so anyone who wants to know what is happening with an account can scroll back rather than ask.

His conclusion is honest about where they have landed. He loves asynchronous work and they trade a lot of documents, but he cannot imagine running everything through written memos, and says they have not figured out how to be fully post geographic. Michael points to GitLab as the company that has pushed the async default furthest, with a similar escalation path to live conversation.

The advice that changed the job

The best advice Hanna got came from Tom Keiser at Zendesk, as he was taking the Grafana role. You are going to have to deal with a lot of things you do not want to deal with, and it is your responsibility to deal with them.

Hanna's reflection is that in earlier roles he could be choosier and leave the messy things alone. That option is gone. It needs to get done regardless of whether it is uncomfortable.

The second thing he has deliberately worked on is the people side, and he is candid that it does not come naturally. He describes himself as an analytic, operational person who has had to invest real time and energy in supporting people as people, building empathy, and helping his team work through personal conflicts with each other and with peers.

His summary of the job at scale is blunt and probably right. These roles are people leadership, management and sorting out drama. Doing the job well requires being good at that, not just at the operating parts.

The 5 things I took away from this conversation

1. Tech, TAM and team is the cleanest job evaluation framework I have heard. It works for taking a role as well as making an investment. Is the product genuinely loved, is the market big enough to absorb ambition, and can you work with these specific people. Hanna's tell on the first one was noticing a 40 person company closing Fortune 50 deals, which is the kind of signal you cannot fake.

2. Supporting sales and owning the number are different jobs. Hanna had years of proximity to revenue at Zendesk and still describes carrying the target as a new experience. Any operator considering a move into revenue ownership should take that seriously rather than assuming adjacency transfers.

3. Say the hard thing about scaling early, and make it about the company rather than the person. Telling someone what they will need to do to grow with the business, and that the alternative is additional leadership, is uncomfortable. Hanna's framing, that this is what a company that renews itself every six months does to every role, makes the conversation survivable and honest at the same time.

4. Every hire is accretive or dilutive, and 400 of them decide the culture. This is the part I would put in front of any founder about to scale headcount fast. The company that emerges is the sum of those decisions, not the sum of your intentions about culture.

5. Async has a ceiling, and pretending otherwise wastes time. A 40 message thread over three days is a failed conversation, not a distributed one. Hanna's version of remote work is a written record plus a low threshold for picking up the phone, which is more useful than the ideological version.

FAQ

How do you scale a company from 70 to 500 people? Hanna's answer centers on hiring quality at volume, since more than 400 people joined net over roughly two years. He focuses his own time on what he can control, builds out leadership for functions that did not previously exist, and treats the question of whether each hire strengthens or weakens the culture as the decisive one.

What happens to a management team during rapid growth? Roles outgrow people faster than people can grow into them. Hanna's approach is to assess where each person is now against what the role requires at 12, 24 and 36 months, then tell them directly what scaling with the business will require and that additional leadership may be needed. He frames it as a structural consequence of growth rather than a personal failing.

What are the COO role responsibilities at an open source company? At Grafana Labs the COO owns all revenue teams, sales, marketing, customer success, support, professional services, education and solutions engineering, plus revenue operations, IT and business operations. Product engineering sits with the CEO and G&A functions have their own leaders, making the role closer to a CRO with operating scope attached.

Does the open source business model actually work? Hanna describes it as a trade with real costs and real benefits. For developer adopted software it drives community growth and mindshare that would be expensive to buy. The business is then built by monetizing a low single digit percentage of a very large base, roughly 750,000 active Grafana instances in this case, the same open core pattern used by MongoDB and Elastic.

How much can a distributed company rely on asynchronous work? Less than the purist version suggests, in Hanna's experience. Grafana Labs writes things down, keeps notes transparent and runs a Slack channel per customer so anyone can catch up without a meeting. But when a thread runs long, he tells people to get on a call, and he does not believe they could operate entirely through written memos.

Also mentioned

• Grafana Labs, and the open source projects Grafana and Loki
• Prometheus, the monitoring system Hanna admits he barely knew before joining
• Zendesk, where Hanna spent four years, and Tom Keiser, later CEO of Hootsuite
• MongoDB and Elastic, the open core comparisons Hanna draws
• Automattic, where Hanna and Michael first worked together
• GitLab, whose public handbook is the reference point for async-first operations
• Part two of this conversation, on scaling the go to market machine

Listen to the full episode

Doug Hanna on Between Two COO's, part 1

Between Two COO's is hosted by Michael Koenig. Subscribe on Apple Podcasts, Spotify, or wherever you listen.