Shipulski On Design

Archive for the ‘Fundementals’ Category

Process, process, process.  Everything has been about process improvement over the last decade.  And Lean has had a good run.  But let’s face it.  Its improvements have diminished, and it has largely hit a wall.  And yet, we are doubling down on this tired old horse.

S-curves are real.  Improvements are slow in the early stages, steep in mid-life, and they roll off as the system hits its asymptotic constraint.  And that’s where Lean is now.  It has hit its physical constraints defined by the product design.  Yes, I said the product is the constraint.  And without a radical change to the product, the next level of process improvement is blocked from coming to be.  But it’s not as bad as it seems.  In a sense, the bad news is the good news.

Over the last couple of decades, we forgot that the total cost is largely defined by the product design, not the manufacturing process.  The design engineering community has been let off the hook and has not been tasked with designing the product with less material cost or designing it in a way that opens up space for the next generation of process simplification (Lean).  The bad news is the product design has not changed and is blocking the next evolution of Lean.  The good news is that because the product design hasn’t changed, it’s ripe for radical cost reduction.  And the better news – changing the product itself can reduce material cost, and the material cost is at least 75% of the total cost.  And, by definition, Lean, in its current and future embodiments, cannot reduce material cost. The only way to reduce material cost is to change the product design.

Lean has saved money, but because it cannot make changes to the product itself, it can only reduce labor cost.  Here’s the math.  If material cost is 75% of total cost, overhead is 5%, and labor cost is 20%, the domain of Lean’s savings has always been limited to about 20% of total cost.  (There has never been a project that successfully reduced overhead, so that’s always off limits.) When the product itself becomes open to change, the potential for cost reduction is almost four times larger (20% to 70%).  And that’s the good news.  But the good news is also the bad news.

Yes, if the design can be changed, cost savings can be astronomical.  But the bad news – there are no engineering leaders who know how to do it.  And without engineering leaders advocating for, cajoling, prodding, and teaching product simplification, the engineering team cannot and will not pull it off.

The tools for product simplification exist, but the appreciation for their power has aged out with the previous generation of engineering leaders.  And the knowledge of how to wield the tools has also aged out.

If you want to open up the next level of company profitability, you’ve got to simplify the product.  Full stop.  And if you want to achieve those 4X savings, you’ve got to hire an old pro who has done it before.  Yes, I said old. (Maybe “experienced” is a better word?)

And before you get the bad idea to research the history of product simplification and the associated tools in the hopes of doing it on your own, don’t.  More than anything, this journey is an emotional journey.  You have to create the right conditions for the engineers to succeed, and that knowledge is not captured in the history books.

If you want to succeed, you’ll have to hire an old pro.  This is The Way.

Image credit — Crosa

I had the best teachers.  They taught me to assess the situation as it is before trying to improve it.  Early in my career, my leaders did not understand the importance of spending the time to define the current state.  Hurry up and fix it!  Why are you spending time analyzing the existing product? Why do you want to create a functional analysis of the product we want to obsolete?  Why do you want to understand why customers purchased our legacy products?

By assessing the system/products as they are, I learned how to identify the elements to reuse, to improve, and to reinvent.  This has been a great way to focus the resources on the most important elements and increase the intensity the allocated resources.  When you don’t spend time on the 50% of the system that can be reused, you double the resource intensity over a complete redesign.

So, I ask you – how do you decide what can be reused, what must be improved, and what must be reinvented?

Regardless of the system’s size or scope of the project, assessing the current state is the right first step.  For example, there is great interest in improving the business model.  First question (that no one can answer) – What is our business model?  There are tools to define business models visually to show the partners, competitors, customers, data flow, money flow, product flow.  The tools show who does what to whom and how, who helps whom and how, and what’s missing.  One of the tools I like is Wardley Maps.  While Simon (Wardley) doesn’t talk much about mapping business models, I’ve misused his maps for business model mapping.

A rule for business models:  If you can’t describe your business model visually on one page, you don’t know what your business model is and you can’t improve it.

And assessing the current state is effective at the leaf-level (the lowest level).  Mapping the system functionally (functional decomposition with Axiomatic Design) and defining a problem rigorously (TRIZ), allows the team to place the problem in the context of the whole system AND to define the problem at the smallest level possible (think telescope to microscope).

A rule for problems – There’s nothing worse than solving the wrong problem, so you better be sure you’re solving the right one.

