Shipulski On Design

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.

When you spend time with a group in person, you get to know them in ways that can’t be known if you spend time with them using electronic means.  When meeting in person, you can tell when someone says something that’s difficult for them.  And you can also tell when that difficulty is fake.  When using screens, those two situations look the same, but, in person, you know they are different. There’s no way to quantify the value of that type of discernment, but the value borders on pricelessness.

When people know you see them as they really are, they know you care.  And they like that because they know your discernment requires significant effort.  Sure, at first, they may be uncomfortable because you can see them as they are, but, over time, they learn that your ability to see them as they are is a sign of their importance.  And there’s no need to call this out explicitly because all that learning comes as a natural byproduct of meeting in person.

And the game changes when people know you see them (and accept them) for who they are. The breadth of topics that can be discussed becomes almost limitless.  Personal stories flow; family experiences bubble to the surface; misunderstandings are discussed openly; vulnerable thoughts and feelings are safely expressed; and trust deepens.

I think we’ve forgotten the power of working together in person, but it only takes three days of in-person project work to help us remember.  If you have an important project deliverable, I suggest you organize a three-day, in-person event where a small group gets together to work on the deliverable.  Create a formal agenda where it’s 50% work and 50% not work.  (I’ve found that the 50% not work is the most valuable and productive.)  Make it focused and make it personal.  Cook food for the group. Go off-site to a museum. Go for a hike.  And work hard.  But, most importantly, spend time together.

Things will be different after the three-day event.  Sure, you’ll make progress on your project deliverable, but, more importantly, you’ll create the conditions for the group to do amazing work over the next five years.

“Elephants Amboseli” by blieusong is licensed under CC BY-SA 2.0.

If there’s no problem, there can be no solution.

If there’s no dissatisfaction, there can be no change.

If there’s no caring, there can be no disagreement, though there can be arguments.

If there is a wanting for things to be different, there can be no happiness, though there will be suffering.

If there’s no room for objection, there’s no contract for meeting objectives.

If there’s a truth untold, there can be no closeness.

If there’s no self-love, there can be no perseverance.

If there is no uncertainty, there can be no learning.

If there is no humility, there can be no change.

If there’s no tolerance for unpredictability, there can be no novelty.

If there’s no inefficiency, there is no adaptability.

If there’s no slack, there’s no room for creativity.

If there’s no room for judgment, there is no trust.

If there’s no trust, there’s no future.

“Gaps” by Mr Moss is licensed under CC BY 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.

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.

If the student has no interest, they are not yet a student and it’s not yet time for learning.

Learning comes hard, especially when it’s not wanted.

The teacher that tries to teach a student that’s not yet a student is not yet a teacher.

There can be no teacher without a student.

If there’s no doing, there’s no learning.  And it’s the same if there’s no theory.

Apprenticeship creates deep learning, but it takes two years.

Learning is inefficient, but it’s far more efficient than not learning.

When you know the student is ready, turn your back so they can see it for themselves.

Objective evidence of deep learning: When students can navigate situations that are outside the curriculum.

“May 14, 2006: Happy Mother’s Day” by Matt McGee is licensed under CC BY-ND 2.0.

Nothing happens until the pain caused by a problem is greater than the pain of keeping things as they are.

Problems aren’t bad for business.  What’s bad for business is failing to acknowledge them.

The consternation that comes from the newly-acknowledged problem is the seed from which the solution grows.

There can be no solution until there’s a problem.

When the company doesn’t have a big problem, it has a bigger problem – complacency.

If you want to feel anxious about something, feel anxious that everything is going swimmingly.

Successful companies tolerate problems because they can.

Successful companies that tolerate their problems for too long become unsuccessful companies.

What happens to people in your company that talk about big problems?  Are they celebrated, ignored, or ostracized? And what behavior does that reinforce?  And how do you feel about that?

When everyone knows there’s a problem yet it goes unacknowledged, trust erodes.

And without trust, you don’t have much.

If you think asking for help is a sign of weakness, you won’t get the help you deserve.

If the people around you think asking for help is a sign of weakness, find new people.

As a leader, asking others for help makes it easier for others to ask for help.

When someone asks you for help, help them.

If you’re down in the dumps, help someone.

Helping others is like helping yourself twice.

Helping is caring in action.

If you help someone because you want something in return, people recognize that for what it is.

Done right, helping makes both parties stand two inches taller.

Sometimes the right help gives people the time and space to work things out for themselves.

Sometimes the right help asks people to do work outside their comfort zone.

Sometimes the right help is a difficult conversation.

Sometimes the right help is a smile, a phone call, or a text.

And sometimes the right help isn’t recognized as help until six months after the fact.

Here’s a rule to live by – When in doubt, offer help.

“Helping Daddy” by audi_insperation is licensed under CC BY 2.0.

When things are overwhelming to you but not to others, it’s okay to feel overwhelmed for a while.

When the seas are rough, you may think you are alone, but others may see it differently.

What’s worthy of your attention is defined by you, though some make it easy for you to think otherwise.

When you disagree with someone’s idea, that says nothing about them.

Judging someone from the outside is unfair, and it’s the same with judging yourself from the inside.

When everyone around you sees you differently than you see yourself, it’s worth looking critically at what you see that they don’t and what they see that you don’t.

You aren’t your thoughts and feelings, but it can feel like it in the heat of the moment.

Self-judgment is the strongest flavor of judgment.

“Object from the exhibition We call them Vikings produced by The Swedish History Museum” by The Swedish History Museum, Stockholm is licensed under CC BY 2.0.

If there’s a recurring problem, take the time to make sure the system hasn’t changed since last time and make sure the context and environment are still the same.  If everything is the same, and there are no people involved in the system, it’s a problem that resides in the clear domain.  Here’s a link from Dave Snowden who talks about the various domains.  In this video, Dave calls this domain the “simple” domain.  Solve it like you did last time.

If there’s a new problem, take the time to understand the elements of the system that surround the problem.  Define the elements and define how they interact, and define how they set the context and constraints for the problem.  And then, define the problem itself.  Define when it happens, what happens just before, and what happens after.  If there are no people involved, if the solution is not immediately evident, if it’s a purely mechanical, electromechanical, chemical, thermal, software, or hardware, it’s a problem in the complicated domain (see Dave’s video above) and you’ll be able to solve it with the right experts and enough time.

If you want to know the next evolution of the system, how it will develop and evolve, the situation is more speculative and there’s no singular answer. Still, the first step is the same – take the time to understand the elements of the system and how they interact.  Then, look back in time and learn the previous embodiments of the system and define its trajectory – how it evolved into its current state.  If there has been consistent improvement along a singular line of goodness, it’s likely the system will want to continue to evolve in that direction.  If the improvement has flattened, it’s likely the system will try to evolve along a different line of evolution.

I won’t go into the specifics of lines of evolution of technological systems, as it’s a big topic.  But if you want to know more, here’s a nice description of evolution along the line of adaptability by my teacher, Victor Fey – The best products know how to adapt.

If there are people involved with the system, it’s a complex system (see Dave’s video).  (There are complex systems that don’t involve people, but I find this a good way to talk about complex systems.) The first step is to define the system as it is, but because the interactions among the elements are not predictable, your only hope is to probe, sense, and respond by doing more of what works and less of what doesn’t.  Thanks to Dave Snowden for that language.

The first step is always to understand the system as it is.

“Space – Antennae Galaxies” by Trodel is licensed under CC BY-SA 2.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.