Critically Engaging With Models

Posted on September 20, 2022 by Rebecca and Mathias

Our worldviews are grown from other people’s models. How do we control what models we let in?

Introduction

You might be familiar with The Five Stages of Grief aka the Kübler-Ross model for processing grief (denial, anger, bargaining, depression, and acceptance). Independent of what the authors intended, this model gives us a framing right off the bat:

The word “Five” suggests a fixed set.¹
The word “Stages” suggests that they are discrete phases.
It also suggests that these stages come in a fixed order.
The word “The” suggests that you always go through these five stages when grieving.
And it is our impression that people interpret this model as prescriptive: in order to process grief, you must go through these stages in order

We’re not interested here in whether these statements are accurate or not. Perhaps the authors’ wording was accidental, and it could just as well have been named “Various Feelings of Grief.” We’re interested in how the language suggests ordered stages, and that’s how most people will perceive it.

When a model puts us in a certain framing, how can we tell? How do we understand what framing a model imposes on us? How do we engage with any model? How can we evaluate it? Should we break out of that framing? Do we accept the model as is? Or do we use it as scaffolding for finding better models, that are better suited to our situation?

Models Are Worldviews

Models, whether for a software system, a development process, diseases, political systems, or otherwise, are a way to look at (a part of) the world. They explain how something behaves and how to modify that behavior. Every model makes a choice about what is important, what categories we classify things in, what we see, what’s invisible, what’s valued, or even what’s valid. Models are reductionist; that is, they only show a selection of the subject they’re describing, and lose something in the process. And models are biased: they implicitly reflect the assumptions, constraints, and values of the model’s author.

Most of the time, when you adopt a model created by someone else, you assimilate it into your worldview without much thought. You acquire a new way of seeing something and accept it. It’s how learning works. However, when you do that, you may not understand the model’s limitations.

Models mess with you. They impose a distinct perspective, and a set of rules for operating within them. They frame how you look at your problem. And you’re usually not aware of this perspective and framing.

But you can choose to look at a model more intentionally. If you’re looking at a model for the first time, you can use your fresh perspective to see what it includes and what it leaves out. You can critically assess whether that model fits your view and your needs. Models are a powerful lens for perceiving a subject, and you should be deliberate when wielding them.

We’d like to share some tools for critically evaluating any models that come your way. We’ll do this by example. We have picked a number of organizational models to illustrate how to examine them and see whether they offer what you need to solve your problems. First, we’ll discuss the hierarchical, social network, and the value creation models. Then, we’ll examine three organizational models that are specific to software development: the Spotify Model, the Agile Fluency Model, and Team Topologies.

Our goal is not to voice an opinion one way or the other about these different models, or to suggest which ones to use for your organization. Our interpretation of these models is by necessity brief. If you are familiar with any of them, you might feel we do them a great injustice by our summarizations. We ask that you look past the specifics of the organizational models we examine, and instead focus on the methods we demonstrate for evaluating any model, in any context.

Here we use well-known published models to illustrate approaches for understanding and comparing them. But these techniques apply equally well to various models that you may encounter or create, such as domain models, working agreements, business processes, or politics.

Hierarchies and Networks

A traditional way of looking at organizations is the hierarchical model. In this model, power is concentrated at the “top” and authority is structured into levels. People talk about “going up the chain of command” in order to reach the “right person” in the hierarchy who has the authority to make a decision. People have often mistaken this model for the whole: “an organization is a hierarchy”. In reality, the model only describes one aspect of an organization.

It’s often by looking at alternative models, that we see the limitations of this hierarchical model. For example, a competing model says: “an organization consists of a hierarchical control structure and a social network”. The social network is who you talk to, and how you informally acquire information you learn at the coffee machine or over lunch. This model is an improvement over the hierarchical model: it shows us that human interactions can affect the functions of the organization. A manager might want to encourage their organization’s social network, or change the dynamics to improve opportunities for informal interactions. They’ll try to improve the functions of the organization, and make sure the social network doesn’t hinder it.

In our role of model evaluators, this teaches us that an organizational model can have two networks operating simultaneously, each representing a different function of the organization. That’s significant, because if our organization has two networks, it is possible to have more.

Heuristic: If there are two ways of looking at something, look for a third.

Another model augments these two organizational networks with a third network: the value creation network. This is the network you turn to to produce meaningful outcomes. It’s knowing which people to ask when you need something done, who the experts are, who can execute it. By modeling our organization now as a hierarchy, a social network, and a value creation network, we are challenging the assumptions made by the previous two models. The new model says: “value creation doesn’t happen through the same channels as control or gossip.”

Before we adopted this third organizational model, there were two possibilities: either value creation was not on our radar at all, or value creation was a responsibility of one of the other two networks (most likely the hierarchy).

When we accept this third model, we believe that value creation:

is important enough to be recognized as an organizational responsibility;
doesn’t happen in a hierarchy or social network;
it happens in its own network.

This new model doesn’t simply add a third network. The new model supplants the prior belief that value is created in the hierarchy, with the belief that it is created through a value creation network. Through the addition of the third network, the other two networks in the model have acquired a new purpose. The third network adjusts your perception of the other networks.

Say a manager has been mandating that all communications and decision-making happens along the lines of the hierarchy. Now, as they accept the new model, they change how they operate, and instead allow and encourage social and value creation networks to thrive. The manager will no longer demand that all communications take a certain shape, and will choose not the exert control over all aspects of communication.

None of these three models capture reality. Instead, they capture beliefs about reality that, in this case, drives business decision-making. Each model alters the way we perceive reality, and how we take action based on that perception. By accepting any model, we accept the belief system that comes along with it, and we change our behavior accordingly.

Heuristics

From our short analysis of three organizational models, we can derive several heuristics for helping to evaluate any organizational model:

Heuristic: Compare different models to figure out what one model adds or omits, emphasizes, or downplays.

That is, use one model to discover if there are any gaps in the other. Look for ways one model might give a lot of attention to one aspect and not to another.

Heuristic: Understand the underlying belief system that comes with the model.

If I accept this model, how does it change my belief about part of the world that this model addresses?

Heuristic: Determine whether the model confirms my existing belief system and values, or conflicts with them.

Am I choosing models based on how well they conform to something I already believe?

Heuristic: Understand whether the model addresses or solves a problem that I’m interested in solving.

It may be an appealing model, but do I really need it?

Heuristic: Ascertain whether the model points me to problems I might have but haven’t yet considered.

We find these heuristics are useful for critically evaluating any model, not just organizational models. In this text, however, we’ll stick to organizational models.

Models Distract

As we have shown, a model creates a lens, a way of looking at the problem. Additionally, models often come with a richer set of guidelines or instruction sets, that tell you how to use them.

The organizational hierarchy model, for example, comes with advice on how to achieve a more desirable organizational structure, such as “Don’t have more than 6 levels,” or “Have between 5-30 direct reports per manager,” or “When your organization gets too big, split it along these function.” These guidelines are congruent with the building blocks of the hierarchical model and with the belief system that underlies it.

Guidelines are useful for implementing this model. Whenever you embrace a model, its instructions lead you to considerations that it views as important. It focuses you on the changes that it wants you to make. It’s saying “this is an important thing to worry about”. The things it finds important have names: the levels, the functions, the reports, … Later, we’ll look at models that don’t include names for levels and reports, but do include names for teams, value streams, fluency, or evolution. The choices of things a model names are what puts us in a frame.

But by discussing “How many levels do we need?” we’re distracted from asking the deeper question of “Do we need levels at all?”. Because the hierarchy model comes with a name for levels, it imposes the need for levels.

The methods and tools that come with any model are insidious in that sense. The presuppositions that a model makes are:

The model is adequate (an organization is indeed a hierarchy);
The tools and techniques are adequate (choosing the right levels is the right solution for organizational problems);
If you fail, you haven’t applied them well (choosing not enough or too many levels).

Models rarely include a technique for determining whether the model fits your environment.

If we look at the flat organizational model, we see that it also makes some presuppositions (which conflict with the hierarchy model):

The model is adequate (an organization should indeed be flatter);
The tools and techniques are adequate (removing middle management is the right solution to improve your organization);
If you fail, you haven’t applied them well (you’ve allowed too much of the old hierarchy to survive).

But, again, if we only discuss techniques for removing middle management, we can forget to ask if any functions of middle management are not being handled with a flat organization model. The flat model doesn’t tell us to look for valid functions of middle management, and it doesn’t provide a pattern language for understanding these functions.

Models help you ask questions, but not necessarily the right ones. If we compare different models however, we can take the questions from one model, and ask them in the context of another. By looking at their difference answers, we can see where they diverge. And in the case of the hierarchy and flat organizational models, we can see they have diametrically opposing world views. Let’s look at some software development specific organizational models next.

The Spotify Model

A popular model for structuring organizations is the Spotify Model.² Again, this model introduces elements not found in previous models we examined. Roughly, the model consists of Squads (cross-functional autonomous teams that are responsible for a discrete part of the product, led by a triumvirate of a Product Owner, Tribe Lead, and Agile Coach), Tribes (for coordinating multiple Squads), a Tribe lead that coordinates with other Tribes, and Alliances (for collaboration across Tribes). Then you have Chapters (to deal with shared interests, such as standardization and preferred practices in a field). Finally, a Guild is an ad hoc grouping of people interested in learning a specific topic.

Although the language is different from our previous models, there’s still a clear sense of hierarchy in this model, but it’s fairly shallow. This probably explains why it’s a popular model: it appeals to managers who believe some form of hierarchy is critical to delivering anything, but it doesn’t emphasize hierarchy at all.

