I’d venture most people who’ve heard the phrase ‘information architecture’ have done so in the context of designing website navigation systems. That’s understandable: The web is a huge deal and IA was exactly what it needed early in its development.

But IA has more to offer than its contributions to UX design. To understand why, consider its ultimate purpose. This is how I describe it: The purpose of information architecture is increasing agency by making systems more legible.

Let’s unpack this statement.

The word agency is loaded now. We talk of agentic systems to mean those powered by AI agents. But here, I mean ‘agency’ in its original sense: giving an actor (human or otherwise) scope to decide and act independently.

Systems are the scope we’re acting on. What is a system? A collection of parts that relate to one another in particular ways so that the whole can serve a purpose. A website is a system. So is a business.

Systems can have subsystems. Many websites are subsystems in service of broader business systems, which are in service of broader social systems. Architects are always aware of the broader context; we operate holistically. As Eliel Saarinen put it,

Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan.

IA makes systems more legible. That is, the actor who’ll use the system will be better able understand what to do with it to accomplish their goals.

Think back to a time when you had to use a complex, unfamiliar product. You scanned its user interface for recognizable labels and symbols, looking for the smooth handle. If you’re like me, the system’s illegibility led you to YouTube, the web, or an LLM for an explanation. IA fixes that — or at least aims to make the process less onerous.

To recap, the ultimate purpose of IA is increasing agency — enabling actors to make good choices — by making systems more legible. Let’s stress-test this claim against some real-world applications:

• A website’s navigation structure should give users recognizable labels that allow them to find their way to the part of the website that has the information they need. The user is the agent; the labels give them clear choices that allow them to make the right decisions about where to click.

• A spreadsheet gives an executive the information they need to understand how their part of the business is functioning. The executive doesn’t need all the data; that might drown the signal in noise. But the right data shown at the right time and place will allow them to make good business decisions.

• Your car’s speedometer tells you how fast you’re going, allowing you to remain compliant with traffic laws. Again, a car generates lots of data. Modern dashboards are carefully designed to put the most important front and center: speed, fuel/energy levels, etc. — ‘most important’ being the ones you need to make critical decisions.

• A map makes physical environments more understandable by collapsing their scale and details into a set of abstractions you can hold in your hand. Reading the map lets you make better decisions about which roads to take to get to your destination.

• A carefully structured prompt allows a large language model to work properly. You could point the LLM to a broad corpus, but that wouldn’t improve its performance. The point of ‘context engineering’ (which is awfully close to IA) is giving the LLM the right information at the right time with the right instructions so it produces useful outcomes.

One of the most common questions I’ve gotten post-LLMs is, “Why do we need information architecture now that we have chatbots?” This is old-school thinking. “For the world wide web” was a phase of information architecture’s development — just a phase. It’s never been more important to re-embrace the discipline’s broader origins and aspirations.

The Journal cited an excellent example:

Cursor recently ran an experiment to evaluate the cost of building a web browser from scratch. Doing the entire task on OpenAI’s GPT-5.5 cost a little more than $10,000. Using Cursor’s Composer coding model in combination with Anthropic’s Opus 4.8, cost $1,339.

The focus here is cost, but that’s not the only concern. The most intelligent models — those offered by frontier labs such as Anthropic and OpenAI — are closed and proprietary. That has implications for your business. For one, you risk becoming dependent on others for critical cognitive tasks — a strategic and privacy risk. If a provider can turn off the intelligence spigot (or, more likely, raise its price) you’re stuck.

The solution is breaking down jobs into tasks that can be done by a variety of models. Some tasks, such as planning, will require more powerful models. But many others can rely on cheaper, less powerful models. Open weight models are becoming a commodity: not only are they cheaper but also mostly interchangeable. Not happy with how a model is performing at a particular task? Switch it out.

This is how business has been organized forever. Some jobs require greater expertise and capabilities than others. For example, neurosurgery can only be successfully done by a very small number of people who have the necessary intelligence, training, and experience. On the other hand, cleaning the operating room can be done by someone with less training, expertise, and smarts. Hence, neurosurgeons earn more.

How do you determine the right mix of intelligences? Think of your AI operations as an “intelligence stack.” At the highest level, you have the vision and strategy for the system. At the bottom, you have particular one-off tasks that carry out system functions. In-between there are workflows with various degrees of complexity. All three levels call for different kinds of intelligence.

The goal is to bootstrap this stack by using expensive frontier models to design and implement the system and more commoditized models to operate it.

When developing the vision and strategy for the system, you’ll research competitors, build scenarios, and explore possibilities. These are open-ended tasks with uncertain outcomes; it’s hard to specify what good outcomes look like in advance. For this kind of job, you want the cleverest sparring partner you can buy.

The system you design to implement that strategy will include lots of frequent tasks that will likely require less clever models. For example, imagine your business responds to lots of RFPs. Each RFP must be triaged. Some will be a good fit, others irrelevant. Those that fit must be routed to the right people in the org, hopefully with draft suggestions on how to respond.

You could prompt a frontier model to analyze each RFP as it comes in, perhaps using a ChatGPT project or Claude Cowork space for context. But that would be costly. A better approach is to break down the process into discrete steps and assign particular tasks to models with lower capabilities. If you know what “good” looks like for each step (which is much easier to do at this level), you can architect model interactions for optimal performance in each step — much as you would when delegating tasks in the real-world.

This approach doesn’t just reduce costs, it also makes the system work more predictably. Without upfront architecture, frontier models must parse each task from scratch, leading to variance over time. A more structured approach can be tuned for the exact range of outcomes needed for each step in the process.

Because the system is modular, you can use different models at each step in the process. Higher-level tasks that require orchestration can use more expensive closed models, whereas granular tasks with predictable outcomes can use less expensive (or even free) models called from deterministic programs. You can also switch providers at various steps in the process, preserving optionality.

Using a mix of models also lets you adjust for latency. Some tasks require faster reactions than others. Smaller, less clever, models can often have lower latency than frontier models. And of course, you can also be more selective about what information leaves your network: open weight models running in your infrastructure preserve your privacy.

Sounds ideal, right? You use expensive (and proprietary) models sparingly to design systems that use cheaper, open models for the day-to-day. What’s the catch? It’s the same one we had before AI: you must define what “good” looks like beforehand and architect the system to deliver expectable results.

That’s not bad, as far as catches go. Thinking through your workflows will force strategic decisions. It makes more sense to automate some workflows than others, and some will be more critical to the business than others. Mapping and architecting the flows will let you focus on what matters.

Yes, architecture can be expensive and time-consuming. But frontier models make it faster and less expensive. (Thats part of the top layer of the stack.) They also allow us to make richer prototypes faster than before, reducing the risk of over-specifying complex systems upfront.

This modular approach can scale and improve as new models come in the market. Today’s frontier models will be tomorrow’s entry-level. When that happens, you’ll want to reconsider the mix. Whether you can will depend on how you structure your systems today.

How can craft help you gain traction? That was the question Harry and I explored in episode 41 of Traction Heroes.

I brought to the conversation a short reading from a book that had a big impact on my career, Chris Crawford’s The Art of Computer Game Design:

Games must be designed, but computers must be programmed. Both skills are rare and difficult to acquire, and their combination in one person is even more rare. For this reason many people have attempted to form design teams consisting of a nontechnical game designer and a non-artistic programmer. This system would work if either programming or game design were a straightforward process requiring little in the way of judicious trade-offs. The fact of the matter is that both programming and game design are desperately difficult activities demanding many painful choices. Teaming the two experts together is rather like handcuffing a pole vaulter to a high jumper; their resultant disastrous performance is the inevitable result of their conflicting styles.

More specifically, the designer/programmer team is bound to fail because the designer will ignorantly make unrealistic demands on the programmer while failing to recognize golden opportunities arising during the programming. For example, when I designed the game Energy Czar (an energy-economics simulation game), I did not include an obviously desirable provision for recording the history of the player’s actions. During the final stages of the game’s development, virtually everyone associated with the project suggested such a feature. From technical experience, I knew that this feature would require an excessive amount of memory. A nontechnical designer would have insisted upon the feature, only to face the disaster of a program too big to fit into its allowed memory size.

Another example comes from Eastern Front (1941). While writing the code for the calendar computations, I realized that a simple insertion would allow me to change color register values every month. I took advantage of this opportunity to change the color of the trees every month. The improvement in the game is small, but it cost me only 24 bytes to install, so it proved to be a cost-effective improvement. A nontechnical game designer would never have noticed the opportunity; neither would a non-artistic programmer.

This image of two handcuffed athletes greatly influenced how I understand design. Simply put, people without hands-on knowledge of a system’s capabilities and constraints shouldn’t be making critical decisions about those systems. (You can guess where I fall on the “should designers learn to code?” question.)

Of course, this applies to more than just designing software. Managers should understand how the organizations they manage deliver value — and not just in theory, but hands-on, on the field. The obvious challenge: delegation. You won’t be effective if you over-manage. But in today’s complex ecosystems, it’s easier to fall prey to abstraction than the opposite.

Where do you land on this spectrum? Please let us know in the comments on YouTube. (We’d love to build more of an audience there now that we’re sharing videos of the shows.)

Traction Heroes episode 41: Craft

We all work within intractably large and complex systems. How much agency do we really have? This was the question Harry and I explored on episode 40 of the Traction Heroes podcast.

Harry read a passage from Eric Ries’s new book, Incorruptible (which I haven’t read.) It starts by citing John Steinbeck’s story of depression-era farmers dealing with bank officers who’ve been rendered impersonal as agents of a large organization. Organizations are a kind of being:

