Shipulski On Design

Posts Tagged ‘Lessons Learned’

When new ideas come from the outside, they are dismissed out of hand.  The technical term for this behavior is Not Invented Here (NIH).  Because it was not invented by the party with official responsibility, that party stomps it into dust.  But NIH doesn’t stomp in public; it stomps in mysterious ways.

Wow!  That’s a great idea!  Then, mysteriously, no progress is made and it dies a slow death.

That’s cool! Then there’s a really good reason why it can’t be worked.

That’s interesting!  Then that morphs into the kiss of death.

We never thought of that.  But it won’t scale.

That’s novel!  But no one is asking for it.

That’s terribly exciting! We’ll study it into submission.

That’s incredibly different!  And likely too different.

When the company’s novel ideas die on the vine, they likely die at the hands of NIH. 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.

If a team is not receptive to novel ideas from the outside, it’s because they consider their own ideas sufficiently good to meet their goals.  Things are going well and there’s no reason to adopt new ideas from the outside.  And buried in this description are the two ways to overcome NIH.

The fastest way to overcome NIH is to help a new idea transition from an idea conceived by someone outside the team to an idea created by someone inside the team.  Here’s how that goes.  The idea is first demonstrated by the external team in the form of a functional prototype.  This first step aims to help the internal team understand the new idea.  Then, the first waiting period is endured where nothing happens.  After the waiting period, a somewhat different functional prototype is created by the external team and shown to the internal team.  The objective is to help the internal team understand the new idea a little better.  Then, the second waiting period is endured where nothing happens.  Then, a third functional prototype is created and shown to the internal team.  This time, shortcomings are called out by the external team that can only be addressed by the internal team.  Then, the last waiting period is endured.  Then, after the third waiting period, the internal team addresses the shortcomings and makes the idea their own.  NIH is dead, and it’s off to the races.

The second fastest way to overcome NIH is to wait for the internal team to transition to a team that is receptive to new ideas initiated outside the team.  The only way for a team to make the transition is for them to realize that their internal ideas are insufficient to meet their objectives.  This can only come after their internal ideas are shown to be inadequate multiple times.  Only after exhausting all other possibilities, will a team consider ideas generated from outside the team.

When the external team recognizes the internal team is out of ideas, they demonstrate a functional prototype to the internal team.  And they do it in an “informational” way, meaning the prototype is investigatory in nature and not intended to become the seed of the internal team’s next generation platform.  And as it turns out, it’s only a strange coincidence that the functional prototype is precisely what the internal team needs to fuel the next-generation platform.  And the prototype is not fully wrung out.  And as it turns out, the parts that need to be wrung out are exactly what the external team knows how to do.  And when the internal team needs expertise from the external team to address the novel elements, as it turns out the external team conveniently has the time to help out.

Not Invented Here (NIH) is real.  And it’s a powerful force. And it can be overcome.  And when it is overcome, the results are spectacular.

Image credit — Becky Mastubara

You can’t see if you don’t look.

You can’t look if you’re distracted.

You can’t be distracted if you’re living in the present moment.

You can’t live in the present moment if you’re sad about the past or afraid of the future.

You can’t be sad about the past unless you want it to be different.

You can’t be afraid of the future unless you want to control it.

You can’t want the past to be different if you accept things as they are.

You can’t want to control the future if you accept you have no control over it.

Yet, we want the past to be different and we want to control the future.

When you find yourself wanting the past to be different or wanting to control the future, focus on your breath for a minute or two.  That will bring you back to the present moment.

And if that doesn’t work, go outside and walk in nature for fifteen minutes then quiet yourself and focus on your breath for a minute or two.  That should bring you back to the present moment.

Everything gets better when you’re sitting in the present moment.

If you can’t imagine it, it’s impossible.

But if you can imagine it, at worst it can only be almost impossible.

Who controls your imagination?

What you think about something affects you like it’s true, even when it isn’t.

And what you think is true often isn’t.

Are you responsible for what you think?

If you have two things to do, that’s doable.  So, do them.

And if you have twenty things to do, chose two and do them.

What if getting ten things done in a week is enough?

If the work is good, it’s likely you’re doing it with people you enjoy.

And if you work with people you enjoy, the work gets better.

Which comes first, the good work or the people you enjoy?

If you tell someone what to do and how to do it, they can do it.

But if you’re not there to tell them, they cannot.

Will you always be there?

If you show you care, people know you care.

And if you tell people you care, they’re not sure.

Why not show them so they can be sure?

If you tell the truth, people can work with you even if they don’t share your truth.

But if you sometimes tell the truth, it means sometimes you don’t.

And how does that work?

image credit — Miranda Granche

When you notice someone having a difficult time, take the time to check in with them.  An in-person “Are you okay?” is probably the best way, but a phone call, text, or video chat will also do nicely.

When you’re having a difficult time, when someone notices and checks in you feel a little better.

