Archive for the ‘Culture’ Category

What They Didn’t Teach Me in Engineering School

The technical stuff is the easy part. Technical systems respond predictably, but people don’t.

There’s nothing worse than solving the wrong problem, so before you start solving you’ve better done a whole lot of defining.

There is no exact answer; engineering is all about judgment.

Organizational structure is important.  Whatever the structure, see its strengths and make them work for you.  If you try to fight it, it will eat you.

Innovation isn’t about ideas, innovation is about commercializing ideas.

Engineering analysis can win minds, but not hearts. And hearts govern minds.

The engineer’s role is not to minimize risk; it’s to understand the commercial reward and take risk accordingly.

What people believe is far more powerful than what they think.

New technology threatens status quoers, and, in turn, they block it.

There is no problem unless someone important thinks there’s one.

All technical systems are really human systems masquerading as technical systems.

If you let it, fear dominates. Be afraid and do it anyway.  But along the way, keep in mind that others are too afraid to try.

Engineering is not sane and rational; engineering is about people.

Own The Behavior

The system is big and complex and its output is outside your control. Trying to control these outputs is a depressing proposition, yet we’re routinely judged (and judge ourselves) on outputs.  I think it’s better to focus on system inputs, specifically your inputs to the system.

When the system responds with outputs different than desired, don’t get upset. It’s nothing personal. The system is just doing its job. It digests a smorgasbord of inputs from many agents just like you and does what it does. Certainly it’s alive, but it doesn’t know you. And certainly it doesn’t respond differently because you’re the one providing input. The system doesn’t take its output personally, and neither should you.

When the system’s output is not helpful, instead of feeling badly about yourself, shift your focus from system output to the input you provide it. (Remember, that’s all you have control over.) Did you do what you said you’d do? Were you generous? We’re you thoughtful? We’re you insightful? Did you give it your all or did you hold back? If you’re happy with the answers you should feel happy with yourself. Your input, your behavior, was just as it was supposed to be.  Now is a good time to fall back on the insightful grade school mantra, “You get what you get, and you don’t get upset.”

If your input was not what you wanted, then it’s time to look inside and ask yourself why. At times like these it’s easy to blame others and outside factors for our behavior. But at times like these  we must own the input, we must own the behavior. Now, owning the behavior doesn’t mean we’ll behave the same way going forward, it just means we own it. In order to improve our future inputs we’ve got to understand why we behaved as we did, and the first step to better future inputs is owning our past behavior.

Now, replace “system” with “person”, and the argument is the same. You are responsible for your input to the person, and they are responsible for their output (their response). When someone’s output is nonlinear and offensive, you’re not responsible for it, they are. Were you kind? Thoughtful? Insightful? If yes, you get what you get, and you don’t get upset. But what if you weren’t? Shouldn’t you feel responsible for their response? In a word, no. You should feel badly about your input – your behavior – and you should apologize. But their output is about them. They, like the system, responded the way they chose. If you want to be critical, be critical of your behavior. Look deeply at why you behaved as you did, and decide how you want to change it. Taking responsibility for their response gets in the way of taking responsibility for your behavior.

With complex systems, by definition it’s impossible to predict their output. (That’s why they’re called complex.) And the only way to understand them is to perturb them with your input and look for patterns in their responses. What that means is your inputs are well intended and ill informed. This is an especially challenging situation for those of us that have been conditioned (or born with the condition) to mis-take responsibility for system outputs. Taking responsibility for unpredictable system outputs is guaranteed frustration and loss of self-esteem. And it’s guaranteed to reduce the quality of your input over time.

When working with new systems in new ways, it’s especially important to take responsibility for your inputs at the expense of taking responsibility for unknowable system outputs. With innovation, we must spend a little and learn a lot. We must figure out how to perturb the system with our inputs and intelligently sift its outputs for patterns of understanding. The only way to do it is to fearlessly take responsibility for our inputs and fearless let the system take responsibility for its output.

We must courageously engineer and own our behavioral plan of attack, and modify it as we learn. And we must learn to let the system be responsible for its own behavior.

Drag Racing Behavior

Our productivity-by-the-minute culture is killing us.

In business speed is king, and with it comes our short-sighted drag racing behavior. As we pull to the starting light our big engines shake and rumble, our pipes shoot flames, and our tires smoke. We stomp the throttle, accelerate to mach 1, kill the engine, and throw the chute. A quarter mile covered in record time, and champagne celebration.

