Shipulski On Design

Archive for the ‘Risk’ Category

Product cost reduction is a good thing.

Too much focus on product cost reduction prevents product enhancements, blocks new customer value propositions, and stifles top-line growth.

Voice of the Customer (VOC) activities are good.

Because customers don’t know what’s possible, too much focus on VOC silences the Voice of the Technology (VOT), blocks new technologies, and prevents novel value propositions.  Just because customers aren’t asking for it doesn’t mean they won’t love it when you offer it to them.

Standard work is highly effective and highly productive.

When your whole company is focused on standard work, novelty is squelched, new ideas are scuttled, and new customer value never sees the light of day.

Best practices are highly effective and highly productive.

When your whole company defaults to best practices, novel projects are deselected, risk is radically reduced (which is super risky), people are afraid to try new things and use their judgment, new products are just like the old ones (no sizzle), and top-line growth is gifted to your competitors.

Consensus-based decision-making reduces bad decisions.

In domains of high uncertainty, consensus-based decision-making reduces projects to the lowest common denominator, outlaws the use of judgment and intuition, slows things to a crawl, and makes your most creative people leave the company.

Contrary to Mae West’s maxim, too much of a good thing isn’t always wonderful.

Image credit — Krassy Can Do It

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

If there is no problem, it is too soon for a solution.

But when there is consensus on a problem, it may be too late to solve it.

If a powerful protector of the Status Quo is to retire in a year, it may be too early to start work on the most important sacrilege.

But if the sacrilege can be done under cover, it may be time to start.

It may be too soon to put a young but talented person in a leadership position if the team is also green.

But it may be the right time to pair the younger person with a seasoned leader and move them both to the team.

When the business model is highly profitable, it may be too soon to demonstrate a more profitable business model that could obsolete the existing one.

But new business models take a long time to gestate and all business models have half-lives, so it may be time to demonstrate the new one.

If there is no budget for a project, it is too soon for the project.

But the budget may never come, so it is probably time to start the project on the smallest scale.

When the new technology becomes highly profitable, it may be too soon to demonstrate the new technology that makes it obsolete.

But like with business models, all technologies have half-lives, so it may be time to demonstrate the new technology.

The timing to do new work or make a change is never perfect.  But if the timing is wrong, wait.  But don’t wait too long.

If the timing isn’t right, adjust the approach to soften the conflict, e.g., pair a younger leader with a seasoned leader and move them both.

And if the timing is wrong but you think the new work cannot wait, start small.

And if the timing is horrifically wrong, start smaller.

Doing what you did last works well, right up until it doesn’t.

When you put 100% effort into doing what you did last time and get 80% of the output of last time, it’s time to do something different next time.

If it worked last time, but the environment or competition has changed, chances are it won’t work this time.

You can never step in the same river twice, and it’s the same with best practices.

Doing what you did last time is predictable until it isn’t.

The cost of trying the same thing too often is the opportunity cost of unlearned learning, which only comes from doing new things in new ways.

Our accounting systems don’t know how to capture the lost value due to unlearned learning, but your competition does.

Doing what you did last time may be efficient, but that doesn’t matter when it becomes ineffective.

Without new learning, you have a tired business model that will give you less year on year.

If you do what you did last time, you slowly learn what no longer works, but that’s all.

The best practice isn’t best when the context is different.

It’s not okay to do what you did last time all the time.

If you always do what you did last time, you don’t grow as a person.

If you do what you did last time, there are no upside surprises but there may be downside surprises.

Doing what you did last time is bad for your brain and your business.

How much of your work is repeating what you did last time? And how do you feel about that?

If you are tired of doing what you did last time, what are you going to do about it?

Might you sneak in some harmless novelty when no one is looking?

Might you conspire to try something new without raising the suspicion of the Standard Work Police?

Might you run a small experiment where the investment is small but the learning could be important?

Might you propose trying something new in a small way, highlighting the potential benefit and the safe-to-fail nature of the approach?

Might you propose small experiments run in parallel to increase the learning rate?

Might you identify an important problem that has never been solved and try to solve it?

Might you come up with a new solution that radically grows company profits?

Might you create a solution that obsoletes your company’s most profitable offering?

Might you bring your whole self to your work and see what happens?

Image credit – Marc Dalmulder

When you see something, do you care enough to say something?

If you disagree, do you care enough to say it out loud?

When the emperor has no clothes, do you care enough to hand them a cover-up?

Cynicism is grounded in caring.  Do you care enough to be cynical?

Agreement without truth is not agreement.  Do you care enough to disagree?

