Shipulski On Design

Posts Tagged ‘Understanding Physics’

When it’s time to innovate, the first task is usually to define the Idealized Future State (IFS).  The IFS is a word picture that captures what it looks like when the innovation work has succeeded beyond our wildest dreams. The IFS, so it goes, is directional so we can march toward the right mountain and inspirational so we can sustain our pace over the roughest territory.

For the IFS to be directional, it must be aimed at something – a destination.  But there’s a problem. In a sea of uncertainty, where the work has never been done before and where there are no existing products, services or customers, there are an infinite number of IFRs/destinations to guide our innovation work.  Open question – When the territory is unknown, how do we choose the right IFS?

For the IFS to be inspirational, it must create yearning for something better (the destination). And for the yearning to be real, we must believe the destination is right for us. Open question – How can we yearn for an IFS when we really can’t know it’s the right destination?

Maps aren’t the territory, but they are a collection of all possible destinations within the design space of the map.  If you have the right map, it contains your destination. And for a long time now, the old paper maps have helped people find their destinations. But on their own maps don’t tell us the direction to drive.  If you have a map of the US and you want to drive to Kansas, in which direction do you drive? It depends. If in California, drive east; if in Mississippi, drive north; if in New Hampshire, drive west; and in Minnesota, drive south. If Kansas is your idealized future state, the map alone won’t get your there.  The direction you drive depends on your location.

GPS has been a nice addition to maps. Enter the destination on the map, ask the satellites to position us globally and it’s clear which way to drive. (I drive west to reach Kansas.) But the magic of GPS isn’t in the electronic map, GPS is magic because it solves the location problem.

Before defining the idealized future state, define your location. It grounds the innovation work in the reality of what is, and people can rally around what is. And before setting the innovation direction with the IFS, define the next problems to solve and walk in their direction.

Image credit – Adrian Brady

When a hurricane is on the horizon, we are all glued to our TVs. We want to know where it track so we know we’ll be safe.  Will it track north and rumble over the top of us or will it track east and head out to sea?  This is not trivial. In one scenario we lose our house and in the other the crazy surfers get to ride huge waves.

The meteorologist shows us a time-lapse of the storm center hour-by-hour. It was one hundred miles off shore an hour ago, it’s fifty miles off shore now and it will hit the shoreline in an hour. Drawing a line from where it was, through its location in the moment, the meteorologist can extrapolate where it will be an hour from now.  In the short term, the storms trajectory will be unchanged and its momentum will help it maintain its pace.  It’s pretty clear to everyone where the storm will be in an hour. No magic here.

But the good meteorologists can forecast a hurricane’s path days in advance. In a phenomenological way, they use behavior models of past storms, assume this storm is like past storms, turn the crank and forecast its trajectory. And they’re right more times than not. And they’re right enough to determine who should evacuate and who should sit tight. This is borderline magic.

The best meteorologists know where hurricanes want go because they understand hurricanes. They know hurricanes want to run in straight lines, if not follow gentle curves. They know hurricanes get anxious when they hop from sea to land, and they know, given the choice, will skirt the coastline and head back home to the salt water.  Meteorologists know the rules hurricane’s live by and use that knowledge to tighten their forecast of the storm’s path.

Just as hurricanes have a desire to follow their hearts, technologies have a similar desire climb the evolutionary ladder. Just as hurricanes behave like their predecessors, technologies behave like their grandparents, aunts and uncles. And just as a meteorologist, using their knowledge of  historical patterns and an understanding of hurricane genetics can forecast the path of a hurricane, technologists can forecast the path of technologies using historical patterns and an understanding of what technologies want.

And like with hurricanes, the best way to forecast the path of a technology is to define where it was, draw a line through where it is and project its trajectory into the future.  Like hurricanes, technologies move in straight lines or gentle S-curves, so their next move is easy to forecast. If a technology has improved year-over-year, it will likely continue to improve. And if this year’s performance is the same as last year, it’s behavior will remain unchanged going forward.  That’s how it goes with technologies.

The best technologists are like horse whisperers in that they can hear the inner voice of technologies. They know when a technology is ready to grow from infant to adolescent and know when a technology is ready to retire. The best technologists can read the tea leaves of the patent landscape and, knowing the predisposition of technologies, can forecast the next evolution.  But just as some ranch owners don’t believe in horse whisperers, some company leaders don’t believe technology whisperers can forecast technologies.

