From Invisible to Explicit: How to Fix the Process Breakdown That's Silently Slowing Your Team

A follow-up to yesterday's post: The Implicit-to-Explicit Transition — the moment your unspoken norms had to become written ones.

In yesterday's post, I described the moment it happens. The team is growing. New hires joining every month. More PRDs, more handovers, more of everything. And suddenly — the invisible glue that held your team together quietly stops working. People lose the sense of who to ask, who owns what, and what good even looks like anymore.

Today I want to go further. Not just name the problem — but give you two frameworks to actually start fixing it.

By the end of this post, you'll walk away with:

• A framework to identify who should own this transition

• A framework to identify what needs to be made explicit first

A quick recap: why the implicit breaks

When the team is small, processes don't need to be written down — documenting everything at that stage creates bureaucracy instead of effectiveness.

The PM handing over a PRD to developers doesn't need a 20-item checklist. A rough draft and a quick sync is faster and better. The PM passing materials to marketing? Also not a checklist — just proactive, regular communication: after discovery, the full concept, what materials are needed, what's coming next.

It works because people have enough context to use their judgment. They know who to ask, who owns what. The cost of mistakes is low.

The ambiguity is even a feature — it creates coffee chats, and more chats mean more bonding, more trust, more context shared organically.

In a small team, a little vagueness is actually connective tissue.

Then a magical number gets crossed. And as a founder or leadership team in a scaling company, you start asking yourself:

• What actually needs to be documented? Which cross-functional processes are breaking?

• Who owns making the implicit explicit — the COO? Each team lead?

• Who sits down and actually writes it, and in what format?

• If the new process doesn't work, who owns the feedback and iteration?

These are exactly the right questions. Here's how to answer them.

Framework 1: Who should own the transition

The instinct is to give this to the COO, or to each team lead. Both are wrong — at least as a starting point.

Karl Weick's Organizational Sensemaking theory gives us a useful lens here. Weick argued that in moments of organizational disruption, the people best positioned to make sense of what's breaking are those who sit at the intersection of multiple information flows — not those at the top of the hierarchy, and not those deep inside a single function.

In a scaling company, that person is rarely the COO (too removed from the daily handover friction) and rarely the individual team lead (too inside their own function to see the cross-functional gap & focus more in team's matters). The right owner is whoever has the "pleasure" to be sitting in the middle of all teams in an operational way, and almost works across teams.

One practical test: ask yourself — who in this company gets pulled into the most cross-functional fire drills? That person already has the context map in their head. They're your transition owner.

A personal example

Let me make this concrete. As a product manager, I sit in between virtually every cross-functional team. That position means I spot a lot of problems — or opportunities, depending on how you look at it — because I interact with a lot of people daily and have a lot of outcomes to drive:

• Enabling the sales team to know what's coming next so they can sell better — and gathering feedback from their lost deals to see if something is missing in the product

• Informing product marketing and social media what's coming, the timeline, and giving inputs on their content direction

• Gathering information from data scientists, or providing strategic pillars on how they should approach the data

You need someone who lives inside the chaos. Either you find someone already in your team who is proactive enough to take this on — that's what I did, and it's actually how I discovered my passion for operational excellence and change management — or you bring in a consultant who goes into your team, runs interviews, and collects the full grocery list of friction points.

COOs and team leads can play this role too. But based on my experience, whoever takes this on needs three specific things:

Strong listening skills — not talking skills. What matters is the ability to listen, ask really good follow-up questions, and open up space for people to surface problems without feeling judged or exposed.

The ability to switch between bird's-eye view and ground-level detail — to hold the big picture while also being able to get into the weeds of a specific handover that's breaking.

The ability to run this like a product — because operational excellence is a product. There will be requests coming from every direction, competing priorities, and no clean roadmap. You need someone who can define a strategy, set a prioritization formula, and manage it as a project with real outcomes.

If you're curious about what this actually looks like in practice — drop a comment and let me know. I may write a dedicated post on the exact application.

And crucially: whoever this person is, they need a formal mandate — explicit authority to convene conversations, collect friction points, and make calls when alignment stalls. Without it, this work gets deprioritized the moment a product deadline hits.

Framework 2: What to make explicit first

Not everything needs to be documented. In fact, over-documenting early is one of the fastest ways to kill the agility that made you successful in the first place.

A useful filter comes from coordination theory — specifically the distinction between pooled, sequential, and reciprocal interdependence (by James Thompson).

Here's how to apply it:

Pooled interdependence: teams share resources but work mostly independently. Low documentation priority.

Sequential interdependence: one team's output is another team's input — like a PM handing a PRD to engineering, or engineering handing a build to QA. This is where implicit norms break first. Document these handovers first.

Reciprocal interdependence: teams continuously adjust to each other in real time — like product and design in active discovery. These are harder to document and more resistant to checklists. Focus on principles and decision rights here, not process steps.

In practice: map your most common cross-functional handovers and ask — is this sequential? If yes, it's your first documentation target.

Start with the two or three handovers generating the most recurring confusion or rework, and make those explicit before touching anything else.

Putting it together: the order of operations

1. Identify your transition owner — the person at the intersection of the most information flows — and give them a formal mandate. Or identify someone and start putting that person in the middle of the chaos so to start the process.

2. Map your sequential handovers — where does one team's output become another team's input?

3. Rank by friction — which of those handovers is causing the most rework, confusion, or unspoken resentment right now?

4. Document the top two or three — not as rigid checklists, but as clear agreements on what good looks like at the handover point.

5. Build in a feedback loop from day one — assign someone to collect what's not working within 60 days, and schedule a revision.

The goal isn't a process library. It's just enough explicit structure to rebuild shared context at the new scale.

The most important thing isn't getting the documentation perfect.

It's naming the owner (letting the team knows someone is going to take ownership of this is already MAGICAL & impactful by itself), and starting with the process of designing ONE workflow causing the most pain. Everything else can iterate from there.

If you're in this moment right now — what's the hardest "process issue" to fix in your team, and do you have a clear owner for it?

Drop it in the comments. I read every single one.