120 000 Nails – Urgency and Busyness as Motivators

This is the third part of the series “Busyness, Productivity and Creativity”. The series consists following parts:

  1. Being creative and productive despise of the insane working pace
  2. Two organization anti-patterns: Urgency as Thread and Busyness as Heroism
  3. The Good Sides of Busyness – Busyness and Urgency as Heuristics for Cadence
  4. 120 000 Nails – Urgency and Busyness as Motivators

In the second part, I claimed that there are four types of urgency and busyness: (1) urgency/busyness as a mechanism of manipulation, (2) urgency/busyness as a necessary part of the system, (3) urgency/busyness as a heuristic indicator, (4) urgency/busyness as a motivator. In the second entry I introduced the first two and in the previous one the third. In this entry I’m going to the last type. I’m not saying that experienced busyness or urgency per se motivates. It does not, the proximity of busyness might motivate.

“Urgency as a goal” is an anti-pattern

Years ago one of my colleagues was leading an important project in another company. The project didn’t proceed as planned and the original deadline looked impossible. His manager got a great idea: Seemingly developers don’t have enough motivation to deliver in time, so let motivate them a bit. He ordered my colleague to tell his team that if the software is not ready until day X they all will be fired.

My colleague did so and the team, indeed, delivered in time. Absolutely great management if you don’t take into account few minor complications: the solution was practically worth of nothing and almost unmaintainable, and the team was pissed off and fatigued. The team dropped off the most good practices – including testing – in order to deliver in time. As a consequence, the result was crap and they used next half a year or so to just to fix bad code and bugs.

That’s how it works. If you force people to do things within unrealistic time schedule, they often invent a way to get things done within that time – by cheating
and by compromising the real goals. Following diagram clarifies what probably happened:

Click to see bigger image(Click the image to see bigger version)

The pattern is actually exactly the same than in an anecdote from Soviet Union: The central authority specified that a nail factory must deliver, say, 120 000 nails per day. That was far over the factory’s capacity. However, cleaver Russian engineers invented a way to do it. They made nails very thin. As a result they went much over the goal. Great – except no-one had use for such a thin nails. As a consequence the central authority corrected the goal. Now the factory’s goal was defined in tons. The goal wasn’t more realistic, nonetheless. Again, clever Russian engineers invented a way to achieve the goal: they made the nails ridiculously big. Again they easily achieved the goal. And again the result was tons of waste. No-one had use for such big nails. (I’ve seen many versions of this anecdote. This one probably isn’t historically the most accurate one. The illustrative story is more important that strict historical correctness.)

Click to see bigger image(Click the image to see bigger version)

Fight or Flight – reactions to urgency

“Deliver this-and-that solution before day X, or else I shall fire you.” That sounds a bad deal. No-one want to choose between two bad things. Instead of that, the people will seek for the third option and minimize the loss. In this case, the third option was non-working software in time.

Manager’s intuition probably was that now people want to “beat the challenge”. He probably thought that the tight time frame is just a problem among other and now, the team is more eager to solve the problem. That’s what we do for living on this industry: we solve problems – technical problems, communication problems, all kind of problems.

Here we come to the context omission fallacy. Consider the diagram below:

(Click the image to see bigger version)

The manager was not panicked and threatened, and he had the organization’s support. For him, the deadline he set seemed to be and also was just challenging problem solving and hard work. Within this context he would have rather beat the challenge than avoided it. Indeed, there is nothing inherently bad and painful in the hard deadline per se – or in urgency. You can see it just as a problem to solve and an interesting challenge. The manager assumed that the team would think similarly.

However, the natural reaction in this kind of situations greatly depends on the support you think you have and the feeling of safeness. If you are alone, you are less likely to take any risks. You also have tendency to see the all problems and challenges as risks. If you can fail to solve them, you will get punished because of that – directly or indirectly. The team was more or less alone: if they fought and failed, they would be fired. So, there was neither rational nor emotional reasons to take the challenge rather than avoid it. Therefore, for the team, there was just one real problem: how to minimize pain and loss?

Nearby and not quite here-and-now

I said this already in the previous entry and now I say this again: The busyness is a great thing as long as it is nearby and not quite here-and-now.

The same logic is true for excitement in general. In horror movies terrible events are exciting just because they are only nearby and not quite here-and-now. In competitive games, the anxiety caused by the uncertainty and the artificial conflict is just fine, because it is only nearby and not quite here-and-now. You can stop playing or watching the movie at any time and get rid of anxiety. They are in control. And so forth.