But for believers and non-believers alike, it’s more effective to compare forecasting capabilities of technologists with the forecasting capabilities of meteorologists.  The notions of trajectory and momentum have clear physical interpretations for hurricanes and technologies, and historical models of storm trajectories map directly to evolutionary paths of technologies.

If you’re looking to forecast where the next big storm will make landfall, hire a great meteorologist. But if you’re looking to forecast when the next technology will rip the roof off your business model, hire a great technology whisperer.

Image credit – NASA

By definition, when the work is new there is uncertainty.  And uncertainty can be stressful. But, instead of getting yourself all bound up, accept it.  More than that, relish in it.  Wear it as a badge of honor.  Not everyone gets the chance to work on something new – only the best do.  And, because you’ve been asked to do work with a strong tenor of uncertainty, someone thinks you’re the best.

But uncertainty is an unknown quantity, and our systems have been designed to reject it, not swim in it.  When companies want to get serious they drive toward a culture of accountability and the new work gets the back seat.  Accountability is mis-mapped to predictability, successful results and on time delivery.  Accountability, as we’ve mapped it, is the mortal enemy of new work.  When you’re working on a project with a strong element of uncertainty, the only certainty is the task you have in front of you.  There’s no certainty on how the task will turn out, rather, there’s only the simple certainty of the task.

With work with low uncertainty there are three year plans, launch timelines and predictable sales figures. Task one is well-defined and there’s a linear flow of standard work right behind it – task two through twenty-two are dialed in. But when working with uncertainty, the task at hand is all there is.  You don’t know the next task.  When someone asks what’s next the only thing you can say is “it depends.”  And that’s difficult in a culture of traditional accountability.

An “it depends” Gannt chart is an oxymoron, but with uncertainty step two is defined by step one.  If A, then B.  But if the wheels fall off, I’m not sure what we’ll do next.  The only thing worse than an “it depends” Gantt chart is an “I’m not sure” Gannt chart.  But with uncertainty, you can be sure you won’t be sure.  With uncertainty, traditional project planning goes out the window, and “it depends” project planning is the only way.

With uncertainty, traditional project planning is replaced by a clear distillation of the problem that must be solved.  Instead of a set of well-defined tasks, ask for a block diagram that defines the problem that must be solved.  And when there’s clarity and agreement on the problem that must be solved, the supporting tasks can be well-defined.  Step one – make a prototype like this and test it like that. Step two – it depends on how step one turns out.  If it goes like this then we’ll do that.  If it does that, we’ll do the other.  And if it does neither, we’re not sure what we’ll do.  You don’t have to like it, but that’s the way it is.

With uncertainty, the project plan isn’t the most important thing.  What’s most important is relentless effort to define the system as it is.  Here’s what the system is doing, here’s how we’d like it to behave and, based on our mechanism-based theory, here’s the prototype we’re going to build and here’s how we’re going to test it.  What are we going to do next?  It depends.

What’s next? It depends. What resources do you need? It depends. When will you be done? It depends.

Innovation is, by definition, work that is new.  And, innovation, by definition, is uncertain.  And that’s why with innovation, it depends.  And that’s why innovation is difficult.

And that’s why you’ve got to choose wisely when you choose the people that do your innovation work.

Image credit – Sara Biljana Gaon (off)

Everyone wants to do more innovation.  But how? To figure out what’s going on with their innovation programs, companies spend a lot of time to put projects into buckets but this generates nothing but arguments about whether projects are disruptive, radical innovation, discontinuous, or not.  Such a waste of energy and such a source of conflict.  Truth is, labels don’t matter.  The only thing that matters is if the projects, as a collection, meet corporate growth objectives.  Sure, there should be a short-medium-long look at the projects, but, for the three time horizons the question is the same – Do the projects meet the company’s growth objectives?

To create the causes and conditions for innovation, start with a clear growth objective by geography.  Innovation must be measured in dollars.

Good judgement is required to decide if a project is worthy of resources.  The incremental sales estimates are easy to put together.  The difficult parts are deciding if there’s enough sizzle to cause customers to buy and deciding if the company has the chops to do the work.  The difficulty isn’t with the caliber of judgement, rather it’s insufficient information provided to the people that must use their good judgement.  In shorth, there is poor clarity on what the projects are about. Any description of the projects blurry and done at a level of abstraction that’s too high.  Good judgement can’t be used when the picture is snowy, nor can it be effective with a flyby made in the stratosphere.

