Management 3.0

The book is a true ref­er­ence of those inter­est­ed in agile man­age­ment, main­ly because it is chang­ing the par­a­digm of man­ag­ing soft­ware devel­op­ment busi­ness­es. Appe­lo has a holis­tic view of the man­age­ment and lead­er­ship required to be applied in a com­pa­nies aim­ing to embrace agile prin­ci­ples. The start point of his the­o­ry is that the poor man­age­ment is one of the main imped­i­ments in imple­ment­ing agile.

The book struc­ture is some­what sim­ple: to effec­tive­ly man­age and lead an agile com­pa­ny, one needs to embrace the com­plex­i­ty of the real­i­ty and to strive to induce as much pre­dictabil­i­ty as pos­si­ble, know­ing that the struc­ture of the com­pa­ny will always be com­pli­cat­ed, while the behav­ior will always be complex.

To do this, a manager/leader should con­tin­u­ous­ly strive to ener­gize peo­ple, to empow­er teams, to devel­op com­pe­tence, to grow and nur­ture struc­ture, to cre­ate align­ment, to cease­less­ly seek improve­ments and to be aware that none of the the­o­ries will work 100%, but some would prove helpful.


There were so far three stages of management:
— Man­age­ment 1.0, which was all about hier­ar­chies and the chain of com­mand that comes along with them. The few peo­ple on the top are in con­trol and as we grad­u­al­ly descend on the com­pa­ny lad­der there is less pow­er and less con­trol. To moti­vate the top com­man­ders there were bonus­es, which served as an incen­tive to seek for com­pa­ny’s well being. The side effect was that bonus­es became more impor­tant than strate­gies and deci­sions and this led also to finan­cial implosion.
— Man­age­ment 2.0, which was not real­ly a dif­fer­ent approach, but a series of add-ons plugged in to Man­age­ment 1.0, such as Bal­anced Score­card, Six Sig­ma, The­o­ry of Con­straints and Total Qual­i­ty Man­age­ment. Some of them worked, some of them did­n’t. To increase the con­fu­sion, many of these add-ons are con­tra­dict­ing each oth­er, each one pre­tend­ing to be the real solution.
— Man­age­ment 3.0, which is a real step for­ward, intro­duc­ing the the­o­ry of com­plex­i­ty as a response to the Age of Com­plex­i­ty, as Stephen Hawkins called the 21st cen­tu­ry. Lead­er­ship is intro­duced along with man­age­ment. And orga­ni­za­tions are per­ceived as net­works, despite their out­er look as hierarchies.

Tak­ing about lead­er­ship, the author dif­fer­en­ti­ates among three type of approaches:
— Lead­er­ship princes, the ones that claim that “lead­er­ship is dif­fer­ent from man­age­ment”, that is tak­ing place at a “high­er” lev­el. They see lead­er­ship being about inspi­ra­tion, while man­age­ment is about exe­cu­tion. But by def­i­n­i­tion lead­ers have no pow­er of author­i­ty over oth­ers. Why would a share­hold­er give mon­ey to some­one that has no author­i­ty? And how about oth­er peo­ple in the orga­ni­za­tion that are not man­agers, but could be true leaders?
— Lead­er­ship priests, the ones that claim that “man­age­ment is not need­ed”. They refer to social media, to orga­ni­za­tions such as Wikipedia, Lin­ux and oth­ers that are func­tion­ing based on a shared pur­pose, sug­gest­ing that self-orga­nized teams do not need man­age­ment, only lead­ers with visions. But busi­ness have assets. And share­hold­ers expect that those assets are not man­aged prop­er­ly. So it is not the teams that need man­age­ment, but the shareholders.
— Lead­er­ship prag­ma­tists, are the ones intro­duced by this book. Man­agers are need­ed to take care of the busi­ness on behalf of the own­ers. And man­agers need to have lead­er­ship skills. But lead­er­ship can arise also from oth­er lay­ers of the orga­ni­za­tion, from non-man­agers. These infor­mal leader must under­stand that the self-orga­niz­ing teams must accept some direc­tions from the own­ers, which pass­es through the managers.

Chap­ter 1: Why things are not that simple