If I make myself busy, I’ve a lot of things to do. That’s fine. If you make me busy, you mess up my day. A significant difference. The person who is or will be busy, must have the control over his busyness. If you make a person busy, he won’t be motivated by the busyness. He doesn’t have time for that.

Sometimes urgency nearby is highly motivating. E.g. a site is being bombarded by unceasing denial of service attacks. The urgency in this situation can be motivating, because it allows a developer to signify and glorify his own work without necessity to enter into the maelstrom of busyness. Actually, it’s his choice how he face the urgency and if he switch to busywork mode.

A manager or a customer can easily ruin the motivation by taking the control over urgency and busyness from the person. Probably the easiest way to poison the source of motivation is blame: “This is your code. Why didn’t you take this into account…? Now, fix it!” The blame can also be implicit like in repetition: “Hurry, hurry, hurry!” The later one is a blame, since it presuppose that the developer doesn’t already try to write a fix as soon as possible.

Honest and understandable busyness

If urgency and busyness is used as a motivator, they must be honest and psychologically understandable. This is often a problem when the investors’ expectations are used as an excuse for busyness and busywork.

“If this project is not ready till day X, we cannot attain its profitability targets.”

“So what? Those obscure objectives belongs to your game, not ours…”

There are only small number of persons for whom profitability target is an honest and understandable motivation. The most people want to have good products and good projects. The profit is a side-effect of them. Setting a side-effect as the main goal is not quite honest and psychologically understandable for the most.

I’m not saying that the profit is unimportant but that the way it motivates does not fit in my everyday life very well. I cannot use it efficiently to signify my work. Therefore, I’m not going to be busy because of profit, and I’m not going to do overwork just because of the profitability of a project or a company. It’s far easier to get motivation for overwork for instance, if you want to show something damn cool next week (and not later), and you won’t get it done in time otherwise.

“I want to be respected by others” is honest and psychologically understandable goal. If it means busyness, I’m oftentimes completely okay with that. Compare it to “I really-really want to do some more profit for the company and investors!” That is neither honest nor understandable for the most people, because the most of us are not brainless servants of venture capitalists – or alternatively paralyzed by decent amount of modern embarrassment killer, money.

Busyness as addiction

There is a significant different between “Gosh, they really need my effort as I’m all the time so busy” and “Oh dear, there’s so much to do… Fortunately, my work has a purpose”.

The busyness can be highly addictive. The busyness become addictive once excessive demand of your effort substitutes the need to do purposeful work. Notice the category difference: busyness override a need. Thinking of SCARF model and the needs our brains have, it’s easy to understand this addiction. Excessive demand of your effort makes you feel more important (need of status) and then, it delusively makes you feel more related to others (need of relatedness).

In a way, heroin addiction motivates the junkie to get more heroin. Yet, I’d like to distinct addiction from motivation. A busyness junkie – a workaholic – is not motivated by urgency and busyness, he is addicted to it.

Referred and used literacy

Apello, J. (2011). Management 3.0: Leading Agile Developers, Developing Agile Leaders.

Cohn, M. (2009). Succeeding with Agile.

DeMarco, T. & Lister, T. (1999). PeopleWare – Productive Projects and Teams. 2nd Edition.

DeMarco, T. (2002). Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.

Kennaley, M. (2010). SDLC 3.0: Beyond a Tacit Understanding of Agile.

Leffingwell, D. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.

Poppendieck, M. & Poppendieck, T. (2006). Implementing Lean Software Development.

Reinertsen, D. G. (1997). Managing the Design Factory.

Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development.

Ries, E. (2011). The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.

Rock, D. (2009). Your brain at work.

Rock, D. (2008). SCARF: a brain-based model for collaborating with and influencing others. http://www.davidrock.net/files/NLJ_SCARFUS.pdf (referred 14.8.2013)

Rother, M. (2009). Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results.

Sheddon, J. (2003). Freedom from Command and Control: A Better Way to Make the Work Work.

Advertisements

Two common leadership anti-patterns: Urgency as Blame and Busyness as Heroism

This is the second part of the series “Busyness, productivity and creativity”. The series consists following parts:

  1. Being creative and productive despise of the insane working pace
  2. Two organization anti-patterns: Urgency as Blame and Busyness as Heroism
  3. The Good Sides of Busyness – Busyness and Urgency as Heuristics for Cadence
  4. 120 000 Nails – Urgency and Busyness as Motivators

On part one I pointed out that an organization may perform well and be creative despise of rush. Yet, usually rush reduces creativity and performance. In the second part of the series I discuss, why pressure sometimes increases performance, and why it doesn’t most of the time.

