Shipulski On Design

Posts Tagged ‘Trust-based approach’

When there’s a big problem, the first step is to define what’s causing it. To do that, based on an understanding of the physics, a sequence of events is proposed and then tested to see if it replicates the problem. In that way, the team must understand the system as it is before the problem can be solved.

Seeing things as they are. The same logic applies when it’s time to improve an existing product or service. The first thing to do is to see the system as it is. But seeing things as they are is difficult. We have a tendency to see things as we want them or to see them in ways that make us look good (or smart). Or, we see them in a way that justifies the improvements we already know we want to make.

To battle our biases and see things as they are, we use tools such as block diagrams to define the system as it is. The most important element of the block diagram is clarity.  The first revision will be incorrect, but it must be clear and explicit. It must describe things in a way that creates a singular understanding of the system. The best block diagrams can be interpreted only one way.  More strongly, if there’s ambiguity or lack of clarity, the thing has not yet risen to the level of a block diagram.

The block diagram evolves as the team converges on a single understanding of things as they are. And with a diagram of things as they are, a solution is readily defined and validated. If when tested the proposed solution makes the problem go away, it’s inferred that the team sees things as they are and the solution takes advantage of that understanding to make the problem go away.

Seeing things as they may be. Even whey the solution fixes the problem, the team really doesn’t know if they see things as they are. Really, all they know is they see things as they may be. Sure, the solution makes the problem go away, but it’s impossible to really know if the solution captures the physics of failure.  When the system is large and has a lot of moving parts, the team cannot see things as they are, rather, they can only see the system as it may be. This is especially true if the system involves people, as people behave differently based on how they feel and what happened to them yesterday.

There’s inherent uncertainty when working with larger systems and systems that involve people.  It’s not insurmountable, but you’ve got to acknowledge that your understanding of the system is less than perfect. If your company is used to solving small problems within small systems, there will be little tolerance for the inherent uncertainty and associated unpredictability (in time) of a solution.  To help your company make the transition, replace the language of “seeing things as they are” with “seeing things as they may be.”  The same diagnostic process applies, but since the understanding of the system is incomplete or wrong, the proposed solutions cannot not be pre-judged as “this will work” and “that won’t work.”  You’ve got to be open to all potential solutions that don’t contradict the system as it may be. And you’ve got to be tolerant of the inherent unpredictability of the effort as a whole.

Seeing things as they could be. To create something that doesn’t yet exist, something does things like never before, something altogether new, you’ve got to stand on top of your understanding of the system and jump off.  Whether you see things as they are or as they may be, the new system will be different. It’s not about diagnosing the existing system; it’s about imagining the system as it could be. And there’s a paradox here. The better you understand the existing system, the more difficulty you’ll have imagining the new one. And, the more success the company has had with the system as it is, the more resistance you’ll feel when you try to make the system something it could be.

Seeing things as they could be takes courage – courage to obsolete your best work and courage to divest from success. The first one must be overcome first. Your body creates stress around the notion of making yourself look bad. If you can create something altogether better, why didn’t you do it last time? There’s a hit to the ego around making your best work look like it’s not all that good. But once you get over all that, you’ve earned the right to go to battle with your organization who is afraid to move away from the recipe responsible for all the profits generated over the last decade.

But don’t look at those fears as bad. Rather, look at them as indicators you’re working on something that could make a real difference.  Your ego recognizes you’re working on something better and it sends fear into your veins. The organization recognizes you’re working on something that threatens the status quo and it does what it can to make you stop. You’re onto something. Keep going.

Seeing things as they can’t be. This is rarified air. In this domain you must violate first principles. In this domain you’ve got to run experiments that everyone thinks are unreasonable, if not ill-informed. You must do the opposite. If your product is fast, your prototype must be the slowest. If the existing one is the heaviest, you must make the lightest. If your reputation is based on the highest functioning products, the new offering must do far less.  If your offering requires trained operators, the new one must prevent operator involvement.