Living things maintain boundaries between themselves and their environment, resources into energy. They grow, adapt, and reproduce. They exhibit behaviors that emerge from their parts but can’t be predicted by studying those parts in isolation. Most importantly, they display a will to survive that shapes every action they take. Organizations exhibit every one of these properties.

The organization is a superorganism that demonstrates emergent properties. Among these, is a kind of intelligence. This is the entity the farmers were interacting with through its agents.

We’ve all had experiences dealing with such complex emergent systems. One might feel disempowered when considering the organization forms part of a broader socioeconomic system that incentivizes it to act in particular ways.

Incorruptible sounds like an antidote to that kind of thinking. Our socio economic systems provide alternate structures and ways of being — and we can choose them: As Harry put it,

the default world that we’re in is just a construct. You really have an enormous amount of flexibility. You have many more degrees of freedom than you are probably aware of. It doesn’t serve the system to inform you of what those are because those degrees of freedom give you more control and give you more agency.

This conversation was empowering and energizing. As I said in the podcast, this book has moved up my queue — check out the show for more.

(On a separate note, this is the first episode we’ve released as a proper YouTube video. We’d love to know what you think — please comment in YouTube itself.)

Traction Heroes episode 40: Agency

The Kinetic Council invited me to join a panel with Abby Covert, Jessica Talisman, and Larry Swanson about the evolving role of information architecture in a world where AI exists. Things got salty! 🧂

Moore’s law was in full force in 1986. Hardware was getting more powerful, faster, and cheaper. Surely, some technology would come along to do the same for software. Brooks argued this wasn’t in the cards, since software is fundamentally different from hardware. For one thing, it’s of a different order:

The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract, in that the conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.

Specifying, designing, and testing this construct is difficult. The challenge isn’t implementation but design: “We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.”

Technical advances usually make development easier. No Silver Bullet traces the history of time sharing, unified programming environments, and high-level languages. Object-oriented programming was a promising new technology at the time and there were even rudimentary AIs in the form of expert systems. Brooks examines them and concludes they’re not enough.

Why? Because coding isn’t the hardest part of making software. Instead, the hard part is knowing what to build:

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

What will the system do? How will it serve strategic objectives? How will it enable better judgment and allow people to derive meaning from data? These aren’t implementation questions, they’re design questions. Somebody must define the “construct of interlocking concepts” that define the system, aiming for good fit between the system and the context it serves. LLMs can help, but they can’t replace human understanding and judgment, at least not yet.

Brooks calls out four inherent properties of modern software systems:

• Complexity: Software systems are among the most complex human constructs. They’ve only gotten more so as computers and operating systems have grown more powerful and capable.

• Conformity: Software solutions must conform to the goals, needs, constraints, and interfaces of the organizations that bring them forth. This is true whether it’s bought off-the-shelf or developed bespoke.

• Changeability: Anything that lasts does so because it’s able to adapt to changing conditions. Software is inherently more malleable than other complex designed systems, such as buildings.

• Invisibility: Whereas complex physical systems (again, think of buildings) can be represented with mechanical drawings, software specs are inherently abstract. This makes them hard to design.

There’s been progress in the last four decades, but these properties remain fixed. LLMs haven’t changed that. Non-deterministic components add immense complexity and unpredictability to software systems. The ease, speed, and volume of code generation make software more malleable and opaque than ever. And LLMs promise to ease bespoke development, tempting orgs away from one-size-fits-all solutions.

Which is to say, LLMs haven’t changed the nature of software. Instead, they’ve made it more so. So far, the technology’s killer application is developing software: teams can now produce more software, faster. (It’s unclear yet whether it’ll ultimately be cheaper, especially when you consider maintenance costs.)

What LLMs haven’t done yet is replace software wholesale, at least not for tasks that require predictable behavior. And as their true costs and constraints become evident, it’s increasingly doubtful they will. Instead, LLMs will likely become part of systems that include traditional deterministic components — both inside the systems and as part of the development process.

The resulting systems will be more complex, malleable, and abstract than prior ones. They’ll also be better fit to purpose than off-the-shelf solutions. But that requires design, which remains primarily a human challenge. And it’s hard:

it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.

Replace “software engineers” with LLMs, and this sentence still stands. But it also hints at where LLMs come closest to being a silver bullet: in their ability to spin up rapid prototypes. Good software is grown, not built. That is, it evolves from an initial core to a more complex system through an organic approach that respects Gall’s law:

The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance, and too complex to be built faultlessly, then we must take a radically different approach.

Let us turn to nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and self-renewing. The secret is that it is grown, not built.

So it must be with our software systems.

What was true then is true now: technology moves the bottleneck from production to orientation. LLMs make coding easier, much like high-level languages, IDEs, and compilers did in the past. But without shared models, structured context, feedback loops, governance, and clear interfaces, they won’t provide the results leaders expect.

As always, how to build gets easier — knowing what to build doesn’t. AI can help with that too — but it needs steering. The question isn’t “Which systems can we replace with AI?” Rather, it’s “How can AI help us grow systems that better fit our needs?” The answer will consider AI as a system component and a production tool. But forty years on, there’s still no silver bullet — just better ways to find good fit, faster.

AI lets us prototype faster than ever before. That’s great, as long as you remember there’s underlying work to be done. Specifically, production systems require structural underpinnings “screen-level” prototypes often miss.

Ironically, this means prematurely-rich prototypes can impede traction. So I wanted to discuss these issues with Harry. I kicked things off with a reading from Stewart Brand’s The Clock of the Long Now:

In recent years a few scientists (such as R. V. O’Neill and C. S. Holling) have been probing a similar issue in ecological systems: How do they manage change, and how do they absorb and incorporate shocks? The answer appears to lie in the relationship between components in a system that have different change rates and different scales of size. Instead of breaking under stress like something brittle these systems yield as if they were malleable. Some parts respond quickly to the shock, allowing slower parts to ignore the shock and maintain their steady duties of system continuity. The combination of fast and slow components makes the system resilient, along with the way the differently paced parts affect each other. Fast learns, slow remembers. Fast proposes, slow disposes. Fast is discontinuous, slow is continuous. Fast and small instructs slow and big by accrued innovation and occasional revolution. Slow and big controls small and fast by constraint and constancy. Fast gets all our attention, slow has all the power. All durable dynamic systems have this sort of structure; it is what makes them adaptable and robust.

This is a succinct articulation of pace layers, an important idea popularized by Brand. Complex systems are made up of diverse components and subsystems that change at different rates and scales. Resilient systems use the faster layers to experiment with new approaches and the slower layers to “remember” those best fit to purpose. Thus, the system evolves while maintaining coherence.

Brand showcased an early version of this model in his book How Buildings Learn: What Happens After They’re Built. As the title suggests, that version focused on explaining how buildings evolve. The model in The Clock of the Long Now casts a larger net, explaining how civilizations change over time.

Which is to say, this model can be generalized to other complex systems. That’s why it’s at the core of my book, Living in Information, where it explains how information environments remain resilient. That version offers five layers. Here they are, in order of fastest- to slowest-changing:

• Form: the user interface
• Structure: the underlying information architecture
• Governance: how the organization manages change
• Strategy: what the organization does differently to win
• Purpose: why the organization exists

As with Brand’s version, the slower-changing layers are more powerful. But the fast layers also play an important role. A healthy system needs both. Therein lies the challenge: AI’s ability to produce rich prototypes can lead us to hang out too long on the fastest layer. Eventually, alignment and coherence require heading down the stack.

What’s exciting is that this isn’t a return to the slow old days. The same tools that can help us with form can help us with architecture and strategy. But they do require attention. You can start by asking yourself two questions:

• What layer am I acting on?
• What layer should I be acting on?

If there’s a misalignment there, you want to fix that first.

The form layer is easy now. And that’s great: it means we can better describe what we want. But you can’t leave it there. Somebody must look after alignment with the underlying layers — especially strategy, governance, and structure. That’s the work I’m increasingly doing, so it was great to discuss it with Harry.

Traction Heroes episode 39: Pace Layers

In systems thinking, this principle was best articulated by John Gall:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

I’ve long promoted Gall’s law to students and clients. It’s been hard going. We want to see products and services in their full glory ASAP. But you can only throw so much cash and person-hours at a problem. Ergo, we got the time-tested idea of a minimum viable product. (It’s no coincidence that orgs with more resources violate Gall’s law more often than scrappy startups.)

But the value of an MVP isn’t just that it allows you to get something that works quickly and cheaply. Instead, the value is that that first try isn’t overspecified to theoretical conditions. It’s only a draft meant to kick off an evolutionary process that leads to a system that meets real-world customer needs.

AI removes these constraints. An afternoon with Claude can yield a comprehensive spec for a very complex system. Further sessions can architect the system and build an initial release that includes bells, whistles, timpani, harps, violas, and all the other instruments in the orchestra. All this, at a fraction of the cost and time it would’ve taken in the past.

That’s amazing. It means we can now design and build much larger systems, faster. This opens new possibilities. Not just one new feature, a new product. Not just a new product, a suite. Not just a suite, a platform. The possibilities seem endless.

But in removing architecture and development constraints, we’re also removing the need to focus on what matters most and the discipline to run it by the market. All that upfront complexity doesn’t necessarily address real-world needs. Instead, it reflects a singular top-down vision that may or may not provide value to others.

Whereas MVPs in the “before times” called for minimal investment before validation, LLMs promise a much more realized vision from the first go. But there’s a significant difference between a sexy concept car and a vehicle customers will take grocery shopping. AI-augmented workflows will give you the former, but not the latter.

