Shipulski On Design

Posts Tagged ‘Learning’

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

If you believe you can’t do something, you can’t.

If you try something and it doesn’t work, you might be able to pull it off next time.

If you believe you’re not good enough, you’re not.

If you try something and it doesn’t work, you’re still good enough.

If you believe someone’s opinion of you matters, it does.

If someone disparages you and you don’t believe it, they’re wrong.

If you believe you can do something, you can.

If you try something and it doesn’t work, try it again.

If you believe you’re good enough, you are.

If you try something and it doesn’t work, you have always been good enough.

If you believe someone’s opinion of you is none of your business, it isn’t.

If someone disparages you, ask them if they’re okay and ask if you can help them.

What do you believe?

What will you try next?

What will you do when someone disparages you?

Image credit — joiseyshowaa

If something’s in the way, call it by name and move it out of the way.

If that something is a technical problem, figure out what’s blocking the solution and move it out of the way.

If that something is a person, try to understand what’s motivating their blocking action.  Don’t call their behavior a “blocking action” but try to understand what’s behind their behavior.  Help them understand what they are putting in the way and why they might be behaving as they are.  And once you both understand their behavior, help them see how their behavior is negatively impacting them.  Usually, that’s enough to break the impasse.

If that something that’s in the way is you, pretend you’re someone else and do the same thing.  Have a conversation with yourself.  Ask yourself what motivates the blocking behavior and then listen.  Believe it or not, if you calm your mind and body, you will hear a reply to your question and learn what’s behind the blocking behavior. If it’s fear of failure, a quiet voice will tell you it doesn’t want to feel the emotional pain or the judgment around failure. If it’s fear of success, a different voice will tell you it doesn’t believe it’s worthy of success or doesn’t think highly enough of itself to give things a try.  If it’s fear of confrontation, a part of you will tell you it’s not confident and it doesn’t want to be judged negatively.  Next, it’s time to fight the aversion to uncomfortable thoughts and get curious.

Feel the discomfort around the fear of failure in your body.  Don’t judge it negatively, just feel it. And get curious about the reason behind the fear of failure.  If you listen, it will likely tell you the reason for the discomfort.  Ask it what it’s afraid would happen if it moved that reason out of the way. Usually, there’s a realization that nothing bad would happen if the blocking action was unblocked and it can be moved out of the way.

Whether it’s the fear of success or the fear of confrontation, the process is the same.  Feel the sensations in your body (without judging) and get curious.  Ask the voice what it’s afraid would happen if it stopped putting something in the way.  And if you can refrain from judgment, the voice will tell you what needs to be moved out of the way so progress can be made.

The process I describe above is based on Internal Family Systems (IFS).  I have found it useful to understand the rationale behind my behavior and help myself make progress.

I hope you find it useful.

Image credit — Joachim Dobler

How do you spend your time?

How much time do you spend on things you want to do?

How much time do you spend on things you don’t want to do?

How much time do you have left to change that?

If you’re spending time on things you don’t like, maybe it’s because you don’t have any better options.  Sometimes life is like that.

But maybe there’s another reason you’re spending time on things you don’t like.

If you’re afraid to work on things you like, create the smallest possible project and try it in private.

If that doesn’t work, try a smaller project.

If you don’t know the ins and outs of the thing you like, give it a try on a small scale.  Learn through trying.

If you don’t have a lot of money to do the thing you like, define the narrowest slice and give it a go.

If you could stop on one thing so you could start another, what are those two things?  Write them down.

And start small. And start now.

Image credit — Pablo Monteagudo

X: When will you be done with the project?

Me: This work has never been done before, so I don’t know.

X: But the Leadership Team just asked me when the project will be done. So, what should I say?

Me: Since nothing has changed since the last time you asked me, I still don’t know. Tell them I don’t know.

X: They won’t like that answer.

Me: They may not like the answer, but it’s the truth.  And I like telling the truth.

X: Well, what are the steps you’ll take to complete the project?

Me: All I can tell you is what we’re trying to learn right now.

X: So all you can tell me is the work you’re doing right now?

Me: Yes.

X: It seems like you don’t know what you’re doing.

Me: I know what we’re doing right now.

X: But you don’t know what’s next?

Me: How could I?  If this current experiment goes up in smoke, the next thing we’ll do is start a different project.  And if the experiment works, we’ll do the next right thing.

X: So the project could end tomorrow?

Me: That’s right.

X: Or it could go on for a long time?

Me: That’s right too.

X: Are you always like this?

Me: Yes, I am always truthful.

X: I don’t like your answers. Maybe we should find someone else to run the project.

Me: That’s up to you.  But if the new person tells you they know when the project will be done, they’re the wrong person to run the project.  Any date they give you will be a guess.  And I would not want to be the one to deliver a date like that to the Leadership Team.

X: We planned for the project to be done by the end of the year with incremental revenue starting in the first quarter of next year.

Me: Well, the project work is not bound by the revenue plan.  It’s the other way around.

X: So, you don’t care about the profitability of the company?

Me: Of course I care.  That’s why we chose this project – to provide novel customer value and sell more products.

X: So the project is intended to deliver new value to our customers?

Me: Yes, that’s how the project was justified.  We started with an important problem that, if solved, would make them more profitable.

X: So you’re not just playing around in the lab.

Me: No, we’re trying to solve a customer problem as fast as we can.  It only looks like we’re playing around.

X: If it works, would our company be more profitable?

Me: Absolutely.

X: Well, how can I help?

Me: Please meet with the Leadership Team and thank them for trusting us with this important project.  And tell them we’re working as fast as we can.

Image credit – Florida Fish and Wildlife

X:  Me:  format stolen from Simon Wardley (@swardley).  Thank you, Simon.