But, because the pace was beyond sustainable, we can’t race again until the damage is repaired. Because it ran too hot the pit crew must pull the engine, because the torque was so outrageous the transmission must be swapped, and because the vibrations were so severe the frame must be checked for metal fatigue. But this is just another opportunity for more racing.

We externalize the setup, design the process for quick changeover, reduce waste, and focus on the vital few. No matter the pit crew doesn’t get sleep, or their families miss them. Engine swapped in record time, and obligatory celebration.

Sure, going fast is good. But business can’t be a series of back-to-back sprints. Plain and simple – people cannot sprint every day, all day. Business should be thought of as a marathon. A marathon run at a respectable pace, but a pace we’ve trained for, a pace we can sustain. With a torn hamstring the fastest sprinter makes no forward progress, and even the slowest marathoner is faster.

Sprint, yes, but only when it makes sense. Sprint, yes, but provide recovery time. Sprint, yes, but not if it will do personal harm.

Increasing speed is directionally correct, but our time horizon is too short. Instead of optimizing over a six second quarter mile, we should optimize for a marathon.

In our chase for speed’s euphoric high, our drug of choice is efficiency. Like speed, efficiency is good. But, just as speed’s time horizon is too short, efficiency’s scale of optimization is too small. We optimize locally and the net result is global sub-optimization. This is clearly an artifact of what we measure. Clearly, we must measure differently.

Every day we chase the dopamine high of efficiency, but ignore the mind-blowing power of effectiveness. If you sprint day after day, you may be efficient, but you’re definitely ineffective. Sprint every day for a month, sleep four hours a night, and spend six weeks away from your family. Are you really in a good position to make a make-or-break decision? How can you possibly be effective? I wish Finance knew how to measure effectiveness as well as it does efficiency.

As a company leader, stop sprinting. As a company leader, stop optimizing locally. As a company leader, stop focusing on efficiency. As a company leader, demonstrate and reward effectiveness. As a company leader, go home and spend time with your family.

Innovation Eats Itself

We all want more innovation, though sometimes we’re not sure why. Turns out, the why important.

We want to be more innovative. That’s a good vision statement, but it’s not actionable. There are lots of ways to be innovative, and it’s vitally important to figure out the best flavor. Why do you want to be more innovative?

We want to be more innovative to grow sales. Okay, that’s a step closer, but not actionable. There are many ways to grow sales. For example, the best and fastest way to sell more units is to reduce the price by half. Is that what you want? Why do you want to grow sales?

We want to be more innovative to grow sales so we can grow profits. Closer than ever, but we’ve got to dig in and create a plan.

First, let’s begin with the end in mind. We’ve got to decide how we’ll judge success. How much do we want to grow profits? Double, you say? Good – that’s clear and measurable. I like it. When will we double profits? In four years, you say? Another good answer – clear and measureable. How much money can we spend to hit the goal? $5 million over four years. And does that incremental spending count against the profit target? Yes, year five must double this year’s profits plus $5 million.

Now that we know the what, let’s put together the how. Let’s start with geography. Will we focus on increasing profits in our existing first world markets? Will we build out our fledgling developing markets? Will we create new third world markets? Each market has different tastes, cultures, languages, infrastructure requirements, and ability to pay. And because of this, each requires markedly different innovations, skill sets, and working relationships. This decision must be made now if we’re to put together the right innovation team and organizational structure.

Now that we’ve decided on geography, will we do product innovation or business model innovation? If we do product innovation, do we want to extend existing product lines, supplement them with new product lines, or replace them altogether with new ones? Based on our geography decision, do we want to improve existing functionality, create new functionality, or reduce cost by 80% of while retaining 80% of existing functionality?

If we want to do business model innovation, that’s big medicine. It will require we throw away some of the stuff that has made us successful. And it will touch almost everyone. If we’re going to take that on, the CEO must take a heavy hand.

For simplicity, I described a straightforward, linear process where the whys are clearly defined and measurable and there’s sequential flow into a step-wise process to define the how. But it practice, there’s nothing simple or linear about the process. At best there’s overwhelming ambiguity around why, what, and when, and at worst, there’s visceral disagreement. And worse, with 0% clarity and an absent definition of success, there are several passionate factions with fully built-out plans that they know will work.

In truth, figuring out what innovation means and making it happen is a clustered-jumbled path where whats inform whys, whys transfigure hows, which, in turn, boomerang back to morph the whats. It’s circular, recursive, and difficult.

