What Systems Thinking Actually Means (And How to Test It)

Systems thinking is showing up in every blog post and every job description right now… and if you ask five people to actually define it, you'll get five different answers. That flexibility is exactly why it's spreading — it can mean big picture thinking, foundational thinking, second order effects, connecting the dots, basically whatever anyone needs it to mean that week. Which also means it tells you nothing useful about who to hire or who needs development.

So here's how I think about it. Once you strip away the vocabulary, systems thinking isn't a trait someone has or doesn't have. It's simply the size of the boundary they draw around the problem they're trying to solve… and that boundary shows up every single time something breaks, or some opportunity appears that nobody assigned them to go find. A bug comes through, one person patches their own component cleanly and moves on. That's not *wrong*. They've just drawn the boundary right at the edge of what they own. Meanwhile someone with a genuinely narrow mandate keeps finding things no one asked them to look for, because they drew the boundary wider than their job description did.

And it kept feeling more obvious to me that this matters more than it used to, not less. Even if you understood the whole system before, execution used to be expensive enough that your own effort could only reach so far… so a narrow understanding never really got tested against reality. Your job boundary and the cost of getting anything done were both capping how far the consequences could travel. Now that execution is cheap and one person can act across the whole system, that cap is gone. If your understanding doesn't stretch as far as your ability to act does, that's exactly how change starts outpacing anyone's grasp of how the pieces fit together… including your own.

So if you actually want to know where someone's boundary sits, don't ask them to define systems thinking. Ask them about a change they made that had downstream effects somewhere they never expected, or one someone else proposed that would have hit their work in a way nobody saw coming. Ask an engineer how operating budget decisions might shape the architectural choices they're about to make, or ask a designer how a customer's experience in a retail store might ripple into the digital product. Whatever comes back tells you exactly where their understanding stops… and whether that's the same place their job description does.

0:00 Why "systems thinking" is spreading everywhere

0:33 The actual definition, once you strip away the vocabulary

0:53 What a narrow boundary vs. a wide one looks like

1:16 Why cheap execution changes the stakes

1:55 How to actually test for it in an interview

SUBSCRIBE for more insights on leadership, product, and technology

Newsletter: https://www.nathanbroslawsky.com

LinkedIn: https://www.linkedin.com/in/broslawsky

#leadership #engineering #management #productmanagement #technology #cto