Category: Evolve

I’m working on a short book, tentatively titled Evolve…

I use a set of principles in my work to help companies improve the way they manage their work while adapting to change. These principles are common to progressive practitioners in several different fields, such as software programming (Agile), manufacturing (Lean Manufacturing), product design (user-centered design), film and theater production, engineering, and even forest management (adaptive co-management). This book collects and summarizes these principles for managers who want to evolve their organizations and their skills through changing conditions.

Using Real Options to Value Design Concepts

The common way that financial people will judge the potential value of a project, or a design concept representing a potential future concept, is by building a model, usually a discounted cash flow model like Net Present Value (NPV). The calculation essentially asks, if we do this project and gain the profit we think we’ll gain, how much is it worth to us right now? That way we can compare it against our other options.

The problem with these models is that they assume the world doesn’t change. The model tries to predict everything that will happen in the project from beginning to end in order to arrive at a single numerical value. But in the technology world, there’s lots of change.

So peeps at the forward edge of product and service development have started using real options to value projects. Real options essentially breaks the project down into a series of decisions. At each decision point a number of outcomes can occur, and for each outcome there’s a probability it will occur. There’s also a revenue associated with each outcome that we receive if it occurs. By multiplying the probability by the revenue we get the value of the option.

This is often illustrated using a decision tree, as with this analysis of a drug in clinical trials…

What’s the big deal? It turns out this is a better way to value investments in Internet services for at least three reasons I can think of off-hand…

  1. Versioning: The Web 2.0 way of doing things is to release our work in stages, the public beta being a perfect example. If the beta is a big fail, we stop there and cut our losses, or we go down a different path of the decision tree.
  2. Uncertainty: There’s a great deal of uncertainty in our work. Twitter, for example, is a big success, but at the cost of a very tricky technical challenge. Instead of an NPV model that would judge the value of the project to be either simply negative or positive, we can model this reality of “large audience / technologically expensive.”
  3. Fast Risk Management: The ease of building betas makes it tempting to skip a big financial modeling activity, especially if it can’t accurately reflect (i.e. predict) how customers will react. Creating at least a simple real options analysis can save a lot of investment before building a beta that is hard to emotionally trash once it’s built. And while it’s tempting to say predictions are impossible so we should just run a trial, few managers with any P&L responsibility will invest in that.

Real options isn’t a perfect technique, however. Proponents claim it supports decisions with “mathematical certainty,” but the probabilities are derived from managers’ experience and judgment which is subjective and imperfect. Getting a group of people to agree on the probabilities may be difficult, and once a project is up and running a team may be unwilling to revise their estimates downward to reflect new information, much less kill their own project. Still, for the kind of work we do it’s better than the old ways.

References:

Woulda, shoulda, coulda. Didn’t. (The Failure to Beta Test)

Monitor110 was a business/site that tried to filter information for institutional investors. This post mortem from a founder probably won’t reveal any new lessons, but it’s always powerful to see theory — in this case the value of the beta release — played out in the form of failure…

…By mid-2005 the system worked, but spam was becoming more prevalent and caused the matching results to deteriorate, e.g., too much junk clogging the output. Around the same time we started to dig into natural language processing and the statistical processing of text, thinking that this might be a better way to address the spam issue and to get more targeted, relevant results. This prompted us to not push version 1.0, instead wanting to see if we could come up with a more powerful release using NLP to mark the kick-off. In retrospect, this was a big mistake. Mistake #5, to be precise. We should have gotten it out there, been kicked in the head by tough customers, and iterated like crazy to address their needs. Woulda, shoulda, coulda. Didn’t.

…We talked about “release early/release often,” but were scared of looking like idiots in front of major Wall Street and hedge fund clients.

Published
Categorized as Evolve

Bruce Hannah on Prototyping

I’m back from Overlap 08 which is becoming my reliable annual inspiration for all things professional. It will surely fuel more thoughts here, but I wanted to capture one thing Deb Johnson said that Bruce Hannah taught her in design school:

Mock it up before you fuck it up.

