The Benefit of Management by Fear

In general, the possibility to avoid threats and pain is a stronger motivator than the possibility to gain something pleasant. This is true for most organisms where you can talk about motivation at all. Responding to threats with fear and avoidance is apparently a good survival tactic.

And like all creatures that are dependent on groups to survive, we are particularly fearful of rejection, that the group will reject us and leave us alone in the wild. Which the group will do if the most influential individual in the group tells it to.

This is why management by fear is such an effective strategy for motivating people to work. If you have the mandate to reject people and make their peers reject them as well, you can make them do anything.

Or, not really. There are a few things that the fearful brain is incapable of doing. So if you are planning to use management by fear there are a couple of things you need to be prepared to handle yourself.

You need to define the tasks for your subordinates since their fearful brains won't be able to come up with the tasks themselves.

The tasks need to be perfectly thought out because your people will perform them even though everyone can see that the result is flawed. A fearful brain doesn't dare to criticize your orders.

You need to increase the checks and controls. If subordinates fears showing you mistakes that has been made you need to find other ways bringing them into the light.

(Extensive checks are also important for linking the necessary punishment to bad behaviour. A small part of uncertainty whether or not you will be punished will strengthen the fear, but uncertainty is a strong demotivator. Most punishment should come as a logical consequence of past outcome.)

The responsibility for planning and follow-up if things are going according to plan or not from now resides with you.

You must handle all the external relations. Fearful brains will focus on pleasing you and not your customers.

From now on you have to do all innovation. A fearful brain is incapable of experimenting.

Given that you are willing to assume these responsibilities, management by fear can be a great tool for your organization. The alternative is to create an organization of customer-focused, innovative responsible adults that can manage their own work according to the goals you set together. That will also require a lot from you as their manager, but it is a different set of tools.

Kvalitet OCH snabbhet

Den falska motsättningen mellan hög kvalitet och snabb leverans är en tankekonstruktion som verkar vara väldigt svår att göra sig av med.

Det kan ha att göra med dessa två kopplingar: slarvig leverans ger låg kvalitet, samtidigt som slarvig leverans utan större ansträning kan snabbas upp.

Så det går att få snabbhet i leveransen genom att slarva, med du kommer då att få låg kvalitet. Men du måste då också vara beredd på fortsättningen: låg kvalitet ger sedan långsam leverans. Defekterna som slarvet orsakade behöver tas om hand. Det du inte säkerställde igår poppar upp idag och rör till allting för er.

Den snabba leveransen sker inte på bekostnad av kvaliteten utan på bekostnad av framtida snabbhet. Snabbt slarv är ett lån från framtiden.

Det finns en mytisk modell inom projektledningen som kallas "projektpyramiden". Den ställer projektets omfång, tid, budget, och kvalitet mot varandra och vill påstå att man genom att vilja ha det ena måste ge avkall på det andra. Den bilden är falsk när den leder folk till att tro att det går att leverera ett visst omfång på en viss tid inom en viss budget om man bara får lov att tumma på kvaliteten. Istället är variablerna bundna vid varandra så att du så snart du sänker kvaliteten får en dramatisk höjning på tid och kostnad för det omfång du bestämt dig för.

Projektpyramiden ger en falsk bild av verkligheten, åtminstone i många producerande och tjänsteutvecklande verksamheter.

Produktivitetsökning kräver ordning och reda. Kräver att det inte finns så mycket okontrollerad varians i systemet. Det är därför som ett fokus på systematiskt kvalitetsarbete i förlängningen ger högre produktivitet (mer, bättre, snabbare och billigare). Men nyckelordet är systematiskt. Det handlar inte om kvalitet genom att individer sliter hårdare eller tar mer tid på sig och dubbel- och trippelkollar allt arbete. Eller genom att man gör väldigt mycket och sedan inspekterar fram den lilla del av produktionen som råkar blir bra. Det handlar om metodik.

Tricket från metodiskt kvalitetsarbete, det som lean och agila metoder använder, är att man gör god kvalitet billigt. Förtydligar kvalitetskraven så att de är otvetydiga och låter de som ska utföra arbetet och de som ska ta emot det utförda arbetet tillsammans avgöra om kravet är tvetydigt eller ej (i Scrum genom redokriteriet och klarkriteriet). Rapporterar blixtsnabbt så snart man ser att en avvikelse från överenskommelserna är på gång att inträffa och får snabba beslut om hur man ska göra. Bokför de avvikelser man av olika skäl inte kan hantera så att man alltid har med dem i beräkningen.

Och det ständigt pågående förbättringsarbetet. Vi dokumenterar hur vi arbetar idag. Vi analyserar vad som hindrar oss från att ta nästa steg mot större kvalitet och snabbare feedbackloopar (där leverans till människor som använder det vi producerar och deras användande är den viktigaste feedbackloopen). Vi experimenterar med vårt arbetssätt. Vi förenklar, arbetar i team, bryter ner i mindre delar, har snabb omplanering, automatiserar så många rutiner som möjligt som har med felsäkring att göra, och så vidare.

