Shipulski On Design

Archive for the ‘Decisions’ Category

Here are the questions I ask myself when I’m asked to take on new work….

Do I know what the work is all about?

Is it well-defined?

Would it make a big difference if the work is completed successfully?

Would it make a big difference if it’s not?

Is it clear how to judge if the work is completed successfully?

Is the work important and how do I know?

Is it urgent? (The previous question is far more important to me.)

Is there more important work?

Who would benefit from the work and how do I feel about it?

Would I benefit and how do I feel about it?

Am I uniquely qualified or can others do the work?

Am I interested in the work?

Would I grow from the work?

Who would I work for?

Who would I work with?

Would my career progress?

Would I get a raise?

Would I spend more time with my family?

Would I spend more time in meetings?

Would I travel more?

What does my Trust Network think?

Would I have fun? (I think this is a powerful question.)

These aren’t the questions you should ask yourself, but I hope the list helps you develop your own.

Image credit — broombesoom

Efficient – How do we do more projects with fewer people?

Effective – Let’s choose the right project.

Would you rather do more projects that miss the mark or fewer that excite the customer?

Efficient – How do we finish the project faster?

Effective – Let’s fully staff the project.

Would you rather burn out the project team or deliver on what the customer wants?

Efficient – How do we reduce product cost by 5%?

Effective – Let’s make customers’ lives easier.

Would you rather reduce the cost or delight the customer?

Efficient – How can we go faster?

Effective – Let’s get it right.

Would you rather go fast and break things or get it right for the customer?

Efficient – How many projects can we run in parallel?

Effective – Let’s fully staff the most important projects.

Would you rather get halfway through four projects or complete two?

Efficient – How do we make progress on as many tasks as possible?

Effective – Let’s work on the critical path.

Would you rather work on things that don’t matter or nail the things that do?

Efficient – How can we complete the most tasks?

Effective – Let’s work on the hardest thing first.

Would you rather learn the whole thing won’t work before or after you waste time on the irrelevant?

If there’s a choice between efficiency and effectiveness, I choose effectiveness.

Image credit — Antarctica Bound

We wait because we don’t have enough information to make a decision.

We wait until the decision makes itself because no one wants to be wrong.

We wait for permission because of the negative consequences of being wrong.

We wait to use our judgment until we have evidence our judgment is right.

We wait for support resources because they are spread over too many projects.

We wait for a decision to be made because no one is sure who makes it.

We wait to reduce risk.

We wait to reduce costs.

We wait to move at the speed of trust.

We wait because too many people must agree.

We wait because disagreement comes too slowly.

We wait for disagreement because we don’t subscribe to “clear is kind.”

We wait when decisions are unmade.

We wait because there is insufficient courage to stop the bad projects.

We wait to stop things slowly.

We use waiting as a slow no.

We wait to reallocate resources because even bad projects have momentum.

We wait when we dislike the impending outcome.

We wait for the critical path.

We wait out of fear.

Image credit — Sylvia Sassen

Software may be eating the world, but the hardware elements of a startup’s work define when lunch is served.

Hardware takes longer than software.  With hardware, after the product and its parts are designed, companies are vetted/selected to make the parts; contracts are signed to make the parts; the parts are made; the parts are shipped; the parts are received; the parts are inspected; and the parts are put in their locators.  Then, the manufacturing process is defined, the manufacturing tooling is designed and purchased; the manufacturing documentation is created; the final test system is designed and built; and the parts are assembled into the product. Then, the product is run through final test and tested for robustness.  After it’s learned the manufacturing process created too much variation and the insufficient robustness manifests, the manufacturing process and its documentation are changed to reduce variation; the parts that failed are redesigned, purchased, made, shipped, and received; and the next iteration of the product is built and tested.  This process is repeated until the product is robust and the manufacturing process is repeatable.  This is why hardware takes longer than software.

If the software is done but the hardware isn’t, the software must wait for the hardware and the customer must wait for the finished product. To get the hardware done faster, recognize that redesign loops are part of the game and invest in the capability to iterate quickly.  Line up the suppliers to make parts quickly; keep utilization low on the support resources so they can jump on the work when it arises (think fire stations who can respond quickly when there’s a fire); and avoid part-time resources on the critical path.  There may be other things to focus on, but only after taking care of these three.

Software may be eating the world, but the hardware elements of a startup’s work govern the cost of getting to the dinner table.

Hardware costs more to make than software.  Hardware is made of steel, aluminum, injection molded plastics, and rare earth elements, all of which cost money.  And because startups do things that have not been done before, the materials can be special (costly).  And unlike software, the marginal cost of an incremental unit is non-zero.  With hardware, if you want to make another one you’ve got to buy more of the materials; you have to pay people to make it; you have to buy/build the manufacturing system; you have to buy the measurement systems and engineering infrastructure; and you have to pay people to break-test-fix the product until it’s ready.

