💬 Unblocked – Get the right answer, now
As per Stack Overflow’s developer survey, 60% developers spend between 30 and 120 minutes every workday searching for answers, often about their own workspace and code.
This is an area where AI can be truly disruptive, which is why I am happy to promote the fantastic work done by the guys at Unblocked 👇
Unblocked provides the accurate answers developers need to get the job done.
It tailors answers by complementing your source code with relevant discussions from GitHub, Slack, Notion, JIRA and more. So you spend less time digging for answers and more time writing great code.
Unblocked is free forever for teams who join during the beta! Learn more below.
Back to this week’s ideas!
1) 🎨 Cynefin
The Cynefin Framework is a decision-making tool created by Dave Snowden during his work at IBM in the late 1990s. The term "Cynefin" is a Welsh word meaning “habitat”, and categorizes problems into five domains:
1) 🟢 Clear
In this domain, cause-and-effect relationships are clear and predictable. The appropriate approach is to sense the situation, categorize it, and respond based on established best practices.
Example: fixing a known bug, or adding a simple feature.
2) 🟡 Complicated
Here there may be multiple correct answers, and while there is a clear relationship between cause and effect, it may not be apparent to everyone. Expert analysis or the use of analytical methods is often required.
Example: designing a system with a set of advanced features that require thorough planning.
3) 🔴 Complex
In this domain, cause-and-effect relationships are only clear in retrospect. The right approach is to 1) probe (experiment), 2) sense (learn from the experiment), and then 3) respond.
This is often the case for innovation and zero-to-one scenarios. For instance, creating a new product needs constant experimentation and feedback from users, which makes it a classic complex domain.
4) 🟣 Chaotic
In chaotic situations, cause-and-effect relationships are unclear and the situation itself is highly unpredictable.
The appropriate approach is to establish order first, then sense where stability is present, and respond to turn the chaotic into the complex.
An example could be responding to a major system outage or security breach.
5) 🔵 Confused
This is the domain of the unknown, where it is unclear which of the other four domains applies.
The appropriate approach is to break down the situation into constituent parts and assign each to one of the other four domains.
The Cynefin framework is useful because it gives you a blueprint of how to respond to situations, and also an ideal path to turn chaos into order.
I published a compilation of my favorite mental models for engineers and managers in this recent edition 👇
2) 🎽 Team-first
A few months back we read Trillion Dollar Coach in the community Book Club.
It is the story of legendary coach Bill Campbell, who during his life advised the likes of Steve Jobs, Larry Page, Jeff Bezos, and many others.
A common thread that runs through all the advice that Bill has given, is how he approaches problems with a team-first attitude.
The book is full of timeless ideas on this — here are my favorite ones:
Smarts & Hearts ⚖️
Don’t hire people who spell team with an “I”.
The principle is that people skills matter as much as technical skills. When hiring, Bill looked for smart people who 1) worked hard, 2) had high integrity, and 3) who were good at empathy and communication.
He wasn’t overly concerned with experience or tech chops — he hired people for potential.
Encourage diversity 🧑🎤
Just like you can’t have a team full of quarterbacks, Bill believed a diverse team achieves greater results.
Diversity applies to everything: background, walks of life, sexes, ethnicities, and more. Diverse teams deflect the risk of groupthink. To create truly world-class solutions, you can’t have an engineer-only team, or a man-only team, or an under-30 only team, and so on.
King Arthur’s round table ⚔️
Also known as: don't decide by consensus.
When facing a decision, all perspectives should be heard and considered. The team should have an open debate about which idea is best, and possibly converge autonomously.
But if the team can't make up their mind, then the manager has to step up, make the decision, and end the debate — because no decision is often worse than a bad decision.
Bill called this the “King Arthur Round Table” decision-making model. Most of the time, the knights can figure it out. When they can't, the king has to make a ruling.
You can find the summary & review of the full book here:
3) 👾 Web3 tech is about dependability
One recurring criticism you hear about web3 is that there isn’t really anything from a technical standpoint that you cannot do with regular tech.
This is... right!
You can build pretty much anything with APIs, regular databases and web services. Also, when you consider health metrics for apps and databases, like latency, cost, or throughput, blockchain vastly lags behind regular tech, often by orders of magnitude.
While improvements are to be expected, we shouldn’t expect raw performance to surpass or become even on par with centralized tech.
However, while you can technically build anything with a “web2” stack, some use cases are just improbable business-wise.
In other words, with web3, while the technical design space stays the same, it’s the business design space that changes.
But why?
Years ago, a VC passed on my startup because they said we were too reliant on some external API. It was considered a liability because that functionality was core to our business. They were right. We eventually replaced it with in-house tech that took 6+ months to be built.
If we could have trusted that service to stay public and immutable, the trajectory of our product would have changed dramatically.
The design space of our product had been ultimately limited not by what could be done technically, but by what made sense for the business — because of the undependable nature of web2 technology.
What if we could all take data from the same, immutable database, and combine public apps that we can always trust to stay there? What could we build? And how fast?
I explored many tech and business ideas around web3 in this past two-part series 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca
thanks for the book recommendation! I'll put it on my list :)
Nice article! I totally agree on point 3. In the past, there were many use cases that did not fit Web3, but there are still many that do.