Achieving Optimal [Web3] Productivity
In a previous blog post, I briefly talked about how ‘the most efficient and effective means of generating more [Web3] Legos is to onboard new developers into the ecosystem’.
The argument was, you as an individual have an upper bound to the amount of work you can do. If optimizing for overall ecosystem productivity, your role should be to onboard new ‘buidlers’ into the ecosystem — since the upper limit to the amount of work your actions can result in is nearly boundless if your work is the work of getting others to do work (i.e. if you onboard even a conservative 5 new developers to the ecosystem, they’ll output an average of 200–400 hours/week, as opposed to your individual upper bound of most-likely 60–80 hours/week)).
In this blog post, I would like to explore the topic of “optimal productivity” a bit further. This topic is especially important in the realm of Web3, wherein we are constantly treading new ground and exploring new frontiers, and you may oftentimes find yourself off the beaten path without a road to guide you. I hope this post, and the functions included within, can act as a bit of a compass in guiding you in a productive direction!
A few of the high-level topics to be covered include:
- Methods for ‘onboarding’ new developers
- The concept of diminishing returns
- The ‘directional coefficient’ & the need for product/operational directionality
Methods for Growing the Ecosystem
When we talk about ‘onboarding’ new developers, what does this mean? What does ‘onboarding new developers’ look like in practice?
Does it involve giving speeches?
Writing blog posts?
Convincing enterprises to adopt specific technologies?
Building interesting technologies ourselves so others follow suit?
Funding interesting projects?
Building communities?
Drafting educational material?
The truth is, it’s a combination of all of these activities and more. ‘Onboarding’ is more of a mindset that should be taken when approaching each of these activities, or each of the activities you already partake in, as opposed to an individual activity itself.
To be most effective at ‘onboarding’, you should do whatever you are best at while maintaining an open, welcoming, cooperative, transparent approach to that work.
- If you’re having a conversation, make sure you welcomingly answer questions, however simple.
- If you’re writing code, make sure you have good, easy-to-follow documentation.
- If you’ve got a bunch of money, make sure you’re making funding available to those who might not be currently involved in this type of work but want to be.
Because of this, the simplest function for the optimization of individual productivity might take on a form that might looks something like this:
Individual Productivity =
(Hours) x (The activity you’re best suited for) x (Your ‘inviting’ coefficient)
Wherein the ‘inviting coefficient’ is your welcoming attitude towards the activity and the ease of attachment of others to that activity due to that ‘welcoming’ approach (or something like that — I’m no wordsmith. You get the point though! (I hope)).
The Concept of Diminishing Returns
There is another important variable to consider when calculating your individual productivity — that is, the concept of diminishing returns.
Drafting educational content about a topic is not as productive if there is already a plethora of educational content about that topic. It may even be 0% productive unless the quality of your content is much higher than the rest of the content regarding that topic…
Therefore, if we aim to be optimally productive, we must track and measure saturation with respect to activities being performed.
If everyone is coding, and you’ve got some affinity for marketing activities, maybe you’re optimally productive if you start doing marketing activities. If nobody is running product on your team, maybe you can be optimally productive if you step up into that product role. If everyone is already a Web3 developer, maybe it doesn’t make sense to try to directly recruit new Web3 developers.
With this, the expanded function for Individual Productivity may look something like:
Individual Productivity =
(Activity Saturation Coefficient) x ((Hours) x (The activity you’re best suited for) x (Your ‘inviting’ coefficient’))
This creates a bit of a conundrum — if you seek to maximize your ‘inviting’ coefficient, you’ll naturally increase the saturation of the activity (decreasing the Activity Saturation Coefficient, and consequently decreasing your overall Individual Productivity). For example, by onboarding new Web3 developers into the ecosystem, you naturally diminish your individual value as a Web3 developer, as more people fulfill the same role.
I’d like to make two arguments for still continuing to maximize your ‘inviting’ coefficient:
- Opportunity in the Ethereum ecosystem is NOT SCARCE. There is so much work to be done, especially at the infrastructural level, that it is the opposite of a zero-sum game. In fact, due to the open, composable nature of Ethereum, your opportunity may actually INCREASE as new developers enter the ecosystem and build more composable Lego blocks for you to work with.
- You should always seek to optimize for SYSTEM PRODUCTIVITY, not Individual Productivity — it just so happens that the best thing you can do to maximize the productivity of the system is to maximize your own individual productivity. When operating in the Web3 world, you are a part of something that is bigger than yourself. You are part of a movement, a revolution, that has the power to change the world for the better. And as such, you should attempt to maximize the productivity of the system itself. The best way to do this happens to be to maximize your individual productivity, but you should not play the game of solely attempting to maximize the function of ‘individual productivity’ at the expense of all else.
The Directional Coefficient
Up to this point, we’ve excluded one of the most important variables in determining productivity — what I will call the ‘directional coefficient’.
The ‘directional coefficient’ is, in simple terms, how relevant your work is with respect to the mission.
If everyone needs boats, and you’re building cars, maybe you should rethink your priorities :)
This is a drastic example, but in the software development world, we fall into this trap quite often. We continually build things without product-market fit, because we THINK that is what people want / need. A lot of times, this happens when no user research is performed, no feedback is gathered, or engineers are forced into the ‘product’ role. There are a number of different reasons why this might happen, but this pitfall must be avoided at all costs if you’re to remain optimally productive (or productive at all).
For example: if we’re building and selling Web3 products, onboarding new Web3 developers to the ecosystem might be ‘directionally aligned’. Conversely, if there are no Web3 developers, getting into the business of selling Web3 developer tools might not make much sense & might not be directionally aligned with your mission if your mission is to make money.
With the directional coefficient involved, our productivity function now may look something like:
Individual Productivity =
(Directional Coefficient) x ((Activity Saturation Coefficient) x ((Hours) x (The activity you’re best suited for) x (Your ‘inviting’ coefficient’)))
Since the “directional coefficient” is loosely defined as the percentage of work being done that is actually productive, this coefficient would be nearly impossible to calculate — but it can at least be used for demonstrative purposes…
Okay… So what does that mean?! What should I do?!
It’s simple! Spend your time doing the thing you’re best at, that the least amount of people are doing, that is most directionally aligned with the mission of the system you’re operating in — and do it with an attitude and approach that allows others to follow suit.
Also, make sure to recalculate your productivity function on a semi-frequent periodic basis! You don’t want to be pivoting all over the place, but the inputs to each of those variables will constantly change, and so you must constantly evaluate /reevaluate to know where you currently stand, and the direction in which you should be trending.
These are just my initial thoughts on the topic, so I am sure there is more room for exploration! & consequently, if you have any additional thoughts or variables or measures to add to the equation, leave a comment!
Let’s work on building a productivity function together, so we as an ecosystem can become optimally productive :)