To create the causes and conditions for innovation, demand clarity and bedrock-level understanding.

To guarantee clarity and depth, use the framework of novel, useful, successful. Give the teams a tight requirement for clarity and depth and demand they meet it.  For each project, ask – What is the novelty? How is it useful? When the project is completed, how will everyone be successful?

A project must deliver novelty and the project leader must be able to define it on one page.  The best way to do this is to create physical (functional) model of the state-of-the-art system and modify it with the newness created by the project (novelty called out in red).  This model comes in the form of boxes that describe the system elements (simple nouns) and arrows that define the actions (simple verbs).  Think hammer (box – simple noun) hits (arrow -simple verb) nail (box – simple noun) as the state-of-the-art system and the novelty in red – a thumb protector (box) that blocks (arrow) hammer (box).  The project delivers a novel thumb protector that prevents a smashed thumb.  The novelty delivered by the project is clear, but does it pass the usefulness test?

To create the causes and conditions for innovation, demand a one-page functional model that defines and distills down to bedrock level the novelty created by the project.  And to help the project teams do it, hire a good teach teacher and give them the tools, time and training.

The novelty delivered by a project must be useful and the project leader must clearly define the usefulness on one page.  The best way to do this is with a one page hand sketch showing the customer actively using the novelty. In a jobs-to-be-done way, the sketch must define where, when and how the customer will realize the usefulness. And to force distillation blinding, demand they use a fat, felt tip marker. With this clarity, leaders with good judgement can use their judgement effectively. Good questions flow freely. Does every user of a hammer need this? Can a left-handed customer use the thumb guard? How does it stay on? Doesn’t it get in the way? Where do they put it when they’re done? Do they wear it all the time?  With this clarity, the questions are so good there is no escape.  If there are holes they will be uncovered.

To create the causes and conditions for innovation, demand a one-page hand sketch of the customer demonstrating the useful novelty.

To be successful, the useful novelty must be sufficiently meaningful that customers pay money for it.  The standard revenue projections are presented, but, because there is deep clarity on the novelty and usefulness, there is enough context for good judgement to be effective.  What fraction of hammer users hit their thumbs? How often? Don’t they smash their fingers too?  Why no finger protection?  Because of the clarity, there is no escape.

To create the causes and conditions, use the deep clarity to push hard on buying decisions and revenue projections.

The novel, useful, successful framework is a straightforward way to decide if the project portfolio will meet growth objectives.  It demands a clear understanding of the newness created by the project but, in return, provides context needed to use good judgement.  In that way, because projects cannot start without passing the usefulness and successfulness tests, resources are not allocated to unworthy projects.

But while clarity and this level of depth is a good start, it’s not enough.  It’s time for a deeper dive. The project must distill the novelty into a conflict diagram, another one-pager like the others, but deeper.  Like problem definition on steroids, a conflict must be defined in space – between two things (thumb and face of hammer head) – and time (just as the hammer hits thumb).  With that, leaders can ask before-during-after questions.  Why not break the conflict before it happens by making a holding mechanism that keeps the thumb out of the strike zone? Are you sure you want to solve it during the conflict time (when the hammer hits thumb)?  Why not solve it after the fact by selling ice packs for their swollen thumbs?

But, more on the conflict domain at another time.

For now, use novel, useful, successful to stop bad projects and start good ones.

Image credit – Natashi Jay

If you think something can’t be done, it won’t get done.  And if you think it may be possible, or is possible, it may get done.  Those are the rules.

If an expert says it will work, it will work.  If they say it won’t work, it might.  Experts can tell you will work, but can’t tell you what won’t.

If your boss tells you it won’t work, it might. Give it a try.  It will be fun if it works.

If you can’t make it work, make it worse and then do the opposite.

If you can’t explain the problem to your young kids, you don’t understand the situation and you won’t make it work.

If something didn’t work ten years ago, it may work now. Technology is better and we’re smarter.  More likely it would have worked ten years ago if they ran more than one crude experiment before they gave up.

If you can’t draw a one page sketch of the problem, it may never work.

If you can’t make it work, put it down for three days. Your brain may make it work while you’re sleeping.

If you don’t know the problem, you can’t make it work.  Be sure you’re trying to solve the right problem.

If your boss tells you it will work, it might.  If they tell you how to make it work, let them do it.