The interesting thing about this model is that it introduces two styles of learning into organizational models: one for broad institutional learning (Chapters grow the skills of the organization as a whole and capture that in standards and common practices), and another for individual upskilling (Guilds). Both are knowledge creation networks. All organizations have a need for learning, of course. But by explicitly naming Chapters and Guilds, the Spotify Model is saying that learning is important enough that you should deliberately structure your organization to support it. It says that creating the knowledge network should be on people’s radar as a distinct responsibility, not just an accidental by-product. Underlying this model is the belief that knowledge work requires structural support.

By adopting the Spotify Model, you’re accepting that you need some hierarchy, but that it should be limited; and that besides value creation, individual and institutional learning are critical problems to organize for.

When you first learn about the Spotify Model, you accept implicitly that learning is an important concern. But if instead of merely accepting this model, you actively compare it to other models, you can ask: “Why is it that value creation and knowledge are considered important? Which other aspects does this model exclude, and why?” Comparing models makes it easier to see what each model brings to the table.

How do other models solve for growing organizational knowledge? For example, some organizations introduce Centers of Excellence. These are standalone teams with dedicated skilled members. This is different from Chapters in the Spotify Model, where the members of a Chapter are also members of different Tribes. Because we are aware now that we can organize for knowledge, we can actively seek out other models, and compare how they address it.

Agile Fluency

Let’s take a quick look at another model which is focused on learning. Agile Fluency is an organizational model that represents teams and organizations as being in different stages of their progress in becoming agile. These stages are defined by the activities they do to improve their capabilities and value to the business.

Zone	Benefit	Investment	Learn From	Time to Fluency
Focusing	Greater visibility into teams’ work; ability to redirect.	Team development and work process design.	“Scrum, Kanban, non-technical XP”	2-6 months
Delivering	Low defects and high productivity.	Lowered productivity during technical skill development.	“Extreme Programming, DevOps movement”	+3-24 months
Optimizing	Higher-value deliveries and better product decisions.	Social capital expended on moving business decisions and expertise into team.	“Lean Software Development, Lean Startup, Beyond Budgeting”	+1-5 years
Strengthening	Cross-team learning and better organizational decisions.	Time and risk in developing new approaches to managing the organization.	Organization design and complexity theories	unknown

Image and table: Diana Larsen and James Shore, agilefluency.org

The picture alone doesn’t do Agile Fluency justice of course. The underlying assumption of Agile Fluency is that when your organization isn’t producing enough value, you can solve this problem by first improving individual teams’ capabilities and ways of working, and then restructuring the organization itself.

Like the Spotify Model, this model addresses learning as an explicit organizational need (as opposed to something you tack on). Unlike the Spotify Model, however, Agile Fluency is not a model for structuring your organization. It does recommend that you address your organizational structure, but leaves that to other models. The scope of the Agile Fluency Model is about agile culture and skills.

What this model does introduce is the idea that teams, and therefore the organization, progress over time. This notion of progression is not present (or in any case it is not very obvious) in the previous models we have discussed. It’s not that those models force you into stasis; you can always change things around. But the previous models don’t have the building blocks for representing progressive change. You’re just supposed to change when needed, with no support from the model, and no language for explicitly reasoning about change.

In Agile Fluency, you can impact progress by choosing the appropriate interventions (focusing, delivering, optimizing, strengthening) at the right time, in the right order. The model’s worldview is that doing these activities out of order is not going to yield the results you’re looking for, because capabilities depend on previously acquired skills.

Now that we understand how the building blocks of Agile Fluency represent progress (instead of structure), we can use this view to compare it to other models.

The Spotify Model allows for evolution (you can split up teams and reorganize them), it allows for learning and encourages it by introducing structure for learning. But it stops short at explaining how to use that learning to progress. What should progress or evolution in the hierarchy model, or in the Spotify Model, or any other look like? The answer you come up with, leads to the next question: do I care about progress in my context? Maybe your situation doesn’t call for progression. If it does, you’ve learned something about the gaps and assumptions of the model you use.

Heuristic: Compare different models to understand what you actually care about.

Heuristic: If a model doesn’t explicitly address something you value highly, try fitting in something from another model and see if the model still hangs together.

Another interesting aspect of the Agile Fluency model is that it has an aspirational aspect, and admits this openly. True fluency playing a musical instrument is achieved over a very long time, and after a lifetime you can still learn more. Similarly, with the Agile Fluency model there is no achievable end state, but you should still strive to get in the strengthening zone. It is worth increasing your skills and capabilities, even if you never obtain all its benefits.

Team Topologies

Image: Henny Portman

Team Topologies is a software organizational model that focuses on fast flow and value creation. It advocates composing your engineering organization from four types of teams and three types of team interactions. You should aligned teams on a common purpose, and reduce their cognitive load, so they can be efficient and focused. This model explicitly values reducing unnecessary cognitive load. The patterns (or topologies as they call them) are Stream-Aligned Teams, Enabling Teams, Complicated Subsystem Teams, and Platform Teams. These teams interact using three communication “modes”: Collaboration, Facilitating, and X-as-a-Service.

When you have teams that don’t map directly into these patterns, they “should either be dissolved, with the work going into stream-aligned teams or converted into another team type … [and] the team should adopt the corresponding team behaviors and interaction modes.”³ Of course there’s more to Team Topologies than our summary, but team types and communication styles are the building blocks of the model.

With Team Topologies, there isn’t a static structure with fixed hierarchies as in the Spotify Model. Instead, you combine the team types and interactions to suit your business goals in order to create value. Another difference is that the Spotify Model values team autonomy so much that it doesn’t directly address cross-team collaboration. Team Topologies advocates autonomy as well, but includes collaboration building blocks. However, it advises to keep interactions between teams tightly constrained.

What’s particularly interesting about Team Topologies in our opinion, is that it defines a set of composable patterns. As an implementer of Team Topologies, you are expected to combine these patterns in ways that optimise for flow in your context. Not only that, but you should expect this structure to evolve. When you sense that your context has evolved, you are expected reshape your organization’s team structure by reapplying these patterns. If this sounds like the design pattern catalogs that we have in software design, it’s because it is very much inspired by that idea.

Image: Henny Portman

Like software design patterns, Team Topologies even comes with some anti-patterns, such as team structures and communication styles to avoid. Unlike pattern catalogs, which typically are open-ended (or at least admit that they are incomplete), Team Topologies doesn’t encourage us to extend the model with new team types and interaction modes.

In our context of evaluating organizational models, using patterns and a catalog of patterns that can be assembled to structure an organization is a powerful idea worth exploring. Perhaps the other models would be better served with such a pattern language. Future models could take this approach even further and create pattern languages for other kinds of organizations that aren’t doing software engineering.

Team Topologies is rooted in the DevOps philosophy. Although it seems to claim to be suitable for all software organizations, it only addresses product-centric organizations. We don’t feel it is suitable for systems like life-critical medical devices or railway infrastructure, because it doesn’t have building blocks that address reliability or safety. It is biased towards this premise: create value and enable flow in product-oriented software organizations. It proposes a small, specific set of building blocks as the means to achieve that. If we wanted to, say, organize for human safety over fast flow, we’d need to come up with a different set of patterns for doing so. If we organized for software quality, correctness, worker wellbeing, learning, or domain understanding, our choices will be different again. Optimizing for flow may ignore other important aspects of systems that you may need to consider.

Heuristic: All models are created within a specific context. Does the original context match yours? Can it be adapted?

You could fit a need for considering human safety into Team Topologies, by moving the responsibility for overall safety into a stream-aligned team, having an enabling team to support them, and a platform team to build the necessary infrastructure. But that is not the same as the model being explicitly designed to enable safety. None of Team Topologies’ defined building blocks suggest that a specific team type or interaction mode serves to enable safety. Likewise, nothing in Team Topologies explicitly addresses learning: you can fit learning in there (the book suggests that some enabling teams are really like chapters and guilds from the Spotify Model), but nothing in the model explicitly supports learning. Team Topologies doesn’t have a rich model and language for how teams learn, as exists in the Agile Fluency model.

These omissions are not a problem with Team Topologies per se, but rather a consequence of its focus. Team Topologies has value creation and flow as its scope. By presenting only building blocks for managing flow, it frames flow as the central concern worth organizzing for. Subsequently, it does not include explicit building blocks for learning or safety or programmer happiness. These omissions should be no surprise.

A problem arises, however, if we adopt the Team Topologies model, with its building blocks and patterns and language—thinking it will solve our organizational problem—without first asking whether improving flow is indeed our most pressing need, and whether we have other needs. If we ask such questions, we can avoid the Golden Hammer Syndrome. Furthermore, by comparing models we can figure out what we need from a model and what its benefits and limitations are.

Explicit Building Blocks

Building blocks are explicit, named concepts in a model. They’re not the focus point of the model (like “control” in the hierarchy), but they’re the elements the model uses to create that focus (like the “levels” in the hierarchy).

A building block is a lightning rod. It predictably focuses attention and energy. The things you find most important should be first class building blocks in the model you’re introducing.

Heuristic: If you care about something, have a building block for it.

When you have a building block for something important, it draws people’s attention. Simply by existing, that building block tells people that this is something that requires their consideration. If, on the other hand, there is no building block for it, people might still give it attention, but there is no home for it. Any attention given could be spotty, brittle, temporary or even deemed unwelcome.

