Status 'GmbH' 2.0



Status has always been about adhering to the guiding principles of Ethereum; decentralization and permissionless participation. This extends beyond the software we create, and to the way in which we organize ourselves.

This year we’ve experimented with many different ways of doing just that, and have found ourselves in a type of ‘hybrid organization’ which uses both decentralized and centralized components to operate.

Building an ecosystem, and networked organization, has always been a long term goal of Status, and requires providing an environment for independent teams to self-organize and work towards a broader vision. Ultimately such an ecosystem will be more competitive, resistant to coercion, and decentralized.

One proposal put forth in Prague is to create a clearer distinction between the way in which we operate within Status the company, and how we interface with with the rest of the world as a DAO.This will allow us to both efficiently deliver the features we’ve promised the community, and at the same time create a structure under which anyone in the world can contribute. These could be summarized as:

  1. A corporate entity (e.g. Status Research & Development GmbH) that fulfils core maintenance activities and supports centralized touchpoints,
  2. A broad network of independent organisations providing services to the Status Network and the wider ecosystem.

The mental model of the Status ‘GmbH’ and Status Network can be thought of similar to the Ethereum Foundation (a legal entity responsible for important R&D efforts of Ethereum) and Ethereum itself (a broad network of independent organisations like Golem, OmiseGo, Maker, etc.)

Caption: Basic diagram of how the Status Network can look

Today we are going to be making changes to the Status ‘GmbH’ to improve the focus, quality and efficiency of development. This also includes making some centralized concessions to our org structure in exchange for a more immediate impact. Specifically the mandate is two fold:

  1. Developing the features in the Status Whitepaper
  2. Supporting central functions of Status that can’t as easily be opened up to permissionless participation. These include:
    a. Security
    b. App release process
    c. Official Status Social/comms channels
    d. Official Status website
    e. GitHub merge privileges

For people who prefer to continue working in a more decentralized structure, the Status DAO/Network will provide a mechanism for both independent developers and teams to submit proposals, including members of the Status ‘GmbH’.


We created Teams back in May, and have had positive and negative feedback on them. We’ve found that smaller teams (~< 8) are the ideal size, and sometimes the fewer the better. The co-ordination tax large teams pay often outweighs the incremental benefit of a new person joining the team (see Mythical Man Month). Another benefit of long standing teams has been an increased sense of ownership and responsibility for a particular area (e.g. Keycard, Wallet, etc.).

One of the challenges the teams model had was the lack of freedom to work on new areas. As the Status DAO/Network comes to fruition, individual(s) will have the opportunity to propose and have those new areas funded.

As execution and impact are the focus for the Status ‘GmbH’ going forward, we propose to split into small teams with the following structure:

Team Leads

Project Flatten was a great learning experience. Individuals felt empowered, had ownership towards Status, and were creative on ways to provide their own take to improve things. One area that lacked as a result is individuals taking responsibility for important things, in particular the Core team.

When looking across all of Status, bright spots have shown forth where there is a humble leader accompanying people on the team to achieve great things, and being a conductor rather than a traditional manager.

Therefore, we would like to re-introduce people leads who will be responsible for the impact each team has on Status. This is a change on how we operate today. The team lead will now be held accountable for the milestones and deliverables of each team. The lead will also be responsible for total budget, team size and salary of individuals

With the Product team being so complex, we are still trying to work out the best structure. This is a still a work in progress, with the current breakdown of responsibilities outlined here.

Development Process