If none of your attempts have been fruitful and you’re out of tricks, purposely make one performance attribute worse to free up design space. That may work.

If you don’t know when the problem occurs, you don’t know much. Your solutions won’t work.

If you tried everything and nothing worked, ask someone for help whose specialty in an unrelated area.  They may have made it work in a different domain.

If you think everyone in the group understands the problem the same way, they don’t.  There’s no way they’ll agree on the best way to make it work. Don’t wait for consensus.

If you don’t try, that’s the only way to guarantee it won’t work.

Image credit – Simon Greig

If you don’t have a problem, there’s no problem. There are no resources without a problem and certainly no focus or momentum.  If you don’t know your problem, stop.  Take time to define your problem using a single page.  Make a sketch or make a block diagram but make it clear.  Make it so the problem description stands on its own. After you’ve defined your problem and someone calls it an “opportunity”, walk away because they can’t help you.  Taking advantage of opportunities is optional, but solving problems is mission critical.  No one worth their salt works on opportunities.  Rock stars solve problems.

After you’ve gnawed on a problem for a month and it hasn’t given in, what do you do?  When you’ve thrown everything at a problem and it still stands tall, what do you do?  When you’ve tried all your tricks and the intractable problem is still blocking an already overdue product launch, what do you do?  What you do is find someone who is unafraid trade an intractable problem for a solvable one, someone who will courageously give ground with the hope of opening up new design space, someone who will unabashedly take an anti-conventional (and hopefully controversial) approach.  What you do is find a rock star.

Intractable problems are not usually intractable; rather, intractable problems are either poorly-defined problems or are the wrong problem altogether.  Either way, it takes someone with courage, usually an outsider, to redefine the problem or see it differently.  But because of pride, an outsider can be brought in only after the team has exhausted all other possibilities.  Unless there’s a problem with the problem solving team (they can’t solve the problem), there’s no problem.  And without a problem, the team won’t accept help from an outsider.

At the rodeo when the cowboy is bucked off the raging bull, the cowboy runs away from the bull but the rodeo clown runs toward the bull to distract it.  Like the rodeo clown, the problem solving rock star runs toward raging problems at full tilt.  The rock star puts it all on the line as she grabs the problem by the scruff of the neck, wrestles it to the ground and hog ties it.  There’s no shyness, just well-practiced technique wrapped in implicit knowledge.  With courage and a cloud of dust, it’s no-holds-barred problem solving until the problem gives it up. Nothing is sacred, no assumptions go unchallenged, and no details are too small to ignore.  Like rodeo clowns, rock stars know their work looks funny from the outside, but they don’t care.  All they care about is solving the problem at hand. Right here, right now.

Before your next intractable problem, take a minute to scan your organization for the special people who have the courage to run toward even the most difficult problems.  Don’t be fooled by titles, positional power or how they dress.  Look deeply because like rodeo clowns, your magical problem solvers may not look the part on the outside.

Image credit – Ed Schipul

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

At the most basic level, business is about allocating resources to the best projects and executing those projects well.  Said another way, business is about deciding what to work on and then working effectively.  But how to go about deciding what to work on?  Here is a cascade of questions to start you on your journey.

What are your company’s guiding principles?  Why does it exist? How does it want to go about its life?   These questions create context from which to answer the questions that follow.  Once defined, all your actions should align with your context.

How has the business environment changed? This is a big one.  Everything is impermanent.  Change is the status quo.  What worked last time won’t work this time.  Your success is your enemy because it stunts intentions to work on new things.  Define new lines of customer goodness your competitors have developed; define how their technologies have increased performance; search YouTube to see the nascent technologies that will displace you; put yourself two years in the future where your customers will pay half what they pay today.  These answers, too, define the context for the questions that follow.

What are you working on? Define your fully-staffed projects. Distill each to a single page. Do they provide new customer value?  Are the projects aligned with your company’s guiding principles? For those that don’t, stop them.  How do your fully-staffed projects compare to the trajectory of your competitors’ offerings?  For those that compare poorly, stop them.

For projects that remain, do they meet your business objectives?  If yes, put your head down and execute.  If no, do you have better projects?  If yes, move the freed up resources (from the stopped projects) onto the new projects.  Do it now.  If you don’t have better projects, find some.  Use lines of evolution for technological systems to figure out what’s next, define new projects and move the resources.  Do it now.