The human brain is wired in a way that every event is per­ceived as the con­se­quence of anoth­er, in a deter­min­is­tic cause-effect approach, called lin­ear think­ing. This was prob­a­bly help­ful in ear­ly stages of human­i­ty, when run­ning from dan­ger when dan­ger was not there was a small price to pay com­pared to being killed by a preda­tor. But the world has evolved in vary dif­fer­ent way since those time, yet our mind tends to orga­nize things in the same man­ner. Com­plex­i­ty has grown a lot around us and one may spec­u­late that our actions as a species tend to increase this com­plex­i­ty. Lin­ear think­ing applied to such com­plex­i­ty may lead to painful mistakes.

Although reduc­tion­ism — under­stand­ing a sys­tem by under­stand­ing its com­po­nents — has been suc­cess­ful in sci­ence, it is gen­er­al­ly accept­ed that it can­not bring us too far.

01fig04Holism — that some­times is per­ceived as the oppo­site of reduc­tion­ism — sug­gest that the behav­ior of a sys­tem can­not be deter­mined by its com­po­nent parts alone. For instance, there is more in a human being that its anatom­i­cal parts. There­fore, to under­stand a com­plex sys­tem, we need a holis­tic view over it.

Man­age­ment 3.0 is a mod­el for Agile man­age­ment, which applies com­plex­i­ty think­ing to Agile soft­ware devel­op­ment teams.

Chap­ter 2: Agile soft­ware development

The Agile move­ment was the result of putting togeth­er the expe­ri­ence gath­ered through dif­fer­ent attempts to “light­weight” the bureau­crat­ic process of soft­ware devel­op­ment in the ear­ly 90’s. A num­ber of per­sons got to ini­tia­tive to hold a con­fer­ence in 2001, where they elab­o­rat­ed the Agile Man­i­festo. It was ini­tial­ly per­ceived as a reac­tion to for­mal­ized clas­si­cal process­es, full of doc­u­men­ta­tions and wast­ed time and bud­get, but very few noticed that the man­i­festo was equal­ly stat­ing its oppo­si­tion to chaot­ic process­es, undis­ci­plined pro­gram­mers and low-qual­i­ty soft­ware prod­ucts.

Accord­ing to Appe­lo the fun­da­men­tals of Agile may be struc­tured in 8 dimensions:
Agile rec­og­nize that peo­ple are unique indi­vid­u­als and not replace­able resources. It counts on moti­vat­ed indi­vid­u­als that are self-orga­niz­ing their work, with account­abil­i­ty for their work.
Agile under­stands that the best prod­ucts are built when cus­tomers are direct­ly involved with the teams that cre­ate them. The require­ments are spec­i­fied in a con­cise man­ner, being detailed while they are select­ed for imme­di­ate implementation.
For hav­ing suc­cess­ful prod­ucts, qual­i­ty is cru­cial. There­fore Agile pro­motes tech­niques that sup­port this goal by Test-Dri­ven Devel­op­ment, code reviews, def­i­n­i­tion of done and refactoring.
There are two types of use­ful tools in Agile: the ones that replace repet­i­tive and bor­ing tasks (dai­ly builds, con­tin­u­ous inte­gra­tion and auto­mat­ed tests) and the ones that radi­ate infor­ma­tion to sup­port a col­lab­o­ra­tive envi­ron­ment (task boards and burn charts).
Agile projects deliv­er results in time-boxed inter­vals, often called sprints or iter­a­tions, each one end­ing with a poten­tial­ly ship­pable prod­uct. This allows cus­tomers to ben­e­fit as ear­ly as pos­si­ble from the soft­ware imple­men­ta­tion. On the oth­er hand the team should always strive to main­tain its devel­op­ment speed almost indef­i­nite­ly to allow pre­dictable future shipments.
One of the core con­cepts embed­ded in Agile is the need to respond to change — fea­tures that were valu­able at a cer­tain point in time, even if deliv­ered to end-user, may become use­less lat­er. Agile tries to cope with this through short feed­back loops and deliv­ery cycles. Thus the busi­ness val­ue of soft­ware devel­op­ment is maximized.
Agile sug­gests a peo­ple-over-process par­a­digm, but this does­n’t mean that the process is not impor­tant. On the con­trary. Min­i­mal plan­ning, dai­ly face-to-face com­mu­ni­ca­tion, mea­sure­ment of progress through work­ing soft­ware assess­ment and reg­u­lar reflec­tion upon per­for­mance are manda­to­ry parts of the Agile thinking.
There are often sit­u­a­tions when Agile prac­ti­tion­ers do not exact­ly agree upon some of the inter­pre­ta­tions asso­ci­at­ed with cer­tain con­cepts. This also part of the Agile fun­da­men­tals. At the end of the day the point is being among peo­ple who enjoy some things more than try­ing to improve on one another.

