Shipulski On Design

To: Leaders of the Company,

We’re still out of gas.

Corporate initiatives and reinvention are important, but so are the fundamentals of meeting customer orders and keeping the production lines running.  And so is our emotional well-being.

We cannot do it all.

Our youngest children must go to daycare and elementary school, and that scares us.  And when they get the sniffles, we have a difficult time knowing whether it’s the sniffles or Covid.  And that creates stress for us.  Though we faithfully show up every day, our children’s health is a concern for us.  We still give 100%, but it isn’t as good as a couple of years ago.  But it is our best.

Our children in high school and college are having a difficult time.  In-person, not in-person, masks, no mask, and soon-to-be masks are all additional stressors to the already stressful high school and college dynamics.  This is what we live with every day.  Is college even worth it? Our kids aren’t sure and neither are we.  But that doesn’t stop the expenses.  This is what we have to deal with after a full day of work.  It’s stressful and draining.  And our batteries aren’t fully charged when we wake up in the morning.  Yet, we come to work and give our best.  Though we know our best isn’t as good as it used to be, it IS our best.

We can’t give more.

And there’s a war in Europe.  And while that messes up the company’s financials, it also messes up our emotional state.  People are being killed every day and we see the pictures on the web. This drains and debilitates us.  We need some time to process all this.

Partisan politics are sucking the positivity out of our country, and it drains all of us.

We have less to give.

And climate change is here, and it’s scary.  And we don’t know what to do.  We didn’t travel for business over the last years, and we did okay.  Why not save the cost and the carbon like we did over the last two years?

Respectfully submitted,

Your People

image credit — Nathan

Did you engage today with someone that needed your time and attention, though they didn’t ask? You had a choice to float above it all or recognize that your time and attention were needed.  And then you had a follow-on choice: to keep on truckin’ or engage.  If you recognized they needed your help, what caused you to spend the energy needed to do that?  And if you took the further step to engage, why did you do that? For both questions, I bet the answer is the same – because you care about them and you care about the work. And I bet they know that and I bet you made a difference.

Did you alter your schedule today because something important came up?  What caused you to do that?  Was it about the thing that came up or the person(s) impacted by the thing that came up? I bet it was the latter.  And I bet you made a difference.

Did you spend a lot of energy at work today? If so, why did you do that? Was it because you care about the people you work with? Was it because you care about your customers? Was it because you care enough about yourself to live up to your best expectations? I bet it was all those reasons.  And I bet you made a difference.

Image credit — Dr. Matthias Ripp

When you were wrong, the outcome was different than you thought.

When the outcome was different than you thought, there was uncertainty as the work was new.

When there was uncertainty, you knew there would be learning.

When you were afraid of learning, you were afraid to be wrong.

And when you were afraid to be wrong, you were really afraid about what people would think of you.

Would you rather wall off uncertainty to prevent yourself from being wrong or would you rather try something new?

If there’s a difference between what others think of you and what you think of yourself, whose opinion matters more?

Why does it matter what people think of you?

Why do you let their mattering block you from trying new things?

In the end, hold onto the fact that you matter, especially when you have the courage to be wrong.

“Oh no, what went wrong?” by Bennilover is marked with CC BY-ND 2.0.

When you don’t know what to do, what do you do?  This is a difficult question.

Here are some thoughts that may help you figure out what to do when you really don’t know.

Don’t confuse activity with progress.

Gather your two best friends, go off-site, and define the system as it is.

Don’t ask everyone what they think because the Collective’s thoughts will be diffuse, bland, and tired.

Get outside.

Draw a picture of how things work today.

Get a good meal.

Make a graph of goodness over time.  If it’s still increasing, do more of what you did last time.  If it’s flat, do something else.

Get some exercise.

Don’t judge yourself negatively.  This is difficult work.

Get some sleep.

Help someone with their problem.  The distraction will keep you out of the way as your mind works on it for you.

Spend time with friends.

Try a new idea at the smallest scale. It will likely lead to a better one. Repeat.

Use your best judgment.

Image credit – Andrew Gustar

If there’s one superpower to develop, it’s to learn how to assess a project and get a good feel for when it will launch.

