✍️ Déjame sin trabajo, por favor

- Tags:: #✍️OwnPosts , #🗣️OwnTalks , [[Engineering Management]] - Created date:: [[2023-05-28]] > [!NOTE] Este artículo podría haber sido una charla >![[Pasted image 20230525134418.png]] ## 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: ![[cuñao.png]] ^917af5 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]]: ![[📖 Bullshit Jobs#^d82517]] 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]]: ![[📖 Bullshit Jobs#^1ad940]] ![[📖 Bullshit Jobs#^750e75]] ![[📖 Bullshit Jobs#^d8cbe9]] 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: ![[Pasted image 20230520170833.png]] 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, [[Engineering Management at Gitlab|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]]: ![[📖 The Making of a Manager#^2c09a2]] Quizá no somos especiales. Quizá engineering management es "management" en "ingeniería". De hecho, este pibón: ![[Pasted image 20230522195521.png]] [[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]] ![[Stop Overcomplicating It- The Simple Guidebook to Upping Your Management Game#^563398]] 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): ![[📖 The Making of a Manager#^e5348a]] Y he pillado ésta de [What is an Engineering Manager? | AWS Startups Blog](https://aws.amazon.com/blogs/startups/what-is-an-engineering-manager/) porque me venía bien para ilustrar: ![[Pasted image 20230504073835.png]] >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... ![[Pasted image 20230504074356.png]] ...pastoreo? *Poca broma con la foto, que esto es el campeonato de España de perros pastores (Nati Soler y su perra Java*) ^4a3eb4 > [!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 ![[📖 The Making of a Manager#^b5d805]] Vamos a ver si tiene sentido el aporte que hacemos ahí. ### ¿Aporte a propósito? ![[📖 The Making of a Manager#^87f183]] #### Overlap con "producto" Para empezar, en esto tenemos un overlap con otro rol, el [[Product Management|Product Manager]]. De [[Engineering Leadership Skill Set Overlaps]] de [[Gergely Orosz]]aka "The Pragmatic Engineer" (un señoro con una newsletter en tech, manager en Uber, Skype): ![[Engineering Leadership Skill Set Overlaps#^e7e014]] 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: ![[Working With Product Managers as an Engineering Manager or Engineer#^e757cb]] Pero es que en el artículo inicial, queda bastante claro: ![[Engineering Leadership Skill Set Overlaps#^1286a3]] "How" no es propósito. #### ¿Necesitamos a una persona en concreto con esta responsabilidad? Encontramos estos testimonios de un manager en [[📖 Bullshit Jobs]] : ![[📖 Bullshit Jobs#^d93161]] ![[📖 Bullshit Jobs#^e4857d]] De hecho, cuando contratamos "individual contributors", buscamos gente que tenga la inquietud por saber por qué hacemos lo que hacemos: es la figura del [[The Product-Minded Software Engineer|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]]: ![[Product Engineers#^36fcbc]] Lo contrario es un modelo terrible, [[The thinker - doer model]]: 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? ![[Pasted image 20230510074838.png|300]] ### ¿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]]: ![[📖 The Making of a Manager#^82283d]] 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". ![[Engineering Leadership Skill Set Overlaps#^e7e014|]] 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: ![[📖 The Manager's Path#^814f5c]] 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]]: ![[Should engineering managers be technical#^27c2ab]] ![[Should engineering managers be technical#^ec989d]] Luego hablamos de ese "help others grow" que hace referencia a personas, pero en cuanto a procesos, está clarísimo: ![[Should engineering managers be technical#^0053c8]] Cabría pensar que te puedes apoyar para la parte técnica en un Tech Lead, pero tú veras lo que haces: ![[Should engineering managers be technical#^d90e57]] ![[Should engineering managers be technical#^c9ecc8]] A [[Steve Jobs]] lo de los managers no técnicos no le funcionó bien ![[37 Years Ago, Steve Jobs Said the Best Managers Never Actually Want to Be Managers. Science Says He Was Right#^e31968]] Y resulta que la ciencia además le dio la razón: ![[37 Years Ago, Steve Jobs Said the Best Managers Never Actually Want to Be Managers. Science Says He Was Right#^388d46]]![[37 Years Ago, Steve Jobs Said the Best Managers Never Actually Want to Be Managers. Science Says He Was Right#^1d223e]] #### 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... ![[Pasted image 20230512073424.png]] ... ![[Pasted image 20230512073714.png|300]] ¡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 [[Process allergy|alergia al proceso]], como lo llama [[Julie Zhuo]] en [[📖 The Making of a Manager]]: ![[📖 The Making of a Manager#^c6761f]] 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]]: ![[📖 Scrum. El revolucionario método para trabajar el doble en la mitad de tiempo#^dc5626]] 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!) ![[📖 Peopleware 3rd Edition#^faf0b2]] ![[📖 Peopleware 3rd Edition#^dad6ba]] 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: ![[Scaling People#^98ce5b]] En cualquier caso, como en este testimonio de [[📖 Bullshit Jobs]], no hay autorealización en lidiar con lo disfuncional: ![[📖 Bullshit Jobs#^91d2f6]] ##### ¿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: ![[Engineering Leadership Skill Set Overlaps#^dec815]] #### Coaching, mentoring... ayudar a la gente a crecer Meet JoseMari: ![[Pasted image 20230513122828.png|300]] >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]]: ![[Scaling People#^18d5e4]] 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: ![[Scaling People#^5177df]] ![[Scaling People#^e6fc5e]] Nos dice [[Russ Laraway]] otra vez: ![[Stop Overcomplicating It- The Simple Guidebook to Upping Your Management Game#^52ebdb]] #### 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]]: ![[📖 The Manager's Path#^9efd98]] 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): ![[How to Be a Manager, Not a Therapist#^6f0ba2]] #### 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]]. ![[Holacracy#^2ecef9]] ![[Holacracy#^6f51ff]] 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](https://www.inc.com/ilan-mochari/brian-robertson-man-behind-holacracy-zappos.html)), 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]]: ![[📖 Superpronosticadores. El arte y la ciencia de la predicción#^9c3cb5]] [[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... ![[Pasted image 20230523190648.png|300]] 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". ![[Pasted image 20230506170141.png]] 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]]): ![[Talking With Tech Leads#^b5be38]] 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": ![[Ep. 240 — Disciplined Laziness#^0a3e8b]] O como [[🧑🏼 Jacinto Fleta]], Eng. Manager en [[Factorial]] resume muy bien: ![[Pasted image 20230507181556.png]] 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: ![[Book Deep Work#^b4cb8d]] 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: ![[How Google Sold Its Engineers on Management#^8ace46]] Así que se los cepillaron en 2002 porque JoseMari como mínimo necesita un secretario y un mediador (People) ![[How Google Sold Its Engineers on Management#^9476e0]] Y eso que intentan buscar personas que no necesitarían managers... ![[How Google Sold Its Engineers on Management#^eab2b7]] ¿Y qué más necesitan? Purpose, and process. ![[How Google Sold Its Engineers on Management#^230cf6]] ### 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: ![[📖 The Square and the Tower#^cc340e]] 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]]: ![[Holacracy#^47a752]] Formaciones de este tipo no son comunes por ahí... ![[Pasted image 20230519065125.png]] 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 [[Poliamory|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... ![[Why Hierarchies Thrive#^661cf8]] (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: ![[📖 The Square and the Tower#^87d2be]] 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]]: ![[📖 The Square and the Tower#^ab89f4]] ## 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 engineering management principles, values, and practices]]: ![[My engineering management principles, values, and practices#^8a363d]] **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]]: ![[Product Engineers#^06462a]] 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]]: ![[Software Engineering at Google#^2b3bd3]] Lo cual no sorprende teniendo en cuenta la trayectoria que hemos visto de Google con los managers. Y más... [Take Longer Vacations](https://boz.com/articles/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. ![[37 Years Ago, Steve Jobs Said the Best Managers Never Actually Want to Be Managers. Science Says He Was Right#^ab2931]] 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 [[My control need|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: ![[Orden Y Concierto 🙂 O... ¡desorden Y Desconcierto! 😱#^ed1ecb]] 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]]: ![[Stop Overcomplicating It- The Simple Guidebook to Upping Your Management Game#^f3b9f3]] Además, la búsqueda de la épica trae otras cosas no muy buenas: ![[📖 It doesn't have to be crazy at work#^ebd665]] Y por último de [[📖 Four Thousand Weeks]]: ![[📖 Four Thousand Weeks#^fd23d1]] --- \* 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]]: ![[📖 Engineering Management for the rest of us#^439a08]]