The profanity I think is not just him being glib but actually justified in most cases.

Published
Categorized as Evolve

Google Labs Embedded in Gmail

I think a lot about how organizations and their products evolve quickly rather than remain static, and Google Labs are a prime example of that. By developing many alpha products, releasing several public betas, and getting live feedback they use the market to tell them what works. For many companies the notion of releasing your proprietary ideas is very scary, and yet the effect is the opposite: risk management.

A colleague just gave me a heads up to the Labs section of Gmail (accessible from Settings). It’s interesting for a few reasons:

  1. They’ve turned the labs upside down, embedding experimental ideas as preferences in an application rather than silo’d sites.
  2. Each feature is attributed to the employee(s) who invented it, acknowledging that great experiments often originate with one person, even if it takes a company to implement it.
  3. Some of the features — like “mouse gestures” which lets you navigate conversations by moving the mouse — innovate at the user interface level.

Gmail Labs

Agile with a capital/lowercase A

It looks like agile software development is having the same growing pains, expressed through semantics, as the design field (or the Design field). It’s the perceived misapplication of language that catches my eye…

Jason Gorman argued that the meaning of Agile was ambiguous and was being inappropriately applied to a very wide range of approaches like Six Sigma and CMMi. He also argued that “Agile”, “evolutionary”, and “lean” (as in Lean software development) did not mean the same thing in practice, even though they are all lumped under the banner of “Agile” – possibly for marketing purposes. Gorman argued that process-oriented methods, especially methods that incrementally reduce waste and process variation like Six Sigma, have a tendency to limit an organisation’s adaptive capacity (their “slack”), making them less able to respond to discontinuous change – i.e., less agile. He also argues in later posts that “agile”, “lean” and “evolutionary” are strategies that need to be properly understood and appropriately applied to any specific context. That is, there is a time to be “agile”, a time to be “lean” and a time to be “evolutionary”.

Fascinating, but a nuance that will be completely lost on business clients who are focused on other matters. But just as IDEO shows what they do instead of only talking about it, I think making it all tangible will be a way around the semantic mess. I’d like to see the Agile Alliance produce a “shopping-cart“-like video of an agile project.

Bad News Should Travel Fast

Another reason I like agile management is because when something bad happens, you should know as soon as you can. If you only check project status every week or longer, that can be way too late. It’s like what Robert Duvall says in The Godfather: “I have to go to the airport. The Godfather is a man who likes to hear bad news immediately.’“

Radiate information – First Draft

[ this is a first draft of a chapter in Evolve, comments are appreciated ]

Healthy organizations share information promiscuously to speed communication and generate tacit knowledge. Share current, important, non-urgent information using information radiators.

In 1966 the New York Stock Exchange installed a huge electronic board that displayed the stock prices of every company on the exchange. The constant flurry of Exchange operations revolved around this board, kept everyone informed, and helped NYSE grow into the largest exchange in the world. Even today people refer to the Exchange as the “Big Board.”

Usually we record and deliver our knowledge work in documents, documents trapped inside a computer or in a pile on someone’s desk. Imagine for a moment you are at the airport leaving for vacation. Your flight is delayed, and to find out the current departure time you and everyone else on the flight need to refer to a printed report at the gate that is updated every half hour (actually, given the efficiency of some airlines, I’m surprised this isn’t the case). Whether it’s a stock exchange, an airport, or a fast food restaurant, moving information out of documents and into the workplace helps people work faster.

Try it now
Isolate the most important information that is needed by most team members most of the time. It could be the status of each activity, how much work is left on each project, or the stage of completion for each activity. In a public area like a hallway, mount a whiteboard or poster board to track this information. Use highly visual formats like calendars, graphs, or charts so passersby can absorb updates quickly. Make it easy for everyone to make updates by leaving markers or sticky notes nearby.

Guidelines:

  • Radiate information that is current, important, but non-urgent
  • Show the state of progress but don’t try to represent process
  • Make it visible to everyone in a high-traffic area like a hallway or kitchen
  • Don’t format it in a way that’s too pretty, precious, or permanent. By designing it so it looks editable and supplying tools like markers to modify it you make it easy for team members to update