Innovation creates things that are novel, useful, and successful.  Novel means different, different means change, and change is scary. Useful is contextual – useful to whom and how will they use it? – and requires judgment. (Innovations don’t yet exist, so innovation efforts must move forward on predicted usefulness.) And successful is toughest of all because on top of predicted usefulness sit many other facets of newness that must come together in a predicted way, all of which can be verified only after the fact.

Innovation is a different animal altogether, almost like it eats itself. Just think – the most successful innovations come at the expense of what’s been successful.

Guided Divergence

We’ve been sufficiently polluted by lean and Six Sigma, and it’s time for them to go.

Masquerading as maximizers, these minimizers-in-sheep’s-clothing have done deep harm. Though Six Sigma is almost dead (it’s been irrelevant for some time now), it has made a lasting mark. Billed as a profit maximizer, it categorically rejects maximization. In truth, it’s a variation minimizer and difference reducer.  If it deviates, Six Sigma cuts its head off. Certainly this has a place in process control, but not in thinking control. But that’s exactly what’s happened. Six Sigma minimization has slithered off the manufacturing floor and created a culture of convergence. If your thinking is different, Six Sigma will clip it for you.

Lean is worse. All the buzz around lean is about maximizing throughput, but it doesn’t do that. It minimizes waste. But far worse is lean’s standard work. Minimize the difference among peoples’ work; make them do it the same; make the factory the same, regardless of the continent. All good on the factory floor, but lean’s minimization mania has spread like the plague and created a culture of convergence in its wake. And that’s the problem – lean’s minimization-standardization mantra has created a culture of convergence. If your thinking doesn’t fit in, lean will stomp it into place.

We need maximization at the expense of minimization, and divergence before convergence. We need creativity and innovation. But with Six Sigmaphiles and lean zealots running the show, maximization is little understood and divergence is a swear.

First we must educate on maximization. Maximization creates something that had not existed, while minimization reduces what is. Where Six Sigma minimization converges on the known right answer, creativity and innovation diverge to define a new question. The acid test: if you’re improving something you’re minimizing; if you’re inventing something you’re maximizing.

Like with He Who Shall Not Be Named, it’s not safe to say “diverge” out loud, because if you do, the lean Dementors will be called to suck out your soul. But, don’t despair – the talisman of guided divergence can save you.

With guided divergence, a team is given a creatively constructed set of constraints and very little time (hours) to come up with divergent ideas. The constraints guide the creativity (on target), and the tight timeline limits the risk – a small resource commitment. (Though counterintuitive, the tight timeline also creates remarkable innovation productivity.) Done in sets, several guided divergence sessions can cover a lot of ground in little time.

And the focused/constrained nature of guided divergence appeals to our minimization bias, and makes it okay to try a little divergence. We feel safe because we’re deviating only a little and only for a short time.

Lean and Six Sigma have served us well, and they still have their place. (Except for Six Sigma.) But they must be barred from creativity sessions and front end innovation, because here, divergence carries the day.

Engineering Incantations

Know what’s new in the new design. To do that, ask for a reuse analysis and divvy up newness into three buckets – new to your company, new to your industry, new to world. If the buckets are too big, jettison some newness, and if there’s something in the new-to-world bucket, be careful.

Create test protocols (how you’ll test) and minimum acceptance criteria (specification limits) before doing design work. It’s a great way to create clarity.

Build first – build the crudest possible prototype to expose the unfamiliar, and use the learning to shape the next prototypes and to focus analyses. Do this until you run out of time.

Cost and function are joined at the hip, so measure engineering on both.

Have a healthy dissatisfaction for success. Recognize success, yes, but also recognize it’s fleeting. Someone will obsolete your success, and it should be you.

To get an engineering team to believe in themselves, you must believe in them. To believe in them, you must believe in yourself.

Lasting Behavioral Change

Whether it’s innovation, creativity, continuous improvement, or discontinuous improvement, it’s all about cultural change, and cultural change is about change in behavior.

With the police state approach, detailed processes are created and enforced; rules are created and monitored; and training is dealt out and attendance taken. Yes, behavior is changed, but it’s fleeting. Take your eye off the process, old behavior slips through the fence; look the other way from the rules, old behavior clips the barbed wire and climbs over the wall. To squelch old behavior with the police state approach, gulag energy must be consistently applied.

To squelch is one thing, but to create lasting behavior change is another altogether. But as different as they are, there’s a blurry line of justice that flips innocent to guilty. And to walk the line you’ve got to know where it is:

  • Apply force, yes, but only enough to prevent backsliding – like a human ratchet. Push much harder and heels dig in.
  • The only thing slower than going slow is going too fast. (Remember, you’re asking people to change the why of their behavior.) Go slow to go fast.
  • Set direction and stay the course, unless there’s good reason to change. And when the team comes to you with a reason, deem it a good one, and the cornerstone of trust is laid. (This is a game of trust, not control.)