Most of the time, when you introduce a new model, you’ve spent the time understand it and buy into all it has to offer. But others will not understand it as deeply as you do, nor will they apply it as rigourously as you do. You may understand where the model can be extended or adapted, but others will apply the model as is. So even if you can make the model work for your context by combining its building blocks with your adaptations, it doesn’t mean others will. They are more likely to do it by the book (or by following your instructions). Adapting the models and their building blocks to your needs, gives you influence over people’s attention, and therefore over the outcomes they produce. If you don’t adapt these models, bringing focus to what you value will be much harder.

If, say, you’re reorganizzing and you want to improve how institutional learning happens in your organization, you can either pick a model that explicitly addresses it with its building blocks (for example, Chapters and Guilds in the Spotify Model), or you can adapt another model to suit your needs. It’s not that this learning won’t happen in, say, a hierarchy or Team Topologies. But without the attention-grabbing power of a good, explicit, and well-explained set of building blocks, there’s not much that tells others what to do and how to do it.

In all knowledge organizations, individual and institutional learning is important. If you’re looking to apply an organizational model, you can ask how they deal with learning, and whether that’s important to you. If learning is happening smoothly, you don’t need to touch it. But if you feel it requires change, you need to have learning explicit in the model.

If instead of improving learning or flow, you want to improve the quality of delivery, or the safety of life-critical systems, your organizational building blocks would need to express that, whether they’re blocks for types of teams, interactions, activities, meetings, or reports.

When the Team Gets Too Big: a Case Study

Models guide our choices for appropriate actions to take. As an example, let’s ask what we should do when a team gets too big. We’ll compare what different models suggest we do, to see what they teach us about their approach, and their underlying value systems.

Heuristic: When you’re evaluating models, find questions that are relevant in your context, and use them to compare the models.

In a traditional hierarchy, when a branch has too many people, you add more subbranches and a corresponding layer of management to manage the people who report to them. At some point, when a hierarchy gets too deep, you make it wider: you split it apart by adding departments or business units with their own management, and allow these to each have their own hierarchies. The value system behind hierarchy is control. It assumes that to scale control, you need to delegate control and control the controllers; so the idea of growing deeper or wider is embedded in the model.

From Jason Yip, a Senior Agile Coach at Spotify, we get some clues on how Spotify deals with splitting squads or tribes:⁴

“You wait for seams to appear: clunkiness in communication flow and interaction patterns. (…) Then you nudge things apart. Maybe a subgroup of people has a slightly different rhythm and events. Nothing formal, just nudging things apart. Over time you notice, hey, I’m not interacting with the other people in the team anyway. So you just formalize that [split]. If done correctly, this is mostly an acknowledgment and a non-event.”

Jason calls this “organic organizational design.” In that model, structure should always follow strategy.

In Team Topologies, when the flow of a Stream-Aligned Team slows, or the team is experiencing increased cognitive load, then it’s grown too big. To fix this you would look for multiple value streams hiding in there, and split the team according to those lines. You could also look for people working on a highly specialized aspect of the value stream, and move them to a separate Complicated Subsystem Team.

When a Platform Team gets too big, Team Topologies suggests that the topologies are fractal. The Platform Team acquires internal topologies, consisting of internal Stream-Aligned Teams, Complicated Subsystem Teams, and Enabling Teams.

The Spotify Model makes no mention of Platform teams, but how would it solve the problem of a Platform Team getting too big? We think that you would create a Chapter that oversees and supports multiple Platform Teams, helping them with standardization and tooling, but you wouldn’t have them impose too much. This solution is different from a Team Topologies’ Enabling Team, because the Chapter is composed of people from across the different Platform Teams.

Contrasting Spotify and Team Topologies

Interestingly, Team Topologies has no building blocks for any kind of group that spans people from different teams. Of course, a Team Topologies organization could have such groups, but as a model it doesn’t tell us to have them, doesn’t tell us how to organize them, or even to recognize that such groups exist.

In the same sense, Tribes are another key difference between the model at Spotify and Team Topologies. Tribes are larger structures than squads. A Tribe manages strategy and goal-setting at a higher level. According to Jason Yip, Squads are less important to preserve than Tribes. Tribes can evolve fast and react organically to change. Team Topologies puts teams first, suggesting to make them long-living and seeing teams as the central unit of organization. Teams are the only tool for looking at organizations, so there’s no natural place for organizzing in terms of business strategy. You organize for flow.

Another fundamental difference between these two models is that the Spotify Model doesn’t mention cognitive load. Instead, it talks about clunkiness, friction, long meetings, … The term “cognitive load” doesn’t show up in its vocabulary. By naming cognitive load, Team Topologies calls attention to it, telling us explicitly to look for and reduce it.

Team Topologies and the Spotify Model also perceive interaction between teams differently. The Spotify Model assumes interactions happen organically inside Squads, between Squads in Tribes, and cross-cutting though Chapters and Guilds.

Team Topologies sees too much interaction as an inhibitor to fast flow. Consequently, interactions need to be designed explicitly. Teams are supposed to be limited to as a few as possible interactions and interaction styles. Ideally, these interactions are expressed in a “team API”: a set of well-defined places where communication happens, such as pull requests, issue trackers, or chat channels.

Finally, when an interaction doesn’t work well in the Spotify Model, an Agile Coach will intervene. That Agile Coach is an explicit building block in the Spotify Model. In Team Topologies, there’s no building blocks for coaches, managers, or other roles that can intervene. (Possibly, Team Topologies wants teams to self-organize, but there’s also no mention of that option.) Again, lack of an explicit building block doesn’t preclude you from having manager roles in Team Topologies, but you won’t get any support for them from the model. Team Topologies doesn’t tell you to focus on such a role or the value it might bring to the organization.

Comparing Models Yourself

We encourage you to compare models to evaluate them. As we have shown, one way to compare models is to ask questions about how those different models might handle a particular problem you are interested in solving. To get started, pick situations (real or imagined) relevant to your environment and test them against the models. Then, try to imagine how each model would handle them.

This is speculative: during this evaluation you’re taking a theoretical view of how the models work and how they stack up against each other. That will never beat the insights you can get from practical experience applying the models. But it’s much cheaper to test-drive a model through realistic scenarios, than it is to put it into practice only to uncover big surprises a year down the road. Besides the measurable costs, reorganizations lead to “reorg fatigue.” Likewise, models that address aspects other than organizations might have varying costs. Running thought experiments with scenarios this way teaches you something about the value system of each model early on. It also exposes whether the model cares about the same things you find important.

As you run various scenarios, you’ll notice that:

some models may give very detailed advice (eg “split a team when it exceeds 10 members”);
others offer only vague guidance (eg. “teams shouldn’t be too big”, without quantifying what is too big or what should be done);
some models have nothing to say about that specific situation.

None of these are bad things. All models include and omit different things, and give more practical or more broad advice. But when applying model you need to understand who you’re getting married to.

Now that you have some ideas on how to compare models, we’d like to give you some more clues. First, we’ll discuss how some models (or their authors) are authoritative. They provide one way, and aren’t open to being extended. Then, we’ll discuss how our own cognitive biases can influence our perception of models. Finally, we’ll look into how models are intended to be used: as observational tools, or as prescriptions of how to act, or even as aspirational guidelines for a future state.

Bossy Models

You might be familiar with SOLID. It’s a set of five object-oriented software design principles. The first letter of each principle forms the word SOLID. For example the Single Responsibility Principle is the “S” in SOLID. This model gives us a framing right off the bat:

There are only five design principles worth caring about.
It’s these five that matter, and not any others.
They apply to all software design, independent of context.
You’re not just supposed to apply these principles in an ad hoc fashion, but you’re supposed to apply them at all times.
The name implies that by applying them, your design will in fact be solid, which is a good thing.

As before, we want to break out of the framing of this model, so that we can understand it better. Here are some questions we ask: Why five? Why these five and not others? What if a sixth principle is discovered? In what context were these principles formulated? Do they apply to the design of all kinds of software in all contexts? Are they as true now as they were 25 years ago? Has software design changed since then?

As evidenced by their framing, it’s clear that the authors intended for this model to be authoritative. As an adopter of this model, you’re not supposed to extend it, or challenge it. (And many of its adopters seem to buy into this framing.)

In reality, there are dozens (if not hundreds) of design principles that have been discovered, long before and long after SOLID. And yet, the SOLID model didn’t adapt. Even if you wanted to evolve it, SOLID doesn’t offer any hooks for extensibility.

The Hierarchical organization model is another example of a definitive model. The building blocks are the hierarchy, where decisions made at the correct level are pushed down, and the reporting goes up the hierarchy chain. There’s no room in the scope of the model to extend it. Extend the hierarchy differently, altering decision-making, or changing the reporting structure, doesn’t fit in the belief system that underlies this model.

Some models are authoritative and definitive, while others are open to being extended. But models rarely make this distinction explicit. They don’t tell you whether to extend them and in what ways. It’s hidden in the language they use, the names and the structures they propose, and in the communications of the authors about the model.

Often, all you need is a straightforward model to tell you how to do something. In this case, the model’s simple building blocks are an enabling constraint: they help you to see something clearly, and make progress faster. In other cases, an authoritative model that seems suitable at first sight, can become a limiting constraint over time. In this case, on top of dealing with your original problem, you’re now also faced with problems caused by the limitations imposed by the model. You start force-fitting things into the building blocks, instead of using the building blocks to achieve your goals. Force-fitting causes you to lose essential components of your context because they don’t fit the model. Inversely, it also causes you to overemphasize unimportant components of your context because the model gives them focus. The metaphors that the model uses, can distort your perception of your context.

