Shipulski On Design

Archive for the ‘Complexity’ Category

If you run a company, the most important thing you can control is how you allocate your resources. You can’t control how the people in your company will respond to input, but you can choose the projects they work on.  You can’t control which features and functions your customers will like, but you can choose which features and functions become part of the next product. And you can’t control if a new technology will work, but you can choose the design space to investigate.  The open question – How to choose in a way that increases your probability of success?

If you want to buy a company, the most important thing you can control is how you allocate your resources. In this case, the resources are your hard-earned money and your choice is which company to buy. The open question – How to choose in a way that increases your probability of success?

If you want to invest in a startup company, the most important thing you can control is how you allocate your resources. This case is the same as the previous one – your money is the resource and the company you choose defines how you allocate your resources. This one is a little different in that the uncertainty is greater, but so is the potential reward. Again, the same open question – How to choose in a way that increases your probability of success?

Taking a step back, the three scenarios can be generalized into a category called a “system.”  And the question becomes – how to understand the system in a way that improves resource allocation and increases your probability of success?

These people systems aren’t predictable in an if-A-then-B way. But they do have personalities or dispositions. They’ve got characteristics similar to hurricanes. A hurricane’s exact path cannot be forecasted, the meteorologist can use history and environmental conditions to broadly define regions where the probability of danger is higher.  The meteorologist continually monitors the current state of the hurricane (the system as it is) and tracks its position over time to get an idea of its trajectory (a system’s momentum). The key to understanding where the hurricane could go next: where it is right now (current state), how it got there (how it has behaved over time), and how have other hurricanes tracked under similar conditions (its disposition).  And it’s the same for systems.

To improve your understanding of how your system may respond, understand it as it is.  Define the elements and how those elements interact.  Then, work backward in time to understand previous generations of the system.  Which elements were improved? Which ones were added? Then, like the meteorologist, start at the system’s genesis and move forward to the present to understand its path.  Use the knowledge of its path and the knowledge of systems (it’s important to be the one that improves the immature elements of the system and systems follow S-curves until the S-curve flattens) to broadly define regions where the probability of success is higher.

These methods won’t guarantee success.  But, they will help you choose projects, choose acquisitions, choose technologies, and choose startups in a way that increases your probability of success.

Image credit — Alexander Gerst

Wanting things to be different is a good start, but it’s not enough. To create conditions for things to move in a new direction, you’ve got to change your behavior. But with systems that involve people, this is not a straightforward process.

To create conditions for the system to change, you must understand the system”s disposition – the lines along which it prefers to change.. And to do that, you’ve got to push on the system and watch its response. With people systems, the response is not knowable before the experiment.

If you expect to be able to predict how the system will respond, working with people systems can be frustrating.  I offer some guidance here. With this work, you are not responsible for the system’s response, you are only responsible for how you respond to the system’s response.

If the system responds in a way you like, turn that experiment into a project to amplify the change.  If the system responds in a way you dislike, unwind the experiment.  Here’s a simple mantra – do more of what works and less of what doesn’t. (Thanks to Dave Snowden for this.)

If you don’t like how things are going, you have only one lever to pull.  You can only change.your response to what you see and experience. You can respond by pushing on the system and responding to what you see or you can respond by changing what you think and feel about the system.

But keep in mind that you are part of the system. And maybe the system is running an experiment on you. Either way, your only choice is to choose how to respond.

It’s relatively straightforward to tell the difference between activities that are done well and those that are done poorly. Usually sub-par activities generate visual signals to warn us of their misbehavior. A bill isn’t paid, a legal document isn’t signed or the wrong parts are put in the box. Though the specifics vary with context, the problem child causes the work product to fall off the plate and make a mess on the floor.

We have tools to diagnose the fundamental behind the symptom. We can get to root cause. We know why the plate was dropped. We know how to define the corrective action and implement the control mechanism so it doesn’t happen again. We patch up the process and we’re up and running in no time. This works well when there’s a well-defined in place, when process is asked to do what it did last time, when the inputs are the same as last time and when the outputs are measured like they were last time.

