TBM 411: Messy Docs As Helpful Pattern
Existing stuff, now more accessible! Check out the POM Starter Pack and OS Discovery playbook, now in non-Gdoc form.
In my day-to-day work (at Dotwork), I hear about all the real-world exceptions, “things that work,” “things that never work” (but we keep trying), and everything in between. I’m a big fan of saying, “Can you show me?” on discovery calls. A slide, agenda, doc, dashboard, screen, etc., combined with the person talking about the “thing”, is worth a million abstract summaries.
I love seeing real examples of how people work every day, especially when they differ from the “official” process.
One interesting pattern I’ve noticed among many (not all) high-performing teams is that they use freeform documents with frequent “migration.” We’re talking very manual:
Ad hoc, random, disconnected status “pills,” flags, and tags everywhere
Links to everything and anything, and those links go everywhere (Miro, dashboards, Jira tickets, other docs, call recordings, etc.). The pool of artifacts is ever-expanding
Complete disregard for theoretical hierarchies. For example, “initiative” is a completely nebulous and shape-shifting idea. Exceptions everywhere. “Oh, that’s just a thing.” “Oh yeah, that really falls into two categories.” “Oh, that’s sort of morphing into this other thing, but for now we’ll…”
Strikethroughs, comments, and information repeated over and over. Comments. Lots of comments
Checklists everywhere. No big push to make everything an official “ticket”, but links to things when it makes sense. Yes, tickets exist, but so do a lot of in-line todos.
Manually copied quantitative data, or links to dashboards or notebooks. Screenshots are OK too.
What is so interesting is how common the practice is. It’s definitely a pattern, though the tools (GDocs, Slack, Confluence, etc.) all vary. The consistent theme is copy-paste migration and reflection as a habit—snapshotting reality, copying it forward, talking about it, and then rinse and repeat. But what is actually going on?
Whenever I see a strong pattern, my brain starts churning.
The fact that a lot of the Claude workflows people are experimenting with sort of mimic this format is especially interesting. I wonder how AI will shift/supercharge this habit?
My mental model for the practice looks like this:
Sure, the work is messy.
First off, the messiness is no surprise. That’s product work.
Whenever companies imagine a “simple” rollup of product work, they are either lying to themselves or very smart about choosing a small number of things to roll up. Or—and this is perhaps most damaging—they are forcing teams to ignore the true essence of the work.
Imagine a manager who immediately shut down this kind of emergent sense-making and forced a team to constrain themselves to tickets for everything. “Everything must be a ticket, OK?”
Well, your most talented/experienced product developers would work around you (a pain, alas). Your least experienced product developers would nod their heads and imagine that you can fit product work exclusively into tickets. That would be a shame, especially if they don’t spend 1:1 time with more experienced people who teach them how things really work.
So in that sense, the pattern is a no-brainer. Form follows function.
Does it scale? Yes and no. Yes, because you can have a whole company doing things at different resolutions, in different pockets, etc. No, because you can’t magically make it “simple”.
(Related post on the “simplicity fetish”…
Getting Things Out Of Your Head
Another piece of this pattern is the power of externalizing working memory.
Product work quickly overwhelms what any individual, or even a small group, can comfortably hold in their heads. There are too many signals: partial insights from customer calls, shifting hypotheses, dependencies with other teams, half-formed ideas about solutions, metrics that may or may not matter, and the ever-present “wait, didn’t we talk about this already?” moments.
So teams that build the habit of maintaining these messy docs push that cognitive load out of their heads and into the environment. That’s what all those messy artifacts are doing. None of this is meant to be a perfectly structured system of record. It’s more like a shared scratchpad for the team’s brain.
Repetition reinforces shared understanding. These teams are getting things out of their heads, and the process of putting them back IN their heads is helpful.
Frequent Integration and Fewer Elephants
Related to the survivorship bias point below, strong teams also seem to have a knack for not letting too many elephants sit in the room for very long. Most of us have seen the opposite play out.
You join a team. Someone proposes a perfectly reasonable working rhythm. Maybe it is a weekly reflection doc, a shared running list, or a lightweight status ritual. Everyone tries it for a couple of weeks. And then the slow decay begins.
The artifacts degrade.
More and more information moves into 1:1 conversations.
Someone starts saying, “Well…we can’t really write that down, can we?”
Three weeks later, the once-helpful document is now a relic. If it is still technically being updated, it is usually a well-meaning project manager dutifully going through the motions. The real status lives somewhere else. The RAG chart becomes a watermelon chart. The “official” update becomes the optics update.
Practices like the messy reflection documents described earlier do not work because they are declared in a meeting. They work when teams close the loop often enough that the habit forms. Sometimes that means a not-so-subtle nudge from a leader to stay on it. Sometimes it is the team’s own desire to keep the loop closed. But more than anything, it requires repetition.
You have to run the cycle enough times that it becomes natural. In other words, the practice cannot just exist as a document. It has to live inside a ritual.
(Related post on frequent integration…
Survivorship Bias
Which brings us to survivorship bias.
Maybe the pattern isn’t that these messy, evolving documents create high-performing teams. It might be that the teams capable of performing well are also the teams capable of sitting with something like this long enough for it to become a habit.
This kind of reflection practice requires patience. It requires people who are willing to pause, copy things forward, revisit assumptions, and talk through what the work actually looks like right now. In many environments, that loop gets shut down quickly. Things move too fast, the pressure for clean artifacts takes over, or the team simply never sticks with the practice long enough for it to become natural.
So it’s possible that what we’re seeing isn’t the cause of strong teams, but a side effect of teams that have created the conditions to sustain that habit.
The Legibility Question
All of this raises a natural question. If the nature of product work is this kind of messy, emergent activity on the front lines, how are leaders/managers in an organization supposed to understand what is actually going on? Leaders still need some degree of legibility. People need to know how work is progressing, where risks are emerging, and where teams are investing their focus. So the moment you acknowledge that real product work looks like the messy sense-making described above, you immediately run into a tension.
Teams need space for local emergence.
Organizations need some way to see and understand what is happening.
That tension raises a deeper question: how should organizations handle this gap between messy reality and organizational legibility?
(Related post on context, legibility, and control…
Three Possible Views
The Trade-Off View
One interpretation is that this is simply a permanent trade-off. Organizations constantly juggle two competing forces: 1) enabling effective work on the front lines, and 2) maintaining enough visibility to coordinate and manage the broader system. There is no clean solution. You are always searching for a moving sweet spot. The work becomes one of continuous adjustment rather than resolution.
Many organizations implicitly accept this framing.
The Fractal Emergence View
Another interpretation is to lean fully into the messy emergence. If teams operate through evolving lists, messy documents, and shared reflection, then perhaps the right move is to replicate that pattern at multiple levels of the organization.
A team has its messy working document.
A group of managers has a messy working document.
A leadership group has its own evolving artifact.
In this view, the pattern becomes fractal. Each layer of the organization mirrors the sense-making behavior happening below it. Legibility emerges through repeated reflection at multiple levels.
The Intentional Interface View
The approach I find most compelling is slightly different. If we treat this as a product problem, the goal is not to eliminate the messy emergence. That is the nature of the work, and it is the nature of the work at multiple levels (see fractal emergence above).
Instead, the goal becomes designing intentional interfaces between that messy reality (or realities) and the broader organization.
What is the smallest number of shared routines?
What are the minimal objects that allow teams to communicate clearly with others?
What shared language helps translate the frontline work without crushing it?
If a team is working effectively in this emergent way, the real question becomes: What simple mechanisms help others understand what they are doing without forcing them to stop doing it that way? That is where thoughtful design matters most.
(Two related posts:
Reflection Questions
Where do you see this pattern already happening in your environment? Think about the real working artifacts people use day to day. Are there messy docs, running notes, Slack threads, or dashboards that act as the team’s shared scratchpad?
What purpose do those artifacts serve that more formal systems do not? What kinds of thinking, sense-making, or coordination happen there that would be difficult to capture in tickets, status reports, or structured tools?
Why might this messy approach work for experienced teams? What habits, trust, or shared understanding allow people to navigate ambiguity without everything needing a rigid structure?
What pressures in your organization push people toward “cleaner” artifacts? Compliance, reporting, leadership expectations, or tooling constraints can all shape how work gets documented.
Where does the tension between messy reality and organizational legibility show up most strongly? When leaders ask for visibility, what information is hardest for teams to translate?
If you think about the “intentional interface” idea, what might that look like in your context? What small set of shared objects, routines, or language could help others understand the work without forcing teams to abandon how they actually operate?
Thank you for that edition!
I really like the approach to facilitate emergence by caring for the interfaces!