A Vision about Post-1.0 Governance and Leadership

What should the Streamr project look like beyond the 1.0 milestone? Having reached the 1.0 milestone earlier this year, this question has been the main topic in various discussions recently. There are many angles from which to approach the question, including go-to-market, adoption, and roadmap, and those topics have already been touched on in this blog post.

One aspect of the Streamr project we haven’t improved in a while is its governance. We introduced token-based voting in early 2021, and since then there have been 20 solid proposals going through the governance process, and all of that works pretty well.

However, there are various levels of governance and project leadership that are worth considering. The SIPs are an amazing tool for big high-level decisions, but the people and structures in practical project leadership and day-to-day operations have stayed the same since the beginning of the project. And while it’s been ok for the early part of the project, all of that should be made more robust and scalable now that the project is in a more mature state.

In this post, I’d like to share my thoughts about it. My goal is to create a structure that enables the project to keep going for the next 100 years, or whatever time frame well beyond any single individual’s involvement.

Here are the four things I would like to achieve:

1) Remove bottlenecks and single-points-of-failure in project leadership

Since the start of the project, I’ve been wearing many hats. I’m the project CEO, de-facto CTO, product owner, as well as CEO and Chairman of the legal entity Streamr Network AG. Perhaps a few other things too. Up until this point it’s somehow worked, and dare I say we’ve even been moderately successful, but it’s obviously not sustainable in the long term and it’s definitely been holding us back. I’m holding us back! Early stage projects can (and need to) tolerate high person-risk in the beginning, but we should now be entering a maturity stage, and it’s hard to imagine the project still looking like this in five or ten years’ time.

Back in 2017-2019, I was quite inspired by how Vitalik actively made himself unnecessary for the day-to-day operations of the Ethereum project, while remaining a respected voice, visionary, and a father figure in the Ethereum space. Ethereum would absolutely not be as successful as it is today without those efforts, as the growth would have been inhibited by too much risk attached to one person. While Streamr is a much smaller project and not entirely comparable, I strongly believe I should attempt something similar to enable the project to succeed in the longer run.

2) Establish active strategic steering and ensure checks and balances

The project’s leadership hierarchy has always been radically flat, for better or worse. Above the day-to-day project contributors are the token holders, and there’s nothing in between for checks and balances and to provide strategic steering. 

Web3 projects don’t need to (and usually shouldn’t even) imitate companies at all, but just to illustrate a point, in traditional companies there’s the Board of Directors which doesn’t exist in web3. The job of the board is usually to set the company’s strategy, appoint and oversee the top-level directors, ensure compliance, and so forth.

As the traditional model is tried and tested, there could be aspects of it worth copying into web3 to strike a balance between the direct but inefficient decision-making of the DAO, and the efficient but more centralized decision-making of the active project team.

3) Reflect project focus in project organization

Up until 1.0, the main focus of the project has been R&D and the delivery of the project roadmap. During that phase, it also made sense that the project was heavily structured, staffed, and led in a way that maximally supported that focus. Post-1.0, the project’s focus shifts to protocol adoption. R&D is still crucial of course, but its goal is no longer to deliver the predetermined roadmap—instead, its goal is to boost adoption by providing improvements and unlocks for current and future users. Given the laser focus on adoption and partnerships, how should the project be structured, staffed, and led?

4) Further decentralize governance by empowering token holders to elect a steering committee

The governance of the project is already decentralized to a large extent in that SIPs, Streamr Improvement Proposals, can be posted and voted on by token holders. So token holders can decide what should be done in the high level, and although the scope of SIPs is not limited to just the ‘what’, there’s no particular mechanism to encourage or require the token holders to decide on the who part: who has the power to steer and influence the day-to-day of the project.

— 

Now that we understand the motivations, goals, and the underlying issues, let’s roll out the actions I propose to address all of the above issues!

Establish a Project Council

