Why the Good Intentions Are Not Enough

Yesterday, I had a short discussion on my blog entry “Two common leadership anti-patterns: Urgency as Blame and Busyness as Heroism” with a friend. He basically asked “do I think that managers are malevolent?” Well, I do not, and I don’t say so in that entry. The text was a critique of systems, it wasn’t at all a critique of people per se. Also this this text is a critique of systems: I’m talking the social and cultural systems around us and the psychological and ideological systems inside us.

If a system is dysfunctional, all the good intentions (within that system) may turn out harmful things. If this is obvious for you, there’s very little truly new in the next ~900 words – just some macabre, black humor.

Imagine a benevolent surgeon, who was raised in a family of excellent carpenters. Almost before he learnt to walk, his parents taught him to make wood sculptures with knife, saw, hammer and chisel. Less than decade after the first sculptures, people could only wonder his outstanding skills to cut wood, so stunningly beautiful were the sculptures. The only reason why he didn’t become a carpenter was the fact that he wanted to do more good than a carpenter can. Because he was so skillful in the use of the hands, he chose to become a surgeon. And so he did. Because the knife, saw, hammer and chisel were so good tools for cutting wood he thought that they would be equally good for cutting flesh. It was a catastrophe.

The good intentions in the wrong system won't make it work. Photos in the image are from Wikipedia and used according to their license:  Chisels: http://commons.wikimedia.org/wiki/File:Cervo100.jpg; Surgery: http://commons.wikimedia.org/wiki/File:Ijn_surgeon.JPG

Many managers seem to think that the good, objectively correct intentions (cf. intention to cut outstandingly well wood/flesh) are the key of good management. The related systems are oftentimes ignored, or conceived as something you cannot and should not change. If something goes wrong, they just need to try harder to be a good manager and intend good even more– like if trying that harder makes any difference. After all, usually, it isn’t their fault that their intentions didn’t lead the intended, good results. It’s no-one’s fault. The problem was that they tried to change something in a system that did not work as they thought it would.

If it isn’t a duck, it most likely won’t behave like a duck even if you kindly and modestly treat it as a duck. The same is true with different kind of systems.

For instance, a manager with genuinely good intentions may honestly believe that Parkinson’s Law is true: “Work expands so as to fill the time available for its completion.” I have met managers that honestly believe in that law, and that makes me sad.  Actually, I have failed once to explain clearly why Parkinson’s Law doesn’t work in this-and-that context. (Embarrassing.) The law was developed in the context of British governmental bureaucracy. It is based on Parkinson’s extensive experience in the British Civil Service. It might have worked in that context. Probably it did. That proves nothing, nonetheless. No-one claims that knife, saw, hammer and chisel don’t work as tools to cut wood, either. They are excellent tools for that kind of cutting.

But then again, there is strong evidence that Parkinson Law won’t work in creative, knowledge work (see e.g. DeMarco & Lister, 1999, PeopleWare). It won’t work in the same sense as knife, saw, hammer and chisel won’t work as surgeon’s tools for cutting flesh even if they are excellent tools for cutting wood: The system around an action (cutting with carpenter’s tools, leading according to Parkinson’s proposals) is wrong. So, the good intentions of manager of this example won’t make a difference. The reason is simple: If something (Parkinson’s Law) doesn’t work in the context of a system (creative knowledge work), it won’t work in that system no matter how good and pure are your intentions (e.g. sustainable, stabile workplace due to successful projects and satisfied customers) and how hard you try. The result can be what I described in “Two common leadership anti-patterns: Urgency as Blame and Busyness as Heroism“:

Also here, the manager most likely had good intentions, but he simply didn’t understand well enough how the system works. He didn’t ask where the distrust comes from. Or what impact the anxiety and stress in fact had to the team? Or why the projects are often late? And so on. He ignored the system, and focused on, say, his benevolent intent to make a good, profitable project. Probably, he thought that his experience is enough, and thus he need not learn more of the system.

A bad manager isn’t usually a bad or malevolent person. I’ve been told that there are malevolent managers but I know none personally. Usually, a bad manager isn’t stupid either like the surgeon who though that the carpenter’s tools would work equally well for cutting flesh and for cutting wood. He is just ignorant and too proud to pay really attention into systems. Therefore he need not to put his assumptions into testimony. He’s like a cottager who killed the goose that laid the golden eggs in Aesop’s Fable: he’s interested only in good results and a solution for current challenges, not the system that produced the current challenges and will produce the results. I call this “system-blindness”.