However, this linear thinking works terribly when the context changes. When the old processes are asked to do new work, the work hits the floor like last time, but the reason it hits the floor is fundamentally different. This time, it’s not that an activity was done poorly. Rather, this time there’s something missing altogether. And this time our linear-thinker toolbox won’t cut it. Sure, we’ll try with all our Six Sigma might, but we won’t get to root cause. Six Sigma, lean and best practices can fix what’s broken, but none of them can see what isn’t there.

When the context changes radically, the work changes radically. New-to-company activities are required to get the new work done. New-to-industry tools are needed to create new value. And, sometimes, new-to-world thinking is the only thing that will do. The trick isn’t to define the new activity, choose the right new tool or come up with the new thinking. The trick is to recognize there’s something missing, to recognize there’s something not there, to recognize there’s a need for something new.  Whether it’s an activity, a tool or new thinking, we’ve got to learn to see what’s not there.

Now the difficult part – how to recognize there’s something missing. You may think the challenging part is to figure out what’s needed to fill the void, but it isn’t.  You can’t fill a hole until you see it as a hole. And once everyone agrees there’s a hole, it’s pretty easy to buy the shovels, truck in some dirt and get after it.  But if don’t expect holes, you won’t see them. Sure, you’ll break your ankle, but you won’t see the hole for what it is.

If the work is new, look for what’s missing. If the problem is new, watch out for holes. If the customer is new, there will be holes. If the solution is new, there will be more holes.

When the work is new, you will twist your ankle. And when you do, grab the shovels and start to put in place what isn’t there.

Image credit – Tony Atler

At some point, what worked last time won’t work this time. It’s not if the business model will go belly-up, it’s when. There are two choices. We can bury our heads in the sands of the status quo, or we can proactively observe the world in a forward-looking way and continually reorient ourselves as we analyze and synthesize what we see.

The world is dynamic, but we behave like it’s static. We have massive intellectual inertia around what works today.  In a rearward-looking way, we want to hold onto today’s mental models and we reject the natural dynamism swirling around us.  But the signals are clear. There’s cultural change, political change, climate change and population change. And a lower level, there’s customer change, competition change, technology change, coworker change, family change and personal change. And still, we cling to static mental models and static business models. But how to move from static to dynamic?

Continual observation and scanning is a good place to start. And since things become real when resources are allocated, allocating resources to continually observe and scan sends a strong message. We created this new position because things are changing quickly and we need to be more aware and more open minded to the dynamic nature of our world.  Sure, observation should be focused and there should be a good process to decide on focus areas, but that’s not the point. The point is things are changing and we will continually scan for storms brewing just over the horizon.  And, yes, there should be tools and templates to record and organize the observations, but the important point is we are actively looking for change in our environment.

Observation has no value unless the observed information is used for orientation in the new normal.  For orientation, analysis and synthesis is required across many information sources to develop ways to deal with the unfamiliar and unforeseen. [1] It’s important to have mechanisms to analyze and synthesize, but the value comes when beliefs are revised and mental models are updated. Because the information cuts against history, tradition and culture, to make shift in thinking requires diversity of perspective, empathy and a give-and-take dialog. [1] It’s a nonlinear process that is ironed out as you go.  It’s messy and necessary.

It’s risky to embrace a new perspective, but it’s far riskier to hold onto what worked last time.

[1] Osinga, Frans, P.B. Science, Strategy and War, The strategic theory of John Boyd. New York: Routledge, 2007.

image credit – gabe popa

When the work is new, it can’t be defined and managed like work that has been done before.

Sometimes there’s a tendency to spend months to define the market, the detailed specification and the project timeline and release the package as a tidal wave that floods the organization with new work.  Instead, start with a high-level description of the market, a rough specification and the major project milestones, all of which will morph, grow and inform each other as the team learns.  Instead of a big batch, think bite-sized installments that build on each other. Think straw-man that gets its flesh as the various organizations define their learning objectives and learn them.

