Shipulski On Design

Posts Tagged ‘Learning’

Slow down to go fast.

Progress over activity.

Effectiveness before efficiency.

Finish at the expense of starting.

Location is more important than destination.

See the system as it could be, not how it should be.

Brown field designs are real; green field designs are not.

What could go right is more important than what could go wrong.

Uncertainty is flexible, certainty is dangerous.

Learning before scaling.

People first.

Image credit — mhobl

Take a position.  People will have to reconcile their thinking with yours and, together, the crew will deepen the collective understanding.

Take an opposite position.  Announce you are running a thought experiment and take a position that is opposite of the prevailing theory.  Make it good.  Make it deep.  Do it for real.  The prevailing theory will be strengthened, adapted, or discarded, and everything will be better for it.

Take an opposite position to your own prevailing wisdom.  If there’s no one to play with, repeat the previous exercise with yourself.  Give yourself the business.  I bet you’ll teach yourself something and you’ll have better clarity on what you know and what you don’t.

Challenge someone’s best thinking.  Announce you want to help them sharpen their thinking.  Ask them why they think as they do.  When they answer, ask them “why?” again.  Repeat this process until you’ve asked “why?” five times.  This process is aptly named The Five Whys.  If they don’t feel uncomfortable, you’re doing it wrong.

Draw a picture. Announce that you want to help solve the problem. Ask “What’s the problem?”  Then, draw a picture of the problem and show it to the crew.  It won’t be right, but that’s okay.  Ask them to fix the drawing so it captures the problem.  Repeat the process until the picture looks like the problem.  From there, the solving will come easily.  Here’s an old blog post from 2013 with a simple “problem defining” template — How Engineers Create New Markets  and another from 2017 that describes how to sketch a problem — See Differently To Solve Differently.

Make a Map. Check out these two blog posts — To Make Progress, Make a Map (2023) and The Half-Life of Our Maps (2014).

I think it’s better to be clear than correct.  Clarity brings contrast; contrast creates conversation; and conversation begets understanding.

Clarity is king.

Image credit – Natashi Jay

The marathon is a two-to-three-hour race.  The training plan is specialized and designed to get the athletes ready to run twenty-six miles.  And the marathon runners are lean and light because the physics of their event demands it.

The 100-meter sprint is a sub-ten-second race.  The training plan develops explosive power to accelerate quickly and strength to hold on for the last twenty meters.  Sprinters are muscled all over – shoulders, chest, glutes, quads, and calves – because that’s what’s required to win their event.

The decathlon is a multi-day event.  The training plan includes jumping, vaulting, throwing, sprinting, and distance running. Decathletes are strong, nimble, fast, robust, and multi-skilled because they compete in a wide range of events.  They do it all, and they do it on their own.  They are often called the best track athletes because they are highly capable in ten diverse events.  But they cannot outlast a marathon runner or out-accelerate a sprinter.

The 4 X 400-meter relay is a three-plus-minute race in which each of the four teammates runs 400 meters carrying a baton and passes it to their teammate.  They train as a team for their specific distance and build the right amount of strength.  They are muscled all over, but a little less so than the sprinters.  And they must work together with their teammates to time and coordinate a high-speed baton pass within the pass zone.  If they drop the baton, they all lose, so teamwork is a must.

Some questions for you.

What are you built for?

Does your sport fit you?

Do you have a good training plan?

How much time will you spend on your training?

Do you want to work on one thing or ten?

Do you want to run solo or with a relay team?

Image credit – Steve Austin

When you know the answer, do you ask the question to test others?

When you know the answer, do you ask the question to help others think differently?

When you know the answer, do you keep quiet because it’s not the right time for a question?

When you know the answer, do you ask the question even though it’s not the right time for a question?

What does that say about you?

When you think you know the answer, do you ask the question to seek the right answer?

When you think you know the answer, do you ask the question and risk looking like you don’t know?

When you think you know the answer, do you keep quiet for reasons you don’t understand?

What does that say about you?

When you don’t know the answer, do you ask in public to solicit diverse perspectives?

When you don’t know the answer, do you ask someone you trust in private?

When you don’t know the answer, do you throw away the question?

What does that say about you?

When you’re asked a question that doesn’t need to be answered yet, do you ask, “Do we need to know that yet?”

When you’re asked a question that cannot be answered yet, do you ask, “Can we know that yet?”

When you’re asked a question that is too costly to answer, do you ask, “Do we have enough time and money to know that?”

Do you have the courage to ask those three questions?

What does that say about you?

Image credit – Tambako The Jaguar

You know you know, but you don’t.

