Systems thinking
When a system crosses a boundary
Internal systems optimize for speed. Delivered systems optimize for repeatability. What happens in between is worth noticing.
I recently completed two agile project management courses that looked at how different frameworks fit different situations: team size, product maturity, risk posture and customer expectations. We studied large space and aviation programs—what worked, what didn't, and why. It gave me a chance to step back and look at something I've lived on both sides of the fence, as a contractor and inside the contracting organization.
The backdrop: two technical reviews in the same week. One internal. One with a supplier. Same expertise in the room. Completely different structure.
Same people, two different systems
Inside the organization, the review felt familiar. Fast. Collaborative. Efficient. We moved quickly because we shared history, context, assumptions and relationships. Much of the system was implicit. It lived in the people.
The supplier review felt different. Structured. Traceable. Deliberate. Every requirement mapped, every assumption documented, every decision anchored. The system had to become explicit. It lived in the process.
From the balcony, a pattern was clear:
Internal systems optimize for speed. Delivered systems optimize for repeatability.
Implicit to explicit
The moment work crosses a boundary—between teams, organizations or contracts—it has to move from implicit to explicit. At small scale, implicit systems work beautifully. But as complexity grows:
- knowledge becomes harder to transfer,
- onboarding slows down,
- automation becomes difficult, and
- lessons learned are harder to reuse.
The system stops scaling, and people become the bottleneck. Implicit systems scale through people. Explicit systems scale through structure.
What struck me most is that suppliers don't operate inside just one system. They move across programs, organizations and industries, constantly translating implicit systems into explicit ones. That's why they often see patterns the rest of us miss. They work at the ecosystem level.
Reviews as organizational memory
So it raises a quiet question. What if structured technical and program reviews aren't overhead, but organizational memory? What if they're the mechanism that lets knowledge scale, insight transfer and the system learn—not to slow us down, but to help the system evolve?
This matters even more now that AI is in the room. A model's output carries none of the shared history that makes an internal review fast. It arrives without context, without the hallway conversation, without the person who remembers why we chose that margin. When an AI answer crosses into your program, treat it like work crossing a boundary: make the assumptions explicit, name who owns them, and write down how you decided.
From where you stand today: which parts of your program run on implicit knowledge, and what would it take to make the important parts explicit before the next review?
Is a model or AI output about to drive one of your decisions? Ten questions will tell you whether you're ready to own it.
Take the free Readiness Check