Shipulski On Design

Posts Tagged ‘Learning’

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

At the start, it’s impossible to know the right thing to do, other than the right thing is to start.

If you think you should have started, but have not, the only thing in the way is you.

If you want to start, get out of your own way, and start.

And even if you’re not in the way, there’s no harm in declaring you ARE in the way and starting.

If you’re afraid, be afraid. And start.

If you’re not afraid, don’t be afraid.  And start.

If you can’t choose among the options, all options are equally good.  Choose one, and start.

If you’re worried the first thing won’t work, stop worrying, start starting, and find out.

Before starting, you don’t have to know the second thing to do.  You only have to choose the first thing to do.

The first thing you do will not be perfect, but that’s the only path to the second thing that’s a little less not perfect.

The second thing is defined by the outcome of the first. Start the first to inform the second.

If you don’t have the bandwidth to start a good project, stop a bad one.  Then, start.

If you stop more you can start more.

Starting small is a great way to start.  And if you can’t do that, start smaller.

If you don’t start, you can never finish. That’s why starting is so important.

In the end, starting starts with starting.  This is The Way.

Image credit — Claudio Marinangeli

Demoing something for the first time is difficult, but doing it for the second time is easy.  And when you demo a new solution the first time, it (and you) will be misunderstood.

What is the value of this new thing?  This is a good question because it makes clear they don’t understand it. After all, they’ve never seen it before.  And it’s even better when they don’t know what to call it. Keep going!

Why did you do this?  This is a good question because it makes clear they see the demo as a deviation from historically significant lines of success.  And since the lines of success are long in the tooth, it’s good they see it as a violation of what worked in the olden days.  Keep going!

Whose idea was this? This is code: “This crazy thing is a waste of time and we could have applied resources to that tired old recipe we’ve been flogging for a decade now.”  It means they recognize the prototype will be received differently by the customer.  They don’t think it will be received well, but they know the customer will think it’s different.  Keep going!

Who approved this work? This is code: “I want to make this go away and I hope my boss’s boss doesn’t know about it so I can scuttle the project.”  But not to worry because the demo is so good it cannot be dismissed, ignored, or scuttled. Keep going!

Can you do another demo for my boss?  This one’s easy.  They like it and want to increase the chances they’ll be able to work on it.  That’s a nice change!

Why didn’t you do this, that, or the other? They recognized the significance, they understood the limitations, and they asked a question about how to make it better. Things are looking up!

How much did the hardware cost? They see the new customer value and want to understand if the cost is low enough to commercialize with a good profit margin.  There’s no stopping this thing!

Can we take it to the next tradeshow and show it to customers?  Success!

Image credit — Bennilover

Software may be eating the world, but the hardware elements of a startup’s work define when lunch is served.

Hardware takes longer than software.  With hardware, after the product and its parts are designed, companies are vetted/selected to make the parts; contracts are signed to make the parts; the parts are made; the parts are shipped; the parts are received; the parts are inspected; and the parts are put in their locators.  Then, the manufacturing process is defined, the manufacturing tooling is designed and purchased; the manufacturing documentation is created; the final test system is designed and built; and the parts are assembled into the product. Then, the product is run through final test and tested for robustness.  After it’s learned the manufacturing process created too much variation and the insufficient robustness manifests, the manufacturing process and its documentation are changed to reduce variation; the parts that failed are redesigned, purchased, made, shipped, and received; and the next iteration of the product is built and tested.  This process is repeated until the product is robust and the manufacturing process is repeatable.  This is why hardware takes longer than software.

If the software is done but the hardware isn’t, the software must wait for the hardware and the customer must wait for the finished product. To get the hardware done faster, recognize that redesign loops are part of the game and invest in the capability to iterate quickly.  Line up the suppliers to make parts quickly; keep utilization low on the support resources so they can jump on the work when it arises (think fire stations who can respond quickly when there’s a fire); and avoid part-time resources on the critical path.  There may be other things to focus on, but only after taking care of these three.

Software may be eating the world, but the hardware elements of a startup’s work govern the cost of getting to the dinner table.

