Ce livre est un peu le pendant de manager’s path[1] mais à la place des personnes techniques qui managent d’autres personnes, Tanya Reilly s’adresse aux “staff engineer”, c’est-à-dire aux personnes techniques ayant dépassé le rang de senior mais qui ne managent personne.
Pour les staff engineer mais pas seulement
Ce type de poste, plus rare que celui de manager, serait d’après l’auteure en développement.
D’après le livre il permet deux choses :
-
de proposer une progression de carrière aux personnes que le management n’intéresse pas,
-
que des personnes ayant l’expérience nécessaire pour porter des chantiers techniques complexes aient le temps nécessaire pour le faire correctement, leur agenda n’étant pas accaparé par les tâches de management.
Une partie du livre s’adresse spécifiquement à ce public en traitant des particularités de ce rôle, en discutant par exemple de la difficulté de se faire une place dans une organisation où on occupe un type de poste un peu à part.
Mais la plus grande partie du livre traite de sujets qui devraient intéresser un public plus large comme les personnes ayant en charge des sujets techniques qui concernent plusieurs équipes, même si elles font aussi du management, mais aussi ceux et celles ayant des responsabilités techniques à l’intérieur d’une équipe.
Trois sujets m’ont particulièrement intéressé
Qu’est ce qu’on fait maintenant ?
Quand une personne technique gagne en séniorité, on peut attendre d’elle qu’elle réalise correctement des tâches mais aussi qu’elle suive des chantiers techniques et même qu’elle identifie et propose des actions à mettre en œuvre.
Par ailleurs, plus d’expertise signifie aussi plus de sollicitations, pour par exemple donner son avis sur du code, une proposition de design, ou participer à un groupe de travail.
Comme il n’y a pas assez de temps pour tout faire, les personnes doivent choisir sur quoi travailler et de quelle manière (quel niveau d’implication ? combien de temps investir ? que laisser tomber quand il y a une urgence ou un changement de stratégie ?), et être en mesure de convaincre les autres que leur choix est le bon.
C’est d’autant plus difficile que sur les projets plus gros les attentes sont plus floues (par exemple s’assurer qu’une migration “se passe bien”) et que les interlocutrices et interlocuteurs ne sont pas forcément d’accord sur les objectifs et les priorités.
Besoin de convaincre
Quand une personne est responsable d’un chantier au-delà d’une certaine taille, il est rare qu’elle puisse tout faire du sol au plafond. Cela signifie qu’il est nécessaire de demander à d’autres personnes de contribuer, même si elles n’y ont pas forcément un intérêt direct et si elles n’ont pas que ça à faire.
C’est d’autant plus vrai quand il s’agit d’un chantier que la personne aura elle-même identifié et qu’elle doit convaincre des supérieur·e·s d’y investir du budget et du capital politique.
Cela signifie savoir convaincre. On peut avoir besoin d’arguments techniques, d’identifier à quels objectifs du chantier la personne sera sensible (voir modifier le chantier pour cela) ou d’influence personnelle et politique.
Cela passe par des échanges officiels (par exemple lors d’ateliers), mais aussi d’autres plus informels autour d’un café ou en se croisant dans un couloir.
Cela ne veut pas dire que tous les moyens sont bons ou qu’on peut exiger des personnes qu’elles deviennent des politiciennes retorses, mais on peut exiger qu’elles obtiennent un certain niveau de résultat dans ce domaine.
Il y a des personnes que ce genre de choses n’intéresse pas, voire qui les jugent dégradantes. La conséquence est qu’il est probablement difficile pour ces personnes d’occuper ce type de postes.
Donner l’exemple
Le dernier est le fait de donner l’exemple.
Une personne expérimentée peut avoir une influence volontaire sur les autres, en travaillant ensemble ou en les coachant. Mais une partie de l’influence est aussi moins visible, et passe par le fait de donner l’exemple.
En effet, quand une personne a des responsabilités dans une organisation, les autres vont inconsciemment l’observer et s’inspirer d’elle.
Cela signifie, que les gestes de la personne — qu’elle le veuille ou non — sont observés et vont être reproduits par les autres.
Cette responsabilité sur laquelle on n’a pas la main peut déstabiliser voir être oppressante : une personne peut très bien se sentir sûre d’elle dans la partie réalisation de son travail mais ne pas être à l’aise avec l’idée que son comportement ait une telle importance.
Au final
La lecture ne m’a rien appris de totalement nouveau mais m’a permis d’expliciter certaines choses que j’avais observées mais pas forcément formulées.
Il se lit facilement mais je ne l’ai pas trouvé très enthousiasmant. Le texte manque parfois de précision et j’ai été agacé par les nombreuses citations de staff enginneer d’entreprises prestigieuses dont l’intérêt n’est pas toujours évident et qui alourdissent le texte.
Je recommanderais de le lire après le manager’s path, y compris pour les personnes plus intéressées par le rôle de staff enginneer sauf si les sujets de management les rebutent vraiment, et de ne pas avoir peur de concentrer leur lecture sur les parties qui leur parlent le plus.
Quelques extraits qui ont attiré mon œil
Early in your career, if you do a great job on something that turns out to be unnecessary, you’ve still done a great job. At the staff engineer level, though, everything you do has a high opportunity cost, so your work needs to be important.
Geologists study plate tectonics, the way the huge pieces of the earth’s lithosphere move against each other over time, forming mountains and trenches and creating earthquakes and volcanic activity. Team tectonics have similar properties. As domains of responsibility smash against each other, they form an organizational terrain, complete with overlaps and conflict, ridges and chasms.
Reorganizations can disrupt communication between groups that need to work closely together. Teams that are under a heavy load can entrench and put up barriers. A new senior leader can cause an earthquake that reshapes the landscape overnight. Navigating an organization requires a topographical map.
It is fascinating to watch how information and opinions flow through a company and to see how unexpectedly they can become a plan of record. Suddenly everyone’s using a new acronym or holding a particular opinion, and it can be hard to see where that came from. A project that held great hope and promise is now dismissed as likely to fail. Everyone’s excited about microservices, or they’ve moved on from microservices and they’re curious about serverless, or they think a modular monolith is just pragmatic common sense. One team has approval to hire more people this year and another doesn’t. How did all of these decisions hap-pen? Was there a memo?
Some decisions seem to emerge from conversations without anyone really declaring that they’ve decided. Others happen more formally, but in rooms you’re not in. If you have a lot of ideas, it can be frustrating when you see other initiatives take root but not yours. Why aren’t they listening to your proposals? The truth is something that a lot of us struggle to make peace with: being technically correct about a direction is only the beginning. You need to convince other people too — and you need to convince the right people.
If you don’t understand how decisions are made in your organization or company, you’ll find yourself unable to anticipate or influence them. You might also find that you think you hold the same opinions as everyone else about what should happen next, and then find that suddenly everyone is advocating for a different path. If you consistently feel out of the loop, that’s a sign that you don’t understand how decisions are made and who influences them.
Choosing your focus can be one of the most painful parts of writing a strategy.
Leadership work can be unpredictable. A crisis, outage, or launch can cause a load spike. If a project needs more help than you predicted, you might find yourself oversubscribed. So, when you’re filling your schedule, think about how volatile your incoming workload might be.
If you allocate 100% of your time and something unexpected happens, your choices are to drop something or run beyond capacity. If a lot of your tasks aren’t time-sensitive, dropping things might be easy. But if you fill your schedule with only important things, then when you hit your limit, by definition you’re dropping something important. If you decide not to drop anything, then work life will inevitably spill into other areas of your life, causing stress and exhaustion.
Know how many hours you want to work on an average week, how many you’re comfortable spiking to, and at what point you’ll stop being able to handle the load and fall over. I know people who run like the “A” person shown in Figure 4-3 and are completely unruffled when a crisis or an opportunity means they want to put in a few extra hours. I know others who work like person C, always right at their maximum capacity and stressed out all of the time. Try to leave at least a little buffer space if you can.
There’s a critically late project, a huge performance regression, or a scary incident — and you could save the day. Once again, it feels nice to be needed! And it can be oddly relaxing to join in on a crisis: the goals are usually very clear and there’s a bias toward action rather than consensus and planning. But it’s an abrupt transition.
If there’s a sudden crisis that calls for all hands on deck (or you on deck), you might be abruptly doing something else for a while, then returning to your regular project schedule. It’s a major context switch. It can be a bit jarring, and afterward it might take you some time to get back on track with whatever you were doing before. But helping out is often the right thing to do.
Remember, though, that if you do too much crisis response, it can be hard to find opportunities for growth, or to have much of a narrative for your work other than “I jumped on whatever the current fire was”.
In general, work that matters to the people in your reporting chain is work that builds social capital. Lest this start to feel really Machiavellian, I want to reiterate that this is just one aspect of the project! I suspect we all know the kinds of people who only optimize for looking good to leadership, and those aren’t people we tend to respect. But do keep an eye on your current standing with the people who influence your calibration, compensation, access to good projects, and future promotions. Managing up includes understanding your boss’s priorities, giving them the information they need, and solving the problems that are in their way — in other words, helping them be successful.
Their success gives them social capital that they can spend to help you.
The difficulty is the point. I find that I can handle ambiguity when I internalize that this is the nature of the work. If it wasn’t messy and difficult, they wouldn’t need you. So, yes, you’re doing something hard here and you might make mistakes, but someone has to. The job here is to be the person brave enough to make — and own — the mistakes. You wouldn’t have gotten to this point in your career without credibility and social capital. A mistake will not destroy you. Ten mistakes will not destroy you. In fact, mistakes are how we learn. This is going to be OK.
Think about who you’re going to talk with when the project is difficult and you’re feeling out of your depth. Your junior engineers are not the right people! While you can and should be open with them about some of the difficulties ahead, they’re looking to you for safety and stability. Yes, you should show your less seasoned colleagues that senior people are learning too, but don’t let your fears spill onto them. Part of your job will be to remove stress for them, making this a project that will give them quality of life, skills, energy, credibility, and social capital.
That doesn’t mean you should carry your worries alone. Try to find at least one person who you can be open and unsure with. This might be your manager, a mentor, or a peer: the staff engineer peers I discussed in Chapter 2 can be perfect here. Choose a sounding board who will listen, validate, and say “Yes, this stuff is hard for me too” rather than refusing to ever admit weakness or just trying to solve your problems for you. And, of course, be that person for them or others too.
We didn’t want to react constantly: we wanted to plan out our weeks, and to make these configuration changes in batches rather than continually restarting services every time. As a result, we had little sympathy for people who came in hot and angry about why we hadn’t done the thing they’d told us about only a few hours ago. Our team motto became “lack of planning on your part is not an emergency on mine”.
Most of all, you’ll be a role model. How you behave is how others will behave. You’ll be the voice of reason, the “adult in the room”. There will be times when you’ll think “This is a problem and someone should say something” and realize with a sinking feeling that that someone is you. When you model the correct behavior, you’re showing your less experienced colleagues how to be a good engineer.
As a leader, you have a responsibility to make the implicit explicit. It’s not fair, but if a junior person asks these questions, the team may sigh and say, yes, obviously we thought of that. If an expert asks, team members learn that they should include explicit answers to these questions in their design documentation. (Or they genuinely consider the question for the first time!)
If the meeting doesn’t have notes, was it really worth getting together? Meeting notes are a great example of glue work. If a junior person is taking notes, they’re unable to participate, and it’s considered low status administrative work. If a senior person takes notes, they’re making sure the meeting is effective, and everyone’s very impressed!
Meeting notes are a great lever for making progress on your projects, so don’t hesitate to volunteer to take them. You can record the facts you think are most important, document decisions made, and be the first to frame the deci-sion. Then you can invite everyone to confirm what you wrote. As a moderator, if you need to give everyone a moment to think and reflect, you can also say, “Wait a moment, I need to catch up with the notes”. They’re a useful flow control for the meeting.
If you’re itching to give unsolicited advice on a topic nobody is asking you about, consider writing a blog post or tweeting about it instead.
Process Preamble
Here’s the introduction I wrote for a process FAQ document at work. Feel free to use it if it’s helpful for you too.
There are a lot of questions about how <topic> should work. It’s hard to find a balance for how prescriptive to be with processes like this.
If you write nothing down, most people hate that and complain that they don’t know how to do anything.
If you write down guidelines, people interpret them as law and argue that they’re wrong because they don’t cover edge cases.
And if you write down every edge case, you end up with a three-ring binder of policy and legalese, and it probably still won’t cover every situation. And everyone still hates it!
This document attempts to give mostly correct answers to some frequently asked questions. These answers will not apply perfectly in every situation. Think twice before discarding them, but if they don’t make sense for a situation you’re in, do the thing that makes sense instead. All guidelines are wrong sometimes. (If these guidelines are wrong a lot, propose a change.)
When in doubt, think hard about the other humans involved in what you’re doing, assume they’re reasonable people trying their best, and also be a reasonable person trying your best.