I have never been able to leave a notebook alone.
Not in the journaling sense. In the literal, physical sense.
If a planner or notebook gets 80% of the way to working for me, the remaining 20% will bother me until I do something about it. I’ll redesign the layouts. Choose different paper stock. Add foldouts where the binding assumed I would not need them. Try different ruling patterns. Rethink how a weekly view should actually work.
Eventually, inevitably, I end up making the whole thing myself: sourcing materials, designing page layouts from scratch, hand-binding the result, and then using it long enough to discover what I would change the next time.
It is a little ridiculous. I am aware of this.
But I have stopped apologizing for it, because at some point I realized the notebook thing is not actually about notebooks.
It is about a specific kind of itch: encountering a system that almost works.
Something that was clearly designed with thought and care. Something that serves most people well enough. Something that is not broken.
It just does not quite fit the way I need it to.
My response is never to throw the whole thing away. It is to get curious.
Where exactly does the friction live? What was this designed to do? What assumptions were made? Where does my reality diverge from those assumptions? What is the smallest, most targeted change that would close the gap?
The thing is, I do this everywhere.
For most of the last decade, my professional work has lived in the spaces between Product, Design, and Engineering. My titles have varied: UX, Design Operations, Product Operations. But the underlying work has been remarkably consistent.
I notice where a system almost works. I try to understand why. Then I look for practical ways to make it work better for the people inside it.
What I have learned is that organizations already have processes.
They have behaviors, history, constraints, and partial solutions that evolved for real reasons, even when those reasons are not documented or immediately obvious. Teams have ways of working that grew out of genuine needs and genuine trade-offs.
The mistake I see most often in operations work is treating that existing landscape as a blank slate. As though good process means walking in, declaring everything broken, and replacing it with a standardized framework.
In my experience, it is almost always the opposite.
Good operational work starts by understanding what is already there.
At a public B2B cybersecurity company, much of my work was in the connective tissue between functions. Product teams, design teams, and engineering teams each had their own ways of planning, executing, and defining what “done” meant.
None of those approaches were wrong.
They had evolved because they solved real problems for the teams using them.
But when those approaches met each other, the seams became visible. A design team might consider a project ready for development at a different point than engineering expected to receive it. Planning might happen across different cadences, which meant that a simple question like “what is currently in flight?” could produce several different answers depending on who you asked. Ownership of certain decisions throughout a project’s lifecycle was sometimes unclear, not because people were avoiding responsibility, but because the question had never been formally asked.
The work was not about choosing a winner or forcing every team into one identical way of working.
It was about understanding how teams already operated, finding the specific points where those differences created friction, and adding structure where it helped.
That meant formalizing lifecycle phases so teams could talk about where a project was using language they all understood. Creating visibility into planning and execution so Product, Design, and Engineering leaders could see the same picture without abandoning the tools and rhythms that already worked for them. Clarifying ownership at key decision points, not to add bureaucracy, but to remove ambiguity.
Good process is not about making everyone work the same way.
It is about making it easier for different people to work together.
This same instinct shows up in a completely different part of my life: on the ice.
I am an adaptive curler.
The sport of curling, like most sports, was designed around a set of physical assumptions that my body does not meet. The standard delivery position, the conventional equipment, and the mechanics of delivering a stone were not created with me in mind.
But the answer was never to decide I could not participate.
And it was never to ask the sport to become something fundamentally different.
The objectives are the same. The rules are the same. The physics of a forty-pound granite stone traveling across pebbled ice do not change.
What needed to change was the interface: the equipment and mechanics that connect my body to the game.
So I did what I always do.
I studied how delivery works and what it is actually trying to accomplish: weight, line, rotation, release. I mapped my own constraints: where range of motion falls short, where strength or balance creates a limitation, where a standard piece of equipment assumes a grip or stance that is simply not available to me.
Then I started building.
I have designed and modified adaptive delivery devices. I have experimented with different release mechanics, different configurations, and different ways of stabilizing my position on the ice.
Some experiments failed.
Some taught me something I did not expect about what the real constraint actually was.
All of them started with the same question:
Where exactly does the standard interface break down, and what would a better one look like?
It is, genuinely, a design process.
Discovery. Constraints. Prototyping. Testing. Iteration.
The fact that it happens on a curling rink instead of inside a product organization does not change what it is. I am understanding a system, understanding a person, finding the gap between them, and adapting the system so the person can do what they came to do.
I have been thinking about why this pattern keeps appearing across contexts that look nothing alike on the surface.
I think it comes down to a belief about where the problem lives.
When a person and a system do not fit each other, there are two obvious framings.
You can decide the person is the problem. They should adapt. Try harder. Work around it.
Or you can decide the system is the problem. Scrap it. Start over. Build something entirely new.
But I keep finding that neither framing is quite right.
The system usually is not broken.
The person is not wrong.
There is a specific place where the two do not meet, and that place is where the interesting work lives.
A notebook that assumes my weeks look like everyone else’s.
A sport that assumes my body works like everyone else’s.
An organization that assumes every team plans and executes the same way.
The shape of the problem is the same in each case, and so is the response: do not force the person to accommodate the system. Do not throw the system away. Understand both, find the gap, and build something at that seam.
My job titles have changed over the years, and the contexts keep changing. But I keep finding myself drawn to the same kind of work: the place where something almost works, and a careful, well-understood change could make it work better for the people using it.
I am not sure there is a perfect name for this kind of work.
I just know it when I see it.
And I do not think the instinct is going anywhere.