Instead of target customer segments and idealized personas, define how the customers will interact with the new product or service. Use the storyboard format to capture sequence of events (what they do), the questions they ask themselves and how they know they’ve done it right. Make a storyboard for the top three to five most important activities the customers must do.  There’s good learning just trying to decide on the top three to five activities, never mind the deep learning that comes when you try to capture real activities of real customers. [Hint – the best people to capture real customer activities are real customers.]

Instead of a detailed list of inputs and outputs, fill in the details of the storyboards.  Create close-ups of the user interfaces and label the dials, buttons and screens.  When done well, the required inputs and outputs bubble to the surface.  And define the customer’s navigation path, as it defines the sequence of things and where the various inputs come to be and the various outputs need to be.  What’s nice is learning by iteration can be done quickly since its done in the domain of whiteboards and markers.

Instead of defining everything, just define what’s new and declare everything else is the same as last time.

The specification for the first prototypes is to bring the storyboards to life and to show the prototypes to real customers.  Refine and revise based on the learning, and rinse and repeat, as needed.

As the design migrates toward customer value and confidence builds, it’s then time to layer on the details and do a deep dive into the details – specs, test protocols, manufacturing, sales and distribution.

At early stages of innovation work, progress isn’t defined by activity, it’s defined by learning.  And it can look like nothing meaningful is happening as there is a lot of thinking and quiet time mixed in with infrequent bursts active activity.  But that’s what it takes to answer the big questions of the front end.

When in doubt, answer the big questions at the expense of the details.  And to stay on track, revisit and refine the learning objectives. And to improve confidence, show it to real customers.

And rinse and repeat, as needed.

Image credit – Jason Samfield

With process improvement, the existing process is refined over time.  With innovation, the work is new. You can’t improve a process that does not yet exist.  Process creation, yes.  Process improvement, no.

Standard work, where the sequence of process steps has proven successful, is a pillar of the manufacturing mindset.  In manufacturing, if you’re not following standard work, you’re not doing it right.  But with innovation, when the work is done for the first time, there can be no standard work. In that way, if you’re following the standard work paradigm, you are not doing innovation.

In a well-established manufacturing process, problems are tightly scoped and constrained. There can be several ways to solve it and one of the ways is usually better than the others. Teams are asked to solve the problem three or four ways and explain the rationale for choosing one solution over the other. With innovation it’s different.  There may not be a solution, never mind three.  With innovation, it’s one-in-a-row solution.  And the real problem is to decide which problem to solve.  If you’re asked to use Fishbone diagrams to solve the problem three or four ways, you’re not doing innovation. Solve it one way, show a potential customer and decide what to do next.

With manufacturing and product development, it’s all about Gantt charts and hitting dates.  The tasks have a natural precedence and all of them have been done before.  There are branches in the plan, but behind them is clear if-then logic.  With innovation, the first task is well-defined.  And the second task – it depends on the outcome of the first.  And completion dates?  No way. If you can predict the completion date, you’re not doing innovation.  And if you’re asked for a fully built-out Gantt chart, you’re in trouble because that’s a misguided request.

Systems in manufacturing can be complicated, with lots of moving parts.  And the problems can be complicated. But given enough time, the experts can methodically figure it out. But with innovation, the systems can be complex, meaning they are not predictable.  Sometimes parts of the system interact strongly with other parts and sometimes they don’t interact at all. And it’s not that they do one or the other, it’s that they do both.  It’s like they have a will of their own, and, sometimes, they have a bad attitude. And if it’s a new system, even the basic rules of engagement are unknown, never mind the changing strength of the interactions.  And if the system is incomplete and you don’t know it, linear thinking of the experts can’t solve it.  If you’re using linear problem solving techniques, you’re not doing innovation.

Manufacturing is about making one thing a million times. Innovation is about choosing among the million possibilities and making one-in-a-row, and then, after the bugs are worked out, making the new thing a million times.  But one-in-a-row must come first.  If you can’t do it once, you can’t do it a million times, even with process improvement, standard work, Gantt charts and Fishbone diagrams.

