My first online purchase ever happened on September 5, 1999. I was in college at the University of Stellenbosch in South Africa, I really wanted to read Lord of the Rings, and after doing the math I realized that buying the book from this online bookseller in America called Amazon.com would be cheaper than buying it from a local bookstore—even when I took international shipping costs into account.

The book arrived a few weeks later, just in time for the summer holidays to start. I did very little that December that wasn’t reading Lord of the Rings. In fact, I distinctly remember missing the turn of the millennium because at 12:00am on January 1, 2000 I was deeply engrossed in the Entmoot proceedings to figure out whether or not the Ents should go to war against Saruman.

The book ended up traveling with me all over the world. To Australia where I lived for a few years, back to South Africa, all the way to the US, then back to South Africa again, and now here, in Portland, OR. It has served me well:

Robin Sloan has a new edition of his newsletter out. It’s called Crossing the Sunshine Skyway and it is wonderful, as always. Towards the end he links to Adam Roberts’s reflections on re-reading Lord of the Rings. It is long and it looks great so I saved it to read over the weekend. But then Robin says this:

I’ve just completed a reread of LOTR myself: a beautiful one-volume edition with Tolkien’s own (slightly wonky) illustrations included, plus some lovely rubrication.

He posted a photo of the edition he purchased and I was immediately smitten. It looked beautiful, and the idea of seeing some of Tolkien’s own illustrations as part of the story? Heck yeah! I decided that it was time. 24 years after purchasing my first copy of Lord of the Rings—and after many years of resisting lots of wonderful editions because I didn’t want to “cheat” on my original—I purchased The Lord of the Rings Illustrated By The Author. Robin only posted one photo in his newsletter, which made for a bit of a surprise when I received the book. It is so much more beautiful than I had imagined.

I am excited to embark on my own re-read of Lord of the Rings this year, something I’ve been planning to do anyway. And I don’t feel so bad about cheating on my 24-year old copy any more. I mostly feel grateful for the internet and blogs and newsletters and how they can help us find our people and make meaningful connections that sometimes end with a beautiful piece of art in our hands that we wouldn’t have known about otherwise. Maybe, at least sometimes, we can have nice things.

There’s a sentiment I started to see in the agile development world that advocates for deleting old/stale items off a backlog completely. A good recent example is Jason Knight’s latest newsletter:

The backlog becomes a dumping ground for every single customer support query. Every account manager and every salesperson has something in there from conversations with customers and prospects. […]

It’s tempting to see “length of time in backlog” as some kind of vector for prioritisation, but it really isn’t. It’s quite the inverse, in fact. So let’s all try to get comfortable, embrace the idea of getting rid of old stuff in our backlogs, and give people a “no” rather than a “one day”.

I’m not trying to pick on Jason—his work is great and it’s another very good edition of his newsletter! I am just using it as an example that got me thinking about this a bit more deeply.

My take is that we should absolutely keep all customer feedback around in our backlogs, because that is continuous discovery data that would be a shame to lose. Instead, my proposal would be to normalize the backlog as a place to build organizational memory and a customer feedback knowledge base—not as a list of things that all have to get done.

Two tactics can help with this approach. First, a Now/Next/Later roadmap keeps the focus on the list of current priorities. The entire backlog doesn’t go into the “Later” column—only things that are currently prioritized to start within the next few months.

Second, have a standard process that the entire company (especially the customer success team) can use to collect user feedback and attach it to features. In our case that’s Productboard, and our success team can easily add and process customer feedback via a browser extension.

I guess our list of features in Productboard is technically our “backlog”, but it doesn’t cause us stress in terms of feeling like we need to work on everything that’s on there. However, as part of our planning cycle we can go through this list and figure out if anything is important enough to pull into the “Later” column of our roadmap. An added bonus: if/when we start to work on any of those features we have access to lots of customer data about each feature, and we can reach out to those customers to have more in-depth conversations with them about their needs.

So instead of deleting old issues off our backlogs, let’s rather remove the pressure and stigma around what backlogs are for (maybe we should rename it to “customer needs knowledge base”?). And then let’s use our actual roadmaps for the list of things we know we’re going to work on.

There’s so much goodness in Mandy Brown’s latest management post Made It, but it’s this paragraph that gets to the heart of it:

This is one of the ways that the adage about “maker time” versus “manager time” does harm. Setting aside the fact that it’s not even coherent—managers make decisions and plans and systems and visions all day long!—it also serves this notion that the stuff is what matters and the humans are just an unruly mess that gets in the way of the stuff. This is a self-defeating story, inasmuch as you don’t get good stuff without a system that takes care of the humans.

I have been thinking about human systems a great deal over the past few weeks. It started when I read Donella Meadows’s Dancing With Systems. When I applied that lens to my own work it was impossible not to see it in absolutely everything we do. Take this quote, for instance:

Don’t maximize parts of systems or subsystems while ignoring the whole. As Kenneth Boulding once said, Don’t go to great trouble to optimize something that never should be done at all. Aim to enhance total systems properties, such as creativity, stability, diversity, resilience, and sustainability–whether they are easily measured or not.

There are so many implications of this principle for the way we make software today. Here are a couple I’ve been thinking about in particular.

Quality

When we have quality issues in our product it’s tempting to try to solve those issues with process and overhead. Common ways to do that include instituting additional approval gates before code can be deployed to production environments, or adding “QA periods” where the entire organization is asked to test a feature before it goes live.

These solutions optimize for parts of the system—such as deployments or manual testing—while ignoring the system that is responsible for introducing quality issues into the product in the first place. To quote Deming:

Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “You can not inspect quality into a product.”

We have to look at the system as a whole. What kind of automated test coverage do we have? What bottlenecks exist in our CI/CD pipelines? What level of responsibility do we ask of engineers to be stewards of their own code? Do teams have enough time to make sure that quality is built in from the start and not an afterthought? These are the total systems properties questions that have to be addressed in order to fix quality issues.

Team stability

One of the bigger leadership mistakes we make is to think that the humans that make up a social system are interchangeable and can be moved around at will without impacting the system as a whole. You see this especially in engineering teams where “resources” are constantly moved from one project to another—usually to speed something up that is perceived to be behind schedule. But we forget that it is the human system that produces the stuff, not the individuals.

Similar to the discussion about quality, if we perceive a project to be off track we need to understand how the project came to be off track, and then find ways to improve the system to correct that. Did we place unrealistic deadlines on the team without getting their input? Are we asking teams to build features that have not been validated with customers? Do teams have adequate autonomy and ownership over the way they prioritize their work? Do teams have the business context they need to make the best possible decisions?

If we instead go for the shortcut of moving people around, we will never get to the heart of the matter. Inserting additional humans into a system can inadvertently break it—and worse, moving folks from one project to another leaves a gap that is very likely to destabilize the project that they were working on before. Suddenly Customer Success doesn’t have an Engineer to talk to about documentation, or the Marketing Team doesn’t have anyone to fix an issue with a piece of demo software.

Once again, Donella Meadows says this well:

Before you disturb the system in any way, watch how it behaves. If it’s a piece of music or a whitewater rapid or a fluctuation in a commodity price, study its beat. If it’s a social system, watch it work. Learn its history. Ask people who’ve been around a long time to tell you what has happened.

Stable teams that work together for an extended period of time all have a steady beat, and we shouldn’t make changes to the system until we know exactly how that beat works. Here’s Donella again: “Before you charge in to make things better, pay attention to the value of what’s already there.”

And that’s how all this connects to Mandy’s piece that I linked to at the beginning. If we want the stuff to be good, we have to pay attention to the beat of the system of humans that make up an organization. We have to understand how they work, and we have to ask them how they want to work. We have to listen to the people who are beating the drums.

It may sound a little counter-intuitive, but if we optimize for the humans who make up a system, the good stuff will follow.

→ Discuss this post on Mastodon

I love when people get obsessed with a topic and then turn that obsession into an “iterative project” where they do the same thing over and over until the topic has nothing left to give. An example: my friend Dave watches sci-fi movies hundreds of times and obsesses about the typography for his blog Typeset in the Future. I think his post on Alien is my favorite:

The opening credits for Alien are nothing short of a typographic masterpiece. You can watch them in their entirety on the Art Of The Title web site, but here’s the general gist: a slow, progressive disclosure of a disjointed, customized Futura reveals the movie’s central theme over 90 seconds of beautifully-spaced angular lettering.

Dave’s book is also amazing and you should buy it.