If the information needs to last a long time independently of people or teams at a company, use a format that will be found easily by subsequent employees. For more permanence, stronger materials like metal plaques can radiate long-lasting ideas like organizational values. Or you can locate information outside the organization, such as by publishing a book.

References:

What the Agile Toolbox Contains

InformationRadiator

Published
Categorized as Evolve

Do the easiest thing that could possibly work – First Draft

When you have a new idea and you’re not sure it will work, create a tangible version of it as quickly as humanly possible. Even if it is very rough, something tangible helps you reach a solution.

I’m sure you’ve been in this situation. There’s an important problem that needs to be solved before the team can move on with other work. It’s a complex issue, maybe it’s charged with emotions, and no one has an answer. You and your team stare at the paper, out the window, or up at the ceiling wondering how anyone could possibly purchase such an ugly light fixture. Short of the day ending or receiving divine inspiration, it is at this point that you should pick up a pencil/marker/keyboard/tool/whatever and do the easiest thing you can imagine that would solve the problem.

When you’re trying to solve a problem and you’re stuck it’s because you’re trying to solve it in your head. Just as you can do simple calculations in your head but need a calculator for everything else, you can’t solve tough business problems in your head.

When you draw, build, write, or use something that is physical, your physical senses help you understand more about the situation. You more fully understand the problem than if you only thought about it. Financial analysts do this by writing calculations on the back of a napkin or playing with numbers in a spreadsheet. Designers do this by sketching on paper or carving foam in the shape of a product. Engineers do it by combining parts they have on hand to make something new.

This is not about conceiving a six billion dollar payroll system or a drug that cures cancer. It’s a way to make progress on one particular idea. It’s about making a physical thing you create quickly, learn from, and throw away.

It’s important to ignore how well you’re doing what you’re doing, because that will distract you from accomplishing the goal. This may go against our usual inclinations to do things “right.” We’re taught to think things through and carefully design a solution. But when you’re stuck we need to overcome this tendency. Free your mind from all the rules you normally follow. Pick up the pencil and just sketch.

You might even use techniques you know to be incorrect because they help you move more quickly. This is good. The are only two guidelines here:

1. Do it quickly
2. Create something tangible

Try it now

When faced with a tough problem, start by working with the familiar, asking, “Is there something that already exists that addresses this problem? What sorts of things that already exist might address this problem?”

It may help – even just to save face in front of co-workers – to start by saying out loud as you grab the pencil, “This is something we’ll throw away later, but for now let’s try drawing something that will solve the problem. We can create the actual solution later.”

——

This has been adapted from:

The Simplest Thing that Could Possibly Work, A Conversation with Ward Cunningham, Part V, by Bill Venners, January 19, 2004

Simplest or Easiest

Published
Categorized as Evolve

Balance control with collaboration – First Draft

To solve tough problems, we need the active participation of a diverse group of people. Instead of control residing only with managers, each person on a team should have the authority and responsibility to contribute fully. Rather than command them from above, the team leader should facilitate the team’s efforts.

Since the industrial revolution we’ve needed a lot of science to deal with the changing nature of work. Science in the form of organizational theory helped us structure giant corporations. And the scientific method made time-motion studies possible which vastly increased manufacturing speed. Frederick Winslow Taylor wrote a book in 1911 about the latter field, appropriately titled, The Principles of Scientific Management.

These days our work increasingly consists of complex problems that cannot be divided into simple, repeatable tasks. Take, for example, the Global Earth Observation System of Systems in which 60 countries have agreed to participate in a 10-year effort to collect and share thousands of measurements of the Earth. This data has a wide variety of applications, from monitoring pollution to predicting the weather. But this requires hundreds of scientists with different agendas to agree on thousands of decisions. As one of the project leaders says, “‘We have been able to make computers work together. The challenge of the 21st century is to get people to work together…’ noting that the problem will be overcoming bureaucracy, politics, and turf.”

