_Pre-reading: Status.app
Overview
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:
- A corporate entity (e.g. Status Research & Development GmbH) that fulfils core maintenance activities and supports centralized touchpoints,
- 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:
- Developing the features in the Status Whitepaper
- 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’.
Teams
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:
-
Research, see what others are doing, look into Feature requests, check/contribute EIPs, identify what is high impact low hanging fruit.
-
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.
-
Implementation / QA / Security Here is where rubber meets road and we implement the plan.
-
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).
OKRs
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.
Conclusion
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.