Clive Thompson wrote about this topic recently in his essay The Power of Indulging Your Weird, Offbeat Obsessions. His point about the value of following your obsessions is this:

It’s enormously valuable to simply follow your curiosity—and follow it for a really long time, even if it doesn’t seem to be leading anywhere in particular. Surprisingly big breakthrough ideas come when you bridge two seemingly unconnected areas.

A few other recent examples got me thinking about this again. Ander Monson watched Predator 146 times and wrote a book about it. From an interview with him:

In following every rabbit hole of his obsession with the film through to its end, Monson creates a book that is truly one-of-a-kind—not just a dose of nostalgia for movie buffs, but a revelatory investigation for anyone who’s ever really loved a singular piece of culture, enough that it got tangled inextricably in their identity and could never quite be excised. In Monson’s own words: “I believe that if you look long and hard enough at what you loved best at fourteen and how you lived then and what you saw in the world, it will reveal both the world and you.” As the pages turn, a question inevitably arises: What have you loved in the way that Monson loves Predator? And, for better or worse, how has it made you who you are?

A few weeks ago Monson published an essay about a similar project: Sean T. Collins’s “Pain Don’t Hurt”, an out-of-print book of 365 essays about the movie Road House (you can read every essay on his website). Monson starts off by calling this a “bad idea essay”, and if anyone is qualified to say that, it’s the guy who watched Predator 146 times. But he goes on to say this:

The reason I love bad idea essays is not because they seem dumb or bad but that they’re hard. Anyone can write a good idea essay. But only a real pro—or a real fool, and it’s hard to tell which you are when you start one, which is the entirety of the stakes of the bad idea essay—can write a bad idea to its exhaustion/completion. Only after exhausting yourself will you see if it was worth it.

But it’s these paragraphs that really get to the heart of the matter for me:

365 essays about Road House is an idiotic thing, and its idiocy is part of its appeal. I am often moved by iterative projects, because in repeating an action every day or every week or every year you make time a subject. […]

The reason I love iterative projects is that the plot is inevitably the movement of the mind (or the life or the body) through time. Every piece is a technical problem: oh shit, what am I going to do today? And the technical problem just gets harder as it goes deeper: How can I not bore myself on essay 241?

The reason obsessive projects like these—or what Monson calls iterative projects—are so appealing to me is two-fold. One, there is The Sad, Beautiful Fact That We’re All Going To Miss Almost Everything:

Surrender, on the other hand, is the realization that you do not have time for everything that would be worth the time you invested in it if you had the time, and that this fact doesn’t have to threaten your sense that you are well-read. Surrender is the moment when you say, “I bet every single one of those 1,000 books I’m supposed to read before I die is very, very good, but I cannot read them all, and they will have to go on the list of things I didn’t get to.”

Two, if we agree that we’re going to miss almost everything, there is a certain beauty in picking a small number of things you want to know everything about, and then sharing that with those around you. We know from the African philosophy of Ubuntu that “I am because you are”, or:

Humanity is not embedded in my person solely as an individual; my humanity is co-substantively bestowed upon the other and me. Humanity is a quality we owe to each other. We create each other and need to sustain this otherness creation. And if we belong to each other, we participate in our creations: we are because you are, and since you are, definitely I am.

One of the most tangible ways we can “owe humanity to each other” is by crawling deep into the corners of a specific topic and picking out the best pieces of it for the people around us. It’s saying, “I know we’re going to miss almost everything, but on this thing I got you. I’ll go deep so you don’t have to, and I’ll share what I learn so we can both enjoy what makes it special.”

There’s one more thing that really drove this point home for me recently. Substack has an interview up with Nicola Lamb, author of the Kitchen Projects newsletter. Nicola has built a very large following on Substack, and her answer to the question “What have your subscribers taught you?” summarizes this entire post so well. In essence, her audience taught her that we all want to hear about each other’s obsessions:

[My audience taught me] to be unashamedly obsessed with whatever you are into. To not shy away from details and to get deep into whatever it is that you love. Thank you for that.

So maybe this is something for all of us to ponder a bit more. What are you obsessed with that seems so niche that surely no one else would care? I’ll say this: if someone can write a fascinating book about watching Predator, I guarantee that your “bad idea essay” is probably actually a really good idea for an iterative project. I, for one, would love to read it.