2606: The Compass, Not the Map

 One month ago I filed the paperwork and became a company. I didn't have a clean plan for what came next, just a hypothesis that the project management consulting I'd been doing informally would find its footing as something formal. What I didn't expect was how fast the scope would move. A month in, the work has already stretched beyond project management into process engineering consulting, because that's where the actual conversations with clients kept going. Nobody asked me to expand the offering. The clients did, just by talking to me about what was actually breaking in their organizations.

That expansion taught me something I thought I already knew but hadn't really tested: you cannot apply project management by the book. I mean that literally — take the textbook, take the framework, lay it over a real organization, and watch how much of it doesn't fit. Not because the principles are wrong. PMBOK, agile, lean, whatever lineage you draw from, the underlying logic holds up. But the actual company in front of you has its own history, its own scar tissue from past failures, its own unspoken rules about who can say what to whom in a meeting. A framework applied without translation just sits on top of that reality, technically correct and practically useless.

What I've been doing instead — and what I only fully understood by doing it for a month straight — is holding the principled version of "how this should work" in one hand, and sitting down with the client's own internal members to build the version that actually fits their company in the other. That second part isn't optional or secondary. It's the actual consulting. Anyone can hand over the ideal process on a slide. The harder, more valuable work is doing the tailoring together with the people who have to live inside that process every day, so what comes out the other end is recognizably theirs, not mine.

Here's the part that surprised me most: the clients I'm fortunate enough to be working with are genuinely excellent at this. I bring the navigation — here's the principle, here's why it exists, here's the direction — and instead of waiting for me to hand them a finished template, they take that and do the interpretation themselves, quickly and well. They ask the right clarifying questions, they push back where the principle doesn't map cleanly onto their reality, and they land on a tailored version faster than I could have designed it alone. I've started to think my actual job isn't delivering the process. It's pointing true north clearly enough that a capable team can chart their own route to it.

That's the broader lesson from month one: the value of this work was never going to be in how faithfully I could reproduce the textbook. It's in how well I can navigate — hold the principle steady, translate it into something workable in coordination with the people who'll own it, and trust that the more capable the client, the less I need to build for them and the more I need to build with them. A month ago I thought I was starting a project management consultancy. What I'm actually building is a practice in navigation, one client's tailoring at a time.

2605: Why "Working Together, Not Delegating" Is Our Real Advantage

Last week I wrote about putting my slide down mid-meeting and just asking what was actually going on — a small moment that sent me into Edgar Schein's "Humble Consulting." I finished the book still turning one idea over: the "Level 2" relationship, where a consultant earns enough trust that a client will finally say what's really wrong. I didn't expect that idea to circle back to something I already believed about my own company. But a few days later, sitting across from a prospective client who kept asking me to just tell him the scope, price, and timeline, it did.

He wanted what most Japanese companies default to when they need project management discipline: carve the function out, hand it to an outside PM firm, get a schedule and a status report back. It's a clean transaction, and on paper it looks efficient. It's also exactly the model Schein spends a whole book warning against — treating expertise as a deliverable you buy rather than a relationship you build. An outside firm shows up with the framework already loaded, produces the Gantt chart, and never gets close enough to hear about the turf conflict or the fear of losing face that's actually stalling the project. They were hired for what I've called koto — the schedule, the process, the paperwork — and structurally excluded from hito, the people problem underneath it.

That's the gap our philosophy, Working Together Not Delegating, was built to close, and reading Schein right before that meeting made me see why it isn't just a nice phrase on our website. A Level 2 relationship doesn't happen in a kickoff call and a signed SOW. It happens because someone sits inside the work with the client, week after week, humble enough to ask instead of prescribe. In a culture where hesitation, deference to hierarchy, and reluctance to say the uncomfortable thing out loud are baked into how meetings work, a delegated outsider almost never gets invited into that territory — there simply isn't enough shared history for the client to risk it. Someone who works alongside the team, rather than around it, has a real shot.

I told the prospective client something I wouldn't have framed this way a month ago: I wasn't going to quote him a fixed-scope PM package, because that's not actually the product that solves his problem. What he needed wasn't someone to take the project off his plate — it was someone to get on the plate with him long enough to find out why his team wasn't moving in the first place. He looked skeptical. Fair enough; it's a harder pitch than "we'll run the whole thing for you." But it's the only version of this work I actually believe produces something that outlasts the contract.

2604 What Edgar Schein Made Me Admit About My Own Advice

 I walked into a meeting this week ready with a recommendation. I'd done the analysis, I had the slide, I knew what the client should do — and within ten minutes the conversation had drifted somewhere the slide couldn't follow. Instead of forcing it back on track, I put the deck down and just asked what was actually going on. That single decision, and how uncomfortable it felt to make, is why I picked up Edgar Schein's "Humble Consulting: How to Provide Real Help Faster" this week, and why I couldn't put it down.

Schein's core claim is almost embarrassingly simple once you see it: most consulting fails not because the expert lacks expertise, but because the expert never builds a relationship honest enough for the client to say what's really wrong. He calls the alternative "Level 2" relationship — a shift from the polite, role-based distance most professional interactions default to, toward something closer to genuine personal trust. You get there not by demonstrating more competence, but by dropping some of it. Asking a real question instead of a leading one. Admitting you don't yet understand the situation instead of performing certainty you don't have.

I've spent most of my career being paid to have answers. Frameworks, methodologies, the right diagram for the right problem — that was the value I thought I was selling. What caught me this week is Schein's argument that the diagram is often the least useful thing in the room, because it answers a question nobody asked, dressed up as insight. The client's actual blocker is almost never a missing framework. It's usually something nobody has said out loud yet: a turf conflict, a fear of looking incompetent, a decision that was made for political reasons and now needs a technical justification. You can't PowerPoint your way into that territory. You have to be invited in, and the invitation only comes after you've shown you're listening for the real problem rather than pattern-matching to the one you already know how to solve.

The part that stung a little was Schein's distinction between "helping" and "being helpful." Being helpful is fast, visible, and often about the helper's own need to look competent. Helping is slower, requires tolerating not-knowing in front of a client, and starts with something as unglamorous as curiosity. Reading that, I recognized how often my instinct to have the answer ready was really an instinct to manage my own anxiety about looking unprepared, not a genuine read of what the client needed from me in that moment.

The broader takeaway I'm sitting with isn't really about consulting technique. It's that expertise and helpfulness aren't the same axis, and I've been optimizing the wrong one. The slide I put down this week wasn't wrong — it just wasn't the thing the room needed yet. Real help, it turns out, starts with humility about what you don't know, not confidence about what you do. That's a harder skill to build than any framework, and probably the one that matters more now than it ever has.