Science alone wouldn’t have a chance to make this project work.

The work practices we used throughout the 20th Century are still important and useful. But for complex, 21st Century work they’re not sufficient. Because the problems are bigger, they require more people with more skills to solve them. These complex problems require the combined effort of people with complimentary experience, knowledge, and ways of thinking.

Working involving new combinations of people requires effective collaboration.

Collaboration requires each person on a team to have the opportunity to drive the processes and outcomes.

In other words, success with complex problems depends on sharing control with others. Joe Kraus, the founder of Excite and JotSpot has said, “Very early on, the founders of startups make an important choice. Do they want success or control? …I’ve picked success. And success implies giving up control – hiring people who are much better than you, or being willing to be the janitor if that’s what’s required.”

Of course, groups that have no leadership at all can easily slide into a death spiral of debate and fail to accomplish anything. Success today requires balancing control in the form of management with collaboration in the form of facilitation.

Try it now
On an interdisciplinary team, assign a team lead that is a contributing member of the team, but also has responsibility for two critical functions:

  1. Facilitate the process – This is an art in itself, but it includes eliciting each team member’s best work, resolving conflicts, and finding alternative paths when the team gets stuck.
  2. Make executive decisions – There will be times when team members will have opposing opinions and can’t resolve them. The team lead synthesizes everyone’s viewpoints, weighs the project priorities, and makes the tough decision, but only when absolutely necessary.
Published
Categorized as Evolve

Use simple tools

The tools we use to create and communicate should be so easy to use we rarely ever think about them. With simple tools we naturally focus on what the tool allows us to do.

The famous typography designer Matthew Carter has said that when you read you should not see the letters on the page, you should see through the type to the message. If printed type was the tool we’ve used to communicate for thousands of years, today we do our jobs using mobile electronics, software user interfaces, rapid prototyping devices, and so on.

And yet, as I write this in 2006, I still can’t use my computer to make an appointment with someone working for a different company and know that the meeting will appear on both our calendars. I may spend time trying, but I know this everyday task is still completed more easily (and with more accuracy) if I simply call the other person and schedule the appointment over the phone.

If your calendar software makes it difficult to schedule a meeting, use something simpler. If it isn’t obvious how to use the functions of your mobile device, get something easier. These tools should be just as transparent as the type you’re looking at now. Communicating and executing our ideas is too important to let technology get in the way.

Robust tools are seductive, but their complexity quickly results in diminishing returns. Adopt tools with as many features as you need, and no more. Usually a few essential features will enable you to do many things well.

Try it now
As you go through your days, write down a list of every tool you use to create and communicate. Mark those that are cumbersome, and find an easier replacement for each cumbersome tool. Do the same with your team.

Published
Categorized as Evolve

Agile everywhere

I’m finding examples of agile work practices in more and more places, and see them as perfectly aligned with the application of design practice in innovation services. Here’s a running list…

I think people in the product design and user-centered design disciplines work in agile ways as well, but haven’t yet found a common frame that other disciplines readily understand.

Periodic process renewal

There’s a funny (or cruel, depending) dilemma to improving your work over time. If you don’t do it, your organization becomes less and less valuable over time, gradually failing, and dying an unfortunate death. If you do all the time, you never get to benefit from each change very long and probably suffer from change fatigue. We’ve even labeled these positions in our worldviews: conservatives want to keep things just the way they are – thank you very much – and progressives always want to embrace the something better that’s just around the corner.

My fix for this is simple: Instead of never changing or constantly changing, set a regular period when you revisit your process. And just so you’re pretty sure the change is leading to improvement, have a simple way to keep track of what you did, why, and what happened as result. Not every change will result in improvement, but at least you’ll know that and not repeat your mistakes.

We can look at this in evolutionary terms using the example of sharks. A shark doesn’t evolve constantly, it evolves by having baby sharks (which are amusingly called pups) that have unique DNA that make them more or less successful than their parents. While each shark is alive, her life is a time of trying out her DNA and either succeeding or failing to have her own pups. Reproduction is a time of trying slight variations (aka gene mutation) on what worked before and only passing on the DNA of successful sharks. Over time, sharks become more and more successful at being sharks.