A long time ago, I led a project that took the time to assess the baseline product (existing product) for cost, part count, and part type.  Using DFMA, ee knew where the parts were, and we designed them out and we knew where the cost was and we designed it out.  It took a “long time” to do that work, but we radically improved the profitability of the new product (7X improvement in profit per square foot of the factory).  We also did a full functional decomposition on the baseline product and learn that there was one subsystem that caused trouble with all the electronic systems and created problems for customers.  We hardened the design against that subsystem’s devilish energy.  And we created robustness tests where we tested the baseline product and demonstrated improved robustness on the new product. (We used TRIZ to solve the right problems.)  Those efforts reduced warranty cost per unit by 4X.

Rigorously assessing the current state (products, processes, systems, business models) seems too slow and a big waste of time.  It is my experience, though, that it’s faster and improves the outcomes of the new product development and improvement projects.

But don’t take my word for it.  Give it a try.  And if you need some help, let me know.

Image credit – Calsidyrose

From: Caring about what others think about you.

To:     Caring about what you think about you.

From: Seeing what you didn’t accomplish.

To:     Seeing what you accomplished.

From: Feeling for others.

To:     Feeling with others.

From: Doing things others want you to do.

To:     Doing what you think is right.

From: Feeling stuck with how things are.

To:     Seeing things as impermanent and taking comfort in that.

From: Making your world small.

To:     Helping others.

From: Judging others through your lens.

To:     Accepting people as they are.

From: Wanting things to be different.

To:     Appreciating what you have.

From: Pushing through illness.

To:     Resting so your body can heal.

From: Being too busy.

To:     Saying no.

From: Judging yourself negatively.

To:     Loving yourself.

Image credit — Jay Huang (Frame)

Everything starts from what’s been done before.  Designing a new product starts with assessing the subassemblies of your existing product.  Here’s how the assessments go for the subassemblies.

First, make two Pareto charts: cost by subassembly and part count by subassembly.  Prioritize the subassemblies on the left of both charts.

If the functionality is sufficient and the cost is right, reuse it as-is.  This allows you to spend your time and energy elsewhere.

If the cost is right but the functionality needs to be adjusted, adjust it and move on.  The technical risk is low, and the cost will still be right.  Spend your energy where the problems are.

If functionality is good and the cost is high, simplify the product using part count reduction.  Create a bench test to verify functionality and robustness are better than the old one.

If the functionality is insufficient and the cost is too high, spend your energy here.  Create a bench test to quantify the performance of the existing subassembly.  Turn up the dials to increase the stress on the subassembly until it breaks.  Fix the part that breaks.  Repeat until you run out of time.  Create two Pareto charts for the subassembly: cost by part and part count by part type (main part, fastener, connector, protection, label).  Design out the highest cost parts and redesign the highest cost parts that remain.  Design out fasteners, connectors, protection parts, and labels.

Create a functional test for the product as a whole (think miles per gallon for a new car) and test the old one until it breaks.  Build the new product with the new subassemblies and test it until it breaks.  The performance must be better, and it must perform under stress longer than the baseline product.  Break the new product, fix the weakest link, and retest.  Do this until you run out of time and launch it.

This is The Way.

Image credit — George Redgrave

I’ve built engineering teams that developed the world’s most successful products in their space.

At the start of the team’s migration to greatness, they don’t believe in themselves. And that’s why you, as their leader, have to believe in them.  Every day, you must tell them why you believe in them.  Every day, you must give them examples of their behaviors that justify your belief in them.  At the start of the journey, they don’t know how to do their work differently.  And that’s why you, as their leader, must show them how.  You can’t simply tell them how to do the new work because they won’t believe you.  And that’s why you must show them.  There are no half measures here.  You’ve got to be all in.

As their leader, you must set exceptionally challenging goals.  They cannot be impossible goals, but they can be almost impossible.  And when the team pushes back on your almost impossible request, you must explain HOW you will help them do the almost impossible.

None of this is free.  You must create the tools, training, and time for the exceptional performance to emerge.  You must give them the new tools, the training, and you must give them the time to learn the tools and use them appropriately.

Pro Tip: If you don’t give the team the tools, training, and time to use them, you’ll get what you got last time.

At the earliest sign of the new behaviors, you must praise them publicly.  “This is what I’m talking about!  This is great!  I like how you used the new tools.  Thank you.”  Tell everyone what they did.  Tell their spouse or partner.  Tell their kids.  Be proud.

And as the new behaviors build on each other (and they will), continue to show them your happiness.  Turn up your excitement for their remarkable work.  Tell them what they did because they won’t know.  Tell them why it was so good.  And push them for more.  Tell them you know they can do more.  And now they’ll believe you because they’ve seen what’s possible.  And they’ll believe in themselves. And once they believe in themselves, it’s off to the races.

The products will work better, will sell more, will cost less, and won’t break.  They will be easy to build, easy to test, and easy to troubleshoot.  And they will be profitable as hell.  But that’s not the real value.  The real value is that you helped build a team that believes they can do it better next time.

