Shipulski On Design

Archive for the ‘Fundementals’ Category

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

Coach? Mentor? Consultant? What’s the right word?

Subject matter expertise.  However they categorize themselves, they must have subject matter expertise.  If you work in the hardware space, they should have experience in hardware.  If you work in the software space, they must have software experience. Ask if they have solved a similar problem in a similar space.

People and Teams.  Whatever they call themselves, they must know how to create the conditions for effective team performance to emerge.  Yes, there is a need to help individual leaders elevate their game.  That’s the minimum entry criterion.  But it’s not enough to guide one person.  Big growth objectives require engaged teams that work together and pull in the same direction.  Have they pushed a team in a skillful way to elevate the work and have the team stand taller because of it?  Ask them for objective evidence.  Have they helped an engineering team obsolete their best work?  This is a high bar because the team must see their best work as something that can be made irrelevant, see themselves as a team that can elevate their work, and be fully engaged in the go-forward challenge.

Systems, not point solutions. Regardless of how they identify, it’s not enough to create a solution for today’s problem.  Anyone can create a narrow solution for today’s specific problem. Have they created the systems, processes, tools, and built out the roles/responsibilities to prevent a broader, more global class of problems?

In the trenches.  Bottom line, no matter their label, they must have done similar work in a hands-on way.  Not in an advisory way, not in an oblique way, not in a thought-leader way, but in an in-the-trenches way.  In a I-did-it-myself way.  Ask them what their role was.  Ask them what they did.  And if they can’t be specific with you, don’t hire them.

It doesn’t matter what they call themselves.  But they must have subject matter expertise, they must have helped teams elevate their game and stand tall, put preventive systems in place, and worked in a hands-on way.

Image credit — Paul VanDerWerf

When you have more projects than people, you have far more activity but far less progress.

Pro Tip: Activity doesn’t pay the bills. Progress does.

Would you rather make lightning progress on two projects or tortoise progress on four?  I prefer lightning.

But isn’t four projects better than two?  It is, if you get compensated for the number of active projects. But it’s not, if you get compensated for finishing projects.

Pro tip: There’s no partial credit for a project that’s less than 100% done.

But how to protect your resources from four projects when you have the resources to deliver on two? This is not a complicated answer: block the extra project from entering the pipeline until you finish one.

Pro Tip: Finish one before you start one, not the other way around.

But what about the efficiency that comes from shared resources that can be spread over four projects?  Don Reintertsen would say “Shared resources create waiting and waiting is the enemy.”  I agree with Don, but I think his language is too reserved.  I say “If you’re focused on the efficiency that comes from shared resources, you don’t know what you’re doing.”

Pro Tip:  Waiting kills progress.  Don’t do it.

Here’s a process to consider.

1. Define the resources you have on hand to work on projects.
2. Choose the most important project and fully staff the project. If the project is fully staffed, start the project.
3. Define the remaining unallocated resources.
4. Choose the next most important project and fully staff the project. If the project is fully staffed, start the project.  If the project is not fully staffed, don’t start a project until you finish one, or you can hire the incremental resources to fully staff a project.
5. Repeat.

Image credit – KIUKO (Elephant Tortoise)

When the cost of the experiment is small, the downside of its potential failure is also small.

Small improvements cost little and can be implemented quickly.

Small improvements make a difference.

If the transformational improvement never sees the light of day because it costs too much to implement, its realized value is less than the smallest improvement that was implemented.

When a small experiment does not go as planned, the learning can be significant (and fast).

Small experiments are funded by small investments that don’t require approval.  Don’t seek approval. Run the experiment.

The second small improvement stands on the shoulders of the first one

If the improvement is never implemented, it’s not an improvement.

Small improvements can be tested under the radar.  When they work well, give the credit to someone who deserves it. When they go poorly, try something else.

Like ants, small improvements gang up to make a real difference.

Once a small improvement is implemented, it stays implemented.  Like a one-way ratchet, there’s no backsliding.

Small improvements add up over time, but only if you bring them to life.

When it comes to improvements, small is beautiful.

Image credit — Jim Roberts – Papa I’m only a little sparrow