If your most seasoned Principal Engineer thinks it’s a good idea, you’re doing it wrong. You’ve got to propose an idea that makes the most experienced people throw something at you. You’ve got to suggest something so crazy they start foaming at the mouth. Your concepts must rip out their fillings. Where “seeing things as they could be” creates some organizational stress, “seeing things as they can’t be” creates earthquakes. If you’re not prepared to be fired, this is not the domain for you.

All four of these domains are valuable and have merit. And we need them all. If there’s one message it’s be clear which domain you’re working in. And if there’s a second message it’s explain to company leadership which domain you’re working in and set expectations on the level of uncertainty and unpredictability of that domain.

Image credit – David Blackwell.

Where’s the Marketing Brief? In product development, the Marketing team creates a document that defines who will buy the new product (the customer), what needs are satisfied by the new product and how the customer will use the new product.  And Marketing team also uses their crystal ball to estimate the number of units the customers will buy, when they’ll buy it and how much they’ll pay.  In theory, the Marketing Brief is finalized before the engineers start their work.

With innovation, there can be no Marketing Brief because there are no customers, no product and no technology to underpin it.  And the needs the innovation will satisfy are unknowable because customers have not asked for the them, nor can the customer understand the innovation if you showed it to them.  And how the customers will use the? That’s unknowable because, again, there are no customers and no customer needs. And how many will you sell and the sales price? Again, unknowable.

Where’s the Specification? In product development, the Marketing Brief is translated into a Specification that defines what the product must do and how much it will cost.  To define what the product must do, the Specification defines a set of test protocols and their measurable results.  And the minimum performance is defined as a percentage improvement over the test results of the existing product.

With innovation, there can be no Specification because there are no customers, no product, no technology and no business model. In that way, there can be no known test protocols and the minimum performance criteria are unknowable.

Where’s the Schedule? In product development, the tasks are defined, their sequence is defined and their completion dates are defined. Because the work has been done before, the schedule is a lot like the last one.  Everyone knows the drill because they’ve done it before.

With innovation, there can be no schedule.  The first task can be defined, but the second cannot because the second depends on the outcome of the first. If the first experiment is successful, the second step builds on the first. But if the first experiment is unsuccessful, the second must start from scratch. And if the customer likes the first prototype, the next step is clear. But if they don’t, it’s back to the drawing board.  And the experiments feed the customer learning and the customer learning shapes the experiments.

Innovation is different than product development. And success in product development may work against you in innovation. If you’re doing innovation and you find yourself trying to lock things down, you may be misapplying your product development expertise. If you’re doing innovation and you find yourself trying to write a specification, you may be misapplying your product development expertise. And if you are doing innovation and find yourself trying to nail down a completion date, you are definitely misapplying your product development expertise.

With innovation, people say the work is uncertain, but to me that’s not the right word.  To me, the work is unknowable. The customer is unknowable because the work hasn’t been done before.  The specification is unknowable because there is nothing for comparison. And the schedule in unknowable because, again, the work hasn’t been done before.

To set expectations appropriately, say the innovation work is unknowable. You’ll likely get into a heated discuss with those who want demand a Marketing Brief, Specification and Schedule, but you’ll make the point that with innovation, the rules of product development don’t apply.

Image credit — Fatih Tuluk

I stand by my statement that trust is the most important element in business (see The Trust Network.)

The Trust Network are the group of people who get the work done. They don’t do the work to get promoted, they just do the work because they like doing the work. They don’t take others’ credit (they’re not striving,) they just do the work. And they help each other do the work because, well, it’s the right thing to do.

Sometimes, they use their judgement to protect the company from bad ideas. But to be clear, they don’t protect the Status Quo. They use their good judgement to decide if a new idea has merit, and if it doesn’t, they try to shape it. And if they can’t shape it, they block it.  Their judgement is good because their mutual trust allows them to talk openly and honestly and listen to each other. And through the process, they come to a decision and act on it.

But there’s another side to the Trust Network.  They also bring new ideas to the company.

Trying new things is scary, but the Trust Network makes it safe. When someone has a good idea, the Network positively reinforces the goodness of the idea and recommends a small experiment. And when one installment of positivity doesn’t carry the day, the Trust Network comes together to create the additional positivity need to grow the idea into an experiment.

