A trend I've noticed amongst the most effective people I know is that many of them are keeping a personal knowledge base (which you could also call a personal wiki, a professional journal, or many other things). This is clearly a trend beyond my immediate network, given the glut of new tools at least partially designed with this purpose in mind (e.g., Notion, Craft, Clover, Roam Research, or Obsidian). I started my personal knowledge base in 2010 (using Evernote) and it has been incredibly valuable to me throughout my career, so it has been great to see this trend take off recently.

People have always taken notes at work — this is not new. What is catching on, though, is the idea of creating, revising/maintaining, and structuring these documents with long-term utility in mind. For most people, the notes they take throughout their careers are intended for temporary use (e.g., to ensure you don't forget decisions made in a meeting). My peers in the personal wiki club are creating long-lived documents on topics, and playbooks for situations, that will come up again in the future. Notably, they put effort into making them easy to rediscover and maintain.

Work is repetitive. Between days, weeks, projects, and jobs, most people will tackle the same, or very similar, problems and tasks multiple times. In the professional services industry, service providers embrace standardisation to improve the ROI of their work. For example, agencies tasked with building e-commerce websites rarely start from scratch — they bolster their process with templates and reusable snippets of code that reduce the need to re-invent the wheel every time they tackle a similar project. Professionals should think about their jobs this way: as an individual providing a service to a client (i.e., your current employer). If you are frequently carrying out similar tasks across different projects, it is common sense to standardise (and potentially automate) this work. By creating and maintaining personal documentation on the various problems you've tackled, you can build a playbook for the next time you have to tackle a similar problem. These playbooks should follow you for your entire career. The secret sauce for your effectiveness and success.

Throughout its lifecycle, a company typically builds value in its revenue, partnerships, employee base and intellectual property, and all of these aspects are reflected in its valuation. Throughout your career, the value of your labour will also increase. This is due to the accrual of value in your experience, your network, and aspects of your professional identity. Experience will give you more knowledge and better intuitions for what to do in various situations, and keeping a personal knowledge base makes your experience much more tangible, explicit, and accessible. This will make you a more valuable employee. You could think of your knowledge base as the intellectual property that you build throughout your career†. People with privileged and well-documented experiences could have a highly valuable knowledge base that makes future success more attainable.

Additionally, while it may be a little too cliche to bother pointing out, writing is a critical part of the learning process. Honing in on a specific opinion on a topic is most easily done through writing, and this process will help you to fully understand what you are learning. One added bonus of this: learnings and ideas that are solidified in text are much more easily shared. If you're trying to understand something complex, I suggest you try by writing an explainer for yourself, and keep it somewhere you can easily access in case you learn more, change your mind, or need to tackle this problem again. Every year, I write a new summary of my approach to product development. This helps me to solidify my ever-evolving learnings and philosophies towards what I do.

† The contents of your knowledge base should be your intellectual property (IP), not the IP of any of your employers. Don't keep data that does not belong to you.

Thanks to artists like Beeple and projects like CryptoPunks, NFTs have been the main character of crypto news in 2021. This has led to an avalanche of NFT sales by artists and celebrities all over the world. Despite the heavy focus on people with clout cashing in on their social capital, I think NFTs will have an even bigger impact on artists emerging today.

NFTs (non-fungible token) at a glance:

• NFTs are entries of data stored on a blockchain.
• The tokens that store data like this are therefore unique and non-fungible.
  • Traditionally, tokens (i.e., coins) on blockchains have been fungible (i.e, interchangeable). So, they work like currency, where there is no meaningful difference between two different notes of the same denomination. There's no value difference between owning two different individual Bitcoins.
  • Because data is stored within a non-fungible token, they are not interchangeable with other tokens — they are unique! There could be a significant value difference between two non-fungible tokens.

One common criticism of NFTs is that, as they are simply data in a public database (albeit a new type of database), they can easily be copied, reproduced, and created without permission. Why would you buy something anyone can copy? People making this criticism are missing the value of NFTs entirely. NFTs are more comparable to a certificate of ownership and authenticity than they are to a physical piece of art. When buying a Rothko, art collectors do not lament how easily they could be reproduced. This is because the value of owning a Rothko is not because it looks like a Rothko, but rather because it is (provably) a Rothko! Through NFTs, blockchains provide a more robust record of ownership than ever before (there is no reason why NFTs couldn't be used to represent ownership for physical art, too). Meanwhile, reproducibility will inevitably only get easier as the world becomes more digital — this makes a reliable record of ownership even more valuable, not less.

A thriving art market, with proof of ownership bestowed by trusted marketplaces, has existed for a very long time. On the surface, the technology behind NFTs may seem like an incremental improvement to this system. In my view, NFTs have already significantly changed the future of the art market, though. They've done this by making the ledger of art ownership available to artists no matter their career stage, rather than just those who can draw the attention of the likes of Sotheby's. This means collectors can invest in artists from all over the world at the start of their careers rather than only after they make it big. This new market of early-career (and therefore cheap) art also opens the collector market to anyone.

The ability to easily and safely find and purchase art from artists who are only just starting their careers is creating a huge opportunity for collectors of all calibres. By investing in an artist at the start of their career, you can achieve much more ambitious long-term capital gains than ever before. Taking a risk on an emerging artist could eventually pay off massively. This essentially creates an angel investing market for art and culture. This angel investing market will strongly favour those with a good eye for what will eventually become very successful, which probably means other artists. This will empower artists to become art collectors, reinvesting the capital they've made from their art, into the next generation of artists. This will look a lot like the world of startup angel investing.

Essentially, the world of art investment will look much less like the ultra-rich investing in already-famous artworks, and more like everyday people and artists re-investing their capital in the next generation of artists. The ultra-rich will continue to acquire their fair share, of course.

Lastly, another feature of blockchains is that they are programmable. This means new rules can be built into blockchain-powered markets. Artists choose where they sell their work, so they can choose a rule set that looks out for them. For example, OpenSea (like many other NFT marketplaces) allows artists to configure royalties when creating their NFTs. NFTs with royalties configured will pay a commission for any future sale to the original artist. This means if you sell your artwork for a small amount today and later become very successful, you'll continue to earn royalties from future sales of your now highly sought after artwork. This, and other future marketplace innovations, will create a more artist-friendly market.

A common anti-pattern in the world of software development is the over-operationalisation of the research and development process. In moving away from traditional ways of working, companies will spin up long-lived teams, working to sprint cycles, but still find a way to cram an inordinate amount of upfront planning into the system, causing a significant amount of waste. This can feel like a big step in the right direction but often comes with very little benefits compared to the old way of working, as the way the team works doesn't change.

Teams should embrace uncertainty and experimentation by implementing a just enough approach to strategy and ideation.

“Just enough” roadmaps

Roadmaps should not be long lists of thoroughly defined features and tasks. As great as it would be to have a bulletproof, long-term plan for your business, this is rarely achievable. Instead, backlogged initiatives should be less thoroughly defined the further they are from implementation. This ensures that:

• Cost to pivot. The cost to pivot is much lower when distant roadmap items are thought of as future opportunities and ideas rather than pre-defined scopes of work scheduled for future completion. New learnings often suggest that you should abandon a large chunk of your planned roadmap in favour of a new set of initiatives.
• Avoid sunk-costs. Time spent detailing future work that may never actually be delivered is unrecoverable. This time could be better spent on other work. Additionally, individuals who've invested big chunks of time in scoping features will be biased towards having those features built. This could lead to inertia in situations where agility (i.e., ability to pivot) is critical.
• Pre-defined scopes are usually bloated. When the planning process is decoupled from the delivery process, one's eyes can be bigger than one's stomach. This usually leads to unnecessarily large scopes of work for the real problem at hand. Outputs are then prioritised over outcomes.
• Manage expectations. Gluttonous, pre-defined scopes of work, have a way of getting around. Internal and external stakeholders get attached to specific implementation details, and any future cutting of scope leads to disappointment. By making future work explicitly tentative and broad, stakeholders can be focused on the problems being solved rather than the bells and whistles.
• Encourage creativity. Upfront planning is usually done in a silo by product managers and designers. Even if they try to be as consultative as possible, the engineers who will eventually execute the scope of work are rarely available to sink their teeth into the scoping process for work that won't be tackled any time soon. By leaving planning until much later, engineers can be much more involved in the process. This will not only lead to better outcomes in the short term, but it will also foster a more innovative environment where engineers are very engaged in the why and how of what they build (as opposed to simply churning out code).

You still need a plan

It's still important to know what's next and to have a North Star for your product. Here are some tips for providing direction without being overly wasteful or prescriptive.

• Start with a simple but ambitious mission. Everything your company tackles should be tied to a one-sentence mission that is easy to remember and understand. For example, Google's mission is to organize the world’s information and make it universally accessible and useful.
• Set a vision for the upcoming period. This could be a goal for the next couple of years or more and should represent a major milestone or step-change for the company. For Google, it might be to become the #1 generalised search engine on the internet. I like to scaffold these goals with specific success measures (e.g., customer count, growth rate, NPS). Again, this should be succinct, easy to remember, and easy to understand.
• Outline your strategy. Enumerate the high-level initiatives that you believe are required in order to achieve the vision. I like to define these as problems to be solved. If the problem isn't well-defined, and relevant to your vision, it probably doesn't belong in your strategy.
• Solution near-term initiatives. While most initiatives should simply represent problems you want to solve in the future, your team may require some guidance to determine how a problem should be tackled. If this is the case, some solutioning should be carried out for initiatives that you expect to tackle soon. A definition of ready for initiatives can help this process.

Using the framework above, the more near term a piece of work is, the more clearly defined it is. The mission is broad, the vision is less so, the strategy has explicit steps (but with open-minded solutions) and upcoming initiative have some high-level solutioning. The goal is to ensure the company has direction, and that when an initiative is picked up it is ready to be ideated and delivered by the team.

I typically leave greater levels of fidelity to the team (e.g., epics, stories, spikes, and tasks), but these should also be defined only when required.

Tactics

The scoping and decision-making process can be greatly simplified if common decisions can be standardised. A high level of standardisation will make planning more rapid and therefore reduce the amount of time required to scope upcoming work. Conversely, standardisation will reduce creativity and out-of-the-box thinking, so it is absolutely possible to go too far.

• Design principles. One way to simplify the decision-making process is to be explicit about what is important to the team. This can be done through designs principles (both UX and technical). Example design principles include API-first, mobile-first and dogfooding.
• Technical patterns and foundations. Teams will likely face the same technical problems multiple times. By building internal foundations (e.g., SDKs, automation, and infrastructure-as-code) upfront, you can reduce future decision making and development effort.
• Design patterns. Teams will also likely face the same user experience challenges multiple times. Building design guidelines and a component library can significantly simplify the user interface design process and enable teams to get straight to execution.

Supplement planning with research and experimentation

A just enough approach to strategy and ideation can feel a bit like shooting from the hip. This is especially true when future initiatives have a significant level of uncertainty around implementation. In scenarios where future initiatives feel especially daunting because the solution is not obvious, research and experimentation should be embraced. Teams can bring forward experiments and research (e.g., technical proof of concepts, customer research, UX prototypes) relevant to future initiatives in order to gain some early confidence in how a problem can be tackled.

The world of work is rapidly migrating from physical space to the internet and this newly dominant medium for work is going to significantly change how we structure society. This may sound dramatic, but it is inevitable that industrial-revolution era systems, legislations and structures will eventually be superseded. I think, in the crypto community, we're already seeing the structures of the future emerge.

The world today looks very different to the world in the 1970s when the first LLCs were established to adapt the corporate world for globalisation. In the crypto community, a new organisational structure has been adopted to cater to the brave new world of distributed collaboration: the DAO (Distributed Autonomous Organisation). Put simply, DAOs are internet-native organisations, orchestrated by code on a blockchain, designed to enable a distributed membership to democratically govern their pooled resources. DAOs can represent commercial endeavours (i.e., companies), non-profit initiatives, social clubs, and more.

Thanks to the glut of acronyms and arcane terms, DAOs can seem a lot more complicated than they really are. Just think of them as a new type of business structure alternative to partnerships, sole traders, companies and LLCs, enabled by some pretty simple technology.

At a glance:

• DAOs are democratic. Membership is granted by the commitment of capital or work. Members can then raise and vote on proposals, like a board of directors.
• DAOs are distributed. As an internet-native organisational structure, DAOs enable (potentially even anonymous) people from around the world to collaborate. I believe this location-agnostic approach is the biggest benefit that will lead to adoption.
• Members pool and invest their resources. A DAO is like a group chat with a bank account. Participants vote to decide how funds (which exist as cryptocurrency) are spent/invested.
• DAOs are regulated by code. All organisations are managed against contracts and regulations, but compliance with these rules is reliant on the good faith of members. DAOs augment their shared bank account with code (smart contracts) that ensures funds are only utilised when the pre-defined voting conditions are met. This enables DAOs to operate in zero-trust circumstances (e.g., collaborations with strangers from all over the world).
• DAO regulations can be patched. DAOs have the capacity to make changes to existing systems by providing a mechanism to replace any part of the system that is not working or is a security risk.

Starting an organisation with someone that involves funding and money requires a lot of trust in the people you're working with. But it’s hard to trust someone you’ve only ever interacted with on the internet. With DAOs you don’t need to trust anyone else in the group, just the DAO’s code, which is 100% transparent and verifiable by anyone.

— Decentralized autonomous organizations (DAOs), Etherium.org.

Contracts are ambiguous, argued by lawyers and discerned by judges. Smart contracts, however, are completely unambiguous — unlike legalese, code is interpreted one way only. This is the innovation that enables truly distributed organisations. If you trust the code that undergirds your organisation, the amount of trust you need in your collaborators is significantly reduced. Obviously, code comes with its own risks: code can have bugs and security flaws and this has caused serious problems for DAOs already.

One common criticism of DAOs by the old guard of business is that truly democratic organisations (particularly ones with a very large voter base) will suffer from the many shortcomings of design by committee. If in the future, you're imagining the average DAO will have a very large pool of distributed members, I think this is actually a pretty reasonable criticism. While broad democracy is a great framework for governing some types of organisations (I imagine this will have phenomenal results in the philanthropic space), I would argue that most great companies succeed as a result of the outsized influence of specific contributors and operators who possess the right skills and experience to solve a specific problem. Absolute organisational democracy would dilute the influence of these people and ultimately put DAOs at a disadvantage against traditional organisations.

This is why I think, in the future, many DAOs will end up having a small, selective membership, resembling a corporations board of directors. And, while many believe DAOs will liberate organisations from the tyranny of centralised leadership (i.e., executives like CEOs), I believe many DAOs will elect to hire CEOs and executive teams. DAOs will also likely lead to more generous and transparent ESOPs for employees.

Is anyone eager to start a DAO and buy some coal mines?

Below is a playbook I've used to describe the responsibilities of a software engineer for hiring and professional development purposes.

Software Engineers are responsible for delivering value to our customers and the business within our product development environment where:

• Outcomes are the focus, rather than outputs.
• Product teams consist of individuals with diverse skills, because no individual covers all bases.
• Ownership between teams and individuals is clear.
• Teams can make time for experimentation to reduce the risk around upcoming work. This helps teams to become more ambitious without jeopardising outcomes.
• Reusable patterns are valued and utilised.
• Teams work backwards from a desired outcome or goal rather than forwards towards a nebulous end state.
• Teams are high-leverage, meaning they've utilised reusable patterns and their body of research to achieve greater outcomes with less effort.

Responsibilities

All Engineers:

• Deliver high-quality software. Business-as-usual for Engineers is the delivery of solutions through high-quality contributions to our codebase. They do this by embracing our established reusable patterns and tooling, test automation, documentation, and collaboration with their peers.
• Explore solutions with your team and stakeholders. It's not enough to simply execute — Engineers need to have ownership over their solutions. This includes participating in refinements, solutioning, and creating initiatives, user stories and tasks.
• Engage in the continuous improvement of your team. Every Engineer belongs to a team, and every team needs to constantly reflect on performance and effectiveness. In order for teams to self-improve, every member needs to be engaged in reflection (e.g., through reviews and retrospectives) and self-improvement.

Senior Engineers:

• Evolve our reusable patterns and tooling. To be high leverage, teams must rally around standardised patterns and tools, to avoid having to re-invent the wheel every time they tackle a common problem.
• Evolve our ways of working. Senior Engineers must champion software development practices that promote outcomes (over outputs) and work with their team to improve the operations of the team.
• Technical architecture/planning. While all Engineers contribute to the technical architecture of our product when developing new features, Senior Engineers (and above) are expected to have a more long-term, cross-initiative opinion on our future architecture. When solutioning an initiative, they must consider other future initiatives and our broader technical direction, to ensure we're working towards our goals.
• Mentor the team. Senior Engineers (and above) should take responsibility for the success of others in their team.

Tech Leads:

• Lead the refinement and solutioning process. Tech Leads are responsible for their teams solutions. This includes leading refinements, solutioning, and creating initiatives, user stories and tasks.
• Manage our upstream dependencies. Our software is built with various upstream dependencies that need to be selected and maintained. Tech Leads should guide this process.
• Manage our reusable patterns and tooling. Tech Leads own the roadmap for pattern and tooling enhancements, which should be tied to our technical vision.
• Manage our ways of working. Tech Leads are responsible for the way of working for their team.

In much of the world, industrialisation has led to the abundance of calories, often in very unhealthy forms — a novel state for a creature that is accustomed to subsistence. This has posed serious challenges for society (e.g., how do we provide large populations of people with healthy food?) and individuals (i.e., how do I eat healthy food in reasonable amounts when millions of years of evolution has instilled a nature of scarcity into me, that drives me to consume all I can find?). Growing up in the 1990s, the golden age of the fad workout plan and diet, the public debate regarding the dangers of junk food was prominent. The parents of many kids in my generation changed their attitudes towards sustenance significantly throughout our childhoods. Abundance, while positive in so many ways, comes with challenges.

Society is experiencing something very similar right now when it comes to information. From the printing press, global literacy booms, the invention of newspapers, cable news, internet publishing and now social media, information has become exponentially more abundant in recent centuries and especially decades. Information abundance, like caloric abundance, is positive in many ways. More truth is out there than ever before. But there is more misinformation, disinformation, click bait and thus doomscrolling. Negativity bias (i.e., the idea that negative information has a bigger sway on your mental health than positive information) is the informational equivalent of the sweet tooth — an irresistible evolutionary glitch in our programming that hijacks our reward centre, turning our adaptations against us.

We no longer live in a world where the most accessible informational calories can possibly form a healthy diet, and in the absence of a significant change to the content creation and distribution pipeline, individuals need to start to take their information diets seriously (noting that junk food is still a significant public health problem that we have not solved). If social media companies are not going to fix their feeds (they may be unfixable), maybe it's time for us to step away from them. Maybe we need to proactively avoid the partisan media divide and content that is clearly designed to outrage us. Maybe we need to view all content (whether from Big Press or Substack) through a more skeptical lens. Perhaps we need to consume a lot less content in general.

Is social media trying to outrage us, or are the algorithms simply feeding us what we subconsciously want to see? Better question: is there any point in personally waiting to find out the cause of this problem? After years of watching and commenting on Big Press' failure to understand and intentional misrepresentation of Big Tech (who I have also extensively criticised), on occasion defending the utility to the wider economy of Facebook's advertising business and the complexity of content moderation, it occurred to me: in spite of my habit of arguing the technicalities of the situation, I've significantly extricated many of these algorithms from my life. Through ad blockers, social media abstinence and the adoption of personally-curated sources of content, I've divorced the algorithms I've occasionally defended. So, while I may disagree with the Big Press view of how and why we got to where we are, and what governments should do next, I absolutely agree that the current state of things is problematic.

In my own journey as a compulsive content consumer, I've learned that I'm happier (and probably better informed) when I opt-out of the exhibitionism of Instagram, trade algorithmic feeds for the chronological feed of my RSS reader, and avoid headline skimming and click-bait-prone publications. Perhaps, as information becomes increasingly abundant, public health campaigns should promote the importance of establishing information diets the way we do with food.