I think this is the spirit Donella Meadows, Peter Senge, and others are asking of us. The courage to sit with ambiguity, ask questions, and dig deeper. This is not about vulnerability or consensus-building. A group that agrees fast isn’t necessarily healthy. Sometimes, fast agreement can mean real alignment, or it can mean that everyone has already learned which thoughts don’t get rewarded. Maybe this is part of why applying systems thinking is hard to implement. This asks us to stay open to revising, distrust the first clean explanation, and expect to be surprised.

(causal loop diagram)

So how do we build intellectual intimacy, that hard skill underneath systems thinking, before the group locks in on an action? You treat it as infrastructure. Separate inquiry from decision and track unresolved questions like you track risks. Give people the space to work through their thinking process.

Part 4 of my journal entry.

Subscribe now

Share

Leave a comment

Some common types of systems include the nervous system (the brain, spinal cord, nerves), technology (smart thermostat: inputs, processes, outputs, feedback), solar system (Sun, planets, moons, asteroids), and ecosystem (plants, animals, bacteria, soil, water, etc.).

Donella Meadows - the modeler

Structural, with elements, interconnections, and the function or purpose around which the whole thing is organized. This makes sense considering her background in computer modeling.

Peter Senge - The leader

An aerospace engineer by training and a management researcher at MIT Sloan. Senge’s definition is based on shifting perspectives and recognizing patterns of change. Training an organization to stop reacting to isolated events and notice the patterns behind them.

Sweeney and Sterman - The educators

This duo approached this definition through a testing lens rather than modeling or leadership.

Meadows defines the object:

Does it name a purpose?

Does it name the elements?

Does it name the interconnections?

Use it to build or diagnose the structure of a system, an organizational chart, and data pipelines.

Senge defines the mindset, interrelationships, and patterns.

Sweeney and Sterman are strong on learning, behavior, and mechanism. In their view, teaching and assessing whether people understand how delays, feedback, and stocks behave before handing them a complex project to run.

Part 3 of my learning journal.

Subscribe now

Share

Leave a comment

This got me thinking about the language in job postings and how we can interpret them. Hiring managers write postings around observable behavior and not frameworks.

So how does an applicant know what to look for when no one screens for a model they've never heard of?

They screen for what the model produces: judgment calls, risk anticipation, and handling ambiguity.

Lately, since my focus has been learning systems thinking and Cynefin, I’ll focus on these two.

Share

Here are phrasings from current job postings that connect directly to systems thinking and Cynefin.

Frameworks are internal models for making better decisions. Resumes and postings are external interfaces for getting hired. If you only speak in framework language, you're filtering yourself out of roles that actually want exactly what you have.

The pattern across all these postings is that none of them name the framework. They describe what the framework produces. The employer wants the output of systems thinking, without knowing or caring what the internal model is called. How do you connect the dots across systems, anticipate downstream effects, and interdependencies? How do you tackle open-ended challenges and experimentation? That is Cynefin. Your resume should speak in outcomes, not framework names.

Subscribe now

Share

Leave a comment

In the last few years, I’ve regularly read Bent Flyvbjerg’s (How Big Things Get Done) and Dave Snowden’s (Cynefin Framework) articles, books, and social media posts. They write about what makes big, complicated projects succeed or fail. Flyvbjerg focuses on complex projects and research on failure rate. He has a database of project data, spanning industrie and decades to work from. Snowden has more of a systems dynamic expertise applied to projects and decision making. He has advised the US military, emergency management, DARPA, The EU, and public safety organizations.

They both agree that a plan for a huge project is fragile, not a fixed plan, because you cannot predict or control it.

My learning journal prompts:

What is the topic, in one sentence? The topic is understanding complex systems (for complex projects and change) in the frameworks of two leading thinkers/researchers in this space - Flyvbjerg and Snowden.

What specifically am I studying within it? When preparing to initiate a complex project what tools and frameworks are best. What is the best thinking workflow.

What does it help you do? Learning the frameworks and research will help me diagnose which kind of uncertainty I’m facing before I pick a method.

What’s the difference I see between them?

Snowden and Flyvbjerg are intellectual allies with opposing approaches to project management. They diagnose the same symptoms and prescribe different cures. Snowden argues that forcing things into order is exactly how systems fail, and Flyvbjerg is trying to turn the unordered into the ordered. I think most PMs default to using one lens and force every problem through it. To move beyond that takes knowing what’s outside the project management body of knowledge and experience. Slowing down the planning to think through the project is important. Classify the work first. Then pick a method or two.

Share

Where they agree

Traditional, linear projects fail when applied to unpredictable, non-linear systems. But their approaches are different. Controversially, they both reject the fail-fast, iterate-as-you-go mentality. Instead, Snowden advocates for small, parallel, bounded probes to test the environment before committing to the broader system. Another one from Snowden: retrospective data cannot predict future outcomes in complex environments.

Regular readers know I have written more than a few articles on project management and how best to manage them for success. In IT, this is crucial to the project's success. It’s more than technical ability.

Bent Flyvbjerg believes project leaders should look at case studies to help make practical decisions based on the situation of the project. He does not trust simple rules that claim to work everywhere, like best practices. That’s understandable and I agree with that. Dave Snowden, on the other hand, warns against looking at a few successful companies, finding something they all do, and then saying, “Do this, and you will succeed.” He says this mixes up things that happen together (correlation) with things that actually cause results (causation), which is a big mistake in complex situations. Also understandable.

Share

As I’ve written in a previous article, Snowden is skeptical of management best practices, and so is Flyvbjerg. A best practice can look like this: 5 successful projects that used agile do not mean agile caused their success or that it will work on every other project.

This overlooks other reasons why those projects might have succeeded or failed. And also, most organizations don’t have a database full of project successes, the reasons for success, and documentation explaining it. Historical documentation as a story. It exist in the project team’s memory which isn’t always accurate, as Snowden suggest.

The main difference between them is that Flyvbjerg uses aggregated macro-data to establish base rates to help people develop practical judgment grounded in context. Snowden warns that in complex systems, even aggregated base rates cannot predict emergent and novel futures. Snowden points out that people may not know the real reasons behind success and might just make up explanations after the fact.

Share

In really complex situations, you can’t know in advance what will work based on past successes. Snowden advises leaders to try small, safe experiments and see what patterns emerge before making big decisions. This really sounds like design thinking: define, ideate, prototype, test, empathize.

As a project leader, Flyvbjerg's research translates for me into looking outward:

1. Project teams have their own inside view, but it shouldn’t be taken as gospel.

2. Take a look at what similar projects have actually delivered.

3. Use a probability model based on observed data to set more credible budgets, schedules, and contingencies.

Snowden’s research translates to looking inward and experimenting:

Share

1. An historical case can offer a hypothesis or a pattern worth exploring; however, it cannot validate a “best practice” for a future complex project. They are complex because they are different (Healthcare.gov)

2. Know the type of project you have: Don’t mistake a complex project for a complicated one. They operate differently and should be managed differently. Complicated is sense first. Complex is probe first.

3. You learn what works through safe-to-fail probes, rapid feedback, and adaptation in the local system. This is similar to design thinking.

My thoughts

I don’t think we need to choose between historical evidence and experimentation. We should use both approaches for different parts of complex projects. Working several angles.

Use Flyvbjerg for forecasting and Snowden to manage uncertainty, stakeholder dynamics, and solution design.

Share

What This Means in Practice: Classify your workstreams

1. Complicated/repeatable work of the project: for IT projects, that can be a data migration, interface development, infrastructure provisioning. Estimated, planned, and controlled work. The Flyvbjerg method is most appropriate here.

2. Complex/emergent work of the project: Stakeholder alignment, governance adoption, operating model change, behavior change, policy interpretation, trust. Experimentation and ongoing sense-making work here. Snowden's methods call for small, observable experiments designed for fast feedback, so that positive patterns can emerge. For example, Healthcare.gov was actually a complex project but wasn’t executed that way. Engaging several states and stakeholders with different medical rules, and scaling for millions of users never attempted before. I don’t have to rehash the problems that ensured because we know what happened. You may not know what they did to fix the issues. They brought in a small team to probe, sense, and respond in real-time and it worked.

These workstreams don’t sit in silos. Even a good PM may not know when a complicated task has degenerated into a complex problem, requiring a switch from Flyvbjerg to Snowden. For complex projects, situational judgment is knowing what can be forecasted, what can be discovered, and what should be governed.

How I Plan to Apply This

Share

Knowing how to distinguish between different types of uncertainty and their appropriate responses is important.

1. Estimation uncertainty: What it means - We know the type of work but not the exact duration, cost, or risk. Response - Use reference class forecasting, ranges, contingencies, and probabilistic commitments. That means you gather the data, study it and then act on the analysis.

2. Technical uncertainty: What it means - A solution is possible but requires expertise, analysis, or design choices. Response: Use prototypes, expert reviews, architectural decisions, and staged delivery. This is what Snowden suggest. Probe, sense, and respond applied to a design problem.

3. Emergent uncertainty: What it means - People, incentives, institutions, and conditions interact in ways that cannot be reliably predicted beforehand. Traditional planning assumes rational choice. Internal politics, habit, and self interest can’t be captured in advance. Response - Run safe-to-fail probes, sense patterns, adapt, and avoid premature standardization.

Don’t choose between historical evidence and experimentation. We may need both. Pairing the outside view (Flyvbjerg) with the emergent view (Snowden) we can stop forcing a square peg into a round hole. Doing this we learn to slow down to speed up and ultimately building a dual-delivery engine: one for baseline forecasting and one for safe-to-fail probes to navigate complexity.

I think most project managers and project work operate in the mostly clear and complicated area on the Cynefin framework. But in technology and other massive multi-million and billion dollar projects, we operate in the complicated and more frequently complex arena. The more advanced the technology gets, the more complicated projects will be. The more interconnected we are the more complicated it gets. Going forward in my PM work I’ll filter the projects through these methods as an initial pass during planning and continuously when projects are reassessed.

And if you didn’t know Cynefin is pronounced kuh-nev-in.

References for this learning journal

The New Dynamics of Strategy: Sense-making in a Complex and Complicated World. Snowden and Kurtz. 2003.

A Leader’s Framework for Decision Making. Snowden and Boone. 2007.

How Big Things Get Done. Flyvbjerg.

Subscribe now

Share

Leave a comment

I’m working through, Sense-making in a Complex and Complicated World, and I wanted to pause on one area: the assumption of order. This is clear enough that we all can think through in our different roles and determine how to apply it.

Subscribe

Assumption of order, in traditional management thinking assumes the world works like a machine, cause and effect, there is a pattern you can build predictive models because X causes Y. It tells you what to do. You can forecast it. You can define best practices because what caused the past you can create the recipe and apply it forward.

These assumptions hold in simple and complicated systems, anything mechanical but breaks down in complex systems when cause and effect are only clear in hindsight, if at all.

Share

So, best practices from past experiences can fail when applied to complex situations. Why? Because the underlying condition were never as stable as they look. Let’s think about it:

• Best practices assume the conditions that produced past success will recur. In a complex environment they usually don’t. Worth thinking through when determining how to approach the next problem solving session or project. How do you determine what mode to use?

• Lessons learned in complex domains aren’t reusable rules. They’re data points about what once worked under in a specific situation of causes.

Don’t apply complicated domain thinking (repeatable, machine-like) to a complex domain problem (context dependent, not fully knowable in advance). And this is where Cynefin framework can assist.

Next I will tackle, from this same article by Snowden, The assumption of rational choice.

https://vdc.edu.au/wp-content/uploads/2018/02/Sense-making-in-a-complex-and-complicated-world.pdf?utm_source=perplexity

I pay attention to what separates good performance in my field from elite performance, and whether that gap is something I can get across.

For most of my career, I was trained as a delivery expert.  Scope, schedule, budget.  Build the thing on time, on specifications, and on budget.  That’s what the project managers’ guide teaches you. But the highest-stakes work require something else on top of that. A set of skills nobody handed me a credential for. I’ve spent the last couple of years trying to identify what those skills actually are and build them deliberately. That’s what this piece is. 

Subscribe

Most PM education stops at strategy.  Align the portfolio. Check the box. Done. Elite level is different. The environment keeps shifting under you. The people you need aren’t your reports, they don’t answer to you at all. That takes another skillset And nobody teaches it.

In my pursuit of becoming an expert in project, program, and portfolio management (PPM), I realized there is a level of understanding that goes beyond what PPM credentials can provide. This is one of the reasons I started to read project management research articles and write about what I read and my opinions of the field. Also, I wanted to apply some of the findings to my daily project work, get better, and pitch ideas within my organization. 

The shift I’m looking for is which skills move a project manager from tasks, processes, controls, and alignment in an individual project to complex adaptive systems. 

What does the next level of knowing looks like for anyone looking to get better at a thing.

So yes, project credentials are important because the process and lifecycle of a project matter and are built into the system of organizations.

Complex adaptive systems are different. It requires navigating emergence, human behavior, politics, diplomacy, and high ambiguity, how to survive and steer when the environment itself is fluid and unpredictable, and the ground keeps shifting under the plan. This goes beyond resilience.

Share

Project credentials matter because process are real. They’re built into how organizations accomplish goals. But complexity explodes at the point of execution, and that’s the terrain this piece is trying to map.

From my research on elite project managers, here are skills I’m working on:

Seeing clearly

• Sensemaking/complexity — Dave Snowden’s Cynefin framework. Knowing what kind of problem you’re actually in before you try to solve it.

• Systems thinking and dynamics — causal loop diagramming, the iceberg model, the Viable System Model, Soft Systems Methodology. Seeing what’s behind the structure.

• Strategic foresight — scenario planning, backcasting, signal detection, STEEP/PESTLE analysis, the Three Horizons framework, the Cone of Plausibility.

• Wardley mapping — evolutionary mapping, climate patterns, value chain maps, the strategic doctrines.

Share

Bent Flyvbjerg studies mega projects and has published several research backed papers and written several books on the subject of projects and project failure. His framework is about forecasting integrity in complex projects and skills project manages need to lead at a mega project level. From his work I’m studying:

• Sociopolitical complexity and corporate diplomacy: mapping shadow hierarchies and informal power networks, understanding who actually holds veto power.

• Cognitive readiness and behavioral dynamics: managing cognitive load, filtering noise to protect the execution team, compressing complex technical reality. Dynamic decision frameworks like Boyd’s OODA loop (I’ve written about), for out-cycling a changing environment instead of just reacting to it.

• Financial and value realization: Treating milestones as options to expand, defer, or abandon rather than one irreversible bet. Benefits realization, tracking the value a project generates 12 to 24 months after closure instead of stopping at on-time, on-budget.

• Technical and architectural synthesis: Conway’s Law, designing team structure to force the technical architecture you actually want. Socio-technical system design, blending human behavior with infrastructure like AI orchestration and data mesh environments.

Share

Governing without a single boss

This is the cluster that convinced me this is a different job, not a harder version of the same one. At this level, nobody hands you a governance structure. You have to build it. So on the study journey:

• Polycentric governance — Elinor Ostrom’s Nobel-winning work, now recognized as essential architecture for megaprojects and joint ventures. Traditional program management assumes a monocentric hierarchy, one sponsor, one chain of command. Large joint ventures and public-private partnerships don’t work that way.

• Metagovernance — the governance of governance. If polycentric governance is managing a network of independent teams, metagovernance is setting the ground rules for those networks without micromanaging them.

Share

Some of these skills I’ve written about before, just not with the depth I want. This learning path means building real understanding of each one, testing it against actual work, and documenting what that looks like as I go.

None of these are PM-specific once you look closely and mostly used in other professional domains. Cynefin, Wardley mapping, polycentric governance, the OODA loop: none of it was built for project managers. It was built for people who need to see structure, power, layers, environments, and change clearly, whatever field they’re in.

This is the first piece in a series. Each skill gets its own articles. Not sure of the sequencing yet but it’s probably sensemaking first.

I’ve spent 15-plus years managing federal programs. Polycentric governance and metagovernance aren’t theory to me. They’re what cross-agency IT modernization work forces you to learn, or fail at.

What’s the skill your job title doesn’t cover, the one you’re building anyway? Tell me what it is and how you’re building it.

Nicole

Subscribe

Comment

Share

Polycentric governance, the term from the second piece in this series, describes a structure:

It doesn’t say anything about who, if anyone, is actively working to keep those authorities lined up. In practice, someone usually is, even informally, even without the title for it.

Public management researchers have a term for that work: metagovernance. Louis Meuleman, who wrote the main academic book on the subject, defines it as designing and managing, shifting between, and combining different styles of governance rather than picking one and sticking with it. A more recent review of the literature puts it more plainly: metagovernance is a practice, mainly by public authorities, of coordinating across governance modes with different instruments and strategies, specifically to fix governance failures that show up when nobody’s doing that coordinating.

Share

Where that work is missing right now

AI governance is that gap, live, at global scale.

The European Union’s AI Act became fully enforceable on August 2, 2026, the first time any jurisdiction has imposed comprehensive, binding regulation on AI systems. That’s one governance mode: hierarchy, backed by enforcement.

The US is running a completely different mode, or rather, 38 different modes. There’s still no comprehensive federal AI law. States enacted 145 AI laws in 2025 alone, with major frameworks now in force in California, Texas, and Illinois, and Colorado’s AI Act taking effect June 30, 2026.

That’s a patchwork built state by state, each one legislating independently, closer to competition than coordination.

Sitting underneath all of it is a fourth mode: NIST’s AI Risk Management Framework, a voluntary technical standard rather than a law. Colorado explicitly built a safe harbor into its own AI Act for companies that follow it, and the framework lines up with both ISO/IEC 42001 and the EU AI Act’s requirements, which makes it one of the few things in this picture actually built to bridge jurisdictions rather than compete with them. The OECD’s AI Policy Observatory is tracking more than 1,000 AI policy initiatives across 69 countries, which gives some sense of how many separate authorities are making this same set of decisions on their own.

Four modes, running at the same time, with no one authority deciding which one applies where: a binding EU law, a state-by-state legislative patchwork, a federal attempt to override that patchwork that hasn’t succeeded, and a voluntary technical standard that happens to be the only thing all sides can plug into. Any company operating across US states and the EU is the one actually absorbing the cost of that gap, piecing together compliance across all four modes itself, because no one else is doing that coordinating for them.

Share

A diagnostic for your own program

The same setup shows up in smaller systems, including the kind most people manage day to day: a program built from multiple offices, vendors, or legal authorities that are each real and each partly in charge.

A few questions to check for it: Are you dealing with more than one governance mode at the same time: some hierarchy, some negotiated agreement, some market-style competition among vendors or teams? Is the choice of which mode to use for a given problem being made deliberately, or is it just whichever tool happens to be closest at hand? And is anyone actually doing the work of switching between modes as the situation calls for it, or is each part of the system running its own default, the way California, Texas, and the EU currently are?

If the answer is nobody, that’s not necessarily a crisis yet. It’s a gap that tends to stay invisible until the cost of it lands on someone, the way it’s currently landing on any company trying to operate across all four AI governance modes at once.

Share

What this changes

None of this requires appointing a new authority or restructuring anything. Metagovernance is usually informal, done by whoever in the system is already paying attention to more than one piece at a time. Naming it just makes that work visible, both to the person doing it and to whoever they answer to.

For AI governance, that coordinating work barely exists yet, and the bill for that gap is already coming due for anyone operating across more than one of these jurisdictions. For a program you manage yourself, the more useful question is whether that work is happening at all, and whether it’s happening on purpose. More on Metagovernance.

Nicole

Subscribe now

Share

Leave a comment

Two lenses for the same problem

Systems thinking is one way to read what’s happening: look at the parts, look at how they connect, and pay attention to where the connections are thin. It’s useful because it doesn’t require picking a villain. State DMVs, TSA, GSA, and NIST are each doing their own job well enough. The gap is in what links them, not in any one piece failing.

Share

Polycentric governance is a narrower, more specific version of the same idea. Political scientist Elinor Ostrom used the term to describe systems built from multiple independent authorities that don’t report to a single boss. Her original definition, from a 1961 paper with Vincent Ostrom and Robert Warren: many centers of decision-making, formally independent of each other, where whether they add up to a working system or to chaos is an open question rather than something built in from the start.

That’s a fair description of state DMVs, TSA, GSA, and NIST: four independent authorities, each with real power in its own lane, none accountable to the others.

The second framework sharpens the first. Systems thinking says: look for the gaps. Polycentric governance says: here’s specifically what to check for inside those gaps. Ostrom’s research on which multi-authority systems actually function found three recurring ingredients: a shared set of overarching rules everyone operates under, some way for the independent parties to monitor and adjust to each other, and a low-cost way to resolve disagreements when two of them conflict.

Systems missing one of these tend to drift instead of coordinate.

Share

What this adds to the digital public infrastructure (DPI) picture

Line this up against the digital public infrastructure gap from the last piece. DPI frameworks call for publicly accountable governance holding the whole system together, and that’s the piece the US digital ID rollout doesn’t have yet. Polycentric governance describes what “accountable” would actually require in practice: a shared rulebook, a way for state DMVs, TSA, GSA, and NIST to adjust to each other’s timelines, and a mechanism for resolving the kind of conflict that leaves a Delaware resident with an ID that works at the DMV but not at the airport.

That reframes what the fix could look like. Ostrom’s research suggests decentralized systems can work well under the right conditions, without a single agency running everything. US card payment networks are one example: independent banks and merchants operate under a shared rulebook set by Visa, Mastercard, and EMVCo, and the system holds together without one company owning every piece. Digital ID doesn’t have that layer yet. Ostrom’s three conditions give a way to check for it, piece by piece, instead of just naming the problem.

What comes next

Both frameworks point at the same missing piece: the rules, monitoring, and conflict resolution that would let independent authorities function as one system instead of four separate ones. The next piece walks through the same gaps in AI governance.

Nicole

Subscribe now