I’ve started developing a simple model of the nature and frequency of process change in companies based on what I’ve seen in the dozens of companies I’ve worked for or with. The model boils it down to three types:

  1. Deteriorating: When the company was young they designed and established productive methods, but over time the methods gradually lose value as the environment changes. We see this trend in the Management Practices across Firms & Nations survey.
  2. Chaos: Change is constant, usually reactionary, and there’s little history of past changes to help judge the effectiveness of future changes.
  3. Periodic Renewal: The company designs and establishes some methods and measures the results, periodically revisiting them and making improvements.

I might draw them like this:

And I might track the change over time like this:
(diagram coming soon)

Periodic renewal requires the organizational discipline to stick with what works as well as the resolve to occasionally improve it, a careful balance. For many companies, the closest analog is periodic performance reviews. We don’t formally judge our colleague’s performance and award raises every day, we do it periodically (or suffer the wrath of seriously pissed off colleagues). How good is your performance review process? Judging your ability to improve this process over successive versions may indicate your current ability to institute periodic renewal of other processes.

Tell the Truth, part II

So how do we tell the truth? Here are a few ways I found work:

Inform the uniformed: Challenging the accepted situation by citing reality may get you sent to Siberia. But it depends on whom you’re talking to. Over time executives become ill informed – ironically – because timid employees avoid giving them bad news. For the executives, the truth becomes a rare and valuable revelation, and you a valuable messenger if you relay the truth in a way that isn’t tied to your personal agenda.

Collectively decide to be honest: Being honest is much harder than it sounds. Much of the mediocrity in companies is a result of superficial niceties that make it impossible to productively critique ideas. Being honest means praising ideas worthy of praise, and criticizing ideas worthy of criticism. Before doing it on an individual level, everyone in a group should agree that honest interaction is necessary to improve the organization, and that honest expression is not personal condemnation.

Reframe ideas: Any current business issue stands on an implicit context of ideas that are part of the company’s culture. This collected wisdom is the frame through which new information is interpreted, even if the freshness date of those ideas is long past, such as growing for years but thinking, “We’re only a small company.” You can reframe the issues by presenting an alternate idea supported by a different context. “Now that we have 2000 employees and four offices, we have the capacity to consider exporting our products.”

Appeal to science: Disinformation is rare among scientists and engineers because their livelihood depends on working within the physical constraints of reality. You’re not likely to hear, “That’s right, Victor, we’ll have that Internet bandwidth commodity exchange done by Tuesday afternoon.” When I work closely with engineers and programmers, they ruthlessly critique business ideas because they know exactly what it takes to implement them (and know they’ll later be responsible if they don’t speak up now). Citing scientific reality – or aligning yourself with scientists – becomes a useful sieve to filter out disinformation.

Published
Categorized as Evolve

Tell the Truth

Over time a company’s official history becomes ideology and people need the truth of reality to help them grow.

On my first trip to Berlin I toured the former Deutsche Demokratische Republik including a number of museums and memorials describing the former communist state, the Berlin Wall, and life within its boundaries. We’re now well aware of the reasons the totalitarian state collapsed. Central planning failed to provide for the needs of citizens. Official “full employment” resulted in idleness and dissatisfying jobs. And the need to further a core ideology made experimentation – and therefore innovation – highly unlikely. Nothing remarkable was possible, the human spirit suffered, and eventually the whole system collapsed.

It reminded me of some companies I’ve worked for.

“Comrade Lombardi, I think you are mistaken in your effort to respond to these so-called customers, as the Party Leader has already informed us, there are no customers. There are only distribution end points. I am sure that lowering your bread rations will help you understand this.”

This management-knows-all behavior creates fear that quickly overcomes the simple desire to tell the truth. When official disinformation is possible in entire countries, it easily happens in companies.

Central planning. Unnecessarily large teams. Official ideology. Poor moral. Are you working in a totalitarian company?

Published
Categorized as Evolve