Finding alternative models, again, can help us out of this problem. In the case of the Hierarchical model, it’s the Social Network and the Value Creation Network models that break us out of constraints. They tell us to stop accepting the framing of the Hierarchy.

Heuristic: Are you fitting the model to your context, or are you force-fitting your context to the model?

Getting Too Cosy with the Model

When we are faced with something new, like a model, we are initially inclined to question it. But we want to believe. We like certainty. So as soon as we’re comfortable with the model, we stop questioning. Being in a state of cognitive ease makes us more accepting of new information or ideas.

Successful models tend to have some characteristics that contribute to our cognitive ease. They have a small number of building blocks clearly presented (perhaps even simplistically so), usually 7 or less. There’s symmetry, balance, and the structures are often repeating. Strangely, these characteristics make us believe the model is more sound, more rigorous, better thought out. It may well be, however, that the model’s structure has been simplified to be symmetrical, balanced, repetitive, and slim. We associate feeling at ease with goodness. Visualizations that fit our sense of “good” structure also help sell a model: quadrants, pyramids, funnels, radars, Venn diagrams with three neatly intersecting sets.⁵

Anecdotes are another tool for putting us at ease. If something is explained to us through stories, we’re more likely to accept it. We trust the story that a familiar face tells us more than when someone gives us critical facts. When a model comes to us with anecdotes of how it contributed to a successful outcome, we don’t question the story.

When we’re at cognitive ease, we trust our intuitions. We narrowly frame our problems to fit the models we’re comfortable with. We become overconfident.

The remedy to cognitive ease is a healthy dose of skepticism, aimed not just at new models, but at our existing models as well. Skeptics examine things, even if this makes them uncomfortable. They let go of certainty in order to see more of what the problem really is and what the model has to offer. We use “getting out of your comfort zone” for social situations or challenging tasks, but it applies to our inner world as well.

Heuristic: Be more skeptical of nice models, be more open minded to jarring models.

Be on the lookout for things that don’t fit, that are slightly awkward, that break the nice structure of the model you’re using. Allow yourself to entertain multiple competing models at the same time, and to context-switch between them liberally. This gives you a certain freedom: no longer boxed in by a single model, you can come to see the models for what they are: potentially useful worldviews, not “truths.”

Heuristic: Models are potentially useful worldviews, not truths.

Prescriptive, Descriptive, Aspirational

In the 16th century, the word network referred to wires or threads arranged in a fishing net like construct. In the 18th century, the term network was adopted to first represent railroads and canals, by the 1940’s it meant radio broadcasting, then was linked computers in the 1970’s, and finally, in the 1980’s, it acquired the meaning of building human relationships. Our modern use of the word is a metaphor, with extra steps.

The model that introduced the social network inside organizations is descriptive. Someone observed their environment, and noticed a pattern of informal communications. They then mapped this pattern to the metaphor of the network. Using the network metaphor, they found a shortcut to describe these real-world patterns. Perhaps you have seen these informal communications as well, but you had never truly noticed them. But then, when someone points out to you that it is a social network, a lightbulb goes on. You now have a language for it.

A descriptive model doesn’t have an intention, it only means to clarify, and help you see something in a new light. This change of perspective does have consequences: you might change your behavior, for example, by creating opportunities for people in your organization to mingle socially.

A prescriptive model, on the other hand, deliberately aims to change your behavior. The Spotify Model clearly has this intention. It’s telling us that our situation will improve if we restructure our organization according to the prescribed building blocks. The Spotify Model originated as a descriptive model of how people organized, before it was turned into a prescriptive model for organizations by others later.⁶

Heuristic: Does this model help me see something clearly, or does it intend to create a change in behavior?

The distinction between descriptive and prescriptive is not as a clear cut as we might like. Only in science do we find purely descriptive models. While the social network model intends to be descriptive, by introducing the term into your organization, you make a value choice. You’re saying that organizations should care about the social network. Usually this is followed by a prescription of how to do that. You may want to enable this network, leave it to evolve organically, or prohibit it. When you adopt a model that you believe to be descriptive, but that actually comes with an underlying value system that you unconsciously adopt, then the model controls you. You are inadvertently allowing it to affect your behavior. By critically evaluating whether a model is mostly descriptive or prescriptive, you can choose to adopt its values and use its prescriptions more intentionally.

Heuristic: Find the prescriptions hidden in innocent looking models, and use them to your advantage.

Some models go even further: they are aspirational. They describe an ideal situation that has not been observed before. The author has created a model of how they believe the world could work, but has not actually applied it, or only partially. Aspirational models serve as a call to action. They speculate that, if we were to adopt all its prescriptions, we could get close to that ideal state, but perhaps never reach it. If we understand that a model is aspirational, then our goal is not to apply it precisely to the letter, but to get as close to it as is useful and practical. Interestingly, some models start as aspirational, but as people start getting better at explaining and implementing them, they observe that the model does indeed give them its stated benefits. If used wisely, aspirational models can drive positive change by getting people to see a new possibility.

Heuristic: Consider that some models may not actually have been tried by the authors.

Putting the Model to Work

With many of the models we acquire throughout our lives, we only engage superficially, and that’s fine. We absorb and assimilate a lot of things without ever deeply engaging with them. This happens when, for example, you’re being onboarded at a new employer, and you simply learn their operating models for doing things in certain ways. The same goes when you’re given some design specifications and implement them as stated. And as a student, you’re usually expected to learn and adopt the models you are taught.

But when we’re trying to achieve something important, we need to take a more critical view. After learning of a new model, we need to decide whether we want to put it to work to help solve our problem. We need to engage more deeply with that model before we decide to commit to it. What if we could make this engagement an intentional process?

What we’ve been trying here, is to identify competing models and to compare them to understand their benefits and limitations, their framing, their values, and the contexts in which they apply. This comparison breaks us out of thinking there is only one option to solve our problem.

We’re making an upfront analysis of a model, before we invest in the model too heavily. This comes with risks: Because we haven’t lived with this model yet, we might be overanalyzing things. We may discount some of benefits because they only surface after spending some effort implementing the model. Still, if we do this analysis upfront, it saves us effort that we would otherwise waste on implementing an unsuitable model. As we’re not invested deeply yet, it’s much cheaper to identify faults in a model and how address them. To avoid the risk of “analysis paralysis,” we remain conscious that no model is perfect, but may still be useful.

Heuristic: There’s always another possible model.

Then, when we find a new model that has a reasonable representation of the problem we’re trying to solve, we can adopt it. We apply its building blocks, and execute the activities it prescribes. As we do, we need to be observant: there is a thin line between learning to adopt a model, and overfitting a model to our situation. This friction is valuable data. Maybe the model has problems, lacks detail, has too much detail, focuses on the wrong aspects, has unintended consequences, or doesn’t directly tackle the problem we’re actually trying to solve. Maybe the model doesn’t fit that well. Or perhaps we don’t want to use the model in the way it’s prescribed. Perhaps we have different values than those supported by the model. If we collect this feedback early, we can use it to reexamine the model.

Heuristic: Following a model as prescribed is not the same as achieving success.

In other words, no matter how beautiful your diagram of hierarchies, Squads and Tribes, or Stream-Aligned and Enabling Teams is, the proof is in the pudding.

As we gain more experience with a model, and learn from feedback, we’ll feel more comfortable reshaping the model, bringing in elements from other models we previously dismissed, adjusting it to our context, and making it truly our own.

In summary, these are the five steps for engaging with a model:

Intentionally study models
Analyse and compare them critically
Adopt a model in your context
Gather feedback about the impact
Reshape it to your needs

Did we just present to you a 5-step model for evaluating models? Are there other models for evaluating models you can compare this one to? Should you adopt our model or create your own? Does our model put you in a certain framing that isn’t relevant to your context? We leave all these question as an exercise for the reader.

Conclusions

Our worldviews and behaviors are mostly the result of other people’s models that we’ve assimilated, along with their biases. Models give us a framing, they highlight some aspects of the problem and obscure others. This is useful, assuming they focus on aspects that are important to us.

When we introduce an unsuitable model into our environment, it distracts us. It makes us ask questions in the framing of the model, and we don’t see that we should be asking different questions. It does this through its building blocks. These building blocks act like lightning rods. They attract the attention and energy of the people who are engaging with them.

Understanding a model’s framing is hard, precisely because we’ve been put into that framing. In that sense, we’re like the fish who can’t understand the world outside of the fishbowl, because nothing in their environment offers any building blocks to explain and structure it.

Acknowledging that you have limited agency is liberating. Comparing a model to other models gives us an edge: we can see more clearly which aspects we could highlight or obscure. By comparing models, we can break out of their constraints, and engage critically with the models.

You can choose which models to let in.

Written by Rebecca Wirfs-Brock and Mathias Verraes.

Share this article on Twitter or LinkedIn
Follow Rebecca on Twitter, LinkedIn

Footnotes

Is it Noise or Euphony?

Posted on August 26, 2021 by Rebecca

The book Noise: A Flaw in Human Judgment by Daniel Kahneman, Olivier Sibony, and Cass Sunstein has me thinking deeply about noisy decisions. In this context, noise is defined as undesirable variability in judgments. They explain two different kinds of noise—level noise (variability in the average level of judgments by different people) and pattern noise. Pattern noise is further broken down into the unique noise individuals bring into any decision and occasion noise—noise caused by the particular context surrounding particular decisions. Occasion noise can be influenced by our mood, the interactions with people we’re deciding with, what we ate for dinner last night, or even the weather.