Launch a project steering group called the Council. The Council sits between the token holders and the project executives. The job of the Council is to set project strategy, appoint and oversee the top-level executives, define the project organizational structure, propose and prepare SIPs (Note: anyone can post SIPs! The Council just ensures that at least somebody does), set high-level project budgets and review spending reports. The Council consists of a Chairman and Council Members. The Council appoints the project’s CEO, and the CEO reports to the Council.

The idea is that in the slightly longer term the token holders would elect the Council and have the power to modify it. However, there are still open questions related to that: Is the Council membership for a fixed term? Can token holders dismantle or modify the Council at any time? Is the project CEO position for a fixed term?

I believe we need to start working in this new structure immediately and get some mileage and experiences from it before formally making it a part of the project governance. So it will be a Step 1 + Step 2 approach, where the Step 1 is that the current project leadership ‘internally’ adopt this structure, and after a number of months, the Step 2 formalizes the first Council via a SIP and specifies (at least some) mechanisms for token holders to modify the Council.

Here’s the Council composition we’re trying first: I will take the role of Chairman, with the rest of the Council consisting of Nikke Nylund, Matthew Fontana, Mark Little, and Eric Andrews. The Council will initially meet on a weekly basis.

New organization structure and new leadership roles

There are also planned changes to how power and responsibility is divided within the day-to-day project contributors. There will be a Tech team and a Business team. The Tech team will have two kinds of main activities: core product development (ie. the SDK, Hub, etc.) as well Labs activities (proof-of-concepts, demos, etc., fully focused on enabling adoption and meaningful partnerships). The Business team will be responsible for Marketing & Comms, and on the other hand Partnerships/Outreach activities across Web3 and Web2.

A number of new roles will be introduced in addition to the above mentioned Council Chairman. The roles will be appointed in a way that maximally serves the new focus of the project: adoption, adoption, adoption.

• The project’s CEO will be the top executive in the project and report to the Council. Matthew Fontana, previously Head of Ecosystem, will take the role of the project’s CEO. (More about my new role further below).
  
• The CTO (Chief Technology Officer) role will be introduced, and they will lead the Tech team. Eric Andrews, previously Lead Developer, will be appointed as the CTO.
  
• The CCO (Chief Commercial Officer) role will be introduced, and they will lead the Business Development and Marketing teams. Mark Little, previously CMO, will be appointed as the CCO.

Building on the previous picture, here’s the project org chart where the project team has been expanded and the faces of the respective leaders added:

The “Labs dev” is an interdisciplinary activity that focuses on technical development of pilots, proof-of-concepts, and so forth related to prospective partnerships. The share of this type of dev work can be expected to grow in relation to the core product work, as adoption is growing while the core product is getting more and more mature and stable.

For those concerned: I’m not going anywhere!

I understand if someone is concerned that I’m going away. Well, I’m not. In fact, I will continue to be around, work on the project, and show up at the office every day (Matthew sits at the same physical office btw!). My goal is that my day-to-day will change from being in a constant busy-loop into something that allows more creativity, and that I’ll be less of a bottleneck – both of which I believe adds more value to the project than just keeping the status quo.

I will assume the role of the Council Chairman, and my goal and inspiration is to become a kind of “Vitalik of Streamr”. This enables me to make more valuable contributions to the project than just keeping things running. Leading, not managing. Innovating, not executing. Helping, not hindering. When going on stage or otherwise representing the project, I will use the title Co-Founder.

Overall, another crucial win here is that no matter what happens to me or any other individual, the project will be able to keep going. I want the power and responsibility to be sufficiently distributed for the project to survive even in catastrophic scenarios: Even if the whole current team gets somehow incapacitated, the token holders can elect a new Council, the new Council can then appoint new executives, and keep rolling!

Join the AMA

Thanks for reading through! We will organize a “Meet the Council + AMA” session on August 14th 2024, where the whole Council will be available to chat more about this change as well as other exciting topics for the project. Please add your questions ahead of the AMA in the #governance channel on the Streamr Discord.

Best,
Henri