Hardware costs more to make than software.  Hardware is made of steel, aluminum, injection molded plastics, and rare earth elements, all of which cost money.  And because startups do things that have not been done before, the materials can be special (costly).  And unlike software, the marginal cost of an incremental unit is non-zero.  With hardware, if you want to make another one you’ve got to buy more of the materials; you have to pay people to make it; you have to buy/build the manufacturing system; you have to buy the measurement systems and engineering infrastructure; and you have to pay people to break-test-fix the product until it’s ready.

What’s a startup to do?

To do hardware faster, focus on learning.  And to do hardware more cost-effectively, focus on learning.

For both time and money, learning efficiency is a good starting point.  The most efficient learning is the learning you don’t have to do, so be ruthless in how you decide what you DON’T learn. Where possible, declare all but the most vital problems as annoyances and save them for later. (Annoyances don’t require learning.)  This will concentrate your precious resources on fewer problems, improve your learning rate, and keep costs to a minimum.

Here’s a good test to decide if the learning is worth learning.  Ask yourself “If we accomplish this learning objective, how will the customer benefit?”  If there is low or no customer benefit, say no to the learning objective.  If there is medium customer benefit, say no to the learning objective.  If there is significant customer benefit, do the learning.

For those learning objectives that make it through the gauntlet, learn what you need to learn, but no more.  To do this, create a formal learning objective: “We want to learn [enter learning objective here].”  With learning objectives, the tighter the better. And define the criteria for decision making: “If the result of the test is [define objective measurement here], we will decide [enter decision here].” With decision criteria, the clearer the better.

Learn effectively, not elegantly.  Be bold, rough, and crude with how you learn.  Design tests that take advantage of the resources you have on hand so you can learn quickly.  If you can run a crude test in one hour and the perfect test will take a week, run three crude tests and be done by the end of the day.

Learn with less confidence and more judgment.  If a wrong decision can be overcome quickly and with low cost, be less confident and use more judgment.

Whether driven by hardware, software, or the integration of both, project completion is governed by the critical path.  And with longer time constants, it’s more likely that the hardware defines the critical path.  The total cost of the project is the sum of the three costs: software, hardware, and integration.  And because hardware requires expensive materials, factories, engineering labs, people to run the tests, and people to make the products, hardware is likely a large percentage of the project costs.

Image credit — Günter Hentschel

When you do something for a long time, the physical and mental muscles you exercise get stronger and you get better at that activity.  But where the muscles you use get stronger, the ones you don’t use atrophy and you get worse at all the other things.

When you do something for a long time, people see you as someone who does that one thing.  And because it’s easy for everyone, that same old work lands on your desk and the system reinforces the problem.  The company knows it will get done quickly and well, and because you’ve done it before, it’s easy for you.  But what’s good and easy in the short term may not be so good and easy in the long term.  When you do what you did last time, you get stale and you don’t grow. It’s the same for your career.  When they see only one slice of you, there’s a long-term downside

When you look at the same old problems for a long time, you see only the same old solutions.  And more troubling, you’re blind to your blindness.  If you’ve solved the same family of problems for the last decade, you won’t see the new solutions made possible by developments in new areas.  And more troubling, you won’t see that it’s time to solve new problems because the same old problems find your desk.

What’s a dinosaur to do?

Pair up with a younger person who wants to learn and teach them how to solve problems.  Their energy will rub off on you and your smarts will contaminate them.  A fair trade for both.  Teach them how to understand the situation as it is – both in the problem space and political space.  Teach them how to read the tea leaves and hear what’s unsaid.  You’ll learn you know far more than you thought and you’ll get to show your whole self to your younger partner in crime.

Put them in a position to succeed and take pride in their success.  Give them credit and revel in their development. Help them stretch and protect them from breaking. Keep them safe and help them live dangerously.  Provide air cover as only you can, and do it with plausible deniability.  You will get great joy (and energy!) from this.

When you’re low on energy, help people. When you’re down in the dumps, take someone to lunch and listen to them.  When you’re tired of the same old work, help people do new work.  And when you want to feel good about what you know, teach people.

At this point in your career, you have all you need and plenty to spare.  Ground yourself in your abundance and give it away.  Everyone will be better for it, including you.

Image credit — Steve Walker