Shipulski On Design

Posts Tagged ‘Lessons Learned’

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

This is the first in a series of blog posts on changes that make a difference.   And the first change I will discuss is elevating the importance of the current state and deprioritizing the future state, especially the idealized future state.

Future State To Current State

I bet you are asking to see an idealized future state and the work needed to get there.  Truth is, by definition, you cannot achieve the idealized future state.  You can use it as a navigation aid, but you’ll never get there (H/T Dave Snowden).  At best, it’s aspirational; at worst, the team knows you think it’s achievable (you asked them for a plan to get there).  This makes for a despondent team.  Do you really want that?

And there are other problems with the idealized future state.  Firstly, there is no universal ideal.  Your ideal is not my ideal.  Whose ideal is right? Who decides?  And how do you know it’s ideal?  The team knows there’s no universal ideal. They know the ideal is arbitrary.  And they know you’re asking them to go after this “ideal” state as if it’s truly ideal.  Outwardly, they behave like it’s ideal, and inside, they know it isn’t.  Why do you want to do this to the team that you need to create your next products?

Secondly, the idealized future state is defined in the present moment.  And since your journey is long, things will change along the way.  And these changes make it impossible to predict the idealized future state. The technology will change, the market will change, the laws will change, the regulatory requirements will change, the people will change, and geopolitics will change.  The team knows the future cannot be predicted, and they know the prediction you made is wrong.  They won’t tell you that, but they know.  Why do you want to create the conditions for the team to withhold their thoughts and feelings?

Everyone knows the future cannot be predicted. Why not behave that way?

I think it’s more effective to create a shared understanding of the current state.  To do that, you and the team must agree on your location (current state) at the expense of agreeing on your destination (future state).  All my journeys started from where I was, and all my future journeys will start from where I will be.  Everything starts from where you are. And I think it’s the same with companies.  And when the team agrees on the current state, they are comfortable and confident.  I think it’s in your and your company’s best interest to put the team in that headspace.  It’s good for the team and good for business.

And all journeys start from where you are.  Why not figure out where you are?

If you are curious about mapping in this domain, here are three posts about mapping:

• If you want to make progress, make a map. (2023)
• The Half-Life of Our Maps (2014)
• Situational Awareness (Winter Is Coming) (2018)

Next week, I’ll discuss how to move from Dilution to Focus.

Image credit – Peter Addor – Tree and Birds go in the same direction

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

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

There is no such thing as losing time.  Time doesn’t reverse itself, at least outside the theoretical physics textbooks. We can spend time on things that will never go anywhere, but that’s wasted time, not lost time. The trick with this type of project is to learn that there’s a fundamental constraint BEFORE running the full project.  Here’s a rule:

If there is a fundamental constraint that blocks the project, work on a different project.

We can work on projects that generate zero customer value, but, again, that’s wasted time, not lost time. The trick with projects that deliver zero customer value is to verify there IS customer value BEFORE running the full project.  Here’s a rule:

If the project will not deliver customer value, work on a different project.

But, to be clear, it is insufficient to demonstrate that the project might deliver customer value.  You must demonstrate that the project delivered customer value.  You should now ask me, “Mike, how can we demonstrate the project delivered (past tense) customer value before we run the project in full?”  The answer is to demonstrate traction.  Traction is objective evidence that the customer spent time and energy in ways that are surrogates for “buying” the offering.

If you create a one-page sales tool, show it to a customer, and they want to buy five, that’s traction.  If, after you show them the one-pager and ask for a $200 deposit, and they give it to you, that’s traction. If you make a non-functional prototype, show it to a customer and describe how it helps them make progress, and they want to buy the prototype, that’s traction.

While, as I said, there is no such thing as losing time, there is another way to think about things that is, I think, closer to losing time.  When you use all your resources to do project A, you lose the opportunity to spend your time on project B. When you do a project that will never launch, you lose the opportunity to spend your time on a project that will.  And when you do a project that delivers zero customer value, you lose the opportunity to spend your time on a project that delivers massive customer value.  This perspective, I think, is preferred because it forces a value comparison among all candidate projects instead of simply evaluating the value of a single project.

And timing matters.  There is a viable time window for each project.  You can be too early and smash your head on a viability window that has not yet opened, or you can start a project too late, and the viability window slams shut on your fingers before you can launch.  And in that way, you can lose out on a project’s viable time window.  This isn’t losing time in the strict sense, but I think talking through time windows is helpful.