So when is noise worth reducing? And what can we do to reduce that noise? How do we know our efforts at noise reduction have the desired effect?

Are there situations where variability might be desirable? I haven’t found a name in the literature for such desirable variation. Perhaps euphony—a harmonious succession of words having a pleasing sound—is one possibility. In these situations we’re favoring finding some euphony over conforming to a noise-free rigid standard for our judgments.

I’ll use the review of conference submissions of papers, talks, and workshops as an example of where both noise and euphony play a part in our decision-making, as it is one I am quite familiar with.

One major source of variability is when new reviewers join a review committee. Newcomers often look at submissions differently than experienced reviewers. But not all variability is noise. If some variability is welcomed, expected, and encouraged, the review process greatly benefits from fresh perspectives. This kind of variability adds spice.

And yet, there may be standards (whether formally written down or more loosely held) we’d like uphold for what we consider a worthy submission. One way to reduce level noise in reviews is to ensure that reviewers understand these expectations. One way to convey this information is to hold a meeting where we discuss and present examples of submissions and exemplary reviews (reviews from prior years are a good source). Newcomers can learn what a reasonable proposal is and what is expected in a review. They also get to know their peers, ask questions and, in effect, “calibrate” their expectations for reviewing.

But this meeting is insufficient to remove another major source of noise—occasion noise caused by group interactions. Kahneman, Sibony, and Sunstein state: “Groups can go in all sorts of directions depending in part on factors that should be irrelevant. Who speaks first, who speaks last, who speaks with confidence, who is wearing black, who is seated next to whom, who smiles or frowns or gestures at the right moment—all these factors, and many more, affect outcomes.” Group dynamics introduce noise.

But there are several practical ways to further reduce the noise in group decisions. Oscar Nierstrasz wrote a set of patterns called Identify the Champion for reviewing academic papers. I encourage anyone running a conference to consider a review process along the lines of what Oscar introduces. I’ve adapted these patterns and process to non-academic conference reviewing with only a few minor tweaks.

The key ideas in these patterns are the roles of champion and detractor, and a structured process for discussing submissions. Champions are strong advocates for a submission who are prepared to discuss its merits; detractors disapprove of a submission and are prepared to discuss its weaknesses.

Submissions are discussed in groups according to their highest and lowest scores. Care is taken to identify proposals with both extreme high and low scores, and to not to rank submissions numerically. If a submission has no champion, it isn’t discussed. It is rejected. Ranking and then discussing submissions one-by-one in order would only add level noise (actually I find we get numbed by reviewing and tend to reject “lower ranked” submissions without enough consideration).

The review committee is asked to suspend final judgments until all championed submissions are presented. The champion is first invited introduce the submission and explain why it should be accepted. Then, detractors are invited to state their reasons. At the end of all presentations, discussion is opened for all and the committee tries to reach consensus.

In practice, following this discussion protocol, it is easy to accept outstanding submissions—they typically have plenty of champions. This leaves the bulk of our time to dig into the strengths and weaknesses those championed submission that have mixed reviews.

The Identify the Champion process forces me to hit “pause” on my judgments and to not jump to premature conclusions. And the first thing we hear about any submission are its positive aspects. When detractors speak, I get a richer understanding of that submission. Although I might have had some initial impressions, I find they can and do change.

Sometimes I warm up to a submission. At other times, detractors’ perspectives grab my attention and make me revisit whether the submission is as strong as I had initially thought.

The cumulative weight of all this discussion has an even more profound effect. I find I am much more accepting of the outcome: what will happen will happen. Yes, there is unpredictability in this decision-making process. But we’re all trying to make reasonable decisions as a group. I end up actively engaged in making the outcome the best it can be and supportive of our collective decisions.

Although the Identify the Champion review process still has noise (it is hard to eliminate noise caused by group dynamics entirely), I believe it to be less noisy than most other review processes I’ve participated in.

One downside, however, is that it can be exhausting. To avoid having some occasion noise creep back in, it’s good to ensure that reviewers get sufficient breaks to meet their personal needs, and not get too tired or cranky or hungry.

One place I’ve applied my adaptation of the Identify the Champion pattern is for Agile Alliance experience report submissions. Experience report submissions are “pitches” for written experience reports. Only after a submission has been accepted does the actual writing begin. So as reviewers, we’re not only judging the topic of the pitch but also whether the submitter will be able to write a compelling report. Champions of experience reports also commit to shepherding the writing of the reports. These shepherd-champions commit to reviewing and commenting on drafts of reports are as they are written over a period of several weeks. Now that’s real commitment! Frequently we have more championed submissions than room in the conference program. So our judgments come down to some difficult choices.

Before we hold our review meeting, we ask reviewers to give us two lists: submissions they’d like to shepherd and an optional list of submissions they’d like to see on the program (but do not want to shepherd). At our meeting, we then have a lively discussion where champions forcefully advocate for their proposals and gain others’ support. Once again, I find we spend most of our time discussing those submissions that have mixed reviews. But we also spend time a lot of time listening to champions and then as a group making tradeoffs between submissions (remember we have more good submissions than we have capacity to accept them). The message we convey to all reviewers is that that if you really want to shepherd a submission, we as a group will support your decision to be a shepherd-champion. But let’s discuss first.

We can’t guarantee the quality of any final report. We base our judgments on both what the submitters have written (in many cases, there has been a back and forth conversation between submitters and reviewers that we can all see that has led submitters to reshape and refine their proposals) as well as the convincing arguments of champions.

Judging conference submissions is subjective. Our process acknowledges that. We accept the risk of selecting a less-than-stellar report proposal over missing an opportunity for a novel or insightful report.

Is it our goal to eliminate noise in our decision-making? Where we can, yes. But, that isn’t our only goal. If we tried to eliminate it entirely we might end up establishing standards for experience report submissions that would inadvertently filter out newness or novelty. In our search for a bit of euphony we stretch out to accept a submission if there is a convincing champion. Consequently, we accept a little variability (and unpredictability) in our decision-making. However, at the end of our review process, reviewers are generally happy with the proposals we accept, happy with their shepherding assignments, and eager to begin working with their experience report authors. An important aspect of our process, which cannot be understated, is that we also work hard to make good matches between each champion-shepherd and prospective authors. Not only do reviewers buy into the review process, they also commit to being ongoing champions.

Noise reduction is important in many situations, especially group decisions. Paying careful attention to how the group is informed, discusses, and then decides can reduce noise. Paying attention to the voices of champions is one way to turn up euphony. By tuning your decision-making processes you can achieve these goals.

Noisy Decisions

Posted on August 18, 2021 by Rebecca

“The world is noisy and messy. You need to deal with the noise and uncertainty.”–Daphne Koller

I have tinnitus. When there isn’t much sound in my environment, for me it still isn’t quiet. I hear a constant background hum. It is hard to describe what this noise sounds like. I’ve lived with it for too long. Remembering back to when I first noticed it, I thought there was some nearby electrical device humming. Was it my phone plugged into the wall outlet? Or??? I remember getting up from bed to hunt for the source of that noise.

I can’t forget that noise or ignore it. It doesn’t go away. But it doesn’t dominate my headspace. I’ve learned to slip between that noise and my desire to sleep or to just be in a quiet place, and not let it distract me. I’ve learned to deal with tinnitus.

Recently I finished reading Noise: A Flaw in Human Judgment by Daniel Kahneman, Olivier Sibony, and Cass Sunstein.

The entire book is about the “noise” in human judgments and what we can do to lessen its effects. So what exactly is this noise? A simple definition is “noise” is undesirable variability in judgments. Call this system noise if you will.

Both recurring and onetime decisions are influenced by noise. Depending on the time of day, how well I slept last night, what others say, and even how we as a group decide how to decide effects my judgment. This noise, in addition to any biases I have, affects all my judgments.

Kahneman, Sibony and Sunstein introduce two different types of system noise: level noise and pattern noise. Let’s consider each in turn.

Level noise is easiest to understand. It is the variability in the average level of judgments by different people. People judge on different scales. Consider rating a talk at a conference. Perhaps you never give a conference speaker the highest possible rating because you believe they could do better. Or, maybe if you are star struck, you always rank a presentation from a well-known speaker more highly. Personally, I know that I tend to not rate speakers either as very high or very low, because, well…I’m sort of middling with my ratings. On average, humans aren’t average in their judgments.

The other kind of noise, pattern noise, is often an even bigger factor in our judgments. It is comprised two parts: occasion noise and our own personal idiosyncratic tics. Occasion noise is the variability in the judgment at different points in time. Depending on my mood, how stressful the situation, how well I slept last night, or how the question is put to me, my judgment will vary. A simple example of occasion noise that software folks can relate to is estimating how long it will take to complete a task. My mind isn’t the same today as it was yesterday. Heck, from moment to moment, I might give a different answer simply because I am thinking about the task differently, or I that I am hungry (and hence tend to come to a snap judgment), or I’m grumpy, or I’m happy.

The second source of pattern noise is our personal attitudes toward the particular judgment context. Consider, for example, this kind of noise when reviewing conference proposals for papers or talks. Some reviewers are harsher in their personal rating for some proposals and more lenient in others. This variability reflects a complex pattern in the individual attitudes of reviewers toward particular proposals. For example, one person may be relatively generous in their review of proposals on a particular topic. Another may be particularly keen on proposals that seem to break new ground but be a harsher judge of proposals on topics that are perceived to cover familiar territory.