I have helped engineering teams do work they could not imagine.  I have helped technicians elevate their performance and outperform engineers. I have helped Ph.Ds. learn from customers.  And I have helped engineers grow into Principal Engineers, Engineering Directors, GMs, and CEOs.

This has been the most rewarding work of my life.

Image credit — Mikhail Esteves – Piggy Back

I’m tired of hearing about North Stars and Idealized Future States. I much prefer to define the current state.

I want to move from “let’s do this!” to “how are we doing it today?”

Stop: Imaging what could be.  Start: Defining what’s going on right now.

Every journey starts with a first step.  And that first step is taken from where you are.

Location before destination, that’s what I say.

Where are you?

Before you can decide if you need a course change, you’ve got to know your direction of travel.

Instead of arguing about a new course heading, analyze the current direction of travel.

To determine your direction of travel, look where you were three years ago, two years ago, and one year ago.  From the past, draw a line through today and onward.  That’s your trajectory.

Before you can know where you’re going, you’ve got to know where you’ve been.

Where have you been?

Now that you know where you were, where you are, and where you’re going, you’re ready to run small experiments to find the fertile design space.

Mari Dallavara — small cairn

This is the second in a series of blog posts on transformation (changes that make a difference).  In the first post, I described the power and benefit of focusing on the current state at the expense of the future state.  The main idea is to define where you are and choose a direction of travel, which is almost the opposite of defining the idealized future state, defining the gaps, and putting together a plan to get there.  The topic of this post is moving from dilution to distillation.

Here’s the situation: Growth expectations were just increased. Competition is more severe. The pace of change is faster than ever. AI has made it easier for startups to start.  The cost of being late is insolvency, so project timelines are pulled in.  And because the project portfolio does not support the increased growth objectives, more projects are added. The next round of layoffs is on the agenda, so there will be fewer people to pull off the impossible.

Adding projects means more projects are spread over fixed resources.  This dilutes resources, and everything slows down. And that’s the opposite of what we want.  Fewer projects spread over fixed resources distill efforts, and progress accelerates.  With projects, there is no partial credit.  Until the project is 100% done, we get 0% credit. A project that’s 98% complete generates zero revenue.  Adding projects pushes out completion dates, but that’s often what we do, even though we know we want otherwise.

Here’s a distillation mantra: Work on fewer projects to get more done.

There are tools, methods, and practices to protect ourselves from creating dilution, but that’s for another time. I will end the post here to reinforce that distillation is more effective than dilution.

Image credit – Alexander Grandholm

The need to grow revenue and profit is ever-present.  And as the pace of change accelerates and competitors elevate their game, it’s getting more difficult.

Growth must be built on top of your best work.  To grow, you must develop new products and services that make your customers swap out the old offering they just bought from you for the new one you just launched.  And you must develop the new product with the team that developed the old one.  This is difficult.  You need to create the conditions for the team to see their best work as crap and prevent them from seeing themselves as crap.

For customers to replace an existing product with a new one, the new product must help customers make more progress than the old one.  In a word, the new one must be better, or customers won’t buy it.  And if they don’t buy the new one, there can be no growth.  But here’s the difficult part – when the team built the old one, they designed in as much goodness as possible, yet your task is to help the team design a better one.  Hey Team, congratulations on the wonderful success of the existing product.  You did new work in new ways; you stretched; you hustled; you sprinted.  Now, you must outdo yourselves, even though you just did that.  This is quite the balancing act for the engineering leader.

Growth comes when the team designs a product that works better than the one they designed last time.

Designing a new product that works better is only half of the profitability recipe.  It must also cost less.  Yes, it must work better AND cost less.  Yes, I said AND.  Most teams don’t believe they can design a new product that costs less, and they think you’re crazy when you tell them the new one must work better and cost less.  But this type of double-barreled profitability improvement is possible and proven.  But only if the engineering leader believes it.  And most don’t.

Growth is realized when the team designs a new product that works better AND costs less.

You can radically improve profitability with this double-barreled approach.  I’ve used it to more than double the profit per square foot of the assembly area.  And that makes the CFO smile and gets you lunch with the CEO.  It’s good for profitability and better for your career.

Radical growth comes from obsoleting your best work, but only if you think it’s possible.

Image credit — Don Miller – double rainbow

AI may be wonderful in some contexts, but AI makes it more difficult to be an effective engineering leader.  Using AI in engineering elevates the training, development, and mentorship requirements that companies must address to make their engineering leaders successful.

When asked questions, AI gives answers.  The answers may be correct or not.  In day-to-day life, that’s not such a big deal.  But in engineering, that’s not good enough.  In engineering, the answers must be right.  Not almost right.  Not maybe right. Not kinda right. The answers must be right. When engineering leaders design products, those products must work, function as advertised, satisfy customers’ needs, meet the cost target, and not hurt people.  If an engineering leader follows AI blindly, there’s no guarantee the product will be successful, profitable, or safe.

