Catégorie : Vie professionnelle

Extraits de The Mana­ger’s Path

Ce sous-chapitre m’a laissé mal à l’aise au début.

C’est une expé­rience person­nelle, un vécu raconté à la première personne. Il n’y a donc aucune argu­men­ta­tion possible. Il reste que j’y lis une façon de voir le projet à base de décou­page et d’es­ti­ma­tions qui n’est plus la mienne aujourd’­hui.

You’ll need to esti­mate project length for your mana­ge­ment team, and give some detail on why you believe things will take that long.

I had to take this incre­di­bly compli­ca­ted set of tasks and try to figure out which ones depen­ded on other ones. I had to think of all kinds of depen­den­cies. How would we make it work in the complex testing frame­work we depen­ded on? How would we deploy it? When did we need to order hard­ware to test it? How long would inte­gra­tion testing take?

I’m afraid that I will be held accoun­table and that I could miss some­thing impor­tant in the process that will make the project fail.

L’au­teure parle de peur, de crainte, de juge­ment du mana­ger, de moments pas fun, pour en tirer que c’est quand même néces­saire mais sans pour autant éclai­rer sur pourquoi.

Je mets ça sur ma liste à relire. Peut-être que je passe à côté du sujet prin­ci­pal.

Je retiens toute­fois ce qui suit, avec lequel je suis par contre en plein accord :

Ulti­ma­tely, the value of plan­ning isn’t that you execute the plan perfectly, that you catch every detail befo­re­hand, or that you predict the future; it’s that you enforce the self-disci­pline to think about the project in some depth before diving in and seeing what happens. […] The plan itself, howe­ver accu­rate it turns out, is less impor­tant than spen­ding time on the act of plan­ning. »

Extraits de The Mana­ger’s Path

This role requires you to have a good sense of the overall archi­tec­ture of your systems and a solid unders­tan­ding of how to design complex soft­ware. It proba­bly also requires you to be able to unders­tand busi­ness requi­re­ments and trans­late them into soft­ware. »

J’ai beau­coup parlé commu­ni­ca­tion et un peu prise de respon­sa­bi­lité, proba­ble­ment en me lais­sant guider par les cita­tions. Ici sort le troi­sième aspect qui me semble indis­pen­sable pour celui qui veut passer au-delà du rôle de déve­lop­peur senior : La prise en compte des besoins de l’en­tre­prise.

Oui il va falloir parler sens commer­cial, stra­té­gie de déve­lop­pe­ment, parte­na­riat, vélo­cité, coûts, et plein d’autres choses que notre qualité tech­nique ou que la fameuse dette tech­nique. Ces deux derniers items ne sont que des outils et pas des fina­li­tés.

Le senior s’ar­rê­tera à « il faut faire comme ça » alors que j’at­tends des rôles de lead et de staff la reflexion de « oui mais ce dont nous avons besoin aujourd’­hui c’est … ».

In a heal­thy orga­ni­za­tion, there is no shame or harm in raising issues early.

Cette petite phrase aurait à mon avis plus de place dans les premiers chapitres mais ça ne fait pas de mal de la rappe­ler.

Commu­niquer au plus tôt de la façon la plus trans­pa­rente possible. Non seule­ment ça permet­tra de répondre au problème plus tôt, mais ça dimi­nuera le stress de tout le monde.

La règle : On ne blâmera jamais quelqu’un pour lever de façon construc­tive une alerte, y compris très tôt. On pourra par contre repro­cher de ne pas l’avoir fait.

As projects move forward, unex­pec­ted obstacles arise. Some­times tech leads are temp­ted to go to heroics and push through these obstacles them­selves, working exces­sive over­time to get it all done.

J’ai envie de dire « ne le faites pas » mais la raison me pousse à être plus modéré. Ne le faites pas souvent. Faites le unique­ment de façon concer­tée après avoir levé le sujet à l’en­semble de l’équipe. Ne restez pas dans un rôle où vous seriez indis­pen­sable.

Passé la douzaine je ne veux plus de héros mais des membres d’une équipe qui colla­bore. L’im­pact indi­vi­duel devient moins impor­tant que l’im­pact collec­tif.

Extraits de The Mana­ger’s Path

Having the tech­ni­cal chops and matu­rity is nothing, howe­ver, if you can’t figure out the biggest trick of being a good tech lead: the willin­gness to step away from the code and figure out how to balance your tech­ni­cal commit­ments with the work the whole team needs. You have to stop relying enti­rely on your old skills and start to learn some new skills. You’re going to learn the art of balance. »