When someone reacts in an outsized way, use that as a signal to check in with them.  Your check-in can help them realize their reaction was outsized, as they may not know.  It’s likely a deeper conversation will emerge naturally.  This is not a time to chastise or judge, rather it’s a time to show them you care.  An in-person “You got a minute?” followed by a kind “Are you doing okay?” work well in this situation.  But a phone call or text message can also be effective.  The most important thing, though, is you make the time to check in.

When you check in, you make a difference in people’s lives.  And they remember.

Is a simple check-in really that powerful?  Yes. Does it really make a difference?  Yes. But don’t take my word for it.  Run the experiment for yourself.  Here’s the experimental protocol.

1. Pay attention.
2. Look for people who are having a difficult time or people whose behavior is different than usual.
3. When you notice the behavior of (2), make a note to yourself and give yourself the action item to check in.
4. As soon as you can, check in with them. Do it in person, if possible.  If you cannot, call them on the phone or send them a text.  Email is too impersonal. Don’t use it.
   1. To initiate the check-in, use the “You got a minute?” and “Are you doing okay?” language. Keep it simple.
   2. After using the language of (4.1), listen to them. No need to fix anything.  Just listen.  They don’t want to be fixed; they want to be heard.
5. Enjoy the good feeling that comes from checking in.
6. Repeat 1-5, as needed.

After running the experiment, I think you’ll learn that checking in is powerful and helps both parties feel better.  And the more you run the experiment (demonstrate the behavior), the more likely it will spread.

And, just maybe, at some point down the road, someone may reach out to you and ask “You got a minute?” and “Are you doing okay?”.

Image credit — Funk Dooby

When there’s a disagreement, listen before you talk.  And if that doesn’t work, listen more. With this approach, disagreement cannot blossom into a problem.

When there’s a decision to be made, make it.  There are problems with any decision you make, and you might as well learn them as soon as you can.

When there’s a change coming, get people together and talk about what’s coming. One thing to remember – the talking you do before the change is much more meaningful than the talking after the change causes problems.

When an important project is behind schedule, pause the project.  Nothing causes dialog, problem-solving, and movement of resources like pausing an important project.

When person A says one thing to person B and another to person C, call a meeting with A, B, and C and within fifteen minutes the source of the problem will be apparent to all.

When someone doesn’t do what they said they’d do, send them an email asking when they’ll do it.  Then, at the same time every week, “reply all” to your email and ask them when they’ll do it.  That way, they get to see the ever-growing, time-stamped record of their problematic non-performance.

When there’s no owner of the problem, there can be no solution.  And that’s a big problem.

When it’s your problem, solve it.

When someone tries to give you their problem, don’t take it.  Like any gift, if you don’t accept it, the would-be giver still owns it.

When there are no problems, there can be no learning.

Image credit — Rob Oo

Show customers what’s possible. Then listen.

The best projects are small until they’re not.

Today’s location before tomorrow’s destination.

The best idea requires the least effort.

Ready, fire, aim is better than ready, aim, aim, aim.

Be certain about the uncertainty.

Do so you can discuss.

Put it on one page.

Fail often, but call it learning.

Current state before future state.

Say no now to say yes later.

Effectiveness over efficiency.

Finish one to start one.

Demonstrate before asking.

Sometimes slower is faster.

Build trust before you need it.

“Yin & Yang martini” by AMagill is licensed under CC BY 2.0.

Choose the right project. When you say yes to a new project, all the focus is on the incremental revenue the project will generate and none of the focus is on unrealized incremental revenue from the projects you said no to. Next time there’s a proposal to start a new project, ask the team to describe the two or three most compelling projects that they are asking the company to say no to.  Grounding the go/no-go decision within the context of the most compelling projects will help you avoid the real backbreaker where you consume all your product development resources on something that scratches the wrong itch while you prevent those resources from creating something magical.

Choose what to improve. Give your customers more of what you gave them last time unless what you gave them last time is good enough. Once goodness is good enough, giving customers more is bad business because your costs increase but their willingness to pay does not.  Once your offering meets the customers’ needs in one area, lock it down and improve a different area.

Choose how to staff the projects.  There is a strong temptation to run many projects in parallel.  It’s almost like our objective is to maximize the number of active projects at the expense of completing them.  Here’s the thing about projects – there is no partial credit for partially completed projects.  Eight active projects that are eight (or eighty) percent complete generate zero revenue and have zero commercial value.  For your most important project, staff it fully.  Add resources until adding more resources would slow the project.  Then, for your next most important project, repeat the process with your remaining resources.  And once a project is completed, add those resources to the pool and start another project.  This approach is especially powerful because it prioritizes finishing projects over starting them.

“Three Cows” by Sunfox is licensed under CC BY-SA 2.0.

Do you believe in yourself?

Belief in yourself manifests in your actions.  What do your actions say about your belief in yourself?

Belief in yourself doesn’t mean everything will work out perfectly.  It means that you’ll be okay regardless of how things turn out.

When you see someone that doesn’t believe in themselves, how do you feel? And what do you do?

And when that someone is you, how do you feel? And what do you do?

When someone believes in you more than you do, do you believe them?