I have identified four different types of urgency and busyness: (1) urgency/busyness as mechanism of manipulation, (2) urgency as a necessary part of the system, (3) urgency as a heuristic indicator, (4) urgency as a motivator. I’m not going to explain why I have ended up this kind of classification. I just try to show the variety of ways urgency and busyness exists in the work life. In this blog post is discuss two wasteful and devastating types of urgency. In the next one I will analyze a useful and good type of urgency/busyness.

Urgency as blame

Some people seem to think that a thread of fear makes people work harder. The logic is basically the same as the logic of slavery: people are willing to do things they would not otherwise want to only if they have to fear something worse. Unfortunately, the effect is opposing to people who like their work: it makes them averse or even hate it; it makes them less motivated to do it well.

An examples clarifies this. Say a customer needs a software system by December. Let’s presume that that it would be not completely possible to deliver the solution in time but also very probable. Even if the initial deadline was realistic, the project failed. The reason to the failure was artificially created urgency that was meant to be motivating.

Following diagram depicts what happened and why the project failed:

So what happened?

  1. First, the customer (=one who pays for the software) buffered risks and told to the supplier that the deadline is two months earlier than it really was. Including a risk buffer to the schedule is certainly a good practice. However, often the risk buffer is hidden due distrust. Instead, what is told is that this is a high risk project, and it have to be ready by day X. The customer believes that the supplier anyway will miss the deadline and if they know the real DL they are likely to miss it too.
  2. Often the supplier’s manager thinks in similar way. In this example, he doesn’t trust in the implementation team since the team have often missed the deadline – even the one they have told realistic. Managers don’t often see the unreasonable and unrealistic expectation as a partial reason to the missed deadlines. That’s the case also in this example. It’s psychologically far easier to subconsciously blame the others than to seek the root reason from the system you are part of. Therefore the manager adds an additional, hidden risk buffer and tells the team that deadline is on August. The real deadline is hidden, since – this is how many people thinks – the people will use the all the available time they have for a task anyway.
  3. As a consequence of (1) and (2) the time schedule is completely unrealistic. As the team complained that they need at least two more months to get things done, they were told that “this is a risky project but we have to try anyway”. Secretly the manager was satisfied. The team’s estimate was aligned with the deadline the customer set and now, by setting the tight deadline the team will try harder. It’s not a surprise that the deadline was missed.
  4. The implementation team feels inadequate and insufficient, even if everyone knew that the DL was unrealistic (4a). Also the manager pretends to be surprised and slightly dissatisfied. Nonetheless, he softens the implicit blame by telling that the company took conscious risk as it tried to implement the solution within this tight schedule. Of course that is not quite true, as there were two months hidden in the risk buffer. “Luckily” the team is given a second chance (4b). The DL is moved by 2 months, and now “we really must keep this schedule, otherwise we have serious problems”. The urgency as a thread and blame is recreated as even worse than it was. As this happens more than once or twice, people stop trusting management and become more and more cynical toward the project (4c) “These projects are always late – who cares” attitude replaces the positive optimism and will to success.
  5. This kind of urgency and pressure has few notable side effects: First, people have the tendency to hesitate. Second, they also often get fatigued by trying harder and harder. People who hesitate and are fatigued make far more mistakes. We all know that. The third side-effect of the urgency and busyness is that managers think “now we are needed more than ever”. The worse the project status, the more time managers seem to require for different kind of “fire fight” meetings and reports that helps them to do “wise decisions”. Common sense says that if the ship is sinking you should either let it sink and save the crew, or let crew focus fully on saving the ship. This is not how the system works in the software industry; instead the focus is often in the manager’s survival plan and in their ability to do decisions. Due to all hesitation, fatigue and wrong focus the team not only misses the managers’ hidden deadline but also the customer’s real deadline.
  6. Next time the manager and the customer secretly reserve an even bigger risk margin and by doing so makes the schedules once again ridiculous. By doing this they follows DeMarco’s and Listers’s first rule of bad management: If something is not working, do more of it.

Urgency/busyness as a mechanism of manipulation

The example above illustrates how urgency and blame substitutes trust and collaboration. Urgency and busyness are powerful tools of manipulation. The false deadline is one the most common pattern how the urgency and busyness is used in management – there are many others.

