I thought I had already pared it down.

So what is… The Lyceum?

I posted a couple of weeks back that I was starting it, and said more would follow. I’m coming to the end of the first learning block now, which means there’s something to report.

The short version: 12 weeks, 10 workshops, an ICM certification at the end of it, taught live by Jake Van Clief. It’s the significant step up from the Foundation ICM course I’d been posting about.

For anyone landing here cold, ICM is Interpretable Context Methodology. Numbered folders, plain markdown files, and a human review gate between the steps, instead of an orchestration framework holding everything together. Each step gets only the context that step needs, so the AI isn’t dragging the whole history behind it.

Worth knowing, because the course is built the same way it teaches you to build.

Questions, then processes, then implementation

It’s 10 workshops in 3 blocks, with a gap week between blocks so everyone can breathe. The first is the questions. The second turns the answers into processes. The third is implementation and testing against a real target. Jake’s reason for that order is to prevent you from spending months and many $$ on the wrong thing, and to figure out what you actually need to implement.

Each session is an hour lecture, then an hour building in breakout rooms with people whose work touches yours, and of course there is the homework.

There are 3 rooms running a similar curriculum: Technical, Business, and Creator. I’m in Business. What changes is where the hours go and what the people around you push you on. Technical concentrates on making it work at scale and safely. Creator concentrates on getting a good thing seen. Business is discovery, packaging, pricing, and go to market, and the question this room asks about whatever you’re building is whether it’s worth money, and how much.

The rooms are sorted by the outcome you’re after rather than your experience.

The teaching itself also keeps moving. There’s a layered file on me that started from my intake call before the course began, and Jake, along with each student, adds to it after every lecture. That’s what lets the course adapt to the room, and further in, to each student. It’s the same layered context loading I’ve been writing about for months, pointed at a person rather than at an agent.

The questions you forgot to ask

The first block is 3 weeks of questions. No building. The framing we were given is that we’re separating out everything you shouldn’t be doing, and that you should expect to leave this block with a smaller, more focused plan than you walked in with.

Early on they gave us an interview about what we’re building. I described mine.

The very first response I got back:

That spans four hand-offs. Which one task is the work you are actually trying to fix: the technician capturing final specs at the home, the change loop back through sales, or the transcription into the manufacturer’s system? Pick one.

I had described a broader system, even though I thought I’d already pared it down.

That’s the part worth thinking about. I hadn’t walked in with a sprawling wish list. I walked in with something I believed was already narrow, and it still spanned 4 ideas.

The right answer, once I could see it, was the change loop. There were 2 reasons.

The first is scope. Choosing the change loop put the transcription of specs into the manufacturer’s system out of frame, and a long tail of work went with it.

The second is that the change loop is the heart of the problem we’re looking to solve. It’s where friction and the errors actually happen today. Picking it wasn’t about making the build smaller. It was about making the build land where it already hurts.

Then they pushed further. Inside that one task there’s more than one receiver, and each receiver needs its own definition, and its own minimum item that can be delivered and actually deliver value. So “pick one” wasn’t the end of the narrowing. It was the start of it.

That’s been the heartbeat of the whole block, and they’ve pushed back on it countless times now. What does the receiver of this actually need. What gets you traction instead of noise. What problem are you solving.

Why the questions come first

Modern software is going to adapt to the person, not the person to the software. That’s the direction all of this is heading.

Which changes what you need to have in hand before you start. If the thing you’re building is going to shape itself around a person, you have to know which person, which role. The actual someone on the other end of it. That’s why picking one task wasn’t the end of the narrowing for me. The change loop has more than one person receiving something from it, and each of them needs their own answer.

So the receiver isn’t a detail you settle while you build. It’s a requirement you bring to the build, the same as anything else you’d need before writing the first line. Same goes for the minimum unit of value, the smallest thing you could hand that person that’s worth having. Get those 2 wrong and you’ve built something that adapts beautifully to nothing of real value.

That’s why questions come before processes, and processes before implementation. Not because it’s tidier. Because the answers are the raw material for everything after them.

If you’re building something right now, here’s the version of this you can run on your own work. Write out the hand-offs your thing spans, and count them. Then pick the single one where the errors and the rework actually happen today, rather than the one that’s most interesting to build. Name who receives it. And name the smallest item of value they need that you could hand them. If you can’t say those 2 in a sentence each, that’s the work, and it comes before the build.

I would have told you before this block that I already worked this way. I had 4 hand-offs sitting on the table and didn’t know it.

If someone made you pick one, would the piece you kept be the one that actually delivers the value?