Je pensais trou­ver un passage sur la commu­ni­ca­tion, la moti­va­tion des équipes, le fait de donner du sens.

Je finis surpris mais assez en accord. La première diffi­culté du lead est de savoir arbi­trer son temps, et c’est bien la compé­tence fonda­men­tale pour réus­sir à chan­ger de rôle.

Sauter la partie tech­nique c’est ne plus être dedans et ne plus savoir correc­te­ment pilo­ter le projet. Trop s’ar­rê­ter sur la tech­nique est tentant puisque c’est ce qu’on sait faire, mais ça veut dire oublier son propre rôle.

L’ar­bi­trage n’est pas simple et, parce qu’il varie en fonc­tion des besoins, je doute qu’on arrive un jour à un équi­libre parfait. Si cet équi­libre existe je ne l’ai pas trouvé.

What’s worse, you’ll often need to balance doing things you know how to do and enjoy doing, such as writing code, with things you don’t know how to do

Je ne me souviens pas avoir vu de déve­lop­peur senior me disant vouloir être lead. En géné­ral c’est une aspi­ra­tion de junior qui voir le rôle comme une étape de plus sur sa progres­sion. Ces envies dispa­raissent quand on montre une voie de progres­sion en contri­bu­tion indi­vi­duelle.

La plupart des leads que j’ai vu passer sont des personnes qui y sont allés par besoin. Ce peut être de façon passive, parce qu’on a eu besoin d’un lead et qu’elles étaient le meilleur choix. Ce peut aussi être plus actif, en voulant résoudre les problèmes, et consi­dé­rer que si personne ne le fait ça n’évo­luera pas. Ce peut être enfin juste parce que c’est là qu’elles ont eu l’im­pres­sion d’être le plus effi­cace. Dans les trois cas c’est diffé­rent de « je veux faire ça parce que ça me plait ».

Il faut que ça plaise mais ce n’est, de mon expé­rience, par le moteur premier et je trouve ça parti­cu­liè­re­ment inté­res­sant. Ça fait sortir une carac­té­ris­tique commune : Le senti­ment de devoir agir et prendre la respon­sa­bi­lité qu’il faut pour ça. Les anglo­phones ont un mot pour ça : owner­ship.

Part of your leader­ship is helping the other stake­hol­ders, such as your boss and the product mana­ger, respect the team’s focus and set up meeting calen­dars that are not overw­hel­ming for indi­vi­dual contri­bu­tors. »

Extraits de The Mana­ger’s Path, début du troi­sième chapitre

Dire qu’on peut progres­ser en carrière sans passer mana­ger devient quasi­ment un lieu commun dans notre métier et tant mieux. Il y a de l’es­pace à prendre au-delà du déve­lop­peur senior.

The idea that the tech lead role should auto­ma­ti­cally be given to the most expe­rien­ced engi­neer, the one who can handle the most complex features or who writes the best code, is a common miscon­cep­tion

This is a senior engi­nee­ring role, but it’s a mistake to tie the notion of tech lead to one that boils down to the best or most expe­rien­ced engi­neer on the team. You can’t lead without enga­ging other people, and people skills are what we’re asking the new tech lead to stretch, much more than pure tech­ni­cal exper­tise. Howe­ver, tech leads will be working on one major new tech­ni­cal skill: project mana­ge­ment.

J’ai parfois l’im­pres­sion d’en­fon­cer les portes ouvertes en disant que le lead n’a pas forcé­ment à être le déve­lop­peur le plus expé­ri­menté, celui avec les compé­tences tech­niques les plus poin­tues, ou celui avec la plus grande exper­tise tech­nique.

Présenté comme je l’ai fait, j’ai géné­ra­le­ment un accord assez facile mais le revers de la médaille est plus complexe : Mon para­graphe précé­dent n’im­plique pas que le rôle de lead est un rôle moins expert ou de moins haut niveau. Ça sous-entends qu’il faut remettre en cause la hiérar­chie mentale basée sur l’ex­per­tise tech­nique ou la somme des connais­sance tech­niques.

C’est vrai quand on parle de lead ou de mana­ge­ment mais c’est aussi vrai sur les grilles de progres­sion de contri­bu­tion indi­vi­duelle dès qu’on dépasse le niveau de déve­lop­peur senior.