It’s not only the managers and management who are sometimes “system-blind” – everyone is. System-blindness is a global disease. It’s okay to be blind every now and then. You cannot avoid that. Yet, it’s ethically wrong to be blind only because opening your eyes would be too painful. Thus, intellectual honesty is a universal obligation. The system-blindness is probably the single biggest reason for suffering. E.g. I claim that the most people who have committed crimes in war, intended to do good but their hard attempt to be good in the wrong system turned against themselves – and against everyone.

This is why good intentions are not enough: A bad system has tendency to make good people accidentally malevolent and their good intentions accidentally devastating actions. The good intentions separated from the system are day dreaming. While day dreaming definitely has its place and value as a source of joy, motivation and creativity, it cannot be the key element in the way organizations are led and developed.

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.

The Good Sides of Busyness – Busyness and Urgency as Heuristics for Cadence

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 of Cadence
  4. 120 000 Nails – Urgency and Busyness as Motivators

In the previous 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 previous entry I introduces the first two. In this entry I discuss urgency and busyness as a heuristic indicator. I have now explaining the two most common ways why urgency is devastating and wasteful. Now I’m going to have a look at why and how urgency and busyness can also be a good thing.

The Significance of Cadence

In “Succeeding with Agile” Mike Cohn discuss why Scrum initially recommended four week sprints rather than six week sprints or even longer. They had experimented six week sprints and found out that they usually got nothing done during the first weeks because the deadline was so far away. Four week cadence worked better. I presume that nowadays the cadence in Scrum-projects is often even shorter, two or three weeks. Cohn is not the only one who had found out that relatively short iterations work best. For instance, Kanban (and the lean software development methodologies in general) recommends to minimize the cycle time, even if the increasing urgency forces you to do big changes to specification, quality assurance and deployment practices. In the lean methodology, ideally, it should be possible to go live at any day.

The reason why short iterations and cycle time works is not urgency per se, but cadence related to it. The mathematical queue theory explains nicely why short cadence works from one perspective – and partially. I’m not going to discuss that now. Rather, I discuss why relatively fast cadence works from phenomenological and psychological perspective. I argue that from phenomenological point of view, the cadence of work and cadence of music or dance (etc.) are very similar: very slow rhythm is approximately as hard to maintain as very fast one, while a relatively fast but not too fast cadence is the easiest to manage.

If the cadence is too slow, it is hard to keep the rhythm instinctively. Usually you need to start counting: 1-2-3-4-5-6-7-bang-1-2-3-4-5-6-7-bang. Etc. This is true in software projects also. If the deadlines are too far away or the cadence is otherwise too slow, you cannot just trust your memory, instincts and gut feelings but you necessarily need Excels and other helpers to keep on track. You may even need a role whose only responsibility is to ensure the cadence; ensure the milestones and keep track of the tasks. This kind of role is needed especially if there is no proper cadence. 1-2-3-bang-1-bang-1-2-3-4-5-6-7-bang and so on. The lack of proper cadence is waste of people potential and a recipe to poorly performing team: it’s hard to dance well, if there is no proper rhythm and it’s even harder to enjoy the dance – even the silence is better.

On the other hand, if the rhythm is too fast, you start missing beats and eventually the music turn into cacophony. Again the analogy to software projects is straightforward: if the cadence is too fast, you start missing deadlines and forgetting things. This is a well-known psychological fact (see e.g. David Rock, “Your Brain at Work). For some reason, this is not obvious in the project management. “The more challenging deadline, the harder and faster you need to work”, we tend to think. Eventually, a project becomes a big ball of mud.

If you want to do things faster, you have first learn to do things fast, and that requires a lot of practice. You have to start slowly and with small steps. The more complex is the choreography, the more repletion you need until you can manage the movement when the cadence is fast. If you try to do things faster than you really can, you will mess up everything. If someone whispers your ears “faster, faster” all the time, you probably will, indeed, screw up faster. This is very true also in projects and software industry. Actually, this is obvious in almost everywhere else where the cadence is crucial – music, dance, martial arts, and so forth – but not in software industry.

