Capítulo 1. ¿Qué dirías que haces aquí?
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
La idea de una vía de ingeniero de plantilla, o "vía técnica", es nueva para muchas empresas. Las organizaciones difieren en cuanto a los atributos que esperan de sus ingenieros más veteranos y el tipo de trabajo que deben hacer esos ingenieros. Aunque la mayoría está de acuerdo en que, como ha escrito Silvia Botros, la cúspide de la vía técnica no son sólo los "seniors más veteranos", no tenemos una comprensión compartida de lo que es. Así que empezaremos este capítulo poniéndonos existenciales: ¿por qué querría una organización que los ingenieros muy veteranos se quedaran? Después, armados con ese conocimiento, desgranaremos el papel: sus requisitos técnicos, sus requisitos de liderazgo y lo que significa trabajar de forma autónoma.
Las funciones de ingeniería de personal tienen muchas formas. Hay muchas formas válidas de hacer el trabajo. Pero algunas formas se ajustarán mejor a algunas situaciones, y no todas las organizaciones necesitarán todo tipo de ingenieros de plantilla. Así que hablaré de cómo caracterizar y describir una función de ingeniería de personal: su alcance, profundidad, estructura jerárquica, enfoque principal y otros atributos. Puedes utilizar estas descripciones para ser preciso sobre cómo quieres trabajar, en qué tipo de función quieres crecer o a quién necesitas contratar. Por último, dado que las distintas empresas tienen ideas diferentes de lo que debe hacer un ingeniero de plantilla, trabajaremos para alinear tu comprensión con la de otras personas clave de tu organización.
Empecemos por lo que es este trabajo.
¿Qué es un ingeniero de plantilla?
Si la única trayectoria profesional fuera convertirse en directivo (como en la empresa representada a la izquierda en la Figura 1-1), muchos ingenieros se enfrentarían a una elección dura y difícil: permanecer en un puesto de ingeniería y seguir creciendo en su oficio o pasar a la dirección y crecer en su carrera.
Por eso es bueno que muchas empresas ofrezcan ahora a una vía "técnica" o de "colaborador individual", que permite progresar profesionalmente en paralelo a las funciones directivas. La escalera de la derecha de la Figura 1-1 muestra un ejemplo.
Figura 1-1. Dos ejemplos de escalas profesionales, una de ellas con múltiples trayectorias.
Las escalas laborales varían de una empresa a otra, tanto que ha dado lugar a un sitio web, levels.fyi, que compara las escalas técnicas de las distintas empresas.1 El número de peldaños de estas escalas varía, al igual que los nombres de cada peldaño. Incluso puedes ver los mismos nombres en un orden diferente.2 Pero, muy a menudo, se utiliza la palabra senior. Marco Rogers, director de ingeniería que ha creado escalafones profesionales en dos empresas, ha descrito el nivel senior como el nivel "ancla" de un escalafón profesional. Como dice Rogers: "Los niveles inferiores son para que la gente aumente su autonomía; los niveles superiores aumentan el impacto y la responsabilidad".
Senior se considera a veces el nivel de "titularidad": no necesitas ir más allá.3 Pero si lo haces, entras en los niveles de "liderazgo técnico". El primer escalón por encima de senior suele denominarse "ingeniero de plantilla", y es el nombre que utilizaré a lo largo de este libro.
En la escala laboral de doble vía de la Figura 1-1, un ingeniero superior puede elegir adquirir las habilidades necesarias para ascender a un puesto de directivo o de ingeniero de plantilla. Una vez ascendido, un cambio de función de ingeniero de plantilla a directivo, o viceversa, se consideraría un movimiento lateral, no un nuevo ascenso. Un ingeniero de plantilla superior tendría la misma antigüedad que un directivo superior, un ingeniero principal equivaldría a un director, y así sucesivamente; esos niveles podrían continuar incluso más arriba en las escalas profesionales de la empresa. (Para representar todas las funciones por encima de senior, voy a utilizar staff+, expresión acuñada por Will Larson en su libro Staff Engineer).
Así es como se ve el trabajo en un escalafón. Pero veamos por qué existen los niveles de liderazgo técnico. En la introducción hablé de los tres pilares de la vía técnica: pensamiento global, ejecución de proyectos y subida de nivel. ¿Por qué necesitamos que los ingenieros tengan esas aptitudes? ¿Por qué necesitamos ingenieros de plantilla?
¿Por qué necesitamos ingenieros con visión de conjunto?
Cualquier organización de ingeniería está constantemente tomando decisiones: elegir tecnología, decidir qué construir, invertir en un sistema o desaprovecharlo. Algunas de estas decisiones tienen propietarios claros y consecuencias predecibles. Otras son elecciones arquitectónicas fundamentales que afectarán a todos los demás sistemas, y nadie puede afirmar que sabe exactamente cómo se desarrollarán.
Las buenas decisiones necesitan un contexto. Los ingenieros experimentados saben que la respuesta a la mayoría de las opciones tecnológicas es "depende". No basta con conocer los pros y los contras de una tecnología concreta, también hay que conocer los detalles locales. ¿Qué pretendes hacer? ¿De cuánto tiempo, dinero y paciencia dispones? ¿Cuál es tu tolerancia al riesgo? ¿Qué necesita la empresa? Ese es el contexto de la decisión.
Reunir el contexto requiere tiempo y esfuerzo. Los equipos individuales tienden a optimizar sus propios intereses; es probable que un ingeniero de un solo equipo esté centrado como un láser en alcanzar los objetivos de ese equipo. Pero a menudo las decisiones que parecen pertenecer a un equipo tienen consecuencias que se extienden mucho más allá de los límites de ese equipo. El máximo local, la mejor decisión para un solo grupo, puede no parecerse en nada a la mejor decisión cuando se adopta una perspectiva más amplia.
La Figura 1-2 muestra un ejemplo en el que un equipo debe elegir entre dos programas, A y B. Ambos tienen las características necesarias, pero A es mucho más fácil de configurar: simplemente funciona. B es un poco más difícil: harán falta un par de sprints para que funcione, y a nadie le entusiasma esperar tanto.
Desde el punto de vista del equipo, A es un claro ganador. ¿Por qué iban a elegir otra cosa? Pero otros equipos preferirían que eligieran B. Resulta que A supondrá un trabajo continuo para los equipos jurídico y de seguridad, y sus necesidades de autenticación significan que los equipos de TI y de plataforma tendrán que tratarlo siempre como un caso especial. Al elegir A, el máximo local, el equipo está eligiendo, sin saberlo, una solución que supone una inversión de tiempo mucho mayor para la empresa en general. B es sólo ligeramente peor para el equipo, pero mucho mejor en general. Esos dos sprints adicionales se amortizarán en un trimestre, pero este hecho sólo es evidente cuando el equipo cuenta con alguien que puede mirar a través de una lente más amplia.
Figura 1-2. Máximo local frente a mejor decisión.
Para evitar los máximos locales, los equipos necesitan responsables de la toma de decisiones (o al menos influyentes en la toma de decisiones) que puedan adoptar una visión externa, quepuedan considerar los objetivos de varios equipos a la vez y elegir un camino que sea el mejor para toda la organización o toda la empresa. El Capítulo 2 tratará de la ampliación y la visión de conjunto.
Tan importante como ver el panorama general de la situación ahora es ser capaz de anticipar cómo se desarrollarán tus decisiones en el futuro. Dentro de un año, ¿de qué te arrepentirás? Dentro de tres años, ¿qué desearás haber empezado a hacer ahora? Para avanzar en la misma dirección, los grupos deben ponerse de acuerdo sobre las estrategias técnicas: en qué tecnologías invertir, en qué plataformas estandarizarse, etc. Estas grandes decisiones pueden acabar siendo sutiles, y a menudo son controvertidas, por lo que es esencial para tomar la decisión ser capaz de compartir el contexto y ayudar a los demás a darle sentido. El Capítulo 3 trata sobre cómo elegir una dirección como grupo.
Por tanto, si quieres tomar decisiones amplias y con visión de futuro, necesitas personas que puedan ver el panorama general. Pero, ¿por qué no pueden serlo los directivos? ¿Y por qué el director de tecnología (CTO) no puede limitarse a conocer todas las "cosas del negocio", traducirlas en resultados técnicos y transmitir lo que importa?
En algunos equipos, sí pueden. En un equipo pequeño, un gestor puede funcionar a menudo como el tecnólogo más experimentado, haciéndose cargo de las decisiones importantes y de la dirección técnica. En una empresa pequeña, un director de tecnología puede implicarse a fondo en los detalles escabrosos de cada decisión. Estas empresas probablemente no necesiten ingenieros de plantilla. Pero la autoridad de la dirección puede eclipsar el juicio técnico: los informes pueden sentirse incómodos discutiendo las decisiones técnicas de un director, incluso cuando exista una solución mejor. Y dirigir a otros seres humanos es en sí mismo un trabajo a tiempo completo. Alguien que invierte en ser un buen gestor de personas tendrá menos tiempo disponible para mantenerse al día de los avances técnicos, y cualquiera que se las arregle para permanecer profundamente "en la maleza" será menos capaz de satisfacer las necesidades de sus informes. A corto plazo, eso puede estar bien: algunos equipos no necesitan mucha atención para seguir por el buen camino. Pero cuando hay tensión entre las necesidades del equipo y las necesidades de la estrategia técnica, un directivo tiene que elegir dónde centrarse. O se descuidan los miembros del equipo o su dirección técnica.
Esa es una de las razones por las que muchas organizaciones crean vías separadas para el liderazgo técnico y el liderazgo de personas. Si tienes más de unos pocos ingenieros, es ineficaz -por no decir que quita poder- que cada decisión tenga que acabar en la mesa del Director Técnico o de un alto directivo. Se obtienen mejores resultados y diseños si los ingenieros experimentados tienen tiempo para profundizar y crear el contexto y la autoridad necesarios para establecer la dirección técnica correcta.
Eso no significa que los ingenieros establezcan solos la dirección técnica. Los directivos, como responsables de asignar personal a las iniciativas técnicas, deben participar en las decisiones técnicas importantes. Hablaré de mantener la alineación entre ingenieros y directivos más adelante en este capítulo, y de nuevo cuando hablemos de estrategia en el Capítulo 3.
¿Por qué necesitamos ingenieros que dirijan proyectos que abarquen varios equipos?
En un mundo ideal, los equipos de una organización deberían encajar como piezas de un rompecabezas, cubriendo todos los aspectos de cualquier proyecto que esté en marcha. Sin embargo, en ese mismo mundo ideal, todos trabajan en un hermoso proyecto nuevo sin limitaciones previas ni sistemas heredados con los que trabajar, y cada equipo se dedica por completo a ese proyecto. Los límites de los equipos son claros e incontestables. De hecho, estamos empezando con lo que los consultores técnicos de Thoughtworks han denominado una Maniobra de Conway Inversa: un conjunto de equipos que se corresponden exactamente con los componentes de la arquitectura deseada. Las partes difíciles de este proyecto utópico son difíciles sólo porque implican una investigación y una invención profundas y fascinantes, y sus propietarios están ansiosos por el reto técnico y la gloria profesional de resolverlas.
Yo quiero trabajar en ese proyecto, ¿y tú? Por desgracia, la realidad es algo distinta. Es casi seguro que los equipos implicados en cualquier proyecto entre equipos ya existían antes de que se concibiera el proyecto y están trabajando en otras cosas, quizá incluso en cosas que consideran más importantes. Descubrirán dependencias inesperadas a mitad del proyecto. Los límites de sus equipos tienen solapamientos y lagunas que se filtran en la arquitectura. Y las partes turbias y difíciles del proyecto no son fascinantes problemas de investigación algorítmica: implican espeleología a través de código heredado, negociar con equipos ocupados que no quieren cambiar nada y adivinar las intenciones de ingenieros que se marcharon hace años.4 Incluso comprender lo que hay que cambiar puede ser un problema complejo, y no todo el trabajo puede saberse al principio. Si te fijas bien en la documentación del diseño, puede que descubras que pospone u omite las decisiones clave que más alineación necesitan.
Esa es una descripción de proyecto más realista. Por mucho cuidado que pongas en superponer equipos en un proyecto enorme, algunas responsabilidades acaban no perteneciendo a nadie, y otras son reclamadas por dos equipos. La información no fluye o se estropea en la traducción y causa conflictos. Los equipos toman excelentes decisiones locales máximas y los proyectos de software se atascan.
Una forma de mantener un proyecto en marcha es tener en a alguien que se sienta propietario de todo el asunto, más que de cualquiera de sus partes individuales. Incluso antes de que se inicie el proyecto, esa persona puede evaluar el trabajo y elaborar una propuesta. Una vez que el proyecto esté en marcha, es probable que sea el autor o coautor del diseño de alto nivel del sistema y un punto de contacto principal para el mismo. Mantienen un alto nivel de ingeniería, utilizando su experiencia para anticiparse a los riesgos y hacer preguntas difíciles. También dedican tiempo a orientar o entrenar informalmente -o simplemente a dar buen ejemplo- a los responsables de las distintas partes del proyecto. Cuando el proyecto se atasca, tienen la perspectiva suficiente para rastrear las causas y desbloquearlo (más sobre esto en el Capítulo 6). Fuera del proyecto, cuentan la historia de lo que está ocurriendo y por qué, venden la visión al resto de la empresa y explican lo que el trabajo hará posible y cómo el nuevo proyecto afecta a todos.
¿Por qué los directores técnicos de programa (TPM) no pueden hacer esto creación de consenso y comunicación? No cabe duda de que hay cierto solapamiento de responsabilidades. En última instancia, sin embargo, los TPM son responsables de la entrega, no del diseño ni de la calidad de la ingeniería. Los TPM se aseguran de que el proyecto se haga a tiempo, pero los ingenieros de plantilla se aseguran de que se haga con altos niveles de ingeniería. Los ingenieros de plantilla son responsables de que los sistemas resultantes sean robustos y encajen bien en el panorama tecnológico de la empresa. Son cautelosos con la deuda técnica y recelosos con todo lo que sea una trampa para los futuros mantenedores de esos sistemas. No sería habitual que los TPM escribieran diseños técnicos o establecieran normas de proyecto para las pruebas o la revisión del código, y nadie espera que hagan una inmersión profunda en las tripas de un sistema heredado para decidir qué equipos tendrán que integrarse en él. Cuando un ingeniero de plantilla y un TPM trabajan bien juntos en un gran proyecto, pueden ser un equipo de ensueño.
¿Por qué necesitamos ingenieros que sean una buena influencia?
El software importa. Los sistemas de software que construimos pueden afectar al bienestar y a los ingresos de las personas: La lista de errores de software de Wikipedia es una buena, aunque aleccionadora, lectura. Los accidentes aéreos, los fallos del sistema de ambulancias y el mal funcionamiento de los equipos médicos nos han enseñado que los fallos y las interrupciones del software pueden matar a personas, y sería ingenuo suponer que en el futuro no se producirán más y mayores tragedias relacionadas con el software.5 Tenemos que tomarnos en serio el software.
Incluso cuando lo que está en juego es menor, seguimos creando software por una razón. Salvo contadas excepciones de I+D, las organizaciones de ingeniería no suelen existir por el mero hecho de crear más tecnología. Se proponen resolver un problema empresarial real o crear algo que la gente quiera utilizar. Y les gustaría conseguirlo con un nivel aceptable de calidad, un uso eficiente de los recursos y un mínimo de caos.
Por supuesto, la calidad, la eficacia y el orden están lejos de estar garantizados, sobre todo cuando hay plazos de entrega de por medio. Cuando hacer las cosas "bien" significa ir más despacio, los equipos que están impacientes por entregar el producto pueden saltarse las pruebas, tomar atajos o hacer revisiones del código. Y crear un buen software no es fácil ni intuitivo. Los equipos necesitan personas veteranas que hayan perfeccionado sus habilidades, que hayan visto lo que tiene éxito y lo que fracasa, y que asuman la responsabilidad de crear software que funcione.
Aprendemos de cada proyecto, pero cada uno de nosotros sólo tiene un número finito de experiencias sobre las que reflexionar. Eso significa que también tenemos que aprender de los errores y aciertos de los demás. Es posible que los miembros menos experimentados del equipo nunca hayan visto hacer un buen software, o que consideren que producir código es la única habilidad importante en la ingeniería de software. Los ingenieros más experimentados pueden tener un gran impacto realizando revisiones de código y diseño, proporcionando buenas prácticas arquitectónicas y creando el tipo de herramientas que hacen que todo el mundo sea más rápido y seguro.
Los ingenieros de plantilla son modelos de conducta. Los directivos pueden ser responsables de establecer la cultura en sus equipos, imponer el buen comportamiento y garantizar el cumplimiento de las normas. Pero las normas de ingeniería las establece el comportamiento de los ingenieros más respetados del proyecto. Digan lo que digan las normas, si los ingenieros más veteranos no escriben pruebas, nunca convencerás a todos los demás de que lo hagan. Estas normas van más allá de la influencia técnica: también son culturales. Cuando los más veteranos celebran el trabajo de los demás, se tratan con respeto y hacen preguntas aclaratorias, es más fácil que los demás también lo hagan. Cuando los ingenieros que empiezan su carrera respetan a alguien como el tipo de ingeniero que quieren "ser de mayores", eso es una poderosa motivación para actuar como ellos.( Enel Capítulo 7 se explorará la posibilidad de subir de nivel en tu organización siendo un modelo a seguir).
Quizá ahora estés convencido de que los ingenieros de deben hacer estas cosas de gran visión, gran proyecto y buena influencia, pero aquí está el problema: no pueden hacerlo además de la carga de trabajo de codificación de un ingeniero superior. Cada hora que pasas escribiendo estrategias, revisando diseños de proyectos o estableciendo normas, no estás codificando, diseñando nuevos sistemas o haciendo gran parte del trabajo por el que se podría evaluar a un ingeniero de software. Si los ingenieros más veteranos de una empresa se limitan a escribir código todo el día, el código base verá el beneficio de sus habilidades, pero la empresa se perderá las cosas que sólo ellos pueden hacer. Este tipo de liderazgo técnico debe formar parte de la descripción del puesto de la persona que lo ejerce. No es una distracción del trabajo: es el trabajo.
Basta de Filosofía. ¿Cuál es mi trabajo?
Los detalles de un puesto de ingeniero de personal pueden variar. Sin embargo, hay algunos atributos del trabajo que creo que son bastante consistentes. Los expondré aquí, y el resto del libro los tomará como axiomáticos.
No eres un directivo, pero eres un líder
Lo primero es lo primero: la ingeniería de personal es una función de liderazgo. Un ingeniero de plantilla suele tener la misma antigüedad que un jefe de línea. Un ingeniero principal suele tener la antigüedad de un director. Como ingeniero de plantilla+, eres el homólogo de un directivo del mismo nivel, y se espera de ti que seas tan "el adulto en la sala" como ellos. Puede que incluso te des cuenta de que tienes más antigüedad y experiencia que algunos de los directivos de tu organización. Siempre que exista la sensación de que "alguien debería hacer algo aquí", hay una posibilidad razonable de que ese alguien seas tú.
¿Tienes que ser un líder? Los ingenieros de nivel medio a veces me preguntan si realmente necesitan ser buenos en "esas cosas humanas blandas" para llegar más lejos. ¿No son suficientes las habilidades técnicas? Si eres el tipo de persona que se metió en la ingeniería de software porque quería hacer trabajo técnico y no le gusta hablar con otros seres humanos, puede parecer injusto que tu vocación tropiece con este muro. Pero si quieres seguir creciendo, profundizar en la tecnología sólo puede llevarte hasta cierto punto. Conseguir cosas más grandes significa trabajar con grupos más grandes de personas, y eso requiere un conjunto más amplio de habilidades.
A medida que aumente tu remuneración y tu tiempo sea cada vez más caro, se espera que el trabajo que hagas sea más valioso y tenga un mayor impacto. Tu juicio técnico tendrá que incluir la realidad del negocio y si merece la pena hacer un proyecto determinado. A medida que aumentes en antigüedad, te harás cargo de proyectos más grandes, proyectos que no pueden tener éxito sin colaboración, comunicación y alineación; tus soluciones brillantes sólo van a causarte frustración si no puedes convencer a las demás personas del equipo de que el tuyo es el camino correcto. Y lo quieras o no, serás un modelo a seguir: otros ingenieros se fijarán en los que tienen grandes cargos para saber cómo comportarse. Así que no: no puedes evitar ser un líder.
Sin embargo, los ingenieros de plantilla dirigen de forma diferente a los directivos. Un ingeniero de plantilla no suele tener subordinados directos. Aunque se implican e invierten en el desarrollo de las capacidades técnicas de los ingenieros que les rodean, no son responsables de gestionar el rendimiento de nadie ni de aprobar las vacaciones o los gastos. No pueden despedir ni ascender, aunque los jefes de equipo locales deben valorar sus opiniones sobre las aptitudes y el rendimiento de otros miembros del equipo. Su impacto se produce de otras maneras.
El liderazgo se presenta de muchas formas que quizá no reconozcas inmediatamente como tales. Puede venir del diseño de soluciones de "camino feliz" que protegen a otros ingenieros de errores comunes. Puede venir de revisar el código y los diseños de otros ingenieros de forma que mejore su confianza y sus habilidades, o de poner de relieve que una propuesta de diseño no satisface una auténtica necesidad empresarial. Enseñar es una forma de liderazgo. Elevar silenciosamente el nivel de todos es liderazgo. Establecer la dirección técnica es liderazgo. Por último, tener la reputación de ser un tecnólogo estelar puede inspirar a otras personas a participar en tus planes sólo porque confían en ti. Si eso suena a ti, ¿adivina qué? Eres un líder.
Tienes un papel "técnico
La ingeniería de personal es una función de liderazgo, pero también es profundamente especializada. Requiere formación técnica y el tipo de habilidades e instintos que se derivan de la experiencia en ingeniería. Para ser una buena influencia, tienes que tener un alto nivel de exigencia en cuanto a cómo es la ingeniería excelente y modelarla cuando construyes algo. Tus revisiones de código o diseños deben ser instructivas para tus colegas y deben hacer que tu código base o tu arquitectura sean mejores. Cuando tomes decisiones técnicas, tienes que entender las compensaciones y ayudar a los demás a entenderlas también. Tienes que ser capaz de sumergirte en los detalles cuando sea necesario, hacer las preguntas adecuadas y comprender las respuestas. Cuando defiendas una determinada línea de actuación, o un determinado cambio en la cultura técnica, tienes que saber de qué estás hablando. Así que tienes que tener una sólida base de conocimientos técnicos.
Esto no significa necesariamente que vayas a escribir mucho código. A este nivel, tu objetivo es resolver problemas de forma eficaz, y a menudo la programación no será el mejor uso de tu tiempo. Puede tener más sentido que te encargues del trabajo de diseño o liderazgo que sólo tú puedes hacer y dejes que otros se ocupen de la programación. Los ingenieros de plantilla suelen asumir problemas ambiguos, desordenados y difíciles, y trabajan en ellos lo justo para que otra persona pueda manejarlos. Una vez que el problema es manejable, se convierte en una oportunidad de crecimiento para los ingenieros menos experimentados (a veces con el apoyo del ingeniero de plantilla).
Para algunos ingenieros de plantilla, bucear profundamente en las bases de código seguirá siendo la herramienta más eficaz para resolver muchos problemas. Para otros, escribir documentos puede dar mejores resultados, o convertirse en un maestro del análisis de datos, o tener un número aterrador de reuniones individuales. Lo que importa es que se resuelvan los problemas, no cómo.6
Aspiras a ser autónomo
Cuando empezaste como ingeniero, tu jefe probablemente te dijo en qué tenías que trabajar y cómo enfocarlo. A nivel superior, tal vez tu jefe te aconsejaba sobre qué problemas era importante resolver, y te dejaba a ti la tarea de averiguar qué hacer al respecto. En los niveles staff+, tu jefe debe traerte información y compartir el contexto, pero tú debes decirle lo que es importante tanto como al revés. Como pregunta Sabrina Leandro, ingeniera principal de Intercom: "Así que sabes que debes trabajar en cosas que tengan impacto y sean valiosas. Pero, ¿dónde encuentras esa mágica acumulación de trabajo de alto impacto que deberías estar haciendo?". Su respuesta: " ¡Lo creas!"
Como alto cargo de la organización, es probable que te tironeen en muchas direcciones. De ti depende defender y estructurar tu tiempo. Hay un número finito de horas a la semana (véase el Capítulo 4). Tú eliges cómo emplearlas. Si alguien te pide que trabajes en algo, aportarás tu experiencia a la decisión. Sopesarás la prioridad, el compromiso de tiempo y los beneficios -incluida la relación que quieres mantener con la persona que te ha pedido ayuda- y tomarás tu propia decisión. Si tu director general u otra figura de autoridad local te dice que necesitan que se haga algo, le darás la importancia adecuada. Pero la autonomía exige responsabilidad. Si aquello en lo que te han pedido que trabajes resulta ser perjudicial, tienes la responsabilidad de denunciarlo. No dejes que se produzca un desastre en silencio. (Por supuesto, si quieres que te hagan caso, tendrás que haberte forjado una reputación de ser digno de confianza y correcto).
Tú estableces la dirección técnica
Como líder técnico, parte del papel de un ingeniero de plantilla es asegurarse de que la organización tiene una buena dirección técnica. Detrás del producto o servicio que ofrece tu organización hay una serie de decisiones técnicas: tu arquitectura, tus sistemas de almacenamiento, las herramientas y marcos de trabajo que utilizas, etc. Tanto si estas decisiones se toman a nivel de equipo como a través de varios equipos u organizaciones enteras, parte de tu trabajo consiste en asegurarte de que se toman, de que se toman bien y de que se escriben. El trabajo no consiste en idear todos (¡ni siquiera necesariamente ninguno!) los aspectos de la dirección técnica, sino en garantizar que haya una solución acordada y bien entendida que resuelva los problemas que se propone resolver.
Comprender tu papel
Esos axiomas deberían ayudarte a empezar a definir tu papel, ¡pero te darás cuenta de que dejan fuera muchos detalles de la puesta en práctica! Lo cierto es que el trabajo diario de un ingeniero de plantilla puede ser muy distinto del de otro. Las realidades de tu función dependerán del tamaño y las necesidades de tu empresa u organización, y también se verán influidas por tu estilo de trabajo y tus preferencias personales.
Esta variación significa que puede ser difícil comparar tu trabajo con el de los ingenieros de plantilla de tu entorno o de otras empresas. Por eso, en este apartado vamos a desgranar algunos de los atributos más variables de esta función.
Empecemos por las cadenas de información.
¿En qué lugar de la organización te sientas?
Nuestro sector no se ha decantado por ningún modelo estándar sobre cómo informan los ingenieros staff+ al resto de la organización de ingeniería. Algunas empresas hacen que sus ingenieros más veteranos informen a un arquitecto jefe o a la oficina del director de tecnología; otras los asignan a directores de diversas organizaciones, a gerentes de varios niveles, o a una mezcla de todo lo anterior. Aquí no hay una respuesta correcta, pero puede haber muchas respuestas incorrectas, dependiendo de lo que intentes conseguir.
Las cadenas jerárquicas (véase el ejemplo de la Figura 1-3) afectarán al nivel de apoyo que recibas, a la información de que dispongas y, en muchos casos, a cómo te perciban los colegas de fuera de tu grupo.
Figura 1-3. Ingenieros de Staff+ informando en distintos niveles de la jerarquía orgánica. Aunque todos estos ingenieros tengan el mismo nivel de antigüedad, a A le resultará mucho más fácil tener un contexto organizativo y participar en conversaciones a nivel de director que a D.
Informar "alto"
Informar "alto" en el organigrama, por ejemplo a un director o vicepresidente, te dará una perspectiva amplia. La información que recibas será de alto nivel e impactante, al igual que los problemas que se te pida que resuelvas. Si dependes de un directivo muy competente, verle tomar decisiones, dirigir reuniones o gestionar una crisis puede ser una experiencia de aprendizaje única y valiosa.
Dicho esto, es probable que tu jefe te dedique mucho menos tiempo que si tuvieras un jefe local. Es posible que tu jefe tenga menos visibilidad de tu trabajo y, por tanto, no pueda abogar por ti ni ayudarte a crecer. Un ingeniero que trabaje estrechamente con un solo equipo pero dependa de un director puede sentirse desconectado del resto del equipo o puede atraer la atención del director hacia desacuerdos locales que deberían haberse resuelto a nivel de equipo.
Si crees que tu jefe no está disponible, no tiene tiempo para entender el trabajo que haces o se ve arrastrado a tomar decisiones técnicas de bajo nivel que no son un buen uso de su tiempo, considera que podrías ser más feliz con un jefe cuyo enfoque esté más alineado con el tuyo.
Informar "bajo"
Estar a las órdenes de un directivo situado más abajo en el organigrama conlleva sus propias ventajas y desventajas. Lo más probable es que recibas una atención más centrada por parte de tu jefe, y es más probable que tengas un defensor. Si prefieres centrarte en una sola área técnica, puede que te beneficie trabajar con un directivo cercano a esa área.
Pero un ingeniero asignado a un solo equipo puede tener dificultades para influir en toda la organización. Nos guste o no, los seres humanos prestan atención al estatus y a las jerarquías, y a las cadenas jerárquicas. Es probable que tengas mucha menos influencia si dependes de un superior jerárquico. También es probable que la información que recibas esté más filtrada y centrada en los problemas de ese equipo concreto. Si tu jefe no tiene acceso a cierta información, es casi seguro que tú tampoco.
Depender de un superior jerárquico también puede significar que dependes de alguien con menos experiencia que tú. Eso no es intrínsecamente un problema, pero puede que tengas menos que aprender de tu jefe, y puede que no sea útil para el desarrollo de tu carrera: lo más probable es que no sepa cómo ayudarte. Todo esto puede estar bien si satisfaces algunas de tus necesidades de gestión en otra parte.7 En particular, si estás a las órdenes de alguien que ocupa un puesto bajo en la jerarquía de la organización, asegúrate de mantener reuniones de nivel salteado con el jefe de tu jefe.8 Encuentra formas de mantenerte conectado con los objetivos de tu organización.
Si tú y tu jefe tenéis ideas diferentes sobre cómo podéis ser más eficaces, eso puede causar tensiones. Puedes acabar con un caso de los problemas máximos locales que he mencionado antes, en el que tu jefe quiere que trabajes en la preocupación más importante del equipo , cuando hay problemas mucho mayores dentro de la organización que te necesitan más. Es más difícil que se produzca un debate técnico o de priorización en igualdad de condiciones cuando una persona es responsable de la calificación del rendimiento y la remuneración de la otra. Si ves que estas discusiones ocurren a menudo, quizá debas abogar por reportarte a un nivel superior.
¿Cuál es tu alcance?
Es probable que tu cadena de informes afecte a tu ámbito: el dominio, equipo o equipos a los que prestas mucha atención y sobre los que tienes alguna responsabilidad, aunque no tengas ningún papel formal de liderazgo en este dominio.
Dentro de tu ámbito, deberías tener cierta influencia en los objetivos a corto y largo plazo. Deberías estar al tanto de las principales decisiones que se toman. Deberías opinar sobre los cambios y representar a las personas que no tienen influencia para evitar las malas decisiones técnicas que les afectan. Deberías pensar en cómo cultivar y desarrollar la próxima generación de ingenieros superiores y de plantilla, y darte cuenta y sugerir proyectos y oportunidades que les ayuden a crecer.
En algunos casos, tu jefe puede esperar que dediques la mayor parte de tus habilidades y energía a resolver problemas que entran dentro de su dominio. En otros casos, un equipo puede ser simplemente una base de operaciones mientras dedicas parte de tu tiempo a incendios u oportunidades en otros lugares de la org. Si dependes de un director, puede haber una suposición implícita de que operas a un alto nivel y unes el trabajo de todo lo que ocurre en la organización, o puede que se te asigne explícitamente a algún subconjunto de los equipos o áreas tecnológicas del director. Ten claro cuál es.
Prepárate para ignorar tu alcance cuando haya una crisis: no existe eso de "no es mi trabajo" durante una interrupción, por ejemplo. También debes sentirte cómodo saliendo de tu experiencia cotidiana, liderando cuando sea necesario, aprendiendo lo que tengas que aprender y arreglando lo que tengas que arreglar. Parte del valor de un ingeniero de plantilla es que no te quedas en tu carril.
No obstante, te recomiendo que tengas muy claro cuál es tu ámbito de actuación, aunque sea temporal y esté sujeto a cambios.
Un ámbito demasiado amplio
Si tu alcance es demasiado amplio (o indefinido), hay unos cuantos modos de fallo posibles.
- Falta de impacto
- Si cualquier cosa puede ser tu problema, entonces es fácil que todo se convierta en tu problema, sobre todo si estás en una organización con menos altos cargos de los que necesita. Siempre habrá otra búsqueda secundaria: de hecho, es demasiado fácil crear un papel que sea totalmente una búsqueda secundaria, sin ningún objetivo real.9 Cuidado con extenderte demasiado. Puedes acabar sin una narrativa de tu trabajo que te haga sentir (a ti y a quien te haya contratado) que has conseguido algo.
- Convertirse en un cuello de botella
- Cuando hay una persona de alto nivel que se ve que lo hace todo, la convención puede convertirse en que necesita estar en la sala para cada decisión. En lugar de acelerar tu organización, acabas ralentizándola porque no pueden arreglárselas sin ti.
- Fatiga de decisión
- Si escapas de la trampa de intentar hacerlo todo, tendrás el coste constante de decidir qué cosas hacer. En el Capítulo 4 hablaré de cómo elegir tu trabajo.
- Relaciones perdidas
- Si trabajas con un conjunto muy amplio de equipos, es más difícil tener suficiente contacto regular para establecer el tipo de relaciones amistosas que facilitan la consecución de los objetivos (¡y que hacen que el trabajo sea agradable!). Otros ingenieros también salen perdiendo: no reciben el tipo de tutoría y apoyo que supone tener un ingeniero de plantilla "local" implicado en su trabajo.
Es difícil funcionar en un lugar de trabajo donde puedes hacer literalmente cualquier cosa. Es mejor elegir un área, crear influencia y tener algunos éxitos en ella. Dedica tu tiempo a resolver algunos problemas por completo. Luego, si estás preparado, pasa a otra área.
Un ámbito de aplicación demasiado estrecho
Ten cuidado también con limitarte demasiado. Un ejemplo habitual es cuando un ingeniero de plantilla forma parte de un único equipo, bajo las órdenes de un superior jerárquico. Esto puede gustar mucho a los jefes: obtienen un ingeniero muy experimentado que puede realizar un gran porcentaje del diseño y la planificación técnica, y quizás actuar como líder técnico o jefe de equipo de un proyecto. A algunos ingenieros también les encantará: significa que puedes profundizar mucho en las tecnologías y problemas del equipo y comprender todos los matices. Pero ten cuidado con los riesgos de un alcance demasiado estrecho:
- Falta de impacto
- Es posible dedicar todo tu tiempo a algo que no necesite la experiencia y el enfoque de un ingeniero de plantilla. Si decides profundizar mucho en un solo equipo o tecnología, debe ser un componente básico, un equipo de misión crítica o algo muy importante para la empresa.
- Coste de oportunidad
- Las habilidades de los ingenieros de plantilla suelen estar muy solicitadas. Si estás asignado a un solo equipo, puede que no seas el primero en la mente para resolver un problema en otra parte de la org, o puede que tu jefe no esté dispuesto a dejarte marchar.
- Hacer sombra a otros ingenieros
- Un ámbito reducido puede significar que no hay suficiente trabajo en para mantenerte ocupado, y que puedes eclipsar a personas menos experimentadas y quitarles oportunidades de aprendizaje. Si siempre tienes tiempo para responder a todas las preguntas y ocuparte de todos los problemas complicados, nadie más adquiere experiencia en hacerlo.
- Sobreingeniería
- Un ingeniero que no está ocupado puede tener tendencia a crearse trabajo. Cuando veas una solución muy sobredimensionada a un problema sencillo, a menudo es obra de un ingeniero de plantilla que debería haber sido asignado a un problema más difícil.
Algunos dominios y proyectos técnicos son lo suficientemente profundos como para que un ingeniero pueda pasar toda su carrera en ellos y nunca se quede sin oportunidades. Ten muy claro si estás en uno de esos espacios.
¿Qué forma tiene tu papel?
Siempre que haya consenso general en que tu trabajo tiene impacto, deberías tener mucha flexibilidad en cuanto a cómo lo haces. Eso incluye una cierta definición de lo que es tu trabajo. He aquí algunas preguntas que debes hacerte:
¿Enfocas las cosas en profundidad o en amplitud?
¿Prefieres centrarte en un único problema o área tecnológica? ¿O te inclinas más por la amplitud en varios equipos o tecnologías, centrándote en un solo problema sólo cuando no puede resolverse sin ti? Ser más profundo o más amplio tiene mucho que ver con tu personalidad y estilo de trabajo.
No hay una respuesta incorrecta, pero te resultará más fácil y agradable si tus preferencias se ajustan a tu ámbito de actuación. Por ejemplo, si quieres influir en la dirección técnica de tu organización o empresa, te encontrarás gravitando hacia las oportunidades de tener una visión más amplia. Tendrás que estar en las salas donde se toman las decisiones y abordar problemas que afectan a muchos equipos. Si intentas hacerlo mientras estás asignado a un único problema arquitectónico profundo, nadie saldrá ganando. Por otra parte, si tu objetivo es convertirte en un experto del sector en un ámbito técnico concreto, tendrás que ser capaz de centrarte y dedicar la mayor parte de tu tiempo a esa área.
¿Hacia cuál de las "cuatro disciplinas" te inclinas?
Yonatan Zunger, distinguido ingeniero en Twitter, describe las cuatro disciplinas que se necesitan en cualquier trabajo del mundo:
- Competencias técnicas básicas
- Codificar, litigar, producir contenidos, cocinar: cualquier cosa en la que trabaje un profesional típico de la función
- Gestión de productos
- Averiguar qué hay que hacer y por qué, y mantener una narrativa sobre ese trabajo
- Gestión de proyectos
- Los aspectos prácticos de alcanzar el objetivo, eliminar el caos, hacer un seguimiento de las tareas, darse cuenta de lo que está bloqueado y asegurarse de que se desbloquea
- Gestión de personas
- Convertir a un grupo de personas en un equipo, desarrollar sus capacidades y carreras, orientarlas y ocuparse de sus problemas.
Zunger señala que cuanto más alto es tu nivel, menos se corresponde tu combinación de estas habilidades con tu puesto de trabajo: "Cuanto más alto llegas, más se cumple esto, cada vez hay más expectativas de que puedas cambiar entre cada uno de estos cuatro tipos de trabajo con facilidad y fluidez, y funcionar en todas las salas".
Cada equipo y cada proyecto necesitan estas cuatro habilidades. Como ingeniero de plantilla, las utilizarás todas. Sin embargo, no es necesario que seas asombroso en todas ellas. Todos tenemos distintas aptitudes y disfrutamos o evitamos distintos tipos de trabajo. Quizá te resulte obvio cuáles te gustan y cuáles esperas no necesitar nunca. Si no estás seguro, Zunger sugiere hablar de cada una de ellas con un amigo y que observe tu respuesta emocional y tu energía mientras habláis de ellas. Si hay alguna que realmente odias, asegúrate de que trabajas con alguien que está deseando hacer ese aspecto del trabajo. Tanto si prefieres la amplitud como la profundidad, te resultará difícil seguir creciendo sólo con las habilidades técnicas básicas.
¿Cuánto quieres (o necesitas) codificar?
Por "codificación" aquí, siéntete libre de cambiar el núcleo trabajo técnico de tu carrera hasta ahora. Este conjunto de habilidades probablemente te ha llevado hasta donde estás hoy, y puede resultar incómodo sentir que te estás oxidando o desactualizando. Algunos ingenieros de plantilla se dan cuenta de que acaban leyendo o revisando mucho código, pero escribiendo poco. Otros son colaboradores principales de los proyectos, codificando todos los días. Un tercer grupo encuentra razones para codificar, encargándose de proyectos no críticos que serán interesantes o educativos, pero que no retrasarán el proyecto.
Si vas a sentirte inquieto a menos que estés en el código todos los días, asegúrate de que no estás asumiendo un amplio papel arquitectónico o de influencia en el que simplemente no tendrás tiempo. O al menos ten un plan sobre cómo vas a rascarte ese picor, para que puedas resistirte a saltar sobre tareas de codificación y dejar que los problemas más grandes se arreglen solos.
¿Cómo va tu gratificación diferida?
Codificar tiene ciclos de retroalimentación reconfortantemente rápidos: cada compilación o prueba realizada con éxito te dice cómo van las cosas. ¡Es como una pequeña revisión de rendimiento cada día! Puede ser desalentador avanzar hacia un trabajo que no tiene ciclos de retroalimentación incorporados que te digan si vas por el buen camino.
En un proyecto a largo plazo o interorganizativo, o con un cambio de estrategia o de cultura, pueden pasar meses -o incluso más tiempo- antes de que tengas una señal clara sobre si lo que estás haciendo funciona. Si vas a estar ansioso y estresado en un proyecto con ciclos de retroalimentación más largos, pide a un jefe en quien confíes que te diga, con regularidad y sinceridad, cómo van las cosas. Si necesitas eso y no lo tienes, plantéate proyectos que den resultados en un plazo más corto.
¿Mantienes un pie en la vía del directivo?
Aunque la mayoría de los ingenieros de plantilla no tienen subordinados directos, algunos sí los tienen. Un director técnico (TLM), a veces llamado jefe de equipo, es una especie de función híbrida en la que el ingeniero de plantilla es el jefe técnico de un equipo y también lo dirige. Es un puesto famoso por su dificultad. Puede ser un reto ser responsable tanto de los resultados humanos como de los técnicos sin sentir que fracasas en uno u otro. También es difícil encontrar tiempo para invertir en el desarrollo de habilidades en ambos lados, y he oído a gente de TLM lamentar una pérdida de progresión profesional como resultado.
Algunas personas asumen un papel de dirección durante un par de años, y luego un papel de ingeniero de plantilla, yendo y viniendo de vez en cuando para mantener afiladas sus habilidades en ambos lados.10 Veremos más sobre este "péndulo" y sobre las funciones de TLM en el Capítulo 9.
¿Alguno de estos arquetipos encaja contigo?
En su artículo "Arquetipos de personal", Will Larson describe cuatro patrones distintos que ha visto adoptar a los roles de ingeniería de personal. Puedes utilizar estos arquetipos para definir el tipo de función que tienes, o que te gustaría tener:
- Líderes tecnológicos
- Asóciate con los directivos para guiar la ejecución de uno o varios equipos.
- Arquitectos
- Responsable de la dirección técnica y la calidad en un área crítica.
- Solucionadores
- Adéntrate en un problema difícil cada vez.
- Manos derechas
- Añade ancho de banda de liderazgo a una organización.
Si no te ves en ninguno de esos arquetipos, o tu papel cruza más de uno de ellos, ¡no pasa nada! Estos arquetipos no pretenden ser prescriptivos; nos dan conceptos que podemos utilizar para articular cómo preferimos trabajar.
¿Cuál es tu objetivo principal?
Así que hemos hablado de tu ámbito y tu cadena jerárquica: los límites aproximados de la parte de la organización en la que operas, y en qué lugar de la organización te sitúas. También hemos examinado tus aptitudes: cómo te gusta trabajar y qué tipo de habilidades te atraen. Pero incluso si entiendes todo eso y tienes una idea clara de la forma de tu función, queda una pregunta: ¿en qué vas a trabajar?
A medida que crezcas en influencia, te darás cuenta de que cada vez más gente quiere que te preocupes por las cosas. Alguien está elaborando un documento de buenas prácticas sobre cómo realiza tu organización la revisión de código, y quiere tu opinión. Tu grupo está haciendo una campaña de contratación y necesita ayuda para decidir qué entrevistar. Hay una desaprobación que progresaría más si contara con un ingeniero de plantilla que consiguiera el patrocinio de los directivos. Y eso es sólo el lunes por la mañana. ¿Y tú qué haces?
En algunos casos, tu jefe o alguien de quien dependas tendrá opiniones firmes sobre dónde debes centrarte, o incluso te habrá contratado específicamente para resolver un problema concreto. La mayoría de las veces, sin embargo, tendrás cierta autonomía para decidir qué es lo más importante. Cada vez que eliges en qué trabajar, también estás eligiendo qué no hacer, así que sé deliberado y reflexiona sobre lo que aceptas.
¿Qué es lo importante?
Al principio de tu carrera, si haces un gran trabajo en algo que resulta ser innecesario, aún así habrás hecho un gran trabajo. Sin embargo, a nivel de ingeniero de plantilla, todo lo que haces tiene un elevado coste de oportunidad, por lo que tu trabajo tiene que ser importante.
Desgranemos esto por un momento. "Tu trabajo tiene que ser importante" no significa que sólo debas trabajar en las tecnologías más elegantes y glamurosas y en las iniciativas patrocinadas por el vicepresidente. El trabajo más importante suele ser el que nadie ve. Puede que te cueste incluso articular su necesidad, porque tus equipos aún no tienen buenos modelos mentales para ello. Puede implicar recopilar datos que no existen, o escarbar en código polvoriento o documentos que no se han tocado en una década. Hay muchas otras tareas sucias que hay que hacer. El trabajo significativo tiene muchas formas.
Conoce por qué el problema en el que estás trabajando es estratégicamente importante, y si no lo es, haz otra cosa.
¿Qué necesitas?
Se da una situación similar cuando una persona senior se dedica al tipo de proyecto de codificación que cualquier ingeniero de nivel medio podría haber asumido: va a hacer un trabajo estelar en él, pero lo más probable es que haya un problema del tamaño de un senior que el ingeniero de nivel medio no sería capaz de abordar. Para usar una frase hecha que mi hijo soltó profundamente un día: "No plantas hierba en tu único barril".
Desconfía de elegir un proyecto en el que ya trabaje mucha gente veterana. Averigua quién más está trabajando en el problema y si parece probable que consigan resolverlo. Algunos proyectos pueden incluso verse ralentizados por la incorporación de un líder más.11 En general, si hay más gente siendo la sabia voz de la razón que gente tecleando código (o lo que sea equivalente en tu proyecto), no te metas. Intenta elegir un problema que realmente te necesite y que se beneficie de tu atención. El Capítulo 4 te dará algunas herramientas para decidir qué proyectos asumir.
Alineación sobre el alcance, la forma y el objetivo principal
A estas alturas, deberías tener una imagen bastante clara de cuál es el alcance de tu función, cómo está configurada y en qué estás trabajando ahora mismo. Pero, ¿estás seguro de que tu imagen coincide con la de los demás? Las expectativas de tu jefe y de tus colegas pueden diferir mucho de las tuyas sobre lo que es un ingeniero de plantilla, la autoridad que tienes para tomar decisiones y un sinfín de otras grandes cuestiones. Si vas a incorporarte a una empresa como ingeniero de plantilla, lo mejor es aclarar todo esto desde el principio.
Una técnica que aprendí de mi amigo Cian Synnott es escribir lo que entiendo de mi trabajo y compartirlo con mi jefe. Puede resultar un poco intimidante responder a la pregunta "¿Qué haces aquí?". ¿Y si los demás piensan que lo que haces es inútil, o creen que no lo haces bien? Pero escribirlo elimina la ambigüedad, y descubrirás pronto si tu modelo mental del papel es el mismo que el de los demás. Mejor ahora que en el momento de la revisión del rendimiento.
He aquí cómo podría ser la descripción de un puesto de este tipo para Ali, un ingeniero de plantilla del tipo "arquitecto con amplitud de miras", que está ayudando (pero no dirigiendo) un gran proyecto de varios equipos.
No te obsesiones con hacerlo perfecto: hazlo lo suficientemente bien. Describir tus objetivos no significa que tengas prohibido hacer otra cosa. Pero es un buen recordatorio de lo que pretendías hacer, y te ayuda a vigilar si realmente estás haciendo lo que decías que era tu trabajo.
Puede que decidas que tu enfoque necesita cambiar antes de lo que esperabas. El estado del mundo puede cambiar o tus prioridades pueden cambiar. Si es así, redacta una nueva descripción de funciones con la nueva información. Ser claro sobre lo que esperas de ti mismo garantiza que todo el mundo esté de acuerdo.
¿Es ese tu trabajo?
Tu trabajo es hacer que tu organización tenga éxito. Puede que seas un experto en tecnología o un programador o que estés afiliado a un equipo específico, pero en última instancia tu trabajo es ayudar a tu organización a alcanzar sus objetivos. Los directivos hacen muchas cosas que no están en la descripción de su trabajo principal. Pueden acabar haciendo cosas que no tienen sentido en la descripción del trabajo de nadie. Pero si es lo que el proyecto necesita para tener éxito, considera la posibilidad de hacerlo.
Algunos de mis compañeros de trabajo en Squarespace cuentan la historia de un día de 2012 en que su centro de datos sufrió un apagón y tuvieron que subir 17 tramos de escaleras cargados de combustible para mantenerlo en línea. "Transportar barriles de gasóleo" no aparece en la mayoría de las descripciones de puestos técnicos, pero eso es lo que se necesitaba para mantener el sitio en línea (¡y funcionó!). Cuando se inundó la sala de máquinas del ISP en el que trabajé hace años, el trabajo consistió en hacer una cadena de cubos de basura para mantener bajo el nivel del agua. Y cuando un proyecto de Google en 2005 se estaba retrasando y no disponíamos de suficientes empleados de hardware, mi trabajo durante un par de días consistió en montar servidores en un centro de datos de San José. Haces lo que tienes que hacer para que el proyecto salga adelante.
Normalmente este trabajo "no es mi trabajo" es menos dramático, por supuesto. Puede significar mantener una docena de conversaciones para desbloquear un proyecto del que depende tu equipo, o darte cuenta de que tu nuevo ingeniero está perdido y comprobar cómo está. Para reiterar: tu trabajo es, en última instancia, lo que tu organización o empresa necesite que sea. En el próximo capítulo, hablaré de cómo entender cuáles son esas necesidades.
Para recapitular
Las funciones del personal de ingeniería son ambiguas por definición. Depende de ti descubrir y decidir cuál es tu papel y qué significa para ti.
Probablemente no seas directivo, pero tienes un papel de liderazgo.
También estás en un puesto que requiere criterio técnico y una sólida experiencia técnica.
Ten claro cuál es tu ámbito: tu área de responsabilidad e influencia.
Tu tiempo es finito. Sé deliberado a la hora de elegir un enfoque principal que sea importante y que no desperdicie tus habilidades.
Alinéate con tu cadena directiva. Habla de lo que crees que es tu trabajo, mira lo que cree tu jefe que es, entiende lo que se valora y lo que es realmente útil, y fija las expectativas explícitamente. No todas las empresas necesitan todas las formas de ingenieros de plantilla.
Tu trabajo tendrá a veces una forma extraña, y eso está bien.
1 También recomiendo progression.fyi, que tiene una amplia colección de escaleras publicadas por varias empresas tecnológicas.
2 Una empresa de la que oí hablar utilizaba los niveles "senior", "staff" y "principal", en ese orden de antigüedad, pero fue adquirida por otra empresa que utilizaba "senior", "principal" y "staff". Un caos. La empresa compradora cambió todo "personal" por "principal" y todo "principal" por "personal", y nadie quedó contento. Tanto el personal como los directores vieron el cambio como una degradación. ¡Los títulos importan!
3 Me gusta la definición de ingeniero superior de mi amigo Tiarnán de Burca: el nivel en el que alguien puede dejar de progresar y continuar con su nivel actual de productividad, capacidad y rendimiento durante el resto de su carrera y aun así "lamentar el desgaste" si se marcha.
4 ¿En qué estaban pensando? ¿Era esto realmente lo que pretendían hacer? Por supuesto, los equipos futuros nos preguntarán lo mismo.
5 El ensayo de Hillel Wayne "No somos especiales" señala que muchas soluciones de ingeniería que solían implicar un cuidadoso ajuste del equipo físico se hacen ahora con un "software kludge". Sinceramente, siempre me sorprende que hasta ahora hayamos tenido tan pocos accidentes mortales importantes debidos al software. No me gustaría depender de que sigamos teniendo suerte.
6 Por eso no soy partidario de hacer entrevistas de codificación a ingenieros experimentados. Si has llegado a este nivel, o sabes codificar bien o has aprendido a resolver problemas técnicos utilizando tus otros músculos. Los resultados son lo que importa.
7 Recomiendo el artículo de Lara Hogan sobre la construcción de un "Voltron manager".
8 Si las reuniones intermedias no son habituales en tu empresa, es posible que tengas que dejar claro que no pretendes socavar o "informar" a tu jefe; lo que quieres es comprender las prioridades del grupo en general y establecer las conexiones que puedan ayudarte a tener un mayor impacto. En el mejor de los casos, tu jefe comprenderá el valor de las reuniones intermedias y te ayudará a organizarlas.
9 Una misión secundaria es una parte de un videojuego que no tiene nada que ver con la misión principal, pero que puedes hacer opcionalmente para conseguir monedas o puntos de experiencia o simplemente por diversión. Imagínate un montón de: "Bueno, estaba a punto de abrirme paso luchando hasta la fortaleza fuertemente custodiada para derrotar al demonio que ha estado aterrorizando esta tierra, pero claro, antes puedo ir a buscar a tu gato".
10 Charity Majors's "The Engineer/Manager Pendulum" es un excelente artículo sobre este tema.
11 Oirás citar la Ley de Brooks en : "Añadir mano de obra a un proyecto de software tardío hace que sea más tardío". Aunque el propio Brooks la calificó de "simplificación escandalosa", hay algo de verdad en ella. Véase The Mythical Man-Month, de Fred Brooks (Addison-Wesley).
Get El camino del ingeniero de plantilla now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