You think you know, but you don’t.

You’re pretty sure you don’t know.

You know you don’t know, you think it’s not a problem that you don’t, but it is a problem.

You know you don’t know, you think it’s a problem that you don’t, but it isn’t a problem.

You don’t know, you don’t know that you don’t need to know yet, and you try.

You don’t know, you know you don’t need to know yet, and you wait.

You don’t know, you can’t know, you don’t know you can’t, and you try.

You don’t know, you can’t know, you know you can’t, and you wait.

Some skills you may want to develop….

To know when you know and when you don’t, ask yourself if you know and listen to the response.

To know if it’s a problem that you don’t know or if it isn’t, ask yourself, “Is it a problem that I don’t know?”  If it isn’t, let it go.  If it is, get after it.

To know if it’s not time to know or if it is, ask yourself, “Do I have to know this right now?” If it’s not time, wait.  If it is time, let the learning begin.  Trying to know before you need to is a big waste of time.

To know if you can’t know or if you can, ask yourself, “Can I know this?” and listen for the answer. Trying to learn when you can’t is the biggest waste of time.

Image credit — Dennis Skley

Good teachers change your life.  They know what you know and bring you along at a pace that’s right for you, not too slowly that you’re bored and not too quickly that your head spins. And everything they do is about you and your learning.  Good teachers prioritize your learning above all else.

Chris Brown taught me Axiomatic Design.  He helped me understand that design is more than what a product does.  All meetings and discussions with Chris started with the three spaces – Functional Requirements (FRs) what it does, Design Parameters (DPs) what it looks like, and Process Variables (PVs) how to make it. This was the deepest learning of my professional life.  To this day, I am colored by it.  And the second thing he taught me was how to recognize functional coupling.  If you change one input to the design and two outputs change, that’s functional coupling.  You can manage functional coupling if you can see it.  But if you can’t see it, you’re hosed.  Absolutely hosed.

Vicor Fey taught me TRIZ. He helped me understand the staggering power of words to limit and shape our thinking.  I will always remember when he passionately expressed in his wonderful accent, “I hate words!” And to this day, I draw pictures of problems and I avoid words.  And the second thing he taught me is that a problem always exists between two things, and those things must touch each other.  I make people’s lives miserable by asking – Can you draw me a picture of the problem?  And, Which two system elements have the problem, and do they touch each other? And the third thing he taught me was to define problems (Yes, Victor, I know I should say conflicts.) in time.  This is amazingly powerful.  I ask – “Do you want to solve the problem before it happens, while it happens, or after it happens?” Defining the problem in time is magically informative.

Don Clausing taught me Robust Design.  He helped me understand that you can’t pass a robustness test.  He said, “If you don’t break it, you don’t know how good it is.”  He was an ornery old codger, but he was right.  Most tests are stopped before the product fails, and that’s wrong.  He also said, “You’ve got to test the old design if you want to know if the new one is better.”  To this day, I press for A/B testing, where the old design and new design are tested against the same test protocol.  This is much harder than it sounds and much more powerful.  He taught me to test designs at stress levels higher than the operating stresses.  He said, “Test it, break it, and improve it.  And when you run out of time, launch it.”  And, lastly, he said, “Improve robustness at the expense of predicting it.”  He gave zero value to statistics that predict robustness and 100% value to failure mode-based testing of the old design versus the new one.

The people I work with don’t know Chris, Victor, or Don. But they know the principles I learned from them.  I’m a taskmaster when it comes to FRs-DPs-PVs.  Designs must work well, be clearly defined by a drawing, and be easy to make.  And people know there’s no place in my life for functional coupling.  My coworkers know to draw a picture of the problem, and it better be done on one page.  And they know the problem must be shown to exist between two things that touch.  And they know they’ll get the business from me if they don’t declare that they’re solving it before, during, or after.  They know that all new designs must have A/B test results, and the new one must work better than the old one.  No exceptions.

I am thankful for my teachers.  And I am proud to pass on what they gave me.

Image credit — Christof Timmermann

X: We need a strategic plan.

Me:  Why do you need one of those?

X: Everybody needs a strategic plan.

Me: Okay.  That didn’t work. Let me try it another way.  What makes a plan strategic?

X: You start with a strategy and you create a plan to make it happen over the next three years.

Me: So, you plan out the next three years?

X: Yes. Or four.

Me: Doesn’t the plan assume you know how the Universe will behave over the next three years?

X: We know our market, we know our customers, we know our technology, and we make a three-year plan.

Me: And what if something changes, like COVID, tariffs, or a new competitor brings to market something that obsoletes your best product?