What’s a startup to do?

To do hardware faster, focus on learning.  And to do hardware more cost-effectively, focus on learning.

For both time and money, learning efficiency is a good starting point.  The most efficient learning is the learning you don’t have to do, so be ruthless in how you decide what you DON’T learn. Where possible, declare all but the most vital problems as annoyances and save them for later. (Annoyances don’t require learning.)  This will concentrate your precious resources on fewer problems, improve your learning rate, and keep costs to a minimum.

Here’s a good test to decide if the learning is worth learning.  Ask yourself “If we accomplish this learning objective, how will the customer benefit?”  If there is low or no customer benefit, say no to the learning objective.  If there is medium customer benefit, say no to the learning objective.  If there is significant customer benefit, do the learning.

For those learning objectives that make it through the gauntlet, learn what you need to learn, but no more.  To do this, create a formal learning objective: “We want to learn [enter learning objective here].”  With learning objectives, the tighter the better. And define the criteria for decision making: “If the result of the test is [define objective measurement here], we will decide [enter decision here].” With decision criteria, the clearer the better.

Learn effectively, not elegantly.  Be bold, rough, and crude with how you learn.  Design tests that take advantage of the resources you have on hand so you can learn quickly.  If you can run a crude test in one hour and the perfect test will take a week, run three crude tests and be done by the end of the day.

Learn with less confidence and more judgment.  If a wrong decision can be overcome quickly and with low cost, be less confident and use more judgment.

Whether driven by hardware, software, or the integration of both, project completion is governed by the critical path.  And with longer time constants, it’s more likely that the hardware defines the critical path.  The total cost of the project is the sum of the three costs: software, hardware, and integration.  And because hardware requires expensive materials, factories, engineering labs, people to run the tests, and people to make the products, hardware is likely a large percentage of the project costs.

Image credit — Günter Hentschel

In that familiar situation, how did you respond in an unfamiliar way?

Instead of your usual yes, did you say no?

With your regular chair available in the conference room, why not sit in a different one?

Instead of using your right hand to brush your teeth, why not try your left? How would it feel?

When someone misbehaved in a meeting, how did you respond? Or did you?

If no one recognized your different behavior, was it different enough? Why not rerun the experiment?

With the same choices on the menu, what’s in the way of asking for a special order?

Instead of going to the meeting, did you ask someone to go in your place as a growth opportunity?

When you pay attention, you notice more opportunities to demonstrate novelty. Do you pay attention?

If it didn’t create a sensation in your body, did you do anything novel?

When you saw someone respond differently, did they like it when you praised their behavior?

When you have a chance to help someone be successful, why not help them?

When you have the chance to make a different choice, why not make it?

When you have a chance to respond differently, why not do it?

When you have a chance to feel uncomfortable, why not feel it?

One more question for you — What novelty did you demonstrate today?

Image credit — Mike Beales

When we quiet our minds, we can hear our bodies’ old stories in the form of our thoughts.

Pay attention to our bodies and we understand our minds.

Our bodies give answers before our minds know the questions.

If we don’t understand our actions, it’s because our bodies called the ball.

The physical sensations in our bodies are trailheads for self-understanding.

Our bodies’ old stories govern our future actions.

If a cat sits on a hot stove, that cat won’t sit on a hot stove again. That cat won’t sit on a cold stove either.  Our bodies are just like the cat.

Our mouths sing the songs but our bodies write the sheet music.

Our bodies make decisions and then our minds declare ownership.

When we’re reactive, it’s because our bodies recognize the context and trigger the old response.

When a smell triggers a strong memory, that’s our body at work.

Bessel was right. The body keeps the score.

Image credit — Raul AB

Before a design can be accused of having too much material and labor costs, it must be able to meet its functional specifications.  Before that is accomplished, it’s likely there’s not enough material and labor in the design and more must be added to meet the functional specifications.  In that way, it likely doesn’t cost enough.  If the cost is right but the design doesn’t work, you don’t have a viable offering.

Before the low-cost manufacturing process can be chosen, the design must be able to do what customers need it to do.  If the design does not yet meet its functional specification, it will change and evolve until it can.  And once that is accomplished, low-cost manufacturing processes can be selected that fit with the design.  Sure, the design might be able to be subtly adapted to fit the manufacturing process, but only as much as it preserves the design’s ability to meet its functional requirements. If you have a low-cost manufacturing process but the design doesn’t meet the specifications, you don’t have anything to sell.