To make it safe, the Trust Network knows to keep the experiment small.  If the small experiment doesn’t go as planned, they know there will be no negative consequences. And if the experiment’s results do attract attention, they dismiss the negativity of failure and talk about the positivity of learning. And if there is no money to run the experiment, they scare it up. They don’t stop until the experiment is completed.

But the real power of the Trust Network shows its hand after the successful experiment. The toughest part of innovation is the “now what” part, where successful experiments go to die. Since no one thought through what must happen to convert the successful experiment to a successful product, the follow-on actions are undefined and unbudgeted and the validated idea dies. But the Trust Network knows all this, so they help the experimenter define the “then what” activities before the experiment is run.  That way, the resources are ready and waiting when the experiment is a success.  The follow-on activities happen as planned.

The Trust Network always reminds each other that doing new things is difficult and that it’s okay that the outcome of the experiment is unknown. In fact, they go further and tell each other that the outcome of the experiment is unknowable. Regardless of the outcome of the experiment, the Trust Network is there for each other.

To start a Trust Network, find someone you trust and trust them. Support their new ideas, support their experiments and support the follow-on actions.  If they’re afraid, tell them to be afraid and run the experiment. If they don’t have the resources to run the experiment, find the resources for them. And if they’re afraid they won’t get credit for all the success, tell them to trust you.

And to grow your Trust Network, find someone else you trust and trust them. And, repeat.

Image credit — Rolf Dietrich Brecher

When you’re asked to do more work that you and your team can handle, don’t pass it onto your team.  Instead, take the heat from above but limit the team’s work to a reasonable level.

When the number of projects is larger than the budget needed to get them done, limit the projects based on the budget.

When the team knows you’re wrong, tell them they’re right. And apologize.

When everyone knows there’s a big problem and you’re the only one that can fix it, fix the big problem.

When the team’s opinion is different than yours, respect the team’s opinion.

When you make a mistake, own it.

When you’re told to do turn-the-crank work and only turn-the-crank work, sneak in a little sizzle to keep your team excited and engaged.

When it’s suggested that your team must do another project while they are fully engaged in an active project, create a big problem with the active project to delay the other project.

When the project is going poorly, be forthcoming with the team.

When you fail to do what you say, apologize.  Then, do what you said you’d do.

When you make a mistake in judgement which creates a big problem, explain your mistake to the team and ask them for help.

If you’ve got to clean up a mess, tell your team you need their help to clean up the mess.

When there’s a difficult message to deliver, deliver it face-to-face and in private.

When your team challenges your thinking, thank them.

When your team tells you the project will take longer than you want, believe them.

When the team asks for guidance, give them what you can and when you don’t know, tell them.

As leaders, we don’t always get things right.  And that’s okay because mistakes are a normal part of our work.  And projects don’t always go as planned, but that’s okay because that’s what projects do. And we don’t always have the answers, but that’s okay because we’re not supposed to. But we are responsible for our response to these situations.

When mistakes happen, good leaders own them. When there’s too much work and too little time, good leaders tell it like it is and put together a realistic plan. And when the answers aren’t known, a good leader admits they don’t know and leads the effort to figure it out.

None of us get it right 100% of the time. But what we must get right is our response to difficult situations.  As leaders, our responses should be based on honesty, integrity, respect for the reality of the situation and respect for people doing the work.

Image credit – Ludovic Tristan

You could be a subtle leader if…

You create the causes and conditions for others to shine. And when they shine, you give them the credit they’re due.

You don’t have the title, but when the high-profile project hits a rough patch, you get called in to create the go-forward plan.

One of your best direct reports gets promoted out from under you, but she still wants to meet with you weekly.

When you see someone take initiative, you tell them you like their behavior.

You get to choose the things you work on.

You can ask most anyone for a favor and they’ll do it, just because it’s you. But, because you don’t like to put people out, you rarely ask.

When someone does a good job, you send their boss a nice email and cc: them.

When it’s time to make a big decision, even though it’s outside your formal jurisdiction, you have a seat at the table.