But there are some mantras to maximize:

  • Over emphasize the positive and overlook the negative.
  • Praise in public.
  • Don’t talk, do.

The first two stand on their own, but the third deserves reinforcement.

This isn’t about your words, it’s about your behavior. And that’s good because you have full authority over your behavior. Demonstrate the new behavior so everyone knows what it looks like. Lead the way with your actions. Show them how it’s done. For lasting change, change your behavior.

Even if changing your behavior influences only one person, you’re on your way. The best prison riots start with a single punch.

 

Prototype the Unfamiliar

Today’s answer to everything is process and tools. Define the desired outcome; create the process; create the tools.  Problem solved.

 

But if the desired outcome is lasting change, deterministic processes and static tools won’t get us there.  Lasting change comes from people and their behavior.

 

Going forward, instead of creating process, create an environment of trust so people will investigate the unfamiliar; and instead of creating tools, create time – time for people to prototype the unfamiliar.

Climbing The Branches Of The Problem Tree

The problem tree is big, old, and rugged with a fully developed branch network and the deepest roots. And nestled in its crown, set directly over the trunk, is the hidden tree house where the problem solvers play.

The problem tree has a left and right, with its why branches to the right and why-nots to the left. To the right, the biggest why limbs grow from the trunk then split into a series of smaller why branches which terminate at the why leaves. It’s the same on the left – big why-not limbs, why-not branches, why-not leaves.

To start their game, the problem solvers first agree on the biggest why limbs – the main reasons why to solve the problem. Once labeled, the team asks why again, and builds out the why side of the canopy – narrowing as they go. They continue their hierarchical why mapping until they get to the why leaves – the lowest-level whys. The last part is most tenuous because as the branches get smaller they can’t hold the weight and they sway in the political wind. But as the organization watches impatiently, the problem solvers know they must hang onto the smallest branches and stretch themselves hard to reach the leaves.

Once the whys are mapped the solvers know why they must solve the problem. They know who wants it solved (the biggest branches can have their own sponsor) and how the whys (and their sponsors) compliment or compete. And where the rubber meets the road (leaf level), they know why it must be solved – think manufacturing floor. Like a spider web, the why network sticks the solvers to the right problem.

Novice solvers think their ready to solve, but the seasoned climbers know it’s time swing on the wild side. It’s time to climb where few dare – the politically charged left side – the why-nots. Slowly, carefully, the climbers step from the safety of their tree house and explore why the company cannot, has not, or may not want to solve the problem. There are usually three big why-not branches – constraints, capability, and culture.

When the solvers shimmy out on the constraint branch, they usually find the smaller no-time-to-solve-it branch, with its leaves of – existing operating plans, product launches, other big problems, unfilled open positions, and reduced headcount. Though real, these branches are tough to talk about because the organization does not want to hear about them. And, sometimes, for all their dangerous climbing and shimmying, the solvers are accused of not being team players.

Their climb on the capability branch is challenging, but not for its complexity. There’s usually one branch – we don’t know how to do it, with a couple leaves – we’ve never done it before and we don’t do it that way. The capability branch is difficult because it causes the organization to overtly admit a fundamental gap. Also, it threatens the subject matter experts, who are important to the solution.

The culture branch is toughest of all. Its limbs can be slippery and sometimes have cover names (so it’s difficult for me to list them), but thematically, the best climbers know the branches represent the worn patterns of company behavior. Often, the behaviors (and the climate they create) have not been formalized, and shining a light on them may is too bright for some. But when the solvers find a why-not branch that cuts across one of these worn cowpaths, that’s just what they must do. Because without changing the behavioral pattern, there can be no solution.

With the problem tree fully built-out on a single page, it’s clear why the problem should be solved and what’s in the way (why-not). And when the solvers present it, the company decides if the whys are important enough to overcome the why-nots. If it’s a go, the first step is to prune the why-nots – resources to solve the constraint problems, tools and training to improve the capability problems, and a change in leadership behavior to solve the cultural problems. After those are taken care of, the problem definition phase comes to a close.

The problem tree defines the problem, it does not solve it. But through the process of building it out, the problem solvers (problem definers) help the company clear cut the forest of why-nots. Now, standing tall, standing alone, clearly seen for what it is, solving the problem is a breeze.

Curiosity Fuels Creativity

