When I talk with folks in large organizations, I often hear a familiar lament: “We’re very siloed here.” By this, they mean the organization is divided into groups that don’t play well with others. Each group functions like an isolated “silo” that acts independently from the rest. They each have their own internal goals, incentives, processes, etc. which make it difficult for them to collaborate.
Siloing impedes the organization’s ability to respond effectively (and in a timely manner) to changing contextual conditions. Because it involves organizational cultures and incentives, it can be a tough challenge to overcome. People in silos have an especially hard time seeing things from others’ perspectives — especially their colleagues.
A big part of the problem is that people in these situations tend to communicate in abstract terms. Often they’re unaware of using language that reinforces the distinctions between them. With our emphasis on making things tangible, designers can help them bust through these barriers.
Complex projects require coordinating and aligning the efforts of many people in different roles and groups. The job is possible only if everyone is clear on what they’re striving towards, and are compelled to do so. This calls for leaders to clearly articulate the project’s vision.
The importance of having a clear, compelling vision is one of the great lessons of the Apollo moon program. U.S. President John F. Kennedy laid out the vision in a speech delivered to Congress in 1961. This speech was meant to convince lawmakers of the worth of investing in space exploration. Essentially, the President was asking his stakeholders — Congress, and more broadly, the people of the U.S. who they represent — for funding for the project. This is something anyone working in a leadership position can relate to.
President Kennedy’s presentation is a model of how to clearly articulate and sell a vision, so it’s worth studying its highlights. The speech starts by framing the space program in the broader geopolitical context of the Cold War. The Soviet Union had by this point made several impressive technological advances, including launching Sputnik (the first artificial satellite) and sending the first man into space. U.S. efforts were seen as lagging behind the Soviets’, so the President started his remarks with the following statement:
The websites and apps you interact with are parts of systems. These systems are often commercial organizations with responsibilities to various stakeholders, including the owners of the business, its employees and managers, its customers, and — more broadly — the rest of us who live in the society where the organization operates.
The people who “own” these digital products and services — product owners, business line managers, etc. — are tasked with being good stewards of these systems. They’re called to steer them towards greater value for stakeholders in the short and long term even as conditions around the systems change. Design decisions will change these systems — even if slightly. For example, the team could develop a new feature, fix an existing (and underperforming) feature, or address an entirely new user audience.
These are systemic interventions. Their effects are seldom limited to the task at hand; a seemingly minor alteration could have a large impact downstream. As a result, product owners must look out for second- and third-order effects; they’re looking to intervene skillfully as the system faces perturbations in its context.
To do this, product owners must become aware of the possible options open to them and their potential effects. Their ultimate goal is to achieve dynamic stability: for the system to continue serving its intended purposes as it evolves over time to address changing conditions. This calls for these folks to become systems thinkers.
One of the central tenets of cybernetics — the science of systems — is the Law of Requisite Variety. It’s relevant to people who aim to control systems. In cybernetics, the word variety has a special meaning: It refers to the number of possible states of a system. The Law of Requisite Variety suggests that skillful control of a system requires (at least) an equal number of possible responses to its number of possible states. This is usually articulated as a maxim: only variety can destroy variety.
Translation into humanspeak: a system with few possible states requires a small range of responses, whereas a system with many possible states requires a broad range of responses. This idea has proven to be useful in a variety of fields, including sports, ecology, management, medicine, and more. The more complex the system you’re dealing with, the more states it can be in. Controlling such systems requires at least an equal amount of flexibility in your ability to respond to changes.
Of course, not all digital products and services aim to serve the same purposes. Some are simpler — and less ambitious — than others. Simpler systems will have — and require — less variety. But many digital products and services are very complex and can have many possible states. A digital system that aspires to become the de facto environment where we interact — socially, commercially, civically, etc. — will have a huge range of possible states. The folks who design and manage these systems face a great deal of variety. To intervene skillfully, they need a larger range of possible responses. Among other things, this calls for greater diversity in their teams.
Erratum: an earlier version of this post made it sound as though this concept was my idea. My friend Christina Wodtke rightly called me out on it; the cone of uncertainty is a concept with a long history in project planning. I must have read about it at some point and buried it in my subconscious. Apologies for any confusion this may have caused; I’ve edited the post to clear it up.
“The beginning is always today.”
— Mary Wollstonecraft
Imagine you’re ramping up to work on a new project that will keep you and your team busy for many months. Before you start, you must define a plan for how you will tackle the work. For example, you must figure out what resources you will need and by when. This requires that you make predictions about the future state of the project: “By the fourth week, we should have already produced high-level design directions. At that point, we’ll be ready to engage a UI designer and a prototyper.”
The problem is that you can’t predict the future with certainty; the best you can do is make educated guesses based on previous experience and best-practices. And of course, reality has a way of messing with things: By week three, the team may uncover a vital requirement they initially missed that forces them to re-think their direction.
Because of this, the team’s confidence in their plans should drop the farther they cast into the future. They must be sure of the activities they need to undertake immediately, and doubtful of the things needed in the more distant future. I often visualize this as a circle of uncertainty around the team:
Many years ago, my wife and I heard about a new bagel shop that was opening near our apartment. We decided to check it out one Sunday morning. The place was charming: roomy enough to feel comfortable, but not bustling. There was a large selection of fresh bagels, an assortment of fixings (including many flavors of cream cheese), and a well-stocked self-serve coffee bar. We loved it; lounging there over the newspaper became part of our Sunday morning routine.
It wasn’t long before other people discovered the bagel shop. Soon the place was crowded, and the experience suffered. Ordering became a chore, with lines that stretched out of the store. The once quiet place became packed and noisy. Worst of all, open tables became a rarity. We changed our routine to arrive close to opening time to get one, but then we would feel guilty about lounging around when others were waiting to sit.
Eventually, the owner leased the store next door and the bagel shop grew to three times its previous size. The expansion relieved some of the shop’s most pressing issues; now it was easier to find a place to sit. However, the quality of the food suffered and the relaxed experience of the early days was gone. The new shop was OK — but it wasn’t the same. At three times its former size, it couldn’t be. That’s not to say it wasn’t a good business anymore; it probably made more money in its new digs. But the soul was gone.
Change is a central part of doing business. If things aren’t going well, you must do something about it. But when things are going well, you must also do something about it. Staying still is the only option not on the table. How the business responds to the always-changing context it participates in (and helps create) will be one of the factors that define its level of success.
Architecture is a critical factor in that response. The bagel shop responded to increased demand with an architectural intervention that changed the character of the business. Even though on the surface things looked the same, a threefold increase in the shop’s physical environment made for an entirely different experience.
The laws of physics don’t apply to digital businesses in the same way they do to a bagel shop. A digital business can scale without needing to physically grow. However, the architecture of its information environments plays a critical role in how customers perceive and interact with the business. As with the physical business, the architecture of a digital business must change if it’s to evolve.
A digital business looking to level up has many options open to it. For example, a product could be on track to become a family of products or a platform. Or perhaps the business is expanding from an advertising-supported business model to a paid-membership model. “More of the same” is not on offer in such cases. The business must rethink its information architecture. Yes, this will impact its website and app navigation structures. But more than that, it’ll result in a new conceptual model that will affect all aspects of the experience.
A thoughtfully designed architecture will result in a new UX that will enable the business towards the next stage of its evolution, without compromising the things that made it great. A solid information architecture is a platform for enabling directed emergence: aimed towards a fixed objective, but open-ended enough to respond to real-world conditions as they arise; a platform for sustained growth that doesn’t sacrifice the soul of the business.
“Can I give you some feedback?” You hear the words, and immediately get a sinking feeling in your belly. “Uh oh,” you think. “What did I do wrong?…” For many of us, the word feedback has negative connotations. It’s become a polite euphemism for criticism; something we offer up only when our expectations aren’t being met. But feedback is not inherently negative.
Feedback refers to the means by which a system can alter its behavior. (The outputs of the system “feed back” into it as inputs, which the system then acts on.) Considered it in this light, feedback can be seen as a steering mechanism: a way of keeping things within bounds. Too much of a good thing can be as bad as too little; knowing where you are relative to the bounds you’ve set allows you to correct course. If you step on the gas, yoiu see the needle on the car’s speedometer creeping up. Past a certain point, you know you’re exceeding the speed limit, so you take our foot off the gas. The speedometer is one of the car’s mechanisms for giving you feedback.
Feedback applies to relationships as well as other systems (such as cars). If you’re managing someone who is performing below the expectations that are expected of him or her, part of your job is to act as the speedometer; you must let them know. (Hence, the sinking feeling.) But the speedometer doesn’t only tell you when you’re going too fast; it also lets you know how fast you’re going in general. Sometimes going too slow is not good either. Giving (and receiving) clear, frequent feedback is essential; it allows team members to assess how they’re doing and whether or not they’re on the right track.
Recently a student asked me what I look for when hiring people. I sent an abbreviated response but thought it worthwhile to expand on it here since it may be useful to others.
When I’m evaluating somebody as a collaborator, I want to know about four factors:
Is s/he a solid thinker?
This comes across in how they express themselves in interviews and written communications, and what they express. Do they demonstrate a solid grasp of key concepts and relationships between them? Can they explain difficult concepts without resorting to jargon/cliches? Can they explain their decision-making process clearly? Are they confident in what they’re saying?
Is s/he a solid maker?
This comes across in the artifacts in their portfolio. Do artifacts communicate clearly? Do they get to the point? Do they demonstrate mastery of medium? Do they demonstrate mastery of craft? Do they demonstrate clear intent? Do they demonstrate a willingness to experiment/push boundaries?
Is s/he a team player?
This is difficult to evaluate through portfolios and interviews; references come in handy. Still, there are cues that reveal how they relate to others. For example, do they give credit to their teammates or do they claim all the glory for themselves?
The character factor
Most importantly, I want to know about their character. Are they upstanding? Do they behave courteously towards others? Do they demonstrate a clear value framework? This is rather difficult to evaluate over brief interactions. Again, references help.
I place less weight on other things such as formal education or a record of having worked at the “right” places. The four factors above go a long way towards identifying the people who will help us be successful.
We do not describe the world we see, we see the world we can describe.
— René Descartes
Let’s say you’re working on a project. The project launches, other people start using it. How do you know it’s good?
This is an important question, but trickier than it appears at first. I divide it into three parts:
Someone is being cast as the arbiter. (“You.”)
A continuum is implied: from no-good to good.
An objective is specified: you want the thing to lean towards the “good” end of the continuum.
All three are up for examination. Let’s start with the arbiter of “good.” If the project is being developed within an organization, it’s likely that many parties will have stakes in its success. And even if you’re working alone, there will still be other parties involved. For example, there will be people interacting with your system. They, too, will have a say on whether it is good or not. “Good” will likely mean different things to different people.
There’s a point along the continuum at which the thing is obviously no-good; it’s not meeting anyone’s criteria of success. As it evolves and (ostensibly) improves, it moves closer to meeting more criteria. (In theory, this process ends with a “perfect” artifact. In practice, this is an impossibility; the context around the system continues to evolve as the project progresses, changing the criteria for success for at least some participants.) Eventually, the system moves far enough along this continuum to flip over into the “good” side. (We say it’s “good enough.”) In other words, it meets the success criteria of a large enough group of stakeholders.
Who defines the threshold where the artifact flips from no-good to good enough? How is this measured? This is the crux of the matter: What “good” means in a particular context is up for grabs. Often there will be one lead stakeholder who will be calling the shots. There is an expectation that this person (or team) will be the arbiter of “good”. But these stakeholders are often buffeted by political forces that influence their decisions one way or another.
Designers working on complex systems need to understand how success will be measured. The criteria stakeholders will use to evaluate success will have an important influence on the structure and form of the system. For example, if the organization defines success and an improvement of a Net Promoter Score (NPS), the system’s designers will be strongly incentivized to structure it in such a way that feeds that measure. (As Jared Spool has pointed out, this may not be a good idea in the case of NPS.) Stakeholders and clients using NPS as a filter will see the world through that lens. This can leave out important factors for success.
What’s good for an internal team may not be good for an organization as a whole. And — more importantly — what’s good for the organization may not be good for society as a whole. As designers of complex systems, we’re called to see beyond the world we (and our stakeholders) can describe and measure. Our vision needs to encompass a wider (and longer-term) perspective if we are to provide real, enduring value.
Incentive structures work. So you have to be very careful of what you incent people to do, because various incentive structures create all sorts of consequences that you can’t anticipate.
— Steve Jobs
What incentives drive your actions?
I don’t mean this in an aspirational, high-level, mission-statement sense. I mean: How is the value you add to the world remunerated? How do you put bread on the table? If you’re rewarded for a particular set of behaviors, you will most likely engage in those behaviors.
Some consultants charge by the hour. They get paid more the longer they focus on a problem. But the client doesn’t want the project to take longer (or cost more) than it needs to. In fact, the client wants a good job done as fast as possible. He or she is driven by different incentives than the consultant; time is usually a key factor. This is a case in which incentives are misaligned.
If you look around, you’ll find many such misaligned incentives. For example, as a citizen, you want to be well-informed so you can make better decisions. However, many mass news media are driven by engagement — how long they can keep you around so you can watch more advertisements. Engagement is a very different metric than elucidation; people will write and say outlandish things if they think it’ll make you pay more attention. (And if they get paid more when you do.)
We’ve never before been able to learn so much about what drives people, and instantaneously re-define their contexts based on what we learn about them. Incentive structures become reified in information environments. So when designing an information environment, we should work towards aligning the incentives that drive the environment with the incentives and goals of the people who will use it.
](https://jarango.files.wordpress.com/2018/05/bagel_lox_sesame_seeds_st-_lawrence_market.jpg?w=764)