When people don’t want to hear the truth, they don’t invite you to the meeting.

You are given the time to think things through, even when it takes you a long time.

Your young boss trusts you enough to ask for advice, even when she knows she should know.

In a group discussion, you wait for everyone else to have input before weighing in. And, if there’s no need to weigh in, you don’t.

When you see someone make a mistake, you ignore it if you can. And if you can’t, you talk to them in private.

Subtle leaders show themselves in subtle ways but their ways are powerful. Often, you see only the results of their behaviors and those career-boosting results are mapped to someone else. But if you’ve been the recipient of subtle leadership, you know what I’m talking about. You didn’t know you needed help, but you were helped just the same. And you were helped in a way that was invisible to others. And though you didn’t know to ask for advice, you were given the right suggestion at the right time. And you didn’t realize it was the perfect piece of advice until three weeks later.

Subtle leaders are difficult to spot. But once you know how they go about their business and how the company treats them, you can see them for what they are. And once you recognize a subtle leader, figure out a way to spend time with them.  Your career will be better for it.

Image credit – rawdonfox

I’m all for stretch goals to help people grow.  “Hey, you did this last year but I think you can do ten percent more this year. And here’s why – [list three reasons here.]” This works. This helps people grow. This is effective. This is grounded in what happened last year. This is grounded in specific reasons why you think the stretch goal is possible. And when you do it this way, you are seen as credible.

Back in the day, when elite runners were running the mile in 4:04 their coaches said “Hey, you ran 4:04 last year but I think you can do it a little faster this year. I think you can run it in 3:59. And here’s why – your time has been decreasing steadily over the last three years, you have been working out with weights and you’re much stronger and there’s a small adjustment we can make to your stride that will help you be more efficient.

As an athlete, I believe this coach. It’s true, I did run 4:04 last year. It’s true, my time has decreased steadily over the last years. It’s true, I have been working hard in the weight room. And, because all these things are true, I believe the coach when she tells me she knows a way to help me run faster. This coach is credible and I will work hard for her.

Back in the day, when elite runners were running the mile in 4:04, their coaches did NOT say “Hey, as a stretch goal, I want you to run 2:59 next year. I know it’s a big improvement, but I want to set an arbitrary and unrealistic goal so I can get the most out of you.  And no, I don’t have any advice on how you can run 27% faster than last year. As the one doing the running, that’s your job. I’m just the coach.”

As an athlete, I don’t believe this coach. There’s no way in hell I will run 27% faster this year. It’s simply not physically possible.  The world record is 4:01 and I can’t break it by over a minute. The coach has no clue about how I can achieve the goal, nor did he build a bridge from last year’s pace to this silly target. This coach is not credible and I will not work hard for him.

As a leader you are credible when you set an improvement goal that’s grounded in the reality of how things have gone in the past. And you’re more credible when you give specific reasons why you think the improvement goal is possible. And you’re more credible when you give suggestions on how to achieve the goal. And you’re even more credible when you tell people you will actively support them in the improvement effort. When you do it this way, people think better of you and they’ll work hard for you.

Here’s a rule: if the goal isn’t believable it’s not achievable.

As a leader, when you set an improvement goal that’s out of line with reality you are NOT credible. When you declare an improvement goal that’s disrespectful of history, it’s not a stretch goal. It’s an arbitrary edict designed to trick people into working too hard. And everyone can spot these “goals” at twenty paces. Your best people will give you the courtesy of calling you on your disingenuous behavior, but most people will just smile and quietly think less of you.  And none of them will work hard for you.

When the improvement goal isn’t credible, neither are you.  Think twice before you ask your people to drink the company Kool-Aid.

Image credit – Andy

Innovation is a hot topic. Everyone wants to do it. And everyone wants a simple process that works step-wise – first this, then that, then success.

But Innovation isn’t like that. I think it’s more effective to think of innovation as a result. Innovation as something that emerges from a group of people who are trying to make a difference. In that way, Innovation is a people process. And like with all processes that depend on people, the Innovation process is fluid, dynamic, complex, and context-specific.