The technology stack we are building on is constantly changing and requires a group effort to ensure that we are implementing things in the right way. As we build, we should try and follow these 4 steps (blatently copy/pasted from Jarrad’s post this morning:

  1. Research, see what others are doing, look into Feature requests, check/contribute EIPs, identify what is high impact low hanging fruit.

  2. Specification & Planning Identifying rough timeline based on guesstimated difficult, manpower and user experience impact. Before implementation a consensus of what should be done will be planned and reviewed. We will submit these to myself and the community (EthMagicians) for feedback.

  3. Implementation / QA / Security Here is where rubber meets road and we implement the plan.

  4. Postmortem & Communication Here we document lesson’s learned, this is important so we actually learn and evolve, we pass on our new features to marketing so they can fit it into their content pipelines.

This process will enable us to more deeply integrate into the existing developer community, and prevent us building our own solutions rather than implementing existing EIP’s (e.g. EIP-1337).


To maintain focus and a regular cadence of prioritization, teams can decide to implement OKRs. Each team OKR can then be assigned to an individual, who will then be solely responsible for the execution of that key result. More on the OKR process to come.


We’re hoping that these changes will mean we can stay focused on shipping an amazing tool, and ensure the continuance of the project that we’re all a part of.

Ceri and I have blocked out time for 1:1’s with everyone on the team, so if you have questions about Status’ short or long term future, or have personal questions, please click here to schedule a time that works for you (or ping Ceri for any questions on scheduling). Looking forward to talking to everyone!

Next Step

  • Product Teams should start to self-organise into areas of preference
  • Brainstorm for each product what impacts the user experience the most (top priorities) to be completed by Friday 17th Nov 2018
    • Biggest Bugs / shortcomings of product
    • Most common feature requests
    • Missing features competition has that we don’t
    • What you would like to see in the Product
    • (attempt to order by people power, time/difficulty, and impact)
  • Teams Leads start to take on team responsibilities from now.

We also have started drafting a separate document for the Core team: Next Actions - CodiMD

My personal feature/bug/gap list - CodiMD - Collaborative markdown notes

1 Like

Some thoughts as @Ned and I dive into the branding work.

  • It is still unclear to both of us as to what the actual organizational and brand architecture is. The diagram above is interesting but does not really tell me anything about how we operate (am I the only one who doesn’t really get it?). How do the DAO and GmbH interact? Does the DAO ultimately fund the GmbH?

  • Is Status GmBH now simply Status Mobile and Desktop App (chat, browse, wallet)? Does this fall within the network of the DAO? How does this impact other teams such as Embark and Nimbus?

  • Is a team like Embark now its own entity within the DAO? Or are they funded by the GmbH (this seems counterintuitive based on the diagram above and conversations we have had)? Where does PeopleOps fit in? How does recruiting for individual teams work? Are they funded by GmbH (once again seems odd if GmbH is the Status Product but also recruiting for Embark)?

*What entities will eventually need their own brand?

  • DAO/Network?
  • GmbH?
  • Status Product? (or is this GmbH?)

I have received a ton of different information from various inputs and it is becoming difficult to understand what the actual architecture of the org is. Before Ned and I continue moving forward with “brand” i think we need a brief from @naghdy or @carl so we do not spin our wheels working against incorrect assumptions. What does an org chart look like?

I have to say, it is pretty frustrating that so much thought and time was spent in Prague discussing what the DAO is and how the DAO will function when very few of us will actually fit into that model. It is very interesting and im happy to see it take shape. But I feel like we should have spent more time talking about how the GmbH will function and the architecture of the entire org (not just a mental model with some lines connecting parts of Status that doesnt really make sense). I understand this is abstract and there is no precedence for this type of structure but at the moment it seems as though things have simply not been thought through and that does not instill confidence.

1 Like

@jonathan thanks for posting these questions. I’m sure you’re not the only one thinking. Have done my best to respond inline

The diagram can be a bit confusing. Below is a simpler version that doesn’t show the flow of funding. The GmbH is within the Status Network (aka DAO). The DAO funds the GmbH, along with other organisations within the Status Network.

The best way to think of it is Ethereum and the Ethereum Foundation. From a brand perspective, the Ethereum Foundation is responsible for the ETH logo,, organising DevCon, etc. In the same way, the Status GmbH is responsible for the Status brand and These are the few “centralized” parts of the Status Network that the GmbH is responsible for.

Embark and Nimbus are critically important to the Status Network as a whole, and live within the GmbH for now. However in the medium/long term, you can imagine that they could be spun out into their own standalone companies. There are no plans to do that, but it is possible.

Embark is funded by the GmbH. Almost all parts of Status as we see it today, are funded by the GmbH. The GmbH will request funds from the DAO to pay for Embark, Nimbus, Product, Incubate, and everyone else in the entity

For example, if Incubate spun-off to be its own company (Incubate 2.0), they would no longer have support of the GmbH’s recruiting or people ops team. The liquid funding for Incubate 2.0 would come from Status as well as anyone else interested in funding it. Incubate 2.0 would be run as its own separate company.

@carl can correct me on this, but the way I see it is:

  • DAO/Network would be the umbrella brand. e.g. “Ethereum”.
  • GmbH is the “Ethereum Foundation” part of the brand. Public perception for this is not so important, mainly just from a recruiting perspective. The GmbH is there to provide support for the central parts of the Status Network/DAO
  • Status Product would be the name of the app in the app store. My assumption was that it would be called “Status” as it is today.

I can see how it’s confusing from a branding perspective because Ethereum doesn’t have a consumer facing brand per se, whereas we have the three above.

My suggestion is we jump on the phone to talk about this

1 Like

Thanks for jumping on a call to clarify. Sorry for the rant :slight_smile:

It is a bit challenging and confusing because there are present, near future, and future states to consider. What we discussed and what @Ned and I should move forward on is:

  • Unique Brand for DAO/Network (whatever we call it). This is the network in which EVERYTHING lives within - GmbH, Nimbus, Embark, Incubate, and future proposals alike.
  • Status GmbH - while this is the GmbH serving teams such as Embark, Nimbus for now, it should be branded as the Status Product (mobile, desktop - chat, browse, wallet). For examplem the website should be dedicated to communicating the Status product.
  • Embark - while it currently is being supported by the GmbH, it is its own unique product and should have its own unique identity with its own unique channels
  • Nimbus - same as above
  • Incubate - same as above for now
  • Keycard - same as above

PeopleOps and recruiting will live within the GmbH. So recruiting will be done through Status. However, we propose that each individual team (i.e. embark and nimbus) have their own jobs posted on their website. These jobs can also be posted on the Status Jobs board as well (think of Google and Nest - Nest has their own recruitment pipeline with their own jobs page - but ultimately all those jobs are available on google jobs board as well).

I also propose that the DAO eventually have its own communication channels.

1 Like

+1. Any “job” created with greenhouse can be posted to multiple job-boards, and we can create job boards for every group (that also point to a master job board).

Can anyone suggest a better name for the Core team that can better reflect its mission and bring more clarity?

Core is problematic because a) it is quite broad and doesn’t refer to anything in particular, and b) conflicts with all of our previous “core” naming and conceptions.