Here’s an example. Two years ago, I started building a product called SiteRanger, an AI-powered agent to help small teams manage large websites. This was before Claude Code or any of the current coding agents. Still, I got surprisingly far by using Claude to augment my basic PHP skills.

Together, we built a functional MVP that implemented what I considered to be the core functionality. The problem: my “core” was in fact an open-ended platform. Rather than solve a particular customer problem, it was designed to solve classes of problems.

By the time I got alpha users on board, the system was wildly over-architected. Worse, I learned new agentic systems could provide ~80% of its value. When I looked to pivot, I realized I’d have to move in a completely different direction, one with entrenched incumbents. It wasn’t worth it.

It wasn’t all a loss. This experiment taught me a lot about developing AI-powered software products using AI. But the most important lesson I learned is that AI makes it very easy for individuals and small teams to land in the same trap as resource-rich orgs: no constraints.

Which isn’t to say you shouldn’t use AI. To the contrary, I’m all for accelerating MVP design and development. But the word “viable” is fungible, especially when you have robot engineers. You want to expose the product to the discipline of the market. That means releasing something embarrassingly simple at first. And that requires discipline and constraint — the two things most scarce when working with LLMs.

My friend Karl Fast pointed me to a wonderful scene in the movie A RIVER RUNS THROUGH IT. The main character, a child, brings an essay to his dad, a strict preacher, for evaluation. The dad’s only reply: “Half as long.” The child does, and returns with the edit. After scribbling with a red pencil, the preacher looks at him and says: “Again, half as long.”

Step away from the console and ask yourself: What would I cut if there were no AI building it? Cut, cut, cut. Then imagine Tom Skerritt staring at you over his schoolmaster glasses and saying drily, “Again, half as long.”

The key distinction is between management through principles and top-down management by rules. The latter is impracticable because managers aren’t omniscient. Arbitrary constraints proliferate in such a system, leading to stasis and entropy.

How do you keep things moving in the right direction without proliferating rules? By infusing the organization with principles. The book showcases 41 that made the Kochs successful, including Integrity, Openness, Property Rights, Mutual Benefit, Personal Knowledge, Stewardship and Compliance, and more.

Some of these are more obvious than others. Sidebars throughout the book highlight each principle as the authors narrate stories from their careers that exemplify how their organizations infused a principled culture, stayed ahead of change, out-competed other organizations, influenced policy, contributed to the broader well-being, and more.

The book starts by suggesting it’ll unfold from the perspective of both Charles and Chase, who also works at Koch Industries. But apart from a couple of autobiographical chapters at the beginning, most of the book told from a unified POV. (It’s clear Chase has internalized his father’s worldview.)

The two autobiographical chapters comprise the first part of the book, which is about applying principles to transform your life. The second part is about transforming your business. The final part is about transforming society. It applies the Koch’s principles to thorny social and political issues.

Business books often gloss over mistakes to elevate the authors. This one doesn’t. The Kohns own up to numerous mistakes, including one that cost the lives of two teenagers. Rather, they often own up to their companies’ managers’ mistakes, something I found a bit off-putting. Still, the message is clear: principled decision-making helped them get ahead — and they got in trouble when eschewing such principles.

The world would be better if principled people were in charge. I happen to agree with most of the principles in this book, but IMO the broader point is driving change through clear and well-grounded principles rather than top-down rules that constrain human agency. In promoting this mindset, this book provides a blueprint for building a more harmonious, adaptive, productive, and fair world.

Avoiding catastrophic failure is essential for gaining traction — and many so-called accidents can be prevented with a bit of forethought.

This idea was at the core of episode 38 of Traction Heroes. Harry kicked it off with a short reading from Alan Levar’s There Are No Accidents, Only Collisions. Here’s a subset:

It’s stunning how often simple safety checks were not carried out on tractor-trailers that subsequently crashed. Things that could have been fixed easily. Human error or judgment is not usually the cause of the collision, but rather it is the driver’s failure to make simple routine checks he should make every time he gets behind the wheel to make sure his truck is safe as possible and he won’t needlessly endanger the public. These checks usually take only five or ten minutes before the driver gets behind the wheel of the truck.

Of course, I wanted to probe further. How do these checklists come about? Are they provided by experts? Compiled from firsthand experience? Both?

In any case, this is actionable knowledge — and it can make an important difference. In the absence of checklists and standards, individuals and teams can “drift into failure,” inching toward catastrophe. Success calls for mindfulness and continuous vigilance.

What can you do besides compiling checklists? You can conduct post-mortems after something happens. Perhaps more usefully, you can also conduct premortems before projects begin. Both post- and premortems can inform checklists.

Good leadership calls for clarity, intentionality, and accountability. Establishing routines and standards — and staying on top of them — can help avoid failure.

Traction Heroes episode 38: Checklists

In the third of our Open-Ended Sessions, Greg and I discussed how AI is changing how product and design work are done. In particular, we’re tracking the shift from feature- and screen-level work to more strategic and human-centered system design.

Lots of orgs are choosing to deploy AI as a means to do more of the same, only faster and cheaper. But AI can also be used to unlock new possibilities by augmenting (rather than replacing) humans.

As Greg put it,

The efficiency play can be in service of unlocking human potential, right? So they don’t have to be either-or paths, but they do have to be both at a minimum.

Ultimately, the key question isn’t what the technology is capable of, but what it’s for.

Links

Books and posts mentioned in the conversation:

• Magnifica Humanitas by Pope Leo XIV
• I think Anthropic and OpenAI have found product-market fit by Simon Willison
• The Cost of Being Busy by Craig Hepburn
• The Feature is Dead. The Job Remains. by Greg Petroff
• This Moment We’re In, Ep. 3 (Greg’s conversation with Cindy Chastain)

Transcript

(AI generated — likely contains errors.)

Jorge: All right, hey Greg.

Greg: Hi Jorge, how are you?

Jorge: I am doing all right.

Greg: Yeah.

Jorge: It is interesting times.

Greg: Oh my gosh, yeah. You know, I think when we were talking about perhaps hosting one of our sessions here, it was really about the zeitgeist, like what’s happening this moment. And there are these peaks where all of a sudden there’s some kind of thread that shows up that just begs to be probed. So thanks for encouraging me and us to have these conversations. And for those who are joining us, welcome to number three of our Unfinishe sessions, where Jorge and I just talk about stuff that we think is interesting that’s going on. And we hope you find it valuable as well.

Jorge: Yeah. And it might be worth recapping beyond the open-ended conversations. This is not just something that we’re doing because we want to talk about things that interest us. In some ways, it feels like the transformations that we’re seeing are, sounds kind of heavy-handed to say it, but they’re existential. They kind of are. And these conversations I see as an opportunity to name the things we’re seeing. You have your note taker just joined when he’s trying to join. You see, it is existential.

Greg: That’s right. There we go. Goodbye.

Jorge: It might be worth unpacking what that means, but we have not pre-scheduled these, to your point. We’re kind of calling these conversations when we have sensed a shift in the zeitgeist. And this is the third one we’ve had so far. And I’m going to try to sketch out the conditions that precipitated this one. And then we’re going to circle back to a post that you shared, which I see as kind of like a way to deal more skillfully, for organizations to deal more skillfully with the situation that they find themselves in now. But there are several factors at play here. One is the big shift toward the end of last year. I think we saw a big shift in how people in general are thinking about AI. Agentic software development tools like Claude Code started proving their mettle in the organization, right?

Greg: Yeah.

Jorge: And Simon Wilson recently had a blog post where he said that Anthropic and OpenAI have found product-market fit. And he was referring specifically to these tools, right? So there’s been this shift from a modality that is more focused toward software development. And then we have things like Claude Code that build on that agentic way of working with these systems. So that was a big shift toward the tail end of last year. And then I would say that around the end of the first quarter of the year, we started paying the piper, literally. Organizations have started realizing that that kind of usage can get very expensive, right? And we’ve started to see some organizations start to pull back, capping their people’s budget for using these tools.

Greg: I would just build. I’ve been working as a fractional for a couple of different companies, fractional design leader, for those who haven’t heard that term before, over the last year. And to watch how product organizations have started to use these tools, and then the uptake in them, and then the capabilities that they unlock, and then the speed that teams can work at, and more importantly that you can do more, it’s been really remarkable to watch. And at the same time, it’s causing all kinds of churn because teams are struggling with who does what, how, when, and they’re hitting some of these issues too around utilization and use of the tools and the cost of using the tools, and not just the financial cost of using the tools, which can be significant when teams burn through their tokens, but the cognitive costs of using these tools, because you can build incredibly dense, rich, powerful documents now, but then your peers have to have time to consume them. And one of the things I’m noticing is that many of us are collaborating with our AIs more than we are collaborating with each other. And so there are all these kinds of things that we’re learning in the process of using these tools. And I also think there was some hyperbole around what was going to happen and how this might change things and the number of people, etc., that I think is starting to not show up. I think there are some things that we can think about that are different. So in this moment, yeah, we saw toward—

Jorge: Beginning of the year, organizations were starting to boast of how many tokens they were using, and they had leaderboards for this stuff.

Greg: Yeah.

Jorge: Which is another factor here that I think the emphasis was clearly on adoption as opposed to value creation. And one of the things that has shifted is, well, first they’ve stopped doing that because I think they realized, like, hey, this is really expensive. But also, that’s no way to measure progress, right? What you want to do is you want to be actually creating value. You don’t want to be boasting of how much you’re using the tools, right? So it feels like we’re kind of speed-running the process of maturing into how—