The algorithm behind this and other similar patterns is very simple: (1) Set such (unrealistic) goals that people will work hard in order to not fail, but most likely they will still fail. (2) Once they have failed, create implicit blame and offer the second chance. As people have failed they are more willing to obey and they less likely protest whatever you do and decide. They also feel that they are not worthy, and therefore it’s hard for them to ask more salary, or other benefits. Why should a company pay more form people who fail often? The manager just need to make people see this logic: you are losers and therefore you have to obey the one who will clean up the mess you’ve created (that’s me) and you must not ask for any benefits because you are not worth of them. “The second change” directs the workers attention away from the managers themselves back to the work. It’s a necessary part of this ‘sleight of hand’. Otherwise the workers might realize that actually, the management is the loser-maker, and not take the blame.

The worst thing in this all is that the most managers don’t consciously use this kind of patterns. They seemingly don’t understand this logic. Instead, they think that this kind of misuse of urgency is a good management practice. They even may see the problems caused by the popular leadership anti-patterns, but they don’t have courage to be critical and do the conclusions. “This is how I’m supposed to behave. This is what people expect from me.” It’s just fine that people become cynical and the projects keep on failing – that’s the way the world work; I can’t do nothing. The urgency and busyness become necessary – that’s the second devious form of urgency and busyness.

Busyness as false heroism

In many companies busyness is associated to diligence. Hard working people are praised, and the ones that do ridiculous amount of overwork are glorified. Not because they get a lot of done, but because they sacrifice a lot for the greater good. The most obvious reason for this kind of work culture is the (false) belief “the more time a worker spends, the greater are the results”.

This is not true in creative knowledge work: rather, the more work hours you have to use for something, the more likely it is that you are doing a lot of unnecessary work. The same thing could be done with significantly less work. The following diagram illustrates the underlying logic of “urgency as a false heroism”:

  1. The system (= here, the way the organization works and interacts with other systems) is initially ineffective, and therefore people need to do more work for the results than necessary. Notice, that the system is taken for granted. It is not questioned or changed intentionally. If it changes, the change is just a side-effect.
  2. Due to the competition and the need for growth, more results are needed. However, changing the system is an unobvious way to do more results. Usually the management want to have control inside the system rather than control over the system. I will discuss this difference (between the control inside the system and the control over the system) in the last part of this series. Instead of a change in the structure and function of the system itself, the most companies force people work more. This is called improved productivity, but actually usually it is just increased busyness.
  3. As a consequence the organization is unable to change. People simply don’t have time for a change. Actually they don’t have time to think if things could be better. They don’t care, as long as the current state isn’t too painful.
  4. As a result people (including management) becomes cynical and pessimistic. Nothing can be done for the system, we just have to work harder and harder in order to survive. This is what I call the first positive feedback loop. As a result, busyness is glorified.
  5. Since busyness is now associated to diligence, productivity and efficiency, diligence, productivity and efficiency are associated to busy people: because that person is busy he must be also highly productive and thus a good worker. Therefore people who want to progress in their careers want to be busy – the busier and closer to burnout, the better. This is what I call the second positive feedback loop.
  6. Busyness is now both necessary and also a good indicator: Too much work becomes a positive problem that need not be solved. Rather we just have to invent a way to do all that work. Instead of thinking what we need to do to the system in order to raise its capacity in a healthy way, we rather maximize the utilization of people. That is, we make people maximally busy. I call this the third positive feedback loop.

Urgency and busyness as a necessity

So, what is missing from the picture? The positive feedback for improving the system. It is not there, because most organizations don’t have a positive feedback loop that would make them change the system and take control over it. Usually the system is sacred. “The logic of business cannot be changed: you either accepts the rules of the game, or you don’t play at all. Changing the rules of the game, is not a legal move. We have to work in this way exactly, because we have to work in this way.”

However, the system can be changed. The organizations could create a positive feedback loop that drives the change. In order to have self-evolving system, you should understand the system and its dynamics. Unfortunately, understanding the system seems to be too hard for the most. Can’t you hear the lamentation of the masses of mediocre and bad managers, can you? “Why can’t we just make profit? Why can’t we just make the results? We don’t’ want all the complexity of the systems, we want simple numbers; simple euros (or dollars)!”

There are numerous reasons why urgency is seen as a necessity. The most common ones are intellectual laziness, lack of imagination and ideals, and inability to think the system. While passive submission for urgency and busyness is an anti-pattern, urgency and busyness as a necessity is not completely bad thing: If urgency and busyness seems to be necessary, you have a problem you should solve – urgently. The next entry in this series “The Good Sides of Busyness – Busyness and Urgency as Heuristics for Cadence” will discuss this subject.