You reach a critical threshold when your belief in yourself can withstand others’ judgment of you.

When you believe in yourself, you don’t define yourself by what others think of you.

When you love yourself more, you believe in yourself more.

If you had a stronger belief in yourself, what would you do differently?

Try this.  Make a list of three things you’d do differently if you had a stronger belief in yourself.  Then, find one of those special people that believe in you and show them your list.  And whatever they say about your list, believe them.

Image credit — ajari

Nothing changes unless there’s a problem.

In fact, without a problem, there can be no solution.

One of the devious ways to solve your problem is to create conditions for others to think it’s their problem.

Shame on you if you try to get me to solve your problem.

And shame on me if I try to solve your problem.

The best way for the problem to find its rightful owner is to leave the problem unsolved.

But leaving the problem unsolved also increases the pressure on all the innocent non-owners that work near the problem.

Leaving the problem unsolved is like a game of chicken, where the person who flinches first loses.

No one can give you their problem without your consent, but that doesn’t mean they won’t try.

So, when someone tries to give you their problem, put your hands in your pockets.

Leaving the problem unsolved isn’t a sign of non-caring, it’s a sign of higher-level caring.

Leaving the problem unsolved is the only way to pressure the company into the higher-level (and unpleasant) organizational learning of who is not solving their own problems.

“Prepare for Squirting” by Wootang01 is licensed under CC BY-ND 2.0.

Breaking up work into small chunks can be a good way to get things started.  Because the scope of each chunk is small, the cost of each chunk is small making it easier to get approval to do the work.  The chunk approach also reduces anxiety around the work because if nothing comes from the chunk, it’s not a big deal because the cost of the work is so low.  It’s a good way to get started, and it’s a good way to do a series of small chunks that build on each other.  But what happens when the chunks are successful and it’s time to scale up the investment by a factor of several hundred thousand or a million?

The scaling scenario.  When the early work (the chunks) was defined an agreement in principle was created that said the larger investment would be made in a timely way if the small chunks demonstrated the viability of a whole new offering for your customers.  The result of this scenario is a large investment is allocated quickly, resources flow quickly, and the scaling work begins soon after the last chunk is finished. This is the least likely scenario.

The more chunks scenario. When the chunks were defined, everyone was excited that the novel work had actually started and there was no real thought about the resources required to scale it into something meaningful and material.  Since the resources needed to scale were not budgeted, the only option to keep things going is to break up the work into another series of small chunks.  Though the organization sees this as progress, it’s not.  The only thing that can deliver the payout the organization needs is to scale up the work.  The follow-on chunks distract the company and let it think there is progress, when, really, there is only delayed scaling.

The scale next year scenario.  When the chunks were defined, no one thought about scaling so there was no money in the budget to scale.  A plan and cost estimate are created for the scaling work and the package waits to be assessed as part of the annual planning process.  And as the waiting happens, the people that did the early work (the chunks) move on to other projects and are not available to do the scaling work even if the work gets funded next year.  And because the work is new it requires new infrastructure, new resources, new teams, new thinking, and maybe a new company.  All this newness makes the price tag significant and it may require more than one annual planning cycle to justify the expense and start the work.

Scaling a new invention into a full-sized business is difficult and expensive, but if you’re looking to create radical growth, scaling is the easiest and least expensive way to go.

“100 Dollar Bills” by Philip Taylor PT is licensed under CC BY-SA 2.0.

Before you decide which project to start, decide which project you’ll stop.

The best way to stop a project is to finish it.  The next best way is to move the resources to a more important project.

If you find yourself starting before finishing, stop starting and start finishing.

People’s output is finite. Adding a project that violates their human capacity will not result in more completed projects but will cause your best people to leave.

If people’s calendars are full, the only way to start something new is to stop something old.

If you start more projects than you finish, you’re stopping projects before they’re finished.  You’re probably not stopping them in an official way, rather, you’re letting them wither and die a slow death.  But you’re definitely stopping them.

When you start more projects than you finish, the number of active projects increases.  And without a corresponding increase in resources, fewer projects are completed.

The best way to reduce the number of projects you finish is to start new projects.

Make a list of the projects that you stopped over the last year.  Is it a short list?

Make a list of projects that are understaffed and under-resourced yet still running in the background.  Is that list longer?

A rule to live by: If a project is understaffed, staff it or stop it.

If you can’t do that, reduce the scope to fit the resources or stop it.

Would you prefer to complete one project at a time or do three simultaneously and complete none?

When it comes to stopping projects, it’s stopped or it isn’t.  There’s no partial credit for talking about stopping a project.

If you want to learn if a project is worthy of more resources, stop the project.  If the needed resources flow to the project, the project is worthy.  If not, at least you stopped a project that shouldn’t have been started.

People don’t like working on projects where the work content is greater than the resources to do the work.  These projects are a major source of burnout.

If you know you have too many projects, everyone else knows it too.  Stop the weakest projects or your credibility will suffer.

“Circus Renz Berlin, Holland 2011” by dirkjanranzijn is licensed under CC BY-ND 2.0.