2610: The Shelf You Put It On

I've been building a slide for a seminar I'm putting together, and one small piece of it kept stopping me mid-edit. It's a short segment on risk, and it splits into three categories: opportunity, constraint, and obstacle. Opportunity is upside uncertainty — the easy one. Constraint is a condition you genuinely cannot change. Obstacle is a problem that can change, if you push on it the right way. Simple to state. I've been designing a quiz to help people feel that third distinction in their gut, using something as ordinary as planning a BBQ — sourcing, venue hours, who's available to run the grill, who has to sign off on the budget — and every time I write a new example, I catch myself second-guessing which shelf it belongs on.

That's the part worth admitting: I've made this mistake plenty of times myself, on real projects, not just in slide-writing. Call something a constraint too early and you stop pushing on it — you file it away as unchangeable and walk past whatever quiet negotiation or workaround might have moved it. Call something an obstacle for too long and you burn weeks of energy trying to bend a regulation or a physical limit that was never going to bend, no matter how creatively the team attacked it. The two failures point in opposite directions, but they share the same root: a single, unexamined decision about which shelf a problem goes on, made early and never revisited.

Building the quiz taught me something I didn't expect going in — getting the "correct" classification right matters far less than I assumed. What actually matters is whether a team develops the habit of stopping to ask "is this really unchangeable, or have we just decided it is?" The same fact pattern can sit as a constraint in one organization and an obstacle in another, or flip from one to the other once the timing or the people involved change. The classification isn't the destination. It's the door into a conversation the team should be having anyway.

That's close to the actual core of what a project manager does, once you strip away the scheduling software and the risk registers. It's less about the technical skill of identifying risks and more about whether the team can keep asking, out loud, whether a wall is actually load-bearing or just looks that way because nobody's leaned on it yet. A team that stops there gets a different outcome from an identical set of constraints than a team that pushes through that one question together.

I'm not going to lay out the full framework or the quiz here — it's built for the room, not the page, and I'd rather people work through the constraint-versus-obstacle confusion the way it's meant to be worked through, with a group and a whiteboard, not by reading my answer key. If the distinction sounds like something your team keeps tripping over, I'm putting together a three-day seminar with a colleague that spends real time on exactly this, alongside the rest of what project design and facilitation actually require. Details are here: https://www.guc-intel.com/seminar.html. For everyone else, the smaller takeaway travels fine on its own: next time something feels immovable, it's worth one more question before you file it away.

2609: Argue First, Then Ask the AI

Yesterday's PP&M seminar left a whiteboard covered in two columns, and the second column was the uncomfortable one. The first listed what should decide who gets assigned to a project — personality fit, availability, capability, relationships, aptitude, soft skills, motivation, diversity. The second, filled in by the room admitting the truth out loud, listed what actually decides it: whoever happens to be free, whoever is loudest, whoever the sponsor already trusts. Nobody enjoyed writing that second column. That discomfort turned out to be the point.

Only once the room had argued its way through that gap — no shortcuts, no tool, just people disagreeing with each other about what's real in their own organizations — did the facilitator open an AI assistant and feed it everything the whiteboard had produced. What came back wasn't a new answer invented by the AI. It was the room's own messy, half-formed conclusions organized into a clean before-and-after comparison, and a first draft of a "next-generation" work description with fields the current template simply doesn't have: a line for communication style, a line for the kind of teammate this role needs to pair well with, a line for the career motivation a good fit for this role should already carry. Every one of those fields traced back to something someone in the room had said twenty minutes earlier. The AI hadn't diagnosed anything. It had taken a diagnosis we'd already reached the hard way and given it a shape that could survive being handed to someone else.

That ordering is the part I keep replaying. It would have been faster to skip the argument and ask the AI directly: what should a good work description include? It would have produced something plausible, even well-organized, and it would have been almost useless, because it wouldn't know that in this particular office, the quiet expert keeps losing assignments to the loud mediocre one, or that the actual friction point is a manager who reads "available" as "capable." Those specifics only exist because a room full of people were willing to sit in the discomfort of naming them to each other first. The AI's value showed up entirely in the second step — structuring, formatting, making an idea portable — and depended completely on the first step having already happened without it.

I do the reverse constantly in my own consulting work, and yesterday made me notice it. A client hands me a mess, and before I've let them sit in the discomfort of naming what's actually wrong, I'm already halfway to a framework, a template, a deck. The instinct isn't laziness so much as a kind of politeness — nobody enjoys watching a room struggle, so you reach for the tool that promises to shorten the struggle. But the struggle is where the real material comes from. Skip it, and the tool, however good, is just organizing air.

The broader lesson isn't about AI at all, not really. It's that the order of operations is the discipline, and the order that actually works is: people argue out the true, uncomfortable version of the problem among themselves first, and only then hand the result to a tool to give it durable shape. Reverse that order and you get something articulate and wrong. Keep it, and even a rough whiteboard turns into something you can actually use on Monday.

2608: What Two Designers Taught Me About My Own Process

I spent last week at a business fes, mostly there to scout partners and see what else was out there. Two of the speakers were designers, walking through how they take a client from "we have a problem" to a finished product — understanding, problem definition, concept, prototype, then support after launch. Neither talk mentioned project management once. And yet by the end of the second session I was scribbling notes, because I kept recognizing my own work inside theirs.