Before a product can function robustly over a wide range of operating conditions, the prototype design must be able to meet the functional requirements at nominal operating conditions.  If you’re trying to improve robustness before it has worked the first time, your work is out of sequence.

Before you can predict when the project will be completed, the design must be able to meet its functional requirements.  Before that, there’s no way to predict when the product will launch. If you advertise the project completion date before the design is able to meet the functional requirements, you’re guessing on the date.

When your existing customers buy an upgrade package, it’s because the upgrade functions better.  If the upgrade didn’t work better, customers wouldn’t buy it.

When your existing customers replace the old product they bought from you with the new one you just launched, it’s because the new one works better.  If the new one didn’t work better, customers wouldn’t buy it.

Function first, no exceptions.

Image credit — Mrs Airwolfhound

Finishing a project is usually associated with completing all the deliverables.  But in the real world there are other flavors of finishing that come when there is no reason or ability to complete all the deliverables or completing them will take too long.

Everyone’s favorite flavor of finishing is when all the deliverables are delivered and sales of the new product are more than anticipated.  Finishing this way is good for your career.  Finish this way if you can.

When most of the deliverables are met, but some of them aren’t met at the levels defined by the specification, the specification can be reduced to match the actual performance and the project can be finished.  This is the right thing to do when the shortfall against the specification is minor and the product will still be well received by customers.  In this case, it makes no sense to hold up the launch for a minor shortfall. There is no shame here.  It’s time to finish and make money.

After working on the project for longer than planned and the deliverables aren’t met, it’s time to finish the project by stopping it.  Though this type of finishing is emotionally difficult, finishing by stopping is far better than continuing to spend resources on a project that will likely never amount to anything.  Think opportunity cost.  If allocating resources to the project won’t translate into customer value and cash, it’s better to finish now so you can allocate the resources to a project that has a better chance of delivering value to you and your customers.

Before a project is started in earnest and the business case doesn’t make sense, or the commercial risk is too high, or the technical risk is too significant, or it’s understaffed, finish the project by not starting it. This is probably the most important type of finishing you can do.  Again, think of opportunity cost.  By finishing early (before starting) resources can start a new project almost immediately and resources were prevented from working on a project that wasn’t going to deliver value.

Just as we choose the right way to start projects and the right way to run them, we must choose the right way to finish them.

Image credit — majiedqasem

What does your team do when you’re not there?  Do they make decisions or wait for you to come back so you can make them?

If your team makes an important decision while you’re out of the office, do you support or criticize them? Which response helps them stand taller? Which is most beneficial to the longevity of the company?

If other teams see your team make decisions while you are on vacation, doesn’t that make it easier for those other teams to use their good judgment when their leader is on vacation?

If a team waits for their leader to return before making a decision, doesn’t that slow progress?  Isn’t progress what companies are all about?

When you’re not in the office, does the organization reach out directly to your team directly? Or do they wait until they can ask your permission?  If they don’t reach out directly, isn’t that a reflection on you as the leader? Is your leadership helping or hindering progress?  How about the professional growth of your team members?

Does your team know you want them to make decisions and use their best judgment? If not, tell them.  Does the company know you want them to reach out directly to the subject matter experts on your team? If not, tell them.

If you want your company to make progress, create the causes and conditions for good decisions to be made without you.

Image credit – Conall

We use our previous experiences as context for decisions we make in the present.  When we have a bad experience, the experience-context pair gets stored away in our memory so that we can avoid a similar bad outcome when a similar context arises.  And when we have a good experience, or we’re successful, that memory-context pair gets stored away for future reuse. This reuse approach saves time and energy and, most of the time keeps us safe.  It’s nature’s way of helping us do more of what works and less of what doesn’t.

The system works well when we correctly match the historical context with today’s context and the system’s fundamentals remain unchanged.  There are two potential failure modes here.  The first is when we mistakenly map the context of today’s situation with a memory-context pair that does not apply.  With this, we misapply our experience-based knowledge in a context that demands different knowledge and different decisions.  The second (and more dangerous) failure mode is when we correctly identify the match between past and current contexts but the rules that underpin the context have changed.  Here, we feel good that we know how things will turn out, and, at the same time, we’re oblivious to the reality that our experience-based knowledge is out of date.

“If a cat sits on a hot stove, that cat won’t sit on a hot stove again. That cat won’t sit on a cold stove either. That cat just don’t like stoves.”  Mark Twain

If you tried something ten years ago and it failed, it’s possible that the underpinning technology has changed and it’s time to give it another try.

If you’ve been successful doing the same thing over the last ten years, it’s possible that the underpinning business model has changed and it’s time to give a different one a try.

“Hissing cat” by Consumerist Dot Com is licensed under CC BY 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