Before running a full project, learn that there’s no fundamental constraint.

Before allocating significant project resources, demonstrate enormous customer value.

Before starting a project, assess the relative value of all the viable projects. Think opportunity cost.

Before going all in on a project, make sure the timing is right.  Think viable time window.

Image credit — Tsutomu Taksu

Slow down to go fast.

Progress over activity.

Effectiveness before efficiency.

Finish at the expense of starting.

Location is more important than destination.

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

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

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

Uncertainty is flexible, certainty is dangerous.

Learning before scaling.

People first.

Image credit — mhobl

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

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

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

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

What does that say about you?

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

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

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

What does that say about you?

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

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

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

What does that say about you?

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

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

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

Do you have the courage to ask those three questions?

What does that say about you?

Image credit – Tambako The Jaguar

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

What is this all about?

What is the reason you do what you do? What’s your WHY behind the WHAT?

When you don’t do what you said you’d do, what’s the reason? And what does that say about you?

If the reason is right, I think it can be okay NOT to do something you said you’d do.  But I try to set a high bar on this one.

When things get tough, what gets you to push through?  For me, it’s about doing something for the people I care about.

When things go well, what causes you to give credit to others?  For me, it’s about building momentum and helping people understand the special things they did to make it happen.

Why do you show up?  When you ask yourself, do you have an answer?

How do you show up for? And the more difficult question – WHY?

When is it okay to be compliant in a minimum energy way?  And how do you decide that’s okay?

When do you decide to apply your whole self to something that others think is misaligned with the charter?  I think this says a lot about a person.

What are you willing to do even though you know you’ll be judged negatively for doing it?  I’m often unsure why to do it, but I’m sure it’s the right thing to do.  I don’t know what that says about me, but I’m okay with it.

To me, the WHY is far more important than the WHAT.  The WHY explains things.  The WHY tells the story.  The WHY gives guidance on what will happen next time.

When you do something happen that’s out of the ordinary (a WHAT), I suggest you try to figure out the WHY.  I have found that some seemingly nonsensical WHATs make a lot of sense when you understand the WHY underpinning the WHAT.

And during this holiday season, may you give people the benefit of the doubt on their WHATs, and take the time to understand their highly personal WHYs.  That can make for a happier holiday season for all.

Image credit — Christopher Henry

Success locks in current practice.

May you have the blessing of declining revenues to see what must change.

Year-on-year growth hides inefficiencies.

May you have one bad year to help you see those inefficiencies.

Past success blinds us to the onset of decline.

May you have brave heretics to sound the alarm early in the decline.

A strong track record of growth prevents new ideas from seeing the light of day.

May you allocate revenue from that growth to bring the next-generation offering to life.

High market share creates intellectual inertia and stagnation.

May you have the luxury of strong competitors that get stronger every year.

A history of unassailable technical advantage breeds competence-induced failure.

May you have the courage to obsolete your best work.

A strong focus on process, combined with remarkable success, extends standard work beyond its useful life.

May you recognize that commercial conditions have changed, and it’s time to dismantle the very thing that generated your success.

Image credit — Thomas_H_foto

Some have more than you, some have less. Can you be thankful?

Things will go well, and things will go poorly.  Will you be thankful?

Some will support you, and others will diminish.  Can you be thankful?

Truth will be told, and so will lies. Will you be thankful?

You can prevent some problems, but others you cannot.  Can you be thankful?

Some of your hypotheses will be validated, and others will be invalidated.  Will you be thankful?

Sometimes you will be supported, and other times criticized. Can you be thankful?

You will be healthy, and you will be sick. Will you be thankful?

You will get old.  Can you be thankful?

Sometimes you will be calm, and other times anxious.  But can you be thankful?

Sometimes you will agree with family, and sometimes you will disagree.  Can you be thankful?

You will have everything, then it will all go away? Can you be thankful?

Things will be better and worse. Will you be thankful?

There will be success and failure.  Can you be thankful?

You will be happy and sad. Will you be thankful?

Some family members will live close to you, and others will live far away.  Can you be thankful?

Some friends will support you, and others will bail. Will you be thankful?

Sometimes you will rise to the occasion, and other times you will bail. Can you be thankful?

You will be understood and misunderstood.  Will you be thankful?

Thankfulness is a choice.  What will you choose?

Image credit — Cindi Albright