Violation of the status quo creates conflict.  Do you care enough to violate?

If you care, speak your truth.

“Great Grey Owl (Strix nebulosa)” by Bernard Spragg is marked with CC0 1.0.

When choosing projects there are two competing questions: Is it big enough? And, is it small enough? The project must be big enough to generate the profits required by the company’s growth objectives.  Larger growth objectives require larger projects.  Yet the project has to be small enough to be completed within the time constraints defined by the growth objectives.  Tighter time constraints require smaller projects.

When the projected revenue generated by the candidate project is less than what’s needed to meet the growth objectives, the project is deemed “not big enough.”  But what if the candidate project is the largest project that the project team can imagine? Does that say something about the project team’s imagination or the growth objectives?  Open question: How do tell the difference between a project that is too small to meet the growth objectives and growth objectives that demand projects larger than the project team’s imagination?

When the projected launch date of the candidate project is later than the date of first revenue defined in the growth plan, the project plan is deemed “too long.”  The team is then asked to sharpen their pencils and return with a launch date that meets the revenue timeline.  And when the revised schedule also violates the revenue timeline, the project is deemed “too big.” Open question: How do you tell the difference between a project that is too big to meet the revenue timeline and a revenue timeline that is too stringent to allow a project of sufficient size?

Theoretically, there are candidate projects that are big enough to meet the growth objectives and small enough that their launch dates meet revenue timelines.  But in practice, candidate projects are either too small to meet growth objectives or too large to meet revenue timelines.  And, yes, I have seen candidate projects that are both too small and too large.  But this says more about the growth objectives, revenue timelines, and the number of projects that run concurrently (too few resources spread over too many projects).

Growth objectives are good, and so are projects that fit with the team’s capabilities to deliver.  Incremental revenue that comes sooner rather than later is good.  And so are project timelines that are governed by the work content, resources applied to the projects, and good product development practices.

Truth is, we need it all – projects that deliver the sizzle that sells and projects that launch sooner rather than later.  And year-on-year, we need to get better at delivering on all of it.  And the best way I know to do all that is to ritualistically invest in the people that do the work and the tools they use.

“Horse Yin and Yang” by onecog2many is licensed under CC BY 2.0.

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.

Your core business, the long-standing business that has made you what you are, is both your greatest strength and your greatest weakness.

The Core generates the revenue, but it also starves fledgling businesses so they never make it off the ground.

There’s a certainty with the Core because it builds on success, but its success sets the certainty threshold too high for new businesses.  And due to the relatively high level of uncertainty of the new business (as compared to the Core) the company can’t find the gumption to make the critical investments needed to reach orbit.

The Core has generated profits over the decades and those profits have been used to create the critical infrastructure that makes its success easier to achieve.  The internal startup can’t use the Core’s infrastructure because the Core doesn’t share.  And the Core has the power to block all others from taking advantage of the infrastructure it created.

The Core has grown revenue year-on-year and has used that revenue to build out specialized support teams that keep the flywheel moving.  And because the Core paid for and shaped the teams, their support fits the Core like a glove.  A new offering with a new value proposition and new business model cannot use the specialized support teams effectively because the new offering needs otherly-specialized support and because the Core doesn’t share.

The Core pays the bills, and new ventures create bills that the Core doesn’t like to pay.

If the internal startup has to compete with the Core for funding, the internal startup will fail.

If the new venture has to generate profits similar to the Core, the venture will be a misadventure.

If the new offering has to compete with the Core for sales and marketing support, don’t bother.

If the fledgling business’s metrics are assessed like the Core’s metrics, it won’t fly, it will flounder.

If you try to run a new business from within the Core, the Core will eat it.

To work effectively with the Core, borrow its resources, forget how it does the work, and run away.

To protect your new ventures from the Core, physically separate them from the Core.

To protect your new businesses from the Core, create a separate budget that the Core cannot reach.

To protect your internal startup from the Core, make sure it needs nothing from the Core.

To accelerate the growth of the fledgling business, make it safe to violate the Core’s first principles.

To bolster the capability of your new business, move resources from the Core to the new business.

To de-risk the internal startup, move functional support resources from the Core to the startup.

To fund your new ventures, tax the Core.  It’s the only way.

“Core Memory” by JD Hancock is licensed under CC BY 2.0

For work that has not been done before, there’s no right answer.  The only wrong answer is to say “no” to trying something new.  Sure, it might not work.  But, the only way to guarantee it won’t work is to say no to trying.

