Start Here If You Inherited a Function You Didn't Build

You inherited a function that already runs. The systems are up. The reports go out on time. On paper nothing is on fire, which is exactly what makes the first month so disorienting, because the thing works and you still cannot see how.

It shows up in small ways. You approve something you do not fully understand because the person presenting it clearly does. The documentation is thin, or it describes a version of the function that stopped being true two reorgs ago. The person who knew why it was built this way is on their way out, and most of what they knew is leaving with them. Every meeting assumes context that did not arrive with the title.

You do not need to read everything on this site to get your footing. You need seven pieces, in this order. The first two help you see what you actually inherited. The next three help you understand how it runs and who really runs it. The last two are about what no chart records.

The order earns the effort, because each piece changes how you read the next one. See who actually owns which decisions before you walk into the politics, and the friction starts to look like what it is, a defense of ownership gaps, rather than a set of difficult personalities. Out of sequence, you keep mistaking symptoms for causes. So take these in order, not by whichever title catches your eye.

Start with What's Running Underneath. Before you touch a process, you have to read the operating surface: the real work the function does every day, as opposed to the version the org chart implies. The gap between those two is where most of your early surprises are hiding. It is the report that officially belongs to one team but only goes out because someone on another team rebuilds it by hand every month.

Operational Learning: What’s Running Underneath

The discipline is knowing which updates produce decisions and which produce only comfort.

Brett W. FarmerBrett W. Farmer

Then read When Everything You Know Lives in One Person's Head. Every inherited function carries a concentration risk, and it is usually worse than anyone will tell you in week one. This piece hands you the question to ask out loud: what stops working within thirty days if the one person who actually understands it walks out the door. You often cannot answer that yet, and the not-knowing is the risk.

Operational Learning: When Everything You Know Lives in One Person’s Head

Organizations don’t forget because they’re careless. They forget because their most critical learning lives in people who were never asked to make it portable.

Brett W. FarmerBrett W. Farmer

Once you can see the surface, three pieces show you how the function actually runs.

Cadence as Control comes first, because control here is exercised through rhythms you did not set. The standing meetings, the review cycles, the deadlines everyone treats as fixed law: some still steer the work, and some just fire on schedule long after anyone remembers what they were for. Learning to tell those apart tells you where the real control sits, and where you are only keeping a calendar warm.

Operational Learning: Cadence as Control

If nobody owns the design of your operating rhythm, the rhythm stops controlling anything.

Brett W. FarmerBrett W. Farmer

Read Ownership as Architecture for the decisions. The chart you were handed says who is supposed to own what. What you need to find is who actually owns it, which is rarely the same map. This one is about ownership that got assigned but never designed, and the way decisions get absorbed in private right up until the day someone leaves and the gap opens under you.

Operational Learning: Ownership as Architecture

...one of the biggest reasons learning isn’t portable is that it’s trapped inside ownership that depends on a specific person’s knowledge, relationships, and institutional memory.

Brett W. FarmerBrett W. Farmer

Then The Politics of Friction, because some of the friction you inherited is protecting the business and some of it is protecting a role, and from the outside the two look identical. If you start stripping out friction to look decisive in your first quarter, this is the piece that keeps you from taking out a load-bearing wall by accident.

Operational Learning: The Politics of Friction

Some of the friction you carry isn’t protecting the business. It’s protecting a role.

Brett W. FarmerBrett W. Farmer

Those final two take longer to see, because you only learn them by being in the room a while.

Read The Polite Lie. By the time you arrive, the team has already worked out what to say carefully and what to leave unsaid, and they are mostly doing it to keep pressurized rooms running, not to mislead you. This piece is about the honest version that stops reaching whoever is in charge, and why that absence is a trained behavior rather than a character flaw. It is the difference between the status you are told and the status that is true.

Operational Learning: The Polite Lie

Most learning systems fail by reading green while quietly losing the room.

Brett W. FarmerBrett W. Farmer

End with Hands Stilled. This one is not for week one, and it will not feel urgent yet. It is for the version of you two or three years in, after you have rebuilt the parts that needed it and fought for an ownership map you finally trust, when the hardest discipline turns out to be keeping your hands off it once it finally runs without you.

Operational Learning: Hands Stilled

The hardest part of building an operating architecture isn’t the years of pushing. It’s the discipline of keeping your hands off it once it catches.

Brett W. FarmerBrett W. Farmer

The pull, early on, is to change something visible fast, to prove they were right to hand you the job. These seven buy you the few weeks it takes to see the function clearly first, so that what you eventually change is what actually needed changing, not just what was easiest to point at.

Start with the one that names what you are most afraid you inherited. Which of the seven is it?