- Tags:: ✍️OwnPosts , 🗣️OwnTalks , Engineering Management
- Created date:: 2023-05-28
Este artículo podría haber sido una charla
Trabajo como Engineering Manager y pienso que es un bullshit job
Soy Trabajo como Engineering Manager de equipos de datos, la mayoría de veces con el gorro de Technical Product Manager, y después de unos cuantos años con esto siento que estoy haciendo carrera de hacer/decir las mismas 3 o 4 cosas. Me siento un poco:
No voy a hablar de autoconfianza, que ya lo hice en ✍️ Sin machirulos hay paraiso. Una charla heterofriendly sobre management, ni tampoco del adanismo, que ya lo hice en ✍️ Refusing to stand on the shoulders of giants, si no de que estos trabajos son un poco “bullshit jobs”.
“Bullshit job” no es simplemente un “trabajo de mierda”, es una definición muy concreta del antropólogo David Graeber en 📖 Bullshit Jobs:
Link to originalFinal Working Definition: a bullshit job is a form of paid employment that is so completely pointless, unnecessary, or pernicious that even the employee cannot justify its existence even though, as part of the conditions of employment, the employee feels obliged to pretend that is not the case. (p. 9)
Este texto en realidad es el resultado de profundizar en por qué pienso esto, cómo es que no me dejo la profesión para irme a arar al campo, y cómo creo que esta actitud hasta me ayuda a desempeñar el curro bien.
¿Y qué si es un “bullshit job”?
Un “bullshit job” es una castaña para todo el mundo, para empezar, para uno mismo, en contra de lo que pudiera parecer. Uno necesita sentirse util. De 📖 Bullshit Jobs:
Link to originalThere is endless empirical evidence to back this [that people don’t want to do nothing] up. To choose a couple of particularly colorful examples: working-class people who win the lottery and find themselves multimillionaires rarely quit their jobs (and if they do, usually they soon say they regret it). (p. 82)
The first study was done by in the sixties by Nancy C. Moore and Robert S. Weiss: The function and meaning of work and the job. - PsycNET and has been replicated several times since with similar results: 74 to 80 percent of workers claim they would go on working if they suddenly got a fortune on their hands.
Link to original
German psychologist Karl Groos discovered in 1901 that we have “the pleasure at being the cause” of effects. We are happy to exercise our powers for the very sake of them, and it’s directly related to play, and, to our own very sense of self. This would be later explored by G. A. Klein, or Francis Broucek, among others (p. 83)
Link to original
Y por supuesto, un bullshit job también es una castaña para la sociedad en general que paga por algo que no debería existir… y no paga poco. De los que más panoja cobramos en tech:
De hecho, David Graeber cree que esto es una especie de prima por sufrir el tener un bullshit job (y el tl;dr de por qué esto pasa es una mezcla entre que “cuando el diablo no tiene nada que hacer, con el rabo mata las moscas”, y la visión del trabajo como algo moral).
En cualquier caso, ojo con desempeñar profesiones en la vida donde la peña se pase el rato dando charlas del tipo: “El rol de XXX en la empresa”. No hay charlas sobre el rol de un backend engineer en la empresa.
El rol del Engineering Manager en la empresa
Una de las cosas más flipantes del rol de Engineering Manager es que hay 200 libros sobre él pero prácticamente no hay definición (ni en 📖 The Manager’s Path, ni en 📖 Engineering Management for the rest of us*, ni en la Biblia, esto es, el repo abierto de Gitlab).
Esto es muy de ingenieros. A pesar de estar en una profesión que tiene principios como el Single Responsibility Principle (que un módulo solo debería cambiar por una razón nada más), os reto a que os peguéis una vuelta por los README de los repositorios de código de los servicios de vuestra organización para descubrir, con horror, que casi ninguno tendrá una definición en una frase de lo que ese servicio hace.
En la definición, casi siempre lo único que tenemos es un mezclijo de cosas que hacer. Como dice Julie Zhuo (VP de Product Design en Facebook) en 📖 The Making of a Manager:
Link to originalthe problem is that these answers are still an assortment of activities. If I asked you, “What is the job of a soccer player?” would you say that it’s to attend practices, pass the ball to their teammates, and attempt to score goals? (p. 16)
Quizá no somos especiales. Quizá engineering management es “management” en “ingeniería”. De hecho, este pibón:
Russ Laraway (que fue Company Comander en los Marines, que se pasó 7 años en Google ganando allí un “Great Manager Award” , luego se va a 4 años a Twitter, se junta con la tipa de Radical Candor, monta una movida de consultoría de software…) dice en Stop Overcomplicating It- The Simple Guidebook to Upping Your Management Game
Link to originalThere’s one common ingredient across every type of manager: You’re leading people. So the core of what makes for good management can’t be all that different, whether you’re leading a team of baristas or engineers.
Eso me deja acudir a la definición que más me gusta de “manager”, que es precisamente de 📖 The Making of a Manager (que no es Engineering Management específico, porque Julie Zhuo es diseñadora):
Link to originalYour job, as a manager, is to get better outcomes from a group of people working together. (Location 416)
Y he pillado ésta de What is an Engineering Manager? | AWS Startups Blog porque me venía bien para ilustrar:
The EM is the interface between strategy and delivery. They will be working with the leadership team and translating directives to their team as actionable tasks and deliverables.
Es decir, leído todo esto así, si lo desproveemos de épica, ¿no se siente…
…pastoreo? Poca broma con la foto, que esto es el campeonato de España de perros pastores (Nati Soler y su perra Java)
WARNING
No te rasgues las vestiduras antes de tiempo, acompáñame hasta el final, pofavó. A donde conduce todo esto es a una postura muy concreta desde la que hacer el curro de management.
Bajemos al barro. En 📖 The Making of a Manager dice que el curro de manager se reparte en
Link to originalthree buckets: purpose, people, and process. (Location 460)
Vamos a ver si tiene sentido el aporte que hacemos ahí.
¿Aporte a propósito?
Link to originalThe first big part of your job as a manager is to ensure that your team knows what success looks like and cares about achieving it. (…) sharing it at every opportunity—from writing emails to setting goals, from checking in with a single report to hosting large-scale meetings. (Location 471)
Overlap con “producto”
Para empezar, en esto tenemos un overlap con otro rol, el Product Manager. De Engineering Leadership Skill Set Overlaps de Gergely Oroszaka “The Pragmatic Engineer” (un señoro con una newsletter en tech, manager en Uber, Skype):
Link to original
(Os invito a leer este otro artículo de él sobre esa relación EM-PM, Working With Product Managers as an Engineering Manager or Engineer, y a ver si sois capaces de hacer una separación clara de responsabilidades. De hecho, él recomienda desenredar este tema:
Link to originalClear ownership of who is responsible for what is a prerequisite for shared leadership to work. Clarifying which areas of the work process the product manager owns, versus what falls under the ownership of the engineering manager, is something you need to do to avoid misunderstandings. I suggest sitting down with the product manager and drawing out all the activities you both do in order to ship software. Start with a blank sheet and then add areas. Once these are down, discuss which of you is ultimately responsible for getting that work done. What is the handoff point, when something is ready for engineering to start to develop? Which artifacts do you put in place to formalize this handoff – such as product requirement documents (PRDs), or engineering documents – and Requests for Comment (RFCs) or Engineering Requirements Documents (ERDs), or tickets? (View Highlight)
Pero es que en el artículo inicial, queda bastante claro:
Why are we building and what are we building? – the PM How will we build it? – the EM
Link to original
“How” no es propósito.
¿Necesitamos a una persona en concreto con esta responsabilidad?
Encontramos estos testimonios de un manager en 📖 Bullshit Jobs :
Link to originalTen people work for me, but from what I can tell, they can all do the work without my oversight. My only function is to hand them work, which I suppose the people that actually generate the work could do themselves. I will say that in a lot of cases, the work that is assigned is a product of other managers with bullshit jobs, which makes my job two levels of bullshit. (p. 51)
Link to original… they are trained in all the tools they need to use and they can, of course, manage their time and tasks. So I normally act as a “task gatekeeper.” Requests come to me through Jira (a bureaucratic online tool for managing tasks), and I pass them on to the relevant person or persons. Other than that, I’m in charge of sending periodic reports to my manager, who, in turn, will incorporate them into “more important” reports to be sent to the CEO. (p. 52)
De hecho, cuando contratamos “individual contributors”, buscamos gente que tenga la inquietud por saber por qué hacemos lo que hacemos: es la figura del ingeniero de producto, cuya mejor definición sería ésta de Jean-Michel Lemieux (fue CTO de Shopify, VP en Atlassian, ahora creo que elige vinos) en Product Engineers:
Link to original“Doubt I invented the term, but I did use it a lot. As a young discipline we’ve spent a lot of time working out « how » to build software and that’s a big focus in schools still. But once you have the foundations, you need devs who engage with the « why » actively. Engineers who have a thirst for using technologies to leapfrog human/user problems. Those with empathy to reach for magical experiences. That is what defined a product engineer in my books (View Highlight)
Lo contrario es un modelo terrible, ✍️ La tiranía del Thinker: una gente que piensa tareas a realizar y otra gente que las hace (y luego pasa lo que pasa, que se hacen regulín, porque no se entienden bien).
Con lo cual, en el mejor de los casos, no hacemos falta ¿por qué necesitamos a una persona específica con esta función? ¿No estamos poniendo un parche?
¿Aporte a procesos?
Bueno, a ver si es que todo va del “how” entonces (con cierto overlap para poder hacer de puente con el “why”). Recuperando 📖 The Making of a Manager:
Link to originalFinally, the last bucket is process, which describes how your team works together. You might have a superbly talented team with a very clear understanding of what the end goal is, but if it’s not apparent how everyone’s supposed to work together or what the team’s values are, then even simple tasks can get enormously complicated. Who should do what by when? What principles should govern decision-making?
Un pequeño detour primero. Pero en este “how”, ¿hablamos de “how” técnico también?
¿¿¿Eres técnico???
Una de las cosas más terriblemente decepcionantes del rol de Engineering Manager es lo poquísimo que se espera técnicamente de uno en casi todos los sitios. Recuperando el diagrama de Venn de antes, fijaos que el Engineering Manager no aparece en “Building Software”.
Link to original
La primera ronda de feedback que suelo tener siempre en todos los equipos en los que he tenido el rol de Engineering Manager es que “me estoy metiendo mucho en lo técnico” cuando por ejemplo, quiero poder ver lo básico de la observabilidad que tenemos o quiero entender por qué hemos tenido una incidencia.
En 📖 The Manager’s Path, Camille Fournier (ex-VP de Tech en Goldman Sachs, ahora en JPMorgan Chase) dice:
Link to originalI’m one of those deeply technical managers, and I have opinions about the way systems should be built and operated. Letting go has been hard for me… (p. 60)
No veo cómo es posible ser responsable de un equipo técnico y que lo contemples como una especie de caja negra de la que salen cosas. En este tema específico hay un par de artículos de Charity Majors, CTO de Honeycomb (antes en Facebook) buenísimos. De su Should engineering managers be technical:
Link to originalAnd since we’re always telling managers not to write code or do technical work – since what managers actually do all day is go to meetings, write emails, and other managerial things – shouldn’t it be management skills that are non-negotiable rather than engineering skills?’ (View Highlight)
Link to originalIt’s a coaching relationship, a derivative role, one that leverages your existing knowledge of the discipline to help teams make decisions, resolve conflicts, and develop skills and processes. Therefore, managers need to have a solid grounding in engineering fundamentals before they can usefully help others grow as engineers. Managers may also need to go back to the well periodically and engage in engineering work to refresh their capabilities. (View Highlight)
Luego hablamos de ese “help others grow” que hace referencia a personas, pero en cuanto a procesos, está clarísimo:
Link to originalYou need to be able to look at a team that isn’t shipping very fast and figure out whether it’s because of under-skilled engineers, legacy code, a weak product culture, a leaky CI/CD pipeline, or a team that has given up and lost confidence in itself. And then you need to start influencing people to do things that visibly and materially improve the system. (View Highlight)
Cabría pensar que te puedes apoyar para la parte técnica en un Tech Lead, pero tú veras lo que haces:
Link to originalTech leads in this configuration are extremely powerful; the manager basically defers to the TL whenever the TL thinks they should, which can be quite gratifying to a senior person. Most of the vocal proponents of this model are people who miss being that TL (View Highlight)
Link to originalIf you try to separate the social from the technical, and assign different domain owners to each, you are slicing up the ownership and responsibility lengthwise. You’re setting yourself up for squabbles about whose fault it really was, instead of making the lines of responsibility and accountability crystal clear. (View Highlight)
A Steve Jobs lo de los managers no técnicos no le funcionó bien
Link to original(Jobs) We’re going to be a big company, we thought. So let’s hire “professional managers.” We went out and hired a bunch of professional management, and it didn’t work at all. They knew how to manage, but they didn’t know how to do anything. If you are a great person why do you want to work for somebody you can’t learn anything from?
Y resulta que la ciencia además le dio la razón:
And it turns out that a 2015 study (Boss Competence and Worker Well-Being by Benjamin Artz, Amanda H. Goodall, Andrew J. Oswald SSRN) agrees with this:
Link to original
Link to original… a boss’s technical competence is the single strongest predictor of a worker’s well-being.
Procesos no-técnicos. Aquí sí.
Entonces, aunque piense que el EM necesita parte técnica activa, en general la industria no lo tiene tan claro. Como me dijeron una vez en una compañía: “es que no te va a dar tiempo con lo demás”.
Vamos a la parte de “procesos” en su vertiente no técnica: ¿cuánto aporte tiene que hacer un EM aquí? Si cogemos el capítulo de 📖 The Making of a Manager dedicado a procesos, descubriremos que para un manager esto es…
…
¡Es gestión básica de proyecto! Y esta sí, es una carencia que he visto una y otra vez :
- No tener visibilidad de lo que se está haciendo. La peña por ahí haciendo lo que les parece.
- Cada miembro del equipo con una tarea totalmente distinta.
- No tener una cadencia de desarrollo - introspección.
- No tener un mecanismo para hablar de prioridades. Tratar a los equipos como el sumidero de la cocina (dinámicas “Kitchen sink”) Da igual la metodología que cojas, TODAS, tienen algo de esto: 📖 Extreme Programming Explained, 📖 Scrum. El revolucionario método para trabajar el doble en la mitad de tiempo, Kanban.
Dice Marie Kondo, una sabia:
Life truly begins after you have put your house in order.
¿Por qué esta carencia?
Solo hay que tener un poco de cuidado con el shock anafiláctico que puedes provocar: existe la alergia al proceso, como lo llama Julie Zhuo en 📖 The Making of a Manager:
Link to originalOften, people have an allergic reaction to the word process. For me, it used to conjure up the feeling of glacial progress. (…) There’s some truth to this. We’ve already established that when you are working by yourself, you get to make all the decisions. (…) In a team setting, it’s impossible for a group of people to coordinate what needs to get done without spending time on it.
Dice Jeff Sutherland, el creador de Scrum, que como pasa con muchas cosas, “si no te gusta es porque no te lo han hecho bien”. De 📖 Scrum. El revolucionario método para trabajar el doble en la mitad de tiempo:
Link to originalEn un mundo teóricamente perfecto, no habría procesos (…). Los «procesos» que la gente utiliza son un derroche y ahí se incluye el Scrum. Pero no vivimos en un mundo perfecto, y los malos procesos están tan enraizados en nuestro pensamiento que, como alternativa, necesitamos el proceso más liviano posible con el mayor impacto en nuestro trabajo (…). Mi intención ha sido que el proceso en sí constituya un marco lo menos perturbador posible y no obstante mantenga a la gente centrada. Lo que realmente queremos en nuestro trabajo es un «fluir» sin esfuerzo (p. 140)
También suele ocurrir que no hay tiempo o ganas de enfrentarse a que el tiempo es finito, como dicen en 📖 Peopleware 3rd Edition (del 87!)
Transclude of 📖-Peopleware-3rd-Edition#^faf0b2
Link to originalThe steady-state cheeseburger mentality barely even pays lip service to the idea of thinking on the job. It’s every inclination is to push the effort into 100-percent do-mode. If an excuse is needed for the lack of think-time, the excuse is always time pressure (…) It’s when the truly Herculean effort is called for that we have to learn to do work less of the time and think about the work more. (p. 11).
Por otro lado, ojo porque a esto también se llega por estar en una no-organización… porque toda la compañía está manga por hombro, no hay prioridades, las prioridades son todas. Esto es lo que le dice Claire Hughes Johnson (COO de Stripe) en Scaling People a un product leader:
I recently coached a talented up-and-coming product marketing leader at Stripe who kept running up against the challenge of syncing her team’s work with the company’s ever-changing product roadmap. We spent a whole 1:1 talking about solutions, at the end of which I observed that there would never be a one-and-done fix for the issue. Instead, she would need to continually adapt her approach and push the product team to adapt theirs.
Link to original
En cualquier caso, como en este testimonio de 📖 Bullshit Jobs, no hay autorealización en lidiar con lo disfuncional:
Link to originalIf there’s any satisfaction that comes from my job, it’s being an expert in navigating the waters of our disorganized organization and being able to get things done. But being an expert in something that is unnecessary is, as you can imagine, not all that fulfilling. (p. 124)
¿Pero no sería cosa de todos?
Y de nuevo, este project management básico del que hablamos, ¿requiere de unas habilidades especiales distintas a las de construir software como para que no podamos tener personas que construyen y se auto-organizan? No lo creo.
¿Aporte a personas?
Vamos entonces al que dice Gergely Orosz que es el que más nos gusta a los EMs, gestión de personas. ¿De qué va esto? Según él:
Link to originalEngineering managers will spend much of their time on helping the team operate well and people to grow. This will encompass team building and operating activities like 1:1s and roadmapping. It will also encompass hiring, promotions, coaching / mentoring / giving feedback and performance management. (View Highlight)
Coaching, mentoring… ayudar a la gente a crecer
Meet JoseMari:
Es como esos letreros, que uno ve cuando pasa por las autopistas que dicen ‘No podemos conducir por ti’; y yo siempre pienso: ¿y quién te ha dicho a ti que quiero que conduzcas por mí? Pues eso es lo mismo, quien te ha dicho a ti… las copas de vino que yo tengo o no tengo que beber? (Jose María Aznar)
Si tienes gente como mínimo, más junior que tú, tiene todo el sentido que ayudes a crecer. Pero tu eres el manager de JoseMari. JoseMari tiene ya pelicos en los huevos. ¿Le hacemos mentoring a JoseMari?
De nuevo de Scaling People:
Link to originalExperienced employees mostly need a leader and just a bit of a manager. If they’ve made it to a certain point in their careers, they’re probably good at getting their work done. (View Highlight)
Pues no, por lo visto JoseMari no necesita un manager, necesita un líder. Pero ese líder… ¿tienes que ser tú como EM? Probablemente no, tú estás a otras cosas, estás a ejecutar:
Link to originalrecognize the difference between being a manager and being a leader. Both are necessary for scaling a company, but they’re not the same thing. (View Highlight)
Link to originalLeaders don’t have to be managers, but if they aren’t, they need to know how to work with and hire managers to build the right teams to execute that vision. (View Highlight)
Nos dice Russ Laraway otra vez:
Link to originalNobody ever applies for a job called ‘leader.’ The job is usually called ‘manager.’ (…) We focus on the esoteric, complex ideas that make us a “leader” rather than the specific things managers must do well.
Para lo serio: psicólogo
Cuando hablamos de hacer de manager de personas hablamos también de conceptos como crear un entorno donde la gente pueda ser vulnerable, de Psychological safety, de empoderar, de ayudar al resto a sacar lo mejor de si mismos, que tienen un impacto bastante grande. El problema es que aquí es muy fácil que nos metamos en un terreno pantanoso de cuidado. De 📖 The Manager’s Path:
Link to originalI had an interesting conversation once with a friend, another CTO who has a lot of management experience. He sheepishly admitted to me that he didn’t like doing regular 1-is because he himself had always resented being forced to do Is with managers that he felt he didn’t need. “Regular 1-is are like going to a psychiatrist when you’re fine and discovering you have depression.” (p. 52)
No somos psicólogos, por dos motivos muy importantes:
- No tenemos las skills para ayudar a gente con problemas que requieren ayuda profesional y podemos hacer mucho daño: Managers Impact Our Mental Health More Than Doctors, Therapists — And Same as Spouses (un estudio de una empresa de recursos humanos, que, si bien sospechoso, parece bien hecho: encuesta de 3400 personas en 10 países)
- Porque ayudar a alguien puede entrar en conflicto con los intereses de la organización. Qui paga mana. De How to Be a Manager, Not a Therapist, de Gabrielle Braun (no os la perdáis, que aplica el psicoanálisis al mundo laboral):
Link to originalManagers are not therapists, and there will come a point when you must protect the work of the organisation. You might, for instance, tell a staff member that they need to draw a line under temper outbursts or insist on their attendance in-person (View Highlight)
Para todo lo demás, Mastercard (uno mismo)
Un manager tampoco es un padre/madre, pero es muy fácil convertirse en uno. Nos cuenta esto Brian J. Robertson en Holacracy.
Link to originalA much-loved leader had just been fired, and one of his team, lamenting the departure of his boss, turned to his coworker and asked: “Who will empower us now?” I found the intentional irony in the statement both poignant and illuminating. Of course, it is a fundamentally disempowered victim’s stance to need someone else to empower you. (Location 276)
Link to originalEven with the best of intentions and great leaders, a top-down authority system leads almost inevitably to a parent-child dynamic between the boss and the employee. (Location 338)
Es decir, en el mismo hecho de buscar empoderar, es fácil caer en el paternalismo y en realidad estar desempoderando.
Cuidao con Brian J. Robertson, porque aunque podría ser un poco magufo (Meet the Man Who Helped Turn Zappos Upside Down | Inc.com), tenía el apoyo de Tony Hsieh (que en paz descanse) y de David Allen el de 📖 Getting Things Done.
Pero es que además, si necesitamos empoderar es porque hay algo desempoderante en la organización. De 📖 Superpronosticadores. El arte y la ciencia de la predicción:
Link to originalA menudo se tropiezan con la impresión de que las fuerzas armadas son organizaciones rigurosamente jerárquicas en las cuales los subordinados se limitan a hacer la venia y obedecer a los superiores. Es una imagen ridícula por lo anacrónica. De hecho, los ex oficiales a menudo se hallan en la situación de aconsejar a los ejecutivos que se preocupen menos por las categorías y se dediquen más a empoderar a su gente y sus equipos, de modo que puedan elegir la mejor manera de alcanzar las metas comunes. En una entrevista que le hizo el Financial Times, Damian McKinney comentó: “Lo irónico del caso es que muchas empresas hacen mucho más hincapié que los militares en lo que yo llamo ‘mando y control’. (p. 226)
Damian McKinney es ex-infante de la Marina Real de Reino Unido y en quien se apoyó Walmart para formar a sus líderes cuando estaban creciendo a todo trapo.
Total, que en personas también…
O sea que en propósito, procesos y personas, en el mejor de los casos no hacemos falta, en el peor, somos un parche: la solución buena o es de otros roles o es de todos o es estructural.
No solo es un bullshit job, también es un shitty job
Pues no. Engineering Management no solo puede ser considerado un “bullshit job”, es que también es un poco “shitty job”.
Seguro que ya lo habéis leído mil veces que el propio trabajo de manger es más desagradable que programar porque los ciclos de recompensa son más largos, pero lo cierto es que hay más profundidad aquí.
Actividad télica = insatisfacción crónica
Además de las consecuencias de las a propia esencia de la actividad del management juega a la contra de lo que nos hace felices como seres humanos. El management es una actividad “télica” (del griego “telos”, meta): es la constante persecución de objetivos. Y distintos filósofos a lo largo de la historia nos cuentan que una vida basada en objetivos es una vida con constante insatisfacción. Por ejemplo, Schopenhauer en su The World as Will and Representation dice:
The basis of all willing, however, is need, lack, and hence pain, and by its very nature and origin [the animal] is therefore destined to pain. If, on the other hand, it lacks objects of willing, because it is at once deprived of them again by too easy a satisfaction, a fearful emptiness and boredom comes over it; in other words, its being and its existence become an intolerable burden for it. Hence it swings like a pendulum to and fro between pain and boredom, and these two are in fact its ultimate constituents.
O en palabras de mi psicólogo: si vas de este palo, ¿qué prefieres? ¿ansiedad o depresión?
El antídoto son las actividades atélicas, esto es, que son placenteras en si mismas. ¿Se os ocurre una actividad télica en tech? Programar. Por eso se nota tanto la diferencia al entrar en management.
Hay un deep dive interesante de esto en 📖 Midlife. A philosophical guide (y el artículo How philosophy can solve your midlife crisis), al que llegué a través de distintas referencias pero principalmente 📖 Four Thousand Weeks.
Time confetti = adiós al flow
Una de las primeras cosas que recuerdo haber leído sobre management—no he encontrado la referencia—decía algo así como “ya no eres dueño de tu tiempo. Tienes que ser interrumpible”. Seguro que todos conocéis lo típico de que los managers tienen un tipo de calendario distinto al de un “maker”: el de los managers está petao de meets, a un maker le partes en dos cada vez que le plantas uno. Esto viene de un ensayo mítico de Paul Graham, el fundador de Y-Combinator, 🗞 Maker’s schedule, Manager’s schedule.
Aquella idea hoy me parece una aberración. Sí que hay que tener en cuenta que (Talking With Tech Leads):
Link to originalYour time is only one person’s worth. Your team’s is n times that. Your focus should be on their productivity. (Location 795)
y que en nuestro rol de brokers de la información y el alineamiento, hay que comunicarse con bastante gente a menudo.
Sim embargo, de alguna manera todo el mundo asume que esto tiene que ser un poco a lo loco, siempre oral, siempre reactivo, en lo que Cal Newport llama “haphazard busyness”:
Link to originalThe Relationship Between Productivity and Autonomy Transcript: Speaker 1 So instead of trying to define productivity, let’s define what it is to not have any organized thinking about productivity in your professional life. And what you’re going to end up with is what I call haphazard busyness. So if your life sub comes to haphazard busyness, which is where you will almost certainly end up if you, you know, like Giniodel, you say, I just want to enjoy the birds, right? If you’re saying I’m rejecting this idea that I want to think in an organized fashion about how I manage my obligations in time, you will probably end up with haphazard busyness where you have a uncontrolled influx of various obligations, a various urgency that you have a hard time keeping track of and tend to pull at your attention suddenly in an emergency type situations haphazard busyness reduces your options. It makes you feel stressed. It’s almost certainly going to lead to overload too much to do. And it tends to push people towards extreme solutions such as this is what work is. So I need to find a way to leave the workforce, for example. (Time 0:10:04)
O como Jacinto Fleta, Eng. Manager en Factorial resume muy bien:
Y para cerrar la ventana hace falta pensar fuerte sobre los problemas estructurales que estás teniendo. Es decir, la habilidad para hacer lo que Cal Newport llama Book Deep Work, lo cual, además, es una ventaja competitiva sobre los demás:
Link to originalThe Deep Work Hypothesis: The ability to perform deep work is becoming increasingly rare at exactly the same time it is becoming increasingly valuable in our economy. As a consequence, the few who cultivate this skill, and then make it the core of their working life, will thrive. (Location 203)
Pero es que además realizar ese trabajo profundo más efectivo, también es más satisfactorio: se dan mejores condiciones para alcanzar ese estado de concentración o flow, que el psicólogo Mihaly Csikszentmihalyi correlacionó con la felicidad.
¡Pues quitemos a los managers! No tan deprisa…
En Google recelaban de los managers:
Link to originalAnd most engineers, not just those at Google, want to spend their time designing and debugging, not communicating with bosses or supervising other workers’ progress. In their hearts they’ve long believed that management is more destructive than beneficial, a distraction from “real work” and tangible, goal-directed tasks. (View Highlight)
Así que se los cepillaron en 2002 porque JoseMari como mínimo necesita un secretario y un mediador (People)
Link to originalIn 2002 they experimented with a completely flat organization, eliminating engineering managers in an effort to break down barriers to rapid idea development and to replicate the collegial environment they’d enjoyed in graduate school. That experiment lasted only a few months: They relented when too many people went directly to Page with questions about expense reports, interpersonal conflicts, and other nitty-gritty issues (View Highlight)
Y eso que intentan buscar personas que no necesitarían managers…
Link to originalGoogle downplays hierarchy and emphasizes the power of the individual in its recruitment efforts (…) It screens candidates’ résumés for markers that indicate potential to excel there—especially general cognitive ability. People who make that first cut are then carefully assessed for initiative, flexibility, collaborative spirit, evidence of being well-rounded…
¿Y qué más necesitan? Purpose, and process.
Link to originalAnd as the company grew, the founders soon realized that managers contributed in many other, important ways—for instance, by communicating strategy, helping employees prioritize projects, facilitating collaboration, supporting career development, and ensuring that processes and systems aligned with company goals. (View Highlight)
La alternativa no necesariamente es una organización completamente plana
Así que Google se cepilló el management, y sin embargo, le salió regular. Hay una parte de salirle regular que tiene que ver con gestión administrativa (querríamos entonces secretarios, no EMs), otra que tiene que ver con conflictos interpersonales (nos faltaban psicólogos por ahí), pero hay una irremplazable, que es la de la eficiencia al encontrar alineamiento.
Que es la necesidad por la que el historiador Niall Ferguson sugiere en 📖 The Square and the Tower que nos llaman las jerarquías:
Link to originalThe crucial incentive that favoured hierarchical order was that it made the exercise of power more efficient: centralized control in the hands of the ‘big man’ eliminated or at least reduced time-consuming arguments about what to do, which might at any time escalate into internecine conflict.” (p. 22)
Pero la única alternativa a tener managers no sería no tenerlos en absoluto. Igual que hacemos con otro roles como el on-call, o el Tech Lead, podría ser un papel que va cambiando de manos, como ocurre por ejemplo en Holacracy:
Link to originalWhen a meeting with my partners at HolacracyOne results in my adding items to my task list, none of us thinks of those tasks as being assigned to “Brian.” Instead, we might speak of a task being assigned to “Trainer,” or “Program Design,” or “Finance”—each of which is a role that I fill (…) and it points to a fundamental shift that Holacracy enables: the differentiation of people and roles, or “role and soul,” (Location 595)
Formaciones de este tipo no son comunes por ahí…
pero hay algunos nombres destacados, como Zappos (aunque por lo visto esta virando un poco a algo más tradicional), o Patagonia (que en realidad usa otra historia similar lamada Teal organization). Reconozco que me pasa con esto como con el poliamor: que suena bien, pero cuánto trabajo. También es cierto que podríamos tener el problema de no darle continuidad suficiente a ciertas medidas (un poco como nos pasa con política).
De hecho el psicólogo de management Harold J. Leavitt sugiere en Why Hierarchies Thrive, que una jerarquía estable, aunque no sea perfecta…
Link to originalOn a fundamental level, they don’t just enslave us, they also fulfill our deep needs for order and security. And they get big jobs done. (View Highlight)
(otro sitio más donde se ve que los seres humanos llevamos mal la Uncertainty).
Si además fomentamos que la gente se comunique en público y de la forma más directa posible, tendremos lo mejor de los dos mundos, la plaza y la torre. Es decir, tener “nodos de decisión” (temporales o no ya es otro tema) tiene sentido, pero sin despojar de responsabilidades al resto del mundo: ni en propósito, ni en proceso, ni en personas. Que por cierto:
Link to originalIn practice, of course, a large proportion of history’s autocratic rulers left a considerable amount of power to the market, although they might regulate, tax and occasionally interrupt its operations. That is why in the archetypal medieval or early-modern town - such as Siena in Tuscany - the tower representing secular power stands right next to, and indeed overshadows, the square where market transactions and other forms of public exchange took place (p. 23)
Por otro lado, también se habla de no tener ningún tipo de coordinación central y jugárselo todo a comportamientos emergentes. De 📖 The Square and the Tower:
Link to originalthere seem to be consensus: few futurologists expect established hierarchies - in particular, traditional political elites, but also long-established corporations - to fare very well in the future.’ Francis Fukuyama is unusual in arguing that hierarchy must ultimately prevail, in the sense that networks alone cannot provide a stable institutional framework for economic development or political order. Indeed, he argues, hierarchical organization … may be the only way in which a low-trust society can be organized? By contrast, the iconoclastic British political operative Dominic Cummings hypothesizes that the state of the future will need to function more like the human immune system or an ant colony than a traditional state - in other words, more like a network, with emergent properties and the capacity for self-organization, without plans or central coordination, relying instead on probabilistic experimentation, reinforcing success and discarding failure, achieving resilience partly through redundancy. This may be to underestimate both the resilience of the old hierarchies and the vulnerabilities of the new networks - not to mention their capacity to fuse to form even newer power structures, (p. 45)
Y aquí esta la madre del cordero: en lo personal… “dejarlo”
Con todo este percal, mi objetivo es dejar de tener que hace este trabajo. De My management principles, values, and practices:
Link to original
- North star metric: “time I spend in VSCode”, as a proxy metric for “we no longer need an engineering manager”, so I can either enjoy creating with my own two hands or focusing on bigger strategy problems.
Si entendemos que esta posición es un parche, hacer bien tu trabajo puede ser asegurarse que todo ocurre sin que tú estés, hacerte obsoleto, al menos aspiracionalmente (luego no ocurre nunca: o bien amplías scope a más equipos con problemas, o subes un nivel de abstracción a estrategia). Buscando material para la charla… justo encuentro a alguien con la misma idea (ya decía yo que no podía haber tenido una idea tan inteligente yo solo). Sherif Mansour (13 años de PM en Atlassian), Product Engineers:
Link to originalIn many ways, I’d argue product managers should always have a personal goal of working out how they could make themselves redundant (granted, one might never achieve it). (View Highlight)
Es más, resulta que Roberto Ansuini (EM en RevenueCat) que en Google ya tenían este concepto: “Always be leaving”, que es una frase de Bharat Mediratta antiguo Engineering Director. De Software Engineering at Google:
Link to originalit’s not just your job to solve an ambiguous problem, but to get your organization to solve it by itself, without you present. If you can do that, it frees you up to move to a new problem (or new organization), leaving a trail of self- sufficient success in your wake. (View Highlight)
Lo cual no sorprende teniendo en cuenta la trayectoria que hemos visto de Google con los managers.
Y más… Take Longer Vacations.
Y en una línea similar, lo mismo pensaba Steve Jobs: el mejor manager es el que no quiere serlo, pero decide serlo por esta pulsión al control, porque le importa el objetivo.
Link to original(Jobs) You know who the best managers are? They’re the great individual contributors who never, ever want to be a manager, but decide they want to be a manager, because no one else is going to be able to do as good a job as them.
Y todo esto tiene un beneficio extra: te protege contra el “sobre-management”: con meterle sobrecomplejidad al management para de alguna manera justificar las 40h/semanales.
A mi me va la marcha
Luego yo a título personal tuve mucha suerte. Soy una persona con una tendencia al control bastante bestia y me satisface mucho el órden. Entonces… para mí el management es una actividad atélica, parecido a lo que cuenta aquí Kiko Llaneras, periodista de datos en El País:
Link to originalImpulso a ordenar como profesión (Time 0:32:01)
Es decir… que puedes tener cierta suerte y que esta actividad sea télica también.
Cosmic Theory of Insignificance
Por último, hay que asumir esto como lo que es (¡tiene bastante impacto!), aunque no tenga grandiosidad. Recuperando a Russ Laraway en Stop Overcomplicating It- The Simple Guidebook to Upping Your Management Game:
Link to originalWe have to restore dignity to the office of the manager. (…) We’ve allowed ourselves to fall victim to this idea of grandiosity — that leadership is better than management.
Además, la búsqueda de la épica trae otras cosas no muy buenas:
Link to originalThe business world is obsessed with fighting and winning and dominating and destroying. This ethos turns business leaders into tiny Napoleons. (…) Companies that live in such a zero-sum world don’t “earn market share” from a competitor, they “conquer the market.” They don’t just serve their customers, they “capture” them. They “target” customers, employ a sales “force,” hire “head-hunters” to find new talent, pick their “battles,” and make a “killing.” This language of war writes awful stories. When you think of yourself as a military commander who has to eliminate the enemy (your competition), it’s much easier to justify dirty tricks and anything-goes morals. And the bigger the battle, the dirtier it gets. (p. 20)
Y por último de 📖 Four Thousand Weeks:
Link to originalimplausible, for almost all people, to demand of themselves that they be a Michelangelo, a Mozart, or an Einstein … There have only been a few dozen such people in the entire history of humanity.” In other words, you almost certainly won’t put a dent in the universe. Indeed, depending on the stringency of your criteria, even Steve Jobs, who coined that phrase, failed to leave such a dent. Perhaps the iPhone will be remembered for more generations than anything you or I will ever accomplish; but from a truly cosmic view, it will soon be forgotten, like everything else (p. 134).
* No es del todo verdad esto, tiene justo una frase por ahí escondida, en la misma línea que el 📖 The Making of a Manager:
Link to originalIf I was going to nail down what I think my job is, it’s to enable the people around me to do their best work … together. (p. 16)