There is also a sort of com­pe­ti­tion for Agile move­ment, which is main­ly rep­re­sent­ed by Lean soft­ware devel­op­ment. Inspired in its prin­ci­ples by the Toy­ota improve­ment process­es, Lean soft­ware devel­op­ment is actu­al­ly over­lap­ping in many ways with Agile, thus bring­ing a more man­age­r­i­al view upon the improve­ment of the devel­op­ment process. A new­com­er in this com­pe­ti­tion is Soft­ware Crafts­man­ship move­ment, that adds on top of Agile some of its own prin­ci­ples: well-craft­ed soft­ware, steadi­ly adding val­ue, com­mu­ni­ty of pro­fes­sion­als and pro­duc­tive part­ner­ships with the cus­tomers. The old-school method­olo­gies are not idle, try­ing to keep the pace — PMI has devel­oped an Agile body of knowl­edge, CMMI has evolved into a frame­work that some are see­ing as com­ple­men­tary to Agile, while the Uni­fied Process (try­ing to com­bine the clas­si­cal and the agile approach­es) are con­tin­u­ous­ly evolv­ing from the vast Ratio­nal Uni­fied Process toward more sim­pli­fied ver­sions, such as Agile Uni­fied Process ans Open Uni­fied Process.

The obsta­cles that stay in front of Agile are main­ly relat­ed to man­age­ment issues, par­tic­u­lar­ly relat­ed to a lack of under­stand­ing of roles in an Agile organization.

Chap­ter 3: Com­plex sys­tems theory

03fig01Com­plex­i­ty sci­ence is a mul­ti­dis­ci­pli­nary approach into sys­tems, which builds on ear­li­er achieve­ments in the field of gen­er­al sys­tem the­o­ry, cyber­net­ics, dynam­ic sys­tem the­o­ry, game the­o­ry and evo­lu­tion­ary theory.

It is wide­ly acknowl­edged that find­ings in com­plex­i­ty sci­ence can be applied to social sys­tems, like soft­ware devel­op­ment teams and man­age­ment, though is still unclear how far we can go in copy­ing sys­tem con­cepts from one dis­ci­pline to another.

03fig02Sys­tems may be ana­lyzed from the per­spec­tive of two dimen­sions: struc­ture and behav­ior. The struc­ture may be sim­ple or com­pli­cat­ed, mak­ing it eas­i­er or more dif­fi­cult to under­stand it. The behav­ior may be ordered (ful­ly pre­dictable), com­plex (some­what pre­dictable, but with many sur­pris­es) or chaot­ic (very unpredictable).

One impor­tant find­ing is that com­plex­i­ty (an indi­ca­tion of pre­dictabil­i­ty) is dif­fer­ent from com­pli­cat­ed­ness (an indi­ca­tion of under­stand­abil­i­ty). Anoth­er find­ing is that many com­plex sys­tems can adapt to chang­ing envi­ron­ments, in which case we call them com­plex adap­tive sys­tems (CAS). Social com­plex­i­ty is the study of social groups as com­plex adap­tive systems.

Chap­ter 4: The infor­ma­tion-inno­va­tion system

04fig03The soft­ware devel­op­ment teams are com­plex adap­tive sys­tems that are essen­tial­ly trans­form­ing infor­ma­tion in inno­va­tion. Although inno­va­tion is prob­a­bly debat­able as a term, the unique­ness of soft­ware code fits to the def­i­n­i­tion (we are not talk­ing about inventions).

There are five nec­es­sary cogs to trans­form infor­ma­tion into innovation:
Knowl­edge, which is the fuel for ino­va­tion and is con­sis­tent­ly and con­tin­u­ous­ly built by the accu­mu­lat­ed input of edu­ca­tion, learn­ing and expe­ri­ence;
Cre­ativ­i­ty, which trans­forms knowl­edge in val­ue, con­sist­ing in ideas that are both orig­i­nal and use­ful and may be per­ceived through a five-step process: prepa­ra­tion — incu­ba­tion — inti­ma­tion — illu­mi­na­tion — verification;
Moti­va­tion, which is the activation/energization of a goal-ori­ent­ed behavior;
Diver­si­ty, aka het­ero­gene­ity, which is impor­tant to cre­ate sta­bil­i­ty and resilience to envi­ron­men­tal changes;
Per­son­al­i­ty, as a sum of virtues like trust, respect, hon­esty — the right recipe depends on many things.