The best leading indicator of innovation is your portfolio of fully-staffed projects.  Where other companies argue and complain about organizational structure, move your best resources to your best projects and execute.  Where other companies use politics to trump logic, move your best resources to your best projects and execute.  Where other successful companies hold on to tired business models and do-what-we-did-last-time projects, move your best resources to your best projects and execute.

Be ruthless with your projects.  Stop the bad ones and start some good ones. Be clear about what your projects will deliver – define the novel customer value and the technical work to get there.  Use one page for each.  If you can’t define the novel customer value with a simple cartoon, it’s because there is none.  And if you can’t define how you’ll get there with a hand sketch, it’s because you don’t know how.

Define your company’s purpose and use that to decide what to work on.  If a project is misaligned, kill it. If a project is boring, don’t bother.  If it’s been done before, don’t do it.  And if you know how it will go, do something else.

If you’re not changing, you’re dying.

Image credit – David Flam

One of the best ways to improve your brand is to improve your products.  The most common way is to provide more goodness for less cost – think miles per gallon.  Usually it’s a straightforward battle between market leaders, where one claims quantifiable benefit over the other – Ours gets 40 mpg and theirs doesn’t.   And the numbers are tied to fully defined test protocols and testing agencies to bolster credibility.  Here’s the data.  Buy ours

But there’s a more powerful way to improve your brand, and that’s to map your products to reliability.  It’s far a more difficult game than the quantified head-to-head comparison of fuel economy and it’s a longer play, but done right, it’s a lasting play that is difficult to beat.  Run the thought experiment:  think about the brands you associate with reliability.  The brands that come to mind are strong, lasting brands, brands with staying power, brands whose products you want to buy, brands you don’t want to compete against.  When you buy their products you know what you’re going to get.  Your friends tell you stories about their products.

There’s a complete a complete tool set to create products that map to reliability, and they work.  But to work them, the commercialization team has to have the right mindset.  The team must have the patience to formally define how all the systems work and how they interact. (Sounds easy, but it can be painfully time consuming and the level of detail is excruciatingly extreme.)  And they have to be willing to work through the discomfort or developing a common understanding how things actually work. (Sounds like this shouldn’t be an issue, but it is – at the start, everyone has a different idea on how the system works.)  But more importantly, they’ve got to get over the natural tendency to blame the customer for using the product incorrectly and learn to design for unintended use.

The team has got to embrace the idea that the product must be designed for use in unpredictable ways in uncontrolled conditions. Where most teams want to narrow the inputs, this team designs for a wider range of inputs.  Where it’s natural to tighten the inputs, this team designs the product to handle a broader set of inputs.  Instead of assuming everything will work as intended, the team must assume things won’t work as intended (if at all) and redesign the product so it’s insensitive to things not going as planned.  It’s strange, but the team has to design for hypothetical situations and potential problems.  And more strangely, it’s not enough to design for potential problems the team knows about, they’ve got to design for potential problems they don’t know about. (That’s not a typo.  The team must design for failure modes it doesn’t know about.)

How does a team design for failure modes it doesn’t know about? They build a computer-based behavioral model of the system, right down to the nuts, bolts and washers, and they create inputs that represent the environment around the system.  They define what each element does and how it connects to the others in the system, capturing the governing physics and propagation paths of connections. Then they purposefully break the functions using various classes of failure types, run the analysis and review the potential causes.  Or, in the reverse direction, the team perturbs the system’s elements with inputs and, as the inputs ripple through the design, they find previously unknown undesirable (harmful) functions.

Purposefully breaking the functions in known ways creates previously unknown potential failure causes.  The physics-based characterization and the interconnection (interaction) of the system elements generate unpredicted potential failure causes that can be eliminated through design.  In that way, the software model helps find potential failures the team did not know about.  And, purposefully changing inputs to the system, again through the physics and interconnection of the elements, generates previously unknown harmful functions that can be designed out of the product.

If you care about the long-term staying power of your brand, you may want to take a look at TechScan, the software tool that makes all this possible.

Image credit — Chris Ford.

Immediately after there’s an elegant solution to a previously intractable problem, the solution is obvious to others.  But, just before the solution those same folks said it was impossible to solve.  I don’t know if there’s a name for this phenomenon, but it certainly causes hart burn for those brave enough to take on the toughest problems.