As Kahneman, Sibony, and Sunstein state: “Noise in individual judgment is bad enough. But group decision making adds another layer to the problem. Groups can go in all sorts of directions depending in part on factors that should be irrelevant. Who speaks first, who speaks last, who speaks with confidence, who is wearing black, who is seated next to whom, who smiles or frowns or gestures at the right moment—all these factors, and many more, affect outcomes.”

Having been part of many conference review teams as well as on the receiving end of their reviews over the years…I find that the dynamics of group decisions to be a particularly salient example of system noise.

The information about system noise in general and noise in group decision making can be rather depressing. If we humans are naturally wired to be imperfect and flawed in our judgments, how can we hope to make reasonable decisions? And, once we become aware of our judgment errors, and try to be better decision-makers, the actions required to lessen the effects of noise these authors suggest seem surprisingly difficult to carry out.

Awareness is a good first step. But it’s not enough. In contrast to tinnitus, of which I’m constantly aware, the noise in our judgments is at first difficult to perceive. But once you become aware of sources of system noise, you start noticing them everywhere. How and when (and even whether) it is appropriate or feasible to mitigate these sources of noise is a topic for another day.

What we say versus what we do

Posted on April 25, 2019 by Rebecca

I’ve been hunting design heuristics for a couple of years. I’ve had conversations with designers in order to draw out their “go to” heuristics. I’ve joined design and programming sessions with experienced designers and captured on-the-fly what we were doing. My goal is to learn ways to effectively find heuristics in the wild, distill them, and then share them broadly.

But lately, I’ve been thinking about how to deal with this puzzle: What people say they do isn’t what they really do.

Let me give you an example. I joined the Cucumber folks last summer for several remote mobbing sessions. One heuristic they shared with me was this:

Heuristic: the person who has the most to learn (or knows the least about how to solve the problem) should take on the role of driver.

In “classic” mob programming as initially described, the person who is the driver and has his or her hands on the keyboard follows guidance of navigators—other mobbers who ostensibly guide the driver on what to do in order to make progress.

“In this “Driver/Navigator” pattern, the Navigator is doing the thinking about the direction we want to go, and then verbally describes and discusses the next steps of what the code must do. The Driver is translating the spoken English into code. In other words, all code written goes from the brain and mouth of the Navigator through the ears and hands of the Driver into the computer.”

What I observed the Cucumber mob doing was somewhat different. Sometimes the driver had an initial design idea and was keen to try it out. In this case, they often actively navigated and drove at the same time. Occasionally others would comment and offer advice. But mostly they just watched the design and implementation unfold. Sometimes that eager driver asked the others, should we try this now? But instead of waiting an uncomfortable length of time for them to chime in, the driver often continued on without any discussion. And I don’t think that driver was asking a rhetorical question. They wanted feedback if someone had any.

At other times the driver would stop to collect their thoughts and force a discussion. In this case the driver became uncomfortable when they didn’t get enough feedback. And sometimes they took themselves out of the driver’s role, asking someone else to fill in. In short, while I observed that driver was often in control of the wheel (and forward progress), at the same time, they didn’t overly dominate. Drivers rotated. Every one got their turn. But how these switches happened was very dynamic.

In all fairness, the mob programming website did touch on drivers and their participation in discussions:

“The main work is Navigators “thinking , describing, discussing, and steering” what we are designing/developing. The coding done by the Driver is simply the mechanics of getting actual code into the computer. The Driver is also often involved in the discussions, but her main job is to translate the ideas into code.”

While the main job of the driver may be “mechanics,” the small fast moving Cucumber team didn’t insist that getting the code into the computer be the driver’s main function. Now mind you, I suspect being remote affected their style of communications. They also knew each other well and knew each others’ common design approaches and preferences.

So why did the Cucumber mob behave this way? Did they believe one way but consciously act in another way? Did they intentionally lie about their heuristics? Or were they deceiving themselves? Are people wired to explain what they do through some kind of distortion field? How often do people believe one thing (and hold it up as an ideal) but then choose alternative heuristics? If so, is this OK?

I’m not sure the team was aware that their ways of driving/navigating deviated from the conventional driver/navigator roles until I shared my observations with them. I suspect that when they first started mobbing they were more rigorous about following the “rules” for these roles. Over time they found their own ways of working. And so the heuristics they collectively use to decide what to do, what design approach to try next, and how they interact with each other are much more fluid and nuanced than the simple descriptions of drivers and navigators on the mob programming website. They don’t exactly go “by the book.” And I suspect their heuristics for how they work together are still evolving.

So how should I as a heuristics hunter reconcile my simple goal of distilling essential heuristics with the messy realities I find on the ground?

Should I plunge into a concerted effort to sort out and formulate more nuanced heuristics? The short answer is, yes. While I want to find and record both general and more particular heuristics, I’m not inclined to want to sort them out into tidy, neat categories. After all, as Billy Vaughn Koen says, there is more than one way to solve any design problem and more than one heuristic that can work. By recording these nuances, I hope to get richer insights into the different conditions and cases and situations that lead to choosing them.

This still leaves me with one nagging question: How can I reconcile what people say they do and believe with what they actually do? My (current) approach is that as I distill heuristics I also describe the context where I find them. Should it bother me that designers don’t do as they say they do all the time? Probably not. After all, we’re wonderfully creative problem solvers. And there are always options.

It’s Not That Simple: The Interplay Between Fast and Slow Thinking

Posted on May 10, 2016 by Rebecca

Our system 2 thinking observes and constantly monitors our actions and thoughts (unless it is tired or compromised). It helps regulate our behavior and to:

Control impulses and stop doing something that we consider inappropriate (such as eating that second piece of pie) or do something, even if we don’t like it (such as not rising to the bait in a political discussion);
Manage our energy, emotions, attention and behavior in socially acceptable ways to achieve our goals;
Stay calm, focused, and alert; and
Deal with daily stresses such as noise, fatigue, challenging situations or tasks, or distractions.

System 2 thinking doesn’t merely look over your shoulder to “correct” illogical system 1 thinking. The interplay between these two systems is much more complex. The two systems have deep connections and influence each other.

Emotions generated by fast thinking affect logical system 2 thinking. And fast thinking, when it doesn’t find meaningful associations that fit the current context calls upon the logical system 2 for help to interpret what is going on.

I had an opportunity to experience this interplay sitting in a bar talking with Linda Rising at an agile conference. A loud angry voice coming from the lobby abruptly interrupted our conversation. Initially, I was frightened. Then annoyed. Then irritated. (My emotional system 1 thinking kicked in). The yelling didn’t stop. Did someone need help? Why was the yelling man so upset? (Again, my system 1 was trying to connect yelling with some reason to be yelling). But I couldn’t understand what the yelling was about. And then, seemingly out of the blue (system 2 thinking coming to the rescue) I remembered that there was also a conference in the hotel on Tourette’s syndrome. That loud angry voice now made sense. It was the voice of someone with Tourette’s.

It is too simple to say that our brain is either emotional and associative (fast thinking) or logical (slow thinking).

We don’t get to choose which form of thinking we use.

The two systems interact…and that’s where it gets really interesting. Being aware of how my brain works hasn’t stopped me from being swayed by my emotions. But it has made me more aware of thinking dynamics. I may not be able to stop my knee-jerk reactions, but I am aware now that my delayed reactions and thoughts might also be helpful, if I give them enough time to surface.

On Thinking

Posted on April 25, 2016 by Rebecca

Daniel Kahneman, in Thinking Fast and Slow, introduces two “systems” of thinking: fast or type 1, and slow or type 2. We don’t actually have two different parts to our brains—but we do have two distinct types of thinking mechanisms, each with their respective strengths and drawbacks.

Fast thinking happens automatically with little or no effort or sense of voluntary control. Quick, what’s your first reaction to this photo?

My immediate visceral reaction: “That dog is ugly! It looks crazed, angry…. scary.”

The dog is Peanut, winner of the 2014 Ugliest Dog contest. His wild hair, bulging eyes and protruding teeth are at odds with his sweet personality. Holly Chandler of Greenville, North Carolina, Peanut’s owner says he was seriously burned as a puppy, resulting in bald patches all over his body. Peanut is healthy now and nothing like my first impression.

In a nutshell, fast thinking is automatic (we do not have to work at it), impulsive (we can’t easily control it) and emotional (once I’ve told you a little about Peanut you probably feel sorry and sad and more positive towards Peanut, despite your initial reaction). Fast thinking draws on our amazing abilities to quickly form associations between related things. When it works well, we easily come to conclusions, draw out inferences, and confidently decide without breaking a sweat.

It’s sweet when your associative memory clicks along in high gear providing ready answers. But fast thinking can be subtly and easily biased. The variety of cognitive biases we have is astonishing.

In contrast, slow or system 2 type thinking requires energy. We get tired when we do a lot of slow thinking. We use slow thinking to reason logically, compute, or, surprisingly, when paying attention to someone speaking to us in a crowded noisy room. Both writing code and writing prose are slow thinking tasks for me. Reasoning about the cause of a bug is too. The fast cycles of strict TDD help some with breaking up the necessary slow thinking into more manageable chunks. For me, deciding what the test should be and how to implement my design ideas are almost always slow thinking tasks. Writing code may or may not be, depending on how familiar I am with the programming language, tool set and design context.

It is too simplistic to say that our brains are wired to be either emotional or logical. We don’t always get to choose which form of thinking we use. Even more interesting is how the two systems interact. Our system 2 constantly monitors our system 1 thoughts, and kicks in when it notices an inconsistency, saying, “Hmm…that doesn’t seem right,” perhaps leading to some conscious system 2 thinking and problem solving.