Creativity generates things that are novel and useful. Make them successful, and you’ve got innovation. There can be no innovation without creativity.

We associate creativity with innate ability that only some have; with transparent happenings that can’t be codified; with eureka moments that come from the subconscious. If anything defies process, it’s creativity. So let’s not use process to squelch creativity, let’s foster behaviors that spawn creativity.

Curiosity is the kindling for creativity; fan its flames and creativity ignites. There a two parts to curiosity – to see things as they are and to propose what could be.

To see things as they are is to create awareness of what is – awareness of context, or changes in context, awareness of worn paths and anomalies, and awareness at high and low levels of abstraction. It takes a disciplined, uncluttered mind to become aware of a new reality, especially while sitting in the old one. And because uncluttering comes only from slack time, to see things as they are is doubly difficult.

The next part of curiosity is to challenge what is in order to propose what could be. To start, root cause must be understood for the new what is. This requires active rejection of old fundamentals and a deep dive to understand new ones. This is toughest when the old fundamentals have been (and are still) successful. (And it’s doubly tough because it requires slack time.) Curiosity twists, pounds, and bends the new fundamentals into a future reality which culminates with a proposal of what could be. Done right, curiosity’s proposal is borderline heretical.

The good news is we don’t need new people – we have plenty of creative capacity. But here’s the bad news – our process thinking isn’t going to get us there because it’s all about behaviors. It’s time to think about how to change things so we can spend more time on behaviors that generate creativity. But if you must use process thinking, come up with a process that lets us spend more time on creative behaviors

The thinking (and some of the language) for this post came from Diego Uribe, a true thought leader in creativity. Thank you Diego.

Small Is Good, And Powerful

If lean has taught us anything, it’s smaller is better. Smaller machines, smaller factories, smaller teams, smaller everything.

The famous Speaker of the House, Tip O’Neill, said all politics are local. He meant all action happens at the lowest levels (in the districts and neighborhoods), where everyone knows everyone, where the issues are well understood, and the fundamentals are not just talked about, they’re lived. It’s the same with manufacturing. But I’m not talking about local in the geography sense; I’m talking about the neighborhood sense. When manufacturing is neighborhood-local, it’s small, tight, focused and knowledgeable.

We mistakenly think about manufacturing strictly as the process of making things—it’s far more. In the broadest sense, manufacturing is everything: innovation, design, making and service. It’s this broad-sense manufacturing that will deliver the next economic revolution.

Previously, I described how big companies break themselves into smaller operating units. They recognize lean favors small, and they break themselves up for competitive advantage. They want to become a collective of small companies with the upside of small without of the downside of big. Yet with small companies, there’s an urge to be big.

Lean says smaller is better and more profitable. Lean says small companies have an advantage because they’re already small. Lean says small companies should stay small (neighborhood small) and be more of what they are.

Small companies have a size advantage. Their smaller scope improves focus and alignment. It’s easier to define the mission, communicate it, and work toward it. It’s easier to mobilize the neighborhood. It’s clearer when things go off track and easier to get things back on track. At the lowest level, smaller companies zero in on problems and fix them. At the highest, they align themselves with their mission. These are important advantages, but not the most important.

The real advantage is deep process knowledge. Smaller companies have less breadth and more depth, which allows them to focus energy on the work and develop deep process knowledge. Many large manufacturers have lost process knowledge over the years. Small companies tend to develop and retain more of it. We’ve forgotten the value of deep process knowledge, but as companies look for competitive advantage, its stock is rising.

Lean wants small companies to build on that strength. To take it to the next level, lean wants companies to think about manufacturing in the more-than-making sense and use that deep process knowledge to influence the product itself. Lean wants suppliers to inject their process knowledge into their customers’ product development process to radically reduce material cost and help the product sprint through the factory.

The ultimate advantage of deep process knowledge is realized when small companies use it to design products. It’s realized when people who know the process fundamentals work respectfully with their neighbors who design the product. The result is deeper process knowledge and a far more profitable product. Big companies like to work with smaller companies who can design and make.

Tip O’Neill and lean agree. All manufacturing is local. And this local nature drives a focus on the fundamentals and details. Being neighborhood-local is easier for small companies because their scope is smaller, which helps them develop and retain deep process knowledge.

Lean wants companies to be small—neighborhood-small. When small companies build on a foundation of deep process knowledge, sales grow. Lean wants sales growth, but it also wants companies to reduce their size in the neighborhood sense.

Mike Shipulski Mike Shipulski

Stay Updated — Receive Our Latest Articles by Email

Archives