Peo­ple are the only ones that can tran­form infor­ma­tion into inno­va­tion. There­fore peo­ple are impor­tant. But there is anoth­er rea­son why peo­ple are impor­tant and it has to do with the Law of Req­ui­site Vari­ety (W. Ross), which states that a sys­tem can be con­trolled by anoth­er sys­tem only when the oth­er sys­tem is as com­plex or more com­plex than the first one. There­fore the con­trol mech­a­nism of any project should rely on peo­ple, not on process­es and tools.

Chap­ter 5: How to ener­gize people

Ener­giz­ing peo­ple has to do with 4 of the 5 cogs described in chap­ter 4: cre­ativ­i­ty, moti­va­tion, diver­si­ty and per­son­al­i­ty. Knowl­edge is more relat­ed to devel­op­ing com­pe­tence and will be dis­cussed lat­er, in the appro­pri­ate chapter.

There are 3 types of creativity:

  • Pre­con­ven­tion­al cre­ativ­i­ty, found in very young chil­dren, when you try things because you are not aware of the con­ven­tion­al constraints
  • Con­ven­tion­al cre­ativ­i­ty, found chil­dren between 7 to 11 years old, when you try only the things that are not vio­lat­ing the constraints
  • Post­con­ven­tion­al cre­ativ­i­ty, found in old­er chil­dren and in adults, when you try things despite the con­straints you are aware of.

Man­ag­ing a cre­ative envi­ron­ment means to:

  • ensure safe­ty, so peo­ple feel ok to share crazy thoughts and strange ideas
  • allow for play­ing games, to chal­lenge peo­ple minds and prac­tice own talents
  • nur­ture vari­a­tion, as rou­tines are killing creativity
  • cre­ate vis­i­bil­i­ty, to stim­u­late visu­al think­ing and shar­ing understanding
  • encour­age peo­ple to dis­cov­er their edges, admit­ting that exit­ing own com­fort zone is bring­ing peo­ple in a cre­ative state of mine

While a lot of cre­ative tech­niques may be applied,  they all fall into sev­er­al categories:

  • Process — tech­niques that describe a process to gen­er­ate cre­ative solu­tions, usu­al­ly through the rep­e­ti­tion of sev­er­al steps, while using oth­er tech­niques for each step (Cre­ative Prob­lem Solv­ing, Pro­duc­tive Think­ing Mod­el, Synec­tics etc)
  • Prob­lem def­i­n­i­tion — tech­niques that deal with prob­lem analy­sis and rede­f­i­n­i­tion to make it more under­stand­able (Chunk­ing, 5W1H, Bound­ary Exam­i­na­tion etc)
  • Idea gen­er­a­tion — tech­niques that stim­u­late find­ing as many solu­tion as pos­si­ble to a giv­en prob­lem (Brain­storm­ing, Talk­ing Pic­tures etc)
  • Idea selec­tion — tech­niques that are focus­ing on select­ing the best solu­tion among the iden­ti­fied ones (Anony­mous Vot­ing, Con­sen­sus Map­ping, Stick­ing Dots etc)

There are basi­cal­ly two types of moti­va­tion that a man­ag­er can choose to nur­ture with­in a team: extrin­sic moti­va­tion and intrin­sic moti­va­tion.

Extrin­sic moti­va­tion is basi­cal­ly a reward offered for achiev­ing a cer­tain objec­tive,. where the reward is com­plete­ly exter­nal to the objec­tive itself. This type of moti­va­tion is based on the The­o­ry X of pro­fes­sor Dou­glas McGre­gor, which states that peo­ple pre­fer not to work and some incen­tive must be pro­vid­ed to them to con­vince them to make an effort. This is a very deter­min­is­tic and lin­ear way of under­stand­ing human behav­ior, assum­ing that the reward A leads direct­ly to the result B.

