Three amazing things I have learned working for Flow
I have been part of the Flow team at DapperLabs for three years now and wanted to share three amazing things that I have learnt along the way as part of this fantastic journey so far.
1. Data-driven decision as part of the culture
As Flow is being developed there has always been a lot of emphasis right from the start on always publishing monitoring data from all the different Flow sub-systems. Publishing usable system data has never been an afterthought but rather always part of the first order of business. The Flow node software defines an ever-growing list of metrics reported as a the node goes about its business. There are metrics to capture low-level networking telemetry of a node such as its message queue size, inbound and outbound connection count etc. and high-level protocol-related metrics such as block execution time, hot stuff consensus protocol-related metrics etc. and everything in between. These metrics feed into several different analytics dashboards which are then used to not only monitor the overall network performance but also used as the source of truth for other engineering and product decisions.
But it gets better — this idea of incorporating such a data-driven approach has been imbibed into the organization’s culture which means all teams within DapperLabs have a habit of publishing relevant data and can thus share their “source of truth”. As a result, data then becomes the primary dialect between different teams that rely on each other. At DapperLabs, we have several different teams working on projects that highly depend on each other. For example, the DapperWallet team and the NBATopShot team rely on Flow. These teams automatically get insights into Flow via dashboards they have created to track the Flow metrics that matter to them and have put in place all the relevant alerting around it.
2. Building in open
Flow is a community-driven open-source project. One of the ways it accomplishes the “community-driven” part is by diligently practising the idea of building in the open.
This idea of building in open is a common web 3.0 practice that is rarely seen in the web 2.0 world but will soon become a norm across all product-based companies. This is also something that I find very exciting! It entails democratizing the way important decisions about the product are made and intentionally asking for community feedback and votes on all destiny-defining engineering, product and business-related decisions. In many ways, I think this is the next step for all teams that have embraced the idea of open-source software development.
Different open-source web3 projects have defined their own frameworks to propose changes and gather feedback e.g. EIP for Ethereum. At Flow, this is done by defining a FLIP (Flow Improvement Proposal). There are FLIPs around all important decisions for the protocol, the smart contract language and chain governance. Soon, there will even be a FLIP on how to improve the FLIP process :). In general, a FLIP is warranted whenever the Flow community comes across a major design choice for any aspect of the chain. While this may seem justified for an open-source project like Flow but overkill for anything else, it in fact forces more deliberation on important decisions and generally results in better outcomes while promoting transparency and a sense of ownership for all stakeholders.
3. If you build it, they will come
Building an layer-1 (L1) blockchain ground up is difficult but justifying the decision to build one is even more difficult. However, the founders have always shown firm conviction and an unwavering commitment to the idea of Flow and what it can accomplish and that sense of conviction flows :) throughout the organization. Flow has come a long long way (here is an old news article announcing the initial launch). It now handles more than 1 million daily transactions supporting several successful Dapps on top. In short, if you build it, they will come!