Greg: These tools can serve human needs. Yeah, there’s a whole set of new problems that are showing up inside product organizations around utilization. Are you using the right model? Are you leaving your context window open too long and therefore every time you ask for something you’re burning through credits like mad? Did you budget appropriately for the amount of credits that your team is using? What does finance think about all of that, right? I think there’s a whole bunch of things that are popping up right now. And some of that showed up in some recent announcements with Microsoft deciding to turn Claude off inside of their environment. There’s been conversation about bringing their own code development tools and their own models to bear, so maybe that has part of it. But I also, from what I understand, they were spending a lot of money. And my own experience in watching the team that I’ve been helping, the startup that I’m working with, is we run out of credits on a regular basis, or tokens on a regular basis. And then we have to go and ask for more. And there’s no real governance or process in place for a small company where they’re kind of making it up as they go and trying to understand what it means. They want to go fast, and so they’re willing to spend the money, but they have finite resources. So they can’t spend as much as they maybe think they should, or as the team wants to spend potentially. And there are all sorts of stories around teams that have burned giant holes in the budget of their organization by doing things which may not have been valuable, right? And it goes back to your point around this leaderboard thing. And I think one of the things that there’s a really great post by Hepburn about the cost of being busy that I think is really interesting to me. It was really about the teams that give the tools so that AI can be adopted throughout the organization and people sort of adopt them at their own speed are not really getting all that much productivity gain. They’re getting richer content perhaps, but they’re not institutionalizing the work in a way that takes the work that’s repetitive or less of priority and maybe building agents around that so that you can unleash your people towards new things. And I think there’s another aspect of this, which you and I started, I think this is one of the reasons why I wanted to talk this week, was Pope Leo’s encyclical came out, and it kind of fits a notion that we’ve been talking about for Unfinishe, our practice, which is we want to help organizations discover how they can, you know, the possibilities of unleashing their talent towards new efforts versus a productivity gain where you’re laying people off because you don’t need them anymore, right? I think it’s a very different mental model. And I think that there’s something about this conversation that needs to come up around the humans in the system and the value that these tools create for us, but also the value of work, etc., that I think is a notional, the conversation’s happening now and that’s good. And I think that document was a really important document to come out. And there’s been a lot of conversation around it. I know you have a take on it, but some people will leave it at that and hear what you think.

Jorge: Yeah, and I’m glad you brought that up. And even though this is turning into a kind of long preamble, I also want to bring to the table the conversation that you had with Cindy Chastain on her podcast.

Greg: Yeah.

Jorge: Because that conversation also circled around some of these issues. And I’m going to try to name it, just hearing you talk about it. I’m going to try to name the connecting thread for all of these things that we’re observing. And the thread is the question: but what is it for? It’s like, what are we doing with this, right? What’s the point? The conversation with Cindy, one way to summarize it might be something like: for design and product teams, there are two possible things that you can do with this. You can approach it as a way to do the things you were doing before more efficiently, faster. I don’t know if more cheaply, as is becoming evident, but do, let’s say, more with fewer people, right? Or another possible approach you could take is you could take this as an opportunity to do more with the people that you have, or maybe even with more people in your team, right? Just empower them to explore possibilities that were previously unattainable because of the natural constraints of a team of humans and their limited cognitive abilities and attention. And I wanted to bring that up because, A, I think that we, well, I’d love to hear your take, but I think that we’re both in the second camp. It’s like, hey, let’s see how we can augment people to do more. Because one of the things that motivates us in our shared practice is possibilities, like opening a broader space of possibilities, right?

Greg: Yes, I think with possibilities, intention, like what future do we want to have and how do we help teams and organizations fulfill that in an intentional way? And I love that you brought that up because I think the conversation that Cindy and I had was really about two stories. I’ve been doing this fractional work, and over the last year I’ve worked with two different companies, and sort of not at the same time, too. So one was sort of last year to the end of last year, and the second one is I’m currently engaged with and I started with in January when all these tools started to mature. And there are sort of two conversations. The first one was sort of dabbling with AI, learning how to use the tools, some experiments with vibe coding, etc. The second one was the design team and the product team not only using those tools, but exploring whole new territories that we just didn’t have time for in the past to do. So we were imagining a new product capability, a new product category for a company, not a pivot, but an expansion of this particular organization’s remit that they want to serve. They had a really good idea of a set of problems they wanted to solve. And we just did things that were just hard to argue for in the normal timeframe that software development gets built. And we were able to do them. So we did a bunch of work on information architecture. And one of the things that we did is we looked at competitive tools that were out there, other people trying to solve the problem in similar ways, and we did really deep analysis of how they structured their experiences so we could try to understand why they were doing it. And that helped inform a better architecture for us. We did a bunch of work looking at agentic systems and emerging conversations around how to build MCP apps. And that was exploratory. Frankly, I think it’s exploratory for everyone who’s working in that area. And so we were able to help use the process of making to define the product requirements. And in some ways, we were leading product development in that conversation because we were really trying to understand meaningful outcomes. And we came up with this thing we called the job brief, and it worked for us very well. So I think the opportunity right now is to build much better products. The concept of an MVP to me is sort of like something that needs to be reexamined because most MVPs were always insufficiently great because they were constrained by time and engineering resources. And now, where engineering resources are less constrained, why do we put product into the market that isn’t foundationally awesome? And so we can do that. And I think there’s an opportunity to really ask the organization to rethink how it takes the time of their customers and fulfills their needs and their goals. And we can be much more clear and more polished and build things which on launch make people feel seen, the users of them feel seen in a way that we couldn’t do before. And so I think that to me is an inkling of what these tools should be doing. And that’s just a product development example. But I think you could do this for organizational change. And I think any organization could take a look at it and say, I don’t just want productivity. I want to unleash the creativity of my people towards new outcomes. And that’s the kind of work I want to work on. I think it’s the kind of work that you want to work on. And it’s the kind of work that I think that the Pope’s encyclical talks about, which is meaningful work and placing humans in the system and not just this sort of technocratic cost-out perspective.

Jorge: Yeah. There’s been a, well, you wrote a post about this and I want to get into the post.

Greg: Yeah, sure.

Jorge: The very title of the post has the phrase, “The feature is dead.”

Greg: Yeah.

Jorge: Which is kind of provocative, right?

Greg: Yeah, sure.

Jorge: Why is the product feature dead, Greg?

Greg: Well, I think we’re designing something different now, right? Feature was a component, a widget, a tool that helped humans solve a problem. And in the traditional way of product development and user experience, the actor was the user, right? The user’s on a journey. You build a capability for them to complete a task that’s important for them. They use that tool. They get it done. And so product development would think in increments of capability, features. That’s what we call them in product. And we would build those features in support of customers accomplishing their goals that were important to them on their adventures at work. And what’s changed now is we have this intelligence that we’re working with. And it can be the actor, right? It can make the choices and decisions on the process, especially when you think about more agentic workflows. And so the notion of product discovery and creating and making is different. We’re not making a widget or a tool. I mean, those are still important, and by the way, yes, thank you for calling out it’s a provocative title. Features don’t disappear; they still are important. But I think what’s more important is encoding the intelligence in a system so that it can support humans and their goals, but also allow some autonomy for agents to do things. And that’s a new skill, a new pattern. And the way I was thinking about it is Clayton Christensen coined this term jobs to be done. And jobs to be done is sort of evergreen. It doesn’t go away. You have to balance your checking account or you have to pay, make payroll, or you have to answer a customer call. But the way that you can do that can change over time with the way technology shows up or how an organization chooses to solve that problem. And ironically, a lot of organizations don’t actually really understand what they do. They’ve built sort of Rube Goldberg machines of technology that allow them to accomplish tasks, and individuals in the organization are actors in that to solve a business problem. But very few people in the organization actually understand the outcomes and business goals that an organization is trying to solve for. So I’ll give you an example. The reason why this came up is there’s also something very different in the way that we can build software right now, where it’s more structural and more of a system and less bespoke custom feature development. So this particular startup that I’m working with, we are building a system that can add new capabilities, and we wanted those new capabilities to show up almost like a feed of content, right? The application would be much more like Spotify, where you’d have a playlist of things that you can, instead of a playlist of things you listen to, a playlist of things that you can do. But to do that, then you have to kind of understand, like, what do those things do and why are they valuable and how do they achieve outcomes that are important for the end user or the company that’s buying a product or a service. And so we built this thing. I’m calling it a job brief. It’s a little bit of a hybrid. It’s influenced a little bit from the Josh Seiden sort of outcomes over output construct, being an outcome-centric notion. But what I wanted to do is try to create a recipe. And I built this sort of recipe card. You can’t really see it here, but I’ll share this with folks if they’re interested. And it was really very straightforward: find the job. What is the problem? Sit with a practitioner or a person at work and find out what is the thing that they need to accomplish. Write a job statement, one sentence: who’s the user, what are they trying to do, whether they want to know or decide. Don’t make it about technology at all. What’s the outcome that they’re trying to get to? And then the next layer, which is new, I mean, this is something we’ve done forever, but the next layer is what is the context that we understand in the system? What data do we have access to? Where is the user or the person who’s acting in a moment in their day, in their workflow, in the ebb and flow of an organization? You have to define what done means. When the job is completed, what does success look like? And then the last part of it is really understanding what expertise is around that. And working with people who have deep knowledge of what that outcome should look like, what’s meaningful for an organization. And I would argue that for every organization, that expertise might be different based on the values of that organization, the people they have, the things that they find important. And this is an opportunity to add that human layer into what differentiates company A from company B. Don’t just use a novel solution that everyone uses. Build something that’s respectful of what’s important to you as an organization. And then finally, the last part is find some way to measure it by how often it’s used, by invocation, like how often it gets done. And so that construct is really about understanding how humans in the system work. Now, I’m not naive. Some of this work turns into agents that do the work for you. And ideally, in an organization, you could use this as a way to look at the things in your organization that you can codify, the domain expertise, to gain productivity and to gain efficiency where you can. But my next point of view on that is in service of being able to do more interesting, more valuable work that pushes your objectives farther forward. And so that’s the notion behind it.

