On waste to avoid waste

The traditional view of management says that any "idle machine" is a waste. This view, which a lot of business people are trained with, has more consequences than it seems.

As a founder and a person in charge of a product, I've heard a lot of times that we should do this "rebranding", we should "redesign this part of the application" or we should do this "big refactor".

These kinds of fuzzy projects, without any set of guidelines, boundaries, or mission, are the ones to be very wary of.

Because not only is there no clear idea of why we should do them, what problem they resolve, or how they will translate into making progress for our customers—in other words, from the demand perspective, there isn't any narrowed problem—but also because most of the time these projects emerge from a lack of other insights or strategic opportunities to tackle.

When you don't have any clear vision of what opportunities or bets you can take and delegate to a team to implement, you have to look for them.

How? Well... Talking to customers, doing some support work, doing some Jobs To Be Done interviews, and analyzing (or event setting) the instrumentation in the product to measure the blocking points or steps for the customers.

Of course, this kind of discovery work (making the work to make the work) involves a lot of effort and requires different and broad skills, not only to execute it but also to be able to identify the insights that are worth looking into more deeply.

Probably the team that usually implements the projects doesn't have the right mix and level of seniority in the different skill sets. Bob Moesta defines them very well in his great book Learning to Build:

• Empathic Perspective.
• Being able to uncover the demand.
• Identifying the causal structures.
• Being able to prototype in order to learn.
• Being able to identify but also make tradeoffs.

Of course, these are general skills. More specific skills particular to the organization and product vision are needed, like business knowledge, customer knowledge, technical feasibility assessment, etc.

So if the implementing (developers, designers) team can't, because of a lack of skills and accountability, be effective in discovering the work, this responsibility falls on the shoulders of the founders or executives.

These executives, finding themselves looking for answers and analyzing the demand, fall into the trap of the traditional management view.

If they are finding the strategic direction, what projects should they delegate to the (now) idle team? Because Taylorism preaches out loud that "people can't be idle".

And this is where these fuzzy projects come into action. Executives delegate these projects thinking that the team can solve them by themselves because they are just a redesign, a rebranding, or a refactor, only to find themselves constantly being asked questions of the type: "What should we do with X?"

But unshaped work doesn't help anyone.

The team without any clear boundaries, purpose, or narrowed problem would be in the uncomfortable (and uninspiring) position of asking the leaders what they should do next. And as they don't have the needed information to make decisions and trade-offs, the team wouldn't be able to know when the project is done or if expectations were met.

The executives, not having defined any clear expectations of the project, when the project can be considered done, or setting a budget, will be constantly interrupted by the team with questions and meetings in order to define what should be done next to move forward the project.

With these constant interruptions, they won't have any available time to define the next projects, interview customers, or analyze the data in order to frame the problems and ideas that emerged.

By trying to avoid waste (idleness), executives lose precious time that should have been allocated to more important projects for the business. 

In fact, that precious time gets misallocated (with interruptions and constant demand) to projects that aren't relevant or at least don't have a clear and perceivable goal that would directly impact the business.

To get out of the hole, you first have to stop digging.

Idleness is not bad per se, and it shouldn't be seen as avoidable at all costs. Like every other decision, it's a trade-off. And when contrasting idleness with an unshaped project, idleness triumphs.

Also it's not like the team doesn't have things to do that can be self-directed.

As an example, in my current company, we are a small team that works in 6-week cycles. And in my role as a founder and the executive of the product area, sometimes I declare a bug-smashing and improvement cycle just because I haven't found any clearly defined problems and a bounded solution (shaped projects) yet.

These are cycles where the team can choose their own small tasks and bugs that they find important to be solved.

Although, during these cycles, the designers might find it hard to find tasks and will have more idle time than the developers, I don't care. The risk of assigning the team unshaped work is far worse than the risk of slack time.

We should change the view that because we hired the people, they should always be busy. We hire people so that they can be available, motivated, and ready when we need them.

And we need them most when you have projects with clear goals and boundaries that need to be shipped within the budget we want to bet.