Shipulski On Design

If you don’t believe in the project, the team will sense it; energy will drain from the project; and no one will want to work the project.

If you don’t believe in the project, you can’t make yourself believe in the project.

If you don’t believe in the project, you can’t fool people and make them believe you believe in the project.  Your disbelief will flow from your pores like a bad smell.

If you don’t believe in the project, your disbelief will weaken an already weak project.

If you don’t believe in the project, your disbelief can twist a good project into a bad one.

If you don’t believe in the project, it may not be the right project, but you are not the right person to run it.

If you don’t believe in the project, but the company still wants you to run it, the worst thing for the project is for you to run it; the worst thing for the company is for you to run it; and the worst thing for your career is to refuse to run it.

If from the start you think the project will fail, tell the right people why you think it will fail. If after telling them why you think the project will fail, they then ask you to run the project, you have a problem and a choice.  Your problem is you’re the wrong person to run the project.  Your choice is to run the project into the ground or take the lumps for not running it into the ground.

My choice is to give someone else an opportunity to run the project.  I think life is too short to run a project you don’t believe in.

Image credit — Bennilover

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

Do the project right or do the right project – which would you choose?

If you improve time to market, the only thing that improves is time to market.  How do you feel about that?

Customers pay for things that make their lives easier.  Time to market doesn’t do that.

There’s no partial credit with new product development projects.  If the product isn’t 100% ready for sale, it’s 0% ready.

If you made 1/8^th progress on 8 projects, you made zero progress. But you did consume valuable resources.

If you made 100% progress on one project, you made progress.

When you have too many projects, you get too few done.

If you don’t know how many projects your company has, you have too many.

Would you rather choose the right project and run it inefficiently or choose the wrong project and run it efficiently?

When you choose the wrong project but run it efficiently, that’s called efficient ineffectiveness.

You can save several weeks making sure you choose the right project by starting the project too soon and running the wrong one for two years.

If your projects are slow, it’s likely the support functions are too highly utilized.  Add capacity to keep their peak utilization below 85%.

When shared resources are sized appropriately, they’re underutilized most of the time.  Think fire station and firefighters – when there’s a fire they respond quickly, and when there’s no fire they improve their skills so they can fight the next one better than the last.

If your projects are slow, check to see if you have resources on the critical path that work part-time.  Part-time resources support multiple projects and don’t work full-time on your project.  And you can’t control when they work on your project.  There’s no place for that on the critical path.

If you’re thinking about using part-time resources on the critical path, don’t.

Know where the novelty is and work that first.  And before you can work on the novelty you’ve got to know where it is.

You can have too little novelty, meaning the new product is so much like the old one there’s no need to launch it.  Mostly, though, projects have too much novelty.

If you are working on a clean-sheet design, there is no such thing.  There are no green-field projects.  All projects are brown-field projects. It’s just that some are browner than others.

Novelty generates problems and problems take three times longer to solve than anyone thinks.  To reduce the number of problems, declare as many as possible as annoyances.  Unlike problems, annoyances don’t have to be solved by the project.  Remember, it’s okay to save some work for the next project.

Even though you have a product development process, that process is powered by people.  People make it work and people make it not work.  If you get one thing right, get the people part right.

Image credit – claudia gabriela marques

If you try to change what you cannot, your trying will not bring about change. But it will bring about 100% frustration, 100% dissatisfaction, 100% missed expectations, 0% progress, and, maybe, 0% employment.

Here’s a rule: If success demands you must change what you cannot, you will be unsuccessful.

If you try to change something you cannot change but someone else can, you will be unsuccessful unless you ask them for help.  That part is clear.  But here’s the tricky part – unless you know you cannot change it and they can, you won’t know to ask them.

If you know enough to ask the higher power for help and they say no but you try to change it anyway, you will be unsuccessful.  I don’t think that needed to be said, but I thought it important to overcommunicate to keep you safe.

Here’s the money question – How do you know if you can change it?

Here’s another rule: If you want to know if you can change something, ask.

If the knowledgeable people on the project say they cannot change it, believe them.  Make a record of the assessment for future escalation, define the consequences, and rescope the project accordingly.  Next, search the organization (hint – look north) for someone with more authority and ask them if they can grant the authority to change it.  If they say no, document their decision and stick with the rescoped project plan.  If they say yes, document their decision and revert to the original project plan.

If you do one thing tomorrow, ask your project team if success demands they change something they cannot.  I surely hope their answer is no.

Image credit — zczillinger