Innovation isn’t sequential, it’s not linear and cannot be scripted.. There is no best way to do it, no best tool, no best training, and no best outcome. There is no way to predict where the process will take you.  The only predictable thing is you’re better off doing it than not.

The key to Innovation is good judgment. And the key to good judgment is bad judgment. You’ve got to get things wrong before you know how to get them right. In the end, innovation comes down to maximizing the learning rate. And the teams with the highest learning rates are the teams that try the most things and use good judgement to decide what to try.

I used to take offense to the idea that trying the most things is the most effective way. But now, I believe  it is. That is not to say it’s best to try everything. It’s best to try the most things that are coherent with the situation as it is, the market conditions as they are, the competitive landscape as we know it, and the the facts as we know them.

And there are ways to try things that are more effective than others. Think small, focused experiments driven by a formal learning objective and supported by repeatable measurement systems and formalized decision criteria. The best teams define end implement the tightest, smallest experiment to learn what needs to be learned. With no excess resources and no wasted time, the team wins runs a tight experiment, measures the feedback, and takes immediate action based on the experimental results.

In short, the team that runs the most effective experiments learns the most, and the team that learns the most wins.

It all comes down to choosing what to learn. Or, another way to look at it is choosing the right problems to solve. If you solve new problems, you’ll learn new things. And if you have the sightedness to choose the right problems, you learn the right new things.

Sightedness is a difficult thing to define and a more difficult thing to hone and improve. If you were charged with creating a new business in a new commercial space and the survival of the company depended on the success of the project, who  would you want to choose the things to try? That person has sightedness.

Innovation is about people, learning, judgement and trust.

And innovation is more about why than how and more about who than what.

Image credit – Martin Nikolaj Christensen

If you’re dissatisfied, there’s a reason.

If you’re dissatisfied, there’s hope for us all.

If you’re not dissatisfied, there’s no forcing function for change.

If you’re not dissatisfied, the status quo will carry the day.

If you’re not dissatisfied, innovation work is not for you.

If you’re dissatisfied, you know it could be better next time.

If you’re dissatisfied, your insecure leader will step on your head.

If you’re dissatisfied, there’s a reason and that reason is real.

If you’re dissatisfied, follow your dissatisfaction.

If you’re dissatisfied, I want to work with you.

If you’re dissatisfied, it’s because you see things as they are.

If you’re dissatisfied, your confident leader will ask how things should go next time.

If you’re dissatisfied, it’s because you want to make a difference.

If you’re dissatisfied, look inside.

If you’re dissatisfied, there’s a reason, the reason is real and it’s time to do something about it.

If you’re dissatisfied, you’re thinking for yourself.

If you’re so dissatisfied you openly show anger, thank you for trusting me enough to show your true self.

If you’re dissatisfied, it’s because you know things should be better than they are.

If you’re dissatisfied, do something about it.

If you’re dissatisfied, thank you for thinking deeply.

If you’re dissatisfied, it’s because you’re not asleep at the wheel.

If you’re dissatisfied, it’s because your self-worth allows it.

Thank you for caring enough to be dissatisfied.

Image credit – Vinod Chandar

The primary impediment to innovation is fear, and the prime directive of any innovation system should be to drive out fear.

A culture of accountability, implemented poorly, can inject fear and deter innovation.  When the team is accountable to deliver on a project but are constrained to a fixed scope, a fixed launch date and resources, they will be afraid.  Because they know that innovation requires new work and new work is inherently unpredictable, they rightly recognize the triple accountability – time, scope and resources – cannot be met.  From the very first day of the project, they know they cannot be successful and are afraid of the consequences.

A culture of accountability can be adapted to innovation to reduce fear.  Here’s one way. Keep the team small and keep them dedicated to a single innovation project. No resource sharing, no swapping and no double counting. Create tight time blocks with clear work objectives, where the team reports back on a fixed pitch (weekly, monthly). But make it clear that they can flex on scope and level of completeness.  They should try to do all the work within the time constraints but they must know that it’s expected the scope will narrow or shift and the level of completeness will be governed by the time constraint.  Tell them you believe in them and you trust them to do their best, then praise their good judgement at the review meeting at the end of the time block.