Jorge: This is all in the context of design and the projects that you have been working on. You’ve been working, your role has been like a fractional chief design officer, right? So you’ve been leading design teams. Another one of the signals that we are picking up from the environment is that it feels like many organizations are questioning the value of investing in design.

Greg: Yeah.

Jorge: And I was thinking, there was a time when a lot of organizations did not have big design teams internally, right? The idea that design is a function of the organization, I would say at least the current wave, because there have been prior ones, but the current wave, we can probably date back to around 20 years ago after it had become clear that Steve Jobs had saved Apple through design, right? And people were upholding the iPod as an example of a well-designed product. And there are still business leaders out there who are thinking in terms of, like, I want something that is as useful, beautiful, whatever, as the iPod, right? So it became like a touchstone that articulated the value of design for organizations. And that seems to have shifted significantly as a result of AI. And I suspect that it might not be coincidental that Jony Ive and company’s latest product to hit the market has not been well received by a lot of people. I’m talking about the new Ferrari.

Greg: Yeah, right.

Jorge: And I have no, you know, I’m not an expert in that space. I’m not a Ferrari fan or anything. To me, it looked like—

Greg: I lost your audio. Oh, no. I can’t hear you. Now I can.

Jorge: Okay, great. What I was saying: I am not a Ferrari fan, so I don’t have as strong feelings about that product as other people. But it did strike me that at least a lot of the commentary I saw online, I got the sense that it felt like this, like it was over-designed or like it’s precious. Or it’s like it’s a product that is trying to make design, like it’s a design-forward thing. And in some ways, that almost hurt it because it feels like it’s a rethinking of what a Ferrari is supposed to be. And I almost found it to be like a metaphor for what’s happening elsewhere in design. It’s like, I guess the question is: is design necessary now that there’s a Claude design and Figma will do design work? And I think that I’ll stop after this. I think that a lot of organizations have built design functions that are primarily production functions.

Greg: Yeah.

Jorge: And by production, I mean they are set up basically to crank out screen-based experiences.

Greg: Yeah.

Jorge: And they have staffed up with people who are tasked with doing that kind of work. And at least to me, it’s been pretty clear that that’s going away, and it has been clear for a while, right? The tools have been getting better. The kind of design work that you’re talking about when you talk about job briefs. You said that the jobs-to-be-done construct is evergreen. And I think that one of the reasons it’s evergreen is because it moves the level of abstraction. It’s not about how do you execute on the hole in the wall. It’s about how do you determine what it is that the customer needs. And then you can figure out how that’s delivered to them, right? And I’m wondering, I’m just, again, this is open-ended and unstructured, right? So I’m thinking out loud here. I’m wondering if what we’re seeing is a shift from an understanding of design as this kind of screen-level production function to, and then there’s a question mark. And I think that your article tries to answer that question by saying to a role that is more strategic, which is something that designers have been trying to do for a while with not a lot of traction, I would say.

Greg: Yeah, many haven’t. Yeah, there have been some examples of people who have, but yes, you’re right. Let me respond to it. I think when we build products, there are different roles that are really important. And I think when design is seen as only craft and only as screen building, it misses the value that design can bring to the table. Those things are important, but they’re not the only thing. And the challenge is that at some level for many people in many organizations, the AI tooling is capable of doing, I wouldn’t say excellent, but reasonable results on the sort of production-level quality of building a user interface. However, I think one of the things that designers bring to the table is a deep understanding of human behavior and building products that recognize humans in the system and the mental models that people have. And it’s connected to empathy. It’s connected to having the ability to do ethnography, basically sit with customers and understand how they solve problems and what they’re trying to accomplish. It requires some new skills now because when we look at the capabilities of these tools, you can incrementally make things better or you could radically change things. And it doesn’t mean one or the other is the right path. It’s actually what is the right path for the group of humans that you’re responsible for delivering a solution for. Too much change may require a group of people to do things they’re just not unwilling to do or unable to do cognitively. Not enough change is a missed opportunity toward functionally changing the game in a way that produces some really interesting results for an organization or for the people who work in the organization. And we’re in this really messy period where the old rules don’t really apply and people are trying to apply the old rules. So you still see PRD, product requirement documents. You still see engineering burndowns. You still see JIRA tickets created. You still see, this is a software development process, because people anchor to that. That’s what they know. They kind of organize around it. But it’s unclear to me if that process of how we built software is still usable and useful in this new moment. And there’s an opportunity to change that. So where am I going with all this? I think designers bring a couple of skills to a team that are really valuable. And if not there, it’s a missed opportunity for organizations. And they can be very strategic. We are adept at the art of juxtaposition. We can take two different ideas and put them together and discern a net-new outcome. Because we make the think, we make things, we make artifacts, and those artifacts inform us. And that conversation we have with the things that we make allows us to find truth or an answer or a solution or a novel way of solving a problem in a way that can be faster than other methods. It’s not the only way to solve those problems, but it’s a super valuable way to do it. So that’s kind of just one path that designers take. The second part of it is I think it is my personal perspective that it’s inexcusable that you don’t make things great now because the tools let us do that. And that requires discernment. That requires someone who can look at a small radius or a small curve on a user experience or looking at accessibility and making sure that a product is useful for all of us, regardless of our abilities. That we can choose words carefully so that it aids people in the direction of the path that they’re trying to take. We don’t just build a piece of software and expect them to learn how to use it. We can now frame a product in a way that fits the mental model of the people that we’re serving, and we can actually get closer and closer and closer to that because these tools allow us to actually iterate and understand that more successfully. So I guess a long way of saying is I think designers are very important. There are some new things that we have to look out for, like I think interfaces are starting to collapse. We’re doing more of our work in language models, right? We’re speaking with AI. We’re having a conversation with AI. AI systems can not only answer words, they can answer in interfaces, so they can create custom experiences for us or custom tools for us in the conversation. You could just do that. But I think the thing that design brings to the table is an intentional way of doing it, shaping the grammar of an organization, inserting a value set of values into an organization, shaping how answers are delivered. Are they long? Are they short? What’s the structure? What’s the organization of them? Left alone, a large language model may choose to answer a problem differently every time you ask it, and that may not serve the audience that you’re trying to serve, right? So I think there’s a role for design to be very much involved in intentional curation of these experiences and bringing human values into them explicitly. I remember, I’m forgetting who told me this. I’ll think of it in a moment. But all software has opinions in it, whether they are explicitly or implicitly embedded in the software. Some teams are very explicit about it: this is what we do, certain things. Others, it’s just the end result of the people who built it and what they valued. But it’s there, right? We have an opportunity to be very explicit about how we serve people. And again, I think design is the discipline that not just solves business problems but figures out ways to make it deeply human. And I think our opportunity is to help organizations at a different layer, at a different level. And it may not be screens we’re working on. It could be orchestrating the flow of how work happens in a way that makes sense for people. And that’s a new skill. Not all designers are going to pivot or understand how to move into that space. But I think the things that we bring to the table are very useful there. Anyway, that—

Jorge: Was a long answer to your question. Well, and it kind of prompts some follow-up questions. You said earlier in the conversation, and I’m going to be—

Greg: I lost you there for a second there, Jorge. I think your internet took a—

Jorge: Yeah, something’s glitchy. Can you hear me?

Greg: I can hear you now, yes. I wanted to repeat your question or insight.

Jorge: Yeah, so you said, I’m going to paraphrase and probably get it wrong, but you said something earlier in the conversation along the lines of one of the things that we’re grappling with, and this was talking about as designers, is the fact that many of the things that we were doing as humans working with tools are now being delegated to agentic systems, right? And I’m going to put on my CEO hat, right? Like I have to make, I have to determine how I’m going to invest, how I’m going to allocate the organization’s capital, right? And there’s a lot of incentive right now for organizations to invest in capability, like technical capability, right? Compute is what they’re calling it, right? And you said that one of the things that designers bring to the table is a deep understanding of human behavior. Yeah. But if the systems that we’re building are not going to be used by humans, why does that matter? If I’m a CEO looking to invest, what’s the argument in favor of investing in a design team that is going to be crafting experiences to be used by humans? When, hey, isn’t AI going to do all of it? Why am I investing in human experiences?