Core deals with mobile fundamentals including issues relating to chat or wallet or browser/dapps, and is ultimately “responsible for implementing a decentralized, reliable Ethereum reference client for Mobile on Android and iOS”.

  • Backbone Team
  • Foundation Team
  • Base Team

What’s wrong with the old name - Mobile

mostly because there are more responsibilities to that team than just mobile.

What’s the single common thing for all items within the scope of this team? Ethereum? Low level?

Core seems fine to me IMO. It’s fundamental and at the core of things (light client, basic reliable transport, consumption, security, etc). As opposed to dapps around this core or kernel.

I agree that Core is actually a fair name. It’s confusing right now, but the old “Core” is now “GmbH.”

Another important role of Status GmbH is that it is an inchain authority, the same multisig that can approve send of funds from ICO are allowed to update Status Network Token, and in future place as a safe-guard until the DAO systems don’t require any supervision.
A detachment of Status GmbH and Status Network would be first allowed by Status GmbH that secondly would be accepted from DAO through an democracy action (holders would need to “vote to become owners” in direct democracy weighted on SNT).
I would suggest also to have a “refund” option for any reject voter, which would be able to join or claim its ICO funds. This is an unlikely case because the value of the token unlikely will be less that it could refund - so selling it would be better for individual interests, but I suggest to have this option for two reasons: 1. safeguard; 2. moral.