Share

Leave a comment

What’s available right now

As of early 2026, 21 states plus Puerto Rico issue a mobile driver’s license, or mobile driver’s license (mDL), that meets a technical standard called ISO/IEC 18013-5. That standard is what lets an ID built by one state get read correctly by a scanner built by a different company. Roughly 41% of Americans now live in a state with an active mDL program.

Share

Availability and use are two different numbers, though. By the end of 2025, only about 7% of eligible cardholders had actually activated an mDL, and adoption varies a lot by state: 21% of licensed drivers in Arizona, 1% in Alaska.

The format also varies. Some states put their mDL in Apple Wallet, Google Wallet, and Samsung Wallet. Others, like Louisiana, Virginia, New York, and Utah, only offer a standalone state app. Delaware and Mississippi issue digital IDs that don’t follow the ISO standard at all, which means TSA doesn’t accept them.

A Delaware resident can hold a state-issued digital ID and still be asked for a physical card at the airport.

Who’s actually building this

Four different organizations each manage a separate piece of this, on their own schedule.

State DMVs decide which technology to issue and which standard to follow. Apple and Google negotiate wallet integration with each state individually, one agreement at a time. TSA decides which state-issued digital IDs it will accept at checkpoints, currently reading them at more than 250 locations, while still telling travelers to bring a physical ID as backup.

And separately, the General Services Administration runs Login.gov, the identity system people use to access federal benefits and services online, which is on track to accept mDLs by March 2026, on its own roadmap.

These four efforts aren’t formally connected to each other. Each one answers to a different set of rules and a different timeline.

Share

You can see this in the law itself. The REAL ID Act, passed in 2005, was written with only physical cards in mind. Digital licenses technically weren’t compliant with it until the Department of Homeland Security issued a rule in late 2024 waiving that requirement on a state-by-state basis. The technology was already in use before the legal framework caught up to it.

Where things stand on coordination

A few specific things are worth tracking as this continues to roll out:

The ISO/IEC 18013-5 standard is shared, but nothing requires every state to follow it. Delaware and Mississippi’s non-compliant apps are an example of that.

TSA, GSA, and DHS are each responsible for a different part of digital identity, and there isn’t a shared roadmap linking their timelines. A GAO report from July 2026 noted that GSA still has work to do on identity verification within Login.gov itself.

Share

Privacy protections in the mDL standard are largely optional rather than required. The standard supports a feature sometimes called “phone home,” where a verifier’s check-in can be logged back to the state that issued the credential. Groups including the ACLU and EFF have raised this as a concern and have been pushing to change the default, rather than have it addressed through legislation.

NIST updated its federal digital identity guidelines, SP 800-63-4, in mid-2025, tightening biometric requirements for federal systems. That guidance applies to federal systems. It doesn’t extend to how an individual state builds its own DMV app.

Where this fits into digital public infrastructure

There’s a term for what these pieces are supposed to add up to: digital public infrastructure, or DPI. The G20 defined it in 2023 as shared digital systems, built on open standards, that deliver services at societal scale.

Most DPI frameworks name digital identity as one of three core building blocks, along with payments and data exchange.

The US mDL system has some of the ingredients. ISO/IEC 18013-5 is the open standard. Apple, Google, Samsung Wallet, and verification companies all build on top of it.

What it doesn’t have yet is the piece that usually separates a working DPI system from a set of related programs: one accountable body coordinating the whole thing.

Share

In the US, state DMVs, TSA, GSA’s Login.gov, and NIST each operate under their own legal authority and their own timeline, and no single office is responsible for making the pieces work together.

That coordination piece is usually what comes next, if the US follows the pattern other countries have used. It tends to show up after the individual programs already exist, once enough states and enough use cases create pressure for a shared framework, rather than being designed in from the start. Login.gov’s mDL rollout in 2026 is one place that pressure could start to show up.

What this means

Digital ID in the US isn’t a single national rollout. It’s a set of separate programs, run by separate organizations, that happen to show up on the same phone screen. That’s a fairly normal way for US infrastructure to get built: state by state, vendor by vendor, without waiting on a single federal design.

For anyone managing a program where multiple organizations, vendors, or pieces of legislation are supposed to function as one thing, this is a useful case to watch. Im interested in the process of coordination and orchestration. It shows what a large, multi-owner rollout looks like while it’s still in progress, before all the pieces are fully connected.

Nicole

Subscribe now

Share

Leave a comment

Ashby’s Law holds everywhere, but what it demands of a IT program is not what it demands of a supply chain or a public health system. The variables that matter change. The constraints change. The people change. A pattern that’s reliable in one context does not transfer cleanly to another just because the underlying structure looks the same on paper.

That’s what nuance actually is. It isn’t a softer version of expertise, but what expertise looks like once it has been tested against enough specific, contradictory cases that you stop trusting your first read automatically. You develop a working suspicion of your own pattern recognition. That sounds like a weakness, but it’s closer to the sign that the thinking has become real.

I don’t think this comes from reading more frameworks. It comes from being wrong inside a domain enough times, in ways that cost something, until the models stop being ideas you hold and become reflexes you can’t fully explain.

That’s the gap between knowing systems thinking and having it. There’s no shortcut through it, only more contact with more domains.

Nicole

Subscribe now

Share

Leave a comment

Mine won’t look like most of them. I don’t read in one lane: systems theory sits next to behavioral economics, project management next to art history, geopolitics next to a book on how to ask a better question. It’s multidisciplinary by design. The eclectic mix is where the actual thinking happens: you borrow a lens from one field to see something you were missing in another. To learn more:

So here’s my honest answer to the question I get asked a lot: what should I actually read if I want to think in systems instead of tasks, plus the books and one website I go back to for reasons that have nothing to do with work at all. This is less a syllabus than a record of where I’ve drawn inspiration to think, be creative and understand the world.

1. Start here: the grammar of systems

When problems come from feedback loops, delays, and structure.

Thinking in Systems, by Donella Meadows is where I’d send anyone first. Meadows spent her career studying why good intentions produce bad outcomes at a planetary scale, and this book distills that into something almost embarrassingly simple: structure determines behavior more than intention does. Stocks, flows, feedback loops, leverage points: once you see them, you can’t stop seeing them in your own program.

Her line that’s stuck with me longest: stay humble, stay a learner. I’ve started using “I know I don’t know” as a working stance instead of a confession, it’s the posture that lets you keep updating the model instead of defending it.

The Fifth Discipline, by Peter Senge is the organizational companion to Meadows. Where she gives you the physics, Senge gives you the practice, the personal mastery, mental models, shared vision, team learning, all in service of the fifth and hardest discipline, seeing the whole instead of the parts. His eleven laws are worth the price of the book alone.

Complexity: A Guided Tour by Melanie Mitchell is the book I hand to anyone who thinks “complex system” is just a vibe. Mitchell explains how large-scale, organized, adaptive behavior emerges from simple rules followed by many individuals, ant colonies, immune systems, the internet. It’s the most rigorous survey on this list, and the one that gives Meadows and Senge their scientific backbone.

Share

2. Why complex systems fail, and why we can’t predict them

When accidents aren’t anomalies, they’re architecture.

The Black Swan by Nassim Nicholas Taleb is the one that made me distrust my own risk register. Taleb’s argument is that rare, high-impact events drive outcomes far more than we admit, and that we build tidy narratives after the fact to explain what was genuinely unpredictable beforehand.

Thinking, Fast and Slow by Daniel Kahneman is the cognitive science underneath all of this. System 1 is fast, intuitive, and the reason we build bad risk registers in the first place; System 2 is slow, deliberate, and usually too lazy to double-check System 1’s work. Once you know the biases by name, you start catching them in status meetings.

3. The state, seen and unseen

When categories, metrics, dashboards, and systems quietly shape reality.

Seeing Like a State by James C. Scott is the one that reframed how I think about my own work inside government. Scott studies why centrally managed plans misfire, and lands on this: top-down schemes fail when they impose a simplified, “legible” view of the world that erases the local, practical knowledge that actually keeps things running. Every standardized data model I’ve ever built has this tension baked in.

The Fifth Risk by Michael Lewis is the most readable book on this list, and maybe the most quietly devastating. Lewis walks through the Departments of Energy, Agriculture, and Commerce to show how much invisible, unglamorous expertise keeps a country from falling apart and how fragile that expertise is when leadership doesn’t understand or respect it.

Recoding America by Jennifer Pahlka is the closest thing to required reading for anyone doing digital public infrastructure work right now. Pahlka argues that government’s technology problem is really a culture problem: a rigid, rule-following posture that prioritizes conformity to process over actually serving people.

Prisoners of Geography by Tim Marshall rounds this section out by zooming all the way out. Marshall uses ten maps to show how mountains, rivers, coastlines, and borders shape what nations can and can’t do, regardless of policy or ideology. If you’re working anything cross-border or multilateral, this is the fastest way to understand why some constraints are physical, not political.

Share

4. Getting big things done, and who’s actually in charge

When execution depends on structure, not heroics.

How Big Things Get Done by Bent Flyvbjerg and Dan Gardner is the megaproject research I wish existed when I started this career. Flyvbjerg’s data-backed rules: plan slow, act fast; think right to left from your goal; find your Lego, meaning build big things out of small, modular, testable pieces. Read like a corrective to almost every failure mode I’ve watched play out in real programs.

Powered by Projects by Antonio Nieto-Rodriguez pushes the argument further: every organization is already project-driven, whether or not its leaders have caught up to that fact. Nieto-Rodriguez lays out what it actually takes to lead a project-driven organization of decentralized decision-making, ruthless prioritization, sponsors who show up rather than delegate.

Team of Teams by Stanley McChrystal is the book behind an opinion I’ve been building toward for a while: the project manager shouldn’t be the singular protagonist of the story. McChrystal describes how JSOC beat a faster, more networked enemy by pushing decision rights out to the edges, trading the “chess master” model of leadership for the “gardener” model. Leadership becomes distributed across a network instead of concentrated in one role.

Share

5. Thinking better: creativity, logic, and sharper questions

When language, metaphor, and reasoning change what you can see.

Inside the Box by Drew Boyd and Jacob Goldenberg makes the case against “think outside the box” entirely. Their Systematic Inventive Thinking method, five techniques including subtraction and division argues that constraint, not blank-page freedom, is what actually produces breakthrough ideas.

Think Wrong by John Bielenberg, Mike Burn, and Greg Galle is a field guide for breaking the status quo on purpose. Six practices: Be Bold, Get Out, Let Go, Make Stuff, Bet Small, Move Fast. Includes drills to run with your team. This book stays on my nightstand when I need a burst of other thinking.

The Medici Effect by Frans Johansson is where I go for the case that the best ideas live at the intersection of fields, disciplines, and cultures, not deep inside any one of them. Johansson calls that intersection the place where existing concepts recombine into genuinely new ones. I found this book strolling through YouTube shorts. It’s basically the intellectual justification for why a systems thinker should also read art history. My opinion.

