Less isn't deprivation. It's clarity.

When you remove what's unnecessary, what remains has room to matter.

Don't use what you can't explain.

In tools, in commitments, in beliefs. If you don't understand it, it owns you.

There's a point where more becomes noise.

The skill is recognizing that point before you've passed it.

The basics aren't boring.

They're what everyone skips and then circles back to. Start there. Stay there longer than feels productive.

Choose things that will still work in ten years.

Relationships, practices, objects, ideas. Trends are a distraction from what lasts.

The default path is paved with other people's decisions.

Going vanilla means choosing on purpose, even when it's slower.

Why be chocolate pistachio praline caramel swirl when you can be vanilla?

These notes are an exploration of that question. Not minimalism as aesthetic, but as philosophy. The idea that vanilla isn't plain or boring or the absence of flavor. It's a flavor itself. One with depth, complexity, and quiet confidence.

Vanilla is the choice to not add more. To trust that enough is enough. To find the extraordinary in the fundamental.

Longer-form thinking. The kind that doesn't fit in a file name or a status update.

These are observations from the middle of things. Written while the work is still happening, not after it's been cleaned up for a case study.

The Job Changed. Nobody Updated the Description.

The Old Shape

The traditional Project Manager role was coordination.

I know because I lived inside it.

Keep the timeline. Manage the handoffs. Track down approvals. Make sure the designer and the developer are talking. Ensure that nothing falls through the cracks.

That was the job. The visible layer. The part that was easy to measure, easy to point to, easy to write into a job description.

Alongside those tasks, other things appeared as line items. "Cross-functional communication." "Stakeholder alignment." "Risk identification." Listed right next to "maintain project timelines" and "facilitate standups." As if they're the same kind of work.

They're not.

The judgment work was assumed to just happen alongside the coordination. It got credit only when it failed.

The Shift

The tools I used two years ago look different than the tools I use now.

That's not the interesting part. The interesting part is that the work looks different too.

The coordination layer is disappearing. Status updates, dependency tracking, timeline management. These run through systems now. Visibility is exactly what automates first.

So what's left?

The skills don't disappear. They move. The instincts that made someone good at coordination, the ability to anticipate dependencies, to see where handoffs break, to know which questions will surface too late. Those translate. They just apply earlier. Before execution. Before the system takes over.

A Different Ratio

A recent engagement made this concrete for me.

I spent more time in documentation than in build. Weeks defining scope, mapping dependencies, writing specifications that anticipated questions before anyone asked them. Edge cases named. Capability boundaries drawn. Handoff points documented so clearly that when execution moved to the LLM tool, there was almost nothing left to coordinate.

In the old way of working, that ratio would have signaled a scheduling failure. Documentation dragging. Build compressed. Something wrong with the timeline.

But nothing was wrong. The build moved fast because the definition was precise. Execution became mechanical because ambiguity had already been removed.

That's where the work went. Earlier. Into the effort to crystallize clarity so that everything downstream runs clean.

Execution used to take the schedule. Now clarity does. The judgment work isn't something to get through before the real work. It is the real work.

Why Upfront Matters

The friction to good execution is shrinking. Tools are more capable every day. The gap between intent and output keeps closing.

But the friction to good input isn't shrinking. Defining the problem precisely. Naming the edge cases. Knowing what to include and what to leave out. That's still hard. That's still human.

When visibility automates, what remains is the work that no one could figure out how to measure. It was always there. It just rode along unexamined.

This is where PM skills belong now. Not in managing the execution. In shaping the input that makes execution possible.

The Shape of the Work

The invisible work isn't random. It has a shape.

Holding context that no single person or system holds on its own. Knowing the business goal, the technical constraint, the political tension, and the deadline pressure all at once. Knowing which one wins when they conflict.

Defining boundaries before the work begins. Not task assignments. Capability boundaries. What gets handled here, what gets escalated there, what never should have been in scope to begin with.

Designing handoffs that don't require a meeting to explain. Structuring work so that when one phase ends and another begins, nothing gets lost in translation.

It's architecture. Not software architecture. Work architecture. The structure that determines how effort flows, where decisions live, and what happens when something falls outside the defined path.

The Reframe

The old job was about keeping things moving.

The new job is about making sure they don't need to be kept moving. Designing the system so that motion is built in. So that handoffs don't require someone in the room. So that escalation paths exist before anyone needs them.

That's where the value sits now. Not in the coordination. In the clarity that makes coordination unnecessary.

This is closer to orchestration than coordination. Closer to designing the machine than running it.

The Open Question

I don't know what to call this yet.

"Project management" doesn't fit anymore. The phrase carries too much of the old job inside it. Too much of the visible work that's already shifting. Too little of the invisible work that remains.

I didn't have language for this when I was doing it. I just called it "being a good PM." But that phrase hides more than it reveals. It bundles the visible and invisible together and pretends they're the same job.

They're not.

Maybe the title changes. Maybe it doesn't matter what it's called.

What matters is that the frame is still standing. The job description is still there.

But what it used to hold has left the building.

This site is what it appears to be. Vanilla HTML, CSS, and JavaScript. No frameworks, no build tools, no dependencies.

Just code that does exactly what it says.