Intrin­sic moti­va­tion is a reward that is encap­su­lat­ed in the results achieved by the team. Is when the team finds a moti­va­tion for work with­in the work itself and its achieve­ments. This is based on the The­o­ry Y of the same pro­fes­sor, which assumes that peo­ple enjoy their phys­i­cal and men­tal duties, based on their innate desire to do well. The deter­min­is­tic, lin­ear per­cep­tion is thus elim­i­nat­ed : the reward A is exact­ly the expect­ed result B. Intrin­sic moti­va­tions is always to be pre­ferred over extrin­sic ones.

Demo­ti­va­tion is anoth­er con­cern for an Agile man­ag­er. Here the Herzberg (Moti­va­tor-Hygiene) The­o­ry applies: some things — called hygiene fac­tors — might not moti­vate peo­ple through their exis­tence, but strong­ly demo­ti­vate them through their absence. In oth­er words, remov­ing demo­ti­va­tors does not auto­mat­i­cal­ly lead to a stronger motivation.

To deter­mine what should be encap­su­lat­ed in the intrin­sic moti­va­tion, we need to under­stand the Self-deter­mi­na­tion The­o­ry, which dif­fer­en­ti­ates between 3 main intrin­sic needs: com­pe­tence, auton­o­my and relat­ed­ness. A sim­i­lar the­o­ry was for­mu­lat­ed by Steven Reiss, nom­i­nat­ing 16 basic desires that guide every human behav­ior. Based on this the­o­ry, elim­i­nat­ing those desires that are not relat­ed to a busi­ness con­text (eat­ing, romance, fam­i­ly and vengeance) a set of 10 desires can be con­sid­ered as moti­vat­ing any team member:

  1. Feel­ing competent
  2. Feel­ing accepted
  3. Curios­i­ty
  4. Hon­or (loy­al­ty to a group formed using self-defined rules)
  5. Ide­al­ism (pur­pose)
  6. Inde­pen­dence (auton­o­my)
  7. Order (the need for min­i­mal rules and policies)
  8. Pow­er (abil­i­ty to influ­ence oth­ers and the environment)
  9. Social con­tacts (relat­ed­ness)
  10. Sta­tus (feel­ing impor­tant inside the organization)

A moti­va­tion­al bal­ance sheet — which is a per­son­al list of things that motivates/demotivate a per­son — should be used to deter­mine how to cre­ate intrin­sic motivation.

Is the abil­i­ty of a team mem­ber, espe­cial­ly the new­com­ers, to estab­lish dif­fer­ent types of con­nec­tions with oth­ers. This abil­i­ty should be assessed when hir­ing and is as impor­tant as competencies.

The per­son­al­i­ty of a team is the result of the inter­ac­tions between each indi­vid­ual per­son­al­i­ty. There should be enough diver­si­ty in terms of per­son­al­i­ty to make the team sta­ble, flex­i­ble and resilient, but there must be also enough com­mon ground to pro­vide cohe­sive­ness and abil­i­ty to resolve conflicts.

Indi­vid­ual per­son­al­i­ty may be assessed through var­i­ous tools, such as the Six­teen Per­son­al­i­ty Fac­tor Ques­tion­naire, Myers-Brig­gs Type Indi­ca­tor, Ennea­gram of Per­son­al­i­ty or the Big Five Fac­tors of Per­son­al­i­ty, which is seen as the most pow­er­ful tool in eval­u­at­ing per­son­al­i­ty psychology.

Assess­ing the team per­son­al­i­ty can be achieved through 3 steps, plus a an option­al fourth step:

  • the man­ag­er takes the test
  • the man­ag­er shares the test results with the team
  • team mem­bers are pri­vate­ly tak­ing the test and share results with the manager
  • [option­al] team mem­ber share test results with each others

Also a set of team com­mon val­ues should be defined. This can be achieved through a DIY Val­ue Kit:

  • print the Big List of 50 Virtues and give a copy to each team mem­ber (Agile/Scrum/Lean prin­ci­ples are includ­ed and high­light­ed with bold letters)
  • tell each of them that they must select between 3 and 7 val­ues that are the most impor­tant for them
  • [option­al] do the same with stake­hold­ers out­side the team (main­ly exter­nal customers)
  • get togeth­er and com­pare the select­ed virtues
  • dis­cuss mutu­al expec­ta­tions until reach­ing a com­mon list of 3 to 7 virtues
  • dis­play those virtues every­where pos­si­ble (posters, mugs, screen­savers etc)
