Most people think systems fluency means being able to draw an org chart or describe how a process flows from step A to step B. That's not it. Systems fluency is the capacity to hold a mental model of the whole — to see feedback loops before they become fires, and to understand why changing one variable rarely produces the effect you expected.
We've met engineers who can build extraordinary things inside a system while remaining completely blind to the system itself. And we've met operators who can't write a line of code but can feel when an organization is about to break. Both are valuable. The rare person does both.
What we're watching
The pressure to move fast is real, and it's at war with the time it takes to develop true systems fluency. Most organizations implicitly reward local optimization — the person who ships the feature, closes the deal, puts out the fire. The person quietly preventing those fires rarely gets a quarterly bonus for it.
This tension isn't new, but it's sharpening as systems grow more complex and more interdependent. The cost of not understanding the whole keeps going up, while the incentives to invest in that understanding stay flat or decline.
The underlying question
Can systems fluency be taught, or does it have to be earned through failure? We don't have a clean answer yet. But we keep noticing that the most fluent systems thinkers we talk to have all, at some point, been responsible for something that broke badly — and were made to understand exactly why.