This is the third part of the series “Busyness, Productivity and Creativity”. The series consists following parts:
- Being creative and productive despise of the insane working pace
- Two organization anti-patterns: Urgency as Thread and Busyness as Heroism
- The Good Sides of Busyness – Busyness and Urgency as Heuristics for Cadence
- 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 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 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.