”Peter principle” spune că o persoană va fi promovată succesiv până va ajunge la nivelul maxim de incompetență. O promovare se face pe baza realizărilor din poziția curentă și nu neapărat după o evaluare a potrivirii cu poziția în care se promovează. Ținând cont că la un moment dat nu mai sunt poziții pe care ar putea fi promovați înseamnă că pe poziția la care au ajuns nu mai performează.
Dacă tu, cititorule încă mai ai poziții pe care poți fi promovat înseamnă că încă nu ți-ai atins nivelul tău maxim de incompetență.
Există și un revers al acestui principiu care spune că dacă ești foarte bun în ceea ce faci există posibilitatea de a nu fi promovat pentru că înlocuirea ta ar fi prea complicată.
”Peter principle” se aplică și în ingineria software pentru a descrie un proiect care se apropie de finalul vieții sale pentru că a devenit încetul cu încetul mult prea complex pentru a fi înțeles și menținut de către cei care îl dezvoltă.
Zic încet și sigur pentru că atunci când simptomele acestei probleme apar, de obicei e prea târziu pentru a face vreo ceva rapid pentru soluționare. Motivele sunt multe și diverse dar țin să enunț vreo câteva: bad management (ca să nu zic management prost), lipsa unei arhitecturi coerente și a unei echipe care să o mențină și să o impună, urmărirea unui roadmap determinat de time to market (adică urgențe peste urgențe), lipsa unor requirementuri de calitate, lipsa comunicării cu clientul (top to bottom și invers), incompetența programatorilor.
Termenul a fost inventat de către Laurence J. Peter și popularizat în cartea din 1969 The Peter Principle: Why Things Always Go Wrong. Chiar dacă au trecut 46 de ani de atunci am impresia că aceleași probleme există și în vremurile noastre (dar eu n-am auzit de așa ceva niciodată; ce glumeț sunt).
Pentru lectura suplimentară: Peter Principle și Software Peter Principle