I could be the tech lead, despite not being the most senior person, because I was willing and able to take on the respon­si­bi­li­ties of the role, while the rest of my team were more inter­es­ted in staying purely focu­sed on the soft­ware they were writing.

I had a few advan­tages. For one, I was more than just a good engi­neer. I was a good commu­ni­ca­tor. I could write clear docu­ments, I could give presen­ta­tions without melting down, and I could talk to people in different teams and different roles and explain what was going on. I was also good at prio­ri­ti­zing. I was eager to push work forward and decide what needed to be done next. Finally, I was willing to pick up the pieces and do what needed to be done to make progress

L’im­por­tant n’est pas de poin­ter l’ex­per­tise, de savoir que vous décou­pez mieux le code ou que vous faites moins d’er­reur d’ar­chi­tec­ture. L’im­por­tant est de savoir quel est l’im­pact que vous avez dans l’équipe.

Being a tech lead is an exer­cise in influen­cing without autho­rity.

Je parle habi­tuel­le­ment de rayon­ne­ment. Le terme est parfois compris comme « se rendre plus visible ». Ça compte mais il n’y a pas que ça.

Vous pouvez avoir un fort impact par votre seule exper­tise tech­nique. C’est possible mais diffi­cile, parce qu’il faudra une sacré exper­tise tech­nique pour justi­fier qu’elle vous fasse passer au niveau suivant. Il est probable que, même avec une exper­tise de pointe, les compé­tences humaines comme la commu­ni­ca­tion avec les autres, votre volonté à prendre des respon­sa­bi­li­tés ou la façon dont vous les gérez, ou encore votre propen­sion à faire gran­dir les personnes autour de vous, vous retienne d’avoir l’im­pact auquel vous préten­dez. Ce sont ces compé­tences là qui vont jouer le plus.

Howe­ver, this was not an easy sell to the other deve­lo­pers, who wanted to write fun new features

Tech lead is not the job for the person who wants the free­dom to focus deeply on the details of her own code. A tech lead who does this is not doing her job.

Il n’y a aucun mal à vouloir être juste un très bon déve­lop­peur, d’ac­cu­mu­ler de l’ex­pé­rience et de l’ex­per­tise. C’est bien­venu. C’est juste que ce qu’on demande à ceux qui veulent aller plus loin est plus que ça.

Extraits de The Mana­­­­­­­ger’s Path

Senior engi­neers can deve­lop bad habits, and one of the worst is the tendency to lecture and debate with anyone who does not unders­tand them or who disa­grees with what they are saying. To work success­fully with a newco­mer or a more junior team­mate, you must be able to listen and commu­ni­cate in a way that person can unders­tand, even if you have to try seve­ral times to get it right. Soft­ware deve­lop­ment is a team sport in most compa­nies, and teams have to commu­ni­cate effec­ti­vely to get anything done.

Nous nous préva­lons de culture scien­ti­fique et de favo­ri­ser le débat. En réalité j’ai beau­coup vu de culture d’af­fron­te­ment et de conflit dans notre métier. Le débat est vu comme une oppo­si­tion, avec un gagnant et un perdant, et l’idée que l’objec­tif est de déter­mi­ner qui a raison.

Je pense qu’on a fait fausse route quelque part et ce para­graphe le met en lumière. Nous devrions mettre en avant l’écoute et la compré­hen­sion plutôt que l’ar­gu­men­ta­tion et l’op­po­si­tion.

Ce n’est pas qu’une idéo­lo­gique de Bisou­nours. C’est l’idée que la colla­bo­ra­tion prime sur le reste. Avoir raison ne suffit pas. Il faut aussi commu­niquer entre nous, et créer une équipe qui colla­bore effi­ca­ce­ment.

Souvent il n’y a pas qu’une solu­tion, pas qu’une vérité. Toutes les alter­na­tives ne sont pas fonda­men­ta­le­ment erro­nées. Notre objec­tif ne devrait pas être de prendre le meilleur choix comme s’il était unique, mais de prendre un des bons choix ensemble en favo­ri­sant l’unité et la colla­bo­ra­tion. Est-ce le meilleur ? Peut-être, peut-être pas, mais cette ques­tion est d’une impor­tance telle­ment moindre que les enjeux humains…