Busyness as a heuristic indicator

“Hey, wait. You said, that you are going explain, in what sense urgency and busyness is a good thing.” Yes and still going to.

Busyness and urgency are good as a heuristic of the optimal performance and as a warning sign of shoals. I’m saying that busyness is a great thing as long as it is nearby but not quite here-and-now. The best cadence for work is much closer to urgency and busyness than boredom and idleness. The optimum performance and productivity is achieved by working nearby the capacity of the organization.

I slow down a bit and start from the systems in which the cadence is paid no attention at all. Both (2) too fast and (3) too slow working pace lead not only to suboptimal performance but are the root cause for other kind of problems.

(Click the image to see bigger version)

There are studies that states that after two weeks of overwork the net results are lower than they was before the overwork. E.g. before overwork you completed 10 units of work per week, after two weeks of overwork you are able to complete only 9. The benefit of overwork is negative (see e.g. Mike Cohn, Succeeding in agile and Lister & DeMarco, PeopleWare). This Fatigue (1a) is devastating because it lower productivity per time unit, and also because it leads to the high level of defects and technical debt (=the solution become hard to change and maintain; 1b & 1c). Because of fatigue, lower quality and technical debt the net effort fluctuate strongly (4).

The too slow pace is less harmful than too fast. In addition to the fact, that you obviously get less things done (as you work under the optimum capacity), the organization’s ability to learn is severed. The reason is to this is twofold: (i) the feedback loop is longer and (ii) people easily become more passive if the natural activity is artificially pushed down (for sake of the process). In addition, maintaining the overly slow cadence usually requires quite a much management overhead.

Actually, in the overly slow organizations and processes, there’s a lot of similar with butoh dance. I’m simply amazed by the control of body and mind that the grotesque and often unnaturally slow movement must require.

Mark Kennaley suggests in “SDLC 3.0 – Beyond a Tacit Understanding of Agile” that maximally efficient organization can learn quickly its capacity via experimenting (1) by experiment. Once the optimum is found it just need to adjust the amount of work to it (2). According to Kennaley this is the optimal performance an organization can achieve in the ideal situation:

(Click the image to see bigger version)

I partly disagree. Kennaley underestimates the potential of learning and of the improvements in the system. I believe that the optimum performance is achieved by keeping the amount of work slightly under the capacity of organization. In this sense, urgency and busyness are a heuristic for the optimum, natural cadence and performance: first work so hard that you feel a bit busy or – even better – almost busy, then slow down immediately and reflect how to avoid that shoal of busyness you just faced.

(Click the image to see bigger version)

I’m not saying that people will learn to do the same thing faster. That would be naïve. People do learn to do things slightly faster, but that improvement is not important at all. I argue that the capacity of an organization can raise if (and only if) people are able to do more the correct value-adding things and they need to do less the unnecessary or wasteful things. Obviously, doing all the time better and faster anything, won’t necessarily add value at all, and thus it does not make the organization more efficient.

In short, slack is needed for reflection of those things the sufficient amount of urgency and busyness reveals and that would make us busy if we don’t change the system. Without urgency and busyness you won’t see what you should do more efficiently – instead you do random things better.


Next, “120 000 Nails – Urgency and Busyness as Motivators“.

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.

Being Creative and Productive despite of Insane Working Pace

This is the first part of the series “Busyness, Productivity and Creativity. In this serious I discuss why we have to slow down to get things done faster and better. The series consists following parts:

  1. Being creative and productive despite 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

Puzzle analogue and slack

So, to be productive, information worker people need some slack – empty space in the calendar. Thus if you keep them busy all the time and maximize the utility, the people get less things done. What really matters is to get things done, not the amount of working hours. Sometimes, by doing more work, less work will done? Counter-intuitive, eh?

Tom DeMarco illustrate in his book “Slack” the need for slack as follows:

The puzzle A is solvable; puzzle B is impossible. Yet, in puzzle A there is approximately 11% unused space while in the puzzle B that all space is utilized. 11% of waste? The innovations dwells in the organizations ability to learn, adapt and change. The empty space needed for change and leaning isn’t waste – except in Excels!