Greg: Well, I mean, that’s a great question. I think if you’re a cost-out CEO, that may be what you think about, right? You’re like, I don’t need a design team. We’re going to use all these tools, and we’re going to deliver this service with as few people as possible. And we’re going to look at generating as much revenue as possible. And this is a path for us to get there. And my guess is there’ll be many parts of our economy that are going to be efficiency plays like that, that are going to be things that people are worried about from a job perspective. And it’s sort of inevitable. However, I also think that there will be a group of CEOs that have a growth mindset who look at what their organization does in their community or wherever they serve and look for opportunities to provide better services or better outcomes or better products. And I think one of the things that’s missed is there’s this bottom-up and top-down conversation that’s missed. So as an example, I think small organizations benefit massively from these tools because they allow them to punch way above their weight so they can compete at levels that they couldn’t compete with before. And small, intimate teams with these tools that communicate well with each other now have the ability to expand their horizons around the things that they can offer, the services they can develop, the things that they can provide for whoever their customers are, or users are, or whatever their goals are, whether they’re for-profit, not-for-profit, etc. In large organizations, I think the transition is going to be identifying also where in the aspect of the services that they provide that humans are actually important for their customers, right? So I think as humans, people want to hang out with people, right? And I mean, there are people apparently who have chat, cheap, and girlfriends, but I think most of us are, especially even post-pandemic, and I still think we’re in the post-pandemic phase, we want to have a sense of community and connection to each other. And so I think there’s huge opportunity for organizations that recognize how to place their people front and center with their customers or the people that they care about or the things that are important. So I guess what I’m trying to discern is I think there’s an opportunity space for the people who are good at unlocking possibilities and discerning new things to service, developing better outcomes for all of us. And it’s a little bit of a, you know, it needs to be seen, but I think that’s the path that I want to see. I would love to see our politics in this world focus on the opportunity to service and support everyone. I’d love to see our businesses look for opportunities to grow their businesses in new and creative ways. And I would love to see human potential be the big story about being unlocked by these tools versus being laid off. And I think we need to think about that very hard. I think we need to find this is going to be a transition. There’s not going to be without, there already is massive transformation going on in organizations. And I think we are, as a culture, need to be managing this carefully. And again, I’ll come back to why I think design is important, because I think designers can find opportunities to potentially mitigate some of the challenges with AI, from an employment and cultural perspective. But they’re also just going to be great at finding new things to do that we didn’t know we needed before and that are exciting and fun and fulfilling and helpful. And so, if I were a large CEO, one of the things I would be investing in is a creative design team that is just exploring and looking for net-new things that could benefit, that are adjacencies to a company’s core mission that might be new growth opportunities for them. And I think that the tooling allows creatives the opportunity to really shine there. I don’t think we’re there yet. I don’t think people have talked about it yet enough. But I do think that there’s really an opportunity for us to look for ways to be more future-focused and actually try to tackle some of the real problems that we have in the world.

Jorge: I kind of want to double down on what you’re saying there, because in playing devil’s advocate earlier, it may not have been clear just how much I agree with what you’re saying there. But my read is that organizations that are kind of restructuring themselves to maybe, like a phrase that you could, maybe a phrase we could use is something like a post-design world, or like a world in which they’re not placing their emphasis on human experience, right? The organizations that are investing in AI as a way to gain efficiencies by automating the sort of touchpoints that humans have relied on so far, they’re doing so from what I see as like a, like in my mind, I have this Venn diagram that has fear, bad incentives, and a kind of like spectacular lack of imagination. Yeah. The phrase that often comes to mind is this Warren Buffett thing where he says that he advises being bold when others are fearful and fearful when others are being bold. And I just want to kind of double down on what you said about this being a time of unique opportunity, particularly for the organizations that are willing to zag where everyone else is zigging in the direction of efficiencies. Just because there are, like to your point, there are now possibilities that were just previously unavailable. And to only think about the path of, like, how can we make, how can we deliver the minimum possible experience as cheaply as possible is one possible direction, but by no means the only one, right? And I suspect that we are still in the throes of, like, hey, this is a new technology and let’s double down on efficiencies where we have not yet truly explored the possibilities of other ways of using the technology, right?

Greg: Yeah, I mean, I love that framing. I’ve been a big, one of the things I’ve talked about for the last 10 years is this notion of incrementalism versus really understanding the problem, right? And for a lot of organizations, incrementalism was the path towards success because you took small pieces and you got better and you got better over time and you got better over time. It kind of fits the Agile Manifesto. It’s how organizations work. They’re risk-averse, so they don’t want to try to take on too much. We’ll make one small change, we’ll make a change of, you know, and. But it was connected to the fact that things were very difficult to do well, and therefore you had to be careful about doing it. And so instead of going for it and doing something big or trying an experiment and failing, you just made your product slightly better over time or your outcome slightly better over time, your system slightly better over time. And there’s nothing wrong with that as a strategy, by the way. It makes sense and allows you to do things in a sustained way. What is interesting about this moment is that these tools allow us to build things that used to be very, the very expensive part of building software is far less expensive than it used to be. And so an incrementalist mindset may just be a faster way to get to the wrong place, you know? And I think one of the things that we don’t do enough of is discovery work, understanding what is the problem and what would really be meaningful for people. And now we can spend a lot of time in that, right? And in the design space there’s this diagram called the double diamond that came out of the British Design Council that’s a very popular way of describing the process of design. And the first half, the first diamond, is discovery. And then you sort of evolve that into a product, and then you go into an execution phase, and then you deliver and you learn from your customers. And my argument now is that these tools allow us to build the first part of that diamond much bigger and the rest of it much smaller. And what do I mean by that? It means that we can spend, in a short period of time with these tools, we can learn way more about who we’re serving and have a much better understanding of what their problem is and iterate on not just one, but hundreds of solutions that could possibly satisfy those needs and outcomes, and then discern which one is the best, refine it, make it great, and then deliver it at fairly low cost from an execution standpoint. And so that upends the process. It used to be the other way around, that the execution part was so hard that that’s where all the energy was, right? And so it was like, make a small bet, get it out to market, make another small bet, make it out to market. So it goes back to your point of lack of imagination. And I think there’s an opportunity right now for companies to at least have some part of their organization that is thinking boldly and broadly and unhampered by an incrementalist mindset. And I think if I were a CEO of a larger organization, I would be setting up a lab to think about not how to use these tools to do what I do better now. I would be setting up a lab on how do I use these tools to do something I’m not doing now that would help me grow my outcomes that are important to my shareholders or to my customers or to the business community that I’m trying to connect to.

Jorge: I love that framing.

Greg: And I think designers are great at that. They’re not the only one. There need to be other parties in that conversation. It’s a multidisciplinary effort, but it doesn’t work without designers in the room.

Jorge: You know, to circle back to the Pope’s encyclical, the central metaphor that he uses to talk about the possible ways forward for the development of AI-based systems, he uses this architectural analogy from using two stories from the Bible. One story is the construction of the Tower of Babel, which is a kind of technocratic, top-down effort to, now I’m kind of reading into it, right, to control. And it’s an effort that kind of flattens differences between people. And he contrasts that with another story from the Bible, which is the rebuilding of Jerusalem after it had been torn down. And he talks about Nehemiah. I don’t know if that’s how you pronounce it, but this person who rather than dictate top-down this technocratic solution, gathered the people who inhabited the city. And through this kind of consultative approach, led to the rebuilding of this kind of organic, more organic city that responded to their needs. And part of what I’m hearing you say is that, and I think that this is also implicit, if not explicit, in the encyclical, is that AI allows for both of those approaches. We can do the top-down thing really fast now and really comprehensively, and it can turn into a real dystopia. Or we could employ it in this more kind of bottom-up, consultative, human-centered way, and it could also do it much faster with greater scope, with the possibility to explore many, many more alternatives just because the tool allows us to do so much more. So it becomes a matter of how do you choose which of the two approaches you’re going to take? And I think what we’re saying here is we would like to foster a world that follows the second path, the more kind of designerly path, the path that puts human beings, their needs, including their dignity, which is an important word in the encyclical, front and center. And the tools are amazing. They can empower us to do much more than before, as long as it’s in service of that, right?

Greg: Yeah, creating a better world. And the irony is you can have both of those things happen. The efficiency play can be in service of unlocking human potential, right? So they don’t have to be either-or paths, but they do have to be both at a minimum. If we just go the Tower of Babel path, I don’t want to live in that future. I’m very much interested in being intentional about the choices that we make. And again, that’s why I go back to why designers are important. We’re good at that. We are good at intentionally helping craft a narrative and artifacts and things which connect to the way that we want to live. And then we’re good at telling stories around that with the things that we create. Those things that we create inspire people. And it’s a really part of being human that there are things that delight us and bring us joy and make us cry and help us understand and live fulfilling lives, all the things that I think are important, which by the way, that’s not the longest list of important things, but nonetheless, I think we’re coming to a close.

Jorge: I was going to say that feels like a good place to wrap it up. If you want to follow our work, we do have a Substack. It’s called Unfinishe Thoughts, and it’s at thoughts.unfinishe.com. Remember, it’s Unfinishe without the D. And Greg and I post there periodically. It feels like almost as infrequently as we do these live streams, but we should write these things up more.

Greg: Yeah, our plan is to be a little bit more prolific in the rest of this year. But thanks for hanging out with us today. And Jorge, as always, I love hanging out with you and talking about our stuff. And we’ll see you at the next Unfinish.

Jorge: Same here. Thanks, Greg. Bye.

Many teams are being measured for the wrong things: tokens used, agents deployed, etc. Their orgs have focused on tech adoption rather than value creation. It’s a mistake.

I wanted to discuss this with Harry in our most recent podcast, so I read a passage from one of my favorite books, James C. Scott’s Seeing Like a State. To my surprise, he’d read it too.

I won’t cite the whole passage, but it kicks off with a familiar distinction:

Isaiah Berlin, in his study of Tolstoy, compared the hedgehog, who knew “one big thing,” to the fox, who knew many things. The scientific forester and the cadastral official are like the hedgehog. The sharply focused interest of the scientific foresters in commercial lumber and that of the cadastral officials in land revenue constrain them to finding clear-cut answers to one question. The naturalist and the farmer, on the other hand, are like the fox. They know a great many things about forests and cultivable land. Although the forester’s and cadastral official’s range of knowledge is far narrower, we should not forget that their knowledge is systematic and synoptic, allowing them to see and understand things a fox would not grasp.

