We keep reading scary reports of swarms of AI agents breaking into computer systems and doing other untoward and perhaps illegal things. To what degree do these agents influence each other? And is there anything we can learn from human behavior that would help mitigate these problems? That’s the heady backstory behind [episode 46](https://www.tractionheroes.com/2439976/episodes/19905275-tribal-psychology) of [_Traction Heroes_](https://www.tractionheroes.com/). Harry brought a short reading from David McRaney’s [_How Minds Change_](https://www.amazon.com/How-Minds-Change-Surprising-Persuasion-ebook/dp/B093R2CP2V/) about the impact of our groups on our thinking and behavior. Here’s the key fragment: > the latest evidence coming out of social science is clear. Humans value being good members of their groups much more than they value being right. So much so that as long as the group satisfies those needs, we will choose to be wrong if it keeps us in good standing with our peers. We never lack evidence for this: just tune in to the news. People do stupid things to remain in good standing with their milieu _all the time_. (I know I have!) And apparently, so do AIs. (Although as I pointed out in the show, we mustn’t anthropomorphize technology.) But more importantly, knowing about the perils of tribal psychology can help us be more effective when working in groups — and therefore, to gain traction. [_Traction Heroes episode 46: Tribal Psychology_](https://www.tractionheroes.com/2439976/episodes/19905275-tribal-psychology)

Are you more of an analytical or a holistic thinker? The answer might depend on the culture in which you were raised — and will impact your ability to gain traction. In episode 44 of Traction Heroes, Harry read a short segment from Joseph Henrich’s The WEIRDest People in the World, which argues that people in “WEIRD” societies — Western, Educated, Industrialized, Rich, and Democratic — tend to think more analytically than holistically. I haven’t read the book, but do believe our culture influences our worldview — including how we think of timeframes and outcomes. If we’re driven by quarterly results, we’ll have a very different orientation than if we have a 10-year outlook. Learning how culture affects our perspective changes how we understand ourselves and how we communicate with others — and both affect our ability to gain traction. Traction Heroes episode 44: WEIRD People

It’s been fifty years since information architecture’s coming out party in Philadelphia. Alas, the discipline is still widely misunderstood. The main obstacle? The very thing that brought it to many people’s attention: the World Wide Web. 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.

Forty years ago, computer scientist Fred Brooks published a paper called No Silver Bullet: Essence and Accident in Software Engineering. As its title implies, the paper argues there are no technological shortcuts to making software radically easier, simpler, or more reliable. You may think AI is the ultimate silver bullet. It isn’t. 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.

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, 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