Image credit jacinta lluch valero

There are two domains – what is and what isn’t. We’re most comfortable in what is and we don’t know much about what isn’t. Neither domain is best and you can’t have one without the other. Sometimes it’s best to swim in what is and other times it’s better to splash around in what isn’t.  Though we want them, there are no hard and fast rules when to swim and when to splash.

Improvement lives in the domain of what is. If you’re running a Six Sigma project, a lean project or a continuous improvement program you’re knee deep in what is. Measure, analyze, improve, and control what is. Walk out to the production floor, count the machines, people and defects, measure the cycle time and eliminate the wasteful activities. Define the current state and continually (and incrementally) improve what is. Clear, unambiguous, measurable, analytical, rational.

The close cousins creativity and innovation live in the domain of what isn’t. They don’t see what is, they only see gaps, gulfs and gullies. They are drawn to the black hole of what’s missing. They define things in terms of difference.  They care about the negative, not the image. They live in the Bizarro world where strength is weakness and far less is better than less. Unclear, ambiguous, intuitive, irrational.

What is – productivity, utilization, standard work. What isn’t – imagination, unstructured time, daydreaming. Predictable – what is. Unknowable – what isn’t.

In the world of what is, it’s best to hire for experience.  What worked last time will work this time. The knowledge of the past is all powerful.  In the world of what isn’t, it’s best to hire young people that know more than you do. They know the latest technology you’ve never heard of and they know its limitations.

Improving what is pays the bills while creating what isn’t fumbles to find the future. But when what is runs out of gas, what isn’t rides to the rescue and refuels. Neither domain is better, and neither can survive without the other.

The magic question – what’s the best way to allocate resources between the domains? The unsatisfying answer – it depends. And the sextant to navigate the dependencies – good judgement.

Image credit – JD Hancock

When doing new things there is no predictability. There’s speculation, extrapolation and frustration, but no prediction. And the labels don’t matter.  Whether it’s called creativity, innovation, discontinuous improvement or disruption there’s no prediction.

The trick in the domain complexity is to make progress without prediction.

The first step is to try to define the learning objective.  The learning objective is what you want to learn. And its format is – We want to learn that [fill in the learning objective here].  It’s fastest to tackle one learning objective at a time because small learning objectives are achieved quickly with small experiments.  But, it will be a struggle to figure out what to learn.  There will be too many learning objectives and none will be defined narrowly.  At this stage the fastest thing to do is stop and take a step back.

There’s nothing worse than learning about the wrong thing.  And it’s slow. (The fastest learning experiments are the ones that don’t have to be run.) Before learning for the sake of learning, take the necessary time to figure out what to learn. Ask some questions: If it worked could it reinvent your industry? Could it obsolete your best product? Could it cause competitors to throw in the towel?  If the answer is no, stop the project and choose one where the answer is yes. Choose a meaningful project, or don’t bother.

First learning objective – We want to learn that, when customers love the new concept, the company will assign appropriate resources to commercialize it.  If there’s no committment up front, stop.  If you get committment, keep going. (Without upfront buy-in the project relies on speculation, the wicked couple of prediction and wishful thinking.)

Second learning objective – We want to learn that customers love the new concept.  This is not “I think customers will love it.” or “Customers may love it.” In the standard learning objective format – We want to learn that [customers love the new concept].  Next comes the learning plan.

What will you build for customers to help them understand the useful novelty of the revolutionary concept?  For speed’s sake, build a non-functional prototype that stands for the concept.  It’s a thin skin wrapped around an empty box that conveys the essence of the novelty.  No skeleton, just skin.  And for speed’s sake, show it to fewer customers than you think reasonable.  And define the criteria to decide they love it.  There’s no trick here. Ask “Do they love it?” and use your best judgement.  At this early stage, the answer will be no.  But they’ll tell you why they don’t love it, and that’s just the learning you’re looking for.