I run GUC, a project management consultancy, and the thing I tell clients constantly is that you cannot apply a framework off the shelf. PMBOK, agile, lean — the principles hold, but the organization in front of you has its own history, its own scar tissue, its own unspoken rules. A framework laid on top without translation just sits there, technically correct and useless. Listening to those two designers back to back, I realized the sequence they were describing — dig into the real situation, define the actual problem underneath the stated one, shape something specific to that problem, test it small, then support it into place — was structurally the same sequence I already walk clients through when I propose how we'll run their project. I'd never once put those two disciplines next to each other before that day.

What made the similarity worth more than a passing observation was what came next: I started thinking about where design process could actually improve how I propose project management to a client, not just where it happened to resemble it. Designers are far more disciplined than PM practitioners tend to be about not designing anything until they've properly understood the person they're designing for. In my own proposals, I'd often move to "here's the process I recommend" faster than a designer would ever move to a concept. The affinity wasn't just interesting — it was a genuine gap I could close. If I borrowed the designers' patience at the front end, the project management approach I hand a client afterward would fit them the way a well-designed product fits its user, not the way a standard template fits any client.

That's a small shift in words but a real shift in practice: proposing project management as something designed for a specific organization, using a design process to get there, rather than proposing a methodology and adjusting it afterward. I left the fes convinced this wasn't just a nice parallel to notice once and forget. It's a discipline I should be borrowing on purpose, every time I sit down with a new client.

I haven't turned that into anything concrete yet, and I don't want to pretend otherwise. What I have is a question I keep returning to since the fes: where exactly, in GUC's own business process, would borrowing a real design discipline change what I hand a client? Not as a slogan about "designing projects," but as an actual sequence I hold myself to before I let any methodology leave the building. That's the part I want to work through properly rather than bolt on quickly.

The broader takeaway is one I keep circling back to in different forms: expertise that arrives ready-made, before anyone has properly understood the person receiving it, is the wrong kind of expertise, no matter how sound the framework is. Two designers who have never run a project management engagement in their lives gave me a clearer articulation of that principle than years in my own field had. That's usually how the useful lessons arrive — sideways, from people solving a completely different problem, who turn out to have already solved yours. Now I just have to do the slower work of actually building it into how GUC operates, instead of stopping at the observation.

2607 The Gift of Solitude: How Alone Time Nourishes the Brain

 

Say the word "solitude" and it often carries a lonely ring. In an age when connection is made visible through social media, spending time alone tends to be read as a bad sign — as if you have no friends, or don't quite fit in.

But I've always liked being alone. Time spent with others matters, of course, but the quiet time I spend alone — thinking, feeling, simply being — has always felt essential to staying grounded.

A book I read recently, The Brain at Rest by Joseph Jebelli, backs up this feeling with research.

Doing Nothing Puts the Brain to Work

When we drift, doing nothing in particular, a circuit in the brain called the Default Mode Network (DMN) switches on. Activating the DMN is linked to sharper intelligence, greater creativity, and higher productivity.

And the key that turns the DMN on is, of all things, solitude. Yet solitude keeps getting pushed aside. Modern life fixates on the benefits of social connection, and social media has woven itself so deeply into daily routines that alone time now gets treated as worthless — something to avoid rather than seek out.

The Great Thinkers Respected Solitude

Great thinkers, Thoreau among them, held solitude in high regard. Stepping away from society's noise, they found, let them see themselves more clearly. One researcher calls this moment "becoming present" — a sign, in neurological terms, that the DMN has begun to fire.

Writing, playing the piano — creative work like this often goes better alone. In that solitary time, the brain forms new synapses, sharpens skill, and nurtures creativity more effectively than it could in company.

Why I Ride Alone

I love heading out on my motorcycle by myself. I do go touring with friends now and then, but most of the time, I choose to ride solo.

The reason is simple: it's both "time alone" and a chance to fully immerse myself in the act of riding itself.

The sound of the engine, the resistance of the wind, shifting your weight through a curve — riding a bike demands constant attention to this moment, right now. You can ride while talking with someone, but doing so inevitably dilutes that sense of immersion.

It's precisely when I'm riding alone that the noise in my head falls away, leaving only the scenery in front of me and the sensations in my body. That, I suspect, is exactly the kind of brain-rest that solitude — the subject of this whole post — provides. Riding along in a half-daze, my mind ends up sorting itself out, quietly, almost without my noticing.

Touring with friends is fun too. But time spent riding solo is irreplaceable — it's time spent facing myself.

If Being Alone Feels Like a Bad Thing

If being by yourself carries a quiet sting of guilt or loneliness, you're far from alone in that. Many people have absorbed the idea that solitude is something negative.

But it's worth trying to see it differently.

In the Netherlands, there's a relaxation practice called niksen — sitting on a bench and watching people go by, or simply lingering in a café with nothing to do. Building this kind of "doing nothing" into daily life has been used as a way to manage stress and even depression.

There's also "mindful solitude" — sitting somewhere quiet and breathing, setting aside the same time each day to be alone, powering down your devices for that stretch. Small habits like these give the brain rest, and help restore creativity and the capacity to solve problems.

In Closing

Solitude might not be something to avoid at all — it might be an asset worth using wisely. Time spent with no one to compare yourself to, no one to accommodate, just facing yourself. That's not a sign of weakness. If anything, it's what makes you sharper and stronger.

The next time you notice you're alone, try reframing it — not as loneliness, but as the brain recovering, and creativity quietly taking root.