When you do something for a long time, the physical and mental muscles you exercise get stronger and you get better at that activity.  But where the muscles you use get stronger, the ones you don’t use atrophy and you get worse at all the other things.

When you do something for a long time, people see you as someone who does that one thing.  And because it’s easy for everyone, that same old work lands on your desk and the system reinforces the problem.  The company knows it will get done quickly and well, and because you’ve done it before, it’s easy for you.  But what’s good and easy in the short term may not be so good and easy in the long term.  When you do what you did last time, you get stale and you don’t grow. It’s the same for your career.  When they see only one slice of you, there’s a long-term downside

When you look at the same old problems for a long time, you see only the same old solutions.  And more troubling, you’re blind to your blindness.  If you’ve solved the same family of problems for the last decade, you won’t see the new solutions made possible by developments in new areas.  And more troubling, you won’t see that it’s time to solve new problems because the same old problems find your desk.

What’s a dinosaur to do?

Pair up with a younger person who wants to learn and teach them how to solve problems.  Their energy will rub off on you and your smarts will contaminate them.  A fair trade for both.  Teach them how to understand the situation as it is – both in the problem space and political space.  Teach them how to read the tea leaves and hear what’s unsaid.  You’ll learn you know far more than you thought and you’ll get to show your whole self to your younger partner in crime.

Put them in a position to succeed and take pride in their success.  Give them credit and revel in their development. Help them stretch and protect them from breaking. Keep them safe and help them live dangerously.  Provide air cover as only you can, and do it with plausible deniability.  You will get great joy (and energy!) from this.

When you’re low on energy, help people. When you’re down in the dumps, take someone to lunch and listen to them.  When you’re tired of the same old work, help people do new work.  And when you want to feel good about what you know, teach people.

At this point in your career, you have all you need and plenty to spare.  Ground yourself in your abundance and give it away.  Everyone will be better for it, including you.

Image credit — Steve Walker

When you catch someone doing good work, do you praise them?  If not, why not?

Praise is best when it’s specific – “I think it was great when you [insert specific action here].”

If praise isn’t authentic, it’s not praise.

When you praise specific behavior, you get more of that great behavior.  Is there a downside here?

As soon as you see praise-worthy behavior, call it by name. Praise best served warm.

Praise the big stuff in a big way.

Praise is especially powerful when delivered in public.

If praise feels good when you get it, why not help someone else feel good and give it?

If you make a special phone call to deliver praise, that’s a big deal.

If you deliver praise that’s inauthentic, don’t.

Praise the small stuff in a small way.

Outsized praise doesn’t hit the mark like the real deal.

There can be too much praise, but why not take that risk?

If praise was free to give, would you give it?  Oh, wait.  Praise is free to give.  So why don’t you give it?

Praise is powerful, but only if you give it.

Image credit — Llima Orosa

If you have nothing to say, be the person that doesn’t say it.

If you’re not the right person to do it, you’re also the right person not to do it.  Why is it so difficult for to stop doing what no longer makes sense?

If it made sense to do it last time, it’s not necessarily the right thing to do this time, even if it was successful last time.  But if it was successful last time, it will be difficult to do something different this time.

If we always standardize on what we did last time, mustn’t this time always be the same as last time? And musn’t next time always be the same as this time?

If it’s new, it’s scary.  And if it’s scary, it’s bad.  And we don’t like to get in trouble for doing bad things. And that’s why it’s difficult to do new things.

Deming said to “Drive out fear.” But that’s scary.  What are the attributes of the people willing to face the fear and demonstrate that fear can be overcome?  At your company are they promoted? Do they stay? Do they leave?

Without someone overcoming their internal fear, there can be no change.

If a new thing is blocked from commercialization because it wasn’t invented here, why not reinvent it just as it is, declare ownership, and commercialize it?

If prevention is worth a pound of cure, why do people that put out forest fires get the credit while those that prevent them go unnoticed? Does that mean your career will benefit it you start small fires in private and put them out quickly for all to see?

If you always do what’s best for your career, that’s not good for your career.

When you do something that’s good for someone’s career but comes at the expense of yours, that’s good for your career.

Why not say nothing when nothing is the right thing to say?

Why not say no when no is the right thing to say?

Why not do something new even though it’s different than what was successful last time?

Why not demonstrate fearlessness and break the trail for others?

Why not be afraid and do it anyway?

Why not build on something developed by another team and give them credit?

Why not do what’s right instead of doing what’s right for your career?

Why not do something for others?  As it turns out, that’s the best thing to do for yourself.

Image credit — Steve Hammond