Being Logical by D.Q. McInerny is the shortest, most useful refresher on actual reasoning I’ve found. Not sure how I came about this book but glad I did. It’s a guide to spotting your own fallacies before someone else does, false dilemmas, ad hominem, the whole list and written with almost no jargon which I appreciate.

The Art of Asking Essential Questions by Richard Paul and Linda Elder is a small book that does one thing well: it teaches you to tell the difference between a question that surfaces assumptions and one that just performs curiosity. Socratic principles, stripped down to something you can actually use in a stakeholder meeting.

Share

Deep Work by Cal Newport is the practical precondition for everything else on this list. None of the books above get read, and none of the systems thinking actually happens, without the ability to sit in distraction-free concentration long enough to follow a hard idea to the end. Newport’s distinction between deep work, which creates real value and is hard to replicate, and shallow work, which just feels productive, is the filter I now run most of my calendar through. His four rules: work deeply, embrace boredom, quit social media selectively, and drain the shallows are less about productivity theater and more about protecting the exact kind of attention that systems thinking requires. Val’s work can be vigorous at times but I often come back to his book when I fall off.

6. Seeing like an artist, and where I steal my style

When aesthetics teach you a way of looking.

How to Read Paintings by the art writer Christopher P. Jones, the first in his Looking at Art series. Jones takes fifteen to twenty paintings at a time and walks through what’s actually happening in them: the myths, the symbolism, the choices the painter made and why. I’ve gone on to read the rest of the series and have learned so much.

The Marginalian isn’t a book, it’s the website I model this whole publication after. Maria Popova has run it alone since 2006, weaving science, philosophy, poetry, and art into long-form essays that never stay inside one discipline - I like that. She’s an excellent writer. One of my favorites to read.

Share

7. How to live

When the system worth studying is your own life.

How to Live by Sarah Bakewell is the one on this list that isn’t really about work at all, and that’s exactly why it’s here. Bakewell structures Montaigne’s life around the question he kept circling in his Essays, how do you live and pulls twenty different answers out of him: don’t worry about death, pay attention, read a lot and forget most of it, reflect on everything and regret nothing. Similar to Seneca, Montaigne invented writing about yourself as a way of thinking, four hundred years before anyone called it a blog, and Bakewell’s own “though I don’t know” runs through the whole book the same way it runs through mine.

Why this shelf, and not another one

None of these are project management books in the traditional sense, even the ones explicitly about projects spend more time on human judgment than on Gantt charts. What ties the whole shelf together is the lens: how do operators inside complex systems see structure, anticipate where it will break, and make moves under constraint, and how do you explain any of that to someone who’s never had to.

Enjoy,

Nicole

Subscribe now

Share

Leave a comment

That’s the tension sitting underneath two recent pieces on organizational change, and it’s worth naming directly, because most change efforts get stuck exactly here. Leadership wants holistic transformation. The org can only actually move locally. The question is whether those two things are in conflict, or whether local is just what holistic looks like up close.

The spreadsheet problem

Start with decision rights. Harvard Business Review’s Lindy Greer, Jennifer Jordan, and Maxim Sytch spent time inside more than 100 companies studying why tools like RACI, the framework meant to clarify who’s Responsible, Accountable, Consulted, and Informed on a given decision so often fail in practice (HBR). Their diagnosis isn’t that RACI is treated as a static artifact: a senior leader fills out a spreadsheet, hands it down, and expects compliance.

It doesn’t work that way. People don’t play assigned roles just because a document says so. Buy-in has to be built, and it has to be built at the level where the actual decision lives, not declared from three layers up.

Share

Their fix is granular almost to a fault. Clarify the specific goal before assigning roles. Co-create the RACI with the people who’ll live with it. Write out what “accountable” and “responsible” actually mean in behavioral terms, because half the time people in the same room are using the words differently. Revisit the assignment as the decision evolves. None of this is a company-wide initiative. It’s a discipline applied one decision at a time, over and over, until it becomes how the place runs.

The pilot problem

Now put that next to a different piece of research: a qualitative study out of Comenius University Bratislava on “systemic project management”: a framework that folds soft factors like communication, trust, and team dynamics into project management, instead of treating time, cost, and scope as the whole story (Schneider & Papula). The researchers ran focus groups with experienced project managers at a global automotive supplier, and the findings on adoption are the interesting part.

Systemic project management is, by design, a holistic idea. It wants the whole organization thinking in terms of feedback loops and interdependence, not siloed metrics. But the experts in the study were unanimous on how you actually get there: you don’t roll it out. You pilot it in one small team, generate a real result, and use that as evidence to expand, “gradual integration along the entire value chain,” in the paper’s words, because systemic changes touch every project phase and no one adopts a complex theoretical framework on faith.

The paper leans on Niklas Luhmann’s systems theory to make the deeper point: acceptance isn’t a decision anyone makes once. It happens when a new way of thinking gets “anchored in organizational communication and continuously reproduced in everyday work.” Not approved. Reproduced. Repeatedly, locally, until it’s just how people talk to each other.

Same mechanism, two domains

Neither of these findings is really about RACI or about automotive project management. They’re about the same underlying mechanism showing up in a governance tool and in a cultural framework: systems don’t change because someone at the top declares a new state. Change happens because a local pattern gets repeated with enough fidelity, in enough places, that it becomes the system’s new default behavior.

Share

This is not a new idea in systems thinking: it’s basically how self-organization works in any complex adaptive system. Global order is an emergent property of local rules, not something imposed from outside the system. What’s useful about lining up an HBR governance article with a systemic-PM academic paper is that you get the same mechanism validated in two completely different registers: hard-nosed management consulting on one side, systems-theory academic research on the other. When practitioners and theorists converge on the same answer from different directions, that’s usually a sign the answer is actually right, not just fashionable.

Where this breaks organizations

Most change efforts fail by picking one end of this and ignoring the other.

Some organizations over-index on the local and never generalize. They run the pilot, get the result, write the case study and then nothing spreads, because no one built the muscle for reproducing the pattern elsewhere. The HBR authors flag this exact failure: teams look at a beautifully co-created RACI once and never touch it again, so it calcifies into exactly the static artifact it was supposed to replace.

Others over-index on the holistic and skip the local entirely. Leadership announces a transformation with new values, new operating model, new framework without ever building the specific, repeatable local behaviors that would actually produce it. The systemic PM paper’s experts are blunt about this: you cannot convince an organization of a holistic idea with a slide deck. You need “measurable variables such as cost and time savings” from a real pilot before anyone with budget authority will move.

Share

The failure mode is almost never “we tried to change locally and it didn’t add up to anything.” It’s usually one of the two half-measures above: local without a growth path, or holistic without a starting point small enough to actually work.

The actual takeaway

If you’re trying to shift how a team, a program, or how an organization operates, the sequencing that both pieces converge on looks something like this:

Pick a real, bounded decision or workflow, not an abstract goal. Build the new behavior with the people who’ll actually use it, not around them. Get it right in that one place before you generalize it. Then treat the generalization itself as an ongoing communicative act, not a one-time rollout because the moment people stop actively reproducing the new pattern in conversation and practice, it reverts to whatever the org defaulted to before.

Holistic change was never the alternative to local iteration. It’s what local iteration looks like once you’re standing far enough back to see the whole system doing it consistently. I learned a lot from these two articles. Give them a read.

Nicole

Sources:

Greer, L., Jordan, J., & Sytch, M. (2026). What Companies Get Wrong About Decision Rights. Harvard Business Review. https://hbr.org/2026/07/what-companies-get-wrong-about-decision-rights

Schneider, A., & Papula, J. (2026). Systemic Project Management and the Impact on Soft Factors in the Organisation. Systemic Practice and Action Research, 39:3. https://doi.org/10.1007/s11213-025-09755-w

Subscribe now

Share

Leave a comment

Donella Meadows had a phrase for how she treated her own models: dance with the system, don’t fight it. Watch what it does, update what you believe, stay loose. That’s the spirit I want to bring back to this thesis eleven months later. So here’s the update of one piece of evidence from the ground, and one from the aggregate.

The bottom-up signal

A few days ago I posted a note with a screenshot from a current (as of this posting) Twitch job listing of a “Preferred Qualifications” section, nothing more:

Twitch, preferred qualifications highlighted: “Comfort with systems-thinking and process design — you’ve built or improved the frameworks a team relies on to operate, by meeting people where they already work.”

It doesn’t prove a trend by itself. But I have more.

Share

Other companies making the same move

Government and international policy work has used this vocabulary for years. Defra, the UK’s environment department, runs an entire Systems Research Programme to navigate “complex, cross-cutting and interdependent policy issues” (UK Government job listing).

“Systems thinking puts world leading evidence at the forefront of Defra’s strategy and decision making. This multidisciplinary and research-led approach to problem solving is already shaping innovative and well-informed solutions to some of the UK’s greatest environmental challenges.”(Department of Environmental, Food and Rural Affairs, UK)

The World Resources Institute is hiring a Systems Transformation Policy Lead to work the “policy design… systems thinking, and cross-sectoral coordination” angle on Indonesia’s food economy (WRI). None of that is new as complexity has always been the native language of policy work.

What’s new is who else is reaching for the same skills.

Mercury, the fintech, is hiring a Staff Visual Designer for its Design Systems team and names systems thinking as a requirement outright… “comfortable balancing expressive visual design with the pragmatic needs of a scalable design system for a data rich product” (Mercury, July 2026). This is a design job, not an engineering one. Even visual craft now has to answer to a system, not just a screen.

Nexthink, an enterprise IT platform, wants a Senior Product Manager who brings “systems thinking: strong analytical skills with the ability to structure ambiguous problems, define scalable solutions, and connect technical trade-offs to business value” (Nexthink, December 2025), explicitly to help the platform absorb “AI-first use cases” without the foundations cracking under the added weight.

enGen, the healthcare technology arm behind Highmark’s dental plans, requires “strong systems thinking” for a Business Systems Analyst who has to trace a single issue across data, configuration, and system behavior at once (Highmark Health, via Built In). Healthcare’s complexity was never in question. What’s notable is a mid-level analyst role naming the skill outright instead of assuming it.

Share

Then there’s System, a healthcare-focused public benefit corporation that built the vocabulary into its identity. Its own description reads: “System builds software to help the world see and solve anything as a system.” The general application for its operations and strategy track doesn’t list systems thinking as a nice-to-have. It opens with “Welcome systems thinkers” (System, June 2026).

Two more names belong on this list, and they’re the two biggest.

Amazon doesn’t just require the skill, one posting actually says what it’s for. A Scaled Abuse Specialist role on Amazon’s Trust and Store Integrity team exists, in the company’s own words, to “protect Amazon customers and stores by applying systems thinking to understand how networks of users interact with multiple services” (Amazon Careers). That’s the clearest statement in this entire list of why the skill matters, not just that it does: fraud doesn’t happen inside one service, it happens in the seams between services, and somebody has to be able to see the seams to catch it. The same logic shows up again in Amazon’s sustainability hiring, where a Senior Sustainability Specialist must “apply systems thinking to complex, fast moving problems while dealing with uncertainty and data gaps” (Amazon Careers), a different domain, the same admission that no single team can see the whole picture alone.