Use customer input to reformulate the learning objective and build a new prototype and repeat.  The key here is to build fast, test fast, learn fast and repeat fast.  The art becomes defining the simplest learning objectives, building the simplest prototypes and making decisions with data from the fewest customers.

With complexity and newness prediction isn’t possible. But learning is.

And learning doesn’t have to take a lot of time.

Image credit — John William Waterhouse

For established companies, when times are good, it’s not the right time to try something new – the resources are there but the motivation is not; and when times are tough it’s also the wrong time to try something new – the motivation is there but the breathing room is not.  There are an infinite number of scenarios, but for the established company it’s never a good time to try something new.

For startup companies, when times are good, it’s the right time to try something new – the resources are there and so is the motivation; and when times are tough it’s also the right time to try something new – the motivation is there and breathing room is a sign of weakness.  Again, the scenarios are infinite, but for the startup is always a good time to try something new.

But this is not a binary world. To create new markets and new customers, established companies must be a little bit startup, and to scale, startups must ultimately be a little bit established. This ambidextrous company is good on paper, but in the trenches it gets challenging. (Read Ralph Ohr for an expert treatment.)  The establishment regime never wants to do anything new and the startup regime always wants to.  There’s no middle ground – both factions judge each other through jaded lenses of ROI and learning rate and mutual misunderstanding carries the day.  Trouble is, all companies need both – established companies need new markets and startups need to scale. But it’s more complicated than that.

As a company matures the balance of power should move from startup to established.  But this tricky because the one thing power doesn’t like to do is move from one camp to another. This is the reason for the “perpetual startup” and this is why it’s difficult to scale.  As the established company gets long in the tooth the balance of power should move from the establishment to the startup.  But, again, power doesn’t like to change teams, and established companies squelch their fledgling startup work. But it’s more complicated, still.

The competition is ever-improving, the economy is ever-changing and the planet is ever-warming.  New technologies come on-line, and new business models test the waters. Some work, some don’t.  Huge companies buy startups just to snuff them out and established companies go away.  The environment is ever-changing on all fronts.  And the impermanence pushes and pulls on the pendulum of power dynamics.

All companies want predictability, but they’ll never have it.  All growth models are built on rearward-looking fundamentals and forward-looking conjecture.  Companies will always have the comfort of their invalid models, but will never the predictability they so desperately want.  Instead of predictability, companies would be better served by a strong sense of how it wants to go about its business and overpowering genetics of adaptability.

For a strong definition of how to go about business, a simple declaration does nicely. “We want to spend 80% of our resources on established-company work and 20% on startup-company work.” (Or 90-10, or 95-5.)  And each quarter, the company measures itself against its charter, and small changes are made to keep things on track.  Unless, of course, if the environment changes or the business model runs out of gas.  And then the company adapts.  It changes its approach and it’s projects to achieve its declared 80-20 charter, or, changes the charter altogether.

A strong charter and adaptability don’t seem like good partners, but they are.  The charter brings focus and adaptability brings the change necessary to survive in an every-changing environment.  It’s not easy, but it’s effective.  As long as you have the right leaders.

Image credit – Rick Abraham1

When doing something from the first time you’re going to get it wrong.  There’s no shame in that because that’s how it goes with new work. But more strongly, if you don’t get it wrong you’re not trying hard enough.  And more strongly, embrace the inherent wrongness as a guiding principle.

Take Small Bites. With new work, a small scope is better than a large one.  But it’s exciting to do new work and there’s a desire to deliver as much novel usefulness as possible.  And, without realizing it, the excitement can lead to a project bloated with novelty.  With the best intentions, the project team is underwater with too much work and too little time.  With new work, it’s better to take one bite and swallow than three and choke.

Ratchet Thinking. With new work comes passion and energy.  And though the twins can be helpful and fun to have around, they’re not always well-behaved.  Passion can push a project forward but can also push it off a cliff. Energy creates pace and can quickly accelerate a project though the milestones, but energy can be careless and can just as easily accelerate a project in the wrong direction.  And that’s where ratchet thinking can help.

