Getting Started: Learning Systems Thinking

calendar Jan 1, 0001 · 6 min read  ·
Share on: linkedin copy

People ask me how to get better at their work - whether it's device management, automation, architecture, or just understanding why complex systems behave the way they do. The answer isn't usually "read the docs" (though that helps). It's about developing systems thinking. Here are resources that changed how I approach problems.

Systems Thinking: Start with "The Goal"

If you read one business book, read The Goal by Eliyahu Goldratt. It's a novel about manufacturing, but it's really about how to think about constraints, bottlenecks, and outcomes.

The core idea: Every system has a constraint. Find it. Optimizing everything else is pointless. This applies to IT as much as it does to factories.

  • When you're troubleshooting, you're looking for the constraint.
  • When you're designing systems, you're trying to avoid creating false constraints.
  • When you're managing processes, you're identifying which step limits throughput.

I've applied this thinking to MDM design (where's the enrollment bottleneck?), API integrations (what's the rate limit?), and feature adoption (what's stopping users from adopting this?). It's the difference between busy work and meaningful problem-solving.

Start with process mapping. Here's the uncomfortable truth: what you think is the process is rarely what's actually happening. People skip steps, add workarounds, create "bandaids" that become permanent fixtures. That's why so many processes fall apart - you're applying constraints to an imaginary process, not the real one.

Before you fix anything, map the current state. Observe. Interview people doing the work. Document what's actually happening (not the flowchart from 2015). Then you can identify where the real constraints are and why those bandaids exist in the first place. Only then can you redesign for automation AND durability.

Related:

Thinking in Systems by Donella Meadows - denser, more scientific, but teaches you how to model complex systems.

The Scientific Method: Applying Rigor to Problem-Solving

I have a degree in Integrated Life Sciences. That background taught me something that I've found invaluable in technology: hypothesis-driven thinking.

The scientific method isn't just for labs. It's how you should approach any problem:

  1. Observe - what's actually happening? (Not what you think is happening.)
  2. Hypothesize - form a testable explanation.
  3. Test - deliberately design an experiment to confirm or refute it.
  4. Iterate - adjust your hypothesis and repeat.

This is why I push back on "quick fixes." Quick fixes skip steps 1 and 3. You end up optimizing for the wrong constraint.

In practice:

  • Troubleshooting a system? Form a hypothesis about why it's failing, then test it. Don't just make random changes.
  • Building a new process? Prototype it with a small team first. Gather data. Iterate. Then scale.
  • Designing a product feature? Get user feedback. Iterate. Don't ship version 1.0 and hope.

Related reading:

Iterative Planning: Especially with AI-Assisted Tools

This is where a lot of people go wrong with AI copilots (GitHub Copilot, Claude, etc.). They jump straight to "build me a thing" and end up with something that partially works, then spend weeks unwinding and adjusting.

Start with a plan. Before you ask an AI to code, design, or architect anything, you need:

  1. Problem statement - what's the real problem you're solving? (Not "I need a script." But "I need to reduce manual provisioning of X by Y%.")
  2. Definition of done - how will you know when it's complete? What does success look like?
  3. Key players and related systems - what systems does this touch? Who's affected? What constraints exist?

Then iterate. Share your plan with the AI. It'll spot gaps. ("What about error handling?" "Have you considered this edge case?") You'll discover scenarios you missed. Refine the plan. Then when you actually build it, you're working from clarity, not guessing.

Why this matters: A 30-minute planning conversation with an AI that identifies a missing piece is worth infinitely more than 20 hours of development that has to be reworked. The AI is excellent at asking "what about..." questions, but only if you give it the context to do so.

In practice:

  • Start in a document (Markdown, Notion, whatever). Write the problem and success criteria.
  • Share it with your AI copilot. Iterate. Add scenarios, edge cases, constraints.
  • Once the plan is solid, then move to implementation.
  • Keep iterating the plan as you build. Don't let implementation diverge from intent.
  • Maintain a decision log. Every time you make a significant choice (why you chose architecture X over Y, why you changed the scope, why you added that constraint), log it with context. Future you will ask "why did we do it that way?" and you'll be grateful the answer is right there instead of lost in your brain.

This applies whether you're building an integration, architecting a system, or designing a process. Plan → iterate → execute. The plan changes, but you're always working from a shared understanding instead of discovering requirements at 2 AM.

Understanding Computing and Security Fundamentals

You can't architect secure systems if you don't understand the fundamentals. Start with:

Podcast (best for commutes):

  • Security Now by Steve Gibson - weekly deep dives into security, cryptography, and how the internet works. Steve explains things clearly without dumbing them down. Highly recommended.

Free resources:

Books:

AI and Large Language Models: Free Training Resources

If you're curious about how LLMs work or want to learn prompt engineering:

Free from Anthropic (Claude's maker):

Free courses and resources:

Practical learning:

  • Use LLMs on real problems. Get uncomfortable with prompt engineering. Try to break them. See what works and what doesn't.
  • Read the papers behind the models you use. Understanding architecture (transformers, attention, token limits) helps you know what to ask for.

Recommended listening:

  • The AI Podcast by Nvidia - interviews with researchers and practitioners. Good for understanding where the field is heading.

The common thread

Systems thinking, the scientific method, security fundamentals, AI - it all comes back to the same thing: understanding how things actually work, then thinking clearly about how to improve them.

Don't just follow best practices. Understand why they're best practices. Then you'll know when to break them.

Comments welcome.