Your career ulti­ma­tely succeeds or fails on the strength of your network. Mento­ring is a great way to build this network. You never know — the person you mentor could provide the intro­duc­tion to your next job, or even come work for you in the future.

J’ai l’im­pres­sion d’avoir créé la surprise il y a deux mois en ajou­tant « créer un réseau de pairs hors de la société » dans la grille d’at­tentes et de progres­sion de carrière pour mes leads.

C’est utile pour l’en­tre­prise, parce que ça permet de voir ce qui se fait ailleurs, de progres­ser en se confron­tant aux autres idées, de prendre des bonnes idées et les repro­duire ou au contraire éviter de repro­duire les mauvaises.

C’est surtout utile pour la progres­sion indi­vi­duelles. J’ai beau­coup souf­fert par le passé de l’iso­le­ment que je me construi­sais moi-même. Je suis mauvais pour prendre l’ini­tia­tive des inter­ac­tions sociales et je n’osais pas poser des ques­tions sur des évidences. Et puis… à qui ?

Faites-vous votre réseau. Inves­tis­sez du temps pour ça. Faites en sorte de pouvoir poser des ques­tions à des personnes qui travaillent diffé­rem­ment, et à d’autres qui ont déjà parcouru le chemin que vous tentez.

Extraits de The Mana­­­­­­­ger’s Path

As a mana­ger you help your team succeed by crea­ting clear, focu­sed, measu­rable goals.

C’est répété un peu partout, expli­ci­te­ment ou impli­ci­te­ment, mais je pense que j’au­rais bien eu besoin de cette lourde répé­ti­tion il y a quelques années donc autant la repro­duire dans mes cita­tions.

Deve­lo­ping patience and empa­thy is an impor­tant part of the career path of anyone working in a team-based envi­ron­ment. Brilliant, intro­ver­ted deve­lo­pers may not ever want to formally manage, but encou­ra­ging them to mentor 1–1 helps them deve­lop stron­ger exter­nal pers­pec­tives, not to mention their own networks. Conver­sely, an impa­tient young engi­neer may find a degree of humi­lity when tasked with helping an intern succeed

Extraits de The Mana­­­­­­ger’s Path

Je n’aime pas trop ce sous-chapitre qui tend à créer une cari­ca­ture du pire sans au final donner des pistes construc­tives à part « atten­tion ».

Deux points tout de même :

She believes herself to be the best, and responds only to messages that support that view. The alpha geek tries to create a culture of excel­lence, but ends up crea­ting a culture of fear. »

C’est mon constant à chaque fois que j’ai croisé ce type de profil. Souvent très tech­nique, parfois excep­tion­nel, mais qui créé la peur et le conflit au lieu de tirer les autres vers le haut.

Le piédes­tal sur lequel on se place ou sur lequel on est mis malgré nous nous place dans une situa­tion qui ne sera jamais aussi effi­cace que celle de l’hu­mi­lité et de la coopé­ra­tion.

He has all the answers. She worked on

C’est inté­res­sant comme l’au­teure fait atten­tion à alter­ner le genre mascu­lin et fémi­nin pour chaque rôle, y compris dans le même para­graphe pour parler de la même personne.

On n’y porte rapi­de­ment plus atten­tion, et ça se lit faci­le­ment, mais ça permet de décons­truire les stéréo­types.

J’ai­me­rais voir ça plus souvent.

Extraits de The Mana­­­­­­ger’s Path

Many compa­nies run formal mento­ring programs where they match people up across teams, and while these programs can some­times enhance networks, they are often an ambi­guous obli­ga­tion for both the mentor and the mentee.

J’avoue que c’est aussi ce que je fais, avec des résul­tats inégaux.

La cita­tion me fait réflé­chir sur si ça a du sens ou pas. Donner des rôles humains arti­fi­ciels parti­cipe souvent à de la perte de sens.

Pour l’ins­tant j’agis aussi parce que je me sens dans une optique de trans­for­ma­tion. Il faut parfois passer par cette étape arti­fi­cielle pour déclen­cher des prises de conscience et des pratiques. Si ça reste trop arti­fi­ciel long­temps alors j’étein­drai proba­ble­ment pour rempla­cer par une inci­ta­tion « si tu veux un mentor, dis-le et quelqu’un se propo­sera ».

Tell your mentee what you expect from him. If you want him to come prepa­red for your meetings with ques­tions he has sent you in advance, ask for that.