When you want to know how long a project will take, ask this simple question: ‘What must the project team learn before the project can launch?”  By starting with this single question, you will start the discussion that will lead you to an understanding of what hasn’t been done before and where the uncertainty is hiding.  And if there’s one thing that can accelerate a project, it’s defining where the uncertainty is hiding. And knowing this doubly powerful, like a pure two-for-one, because if you know where uncertainty is, by definition, you know where it isn’t. Where the uncertainty isn’t, you can do what you did last time, and because you’ve done it before, you know how long it will take.  No new tools, no new methods, no new analyses, no new machines, no new skillsets, no new anything. And for the remaining elements of the project, well, that’s where the uncertainty is hiding and that’s where you will focus on the learning needed to secure the launch.

But it can be difficult to understand the specific learning that must be done for a project to launch.  One trick I like to use is the Same-But-Different method. It goes like this.  Identify a project that launched (Project A) that’s most similar to the one that will launch next (Project B) and perform a subtraction of sorts.  Declare that Project B (the one you want to launch) is the same as Project A (the one you already launched) but different in specific ways and then define those differences as clearly and tightly as possible.  And where it’s different, that’s where the learning energy must be concentrated.

Same-But-Different sounds simplistic and trivial, but it isn’t.  More than anything, it’s powerful.  For the elements that are the same, you do what you did last time, which is freeing.  And for the small subset if things that are different, you dig in!

Same-But-Different drives deep clarity and extreme focus, which result in blistering progress and blinding effectiveness.

And for some reason unknown to me, asking a team to define the novel elements of a project is at least fifty times more difficult than asking them how Project B is different than Project A.  So, it feels good to the team when they can use Same-But-Different to quickly easily define what’s different and then point directly to the uncertainty.  And once the team knows where the uncertainty is hiding, it’s no longer hiding.

And if there’s one thing a project team likes, it’s knowing where the uncertainty is hiding.

“The same, but different by the Paris Photographic Co. (c.1880)” by pellethepoet is marked with CC BY 2.0.

When you want new thinking or rapid progress, create a small team.

When you have a small team, they manage the handoffs on their own and help each other.

Small teams hold themselves accountable.

With small teams, one member’s problem becomes everyone’s problem in record time.

Small teams can’t work on more than one project at a time because it’s a small team.

And when a small team works on a single project, progress is rapid.

Small teams use their judgment because they have to.

The judgment of small teams is good because they use it often.

On small teams, team members are loyal to each other and set clear expectations.

Small teams coordinate and phase the work as needed.

With small teams, waiting is reduced because the team members see it immediately.

When something breaks, small teams fix it quickly because the breakage is apparent to all.

The tight connections of a small team are magic.

Small teams are fun.

Small teams are effective.

And small teams are powered by trust.

“LEGO Octan pit crew celebrating High Five Day (held every third Thursday of April)” by Pest15 is marked with CC BY-SA 2.0.

Clean-sheet designs are fun, right up until they don’t launch.

When you feel the urge to do a clean-sheet design, go home early.

When you don’t know how to make it better, make it worse and do the opposite.

Without trying, there is no way to know if it will work.

Trying sometimes feels like dying.

But without trying, nothing changes.

Agreement is important, but only after the critical decision has been made.

When there’s 100% agreement, you waited too long to make the decision.

When it’s unclear who the customer is, ask “Whose problem will be solved?”

When the value proposition is unclear, ask ‘What problem will be solved?”

When your technology becomes mature, no one wants to believe it.

When everyone believes the technology is mature, you should have started working on the new technology four years ago.

If your projects are slow, blame your decision-making processes.

Two of the most important decisions: which projects to start and which to stop.

All the action happens at the interfaces, but that’s also where two spans of control come together and chafe.

If you want to understand your silos and why they don’t play nicely together, look at the organizational chart.

When a company starts up, the product sets the organizational structure.

Then, once a company is mature, the organizational structure constrains the product.

At the early stages of a project, there’s a lot of uncertainty.

And once the project is complete, there’s a lot of uncertainty.

“Toys Never Forget” by Alyssa L. Miller is marked with CC BY 2.0.

