Shipulski On Design

Archive for February, 2022

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