The Idealized Future State (IFS) is all the rage these days.  The idea behind it is the team defines the IFS so it can then define the steps needed to achieve it.  The IFS is just what it says it is – a description of the perfect state of our future affairs.  It defines what things will look like and how things will go when the system evolves in the best imaginable way.  It describes a future perfection.  Some troubling questions should come to mind.  Here are some.

How is “best” defined? What if there is disagreement on multiple bests? Whose best becomes bestest? Once the best best is chosen, can’t it be bested by a better best?

If there were two IFSs at a social event, what would you ask them to figure out which one was an almost-IFS and which was the ideal-IFS?  And if both were imposter-IFSs, how could you tell?

Since the IFS is supposed to predict the future and we can’t predict the future, why do we think it’s a good idea to ask people to predict the future?

If it takes imagination to create an IFS and imagination is not bound by reality, isn’t it likely that an imagined idealized future is not possible to achieve?  And won’t a project that must achieve an impossible future likely to run long and miss its launch window?

Wouldn’t an Achievable Future State (AFS) be a little less bad?  But who gets to choose what is achievable and what is not?  And how could they know?

Instead of fixating on an IFS as the ultimate destination, why not agree on the situation as it is and locate yourself within that context?  Why not start the journey with a sense of direction?*

Why not understand the situation as it is and do the next right thing?*

Why not run small experiments in parallel and do more of what works and less of what doesn’t?*

*Thanks to Dave Snowden for this language.

Here are the top blog posts (in descending order) from the previous twelve months.  The short descriptions give some context for the posts and my intentions for writing them.

Thanks for reading.

Mike

When You Have Enough… The post describes behaviors that demonstrate you have enough and the benefits of having enough.  And it calls out some problematic consequences when you don’t think you have enough. The main point of the post can be summarized in one sentence – When you have enough, it’s because you’ve decided you have enough. Enough of what, you ask?  Well, I left that up to you.

Overcoming Not Invented Here (NIH), The Most Powerful Blocker of Innovation.  With innovation, sometimes the novelty threatens which causes the Establishment to reject new ideas.  The post described what NIH looks like so you could spot it at twenty paces.  Here’s a summary of the post in three sentences.  If you can’t understand why a novel idea never made it out of the lab, investigate the crime scene and you may find NIH’s fingerprints.  If customers liked the new idea yet it went nowhere, it could be NIH was behind the crime. If it makes sense, but it doesn’t make progress, NIH is the prime suspect.

Is The Timing Right? I was surprised that this post was popular.  The idea behind the post was to give examples of being too late and being too early so you could dial in the timing of your work.  I thought the bias toward accelerating everything, pulling in projects, and doing everything in parallel would contradict the idea of a right time to do the work.  But, people liked this one.

Stop, Start, Continue Gone Bad.  This post was intended to poke fun the fundamental problem that we start far too many projects and finish too few or finish too slowly.  I introduced the dangerous variant of Stop, Start, Continue called Start, Start, Continue and described its consequences.  To battle that variant, I introduced the powerful antidote called Stop, Stop, Stop.

When you say yes to one thing, you say no to another.  In the heat of battle, we want to make progress but we forget that our and our company’s capacity is limited.  With this post I wanted to describe “opportunity cost” with straightforward yes-no language to help us remember to say no when yes is not the right answer. And I proposed a system to help do just that.  Here’s the first step — Open your work calendar and move one month into the future.  Create a one-hour recurring meeting with yourself.  You just created a timeslot where you said no in the future to unimportant things and said yes in the future to important things.

How To Grow Talent. The objective of this sparse post was to give examples of how to use the work itself to help people grow and to show what a natural progression of growth can look like.

Image credit — Mike Beales

Credibility built – when the situation is not good, you say “the situation is not good.”  And when things went poorly you say “things went poorly.”

Trust built – when things go well you give away the credit.

Credibility built – when you provide a controversial perspective and three years later it turns out you were right.

Trust built – when you share your frustrations in confidence.

Credibility built – when you ground your argument in facts, especially inconvenient ones.

Trust built – when you say “I will keep that in confidence” and you do.

Credibility built – when you don’t know, you say “I don’t know.”

Trust built – when you do something that benefits others but comes at your own expense.

Credibility destroyed – when you tell people things are one way when they know it’s the other.

Trust destroyed – when you respond from a hardened heart.

Credibility destroyed – when you tell partial truths.

Trust destroyed – when you avoid doing the right thing.

Credibility and trust are a powerful one-two punch, but only if you build them.

Image credit — _Veit_