If you’re asked to be faster, choose to be more effective.  There’s nothing slower than being fast at something that doesn’t matter.

If you’re given a goal to be more productive, instead, improve effectiveness. There’s nothing less productive than making the wrong thing.

If you’re measured on efficiency, focus on effectiveness. Customers don’t care about your efficiency when you ship them the wrong product.

If you’re asked to improve quality, that’s good because quality is an important element of effectiveness.

If you’re asked to demonstrate more activity, focus on progress, which is activity done in an effective way.

If you’re asked to improve your team, ask them how they can be more effective and do that.

Regardless of the question, the answer is effectiveness.

Image credit pbkwee.

When you have no slack time, you can’t start new projects.

When you have no slack time, you can’t run toward the projects that need your help.

When you have no slack time, you have no time to think.

When you have no slack time, you have no time to learn.

When you have no slack time, there’s no time for concern for others.

When you have no slack time, there’s no time for your best judgment.

When there is no slack time, what used to be personal becomes transactional.

When there is no slack time, any hiccup creates project slip.

When you have no slack time, the critical path will find you.

When no one has slack time, one project’s slip ripples delay into all the others.

When you have no slack time, excitement withers.

When you have no slack time, imagination dies.

When you have no slack time, engagement suffers.

When you have no slack time, burnout will find you.

When you have no slack time, work sucks.

When you have no slack time, people leave.

I have one question for you.  How much slack time do you have?

“Hurry up Leonie, we are late…” by The Preiser Project is licensed under CC BY 2.0

When you design something, you create a solution to a collection of problems.  But it goes far beyond creating the solution.  You also must create objective evidence that demonstrates that the solution does, in fact, solve the problems.  And the reason to generate this evidence is to help the organization believe that the solution solves the problem, which is an additional requirement that comes with designing something.  Without this belief, the organization won’t go out to the customer base and convince them that the solution will solve their problems.  If the sales team doesn’t believe, the customers won’t believe.

In school, we are taught to create the solution, and that’s it.  Here are the drawings, here are the materials to make it, here is the process documentation to build it, and my work here is done. But that’s not enough.

Before designing the solution, you’ve got to design the tests that create objective evidence that the solution actually works, that it provides the right goodness and it solves the right problems.  This is an easy thing to say, but for a number of reasons, it’s difficult to do.  To start, before you can design the right tests, you’ve got to decide on the right problems and the right goodness.  And if there’s disagreement and the wrong tests are defined, the design community will work in the wrong areas to generate the wrong value.  Yes, there will be objective evidence, and, yes, the evidence will create a belief within the organization that problems are solved and goodness is achieved.  But when the sales team takes it to the customer, the value proposition won’t resonate and it won’t sell.

Some questions to ask about testing. When you create improvements to an existing product, what is the family of tests you use to characterize the incremental goodness?  And a tougher question: When you develop a new offering that provides new lines of goodness and solves new problems, how do you define the right tests? And a tougher question: When there’s disagreement about which tests are the most important, how do you converge on the right tests?

Image credit — rjacklin1975

If you see a problem, tell someone.  But, also, tell them how you’d like to improve things.

Once you see a problem, you have an obligation to seek a solution.

Complaining is telling someone they have a problem but stopping short of offering solutions.

To stop someone from complaining, ask them how they might make the situation better.

Problems are good when people use them as a forcing function to create new offerings.

Problems are bad when people articulate them and then go home early.

Thing is, problems aren’t good or bad.  It’s our response that determines their flavor.

If it’s your problem, it can never be our solution.

Sometimes the best solution to a problem is to solve a different one.

Problem-solving is 90% problem definition and 10% getting ready to define the problem.

When people don’t look critically at the situation, there are no problems.  And that’s a big problem.

Big problems require big solutions. And that’s why it’s skillful to convert big ones into smaller ones.

Solving the right problem is much more important than solving the biggest problem.

If the team thinks it’s impossible to solve the problem, redefine the problem and solve that one.

You can relabel problems as “opportunities” as long as you remember they’re still problems

When it comes to problem-solving, there is no partial credit. A problem is either solved or it isn’t.

“Fry complaining” by kaibara87