We Built an Operating System for How We Work. Here's Why.

This is the first article in “How We Actually Build”... a new series where we open up the CRAFT methodology, one layer at a time, as we roll it out to real client teams. No retrospective polish. Just what we built, why we built it, and what we’re seeing as we run it.

There’s a pattern I’ve watched repeat across a dozen client engagements, and it took me a long time to name it correctly.

A team has the right people. They’re moving fast. They’re using AI tools like Cursor, Claude, and GitHub Copilot, and genuinely getting leverage from them. The early demos are impressive. The client is excited. Things feel like they’re working.

And then, somewhere around week six or eight, something starts fraying. A decision made three weeks ago gets re-litigated in a status call because nobody documented why it was made. A new developer joins and spends two weeks getting up to speed on context that nobody wrote down. A deployment happens without a rollback plan because the team was moving fast and “we’ll handle it if something breaks.” Something breaks.

Thanks for reading! Subscribe for free to receive new posts and support our work.

None of this is caused by bad people. Every team I’ve watched go through this had talented, hardworking engineers.

The problem isn’t the people. The problem is that the system they’re working in is designed to scale heroes, not outcomes.

Why instinct stops working

For the first several years of InTech, we ran on good instincts and strong people. That worked. When your team is small enough that everyone is in the same conversations, instinct is a reasonable substitute for process. Problems surface quickly. Context lives in people’s heads because you’re all in the same room. A senior person catches things before they go sideways.

But at some point, instinct stops being a feature and starts being a liability.

TheAI era made this more acute, not less.

When individuals can generate code faster than ever, the bottleneck shifts away from output and toward judgment.

What should we build? What did we already decide? What’s the constraint we’re working within that the AI doesn’t know about? Those questions don’t answer themselves. And the faster a team moves, the more expensive it is when they go unasked.

Last fall, I started looking hard at a pattern I’d been seeing across our projects: teams using AI tools and getting real individual productivity gains, but not seeing those gains compound at the delivery level.Individual output up. System-level outcomes roughly flat. The reason was almost always the same: no shared operating layer. Everyone was optimizing locally. Nobody wasoptimizing the system.

That’s when Chuck and I decided to stop assuming and start designing.

What we built

We spent the fall of 2025 building what we now callCRAFT, a lightweight operating system for how small, AI-enabled teams actually work. Not a methodology pulled from a consulting framework. Not Agile with a new coat of paint. Something built from scratch around the specific failure modes we kept watching repeat.

CRAFT is an acronym:Context → Rationale → Automate → Fortify → Telemetry.

Each phase addresses something that breaks when teams move fast without a system:

Contextis shared truth: what are we building, for whom, under what constraints, and what do we already know about the risks. The thing that usually lives in one senior person’s head and never gets written down.

Rationaleis explicit decisions. Not just what we chose, butwhy, what we considered, and what would cause us to revisit it.

If a decision was made verbally and not captured, it wasn’t made. It was assumed.

Automateis AI and tooling used deliberately, calibrated to the risk level of the task. Not “give everyone Copilot and see what happens.” Automation earns its autonomy based on what’s at stake if it’s wrong.

Fortifyis the set of conditions that have to be true before anything ships. Rollback plan. Known failure modes. Basic telemetry. A shared definition of done that isn’t “it compiles.”

Telemetryis measurement of outcomes, not activity. Not how many pull requests merged, but whether the thing we built did what we needed it to do, and what we learned from the gap.

This series will go deep on each of these, one article at a time. Chuck takes the next two: the Intent Contract and the Decision Record, the first two artifacts teams start using. I’ll share the actual templates we run. Because this isn’t a philosophy. It’s a system you can pick up.

The five laws we don’t negotiate on

Before the artifacts and the phases, there’s a layer underneath all of CRAFT we call the Constitution. Five rules. They’re not suggestions, and they’re not context-dependent. Every time we’ve allowed an exception to one of these, it has cost us.

1. No work without Intent. Work doesn’t start until the team has a clear, written answer to: what are we building, for whom, and what does success look like? If you can’t answer those three questions in writing, you’re not ready to build. You’re ready to have a conversation.
2. Decisions must be explicit. If a decision was made verbally and not written down, it wasn’t made. It was assumed. Assumptions show up as rework, re-litigation, and “wait, I thought we decided...” moments six weeks later.
3. Automation scales with risk, not ambition. The question isn’t “can AI do this?” The question is “what happens if AI does this wrong?” Low-stakes, reversible tasks? Automate aggressively. Decisions with production consequences? Humans stay in the loop. The sophistication of your AI tooling is not the right metric for how much you trust it.
4. No scale without Fortification. Nothing ships without a defined rollback plan, known failure modes, and at least basic telemetry in place. This is the rule teams break most often under pressure. It’s also the rule that produces the most expensive incidents when broken.
5. Learning is mandatory. Every delivery cycle produces something the team knows now that they didn’t know before. If that knowledge doesn’t get captured and fed back into the system, it disappears when people move on, get busy, or forget.

Learning that isn’t captured doesn’t compound.

These five are the floor. If your team operates inside all five, you have the foundation. What you build on top is up to you.

What we’re betting on

CRAFT has been running in pilot with a small number of client teams since early this year. Three months old as a live system, not three years. I’m not going to tell you it’s proven. That would be getting ahead of what we actually know.

What I can tell you is what we’re betting on.

We believe the next meaningfulcompetitive advantage in software deliveryisn’t individual AI productivity.

Everybody has access to the same tools now. The advantage is team-level compound leverage: a small, well-coordinated team running on a real operating system versus a larger team running on vibes and standups. That gap is structural, not marginal. And it widens the longer each team runs its system.

CRAFT is how we’re designing for that gap. And this series is how we’re building in public about it, sharing not just the finished methodology but the actual experience of running it. What’s working. What surprised us. What we’re still calibrating.

If you’ve been with this newsletter since Series 1, you’ve already seen the problems we’re trying to solve. The estimation models that lie to you. The decisions that get re-litigated in every status call. The $50k prototype that looked like a product and wasn’t. CRAFT is the operating system we built in response to those problems.

Next week, Chuck walks through the first CRAFT artifact: the Intent Contract. It’s what goes at the beginning of every piece of work, before a keyboard gets touched. It’s also the thing that surfaces more misalignment, faster, than anything else we’ve tried.

If this resonated, subscribe. We’re writing about what’s actually changing in software delivery, no hype, no hand-waving, just what we’re seeing on real projects.