Also e.g. Donald Reinersten underlines the importance of sufficient amount of slack in the organization in his book “Managing the Design Factory”. Reinersten does not use term ‘slack’. Instead he discussed lead time, queue length, capacity etc. In practice, his recommendations and conclusions are similar to DeMarco’s. Reinersten’s mathematical approach shows that slack makes sense also in the Excels if you measure correct things.

The third book reference: In his book “Your Brain at Work” David Rock’s book discusses this subject form the neurophysiological point of view. There are limited amount of resources in the brain. Creative thinking require a lot from your brain, the all irrelevant noise – like awareness of the deadlines that are not attainable – lower the probability of a creative insight. The most of the time the busy people just “survive” – they don’t “shine” since they don’t have time for that.


Last spring I had a very nice discussion about busyness, rush, pressure and their impact to creativity and organizational efficiency. I had just referred DeMarco’s Slack and claimed that continuous busyness and one-eyed attempts to maximize utility of people have tendency to kill creativity and ability to change. As bonus people get burnout sooner or later – or are smart enough to apply another job before that. My opponent, a smart Russian game developer replied:

[My busyness] is nothing compared to working in an advertising agency. Advertising is a job where you usually sleep at the workplace. And people usually just burn out after some time… It is strange (doesn’t fit into your [claim that Rush kills creativity and ability to change]) but creativity actually flourishes – at first, before a person burns out. In the other company – software startup – they introduced plans and procedures to avoid rush. But it lead to people becoming more passive and non-creative over time, because some air of suddenness and inspiration disappeared. So it was good for some people, who were new; there will be no sudden changes just before deadline, but not so good for those who used to act on inspiration – like being half-asleep for a week and then do the week’s work in three hours.

Embracing – was forced to restructure my argument. What follows next, is my revised answer to her excellent counter-argument. I have divided my argument into two parts:

  1. Why some organizations perform well and are highly creative, even if the working pace is insane?
  2. Why often lack of rush seems to lead passivity and lack of inspiration?

Why some organizations perform well and are highly creative, even if the working pace is insane?

These counterexamples against my argument are probably rather common, but nonetheless probably base on misconceptions or fallacies. I know that there are few opinionated studies saying something different, as my studies poses rather strong counter arguments against them.

It’s true that advertisement offices do time to time highly creative work and performs extremely well. However, you cannot deduce that they are creative because of the overly thigh schedules and busyness.

I presume, that the creativeness in advertisement agency can be explained by following four factors:

(1) Motivated, competent and experienced people. In advertisement offices the workers are often highly motivated and competent. Some of them have practiced arts (e.g. drawing) for decades and have high level of formal education on arts, while other have formal education on economics.

(2) Diversity in the working community. Diversity of working community increases amount of innovative solutions: in advertisement offices some of the workers are highly art oriented while others have financial stance and are money oriented. This kind of diversity and multitude of perspectives is good for creativity.

(3) Working environment. Working environment and way of working in itself is fruitful. Workers often enjoys of high level of autonomy and high level of trust (at least for the “high performers”). The success of a campaign depend greatly on them and thus, there is no place for indifference. In a way the results are “part of you”, and therefore you want them to be as good as possible.

(4) Short feedback loop. The feedback loop between and idea and response is relatively short. Often you see, if the idea worked within few hours, rather than within few months. In order to optimize learning, you have to shorten the feedback loop.

I argue that excessive busyness and rush make advertisement offices perform worse than they could. They have very good starting point, and then the greed spoils the most creative edge of the working community. The greed not only make they perform more poorly, it also endangers their health. According the studies I’ve referred, overly busy advertisement offices would do a lot better results and they would do even more creative campaigns, if there is enough slack in their schedules.

How much slack is needed?

I do not claim, that there must be only slack – that does not work either. Creative workers need some empty space, but only some. So, how much slack an information worker needs? I have not seen exact numbers. Probably, the proper amount of slack depends greatly on the person and on what you are doing.

According Donald Reinersten, for ordinary software development company the optimum performance is achieved with 60-80% relative utility ratio (2010, “The Principles of Product Development Flow”). If the utility score is over 80%, usually there are long queues that add no value but just costs. That is, there should be 20-40% of slack in order to make the organization perform optimally. Then again, Reinersten discusses organizational performance only, not creativity or performance of an individual person.


Next part: “Two organization anti-patterns: Urgency as Blame and Busyness as Heroism