Library

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 ...

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...

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...

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...

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).

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...

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...

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...

How is it that we’ve found ways to organize the work around so many other creative disciplines but writing software is still hard?

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.

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...

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 ...

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.

Besides the usual communication tools, like Zoom, WhatsApp, Slack and Drift Video, the only tools I have as a CEO are learning tools.

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. This distinction is more pronounced when teams are organized according to microservices. What's the best tool for reasoning about this?

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.

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.

One of the biggest scaling bottlenecks ends up being the related problems of asymmetric information and decision fatigue.

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.

(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. The errors will blow up in your face at some point. And the projects are hurting your performance.

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...

Map future possibilities, to mitigate possible things and to better notice when your assumptions turn out to be incorrect.

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. It's riddled with misalignments, hidden assumptions, interpretations, and definitions. If you want to help your teams improve, start there.