Microsoft is asking for the same aimed at product decisions instead of fraud patterns. A Senior Product Manager role on Microsoft Teams asks candidates to “champion a systems-thinking approach to product development, considering the downstream implications of core design decisions on the broader Teams ecosystem” (Microsoft Teams PM listing), because one change to the core messaging engine ripples across chats, channels, and meetings for hundreds of millions of people at once. A separate Microsoft posting, for a PM shaping the Facilitator agent inside Teams meetings, frames it even more plainly: the job is for someone who enjoys “ambiguity, systems thinking, and building AI experiences that must work reliably in the real world.”

Share

Six companies, six very different roles: a design team, a product platform, a healthcare back office, a company’s entire reason for existing, a fraud investigations unit, and the team deciding how an AI agent behaves in a meeting. The line connecting all of them is the one from the Twitch posting. None of these roles are being asked to optimize one part, one component, one area. The ask is to answer for what happens when the parts start talking to each other, and in Amazon’s case, to say so directly instead of leaving it implied.

The cost of skipping it

None of this is only about which skill gets listed in a posting. There’s a harder case underneath it, and it comes from a peer-reviewed paper, not a job board: companies that skipped systems thinking didn’t just miss a trend. They lost the market. I wrote about this in several articles.

Researchers at Worcester Polytechnic Institute catalogued a set of well-known business failures that trace back to exactly this gap (Monat, Amissah & Gannon, Systems, 2020). The pattern repeats often enough to stop looking like coincidence.

Share

Microsoft built the Zune to compete with the iPod in 2006. The hardware wasn’t the failure. Apple had built the licensing deals, the payment infrastructure, and iTunes built the entire apparatus that made owning an iPod worth it. Don Norman put it plainly: “It is not about the iPod; it is about the system… No one seems to understand the systems thinking that has made Apple so successful,” as the paper quotes him. Microsoft matched the device. It never built the system the device was supposed to live inside.

Polaroid led the digital camera market by 1990 ahead of Sony, ahead of Kodak, then filed for bankruptcy by 2001. Leadership kept funding digital R&D through a hard-copy-print mental model, protecting a film business with 65% margins instead of following where the technology, and the customer, were actually headed.

BlackBerry held over 10 million subscribers and a $67 billion valuation in 2007. It kept building a secure email device while Apple and Samsung built a mobile entertainment system that happened to also send email. By 2013, BlackBerry posted a $1 billion loss on unsold inventory nobody wanted.

The oldest example in the paper predates all of them. Swiss watchmakers controlled 65% of the world’s watch sales through the 1960s, on the strength of mainspring-driven movements they’d refined for generations. In 1968, their own researchers invented the quartz movement, battery-powered watch with no mainspring at all. The industry looked at its own invention and decided traditional watchmaking would simply outlast it. They didn’t even patent the idea. Seiko did. By 1978, the number of Swiss watchmakers had dropped from 60,000 employees to 10,000, and Swiss market share had fallen below 10%.

None of these companies were short on talent or capital. Each optimized a part while missing what the part sat inside of, the same distinction this newsletter keeps circling back to. Read against that history, the postings above stop looking like a buzzword rotation. They look like companies writing down, in a job requirement, a lesson several of their competitors already paid for in market share.

Share

The top-down signal

Zoom out further, and the aggregate data is triangulating on the same point from a completely different altitude.

• Dice’s mid-2026 tech jobs report lists Systems Thinking among the skills with 250%+ year-over-year growth in postings in the same bracket as Agentic AI, AI Agents, and AI Infrastructure. It isn’t rising alone. It’s rising with the agentic AI buildout (Dice, 2026 Tech Jobs Report).

• LinkedIn’s Skills on the Rise 2026 list singles out systems thinking specifically for program and project management roles, describing it as the ability to “see upstream and downstream dependencies and build holistic solutions, especially when legacy systems lurk” (LinkedIn News).

• The World Economic Forum’s Future of Jobs Report 2025 named the structural drivers directly: the expansion of AI and big data, and the growth of autonomous systems that require someone managing the interface between human judgment and machine action (World Economic Forum).

• Coursera’s learning data shows hours spent on systems thinking courses climbing since 2022, with a sharper jump starting in 2024 — professionals were feeling for the leverage point before most job descriptions had language for it (Coursera / WEF, New Economy Skills report).

• McKinsey’s late-2025 research found demand for AI fluency grew nearly sevenfold in two years, with demand for complementary skills like process optimization and quality assurance rising right alongside it — because once AI is doing pieces of a workflow, someone still has to hold the whole loop together (McKinsey).

Top-down and bottom-up rarely agree this cleanly. When they do, it’s worth taking seriously.

Share

What this actually means

Meadows spent a career arguing that the leverage isn’t in the parts, it’s in the structure connecting them: feedback, incentives, the rules nobody wrote down but everyone follows. Read the postings with that lens and “systems thinking” as a qualification decodes into something specific. It rarely means the candidate has read a systems theory textbook. It means the employer wants someone who can:

• Trace second- and third-order effects across teams or tools, not just execute inside their own lane

• Improve the operating structure a team runs on, rather than just work within it

• Manage the handoff between human judgment and automated or AI-driven steps, now that “the system” includes non-human actors

• Translate between departments or domains that don’t naturally share a vocabulary

That’s the difference between a local move and a system stance, applied to a career instead of an org chart. Analytical thinking optimizes your lane.

Look closely at how these postings actually phrase the requirement, and something else shows up: none of them ask for systems thinking in place of analytical rigor. Amazon’s Sustainability Specialist role requires “strong analytical skills and the ability to apply systems thinking to complex, fast moving problems” not one or the other, both, in the same sentence (Amazon Careers). Nexthink’s listing pairs them the same way, naming “systems thinking: strong analytical skills” as a single qualification rather than two competing ones (Nexthink). LinkedIn frames it as what analytical thinking misses on its own: the thing you need “especially when legacy systems lurk” (LinkedIn News).

That’s closer to the original argument than a replacement would be. These companies aren’t demoting analytical thinking. They’re writing down, in the same line, that it isn’t sufficient by itself — which is the claim from last August, restated by people who have never read the piece.

Share

Where the model stands now

I don’t think the data settles the argument outright. WEF’s own ranking still puts analytical thinking above systems thinking as the top core skill employers name (World Economic Forum). So the strict claim, systems thinking before analytical thinking, is still the harder position to hold, not the consensus one.

What’s changed since August is the direction of travel. The growth curves, the plain-language postings, a streaming platform quietly asking content moderators for the same fluency a systems engineer would need, Amazon naming the exact fraud mechanics the skill is meant to catch, a documented trail of companies that paid for skipping it: none of that existed as evidence eleven months ago. I’m not calling the argument proven. I’m updating the model with what the system just told me, which is the only honest way to hold a thesis like this one.

Your turn

I’m building a running file of postings where the language is doing more work than the job title suggests. If you’ve seen “systems thinking,” “systems-level,” or “holistic frameworks” show up somewhere unexpected, put it in the comments.

Nicole

Subscribe now

Share

Leave a comment

That’s a strange kind of freedom, and it isn’t the same as talent. What he had was something closer to a missing wall, what Frans Johansson, in The Medici Effect, calls a low associative barrier. Most people’s minds sort ideas into bins labeled by discipline or culture, and moving between bins takes a conscious, effortful shove. Some people’s minds don’t build the bins in the first place. The ideas just sit together, undivided, waiting to be combined.

(The local palate)

Johansson’s book is built around a claim that has become almost a cliché in innovation circles: breakthroughs happen at the intersection of fields, not within them. He names it after the Medici family, who spent the fifteenth century bankrolling painters, sculptors, philosophers, and engineers and putting them in proximity to one another in Florence. Out of that proximity came Brunelleschi’s dome, Botticelli’s mythologies, the rediscovery of classical philosophy, a concentration of genius so dense that historians still argue about how it happened at all. Johansson’s answer is that the Medicis didn’t do anything mystical. They just funded a room. Different disciplines showed up to the same dinners, the same workshops, the same patronage networks, and their proximity did the rest.

(Italian renaissance art)

It’s a good story and a useful frame. The intersection Johansson describes is geographic. It’s a place. You go to Florence, or a conference, or a company where the design team sits next to engineering, and the collisions happen because the walls came down. But if you look at the individual moments of insight inside that story, not the environment that made them possible, but the instant the insight occurred something else is going on. The room didn’t do the thinking. A person did. And what that person was doing wasn’t geographic. It was perceptual.

Share

Take Darwin. He wasn’t a bird expert. He was a geologist by training, on a ship chartered mostly to survey coastlines, and when he got to the Galápagos he collected finches the way an amateur collects things. A little haphazardly, without the taxonomy care an ornithologist would use to track which island each bird came from. Back in London, he handed the specimens to John Gould, an actual ornithologist, expecting confirmation of what he already half-suspected. Gould’s first reaction was unimpressed. He looked at the birds through the lens of his expertise and saw variation, not the outline of a mechanism. It took weeks for him to recognize that these weren’t varieties of the same finch, but were distinct species, shaped differently by different islands.

Here’s the part that matters: neither man could have produced the insight alone. Gould had the taxonomic precision Darwin lacked. But Darwin had something Gould didn’t: the freedom of not knowing the field’s assumptions well enough to be constrained by them. He looked at the birds the way an outsider looks at anything, without the professional reflex to sort them into existing categories. The intersection here wasn’t a location. Darwin and Gould weren’t in a room designed to produce collisions. It was two ways of seeing, brought into contact by circumstance, one of which had to notice something the other’s expertise made invisible.

Share

I’ve been circling this distinction for a while without naming it directly. In an earlier piece, I wrote about Hans Haacke’s 1971 show at the Guggenheim, the one that never opened. Haacke had built a body of work using publicly available real estate records to map the shell companies and slum properties tied to a member of the museum’s own board. The museum’s response wasn’t to critique the work. It was to cancel the retrospective six weeks before it opened. At the time, I framed this as proof that systems art had succeeded almost too well: it had stopped representing how power and capital move invisibly through institutions and had become an actual disruption of that movement. The cancellation wasn’t a failure of the work. It was the work completing itself.

(Places journal)

What I was really describing was systems thinking as a way of rendering invisible structures visible, ownership networks, information flows, incentive gradients that don’t show up on any map because maps aren’t built to show relationships, only positions. That’s a perceptual skill, not a location. You can stand inside the same museum, look at the same board of trustees, and see either a group of civic-minded donors or a web of financial interest with a museum attached to it. The room hasn’t changed. What’s changed is whether you’ve trained your eye to see the connective tissue instead of the individual nodes.

Share