Accu­ra­cy Cre­ativ­i­ty Hon­esty Per­sis­tence Sim­plic­i­ty
Assertive­ness Curios­i­ty Humor Prag­ma­tism Skill
Aes­thet­ics Deci­sive­ness Indus­tri­ous­ness Pur­pose­ful­ness Stew­ard­ship
Bal­ance Deter­mi­na­tion Ini­tia­tive Ratio­nal­i­ty Tact­ful­ness
Cau­tion Endurance Integri­ty Reli­a­bil­i­ty Thor­ough­ness
Clean­li­ness Enthu­si­asm Joy­ful­ness Resilience Tol­er­ance
Com­mit­ment Excel­lence Knowl­edge Respect Trust
Con­fi­dence Flex­i­bil­i­ty Mind­ful­ness Respon­si­bil­i­ty Trust­wor­thi­ness
Coöper­a­tion Focus Open­ness Self-dis­ci­pline Uni­ty
Courage Help­ful­ness Order­li­ness Ser­vice Vision

Chap­ter 6: The basics of self-organization

Self-orga­ni­za­tion is the nat­ur­al way things are hap­pen­ing in the known uni­verse. In con­trast, com­mand-and-con­trol is a quite recent par­a­digm invent­ed by humans to dri­ve things and peo­ple toward a pre­de­fined result. But it is not a nat­ur­al way. In this per­spec­tive it is rather strange to con­sid­er that self-orga­ni­za­tion is a new approach to com­plex sys­tems, as it has hap­pened since the begin­ning of time.

Self-orga­ni­za­tion hap­pens in a con­text. More than that, no self-orga­niz­ing sys­tem exists with­out a con­text. And the con­text has a huge influ­ence to the way the sys­tem is self-orga­niz­ing, by intro­duc­ing con­straints and directions.

Self-orga­ni­za­tion must hap­pen toward val­ue. Val­ue can be defined in var­i­ous way, but it is also true that self-orga­ni­za­tion may hap­pen toward bad results. In soft­ware devel­op­ment the val­ue is the one defined by the cus­tomer, there­fore there should be less debates about oppor­tu­ni­ty or moral­i­ty of the result.

06fig01Self-orga­ni­za­tion is a a form of accept­able anar­chy. The term anar­chy defines the absence of order and/or for­mal author­i­ty, which is part­ly true, as a self-orga­niz­ing sys­tem does not rely on pre­de­fined rules or exter­nal man­age­ment. Still, to some peo­ple anar­chy leads to chaos, but this is not the goal of self-orga­ni­za­tion. When the behav­ior of the sys­tem involves a cer­tain degree of com­plex­i­ty, self-orga­ni­za­tion should bring as much order as pos­si­ble (while keep­ing the effi­ca­cy). So the simil­i­tude between self-orga­ni­za­tion and anar­chy is lim­it­ed to the absence of for­mal authorities.

Self-orga­ni­za­tion should trig­ger emer­gence. Emer­gence is the abil­i­ty of a sys­tem com­posed of dis­tinct and dif­fer­ent parts to have prop­er­ties that are not present in any of their com­po­nents. This is how self-orga­niz­ing teams are mak­ing col­lec­tive deci­sions and have a con­sis­tent view of their objec­tives, despite the dif­fer­ent indi­vid­ual views of each team mem­ber. A self-orga­niz­ing sys­tem that has emer­gence is more than just the sum of its parts.

The Dark­ness Prin­ci­ple states that each com­po­nent of a sys­tem should be igno­rant of all behav­iors of the entire sys­tem. Oth­er­wise, the part that “knows” the entire sys­tem is the sys­tem itself and makes all oth­er parts useless.

Del­e­ga­tion of con­trol is the only valid response to the Conant-Ash­by The­o­rem (Every good reg­u­la­tor of a sys­tem must have a mod­el of that sys­tem). Self-orga­niz­ing sys­tems that are too com­plex to have a valid exhaus­tive mod­el of them must del­e­gate con­trol to the sub­sys­tems that are clos­er to the infor­ma­tion need­ed for con­trol. Dis­trib­uted con­trol is manda­to­ry for a com­plex sys­tem to work.