But as this two-star Amazon reviewer observes, Kahneman’s book doesn’t contain easy-to-digest pop psychology advice for how to be a better thinking being:

“Peace to all…The idea of system 1 and 2 for the brain was the twist. (System 1 is impulsive autopilot, system 2 reflective and analysis oriented)
Other than that, the book is filled with too many experiments that i felt didnt add practical value to me. I was hoping for practical solutions to help make those two systems work together in harmony…the book did NOT deliver that which was disappointing.”

Kahnman won’t fill you with sound-bite sized advice on how to sharpen your thinking. So what can you do now that you are aware of how you think? Are there ways to counteract the bad things about these systems and amplify the good things? I think so.

Since reading Kahnman, I’ve observed how my environment affects my thinking and how my thinking demands shift from task to task. Sometimes fast thinking trips me up because what I assumed made it difficult for me to really see things as they were. I keep working to counteract cognitive biases of my own and those I work with. I’ve become more aware when others don’t react as I expect or aren’t making “logical” decisions. I’ve become more understanding and less impatient.

I am experimenting with ways to support and enhance system 2 thinking in others and myself. I find that I need to carve out a space where I can work without distraction and have enough time to get deeply engaged in a challenging system 2 type task. I am easily distracted by noise or visual stimulation. I also find the Pomodoro technique doesn’t help me get more work done. I don’t have a problem with focus. My problem is knowing when to take a break. And I don’t easily get back on task after a 5 minute break.

Your experience no doubt varies. Our brains don’t work the same way. Let’s continue exploring how our daily work practices enhance our thinking and where we need to take extra care and pay more attention.

Can Nudging Help Us Make Better Choices?

Posted on January 9, 2015 by Rebecca

Nudging, as popularized by Richard Thaler’s book Nudge, is the idea of making a by-default action the preferred choice so you don’t have to think deeply to make a good decision. However the common definition for nudge as, “a slight or gentle push or jog, especially with the elbow,” gives me reason to pause.

I don’t like being elbowed, even if it is done gently with good intentions.

Does nudging ever work?

At first glance, I was intrigued by the possibility of personally crafting my own nudges. The idea of setting up personal reminders using a service like NudgeMail, seemed promising. While potentially useful, NudgeMail reminders aren’t exactly what Richard Thaler means when he talks about nudging. A Thaler nudge is more like an unobtrusive force that moves you to make a better decision or action without feeling poked or prodded. A nudge isn’t the same as a reminder.

Successful nudges need to be unavoidable attractive shiny attractions that draw you to nearly effortlessly make good decisions or take appropriate action. They are the not prods, nags, or scoldings, either. You can’t be nudged when you are annoyed.

In today’s Oregonian there was an article about the use of electric car charging stations. The idea behind installing publicly accessible recharging stations was to “nudge” more people to buy and drive electric cars. By plunking public charging stations all over the place, the thinking went, people wouldn’t be so concerned about draining their batteries while out and about.

Public charging stations has been in failure in Oregon. Even though placed in public places, chargers are rarely used. Some appear conveniently located (like parking garages in downtown Portland). But many others are located in out of the way places (there’s one at the back end of a shopping mall near in the small town where I live. I’ve never seen a car there). Turns out they were located more as matter of political expediency than common sense or practicality.

Inconveniently, it also takes hours, not minutes, to recharge a car using them. Consequently, people find it cheaper and more convenient to plug in and recharge their cars at home overnight. They don’t need to top off their battery’s charge while working out at the gym. Often people buy electric cars with the intention of using them only for short commuter trips. They don’t need or want public charging stations.

But consider the case of Tesla. Tesla has strategically installed fast-charge station capable of delivering up to 50% battery capacity to their sporty cars in about 20 minutes (roughly 16 times faster than most public charging stations). Tesla wants its customers to feel comfortable driving their electric cars on longer trips. There’s a Tesla recharging station by the Burgerville in Centralia, Washington, halfway between Seattle and Portland. Tesla owners are more likely to travel between Portland and Seattle, a distance of 180 miles, if they can stop for a burger at the healthy, local food-sourced burger joint halfway on their journey and get their battery charged at the same time. Tesla has found the right nudge to encourage longer road trips.

The idea of painless nudges that help us “do the right thing” seems compelling. But isn’t easy to find subtle nudges for behaviors we want to change.

Merely speculating on what might be a good nudge before you implement it can be a bad idea. You need to experiment. I’m not so sure government policy-makers can or do take the time to experiment on the effectiveness of nudges before they implement them. Perhaps they should.

On a personal level, any nudge I put in place has to be cost effective, cheap to set up, and easy to tinker with. For example, buying fresh fruit (for me, anyways) is just the nudge I need to eat fruit instead of more sugary snacks. If you don’t like fresh fruit, this nudge won’t work for you.

Keeping a tab in my browser open to Duolingo, where I’m trying to learn Portuguese, is just enough of a nudge for to keep me to keep at it. I study for a few minutes every day when I need to take a break from work. And Duolingo gently sends me email reminders about keeping up my daily streak. Still relatively new to Duolingo, these reminders aren’t yet annoying. Overtime, I know they will be. I don’t like to be reminded to do what I’m already doing. I just hope they have a way to turn them off.

If motivated, I can be nudged a little. But I’ve got to be in the right mood and it has to be in an appropriate situation and context. If a nudge feels at all like a shove or a poke instead of gentle, painless, helpful guidance, I’m inclined rebel and do the opposite.

A classic example of “nudging” by policy makers is to create incentives (think tax breaks or credits). For example, giving a rebate upon buying energy efficient appliances or solar panels. That nudge has been in place for some time here in Oregon. But I haven’t bought a new energy efficient appliance simply to get a tax break. Even if the investment will be paid back in a few years in savings on my electric bill. That nudge was more likely to nudge people moving into a new home instead of someone like me.

A couple of years ago, I recycled an old refrigerator because I happened to stumble upon an extremely attractive nudge when I was searching the Internet for recycling options. I could schedule an appointment online (selecting the day and time from a list of available times) for someone to come to my house, cart away my fridge, and mail me a $50 refund check. I was in the right frame of mind for that nudge. The conveniences plus the small monetary compensation made this a perfect nudge.

But it is oh so easy to resist a nudge when I am at all forced to think even a little. I am a cranky contrarian who doesn’t like pushy nudges. Don’t tell me I have to recycle my used appliances. And don’t give me too many options to choose from, either. But give me a choice.

Nudges should be easy peasy, transparent, painless offerings of ideal options.

If you are a policy maker at your company, you might be able establish a few nudges like providing free bus passes to encourage mass transit use or putting in showers to encourage bicycling to work or exercise.

If you are an agile coach or team leader you can nudge a little, too.

Want to limit the time of a daily standup meeting? Hold it around a whiteboard and have people actually stand up. In my experience, getting comfy around a table makes meetings last longer. But watch out. I know some people who happily spend hours talking at the whiteboard. Every day. They need more than a nudge to keep stand ups brief. This leads some agile coaches to introduce protocols or standard ways of doing things that are demonstrated, and then gently enforced in order to encourage appropriate actions. How I feel about protocols and rituals is the topic for another blog post.

Nudging isn’t social engineering for social engineering’s sake, but with the intent of setting up your environment and context so you want to make the obvious better choice without feeling pressured.

Have you found effective ways to nudge yourself and change you or your team’s habits? If so, I’d like to hear from you.

Making New Behaviors Stick

Posted on December 15, 2014 by Rebecca

My last post argued that knowing about cognitive biases and how our brain works is valuable, even if knowing isn’t enough to effectively change our behavior. Tweeter Jessica Kerr sums this up nicely, “Knowing isn’t half the battle, but without it, we don’t know the battle exists.” Knowing doesn’t prevent automatic behaviors and biased reactions. However, knowing gives us words we can use to reflect on our actions and feelings.

And then what? After awareness comes the really hard parts: consciously replacing undesirable, semi-automatic behaviors with more desirable ones.

Much of our daily behavior is driven by habit. Social psychologists estimate around 35-50% of our daily behaviors are driven by habit. Personally, I think that may be somewhat on the low end.

There’s a good reason for habits. If we had to consciously think through every action we took, we’d be exhausted. When we have to consciously think about how to perform any task, it takes mental energy. And that wears us out. When we are tired we unconsciously fall back on our fast (associative) thinking to conserve mental energy and provide easy (if not always well-reasoned) answers to difficult questions.

It’s better if we can slip on our shoes in the morning and tie them without thinking.

We actively use our system 2 brain when we learn new skills or are placed into unfamiliar situations (think trying to navigate around a new neighborhood, learning customs in an unfamiliar country, learning a new problem domain or new programming language, or tracking down a tricky intermittent software bug).

When we’re not forced to work so hard, we mentally take it easy. We’re NOT lazy. But we do many things out of habit, to conserve our slow thinking, system 2 brain for when we really need it.

But what if we want to replace an old habit with a new improved one—and make that new habit automatic?

To change entrenched habits, we have to find effective replacements, insert them into our daily life…and be vigilant. This takes energy and effort.

The bad news: Old habits can still be triggered. They don’t disappear. They are simply supplanted by more recent habits (if those new habits can be successfully triggered).

One way to thwart undesirable habits is to remove their triggers from your environment. That’s why some people recommend removing unhealthy food from your household and environment when wanting to develop healthier eating habits (easier said than done when you live with others or if there are always donuts at work on Fridays).