On revient beau­coup sur l’idée de défi­nir expli­ci­te­ment les attentes. Je suis désor­mais convaincu que c’est une des bases du mana­ge­ment si on veut favo­ri­ser l’au­to­no­mie. Le livre se répète sous diffé­rentes facettes, mais fina­le­ment c’est un peu son rôle.

Prépa­rer ses 1–1 avec son mana­ger, lui poser les ques­tions en avance, ce sont deux attentes expli­cites que je pose sur les grilles de compé­tence. Ça vaut effec­ti­ve­ment certai­ne­ment avec les mentors aussi.

Whate­ver you do, don’t say yes and then fail to actually do the mento­ring work. 

Le point n’est pas encore abordé dans le livre mais il trans­pa­rait ici : Dites non à vos mana­ger.

Le mana­ger n’est pas Dieu. Il est capable de ne pas voir des choses, de ne pas savoir, de se trom­per. Lui dire quand ça ne fonc­tionne pas c’est le trai­ter avec respect et faire confiance dans son humi­lité.

Le pendant c’est être humble soi-même. Vous même ne savez pas tout, n’avez pas le point de vue propre au rôle de mana­ger. Vous n’avez pas non plus tous les enjeux person­nels qu’il cherche à équi­li­brer (et vous n’avez pas forcé­ment à les savoir, parce que c’est juste­ment des enjeux person­nels de tiers).

Dire non c’est aussi savoir le faire sur la discus­sion, en moti­vant et expliquant, puis en sachant poten­tiel­le­ment passer outre ensuite.

Les deux seules atti­tudes à éviter c’est dire oui alors que vous pensez non, ou dire non comme un point d’ar­rêt qui ne peut pas être renversé.

Extraits de The Mana­­­­­­ger’s Path

I didn’t know how to ask for help, and I was afraid that I would be seen as a fool if I did.

Le message que je trans­mets aux nouveaux c’est « Pose toutes les ques­tions main­te­nant, même celles qui te paraissent honteuses, parce que plus tu tardes plus tu auras honte de ne toujours pas savoir. L’in­té­gra­tion dans l’équipe t’offre l’op­por­tu­nité de le faire. » Le reste de l’on­boar­ding autour s’as­sure juste­ment qu’on fait le plus de choses dans les premières semaines pour savoir faire et que juste­ment, si ques­tion il y a, elle appa­rait le plus tôt possible. C’est gênant pour tout le monde si un ingé­nieur là depuis un an pose une ques­tion sur un outil d’usage quoti­dien (mise en prod, lecture des logs, etc.)

C’est ce que j’ai trouvé pour encou­ra­ger les ques­tions les premières semaines. En réalité je ne suis pas satis­fait de se message parce qu’il renforce l’idée qu’il y a des ques­tions qu’on ne devrait pas poser après un certain temps, et parce que je joue sur les complexes pour encou­ra­ger le compor­te­ment souhaité.

C’est ce qui me fait réagir sur cette cita­tion : Mettez en place un envi­ron­ne­ment où chacun se sent en toute sécu­rité à poser une ques­tion sur quelque chose qu’il ne sait pas. Ça implique de couper toute critique de la ques­tion, et remettre à leur place tous ceux qui répon­dront par « tu devrais le savoir » ou autre « quel noob ».

Poser une ques­tion c’est faire preuve d’hu­mi­lité, et ça sera toujours mieux que de faire semblant ou que de rester dans l’igno­rance.

A more subtle unspo­ken rule dictates approxi­ma­tely how long you are expec­ted to struggle with some­thing by your­self before asking someone else to help you.

C’est la règle impli­cite que j’ai vu partout, avec un « commence par cher­cher » dédai­gneux. Je la trouve toxique et contre-produc­tive.

Je fais confiance à la personne pour se rendre compte du temps qu’elle prend aux autres et de savoir si elle peut obte­nir sa réponse seule plus effi­ca­ce­ment. Je n’ai pas besoin de la forcer à tour­ner en rond pendant deux heures avant de poser sa ques­tion.

À l’op­po­ser, je n’ai pas envie de lui inculquer qu’on doit poser la ques­tion au bout de deux seules heures si ça coûte moins cher de cher­cher seul.

Infor­mez des coûts et faites confiance aux personnes qui ont des ques­tions. Le coût éven­tuel de poser des ques­tions trop faci­le­ment est insi­gni­fiant par rapport au risque d’une culture de défiance vis à vis du fait de poser des ques­tions.