Det kräver ganska stora frihetsgrader för arbetsgrupperna för att de ska kunna arbeta med metodiskt kvalitetsarbete. Det kräver å andra sidan av grupperna att de hela tiden arbetar under stor transparens så att alla ser vad som händer, och att de arbetar med ständig riskreducering så att utforskandet av arbetssätten blir säkra och trygga.

När arbetsgrupper börjar använda lean och agila metoder utmanas de befintliga strukturerna. Myter i organisationen, som till exempel projekttriangeln eller tron på planerbarhet i komplexa miljöer, eller tron att effektivitetsförbättring i alla verksamhetens delar innebär effektivitetsförbättring på hela flödet, riskerar att avslöjas när verkliga mätdata synliggörs av de som arbetar nära det direkta värdeskapandet.

Personer som har sin yrkesroll och identitet baserad på att upprätthålla myterna blir hotade av det nya arbetssättet. Detta gäller inte minst många chefer som tillsatts för att bevara och förstärka en struktur som inte längre kan sägas vara hjälpsam. Det gör att förändringsarbete som syftar till att få både kvalitet och snabbhet förhindras av ett uteblivet skifte i tankesätt och kultur.

Samtidigt är det ofta dessa chefer som äger frågan om både kvalitet och snabbhet. De är tillsatta för att få till precis det de själva förhindrar, så länge de inte inser att det krävs ett nytt tankesätt och ett nytt beteende från deras sida. Att arbeta i det spänningsfältet utgör större delen av mitt arbete att stötta organisationen i förändringen. Det är väldigt intressant och väldigt utmanande.

When you can't iNvEsT

In agile development we have a backlog: a list of needs that we want to fulfill in a certain order. We also try to have a cross functional small team that take care of meeting the needs without having to handover stuff that must happen to other people. In certain agile frameworks (such as Scrum) the team shouldn't even have to interact with others when meeting the need so that they are able to independently take responsibility for a couple of weeks worth of work.

That means that each work item that meets a need (is valuable) also has to be small. We also want each item to be independent of the others so that we can give our primary stakeholder (for example the Product Owner role in Scrum) the opportunity to pick and choose any of the items in the backlog to be fulfilled.

In 2003 Bill Wake suggested that these three characteristics (I for "independent", V for "valuable" and S for "small") of a good product backlog item should be combined with the characteristics negotiable (in agile, a requirement is the starting point of a conversation and not the end of a discussion), estimable (just enough so that stakeholders can decide if it is worth it), and testable (if we can't test if a need is fulfilled or not, the need was probably not expressed clearly enough). And thus the acronym INVEST (independent, negotiable, valuable, estimable, small and testable) was born.

Now, while INVEST can be an ideal (since if we manage to make all of our items on the list INVEST compliant it is really easy to increase the agility in our development) many have found it hard, if not impossible, to achieve. So what should we do then? Abandon the whole idea? No. But think a bit. And know how to work with it.

The thing is that three of the letters in the acronym has everything to do with the organization. Why isn't the items negotiable? Why can't you reach a consensus on them? There is almost always a destructive power game present when people doesn't understand why the items on the backlog isn't the last word on how to meet a need or what the need is about.

Why isn't the item estimable? Are there hidden complexities that you haven't explored yet? Don't you have sound practices around refinement so that you know what it would take? And why isn't the item testable? Haven't you had all the required conversations yet? Doesn't people know what they want? Do you let people who know how to test things step up and participate in the item generation?

The N, the E, and the T are typically things that an agile transformation address, and it goes typically very well. It isn't that hard to create an environment where we collaborate on the items, negotiates what we would like to see done, make forecasts, and thinking about their testability. The problem usually resides with the other three.

Things can be cut into small partial targets. But in many environments, they are not valuable. Due to inherited complexity in the technical environment things cannot be small and valuable at the same time. They might be able to, later on, but not now. So we might have to slice down a valuable feature into smaller pieces, starting with a primitive version of the feature and improving it over the course of a few sprints. In the same manner, features may be dependent of each other and implemented and released in a certain order within a releasable package.

It is for circumstances like these a backlog split in three levels, as Dean Leffingwell suggests, is constructed. Closest to the team are the sprintable items that they can plan for and implement. A group such of sprintables is needed to implement a feature (the second level), and packages of related features that are needed together in order to generate business value (Leffingwell calls these packages Business Epics) constitutes the third.

The three tier backlog has its place when the items cannot be small, valuable and independent at the same time. It has been criticized for introducing complexity, but the idea is not to introduce complexity but to mirror the actual complexity we actually have to deal with. Then we can start to manage the complexity and hopefully work in order to reduce it.

Related: The SMIDIGT! module about the three tier backlog: documentation-the-backlog.pdf