X: You can’t plan for that.

Me: Exactly.

X: You’re talking in circles! What do you mean?

Me: If your three-year plan can’t plan for unplanned things, what kind of plan is that?

X: I told you.  It’s a strategic plan.

Me: Hmm.  Let me try that again.  What happens when something unexpected arises and your plan needs to change?

X: It’s a strategic plan.  Those don’t change.

Me: Arrg.  Do you mean the plan should change, but you don’t make the change? Or strategic plans never change?

X: Strategic plans don’t change because they’re strategic.  We put a lot of time into creating them.

Me: They don’t change because they take a lot of time and effort to create?

X: Well, yes.  We have long planning meetings, and our best people spend a lot of time creating it.

Me: Do you think the Universe cares how long it took you to create your plan?

X:  There you go again with the Universe thing.

Me: What I mean by that is there are many factors outside your control.  It’s a big world out there. And you can’t plan for everything.

X: What do you mean? We put everything in the strategic plan.

Me: That’s not the type of everything I’m talking about.  I’m talking about things outside your control that you cannot possibly know.

X: Are you saying we don’t know what we’re doing?

Me: No, I’m saying you know everything you’re going to do over the next three years.  And that’s the problem.

X: You are frustrating.  First you tell me it’s impossible to plan for everything, then you tell me we have a problem because we plan for everything.  What’s wrong with you?

Me: That’s the right question.  There’s a lot wrong with me. I have a good idea that turns out to be wrong, so I change my plan. I think I understand what’s going on, but I learn that I’m wrong, so I change my plan. I have a plan, but something unexpected happens and turns my plan from good to wrong, so I change it, even if the plan is strategic, whatever that means.

Image credit — Geoff Henson

Plans are good, until they’re not.  The key is knowing when to stay the course and when to adjust the plan.

The time horizons for strategic plans or corporate initiatives can range from two to five years.  To ensure we create the best plans, we assign the work to our best people, we provide them with the best information, and we ask them to use their best judgment.  As input, we assess market fundamentals, technology trends, customer segments, our internal talent, our partners, our infrastructure, and our processes.  We then set revenue targets and create project plans and resource allocation plans to realize the revenue goals.  And then it’s go time.

We initiate the projects, work the plans, and report regularly on the progress.  If the progress meets the monthly goal, we keep going.  And if the progress doesn’t meet the monthly goal, we keep going.  We invested significant time and effort into the plan, and it can be politically difficult, if not bad for your career, to change the plan.  It takes confidence and courage to call for a change to a strategic plan or a corporate initiative.  But two to five years is a long time, and things can (and do) change over the life of a plan.

A plan is created with the best knowledge available at the time.  We assess the environment and use the knowledge to set the financial requirements for the plan.  When the environment and requirements change, the plan should change.

Before considering any changes, if we learn that the assumptions used to create the plan are invalid, the plan should change.  For example, if the resource allocation is insufficient, the timelines should be extended, resources should be added, or the scope of the work should be reduced. I think changing the plan is responsible management, and I think it’s irresponsible management to stay the course.

The environment can change in many ways.  Here are five categories of change: tariffs, competition, internal talent (key people move on), new customer learning, and new technical learning (e.g., more technical risk than anticipated).  Significant changes in any of these categories should trigger an assessment of the plan’s viability.  This is not a sign of weakness.  This is responsible management.  And if the change in the environment invalidates the plan’s assumptions, the plan should change.

The specification (revenue targets) for the plans can change.  There are at least two flavors of change: an increase in revenue goals or a shorter timeline to achieve revenue goals, which are usually caused by changes to the environment.  And when there’s a need for more revenue or to deliver it sooner, the plans should be assessed and changed.  Again, I think this is good management practice and not a sign of failure or weakness.  When we realize the plan won’t meet the new specification, we should modify the plan.

When we learn the assumptions are wrong, we should change the plan.  When the environment changes, we should change the plan.  And when the specification changes, we should change the plan.

Image credit — Charlie Day 

Improvement is progress.  Improvement is always measured against a baseline, so the first thing to do is to establish the baseline, the thing you make today, the thing you want to improve.  Create an environment to test what you make today, create the test fixtures, define the inputs, create the measurement systems, and write a formal test protocol.  Now you have what it takes to quantify an improvement objectively.  Test the existing product to define the baseline.  No, you haven’t improved anything, but you’ve done the right first thing.