Scott then unpacks how flattening an ecosystem to a few legible variables leads to a kind of myopia. This is assuming the variables are meaningful, as with land productivity for cadastral purposes. Token maxxing, on the other hand, is folly.

Legibility — instrumenting processes so we can track progress — is essential for traction. But we shouldn’t focus on things we can measure (e.g., tokens used, numbers of agents created) rather than those that matter to the business.

It’s harder to focus on the right measures when we’re acting urgently and/or from fear, as is the case for many teams now. How can we measure what really matters? That’s what Harry and I explore in this episode.

Traction Heroes episode 37: Legibility

The Pope’s namesake, Leo XIII, led the Church during the second half of the 19th century. It was a time of social unrest triggered by technological changes: the Industrial Revolution precipitated the exploitation of workers and its counteraction in Marxism. Both dehumanized societies.

The Church’s response was Rerum Novarum (1891), an encyclical that promoted both the rights of workers and free markets. It offered a sensible middle path between anything-goes capitalism and atheistic socialism, and set the foundations for the Catholic Church’s modern social positions.

In choosing the name Leo XIV, the current Pope hinted at continuing this work. It’s certainly needed: digital technologies — and AI in particular — are at least as transformative as industrial machinery. The central question is, how will we use this technology? Will it serve the common good or dominate and exploit people?

These aren’t technical questions: they’re moral and spiritual. The Catholic Church has grappled with such issues for centuries, and Magnifica Humanitas offers an overview of that history, warts and all. The outcome is a comprehensive social framework based on several key principles:

• The common good. Work toward social well-being collectively, not by aggregating individual interests.
• The universal destination of goods. Don’t monopolize wealth and resources; steward the goods that create well-being for all.
• Subsidiarity. Delegate decision-making authority to the smallest possible unit.
• Solidarity. Recognize that our destinies are bound together and we have obligations toward each other.
• Social justice. Be fair and don’t exploit or discriminate against people. (Again, everyone has inherent worth.)
• Integral human development. Elevate people so they can participate with dignity in society.

After recapping the Church’s Social Doctrine, the encyclical applies these principles to AI and the digital economy. We can choose how to design these technologies. The Pope describes two possible approaches by using architectural metaphors drawn from scripture. One is that of the Tower of Babel: a construct meant to glorify its dominator-builders and homogenize people for the sake of power and efficiency. The other is exemplified by the lesser-known story of the rebuilding of the walls of Jerusalem:

Nehemiah, a Jew in the service of the Persian King Artaxerxes, received news of the disastrous state of his ancestral city. Before taking action, he fasted, prayed and interceded for the people. He then asked the king for permission to return to Jerusalem and, upon arriving, examined the destroyed areas in silence. He did not impose solutions from above. He convened the families, assigned each of them a section of the wall to rebuild, listened to their concerns, coordinated their efforts and addressed any opposition.

Which is to say, an organic, consultative process with the people affected — as opposed to a top-down technocratic initiative. The former responds to the needs of members of the community. The latter imposes “solutions” from above, eroding their agency. Upholding human dignity is the encyclical’s foundational principle, and it’s under threat:

It is important to ensure that this growth in appreciation of human dignity is not obscured by the pressure of new ideologies or very powerful interests in today’s world. Among these ideologies, I consider particularly insidious the one that suggests that every person must earn or justify his or her own worth, to the point of attributing greater value to those who are more efficient or effective. From this perspective, persons end up being reduced to a means of achieving results, a resource to be used and exploited, and are no longer recognized as a proper end in themselves who should never be instrumentalized. The value of persons, however, does not depend on what they achieve or produce. There are rights that apply to everyone simply by virtue of being human, and no human power can legitimately deny or arbitrarily limit them.

Like all technologies, digital systems are shaped by the values of the socioeconomic systems that create them. Systems that prioritize domination and personal gain over the common good pose serious risks, including growing inequality, weakened democracy, increased social unrest, environmental degradation, the emergence of new forms of slavery, and more.

And of course, there’s the ever-present risk of violence. Autonomous weapons threaten new levels of destruction. War takes a new valence when the systems deciding on the path of death aren’t human:

Artificial intelligences do not undergo experiences, do not possess a body, do not feel joy or pain, do not mature through relationships and do not know from within what love, work, friendship or responsibility mean. Nor do they have a moral conscience, since they do not judge good and evil, grasp the ultimate meaning of situations, or bear responsibility for consequences. They may imitate language, behavior and analytical skills, or even simulate empathy and understanding, but they do not understand what they produce, for they lack the affective, relational and spiritual perspective through which human beings grow in wisdom.

But Magnifica Humanitas is less an AI manifesto than a commentary on (and corrective of) the socioeconomic systems under which it’s emerged. Instead of systems that treat people as means to particular ends (e.g., Marxism, extreme forms of capitalism), the Pope calls for building a civilization of love grounded on justice, human rights, and basic decency.

In issuing this encyclical, the Church stakes a clear moral position. It isn’t an argument against technology, private property, or free markets. Instead, it’s a reasonable call to treat humans and our labor with dignity:

In the era of artificial intelligence, when human dignity is threatened by new forms of dehumanization, ours is the pressing duty to remain profoundly human.

You needn’t be Catholic to recognize the importance of this message. Ultimately, the question of how we’ll put AI to use isn’t technical, but moral. The stakes — human dignity, democratic participation, the distribution of power — couldn’t be higher.

We do that a lot, lie to ourselves.

I don’t like making predictions, but I’ll make one now. I’m confident it’ll pan out: organizations cutting staff “because AI” will come to regret that choice.

That’s not to say I believe that’s why they’re actually laying people off. Many orgs were likely overstaffed. AI is just the excuse leaders are giving Wall Street. Perhaps some believe it. If so, they’re lying to themselves. And there will be consequences.

As the class “fat kid,” I was bullied. It affected my personality. I became simultaneously shy and viciously sardonic. My grades suffered. I’m still paying the price for the fridge “easy fix” decades ago. Near-term pleasure, long-term suffering.

Orgs cutting staff are being rewarded with a near-term financial boost. What might be some long-term consequences?

I see at least three:

1. Reduced trust. The people who remain still have work to do. That includes deploying AI, a technology they now viscerally perceive as a threat. They’re damned if they do and damned if they don’t. And their leaders have made clear what they value.

2. Brand erosion. Wall Street isn’t the only audience: customers are listening too. And they’re likely (and rightly) concerned that the org seeks to replace human judgment. We’ve been burned before: that’s why the word ‘enshittification’ exists.

3. Loss of culture and knowledge. Much of how organizations produce value isn’t formally codified. In many ways, an org is its people — their shared culture and knowledge, most of which is tacit. The data AI needs about how orgs tick doesn’t exist.

Humans aren’t mere resources. Organizations are complex adaptive systems where people play critical roles that extend well beyond their job descriptions. For many orgs, interpersonal relations are the golden egg-laying goose.

Current AI can’t bridge these gaps. Leaders who believe it can are either deluded about its capabilities, the true nature and complexity of the business, or both. Or they’re lying to themselves.

My mother was right. You may think you’re cleverly misdirecting others, but you’re only misdirecting yourself. And the consequences will haunt you.

I’ve been pretty glum on this note, but that’s because I don’t like what I’m seeing. So I’ll leave you with the positive flipside of my prediction: The organizations that thrive in the AI era will be those who augment and empower their people — not those who cut them.

The technology is capable, but it will require lots of work. The challenge is architecture, not headcount.

You want to make better decisions to act more skillfully. But how? Seeing clearly is essential. It’s hard enough to get a good read on your context, but getting a good read on yourself is even harder. When it comes to self-assessing, we all have blind spots.

In episode 36 of Traction Heroes, Harry brought a short reading that explores this idea. It’s from Phyl Terry’s Never Search Alone, a book that has helped people I know with their job search. But our conversation didn’t focus on job hunting. Instead, we explored what Terry calls Kahneman’s conundrum, after celebrated psychologist Daniel Kahneman:

Kahneman says that he himself has no idea when he’s making any of the cognitive mistakes that he spent a lifetime identifying: ‘my intuitive thinking is just as prone to overconfidence, extreme predictions, and the planning fallacy as it was before I made the study of these issues.’

Whoops! Even the most prominent researcher on cognitive biases can’t effectively self-assess them. Terry continues,

Might there be a way for leaders to at least know when they’re about to make a mistake based on a bias? Kahneman says no. We would all like to have a warning bell that rings loudly whenever we’re about to make a serious error, but no such bell is available.

Bottom line:

The knowledge of these biases does not seem to matter. The expert knowledge gained from decades of research does not even help the co-founder of the discipline. We humans are destined to make the same kinds of mistakes repeatedly, to be blind about our blind spots. It is simple but true. We all know that we can easily see the errors in others while being frustratingly blind to our own.

A conundrum indeed! What can we do about it? I suggested getting others’ perspective, whether a trusted colleague, friend, or mentor. Harry offered the Johari window as a tool for understanding what others think about us that we don’t know ourselves.

Continuing on the practical vein, I mentioned my experiment with using AI to illuminate my blind spots. Some folks pushed back on this as a sort of modern-day astrology (i.e., the language invites us to read into it), but I found ChatGPT’s ‘reading’ insightful.

