Management 3.0

by Jurgen Appelo

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 21^st 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.

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.

Holism — 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.

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:
— Peo­ple
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.
— Func­tion­al­i­ty
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.
— Qual­i­ty
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.
— Tools
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).
— Time
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.
— Val­ue
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.
— Process
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.
— Con­flict
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.

Com­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.

Sys­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.

The 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.

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.

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.

Self-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.

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.

Pick 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.

…

…

…

…

…

…

…

…

…