Intractable problems are so fundamental they are no longer seen as problems.  Over the years experts simply accept these problems as constraints that must be complied with.   Just as the laws of physics can’t be broken, experts behave as if these self-made constraints are iron-clad and believe these self-build walls define the viable design space.  To experts, there is only viable design space or bust.

A long time ago these problems were intractable, but now they are not.  Today there are new materials, new analysis techniques, new understanding of physics, new measurement systems and new business models.. But, they won’t be solved.  When problems go unchallenged and constrain design space they weave themselves into the fabric of how things are done and they disappear.   No one will solve them until they are seen for what they are.

It takes time to slow down and look deeply at what’s really going on.  But, today’s frantic pace, unnatural fascination with productivity and confusion of activity with progress make it almost impossible to slow down enough to see things as they are.  It takes a calm, centered person to spot a fundamental problem masquerading as standard work and best practice.  And once seen for what they are it takes a courageous person to call things as they are.  It’s a steep emotional battle to convince others their butts have been wet all these years because they’ve been sitting in a mud puddle.

Once they see the mud puddle for what it is, they must then believe it’s actually possible to stand up and walk out of the puddle toward previously non-viable design space where there are dry towels and a change of clothes.  But when your butt has always been wet, it’s difficult to imagine having a dry one.

It’s difficult to slow down to see things as they are and it’s difficult to re-map the territory.   But it’s important.  As continuous improvement reaches the limit of diminishing returns, there are no other options.  It’s time to solve the intractable problems.

Image credit – Steven Depolo

Work is never perfect, family life is never perfect and neither is the interaction between them.  Regardless of your expectations or control strategies, things go as they go.  That’s just what they do.

We have far less control than we think.  In the pure domain of physics the equations govern predictively – perturb the system with a known input in a controlled way and the output is predictable.  When the process is followed, the experimental results repeat, and that’s the acid test.  From a control standpoint this is as good as it gets. But even this level of control is more limited than it appears.

Physical laws have bounded applicability – change the inputs a little and the equation may not apply in the same way, if at all. Same goes for the environment. What at the surface looks controllable and predictable, may not be.  When the inputs change, all bets are off – the experimental results from one test condition may not be predictive in another, even for the simplest systems, In the cold, unemotional world of physical principles, prediction requires judgement, even in lab conditions.

The domains of business and life are nothing like controlled lab conditions.  And they’re and not governed by physical laws.  These domains are a collection of complex people systems which are governed by emotional laws.  Where physics systems delivers predictable outputs for known inputs, people systems do not.  Scenario 1. Your group’s best performer is overworked, tired, and hasn’t exercised in four weeks.  With no warning you ask them to take on an urgent and important task for the CEO.  Scenario 2. Your group’s best performer has a reasonable workload (and even a little discretionary time), is well rested and maintains a regular exercise schedule, and you ask for the same deliverable in the same way.  The inputs are the same (the urgent request for the CEO), the outputs are far different.

At the level of the individual – the building block level – people systems are complex and adaptive,  The first time you ask a person to do a task, their response is unpredictable.  The next day, when you ask them to do a different task, they adapt their response based on yesterday’s request-response interaction, which results in a thicker layer of unpredictability.  Like pushing on a bag of water, their response is squishy and it’s difficult to capture the nuance of the interaction.  And it’s worse because it takes a while for them to dampen the reactionary waves within them.

One person interacts with another and groups react to other groups.  Push on them and there’s really no telling how things will go.  One cylo competes with another for shared resources and complexity is further confounded.  The culture of a customer smashes against your standard operating procedures and the seismic pressure changes the already unpredictable transfer functions of both companies.  And what about the customer that’s also your competitor?  And what about the big customer you both share?  Can you really predict how things will go? Do you really have control?

What does all this complexity, ambiguity, unpredictability and general lack of control mean when you’re trying to build a culture of accountability?  If people are accountable for executing well, that’s fine.  But if they’re held accountable for the results of those actions, they will fail and your culture of accountability will turn into a culture of avoiding responsibility and finding another place to work.

People know uncertainty is always part of the equation, and they know it results in unpredictability.  And when you demand predictability in a system that’s uncertain by it’s nature, as a  leader you lose credibility and trust.

As we swim together in the storm of complexity, trust is the life boat.  Trust brings people together and makes it easier to row in the same direction.  And after a hard day of mistakenly rowing in the wrong direction, trust helps everyone get back in the boat the next day and pull hard in the new direction you point them.

Image credit – NASA