As an approach, the objective of ratchet thinking is to create small movements in the right direction without the possibility of back-sliding.  Solve a problem and click forward one notch; solve a second problem and click forward another notch.  But, with ratchet thinking, if the third problem isn’t solved, the project holds its ground at the second notch.  It takes a bit more time to choose the right problem and to solve it in a way that cannot unwind progress, but ultimately it’s faster.  Ratchet thinking takes the right small bite, chews, swallows.

Zero Cost of Change. New work is all about adding new functions, enhancing features and fixing what’s broken.  In other words, new work is all about change. And the faster change can happen, the faster the product/service/business model is ready for sale.  But as the cost of change increases the rate of changes slows.  So why not design the project to eliminate the cost of change?

To do that, design the hardware with a bit more capability and headroom so there’s some wiggle room to handle the changes that will come.  Use a modular approach for the software to minimize the interactions of software changes and make sure the software can be updated remotely without customer involvement.  And put in place a good revision control (and tracking) mechanism.

Doing new work is full of contradictions: move quickly, but take the time to think things through; take on as much as you can, but no more; be wrong, but in the right way; and sometimes slower is faster.

But doing new work you must.

image credit – leasqueaky

Today’s work is complicated with electronic and mechanical subsystems wrapped in cocoons of software; coordination of matrixed teams; shared resources serving multiple projects; providing world class services in seventeen languages on four continents. And the complexity isn’t limited to high level elements.  There is a living layer of complexity growing on all branches of the organization right down to the leaf level.

Complexity is real, and it complicates things.  To run projects and survive in the jungle of complexity it’s important to know how to put the right pieces together and provide the right answers.  But as a leader it’s more important to slash through the complexity and see things as they are.  And for that, it’s more important to know how ask diabolically simple questions (DSQ).

Project timelines are tight and project teams like to start as soon as they can.  Too often teams start without clarity on what they’re trying to achieve.  At these early stages the teams make record progress in the wrong direction.  The leader’s job is to point them in the right direction, and here’s the DSQ to set them on their way: What are you trying to achieve?

There will likely be some consternation, arm waiving and hand wringing.  After the dust settles, help the team further tighten down the project with this follow-on DSQ:  How will you know you achieved it?

For previous two questions there are variants that works equally well for work that closer to the fuzzy front end: What are you trying to learn? and How will you know you learned it?

There is no such thing as a clean-sheet project and even the most revolutionary work builds on the existing system.  Though the existing business model, service or product has been around for a long time, the project team doesn’t really know how it works.  They know they should know but they’re afraid to admit it. Let them off the hook with this beauty: How does it work today?

After the existing system is defined with a simple block diagram (which could take a couple weeks) it’s time to help the project team focus their work.  The best DSQ for the job: How is it different from the existing system?  If the list is too long there’s too much newness and if it’s too short there’s not enough novelty.  If they don’t know what’s different, ask them to come back when they know.

After the “what’s different” line of questioning, the team must be able to dive deeper.  For that it’s time one of the most powerful DSQs in the known universe: What problem are you trying to solve? Expect frustration and complicated answers.  Ask them to take some time and for each problem describe it on a single page using less than ten words.  Suggest a block diagram format and ask them to define where and when the problem occurs.  (Hint: a problem is always between two components/elements of the system.)  And the tricky follow-on DSQ: How will you know you solved it? No need to describe the reaction to that one.

Though not an exhaustive list, here are some of my other favorite DSQs:

Who will buy it, how much will they pay, and how do you know?

Have we done this before?

Have you shown it to a real customer?

How much will it cost and how do you know?

Whose help do we need?

If the prototype works, will we actually do anything with it?

Diabolically simple questions have the power to heal the project teams and get them back on track.  And over time, DSQs help the project teams adopt a healthy lifestyle.  In that way, DSQs are like medicine – they taste bad but soon enough you feel better.

Image credit – Daniela Hartmann