Maria Popova is what this looks like when the room disappears entirely. For nearly two decades, first as Brain Pickings and now as The Marginalian, she has read across science, poetry, philosophy, and art, writing essays that treat those fields as if the borders between them were bureaucratic rather than real. She isn’t a scientist, a philosopher, or a historian. She pairs Thich Nhat Hanh with Erich Fromm, Whitman with Buddhist teaching, Nietzsche with Seamus Heaney, not because the subjects overlap but because the underlying shapes do. I found her work before I had language for what she was doing. Enchanted, first, by the writing itself, the way she would pull something from quantum physics and set it next to a nineteenth-century poet and the combination would land with a kind of quiet logic, like two things that had always belonged together finally introduced. “We read to learn how to live,” she has written, “how to love and how to suffer, how to grieve and how to be glad. We read to clarify ourselves.” Where Johansson asks how institutions engineer proximity, Popova shows the eye can do it alone, no dinner party required, just the discipline of reading structurally instead of by category.

Networked Knowledge

I made a related argument in a piece about moving concepts across domains, the practice of taking an idea that works in one field and deliberately testing it in another. I opened that piece with what I called an unforced error: a case where someone imported a framework from one domain into another without checking whether the underlying conditions still held, and the transplant failed in a way that was instructive precisely because of how it failed. The useful move isn’t noticing that two things resemble each other. It’s finding the point where the resemblance breaks, because that breaking point tells you more about both domains than the similarity does. Velcro is the cleaner version of the same idea. George de Mestral wasn’t a materials scientist. He came back from a walk with his dog covered in cockleburs, and instead of picking them off and moving on, he put one under a microscope and saw the hundreds of tiny hooks that had evolved to grab onto fur. He didn’t need advanced knowledge of textiles for the initial insight. He needed to look at a bur the way you’d look at a fastening mechanism rather than a weed. The translation from biology to industrial design happened at the exact point the hook-and-loop structure stopped being about the plant and started being a mechanical principle that had nothing to do with plants at all.

Share

This is the piece I think Johansson’s geography leaves out. The Medici court was necessary but not sufficient. Plenty of wealthy families in that era funded artists and never produced a Renaissance, because funding proximity is not the same as cultivating the eye that can use it. You can put a chemist and a choreographer in the same room for a decade and get nothing, if neither has practiced the discipline of treating their own field’s assumptions as contingent rather than fixed, of asking what a shape, a mechanism, a data structure, an ownership pattern actually is, stripped of the vocabulary that domain uses to describe it. That stripping-down is systems thinking’s real function. Not diagramming complexity for its own sake, but developing the habit of seeing structure instead of surface, so a Galápagos finch or a clinging bur or a spice cabinet reveals its underlying mechanism rather than its local costume.

There’s a risk here, which I’ve written about before and won’t soften: systems thinking can become its own trap, mistaking the map’s elegance for the territory’s truth. Seeing connections everywhere is not automatically wisdom. Sometimes a bird is just a bird. But checking whether a pattern is structural or merely aesthetic is itself part of the practice, not a flaw in it.

Share

The Medici family didn’t know they were building the Renaissance. They were patrons managing relationships, hedging their bets across a portfolio of talented people, most of whom they probably didn’t expect much from individually. The explosion of ideas that followed was an emergent property of proximity, not a plan. But proximity alone has been tried many times since, in accelerators and innovation labs and open-plan offices, without producing anything close to a Renaissance, because the room was never the active ingredient. The active ingredient was whether the people inside it had trained themselves to notice the hook under the microscope, the finch that didn’t fit the taxonomy, the real estate holdings hiding in plain sight in public records. The intersection is a way of looking you either bring with you or you don’t. The question worth asking is whether you’ve already trained your eye to see what’s colliding, right where you’re standing.

Nicole

Subscribe now

Share

Leave a comment

The closing track was called “Romance.” It is unhurried in a way that has nothing to do with laziness. A slow, warm, unbothered piece of music that sounds like it knows exactly what it is. Suzuki’s trombone does not perform for you. It just tells you something and trusts you to sit with it. Nothing about the performance was tentative. Nothing about the musicianship was in question. This was a finished, fully realized piece of work, made by a man who had already put in his ten thousand hours somewhere else, in someone else’s band, learning a discipline most people never bother to acquire.

There was no slow burn. No cult following quietly assembling in the background, passing the record between true believers. No whisper network of collectors keeping the flame alive. The album just sat there in a few crates, in a catalog entry, in the memory of the musicians who made it, while the rest of the world moved on to other things. Not rejected. Not controversial. Simply unheard. That particular kind of obscurity is harder to reckon with than failure, because there’s nothing to point to. The work was done. The silence wasn’t feedback. It was just silence.

Share

For close to forty years, that was the end of the story. Then, sometime in the 2010s, streaming platforms and algorithmic recommendation systems started doing something record stores and radio never could: they started surfacing things based on sonic similarity instead of marketing budget. Lo-fi playlist culture needed warm, groove-based, slightly melancholic instrumental music, and it turned out crates of forgotten Japanese jazz-funk records from the seventies were exactly that. “Romance” found an audience it never had. It now sits north of eleven million plays on YouTube. In 2023, Columbia’s Japanese catalog division released an official music video for it: a music video, for a song from an album that had been dead for decades. Suzuki had passed away in January 2020. He never saw any of it.

Share

The tidy version of this story is that the internet finally did justice to a forgotten genius. I don’t think that’s quite right, or at least it isn’t the interesting part. The music didn’t get better with age. It was just as finished in 1976 as it is now. What changed were the conditions around it, the infrastructure for a piece of music like this to find the specific ears that would actually want it. But here’s the part I keep turning over: I am one of those ears, and I know for a fact that if I’d heard “Romance” in my twenties, it would have washed right past me because I lacked the particular kind of tired, patient attention the song is asking for. Some things aren’t ready for you. Sometimes you’re not ready for them. Both can be true about the same object at different points in a life, and neither one is a flaw.

Share

I’ve been a project manager for a long time. Credentialed, tested, trained in the actual canon of waterfall in its rigid glory, agile in all its variants, the ceremonies, the frameworks, the whole apparatus that gets built around the idea that work can be scheduled into submission. I do it well most of the time. I got good at it in the way you get good at anything you do for fifteen years. The artifacts stopped being the hard part. Better templates. Tighter status reporting. More rigorous risk registers. It took me embarrassingly long to consider the possibility that the frameworks weren’t wrong. They were just incomplete. They gave me a vocabulary for tasks, dependencies, and timelines, and no vocabulary at all for the thing actually running underneath every project. The cadence, the politics, the feedback loops, the incentive structures nobody put in the charter, the gap between what a stakeholder says in a meeting and what hasn’t been said. Everything in my methodology was a description of the surface of the water. Nobody had given me a way to talk about what was moving underneath it.

Share

I came to systems thinking late, and I want to be precise about what “late” means here, because it wasn’t that the field was hard to find. I actually found it early. In the late 1990s, I sat through a workshop where someone handed out Peter Senge’s The Fifth Discipline. I read it. I found it genuinely interesting. And then I put it down and went back to my projects, because I could not find the edge where that book connected to the work I was actually doing. I wasn’t incurious. I wasn’t dismissing it. I just didn’t have enough scar tissue yet to know what question it was answering. The field wasn’t hidden. Meadows, Senge, decades of organizational theory, entire disciplines built around feedback loops and stocks and flows and second-order effects was all sitting there, available to me for most of my career, the way “Romance” was sitting on a shelf in a record store for forty years. I could have picked it up any time. First contact isn’t the same as readiness. It didn’t land until it landed, and when it finally did, it didn’t feel like acquiring a new skill. Learning a new tool feels additive: you have a slot, and now something occupies it. This was different. This was the difference between hearing a song and finally being ready to hear it.

And this is important: systems thinking is not a certification you complete and then possess. There’s no exam that confers it on you the way a PMP confers a credential. It isn’t a process you run. Pierre Bourdieu, writing about how people actually acquire the kinds of knowledge that change them, argued that embodied cultural capital, the kind that alters how you perceive and act, not just what you can recite cannot be transmitted instantaneously by gift or purchase, or bequest or exchange. It has to be grown from the inside. There is no shortcut. That’s exactly what systems thinking is: not a framework you layer on top of your existing practice, but a perceptual capacity that has to form slowly, under pressure, through accumulated experience. A way of seeing cannot be issued: it has to be earned through a specific density of lived, frustrating, contradictory experience. You need the scar tissue first. If someone had sat twenty-six-year-old me down and explained feedback loops and reinforcing dynamics with a whiteboard and a diagram, I would have nodded, taken notes, and understood absolutely nothing that mattered. The concepts need weight behind them, like actual memories of actual rooms where the stated plan and the real plan diverged or they stay decorative. Abstractions without scar tissue are just trivia.

Share

Once it does take hold, though, there’s no putting it back. I can’t watch a kickoff meeting anymore without seeing the org chart underneath the agenda. I can’t read a status report without noticing what it’s carefully not saying. It has made me considerably more useful in rooms where things are actually breaking down, and it has occasionally made me a more exhausting person to sit next to in a meeting that’s proceeding, on its surface, exactly according to plan. That’s the trade. I don’t think it’s optional once you’ve crossed it.

It’s the same thing that happens the first time “Romance” actually gets you, after years of other music passing through you without leaving a mark. The reference point doesn’t go away afterward. You hear its warmth, its patience, its total lack of need to prove anything, and then you start noticing its absence everywhere else. In the tracks that are straining, in the music that’s working too hard to be liked, in all the noise that mistakes urgency for substance. Suzuki wasn’t trying to be discovered. He made the thing, fully, and let it be exactly what it was, on its own schedule. That’s the part I go back to. Not the eleven million views. Not the forty years it took. The fact that once you actually hear it, really hear it, you can’t go back to not hearing it. You just start noticing it everywhere else it’s missing.

Nicole

Subscribe now

Share

Leave a comment

A chair in a room. A room in a house. A house in an environment. A city in its region.

Saarinen wasn’t making a philosophical point. He was describing a discipline of a specific cognitive move that separates design that works from design that is merely correct. The chair might be structurally sound, ergonomically tuned, beautifully finished. And still wrong, because it was designed in isolation from the room it would inhabit, the people who would use it, the purpose the space was meant to serve.

This is not a problem unique to furniture.

What the Principle Actually Says

The framing matters. Saarinen didn’t say consider the larger context. He said consider the next larger context. implying a specific, bounded move. Not infinite abstraction. Not “zoom all the way out until everything looks small.” One level up. The immediate containing system.

That precision is what makes it useful.

When you’re designing a door, the next larger context is the wall. When you’re designing a wall, it’s the room. Each step requires you to ask: what is this thing for, within the system that holds it? What constraints does that system impose? What would make this element serve the whole rather than just satisfy its own internal logic?

The failure mode Saarinen was naming is optimization at the wrong level of abstraction. You solve the problem in front of you so thoroughly that you create a new problem one level up, one that didn’t exist before you started, and that your solution actively caused.

Share

What This Looks Like in Architecture

The TWA Flight Center at JFK, completed in 1962, is the clearest example of Saarinen working from the next larger context outward. He wasn’t designing a terminal building. He was designing the experience of flight. The emotional register of departure and arrival at a moment when commercial aviation was still new enough to feel like an event.

The swooping concrete shell, the sunken conversation pits, the red carpeting, the tubular passenger tunnels. None of these make sense as isolated design decisions. It is coherent when you understand that Saarinen’s unit of analysis was the passenger’s psychological journey, not the building’s program requirements.