Improving the right thing to make progress.  If the problem invalidates the business model, stop what you’re doing and solve it right away because you don’t have a business if you don’t solve it. Any other activity isn’t progress, it’s dilution.  Say no to everything else and solve it.  This is how rapid progress is made.  If the customer won’t buy the product if the problem isn’t solved, solve it.  Don’t argue about priorities, don’t use shared resources, don’t try to be efficient.  Be effective.  Do one thing.  Solve it.  This type of discipline reduces time to market.  No surprises here.

Avoiding improvement of the wrong thing to make progress.  For lesser problems, declare them nuisances and permit yourself to solve them later.   Nuisances don’t have to be solved immediately (if at all) so you can double down on the most important problems (speed, speed, speed).  Demoting problems to nuisances is probably the most effective way to accelerate progress.  Deciding what you won’t do frees up resources and emotional bandwidth to make rapid progress on things that matter.

Work the critical path to make progress. Know what work is on the critical path and what is not.  For work on the critical path, add resources.  Pull resources from non-critical path work and add them to the critical path until adding more slows things down.

Eliminate waiting to make progress.  There can be no progress while you wait.  Wait for a tool, no progress.  Wait for a part from a supplier, no progress.  Wait for raw material, no progress.  Wait for a shared resource, no progress.  Buy the right tools and keep them at the workstations to make progress.  Pay the supplier for priority service levels to make progress.  Buy inventory of raw materials to make progress.  Ensure shared resources are wildly underutilized so they’re available to make progress whenever you need to.  Think fire stations, fire trucks, and firefighters.

Help the team make progress. As a leader, jump right in and help the team know what progress looks like.  Praise the crudeness of their prototypes to help them make them cruder (and faster) next time.  Give them permission to make assumptions and use their judgment because that’s where speed comes from.  And when you see “activity” call it by name so they can recognize it for themselves, and teach them how to turn their effort into progress.

Be relentless and respectful to make progress. Apply constant pressure, but make it sustainable and fun.

Image credit — Clint Mason

No one has ever been promoted by failing fast.  They may have been promoted because they learned something important from an experiment that delivered unexpected results, but that’s fundamentally different than failure.  That’s learning.

Failure, as a word, has the strongest negative connotations.  Close your eyes and imagine a failure.  Can you imagine a scenario where someone gets praised or promoted for that failure?  I think not.  It’s bad when you fail to qualify for a race.  It’s bad when you fail to get that new job.  It’s bad when driving down the highway the transmission fails fast.  If you squint, sometimes you can see a twinkle of goodness in failure, but it’s still more than 99% bad.

When it’s bad for people’s careers, they don’t do it. Failure is like that.  If you want to motivate people or instill a new behavior, I suggest you choose a word other than failure.

Learning, as a word, has highly positive connotations.  Children go to school to learn, and that’s good.  People go to college to learn, and that’s good.  When people learn new things they can do new things, and that’s good.  Learning is the foundation for growth and development, and that’s good.

Learning can look like failure to the untrained eye.  The prototype blew up – FAILURE.  We thought the prototype would survive the test, but it didn’t.  We ran a good test, learned the weakest element, and we’re improving it now – LEARNING.  In both cases, the prototype is a complete wreck, but in the FAILURE scenario, the team is afraid to talk about it, and in the LEARNING scenario they brag.  In the LEARNING scenario, each team member stands two inches taller.

Learning yes; failure no.

The transition from failure to learning starts with a question: What did you learn?  It’s a magic question that helps the team see the progress instead of the shattered remains.  It helps them see that their hard work has made them smarter.  After several what-did-you-learns, the team will start to see what they learned.  Without your prompts, they’ll know what they learned.  Then, they’ll design their work around their desired learning.  Then they’ll define formal learning objectives (LOs). Then they’ll figure out how to improve their learning rate.  And then they’re off to the races.

You don’t break things for the sake of breaking them.  You break things so you can learn.

Learning yes; failure no.  Because language matters.

Image credit — mining camper

Be bold – the alternative is boring.

Be the first to forgive – it’s like forgiving twice.

Be yourself – you’re the best at that.

Be afraid – and do it anyway.

Be effective – and to hell with efficiency.

Be happy – if that’s what’s inside.

Be authentic – it’s invigorating.

Be energetic – it’s contagious.

Be a listener – that’s where learning comes from.

Be on time – it says you care.

Be early if you can’t be on time – but just a little.

Be courageous – but sparingly.

Be kind – people remember.

Be truthful – that’s how trust is built.

Be a learner – by learning to listen.

Be sad – if that’s what’s inside.

Be a friend – it’s good for them and better for you.

Be nobody – it’s better for everybody, even you.

Image credit — Irene Steeves