What Is a Systems Thinker, Anyway?

TL;DR: Systems thinking means seeing how the parts connect: what a change touches downstream, what has to happen first, and whether mistakes loop back. I picked it up on a construction site, and it’s the same habit I use in customer success and with AI.

Why I keep hearing this phrase

Lately my YouTube feed is full of videos with titles like “The People Who Will Do Well in the Age of AI.” The specifics change, but the answer keeps landing in the same place: systems thinkers.

I call myself one, so I find myself nodding along. When I stopped to ask what “systems thinking” actually means, “I think about the big picture” felt too vague and simplistic. There must be a better way to explain it.

So what does it actually mean?

A systems thinker looks at how the parts of something connect, not only at the part in front of them. Three habits show up for me over and over.

Downstream. When one thing changes, what else moves? The change itself is rarely the expensive part. The expensive part is everything it touches, especially if what it touches is not obvious until much later.

Sequence. What has to happen first for the later steps to work? Order is often the difference between a smooth project and a rework.

I love getting into the weeds of thinking through the details- drawing process maps, honing in on step by steps, because a lot of times, a process can sound simple (“Send a renewal notification to the client”), but there can be a lot of manual steps involved:

1. Identify the renewal notification period
2. Look at the current contract
3. Calculate renewal pricing based on specific parameters
4. Identify renewal contacts
5. Draft the renewal notification email from a template
6. Attach all relevant backup material
7. Send
8. Follow up at specific time periods

These manual steps are great opportunities for improvement.

Loops. Does the output of a process come back around and change the next input? Good loops improve themselves over time. Broken loops quietly make the same mistake again.

Take the renewal notification example above. Say a client tells you they never received it. The quick fix is to resend it. The loop fix is to find which step failed, such as an outdated contact or a manual human error, correct that step, and add a check so the next renewal doesn’t fail the same way. The failure feeds back into the process, and the process gets better.

A specialist asks, “Is my piece done well?” A systems thinker also asks, “What does my piece do to everyone else’s?”

---

How I developed systems thinking

I have always been interested in how things work together. Growing up in both Hong Kong and NYC, I’ve loved the beautiful skylines and the humongous skyscrapers that decorate them. I picked civil engineering as my undergrad major because I liked math and solving problems. In senior year of college, we had a guest speaker who mentioned that construction management was where the money was, so that seemed like a good enough reason to target this industry.

(I didn’t take any personality tests back then, but looking back, my results suggest construction was a better fit than I knew. A couple of my strengths line up well with coordinating trades against a budget and a schedule. I wrote a blog post about my results if you want to learn more.)

Learning to see the whole building

My first job out of college was on the interiors construction engineering team at Turner Construction. Interiors trades join the jobsite after foundational, structural, curtain wall, mechanical, electrical, plumbing, and fire protection trades, so my trades had to work around whatever the earlier trades had already built. I needed to know about changes to any of that work, because each one could ripple down to my trades.

Here is the kind of chain I learned to see. Reconfigure the piping in a room and the ceiling may have to change to hide it. That can mean a new drywall bulkhead, a different ceiling grid layout, and light fixtures and sprinkler heads that no longer land where the drawings put them. If the drywall is already framed or hung, someone has to tear it out and redo it, and the work may need another inspection before the ceiling closes. None of those changes look big on their own. Together they decide whether the room works.

I also had to coordinate with those earlier trades. For example, the curtain wall couldn’t fully close until we had brought in the interior materials that were too big to fit in the hoist. Close it too early and those materials had no way in. Leave it open too long and the building stays exposed to the weather, which can hold up the finishes inside.

Decisions like that only work when you can see the whole building at once, because a choice that is right for one trade can quietly cost another.

Why change orders stuck with me

I also worked on ASIs (architect’s supplemental instructions, which are clarifications or changes to the drawings during construction), so I saw every drawing update as it came through.

Change orders (the formal changes to a contract’s cost and schedule) were the bane of the engineer’s existence. Nobody likes rework and all the waste around it, especially me. I know change orders are somewhat part of the game, but it felt like a personal failure whenever I had to push one through, because I was supposed to coordinate the changes to prevent them.

That left a lasting impression. It is really important to get things done right the first time, because every change order brings unproductive work: more money, more time, more admin work, more negotiating, and more back and forth that does not add value to the project. That is what reinforced my systems thinking.

Looking back

In hindsight, 22-year-old me made a wonderful decision to start my career in construction management. I spent five years on the Police Academy project, and it was really cool that when I joined, we were just driving piles into a huge dirt field. By the time I left, I got to see a brand-new, two-building campus with actual NYPD cadets in training. I also took away all the lessons of how to put together a building, like Legos but in real life. 10/10 would do it again.

---

I care about foundations, and I run loops

I like digging into the details to make sure the foundational data is right, because it affects everything built on top of it. A wrong number at the bottom doesn’t stay at the bottom.

