Many people, each much smarter than us, have written in depth about the types of challenges Nemo is built for. Here are some of our favorites. Email us at with any recommendations - we’re always looking for more!

Software and its Discontents, Part 2: An Explosion of Complexity
Talking primarily to engineering leaders, but also CEOs, VCs, ICs, and other practitioners, the most common response to the question of “has something substantially changed?” is that software, counter intuitively, has gotten harder to build. This is counter intuitive because the tools are orders ...
Systems design explains the world: volume 1
What is systems design? It's the thing that will eventually kill your project if you do it wrong, but probably not right away. It's macroeconomics instead of microeconomics. It's fixing which promotion ladders your company even has, rather than trying to climb the ladders. It's knowing when a di...
Adobe covered its Figma short position
Software tools are organizational tools: the way a company "thinks" is mediated by the software it uses. Companies that make decisions via powerpoint tend to have a linear style that references one idea at a time; a memo-based culture is more about loading a comprehensive concept into RAM and the...
Decision Errors, Organizational Iatrogenesis and Errors of the 7th Kind
Making strategic decisions about what actions could be taken, and whether or not to act at all, is fundamental to both managing and leading. When managers focus upon event attributes and event structures related to issues and problems, they face (at least) four stages of analysis and decision mak...
Notes from “Good Strategy / Bad Strategy”
A set of coherent actions dictate how the guiding policy will be carried out. The actions should be coherent, meaning the use of resources, policies, and maneuvers that are undertaken should be coordinated and support each other (not fight each other, or be independent from one another).
"Drawing your three maps" exercise
The instructions we followed were: Using one color, create your locator map, describing the key teams (e.g. Data Engineering, Quality Assurance, Customer Success, etc) and platforms (e.g. Content API, CI/CD, user authentication, analytics, etc) that you work with Using a second color, add topogra...
Prioritization is a Political Problem as Much as an Analytical Problem
Regardless of how we rank alternatives or sequence work or match roadmap items to corporate initiatives, no matter what analytical method we apply, we [product managers] get similar reactions from the go-to-market side of the house: "I only see 1 of my 5 critical items" and "we have to do more" a...
Notational intelligence
Inventing better notation is a cheap, universally useful way to increase our effective intelligence in many domains. Better notations let us work more easily with more complex abstractions, and enable us to solve new complex problems. When faced with a new seemingly intractable problem, it’s wort...
Everyone Is Still Terrible At Creating Software At Scale
How is it that we’ve found ways to organize the work around so many other creative disciplines but writing software is still hard?
Breaking the Wicked Loop
It is very difficult to pin down one “root cause” when you’re stuck in one of these loops. There is a ton at play. In fact, efforts to course correct — like create a new plan — can feel good in the moment, but backfire.
Vitalik Buterin on 2020
So we have a world where: One-to-one interactions are less important, one-to-many and many-to-many interactions are more important. The environment is much more chaotic, and difficult to model with clean and simple equations. Many-to-many interactions particularly follow strange rules that we sti...
Software engineering in-the-large: the coordination challenge
But the problem is that there’s too much context! You can’t just firehose all of the available information to everyone, that doesn’t scale: everyone will spend all of their time reading docs. How do you get the information into the heads of the people that need it? becomes the grand challenge in ...
Problem: Rise of metawork
The real work feels at risk of being overwhelmed by metawork — the friction surrounding our tools and created by the combination of them and our organizations.
As a CEO, I don’t have a stack.
Besides the usual communication tools, like Zoom, WhatsApp, Slack and Drift Video, the only tools I have as a CEO are learning tools.
The Origins of Opera and the Future of Programming
In order to change our system, we need a mental model of it. Each developer has a mental model of the software we work on. Each developer’s mental model is necessarily incomplete and out of date. And, they’re each different from everyone else’s.
Product/feature roadmaps are more like dependency graphs than sequential lists - the Civ technology tree comes to mind
Product/feature roadmaps are more like dependency graphs than sequential lists - the Civ technology tree comes to mind. This distinction is more pronounced when teams are organized according to microservices. What's the best tool for reasoning about this?
The Tree of Up
It's a great way to understand how features are connected to each other and see which features are the necessary foundations for other functionality to be built on.
A “map” of the teams that you depend on.
Working in a large tech company, one thing I wish every team had (but barely any have it): A “map” of the teams that you depend on, that depend on you, and ones that are coupled to your work in one way or the other.
Companies and Entropy
One of the biggest scaling bottlenecks ends up being the related problems of asymmetric information and decision fatigue.
I’m very curious if/how new tools/approaches will make it easier to connect and orchestrate systems of systems.
It seems like today the “best engineers” are no longer building new product features OR building new systems; they’re compelled to spend time integrating existing systems. This is necessary, but doesn’t feel high leverage.
Creating a graph of insights
(4) the linearity of most writing tools only really makes sense from a presentational point of view; but when writing, you're basically creating a graph of insights. Being able to reshape your document and figure out the flow != skeuomorphic typewriter experience
Remote work means we are missing the insidious threat of quiet errors & projects that aren’t worth the trouble.
Remote work means we are missing the insidious threat of quiet errors & projects that aren’t worth the trouble. The errors will blow up in your face at some point. And the projects are hurting your performance.
Meetings *are* the work
Our industry suffers from a deep association of work with structured productive toil, a framing that’s in every way a bad fit for knowledge work. Knowledge work is uncertain and messy (and sometimes enjoyable too). The messiness can be avoided, but only at the cost of sacrificing the power and di...
Navigating the unpredictability of everything
Map future possibilities, to mitigate possible things and to better notice when your assumptions turn out to be incorrect.
Product: ???
Design: Figma Tasks: Linear Product: ??? Specifically, team problem solving.
One of the most difficult challenges that many teams face is the handover of work between product, design, and engineering.
One of the most difficult challenges that many teams face is the handover of work between product, design, and engineering. It's riddled with misalignments, hidden assumptions, interpretations, and definitions. If you want to help your teams improve, start there.