Friday, July 31, 2026

2603 Koto and Hito

 This week I sat down to write a memo for my CBL colleagues, and halfway through I realized I was really writing about the thing I've been circling for two decades of project management: there are two completely different jobs hiding inside the job title "project manager," and I've spent most of my career treating them as one.


In Japanese I split them as koto and hito. Koto — literally "the matter" or "the thing" — is the schedule, the budget, the risk register, the status report, the process. Hito — "the person" — is why a stakeholder is stalling, why a team goes quiet in meetings, why two departments that should cooperate instead quietly sabotage each other. For most of my career the two blurred together into one skill called "project management," and the koto side was where the credentials, the Gantt charts, and the professional identity lived. Hito was the messy overflow you handled with instinct, if you handled it at all.


What made me actually write the memo, rather than just think it, was watching how fast AI has started eating the koto side this year. Schedule optimization, cost forecasting, risk analysis pulled from historical data, progress reports auto-summarized from meeting transcripts — the tools I trained a generation of junior PMs to painstakingly build by hand are now something you generate in a prompt. And PMI saw this coming before I did: PMBOK's sixth edition, the one I studied for my own certification, was almost entirely a koto document — process, tools, techniques, prescribed in detail. The seventh edition, published in 2021, pivoted hard toward what they call "power skills" — principles for how a team actually creates value, not a checklist for how to run one.


That's not a coincidence. It's the largest project management body in the world quietly admitting that the technical half of the job was becoming commoditized well before AI made it obvious.




Here's the part that actually matters, though, and it's the part I underestimated for years: AI is extraordinarily good at statistical patterns, and hito problems are not pattern problems. "Why won't this team move" isn't sitting in a dataset — it's sitting in a history between specific people, in resentments nobody wrote down, in a culture gap nobody named out loud. You cannot prompt your way to that diagnosis. You have to be in the room, and you have to actually know the people.


This week an AI tool drafted a full project schedule, a cost forecast, and a risk register in a fraction of the time it used to take — work that once ate a full day of mine, back when I built these things by hand. I sat there a little stunned, and a thought I've circled for two decades finally clicked into words: project management has always been two different jobs stitched together, and I'm not sure the one I trained for is the one that matters anymore.

In Japanese I split them as koto and hito. Koto — literally "the matter" or "the thing" — is the schedule, the budget, the risk register, the status report, the process. Hito — "the person" — is why a stakeholder is stalling, why a team goes quiet in meetings, why two departments that should cooperate instead quietly sabotage each other. For most of my career the two blurred together into one skill called "project management," and koto was where the credentials, the Gantt charts, and the professional identity lived. Hito was the messy overflow you handled with instinct, if you handled it at all.

I'm not the only one who's noticed the split widening. PMBOK, the project management bible I studied for my own certification, was almost entirely a koto document in its sixth edition — process, tools, techniques, prescribed in detail. The seventh edition, published in 2021, pivoted hard toward what PMI calls "power skills" — principles for how a team actually creates value, not a checklist for how to run one. The largest project management body in the world quietly admitted the technical half of the job was becoming commoditized well before AI made it obvious.

Here's the part I underestimated for years, though: AI is extraordinarily good at statistical patterns, and hito problems are not pattern problems. "Why won't this team move" isn't sitting in a dataset — it's sitting in a history between specific people, in resentments nobody wrote down, in a culture gap nobody named out loud. You cannot prompt your way to that diagnosis. You have to be in the room, and you have to actually know the people.

So the koto knowledge I spent years accumulating — the tools, the methods, the certifications — is depreciating in market value in real time, whether I like it or not. But the hito work — reading what actually motivates a stakeholder, building a room where people function as themselves instead of performing a role, turning a cultural gap into leverage instead of friction — isn't just AI-proof. Its scarcity is going up precisely because everything around it is getting automated.

The broader takeaway, for me, is uncomfortable and clarifying at the same time: the parts of this career I was proudest of on my resume are the parts getting automated first, and the parts I used to file under "soft skills" are turning out to be the whole point. If that schedule is any indication, the koto side isn't coming back as a differentiator. The only question left is how deliberately I invest in the hito side instead of treating it as something that just happens if I'm lucky.

Sunday, July 26, 2026

2602 GUC Is live


 I stared at a blank "publish" button for longer than I'd like to admit. Not because the website wasn't ready — it had been ready for days — but because clicking it meant the thing I'd been quietly building since I left T&T was no longer a private project. It was now a company other people could find, judge, and, hopefully, call. This week I clicked it. GUC — Growth Unlimited Co. — is officially live at guc-intel.com.

Two posts ago I wrote about why I was leaving. Last week I wrote about the disorienting first week of having no structure at all. This week the structure finally started to take shape, and it took shape around one decision I kept coming back to during every conversation I had this month: GUC will not be a firm that takes projects off your plate. It will be a firm that gets on the plate with you.


That distinction sounds like branding, but it's actually the whole thesis. I spent 25 years watching how expensive external advisory work usually plays out — a PM firm parachutes in, runs the project competently, and parachutes out, taking all the hard-won judgment with them. The client is relieved for eighteen months and then right back where they started, because nothing was transferred. I've been that parachuting expert. I got good at it. And I've decided I don't want to build a company on repeating it.


So GUC's model is deliberately less convenient for me and more useful for the client: work alongside the team, not instead of it, and treat "does the client's own staff walk away better at this" as a real success metric, not a nice-to-have. It's why the services page leads with advisory work embedded inside client teams, and only gets to training and organizational development — strengths-based, in partnership with CBL — once that embedded trust is established. You can't teach an organization to run itself if you're the one running it.


The insight that surprised me, building this out over the past few weeks, is how much that philosophy is really just lean thinking applied to consulting itself. Lean says don't build more process than the work needs. Applied to advisory services, it says don't build more dependency than the client needs either. Every EPC project I ever ran taught me that the healthiest projects are the ones where, by the end, the client barely needs the outside expert anymore. I'm trying to build a business whose success is measured the same way — not by how indispensable I become, but by how quickly I make myself less necessary.


The broader takeaway: if you're building something new, the model you choose says more about your values than your mission statement does. I could have built GUC around maximizing billable hours per client. Instead I built it around minimizing them, deliberately, because that's the version of this work I actually believe in. It's a harder way to run a company. It's also the only way I wanted to run one.


The site is live. The real work — the first client conversations — starts now.

https://www.guc-intel.com/