Your job as a new hire mentor consists of onboar­ding, helping this person adjust to life in the company effec­ti­vely, and buil­ding your and her network of contacts in the company.

Le mentor peut-être un pallia­tif effi­cace. Il a du temps dédié et c’est son rôle. On fait sauter un peu de réti­cences et on ne peut pas répondre que la ques­tion génère de pertur­ba­tions : Le mentor est là pour ça.

Adopt the mind­set that network buil­ding is a worthw­hile invest­ment of your time and energy.

Et c’est vrai qu’on soit intro­verti ou extra­verti. Le rela­tion­nel interne a une valeur extra­or­di­naire, à la fois pour la société, pour son propre déve­lop­pe­ment et pour celui des autres.

Ce n’est pas une option pour ceux qui veulent faire du mana­ge­ment. C’est une étape indis­pen­sable pour deve­nir quelqu’un de meilleur, même si on choisi une orien­ta­tion d’ex­per­tise tech­nique.

Je commente ma lecture du livre The Mana­­­ger’s Path de Camille Four­nier sous-chapitre par sous-chapitre.

Il y a un flux RSS sur la page du tag, et une caté­go­rie plus géné­rale sur le mana­ge­ment.

Pour faci­li­ter le suivi, je vais tenir à jour le sommaire ici :

1. Mana­ge­ment 101
   • What to Expect from a Mana­ger
     • One-to-One Meetings
     • Feed­back and Work­place Guidance
     • Trai­ning and Career Growth
   • How to Be Mana­ged
     • Spend Time Thin­king About What You Want
     • Your Are Respon­sible for Your­self
     • Give Your Mana­ger a Break
     • Choose Your Mana­gers Wisely
2. Mento­ring
   • The Impor­tance of Mento­ring to Junior Team Members
   • Being a Mentor
     • Mento­ring an Intern
       • Listen care­fully
       • Clearly commu­ni­cate
       • Cali­brate your response
     • Mento­ring a New Hire
     • Tech­ni­cal or Career Mento­ring
   • Good Mana­ger, Bad Mana­ger: The Alpha Geek
   • Tips for the Mana­ger of a Mentor
   • Key Takea­ways for the Mentor
3. Tech Lead
   • All Great Tech Leads Know This One Weird Trick
   • Being a Tech Lead 101
   • Mana­ging Projects
   • Mana­ging a Project
   • Deci­sion Point: Stay on the Tech­ni­cal Track or Become a Mana­ger
   • Good Mana­ger, Bad Mana­ger: The Process Czar
   • How to Be a Great Lead
4. Mana­ging People
   • Star­ting a New Repor­ting Rela­tion­ship Off Right
   • Commu­ni­ca­ting with Your Team
   • Different 1–1 Styles
   • Good Mana­ger, Bad Mana­ger: Micro­ma­na­ger, Dele­ga­tor
   • Prac­ti­cal Advice for Dele­ga­ting Effec­ti­vely
   • Crea­ting a Culture of Conti­nuous Feed­back
   • Perfor­mance Reviews
   • Culti­va­ting Careers
   • Chal­len­ging Situa­tions: Firing Under­per­for­mers
5. Mana­ging a Team
   • Staying Tech­ni­cal
   • Debug­ging Dysfunc­tio­nal Teams: The Basics
   • The Shield
   • How to Drive Good Deci­sions
   • Good Mana­ger, Bad Mana­ger: Conflict Avoi­der, Conflict Tamer
   • Chal­len­ging Situa­tions: Team Cohe­sion Destroyers
   • Advan­ced Project Mana­ge­ment
6. Mana­ging Multiple Teams
   • Mana­ging Your Time: What’s Impor­tant, Anyways?
   • Deci­sions and Dele­ga­tion
   • Chal­len­ging Situa­tions: Stra­te­gies for Saying No
   • Tech­ni­cal Elements Beyond Code
   • Measu­ring the Health of Your Deve­lop­ment Team
   • Good Mana­ger, Bad Mana­ger: Us Versus Them, Team Player
   • The Virtues of Lazi­ness and Impa­tience
7. Mana­ging Mana­gers
8. The Big Leagues
9. Boots­trap­ping Culture
10. Conclu­sion

(le reste arrive avec le temps, je publie envi­ron une note par jour sur le lien donné plus haut)