Empow­er­ment is a con­cept of del­e­gat­ing both the respon­si­bil­i­ty and the author­i­ty of mak­ing deci­sions. Empow­er­ment is a neces­si­ty for self-orga­niz­ing sys­tems to func­tion prop­er­ly. Instead of focus­ing on con­trol­ling and decid­ing, a man­ag­er should be a Gard­ner that grows and nur­ture the system.

Chap­ter 7: How to empow­er teams

Do not cre­ate moti­va­tion­al debt. Peo­ple don’t want to be told what to do, they want to be asked. Wear a wiz­ard’s hat. A man­ag­er is not there to do the work, but to sup­port the team to succed.

Empow­er­ment is more than del­e­ga­tion. Empow­er­ment includes also a sup­port of the man­ag­er for risk tak­ing, per­son­al growth and cul­tur­al change. Empow­er­ment is key for the man­age­abil­i­ty of a com­plex sys­tem. Reduce the fear of empow­er­ing peo­ple, and increase the sta­tus by lead­ing pow­er­ful teams.

Choose the right matu­ri­ty lev­el (low, mod­er­ate or high empow­er­ment) depend­ing on their expe­ri­ence an exper­tise. Bring every­one to the high empow­er­ment lev­el, but not by skip­ping stages.

07fig01Pick the right author­i­ty lev­el (tell=decide and tell them, sell=decide and sell to them, consult=ask opin­ion then decide, agree=jointly decide, advise=share your opin­ion and let them decide, inquire=let them decide then ask ques­tions, delegate=just let them decide) depend­ing on the impor­tance of each task.

Apart from choos­ing the right matu­ri­ty and author­i­ty lev­el, assign teams or indi­vid­u­als to each task.

The del­e­ga­tion checklist

  1. Is the risk fac­tor of del­e­gat­ing this work ade­quate­ly addressed?
  2. Have you con­sid­ered and select­ed the right lev­el of authority?
  3. Have you con­sid­ered the ques­tion of del­e­gat­ing to indi­vid­u­als or to teams?
  4. Have you con­sid­ered the best order of del­e­gat­ing this work ver­sus oth­er work?
  5. Is what you are del­e­gat­ing a dis­crete chunk of work?
  6. Do the peo­ple have the skills to do this par­tic­u­lar kind of work?
  7. Do the peo­ple have the right for­mat for the work prod­ucts to use?
  8. Do the peo­ple have the tools nec­es­sary to be successful?
  9. Do the peo­ple know what the results should look like?
  10. Have you set the bound­ary con­di­tions for the work (e.g. bud­get, time, resources, quality)?
  11. Do the peo­ple know when the work is due?
  12. Do the peo­ple know what progress looks like?
  13. Do the peo­ple know how often to report to you on progress (adher­ing to inter­im milestones)?
  14. Is some­one avail­able (you or anoth­er per­son) to coach or men­tor the peo­ple in case they need help?

When empow­er­ing peo­ple, prac­tice patience and resist your man­ager’s resis­tance. Always try to address peo­ple’s 10 intrin­sic desires, the ones inves­ti­gat­ed ear­li­er (chap­ter 5). Make sure that the envi­ron­ment is sup­port­ive with empowerment.

Trust and respect are fun­da­men­tal virtues to the empow­er­ment. With­out them empow­er­ment does­n’t work.

There are 4 actions for build­ing trust relationships:

  1. Trust the team, which means to empow­er peo­ple and give them an hon­est chance to prove themselves.
  2. Earn the trust of the team, by walk­ing the talk.
  3. Help team mem­bers to trust each oth­er by encour­ag­ing com­mu­ni­ca­tion and com­mit­ment. Make sure peo­ple have the right oppor­tu­ni­ties and tools to com­mu­ni­cate and that com­mit­ments are kept. When com­mit­ments are not reach­able, make sure the respon­si­ble ones are com­mu­ni­cat­ing it ear­ly and fully.
  4. Trust your­self

Respect peo­ple, ask for feedback.

Be respect­ed, give feedback.

Chap­ter 8: Lead­ing and rul­ing on purpose

Chap­ter 9: How to align constraints

Chap­ter 10: The craft of rulemaking

Chap­ter 11: How to devel­op competence

Chap­ter 12: Com­mu­ni­ca­tion on structure

Chap­ter 13: How to grow structure

Chap­ter 14: The land­scape of change

Chap­ter 15: How to improve everything

Chap­ter 16: All is wrong, but some is usefull

Genre: Agile, Lead­er­ship, Man­age­ment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.