When asked the wrong question, AI gives an incorrect answer to the question that should have been asked.  If an engineering leader misunderstands the context, there’s a good chance they’ll ask the wrong question.  And they won’t know it. At best, this will create rework and project delays. And in the worst case, the company could launch a product that hurts people.

And there’s an even more troubling situation: when the engineering team presents solutions to the engineering leader without informing the leader that AI was used to generate the solutions.  To protect against this failure mode, the engineering leader must recognize when AI has been used and dig into the questions/prompts the AI was given.  From there, the engineering leader must use their knowledge of the design context to decide whether the prompts were valid and whether the answer is useful or viable.  This is a heavy lift and requires highly capable engineering leaders who have been trained to recognize AI use and verify the validity of its solutions.

Can your engineering leaders use their knowledge of the design context to provide the right prompts to an AI?

Can your engineering leaders challenge the applicability of an AI’s answer even when they think they’ve provided good prompts to the AI?

Can your engineering leaders detect when their teams have used AI to generate solutions?

Can your engineering leaders challenge the engineering teams when they suspect AI has misled the engineering team?

I hope the answer to those four questions is yes.

Image credit — Richard

Go faster. Do it better. Do more with less.  Meet the growth objective.  All good ideas, but how? In two words: Engineering Leadership.

Going forward, competition will be fiercer. Engineering organizations will be asked to do better engineering work, even though they did that on the previous project.  And to do that, engineering leaders will have to up their game.  They will have to improve the engineers’ performance on the job and their own performance.

I think engineering leadership development is a singular challenge for companies that want to thrive and grow. And for mature companies, I think it will become more difficult as these companies reduce headcount.  The burden on engineering leaders will grow as there are fewer leaders, more projects to complete, more work to elevate, and each leader will have more direct reports.   It’s already difficult for engineering leaders to make time to grow engineers and to do it without guidance and support, but I think it will become more difficult.

And developing engineering leaders is difficult for younger companies that want to grow.  These companies have engineering leaders with less experience and are new to the company and the industry.  The organizational design is still forming and fluid, the work processes are still under development, and there are far more projects to deliver.  Engineering leaders must create the organizational structure, identify engineering talent to develop, fill organizational holes, and increase design productivity to meet the company’s growth targets.  These are big challenges for new-to-role engineering leaders who must get it done without mentorship and guidance.

Often, companies try to use standard leadership development programs to grow engineering leaders, but in my experience, these generic leadership programs don’t cut it.  Every aspect of engineering leadership work has a technical bias that shapes the work, the processes, and the approaches.  Generic leadership development programs are not built on a technical backplane and don’t provide the specialized guidance and support for the work.

Engineering leadership development is different.

Engineering leadership development comes with unique challenges.  And to further complicate things, those challenges differ between mature companies and younger companies.

Your products and technologies are different.

Your processes are different.

Your business models are different.

And your engineering leadership development program should be different.

Image credit — Bennilover

To help your team members communicate more effectively, teach them to put their argument on one page.  Teach them what to leave off the page and explain why those things should be omitted. Teach them what’s at the top of the page and explain why.  Help them identify the central element and show them how to make it fill the center of the page.

Teach them that the professionals distill.

They will have difficulty stripping away the clutter.  They will have difficulty shedding the details. They will have difficulty raising the level of abstraction.  Their fear is typically that people (the leadership team) will think they don’t know what they’re doing because their one-pager doesn’t contain all the details.  It’s your job to help them think otherwise.  You have to help them understand that capable people know how to distill their argument to its essence and answer questions about the details when asked.

To help your team members get the tone right, teach them about snarl words and no purr words.  Snarling and purring create a manipulative tone that devalues the argument.  Teach them to use the fewest, clearest, non-judgmental words.  And no blaming words.  Explain that “they” and “them” signal that there are competing factions that aren’t working well together.

Teach them that words matter.

To help your team communicate a complicated process, system, or approach, teach them to create a hand sketch that represents the complicated idea.  The hand sketch method is like the verbal decluttering described above, but teaching them to create a hand sketch takes the distillation to the next level. The hand sketch is not the process itself; it represents the process.  The sketch doesn’t describe the system in full; it focuses on the main pillars. And it doesn’t describe the approach in a flow chart way; it elevates the novel elements.  And to further raise the bar, limit the number of words to an unreasonable number like six or twelve.

Teach them that a sketch demonstrates understanding.

This one-page approach can also be used for problems, planning, and prioritization, but that’s for another time.

Image credit — Tambaco The Jaguar