¿Qué hacen realmente los ingenieros Staff?
El papel de un ingeniero Staff-plus depende mucho de las necesidades del equipo y también de los puntos fuertes del ingeniero en particular. Según mi experiencia, las responsabilidades de un ingeniero Staff-plus pueden cambiar con el tiempo, pero normalmente su objetivo principal es trabajar en proyectos/esfuerzos que tengan un valor estratégico para la empresa, a la vez que impulsan el diseño técnico y elevan el nivel de su equipo. – Diana Pojar
Cualquiera que haya sido acorralado por sus familiares en una fiesta y le hayan pedido que explique lo que hacen realmente los ingenieros de software sabe que explicar el trabajo puede ser un reto. Con el tiempo puede haber creado una respuesta convincente para sus familiares, pero la mente de muchas personas se queda en blanco cuando su compañero de trabajo se inclina y pregunta: «¿Qué hace un ingeniero de Staff?»
La respuesta más fácil es que los ingenieros de Staff siguen haciendo mucho de lo que les hizo triunfar como ingenieros Senior: construir relaciones, escribir software, coordinar proyectos. Sin embargo, es una respuesta engañosa. Siguen haciendo esas mismas tareas, pero mientras que antes eran el núcleo del trabajo, se han convertido en tareas auxiliares y tienen nuevas prioridades. Su programa diario varía un poco según el arquetipo, pero hay una base compartida en todos los arquetipos: establecer y editar la dirección técnica, proporcionar patrocinio y tutoría, inyectar el contexto de la ingeniería en las decisiones de la organización, la exploración, y lo que Tanya Reilly llama ser pegamento.
Establecer la dirección técnica
Me siento más impactante cuando puedo facilitar el establecimiento de una visión técnica para un área y hacer que la gente se mueva hacia esa visión. Creo que todos estamos de acuerdo en que queremos que nuestro código tenga una mejor arquitectura de la que tiene o que se mejore de alguna manera. Sin embargo, me he dado cuenta de que a menudo la gente tiene una vaga sensación de querer algo mejor sin tener una idea clara de qué es lo que quieren. Me gusta ayudar al grupo a decidir sobre un entendimiento compartido de adónde quieren llegar exactamente (en realidad, no pasa nada si nunca llegamos allí) y elaborar un plan de juego general de cómo llegar allí. – Joy Ebertz
Al igual que el Lorax habla en nombre de los árboles en su popular libro infantil, los ingenieros de personal hablan en nombre de la tecnología de sus empresas. La tecnología no puede hablar por sí misma y necesita defensores eficaces en su nombre. La gente que hace avanzar la tecnología con éxito es pragmática, deliberada y se centra más en la tendencia de progreso a largo plazo que en considerar cada decisión individual como una crisis decisiva. Puede ser útil pensar en esto como un Gerente de Producto a tiempo parcial para la tecnología.
Algunos ingenieros de Staff-plus son contratados explícitamente para liderar un área específica como el diseño de la API, y en otros casos se encuentran editando y alineando los enfoques en un área amplia. Una constante en todos los roles es que la realidad de establecer la dirección técnica es mucho más acerca de la comprensión y la solución de las necesidades reales de la organización que te rodea, y mucho menos sobre la priorización de la tecnología y los enfoques que usted personalmente está emocionado de aprender. En funciones anteriores puedes haber tratado de influir en las decisiones hacia las opciones tecnológicas que te motivan, pero en las funciones superiores tienes que rendir cuentas a la empresa y a la organización en primer lugar, y a ti mismo en segundo lugar.
Mentorización y patrocinio
En mi función actual, me siento lleno de energía cuando alguien a quien he patrocinado envía un anuncio de que ha enviado su trabajo, o cuando veo que he ayudado a dar forma o cambiar el modelo de un equipo de ingeniería sobre un tema importante. Son estos equipos, y no yo, los que hacen el duro trabajo diario de construir y apoyar su tecnología. Mido mi impacto basándome en su progreso y, lo que es más importante, en la dirección de ese progreso y en la alineación de su trabajo con los objetivos de la empresa. – Michelle Bu
Hay una visión popular del liderazgo heroico que se centra en individuos extraordinariamente productivos cuyas decisiones cambian el futuro de su empresa. La mayoría de esas narrativas están diseñadas intencionadamente por equipos de relaciones públicas para crear una buena historia. Es mucho más probable que cambies la trayectoria de tu empresa a largo plazo haciendo crecer a los ingenieros que te rodean que a través de heroicidades personales. La mejor manera de hacer crecer a los que te rodean es crear una práctica activa de tutoría y patrocinio.
Muchos escalafones profesionales tienen una casilla obligatoria en torno a la tutoría para poder optar a un ascenso a un puesto de personal, y la tutoría es una parte clave del papel. Compartir tu experiencia y consejos, junto con una relación continua para entender el contexto del receptor, es un trabajo de alto impacto. En los puestos superiores, la tutoría es sólo el listón de la admisión, y los ingenieros de Staff más eficaces combinan una cantidad moderada de tutoría con un patrocinio considerablemente mayor: poner el pulgar directamente en la balanza para ayudar a avanzar y apoyar a los que te rodean. Si aún no lo has leído, Lara Hogan ha escrito el artículo canónico sobre la distinción entre patrocinio y tutoría, ¿Qué aspecto tiene el patrocinio?
Proporcionar la perspectiva de la ingeniería
Tengo un asiento en la mesa en las discusiones de ingeniería de más alto nivel que se producen en un nivel superior a los proyectos y equipos individuales. Tenemos reuniones recurrentes con el personal de ingeniería en las que discutimos problemas que abarcan a los equipos y que son de naturaleza tanto técnica como no técnica. – Dan Na
Las organizaciones eficaces racionalizan la toma de decisiones rutinarias. Un buen ejemplo de ello es el proceso de revisión de contratos para potenciales clientes empresariales. Al principio, se firmarán algunos contratos con los que los equipos de producto e ingeniería no se sientan cómodos. Después de que esto ocurra unas cuantas veces, el proceso incluirá a más partes interesadas en los pasos de revisión y, con el tiempo, las personas adecuadas estarán en los lugares correctos en el momento adecuado.
Hay una segunda categoría de decisiones, las que son sensibles al tiempo y a la importancia, y es más difícil conseguir que las personas adecuadas estén en la sala antes de que esas decisiones se finalicen. Es frecuente que se produzca una reestructuración organizativa sin que se produzcan aportaciones valiosas que habrían cambiado el resultado. Del mismo modo, es habitual que los bucles de entrevistas para puestos poco frecuentes -aquellos en los que se puede contratar a una persona al año, como los ejecutivos o los ingenieros Staff-plus en una empresa en fase inicial- no evalúen al candidato en una dimensión importante. Para algunas empresas, incluso cosas como la planificación de la hoja de ruta entran en esta categoría.
Los ingenieros Staff-plus son las personas que a menudo se ven arrastradas inesperadamente a la sala donde se toman este tipo de decisiones. Esto les da la oportunidad de inyectar el contexto y la perspectiva de la ingeniería en una decisión mientras todavía es posible cambiar el resultado. Estos breves momentos de aportación a las decisiones críticas tienen un gran impacto y le permitirán mantener la perspectiva de los ingenieros. También son un momento en el que es fácil olvidar que tu papel en estos momentos suele ser representar los intereses de toda la ingeniería, no sólo los tuyos.
Exploración
En mi papel actual dentro de la incubadora me paso todo el día creando prototipos, pero en mi anterior papel de líder tecnológico hacía muchas cosas diferentes. – Ritu Vincent
La escalada no puede resolver todos los problemas, pero es tan eficaz que muchas empresas luchan por adoptar otros enfoques. Puede tratarse de una empresa orientada al consumidor que se esfuerza por apoyar los acuerdos empresariales, o de una empresa madura que lucha por competir con la cadencia de lanzamientos de un competidor más pequeño. Incluso puede darse el caso de que su negocio actual sea tan valioso que le resulte difícil dar prioridad a nuevos negocios, aunque la tasa de crecimiento del negocio valioso vaya a la baja.
A largo plazo, las empresas o aprenden a explorar o se desvanecen; no es un reto ignorable. Asignar simplemente un equipo que domine la escalada de colinas para hacer el trabajo de exploración no es nada seguro, por lo que muchas empresas adoptan un enfoque diferente. Encuentran a un par de personas de confianza con amplios conocimientos, asignan algunos recursos y vuelven a comprobar unos meses después lo que han descubierto. Uno de esos ingenieros suele ser un ingeniero de personal.
Tampoco se trata siempre de un problema de negocio, puede ser cualquier tipo de problema ambiguo e importante que los sistemas de la empresa no están preparados para abordar. Puede ser reducir los costes de infraestructura en un orden de magnitud. Puede ser la identificación de una estrategia multirregional que lleve seis meses en lugar de tres años. Podría ser abordar la repentina comprensión de que su base de datos principal sólo tiene tres meses de espacio de disco restante y no se puede actualizar a un tamaño más grande (en mi experiencia, un problema sorprendentemente frecuente en las nuevas empresas de rápido crecimiento).
Este es uno de los trabajos más gratificantes, y más arriesgados, que hacen las empresas, y se necesita una gran cantidad de confianza organizativa para que te confíen este trabajo, incluyendo tener el respeto de la empresa de que si fallas es un reflejo del problema y no de ti.
Ser pegamento
Tanya Reilly escribió un maravilloso post, Ser pegamento, que captura otro elemento central de los ingenieros de personal con éxito: hacer lo necesario para identificar el trabajo correcto y conseguir que se envíe. No es glamuroso, pero las organizaciones de alto impacto a menudo tienen uno o más ingenieros de plantilla trabajando entre bastidores acelerando el trabajo más importante y asegurándose de que se termine.
¿Pero seguirás escribiendo software?
Es descortés terminar cualquier discusión sobre el papel de los ingenieros de plantilla sin opinar sobre la primera pregunta que los ingenieros de plantilla hacen cuando se reúnen en una sala: «¿Sigues encontrando tiempo para escribir software?» La respuesta es, por supuesto, ¡depende!
Ras Kasa Williams dijo: «Sigo contribuyendo al código con regularidad, ciertamente menos que el resto de los ingenieros de mi equipo; pero era importante que mantuviera el trabajo «mano a teclado» para asegurar que mi estrategia técnica (y otras decisiones a nivel macro) estuvieran informadas por las experiencias sobre el terreno del resto de mi equipo.»
Katie Sylor-Miller dijo: «Soy arquitecta de frontend, pero lo que más he escrito últimamente es SQL, porque estoy haciendo muchos análisis de datos. He estado mirando nuestras métricas de rendimiento para averiguar dónde están las áreas de mejora, y cuáles serían los problemas más impactantes a arreglar para mejorar el rendimiento y las métricas de negocio. Escribo pequeños fragmentos de JS o PHP aquí y allá, pero la mayoría de las veces es para ayudar a desbloquear equipos o para realizar pequeños experimentos relacionados con el rendimiento».
Silvia Botros dijo: «Ya no hago codificación para el negocio. Creo que la última vez que tuve que sacar mi terminal fue para refactorizar mis archivos dot. Es una decisión intencionada de mi jefe, el arquitecto jefe. Cada trimestre nos revisa para asegurarse de que no hemos contribuido con ningún código que vaya a producción».
Joy Ebertz dijo: «Cuanto más alto seas, menos se relaciona tu trabajo con el código. Claro, a diferencia de un gestor de personas, sigues teniendo una inclinación muy técnica e incluso a través del director, es probable que hagas al menos algo de código. Sin embargo, cuanto más alto llegas, más tu trabajo se convierte en la tutoría y el crecimiento de las personas que te rodean (y más ampliamente), la construcción de tu equipo a través de la construcción de la marca de tecnología pública de tu empresa, notando las tendencias técnicas más grandes que pueden ser mejoradas o corregidas, ayudando a establecer la visión de la tecnología para tu equipo o la empresa y abogando por la dotación de recursos para los proyectos de la deuda de la tecnología.»
La mayoría escriben algunos, algunos no escriben ninguno, pero ninguno escribe tanto como solían hacerlo al principio de su carrera. Habrá una semana ocasional en la que sólo se escriba, pero no será la norma, y si ocurre con demasiada frecuencia suele ser un signo de que se está trabajando en algo cómodo más que en algo importante.
Lento pero gratificante
Un tema unificador en el trabajo de Staff-plus es que los plazos son simplemente más largos. Al principio de tu carrera es fácil encariñarse con el rápido ciclo de retroalimentación del desarrollo de software -escribir, probar, enviar, repetir- y la mayor parte del trabajo que harás a este nivel sustituye ese ciclo de retroalimentación por uno que lleva semanas, meses y años.
El impacto y el crecimiento personal viven en esos plazos más largos, y aunque todos con los que hablé deseaban tener ocasionalmente más tiempo para codificar, ninguno de ellos lamentó su transición a sus funciones actuales.