The building served its brief. But it was designed for its context.

Compare that to the vast majority of infrastructure built in the same era: functional, code-compliant, internally consistent, and experientially incoherent. Buildings that solved the problem of enclosure without asking what the enclosure was for.

Share

Where the Principle Travels (long time readers know I was moving to this understanding)

The reason Saarinen’s framing is useful beyond architecture is that optimization-at-the-wrong-level is a universal failure mode. It appears wherever complex systems are designed by people who are focused on their own component without sufficient visibility into the containing system.

In software development, this is the microservices trap. Individual services, each optimized for their own performance and maintainability, can compose into a distributed system that is slower, more fragile, and harder to reason about than anyone intended. Not because any single decision was wrong. But because no one was optimizing for the whole. Systems degrade not through failure, but through the accumulation of reasonable choices.

In organizational design, this is the classic silo failure. Each department optimized for its own metrics, producing outcomes that satisfy every internal scorecard while the organization as a whole loses coherence, speed, and the ability to deliver anything that requires coordination across units. The departments work. The organization doesn’t.

In policy, this is what happens when a regulation is written to solve a specific problem without modeling the adjacent systems it will disturb. The rule is internally logical. Its second-order effects undo the first-order benefit.

In personal decision-making, this is optimizing a career move for compensation without accounting for the organizational culture, or choosing a house for its features without thinking about the neighborhood, the commute, the social infrastructure around it. The thing is fine. The context makes it wrong.

Share

Why We Keep Getting This Wrong

Saarinen’s principle sounds obvious once stated. It is not obvious in practice, for a structural reason: we tend to have clearest visibility into the level we’re working at, and progressively less visibility into the levels above it.

The engineer sees the component. The architect sees the building. The urban planner sees the block. The policymaker sees the system. Each of these perspectives is real and legitimate. Each of them is also incomplete.

The problem is that authority and accountability are usually organized around the component level. You are responsible for the thing you’re building. You are not formally responsible for the system it enters. Which means the incentive structure actively discourages the move Saarinen is recommending.

Considering the next larger context costs time, creates ambiguity, and often produces constraints that make your immediate job harder. You might discover that the thing you’ve been asked to build shouldn’t be built at all — or should be built completely differently — because of what the containing system actually needs. That’s not a career-enhancing finding in most organizations. So the discipline gets skipped. Not from ignorance but from incentive.

The Practical Move

Saarinen’s principle becomes a usable tool when you treat it as a diagnostic question rather than a design philosophy.

Before committing to a solution, ask: what is the next larger system this will enter, and what does that system need from this component?

Not “what are all possible contexts?” One level up. The immediate container.

Then ask a harder question: does my solution serve that system, or does it serve my component at the system’s expense?

This question surfaces a specific class of problem that most analytical frameworks miss: the problem that doesn’t exist at the level you’re working at, only at the level above. The chair that works perfectly and ruins the room. The policy that solves its target problem and destabilizes the adjacent one. The feature that performs well in isolation and degrades the product. Infuriating.

These problems are invisible if you don’t look for them. They are obvious once you do. Most of the time we don’t see it until after the thing is already built or in process.

Share

The Discipline, Not the Insight

What made Saarinen’s work distinctive wasn’t that he had a clever principle. It’s that he applied it consistently, even when it made the immediate design problem harder. The TWA terminal is more expensive and more structurally complex than a conventional building of the same size would have been. The Arch required engineering solutions that didn’t exist when the project was commissioned.

The next larger context often demands more of you than the component alone would. That’s the point. The discipline is in not looking away from what the larger system requires, even when what it requires is inconvenient.

Most failures of design in buildings, software, organizations, policy, are not failures of execution at the component level. No, they are failures of framing at the system level. The thing was built correctly. It was built for the wrong context.

Saarinen’s move seems simple: before you build, look one level up. Ask what the container needs. Then design the thing to serve that, not just itself.

It won’t make the work easier. It will make it right.

Nicole

Subscribe now

Share

Leave a comment

I shared a short note about systems thinking: a quote from Diana Montalion’s *Learning Systems Thinking* and a line I joked should go on a t‑shirt:

“We could say that the most valuable quality of a systems thinker is they know they don’t know.”

What I meant was simple: systems thinking, as I practice it, starts with epistemic humility. Complex systems will always exceed your picture of them. You assume your understanding is incomplete, you expect to be surprised, and you treat your conclusions as provisional, something to be tested against how the system actually behaves over time.

Share

I wasn’t trying to make a metaphysical claim about knowledge. I was naming a stance.

How the conversation derailed

The reply that kicked things sideways didn’t engage that stance at all. Instead, it went after the phrase:

- “You know what you don’t know is an illogical statement.”

- “If you are a top‑down and bottom‑up thinker that statement should make you feel confused.”

- Followed by a description of systems thinking as a kind of higher‑dimensional, “3D or above” practice only “real” systems thinkers can do.

In other words, my “know I don’t know” got read as a literal logical claim, “you know what you don’t know” and then rejected as incoherent. From there, the conversation shifted into gatekeeping: who counts as a proper systems thinker, which tools they must use, and what level of abstraction they should be operating on. Remember we covered this with my article are we born with it or learned.

Share

By that point, we weren’t having the same conversation:

- I was talking about a posture toward your own models.

- They were talking about literal semantics and identity.

The words looked the same, but the object of concern had changed.

Two meanings of “I don’t know”

Part of the clash is that the same phrase is doing different jobs:

- In my post, “I know I don’t know” is shorthand for epistemic humility. I’m acknowledging that my mental model is partial and probably wrong in important ways, and that I need to keep learning from the system itself.

- In their comments, “you can’t know what you don’t know” is a literal paradox. If the unknowns are truly unknown, you can’t list them, therefore the sentence must be nonsense.

Those are technically compatible ideas. Of course I don’t have a complete inventory of everything I’m ignorant of. That’s not what the slogan is trying to say. It’s pointing at awareness of limits, not an exhaustive map of them.

Share

This is where Donella Meadows is useful. She keeps reminding us that in complex systems, “we can’t control systems or figure them out. But we can dance with them.” That dance assumes your understanding is incomplete and must be continually adjusted as you observe stocks, flows, feedback loops, and delays. The humility isn’t a bug; it’s the entry ticket. That’s the tradition I was drawing from.

When theory talk becomes status talk

There was another layer to the exchange that felt familiar: theory talk doing status work.

The pattern looked like this:

- Declare the phrase “illogical.”

- Invoke specialized language (top‑down, bottom‑up, 3D, binary practice).

- Conclude that if you don’t see the problem, you must not be a serious systems thinker.

It’s a very online move: use technical vocabulary to position yourself as holding the “real” version of a concept, and imply that disagreement is a sign of lesser understanding rather than a different frame.

Share

I’m not immune to that impulse either. But it’s worth noticing that once the conversation slides into “who really gets it,” we’ve left the terrain of systems and wandered into the terrain of identity.

What I was actually trying to say

If I strip my post back to its bones, it was really about three ideas:

- Complex systems are bigger than any one model.

You will never fully capture an organization, a policy regime, or a socio‑technical platform in a neat diagram. There will always be dynamics you didn’t anticipate.

- Your models are tools, not trophies.

The point of building a mental model isn’t to be “right” once, it’s to have something you can keep testing against what the system actually does, and then revise.

- Humility is a practice, not a personality trait.

“I know I don’t know” isn’t self‑deprecation. It’s a commitment to keep listening to behavior, to data, to people at different vantage points, so that your understanding can keep changing.

In that light, the line I liked from Montalion reads less like a slogan and more like a constraint: if you can’t tolerate the feeling of “I don’t fully understand this,” you’ll be tempted to pick a story and start defending it. At that point, no amount of systems vocabulary will help you.

Share

A practical move for sharing thinking online

The whole exchange taught me something useful about talking publicly about “how we think” in complex work.

When these conversations go sideways, a lot of the friction comes from people operating at different levels without saying so. One person is talking about stance, another about formal logic, another about identity or status.

The practical move I’m taking from this is simple:

- When you share a thinking tool or quote, name the level you’re speaking at.

That can sound like:

- “I’m talking about a stance here, not a precise logical statement.”

- “I’m using this phrase as shorthand for a kind of humility, not claiming to have an inventory of unknowns.”

- “I’m not defining who counts as a systems thinker; I’m describing one habit I’ve found valuable.”

Share

This doesn’t guarantee harmony. Some people are invested in the semantics fight. But it does three things:

1. It keeps *you* anchored in the system you were actually trying to describe.

2. It gives others a handle on what your words are supposed to be doing.

3. It makes it easier to recognize when a thread has left the territory you care about and when it’s time to, calmly, leave it there.

And if nothing else, it’s a reminder that online discourse is its own system, with its own feedback loops and incentives. Sometimes the most systems‑literate move is not to fix the comments, but to learn from how they behave and then, calmly, let it be.

Subscribe now

Share

Leave a comment

This field guide is for that stretch of time, when you can sense the structure fraying before anyone will admit the initiative is in trouble. It shows how to use AI as a sharp but obedient analyst to pull the real system into view, name the pattern early, and turn a mess of documents into a brief a senior person can actually act on.

What this workflow is for

The Systems Briefing Workflow is built for work that has already outgrown the normal tools people use to describe it. The weekly update is too thin. The risk log is technically correct but strangely unhelpful. Everyone agrees the initiative matters, yet nobody can quite explain why progress feels slower, messier, and more political than the plan suggested.

This is usually the point where people ask for better tracking, more meetings, or a cleaner deck. Sometimes those things help. Often they just make the surface of the work more legible while the underlying structure stays murky. The value of this workflow is that it helps you read the initiative at the level where the real difficulty lives: competing incentives, diffuse ownership, hidden assumptions, and decisions that have not actually been made.

Used well, the workflow produces three things. It gives you a clear inventory of what is actually in play. It gives you a first-pass read of the system itself: the actors, constraints, tensions, and likely failure pattern. Then it gives you a two-page briefing note that can support a decision, reset a conversation, or change the operating approach before the situation hardens further.

Share

Before the model enters

Start with one live initiative. Not a class of problems, and not a vague aspiration. The workflow becomes useful when the stakes are specific enough that you can point to the pressure in plain language: a launch that is slipping because decision rights are blurred, a transformation program that has too many sponsors and no real center of gravity, a cross-functional effort that looks coordinated until you sit in the meetings.

Before you ask the model for anything, write a short case frame. One paragraph is enough. What is the initiative. Why does it matter now. What has started to feel unstable. Who is the eventual reader of the brief. This is a small discipline, but it prevents the analysis from floating upward into abstraction. The point is to stay close to a real operating situation from the very beginning.

Read more

In my original piece, I drew a line between those three types of work: automated work, verified work, and accountable work. The new roles now appearing around us, forward deployers, human–machine collaboration leads, “ghostbusters” who hunt down bad processes, and corporate storytellers, live squarely in that third category.

As more of the producing, classifying, and optimizing shifts to machines, the scarce work moves upstream. The jobs machines cannot do are the ones that hold systems together.