When it’s impractical to remove undesirable triggers, you’ve simply got to deal with them. Instead of reacting blindly to that old trigger, you can experiment with introducing new behaviors for that trigger with even stronger rewards. When the donuts show up at work, treat yourself to a good cup of coffee and slightly healthier biscotti instead (if you really really like donuts this isn’t going to work). Better yet, avoid the strongest morning donut trigger by coming later on Friday after all the good donuts are gone (those stale donuts may be a trigger that you are still suceptible to, especially if you are tired).

This isn’t easy. Change rarely is.

Perhaps another solution to making changes stick is diligence. Be on the lookout for undesired behaviors/actions/triggers. Spot them, then quickly squelch ’em. Then go back to doing the desired behavior. This works, for a while.

Exercising diligence takes mental energy. You only have limited amounts of willpower to spare and when it is gone, well, things can get ugly. That’s why after a stressful day (when your system 2 is already tired from everything else you used it for) that you can let down your guard in a heartbeat. And then, dammit!…you slip up. You notice you slip up, beat yourself up about it, and vow to be even more vigilant. But you slip up again and…rinse, repeat…. I am not going to continue down this rat hole because it IS depressing.

So how do we get ourselves out of these mental ruts?

Evidence suggests that too much retrospection isn’t good. So don’t beat yourself up when you slip up. Recognize that you’ve slipped up and try again. Switch things up and keep on trying (identify a better trigger or reward, experiment, try and try again). Don’t give up or give in to a defeatist attitude.

Some good news: Research suggests we are more successful at changing behaviors when we go through life changing events—when we move, retire, graduate from school, go off to college, start a new job, quit a job, marry, get ill—we are more open to change.

But I don’t wait for a big event to effect big changes. I don’t make New Year’s resolutions, either. Instead, I periodically mix things up and try new things just for their novelty. Life is a grand experiment.

But still…research hasn’t yet shown how to sustain new behaviors. Even years after embracing new behaviors, we are prone to slipping up, given the right triggers (think vacations, travel, holidays).

Knowing how we can slip-up is not enough to avoid slip-ups. Santos and Gendler are right.

But believing that you can recover after a slip up is key to getting back on track. And that’s where a positive mindset, determination, the belief that you can learn from mistakes, and resilience go a long way towards making change and making changes stick.

Footnote: The Power of Habit by Charles Duhigg is a good book for those wanting to know more about habits in their life and business.

What good is knowing if it’s not half the battle?

Posted on December 12, 2014 by Rebecca

Cognitive psychologists Laurie Santos and Tamar Gendler answered Edge.org’s 2014 question of the year, “What scientific idea is ready for retirement?” by stating we should retire our unquestioned belief that, “Knowing is half the battle.” The phrase, “knowing is half the battle” was popularized by the 1980s G.I. Joe cartoon’s ending message, “Now you know. And knowing is half the battle.”

I am too old to have watched G.I. Joe cartoons…but somehow that meme worked into my brain and has colored my outlook on life. I’m always seeking new information. I want to know and then act based on that knowledge.

Santos and Gendler state that, “Recent work in cognitive science has demonstrated that knowing is a shockingly tiny portion of the battle for most real world decisions.” When it comes to making decisions, knowing about how our brains work isn’t enough to stop us from making irrational decisions, doing things in the short term that undermine our long-term goals, or being biased by seemingly incidental (and unimportant) information. In fact, knowing might even get in the way of taking appropriate action.

But I like to know how things work. I want to believe that if I knew more about how my brain works, that I could make better decisions, act more rationally, and be less influenced by my goofy cognitive biases.

Yet, when I read Santos’ and Gendler’s Edge response and dug into their research, I realized that I have been deluding myself. Knowing is rarely sufficient to overcome our “built-in” brain reactions.

Knowing isn’t intrinsically bad. It just isn’t sufficient to effect change. Yet I still want to know how things work. I still believe knowing is incredibly powerful.

So what good is knowing?

Knowing a name for some thing gives you the vocabulary to talk about it. In my review of Design Patterns, I said, “most importantly, it names these design constructs, allowing teams to share a common vocabulary.”

You aren’t a better designer because you know design patterns. There is so much more to design than knowing a few patterns or applying them to solve a problem. But knowing about patterns enables you to have more informed conversations about what you see in existing designs and what design possibilities there are.

Knowing about system 1 and system 2 thinking as described in Kahneman’s, Thinking Fast and Slow, and how they interact can help you talk about how you behaved the way you did.

Knowing about a thing or concept enables you to see it. Once I knew of the Cargill logo, I spotted it everywhere. On trains, buildings, products. Before that, it was invisible.

Knowing about cognitive biases can help you spot “irrational” decisions.

Knowing about some thing helps you focus attention on it (which can at times be good). But simply increasing awareness and attention won’t guarantee that you won’t miss something else important or avoid making poor decisions.

Simply knowing isn’t enough to eliminate undesirable associations or remove biases. Otherwise, you’d never have knee-jerk reactions and would always accurately weigh risks and rewards when making an important decision.

We can’t change our “system 1” thinking with its automatic fast associations. That’s how we’re wired. Associations are freewheeling, making us extremely susceptible to priming, anchoring, and myriad other cognitive biases.

Knowing increases awareness. Maybe I’m overly optimistic, but I believe increased awareness is the first step towards making any significant change.

Knowing doesn’t prevent the triggering automatic behaviors and reactions. But it helps us shape the words we can use to reflect on our actions and feelings. And then, what?

If we want to behave differently, we need to take some action to avoid tripping up in the future. But since we can’t turn off our automatic reactions, what can we do? Indeed, changing “automatic” reactions is hard.

And that’s the focus of my next blog post.

Beware of Dogma. No. Be aware of dogma

Posted on October 17, 2014 by Rebecca

Dogma has several different meanings. I’m going to purposefully split hairs in this post, because I don’t want to attach negative connotations to dogma in a knee jerk fashion. I want to be more thoughtful about my choice of words and my reactions to them.

Here are four meanings for dogma:

“1. an official system of principles or tenets concerning faith, morals, behavior, etc., as of a church.
2. a specific tenet or doctrine authoritatively laid down.
3. prescribed doctrine proclaimed as unquestionably true by a particular group.
4. a settled or established opinion, belief, or principle”
from dictionary.com

At first, these subtle differences in meanings annoyed me. But I wanted to push through that to see what I can learn about dogma. So here goes…

An official set of principles or tenets concerning faith, morals and behavior.
As a software professional, do I have an “official” set of principles and tenets that I believe in?

I have a set of guiding principles and practices for how I work, think about design, write code and tests that I’ve built up over 20+ years of practice. They have become part of how I prefer to operate. I’ve changed and refined them over time, discarding some practices, fine tuning others.

The guiding principles I follow weren’t handed down by authorities. I discovered them working alongside smart people and interacting with thoughtful designers who cared deeply about how they built and implemented software. I wanted to understand how productive people thought and worked, and try to incorporate what I saw as good practices and beliefs into my own beliefs and ways of working.

In the process, I co-wrote two object design books that shared a way of thinking about objects that I still find effective and powerful. Maybe writing books made me an authority. But I also have become a seeker of new and better ways of working. Over the years I have “blended” into my personal set of practices and beliefs about design some powerful ideas of others. This process of incorporating these ways of thinking and problem solving to me feels highly integrative rather than just “accepting” them as unchallenged beliefs or tenets. I have to sort through them, adjust them and then make them part of who I am and what I do. I am not one to blindly accept dogma.

The 3rd definition of dogma has negative connotations: a prescribed doctrine proclaimed as unquestionably true by a particular group.

Hm. I don’t hold many things about software design as being unquestionably true. I find it disconcerting when groups and factions form around the latest truth or discovery. For example, some fervent agile developers I know unquestionably believe that test-first development is the only way to design software. (I’m more of a test-frequent designer by nature). Those who refuse to acknowledge that there are other effective pathways to producing well-written, well-designed, maintainable code are trying to push a dogma of the 3rd meaning.

I find myself questioning any software doctrine that is held as being “universally” true. How presumptuous! There are so many different ways to solve problems and build great software.

I try to keep an open mind. My most strongly held beliefs are ones I should challenge from time to time. To do that, I have to push myself out of my comfort zone. For example, I have discovered a few things by letting go of several strongly held beliefs and performing some interesting experiments: How much code that checks expected behaviors do I really need to keep around to keep software from regressing? How many tests does any organization really need to keep? How many comments do I need in my code? How much of my code should check for well-formed arguments? Is it better to fail fast or fail last? What’s the effect on my code to put in all those checks? What’s the effect of leaving them out.

Not all dogma is handed down from on high or authoritatively laid down…nor is it necessarily bad to hold a common set of beliefs and opinions (the fourth definition of dogma). I’ve been in dysfunctional groups where we couldn’t agree on anything. It was extremely stressful and unproductive.

If as a group we establish and hold a common set of beliefs and practices, then we can just get on with our jobs without all that friction jockeying for who is right and the right way to do things.

But, here’s the rub…if you accept a certain amount of dogma (and I’m not saying what kind of dogma that might be…if you are an agile software developer I am sure you hold certain beliefs on testing, task estimation, collaboration, specification, keeping your code clean, whatever…) be wary of becoming complacent. Dogma needs to be challenged and re-examined from time to time. But don’t toss your current dogma aside on a whim, either. Old beliefs can get stale. But they may still be valid. We need to try out new ideas. But not simply discard older beliefs because shiny new ones are there to distract us.

The Responsible Designer

Don't you want to take responsibility for your designs?

Category Archives: Psychology