Nebulab

Nebulab's leadership structure is slightly unconventional: rather than having one CEO, we have four directors which make decisions together—think of them as co-CEOs, if you want. Their main responsibility is to hire great people and support them in achieving the Nebulab's vision by constantly iterating on the company's policies and business strategy.

The directors treat Nebulab as if it were a product. They work in cycles of four weeks—these look somewhat like sprints, although they don't present much of the overhead of a regular Scrum process. Each director is welcome to create a ticket and pitch it for the upcoming cycle. Tickets generally impact one or more of the company's strategic goals.

We don't generally require consensus to make decisions: instead, we try to disagree and commit, since running an experiment is often much faster than debating endlessly over abstract concepts. The only exception to this rule are decisions that are really critical for the company's future and/or the team's well-being—these are often discussed at length and analyzed from different angles before a conclusion is reached.

During the cycle, directors typically work by themselves or in pairs of two, depending on the complexity of the task. They chat constantly in Slack, and they meet every Monday for a 1-hour sync where everyone presents their work and asks the group for feedback. Very often, directors will also use 1:1s to collect feedback from the team and make sure they're headed in the right direction.

Complex initiatives and RFCs

For complex initiatives, the first step when executing a ticket is to write a Request for Comments (RFC). This is a Notion document that outlines the problem we're trying to solve and how we're planning to solve it. Our process has evolved a bit over the years, but it's explained at a high level in this blogpost.

RFCs are very thorough and typically include detailed rollout plans, deliberate assumptions, success metrics, future opportunities and any other piece of information that might be helpful to evaluate the problem and the proposed solution.

When an initial draft is ready, the author(s) of the RFC submits it to the group for an initial review and Q&A. This stage is critical in identifying any possible shortcomings in the problem analysis or proposed solution. Often, we will only need to make make slight adjustments to an RFC before execution, but sometimes we'll find that we're completely off track and we'll have to abandon it entirely—this is totally fine, as the main goal of RFCs is to explore and evaluate.

Once the RFC has been approved, it is rolled out, and it moves to an experimental stage where it can be validated in a controlled environment. This can take different forms depending on what problem we're tackling, but it most often means trying the new policy/initiative with a small group of volunteers, or in a way that can be easily reverted.

After an established experimental period, the RFC is either abandoned, if it fell short of our expectations, or rolled out to the entire company, at which point the policy can also be documented in the playbook.

RFCs are an amazing tool to promote deep thinking, create alignment and foster healthy discussions around nebulous and/or divisive matters. Some of our most distinctive policies and initiatives, such as Investment Time and our compensation strategy, were born as an RFC.

Accessible leadership

When designing the process for the directors' work, we wanted to make the decision-making process to be as accessible as possible. Accessible, in this context, meant two things:

1. We wanted everyone to be able to look at what the directors are working on, why they think it is a priority, and what conclusions they reach.
2. We wanted everyone to be able to pitch a company-wide change, no matter what department they work in or whether they're an IC or a manager.

The policy we settled on to make this happen is dead-simple: everyone has read-write access to the Linear board the directors use to define and prioritize work, and everyone has read-write access to the list of RFCs in Notion. At any point, you can create a new ticket, write an RFC or comment an existing one to make a suggestion or ask a question.

Over the years, we've used this to ask the team to look at draft RFCs that we were considering but weren't really sure about, as well as to loop in teammates from all over the company into leadership tasks, when they had the bandwidth to think about them and we thought they were a good fit.