Those are the roles this essay is about.

The promise behind the “fifth” industrial revolution

People use “fifth industrial revolution” or “Industry 5.0” to point to a simple idea: after a long stretch of chasing efficiency and automation, the focus is supposed to swing back to people.

Instead of asking only, “What can we automate?”, the better question becomes, “Where do humans and machines work side by side, and what does that look like in practice?” It is a design problem. It forces organizations to think about safety, resilience, and working conditions, not just throughput or headcount.

Share

What actually shrinks

When you look past the hype, the same pattern shows up again and again. Jobs that are made up mostly of repeatable, rule-based tasks start to thin out. This includes familiar clerical work, some forms of basic analysis and reporting, and narrow operational roles built around routine process execution.

By contrast, roles that sit closer to the messy edge of the organization do not disappear so easily. Project managers and other coordination-heavy roles are still very much needed, but their job descriptions have expanded. They are increasingly expected to manage risk, alignment, communication, and cross-functional dependencies, not just track schedules and deliverables.

So the useful distinction is not “this profession dies, that one survives.” It is “this role was written for a smaller, simpler system, and now the system has grown around it.” A job can stay in demand and still be too narrow for the world it operates in.

Subscribe now

The new integrator jobs

That helps explain the rise of unusual titles across technology companies and AI-forward firms: Forward Deployer, AI Accelerator, Human–AI Collaboration Lead, and even “Ghostbuster” roles designed to find broken processes, outdated decisions, and tools that slow everyone down.

Under the labels, these jobs have a common shape. They are dropped into real teams and workflows, where they translate between what technology can do and what the organization actually needs. They decide which tasks stay with people, which move into tools, and how to handle the disruption when systems change.

A Human–AI Collaboration Lead, for example, is responsible for defining frameworks for how people and AI systems work together to achieve business goals, improve performance, and support change across teams. That is not a narrow technical role. It is a role focused on coordination, judgment, and organizational design.

These people are not measured only by output. They are measured by whether the whole system becomes easier to navigate, more coherent, and more resilient.

What the language already says

It would be easy to overstate this point and claim that every one of these new jobs is formally branded as a systems-thinking role. That would not be quite true. But it would also be wrong to suggest there is no factual basis for linking this work to systems thinking.

Share

Some Industry 5.0 and human–machine collaboration writing says it directly. One Industry 5.0-oriented initiative describes the needed skill base this way: “Research and innovation and the associated cross-functional skills required are fundamental to, and supported by, Statistics, Systems thinking, Sustainability and STEM skills.”

A human-centric leadership piece on the Fifth Industrial Revolution is even more explicit: organizations “need systems leaders who exemplify empathy and emotion, and combine that with critical thinking to bring diverse people together to problem-solve in volatile, complex environments,” and it argues for developing “Systems Thinking” alongside design thinking, agile thinking, and human capital.

A separate article on human–machine collaboration and the future of work makes the same point in slightly different language, arguing that organizations need a workforce that “is highly collaborative, and consists of critical, systems-based thinkers.”

Even where the label is not used, the capability is often described. One straightforward definition puts it this way: “A systems thinker is someone who is able to look at a complex system and consider its interconnectedness and interdependencies, not just its isolated components.”

Share

That definition is very close to what these emerging roles are being asked to do in practice. They sit between teams, tools, workflows, incentives, and decisions. Their job is not only to optimize a task, but to make the whole arrangement work.

The capability underneath the titles

If these roles sound vague, it is because the underlying capability rarely appears in job frameworks by name. In practice, they ask people to do what systems-oriented thinkers are trained to do: understand how people, processes, tools, data, and incentives interact in the real world.

To hold a system together, a person needs to notice repeated patterns, understand how one local fix creates downstream effects, and ask what structure keeps producing the same outcome. They also need to turn those patterns into usable rules, clearer responsibilities, and better feedback loops that other people can actually work with.

And then there is the part many organizations still underestimate: explaining the system. The person doing this work has to tell a coherent story about why change is happening, what problem it solves, and how people inside the organization should understand their role in it. That is one reason narrative skill and whole-system judgment increasingly travel together.

Some employers now explicitly mention systems thinking in job postings, especially in strategy, design, operations, and transformation work. Many more describe the behavior without using the label, asking instead for end-to-end ownership, cross-functional leadership, comfort with ambiguity, and the ability to connect the dots across teams.

Share

Why storytelling belongs here

The rise of storytelling roles is not a side trend. Companies such as Netflix explicitly describe parts of their content, communications, and marketing organizations as storytellers, and broader reporting has pointed to increased demand for storytelling skills across firms trying to shape their narratives directly.

In an environment where content is cheaper to produce and automation touches more of the business, meaning becomes harder to hold onto. Someone still has to explain what is changing, why it matters, and what people are being asked to trust. In that sense, storytelling becomes part of the operating system, not just a layer of polish applied after the fact.

Good storytelling is what keeps technical change from becoming organizational fog. It gives people language for the change they are living through and helps institutions preserve legitimacy while they redesign work.

What these jobs are really hiring for

Very few of these job ads say “systems thinker” out loud. More often, they ask for end-to-end ownership, cross-functional leadership, sound judgment, change management, and the ability to connect the dots across teams, workflows, and tools.

That matters because it suggests the market is rewarding a set of capabilities before it has settled on one name for them. Many people are already doing this kind of work under other labels: program manager, strategist, operations lead, product lead, transformation lead, or storyteller.

Share

Back to the jobs machines cannot do

In my original piece, I argued that the real divide in the future of work is not between people who use AI and people who do not. It is between automated work, verified work, and accountable work.

That distinction matters even more now. Machines can draft, summarize, classify, schedule, and optimize. What they cannot do on their own is hold a system together, carry judgment across contexts, negotiate trade-offs between groups, or take responsibility for the consequences of change.

That work still belongs to people. It requires technical literacy, judgment, memory, negotiation, and narrative skill all at once. It asks someone to see the whole, shape the structure around it, and explain the change in a way other people can trust.

Those are the jobs machines cannot do. And increasingly, they are the jobs that reward people who know how to work across the whole system, even when the job description never quite says so.

Nicole

Share

Leave a comment

That framing is not wrong, but it is incomplete. In real organizations, the gap is usually not a shortage of thinking modes. The gap is a shortage of judgment about which mode to use, where to use it, and what part of the system is actually generating the problem.

Local moves and system stance

What lists like this capture well are local moves. A local move is a bounded mental operation applied to a decision, a paragraph, a problem set, or a meeting. Causal thinking helps trace relationships. Counterfactual thinking helps test alternatives. Bayesian and probabilistic thinking help reason under uncertainty.

What the list does not name is the broader stance that gives those moves coherence. Systems thinking is less a single move than a way of seeing interconnections, feedback, delays, incentives, and whole-system behavior over time. It is the difference between asking what decision was wrong and asking what structure made that decision likely.

Share

That distinction matters because local intelligence does not automatically produce systemic insight. A team can be full of smart people using sophisticated reasoning and still remain trapped inside the logic of the system they are operating in. They can update beliefs, compare options, and generate elegant hypotheses while never examining the incentive structure, governance model, or feedback loops shaping all three.

How the listed modes change inside a system

Several items in the carousel become more powerful once they are placed inside a systems frame. Causal thinking, for example, is often taught as tracing a line from one event to another. In organizational life, it becomes more useful when reframed as feedback analysis: how a metric drives behavior, how that behavior distorts the metric, and how the system then doubles down on the distortion.

Nonlinear thinking also shifts meaning once it leaves the classroom. It no longer simply means that effects are not proportional to causes. It means that trust can erode gradually and then collapse all at once, or that one more dependency can push a functioning team into a coordination spiral that did not exist a month earlier.

Recursive thinking becomes more concrete as well. The same risk posture that appears in an executive steering committee often reappears in miniature inside project reviews, change control practices, and even status reporting. The local pattern is often a small copy of the larger system logic.

Share

Bayesian and probabilistic thinking matter too, but not only in the formal sense of updating beliefs from evidence. In actual institutions, evidence arrives through people, incentives, silences, and signals. The question is not only what the data says, but what the surrounding system makes probable.

Integrative thinking, finally, is often praised as the ability to hold multiple perspectives at once. In practice, the hard part is not synthesis in the abstract. The hard part is synthesizing under real constraints such as compliance rules, budget cycles, legacy architecture, procurement timelines, and informal veto power.

The question beneath the list

In my recent article, The Reader Comment That Sent Me Down a Systems Thinking Rabbit Hole, pushed on a deeper question: do some people naturally think in systems, or is systems thinking something learned over time through practice and exposure to complexity? That question sits underneath the Instagram list whether it is acknowledged or not.

The carousel assumes these modes can be taught as discrete skills. But systems judgment often looks different. Many people seem to acquire it inferentially, through repeated contact with messy environments where consequences are delayed, incentives are misaligned, and visible problems are generated by invisible structures. They do not always learn it in a formal curriculum. They piece it together by living inside systems long enough to notice the pattern.

That raises a harder question. If systems judgment can be learned, why is it so rarely taught directly?

Why it is not taught directly

One reason is assessment. It is relatively easy to test whether someone can recognize a counterfactual, estimate a probability, or choose the strongest causal explanation from a short prompt. It is much harder to test whether someone can identify the level at which a problem actually sits, distinguish an actor problem from a rule-set problem, or trace how incentives and delays are producing recurring failure.

Share

Another reason is curricular structure. Traditional education is organized around subjects and discrete competencies. Systems thinking cuts across domains and often requires synthesis rather than segmentation. It asks learners to examine not only the problem in front of them, but also the conditions producing that problem, including the institutional logic of the classroom, organization, or policy environment itself.

There is also a political reason. Teaching systems thinking means teaching people to see perverse incentives, governance failure, performative metrics, and the gap between stated goals and operating reality. That is useful for understanding institutions, but it can be uncomfortable for institutions to normalize.

Systems judgment as the real high-level skill

The better way to reinterpret the original list is not to reject it, but to relocate it. These are not twelve equal, standalone forms of mastery. They are tools that become valuable when a person knows which layer of the system they are operating on and what kind of reasoning that layer requires.

At the actor level, heuristic or probabilistic reasoning may help interpret decisions made by specific people under uncertainty. At the interaction level, causal and nonlinear thinking help reveal reinforcing loops, friction points, and unintended consequences across handoffs or meetings. At the rule-set level, dialectical and integrative thinking help reconcile competing logics embedded in policy, governance, and incentives. At the environmental level, abstract and epistemic thinking help make sense of the larger context that defines what kinds of moves are even possible.

Share

That is why the missing mode is not simply systems thinking as one item added to the end of the list. The missing mode is systems judgment: the capacity to sense which mode to lean on, at which level of the system, and how to reconcile conflicting insights when they do not point in the same direction.

High-level thinking in the world outside the classroom is rarely about having more concepts on hand. Recognizing that isolated decisions are often downstream of structure, and that better thinking begins when the structure itself comes into view.

Nicole

Subscribe now

Share

Leave a comment