In customer success, the mistakes that taught me the most were the plausible wrong answers. A report that shows zero might mean no activity, or it might mean the data just isn’t there. A count of “users” might not count the people you assume it does. So now I ask one question before I build on any number: what is this actually measuring?

Sometimes I wonder if I seem like too much of a stickler for details because I need to know the definition behind things, but my definition of “number of accounts” in a database might not match someone else’s- do we mean number of all accounts ever, including deleted ones? Do we mean to include both active and inactive accounts? These details are important because there’s nothing I dislike more than being inefficient, and different people working on the same problem but speaking different languages without understanding each other is super inefficient. So ironically, I am a very detail-oriented systems thinker.

Here is the part that makes it a loop and not just a lesson. Every wrong answer I catch becomes a standing rule, so the same mistake doesn’t happen twice.

I do the same thing with AI. I analyze my own work with it, then have it improve itself, so each round makes the next one better. I’m very meta about this on purpose.

Have I told you I really dislike waste?

Long story short: I dislike wasting time and money. Efficiency isn’t a hobby for me, it’s closer to an itch.

I mean it when I say that I don’t really want to win a $1B lottery jackpot. A more reasonable amount, something like $20M net, would be more than enough for what I need. (To be clear, I’m not saying I wouldn’t accept a $1B lottery jackpot, I’m just saying I’d be happy, if not happier, with a smaller amount.)

While this may not make sense to other people, it makes perfect sense to me. I look at what the system is for, and stop optimizing past the point where it helps.

---

Why this matters more now

The systems thinker answer feels intuitive to me because AI has so much potential to help us with workflows from end to end, as opposed to just being plugged in to build specific apps.

Think about the pre-AI world. SaaS was a primary business model because customers bought software to fix specific problems. If they needed to manage client relationships, they bought a CRM like Salesforce. If they needed data visualizations, they bought something like Tableau. Each tool solved one pain point.

With AI, we need to think about replacing whole workflows end to end, not plugging into one pain point at a time. That takes someone who can see the whole workflow.

AI has made building much faster, and that shifts where the hard part is. Knowing what is worth building, and what it will touch, is now the scarce skill. When something takes a weekend instead of a quarter, you can ship a lot of changes before anyone notices the one that quietly broke something downstream.

That’s the same lesson as the change order. Speed makes the downstream question matter more, not less.

Seeing the whole post-sales journey

The biggest place I use this right now is at work. I’m helping think through AI agents for the entire post-sales customer journey at my company, not only for customer success.

It would be easy to build agents for CS and stop there, because that’s my seat. But agents are only as good as what they read from, so the part I care about most is the shared substrate: one layer of customer context that everyone in post-sales feeds into and draws from. That includes product operations managers, implementation project managers, technical consultants, support, and renewals managers.

Here is why that matters in practice. What a client shares during onboarding is important context for the CSM later, so the client doesn’t have to repeat themselves. If support helps a client work through a gnarly bug, the CSM should know about it too, because it’s part of the client’s experience even if the CSM never touched the ticket.

That’s the downstream and loop thinking from earlier, applied to a whole team. Each role’s work lands on the next one, and a fact captured once, in the right place, saves every later step from having to rediscover it.

Our jobs have traditionally been organized into separate roles, but I think in terms of the system and not just my role. That lets me care about how the whole journey feels to the client, not only my slice of it.

---

How to practice it

You don’t need a construction site to build this skill. It comes from a few habits you can practice on whatever you’re working on right now. Before you change a process, ship something, or build on a number, start with these four questions:

• What does this touch? List who and what depends on it before you change it.
• What has to happen first? Check the order, not just the list.
• What is this number actually measuring? Know what it includes and what it leaves out before you build on it.
• Does this come back around? If a mistake happens twice, turn it into a rule or a check, and make sure it fires without you having to remember it.

Then try these exercises, one at a time:

1. Draw one process end to end. Pick something you do repeatedly, like onboarding a new client or sending a renewal notice. Write down every step, including the manual ones nobody mentions. Circle the steps where work waits, gets redone, or changes hands. Those are your opportunities to improve.
2. Ask “and then what?” three times. Before you approve a change, follow it downstream. What does it touch, what does that touch, and who finds out last?
3. Talk to the next person in the chain. Ask what they receive from you and what they wish they had received. People downstream see problems you can’t see from your seat.
4. Write down your definitions. Before you share a number, write what it includes and excludes, and check that the person reading it means the same thing.
5. Keep a mistake log. When something goes wrong, note the wrong assumption and write one rule or check that would have caught it. Then build that check into a template or checklist so you don’t depend on remembering it.
6. Ask AI to poke holes. Describe your process (a generic version works fine) and ask, “What does each step depend on, what could break, and what happens downstream if I change step 3?” It’s also good at spotting steps you left out of exercise 1.

Start with one. Systems thinking is a habit, and it gets easier every time you trace a change one step further than you did last time.

Frequently asked questions