Innovation is about solving new problems, yet fear blocks teams from trying new things. Teams like to solve problems that are familiar because they have seen previous teams judged negatively for missing deadlines. Here’s the logic – we’d rather add too little novelty than be late.  The team would love to solve new problems but their afraid, based on past projects, that they’ll be chastised for missing a completion date that’s disrespectful of the work content and level of novelty.  If you want the team to solve new problems, give them the tools, time, training and a teacher so they can select different problems and solve them differently. Simply put – create the causes and conditions for fear to quietly slink away so innovation will flow.

Fear is the most powerful inhibitor. But before we can lessen the team’s fear we’ve got to recognize the causes and conditions that create it. Fear’s job is to keep us safe, to keep us away from situations that have been risky or dangerous.  To do this, our bodies create deep memories of those dangerous or scary situations and creates fear when it recognizes similarities between the current situation and past dangerous situations.  In that way, less fear is created if the current situation feels differently from situations of the past where people were judged negatively.

To understand the causes and conditions that create fear, look back at previous projects.  Make a list of the projects where project members were judged negatively for things outside their control such as: arbitrary launch dates not bound by the work content, high risk levels driven by unjustifiable specifications, insufficient resources, inadequate tools, poor training and no teacher.  And make a list of projects where team members were praised.  For the projects that praised, write down attributes of those projects (e.g., high reuse, low technical risk) and their outcomes (e.g., on time, on cost).  To reduce fear, the project team will bend new projects toward those attributes and outcomes. Do the same for projects that judged negatively for things outside the project teams’ control. To reduce fear, the future project teams will bend away from those attributes and outcomes.

Now the difficult parts.  As a leader, it’s time to look inside.  Make a list of your behaviors that set (or contributed to) causes and conditions that made it easy for the project team to be judged negatively for the wrong reasons.  And then make a list of your new behaviors that will create future causes and conditions where people aren’t afraid to solve new problems in new ways.

Image credit — andrea floris

Your company believes everything should always go as planned.

You still have to do your regular job.

The project’s completion date is disrespectful of the work content.

Your company doesn’t recognize the difference between complex and complicated.

The team is not given the tools, training, time and a teacher.

You’re asked to generate 500 ideas but you’re afraid no one will do anything with them.

You’re afraid to make a mistake.

You’re afraid you’ll be judged negatively.

You’re afraid to share unpleasant facts.

You’re afraid the status quo will be allowed to squash the new ideas, again.

You’re afraid the company’s proven recipe for success will stifle new thinking.

You’re afraid the project team will be staffed with a patchwork of part time resources.

You’re afraid you’ll have to compete for funding against the existing business units.

You’re afraid to build a functional prototype because the value proposition is poorly defined.

Project decisions are consensus-based.

Your company has been super profitable for a long time.

The project team does not believe in the project.

Image credit Vera & Gene-Christophe

The toughest part of all things is the people part.

Hold on to being right and all you’ll be is right.  Transcend rightness and get ready for greatness.

Embrace hubris and there’s no room for truth.  Embrace humbleness and everyone can get real.

Judge yourself and others will pile on.  Praise others and they will align with you.

Expect your ideas to carry the day and they won’t. Put your ideas out there lightly and ask for feedback and your ideas will grow legs.

Fight to be right and all you’ll get is a bent nose and bloody knuckles.  Empathize and the world is a different place.

Expect your plan to control things and the universe will have its way with you.  See your plan as a loosely coupled set of assumptions and the universe will still have its way with you.

Argue and you’ll backslide.  Appreciate and you’ll ratchet forward.

See the two bad bricks in the wall and life is hard.  See the other nine hundred and ninety-eight and everything gets lighter.

Hold onto success and all you get is rope burns.  Let go of what worked and the next big thing will find you.

Strive and get tired. Thrive and energize others.

The people part may be the toughest part, but it’s the part that really matters.

Image credit — Arian Zwegers