If innovation projects fail nine out of ten times, you can increase the number of projects you try or you can get better at choosing the projects to say no to.  I suggest you say learn to say yes to the one in ten projects that will be successful.

If you believe that nine out of ten innovation projects will fail, you shouldn’t do innovation for a living.  Even if true, you can’t have a happy life going to work every day with a ninety percent chance of failure.  That failure rate is simply not sustainable.  In baseball, the very best hitters of all time were unsuccessful sixty percent of the time, yet, even they focused on the forty percent of the time they got it right.  Innovation should be like that.

If you’ve failed on ninety percent of the projects you’ve worked on, you’ve probably been run out of town at least several times.  No one can fail ninety percent of the time and hold onto their job.

If you’ve failed ninety percent of the time, you’re doing it wrong.

If you’ve failed ninety percent of the time, you’ve likely tried to solve the wrong problems.  If so, it’s time to learn how to solve the right problems.  The right problems have two important attributes: 1) People will pay you if they are solved. 2) They’re solvable.  I think we know a lot about the first attribute and far too little about the second. The problem with solvability is that there’s no partial credit, meaning, if a problem is almost solvable, it’s not solvable. And here’s the troubling part: if a problem is almost solved, you get none of the money.  I suggest you tattoo that one on your arm.

As a subject matter expert, you know what could work and what won’t.  And if you don’t think you can tell the difference, you’re not a subject matter expert.

Here’s a rule to live by: Don’t work on projects that you know won’t work.

Here’s a corollary: If your boss asks you to work on something that won’t work, run.

If you don’t think it will work, you’re right, even if you’re not.

If it might work, that’s about right. If it will work, let someone else do it. If it won’t work, run.

If you’ve got no reason to believe it will work, it won’t.

If you can’t imagine it will work, it won’t.

If someone else says it won’t work, it might.

If someone else tries to convince you it won’t work, they may have selfish reasons to think that way.

It doesn’t matter if others think it won’t work. It matters what you think.

So, what do you think?

If you someone asks you to believe something you don’t, what will you do?

If you try to fake it until you make it, the Universe will make you pay.

If you think you can outsmart or outlast the Universe, you can’t.

If you have a bad feeling about a project, it’s a bad project.

If others tell you that it’s a bad project, it may be a good one.

Only you can decide if a project is worth doing.

It’s time for you to decide.

“Good example of Crossfit Weight lifting – In Crossfit Always lift until you reach the point of Failure or you tear something” by CrossfitPaleoDietFitnessClasses is licensed under CC BY 2.0

Success demands people do what they did last time.

Success blocks fun.

Success walls off all things new.

Success has a half-life that is shortened by doubling down.

Success eats novelty for breakfast.

Success wants to scale, even when it’s time to obsolete itself.

Success doesn’t get caught from behind, it gets disrupted from the bottom.

Success fuels the Innovator’s Dilemma.

Success has a short attention span.

Success scuttles things that could reinvent the industry.

Success frustrates those who know it’s impermanent.

Success breeds standard work.

Success creates fear around making mistakes.

Success loves a best practice, even after it has matured into bad practice.

Success doesn’t like people with new ideas.

Success strangles.

Success breeds success, right up until the wheels fall off.

Success is the antidote to success.

“20204-roots strangle bricks” by oliver.dodd is licensed under CC BY 2.0

If you want to make a difference, build trust.

If you want to build trust, do a project together.

If you want to build more trust, help the team do work they think is impossible.

If you want to build more trust, contribute to the project in the background.

If you want to build more trust, actively give credit to others.

If you want to build more trust, deny your involvement.

If you want to create change, build trust.

If you want to build trust, be patient.

If you want to build more trust, be more patient.

If you want to build more trust, check your ego at the door so you can be even more patient.

If you want to have influence, build trust.

If you want to build trust, do something for others.

If you want to build more trust, do something for others that keeps them out of trouble.

If you want to build more trust, do something for others that comes at your expense.

If you want to build more trust, do it all behind the scenes.

If you want to build more trust, plead ignorance.

If you want the next project to be successful, build trust.

If you want to build trust, deliver what you promise.

If you want to build more trust, deliver more than you promise.

If you want to build more trust, deliver more than you promise and give the credit to others.

If you want deep friendships, build trust.

If you want to build trust, give reinforcing feedback.

If you want to build more trust, give reinforcing and correcting feedback in equal amounts.

If you want to build trust, give reinforcing feedback in public and correcting feedback in private.

If you want your work to have meaning, build trust.

“[1823] Netted Pug (Eupithecia venosata)” by Bennyboymothman is licensed under CC BY 2.0