However you do it, include others’ candid feedback into your decision-making process. Self-awareness alone won’t cut it.

Traction Heroes episode 36: Blind Spots

Still, mindful leaders are encouraging their teams to embrace AI. Experiments proliferate. Overnight, teams find themselves grappling with dozens of “agents” that cover similar ground. There’s more competition than collaboration among team members.

There’s little coherence. Most of these efforts don’t solve strategic business or customer problems. At best, they’re compelling — yet ad-hoc — proofs-of-concept.

Worse, they’re emerging in a context of generalized anxiety. Team members are trapped in a “damned if they do/damned if they don’t” conundrum: Their jobs are at risk if they don’t adopt AI, but media constantly reminds them AI might replace their jobs.

The anxiety is understandable, but also a bit sad. There’s so much potential. AI is by far the most exciting tech development I’ve experienced in my three-decade career.

Even so, many people have bad expectations of what the technology can deliver now. These things take time. It took several years — and expensive mistakes — for businesses to learn where and how the web could be used most effectively.

It’s too early to expect efficiencies from AI. The goal right now should be learning, not optimizing.

The best we can do is run directed experiments: fast, small, iterative projects that explicitly aim to move the business forward while developing essential new skills. Not just bottom-up, but building toward a directed vision.

How do you define that vision? You consider the big picture. What’s the organization’s strategy? How does the business unit serve that strategy? What are its key information flows? Where are the bottlenecks? Which can be best addressed using AI?

Throwing agents against the wall won’t answer these questions. Real progress requires top-down direction and visibility: understanding the big picture well enough to determine how AI might best unlock new possibilities. But it also requires experimenting to learn how the technology can actually work within your particular context.

These things aren’t in tension. A mindful balance is called for.

Ultimately, it’s an architectural problem. The organizations that benefit most from AI won’t be the ones that burn the most cycles and tokens. Instead, it’ll be those who understand the big picture well enough to drive advantage by architecting intelligence.

When I was a kid, I tended to view the world in stark black-or-white terms. Things were either amazing or terrible. People were brilliant or bozos. My dad would caution me: right answers often land closer to the middle of a spectrum than its extremes.

Later in life, I read an essay called Axis Thinking, which organized these ideas into a coherent framework. Written by the musician, producer, and systems polymath Brian Eno, it appeared in his book A Year with Swollen Appendices.

Axis Thinking has influenced how I consult. I wanted to hear Harry’s take, so I brought it as the focused reading on episode 35 of Traction Heroes. How has it changed my work, specifically? Eno put it well:

Axial thinking doesn’t deny that it could be this or that, but suggests that it’s more likely to be somewhere between the two. As soon as that suggestion is in the air, it triggers an imaginative process, an attempt to locate and conceptualize the newly acknowledged greyscale positions.

I am interested in these transitions — these moments when a stable duality dissolves into a proliferating and unstable sea of hybrids. What happens at such times is that all sorts of things become possible: there is a tremendous energy release, a great burst of experimentation. Not only do the emerging possible positions on this new-born axis have to be discover­ ed and experienced and articulated; they have to be placed in context with other existing axes to see what new resonances appear.

That is, it’s not enough to look for solutions in the middle points of a spectrum. Sometimes, what’s called for is questioning the spectrum altogether. One or both poles might not go far enough — or go too far. And exploring completely different axes might prove fruitful.

Axial thinking is highly relevant today. See, for example, the barren discussions that frame AI as either all good or all bad. Most realistic scenarios fall somewhere in the middle — but opening an altogether different axis (e.g., replacement ↔ augmentation) can spur more generative discussions.

Gaining traction sometimes calls for dissolving stable dualities “into a proliferating and unstable sea of hybrids.” Nuance and imagination are more important than ever. This conversation offers pointers on how to move past entrenched polarities.

Traction Heroes episode 35: Axis Thinking

That’s where we’re at with AI. Companies are throwing stuff at LLMs to see what works. Right now, traction and speed matter more than efficiency. But that won’t always be the case. Eventually, we’ll shift to AI-powered systems that are both more efficient and controllable. What will they look like?

My bet: a combination of more carefully structured inputs (i.e., context engineering) and good, old-fashioned deterministic programming.

I like Simon Willison’s definition of agents: “An LLM agent runs tools in a loop to achieve a goal.” The most common way to do this is to give an agentic system (e.g., Claude Code) the ability to call deterministic tools — Unix CLI utilities, APIs, etc. It’s a powerful and flexible approach, but one that uses a lot of tokens and requires advanced models. It’s also unpredictable in ways that matter when you’re running a business.

But for many use cases, you can achieve similar results by inverting the hierarchy. Instead of giving an LLM the ability to use deterministic programs, you have a deterministic program call an LLM at specific points in its flow, using heavily curated context. It’s an information architecture challenge as much as a software challenge.

This isn’t as flashy as an autonomous agent improvising its way through a problem. But for many business tasks, it doesn’t need to be. The constrained approach produces more predictable outcomes, runs on smaller and cheaper models, and keeps your data under control.

The tradeoff: you must know what you’re building before you build it, since the bulk of the work happens in traditional software. But — and here’s the kicker — coding agents can help design and write that software. A bit of probabilistic work upfront to spin up a mostly-deterministic system.

I’m using such “agents” on my Mac. For example, one monitors a directory for new PDFs and fires a script that calls an LLM to transcribe my handwritten notes. About 80% of the work is classic if-then logic. The AI handles only the part that actually needs AI. Because those asks are tightly constrained, I use small models running locally — free to download, private by default, and using hardware and energy I’ve already accounted for.

This is what more mature AI adoption will look like for most organizations. Instead of open-ended agents improvising at scale, tightly-scoped systems that call on AI for the things AI does best. Heavy thinking upfront, with day-to-day operations using limited AI. Upshot: increased control, efficiency, and predictability.

Automation doesn’t just do work for us: it changes how we experience work, sometimes leading to unexpected consequences. Technology can make us complacent, leading us to make mistakes.

In episode 34 of Traction Heroes, Harry told of a time when he drifted off course by following GPS navigation instructions. Instead of the airport, he ended in a remote part of Virginia — and almost missed his flight. Things like this happen. Harry also cited a compelling story from Nicholas Carr’s The Glass Cage:

Automation complacency has been documented in many high-risk situations, from battlefields to industrial control rooms, to bridges of ships and submarines. In one classic case involving a 1,500-passenger ocean liner named The Royal Majesty, which in the spring of 1995 was sailing from Bermuda to Boston on the last leg of a one week cruise. The ship was outfitted with a state-of-the-art automated navigation system that used GPS signals to keep it on course. An hour into the voyage, the cable for the GPS antenna came loose, and the navigation system lost its bearings. It continued to give readings, but they were no longer accurate. For more than thirty hours, the ship slowly drifted off its appointed route. The captain and crew remained oblivious to the problem despite clear signs that the system had failed. At one point, a mate on watch was unable to spot an important location buoy that the ship was due to pass. He failed to report the fact. His trust in the navigation system was so complete, that he assumed the buoy was there and he just didn’t see it. Nearly twenty miles off course, the ship finally ran aground.

Like many technologies, GPS works well most of the time, so we don’t question it. But things can go wrong. Our trust in the technology’s capabilities can lead to a misplaced sense of security. The results can range from inconvenient to catastrophic.

This is obviously highly relevant in the age of AI. Not only is the technology fallible, but it also presents its outputs with high degree of self-confidence. So we must be especially vigilant. That said, always second-guessing results can cost valuable time and resources.

As I explained, we must use AI with a clear understanding of our own competence in the domain in question. We can be a bit less vigilant in domains where we have enough expertise to judge the quality of the output, but must be more skeptical when we don’t know what we don’t know.

Knowing where and when to apply critical thinking is key to avoiding setbacks. What’s required is literacy: understanding how the technology works under the hood. AI isn’t magical. If you understand how it can fail, you’ll be less likely to accept results uncritically — and when it’s ok to trust them.

Traction Heroes episode 34: Automation Complexity

Here’s a tricky situation: you start reading someone through a negative lens, which changes how you interact with them. They respond in kind, which seems to confirm your negative views. Cue vicious cycle.

In any situation, you are both observer and participant, whether you realize it or not. And often, you’re responding not just to the person in front of you, but to your story about them.

This mind-bending topic was the subject of episode 33 of Traction Heroes. Harry brought a reading from Nir Eyal’s Beyond Belief to set up the conversation. Here’s one of the key bits:

More often, it’s our brains creating problems because none exist. Since perception follows belief, we perceive the problems we look to find and if we can’t find them, our brain skews the data to fit the brief. If you believe your partner is constantly criticizing you, innocent comments transform into attacks. If you believe your boss doesn’t value you, any feedback becomes proof of your perceived inadequacy. This cycle becomes dangerous when it reinforces our negative beliefs, locking us into a belief-driven feedback loop that distorts reality and quietly builds a prison of our own making.

I’ve been there, and I’m sure you have too. You may have even unwittingly flipped someone’s “bozo bit,” leading to a strain in the relationship that can be hard to undo.

The question is: what can you do about it? As with so many other topics we’ve discussed in the podcast, it comes down to self-awareness: having the wherewithal to step back and realize you’re layering meaning onto situations.

Easier said than done! For one thing, you want to perceive clearly to avoid misreadings. But you don’t want to lapse into paranoia, which can also cast a negative valence.

Often, our misperceptions become obstacles to gaining traction. Surfacing them is a start, but we also explored practical suggestions in the podcast. Check it out:

Traction Heroes episode 33: Perceptions