Este gran artículo de John Olspau se titula "Ser un ingeniero principal" . La primera vez que lo leí hace unos cuatro años, cuando acabo de cambiar a mi trabajo actual, y realmente influyó en las ideas sobre esta área de mi carrera.

Después de releerlo ahora, una cosa parece realmente interesante allí, que la empatía y ayudar al equipo es una parte importante del trabajo de los adultos mayores. ¡Lo cual por supuesto es cierto!

Pero ahora veo que la mayoría o todos los ingenieros líderes que conozco ayudan de manera significativa a otros empleados además de su trabajo de programación personal. Ahora me parece que mis colegas y yo nos enfrentamos no tanto con el problema “¿Qué? ¿Necesita hablar con la gente? INCREÍBLE ”, ¿qué tanto con otro problema:“ ¿Cómo equilibrar todo este trabajo de liderazgo con su aporte / programación individual? ¿Cuánto y qué tipo de trabajo debo hacer? Por lo tanto, en lugar de hablar sobre los signos de la persona mayor del artículo de Olspau (con el que estoy completamente de acuerdo), quiero hablar sobre el trabajo que estamos haciendo.

¿De qué trata este artículo?

"Lo que hace un ingeniero principal" es un tema enorme, pero aquí hay un pequeño artículo, por lo que debe tener en cuenta:

• Solo hay una descripción posible de lo que puede hacer un ingeniero líder. Hay muchos enfoques para trabajar, y esto no debería ser un dogma.
• Principalmente trabajé solo en una empresa, por lo que mi experiencia y opiniones son obviamente bastante limitadas.
• Obviamente, hay muchos niveles de "senior". Se trata del nivel P3 / P4 en la jerarquía de Mozilla (ingeniero sénior / ingeniero de personal), quizás un poco más cerca del nivel de "personal".

Cuales son las responsabilidades

Estas son cosas que veo más como el trabajo de un ingeniero principal y menos como el trabajo de un gerente (aunque los gerentes definitivamente hacen algo de lo anterior, especialmente creando nuevos proyectos y vinculando proyectos con prioridades comerciales).

Casi todo este trabajo es esencialmente técnico : ayudar a alguien a hacer frente a un proyecto complejo es claramente una interacción humana, ¡pero los problemas que trabajaremos juntos generalmente serán técnicos! ("Tal vez, si simplificamos el diseño, podemos hacer frente más rápido").

• Escribir código (obviamente).
• Haga una revisión del código (obviamente).
• Escribir y revisar la documentación de diseño . Al igual que con otras revisiones, es probable que una apariencia de terceros ayude a mejorar el diseño.
• Ayuda a tus colegas si están atrapados . ¡A veces las personas se atascan en un proyecto, y es importante ayudarlas! Pienso en esto no tanto en "lanzarse en paracaídas desde el cielo y entregar su conocimiento mágico a las personas", sino en "trabajar juntos para comprender el problema y ver si dos cerebros pueden hacer frente más rápido que uno" :). También significa trabajar juntos, no resolver un problema en lugar de otra persona.
• Mantenga a sus colegas en lo alto . Para diferentes personas, "nivel" tiene diferentes significados (para mi equipo esto significa confiabilidad / seguridad / conveniencia del producto). Si alguien toma una decisión que no me gusta, significa que sé algo que él no sabe o que sabe algo que yo no sé. Por lo tanto, no es necesario que diga: "Oye, lo hiciste mal, debes hacer X en su lugar", pero es mejor simplemente darles información adicional que no tenían, y a menudo esto resuelve el problema. Y a menudo resulta que me faltaba algo, y de hecho su solución fue bastante razonable. En el pasado, a veces veía a los principales ingenieros tratar de mantener los estándares de calidad repitiendo sus opiniones más alto porque piensan que su opinión es correcta. Personalmente, no encontré útil este enfoque.
• Crea nuevos proyectos . ¡El equipo de desarrollo de software no es un lugar de suma cero! Los mejores ingenieros que conozco no dejan el trabajo más interesante para ellos, crean nuevos proyectos interesantes / importantes y crean espacio para que otros hagan este trabajo. Por ejemplo, alguien de mi equipo comenzó a reescribir nuestro sistema de implementación. El proyecto resultó ser súper exitoso, ¡y ahora todo el equipo está trabajando en nuevas características que se han vuelto más fáciles de implementar!
• Planifica el trabajo de tus proyectos . Se trata de escribir / informar una hoja de ruta para los proyectos en los que está trabajando y asegurarse de que las personas entiendan el plan.
• Informe los riesgos del proyecto por adelantado . Es muy importante reconocer cuando algo no va muy bien, notificar a otros ingenieros / gerentes al respecto y decidir qué hacer.
• ¡Informe de éxito!
• Para realizar proyectos de terceros que beneficien al equipo / empresa . Veo que muchas personas mayores a veces hacen proyectos pequeños pero importantes (por ejemplo, crean herramientas de desarrollo / ayudan a establecer políticas), que en última instancia ayudan a muchas personas a hacer su trabajo mucho mejor.
• Tenga en cuenta cómo los proyectos se relacionan con las prioridades comerciales.
• Decide cuándo detener el proyecto . Resulta que es sorprendentemente difícil de entender cuando necesita parar / no comenzar a trabajar en algo. :)

Puse "escribir código" en primer lugar, porque en realidad esta tarea se desliza fácilmente por la lista de prioridades. :)

No hay ningún elemento "hacer estimaciones / pronósticos" en la lista. Todavía no soy muy bueno aquí, pero creo que algún día vale la pena dedicarle más tiempo.

La lista parece ser grande. Parece que si haces todas estas cosas, absorberán todos tus recursos intelectuales. Creo que, en general, tiene sentido aislar alguna parte y decidir: "En este momento me voy a centrar en X, Y y Z, creo que mi cerebro explotará si trato de hacer B y C".

Lo que no es un deber

Esto es un poco más complicado. No estoy diciendo que no puedas lidiar categóricamente con tales cosas. La mayoría de los ingenieros líderes que conozco pasan mucho tiempo pensando en estos problemas y trabajan un poco en esta dirección.

Pero me parece que es útil trazar un límite determinado, porque algunas personas tienen un alto sentido de responsabilidad por el equipo y la empresa, y están listas para asumir todo, como resultado de lo cual estarán sobrecargados y no podrán hacer una contribución técnica, que en realidad es su negocio principal Por lo tanto, el establecimiento de ciertos límites ayuda a determinar en qué temas tiene sentido pedir ayuda cuando la situación se vuelve turbulenta. Sus límites reales dependen de usted / su equipo. :)

La mayoría de los siguientes son trabajos gerenciales. Descargo de responsabilidad: los gerentes hacen mucho más de lo que se enumera aquí (por ejemplo, "crear nuevos proyectos"), y en algunas empresas, algunas de las anteriores pueden ser en realidad el trabajo de un ingeniero principal (por ejemplo, la gestión de sprint).

• Para asegurarse de que cada empleado sea recompensado de acuerdo con sus méritos por su trabajo.
• Asegúrese de que el trabajo esté distribuido de manera justa.
• Asegúrese de que las personas trabajen bien juntas.
• Garantizar la cohesión del equipo.
• Hable en privado con cada empleado.
• Capacite a los nuevos gerentes, ayúdelos a comprender lo que se espera de ellos (aunque creo que los programadores líderes a menudo realmente llegan a tal actividad).
• Gestionar proyectos de terceros (en mi trabajo, este es el trabajo de cualquier ingeniero que lidere ese proyecto).
• Sé un gerente de producto.
• Dirigir la gestión de sprint sprint / determinar las etapas de trabajo para cada uno / realizar reuniones semanales.

Es útil establecer límites explícitamente

Recientemente me encontré con una situación interesante cuando discutí mis responsabilidades con el gerente, ¡y nos dimos cuenta de que las veíamos de manera muy diferente! Aclaramos la situación y ahora todo está en orden, pero me di cuenta de que es muy importante acordar las expectativas. :)

Cuando comencé como ingeniero, el trabajo era bastante simple: escribí código, intenté encontrar proyectos que tuvieran sentido, y todo fue perfecto. Mi gerente siempre tuvo una idea clara de mi trabajo, nada demasiado complicado. ¡Ahora la situación ha cambiado! Por lo tanto, ahora creo que debo determinar el trabajo que:

• Puedo hacer / ajuste a largo plazo para mí.
• Quiero hacer / que generalmente es agradable y consistente con mis objetivos personales.
• De valor para el equipo / organización.

La redacción exacta diferirá para diferentes personas (no todos tienen los mismos intereses y fortalezas, por ejemplo, ¡no soy demasiado bueno en la revisión de códigos!). Creo que por esta razón es aún más importante discutir este tema y acordar las expectativas.

No te conformes con el trabajo que no puedes / no quieres hacer

¡Creo que es muy importante renunciar al trabajo que no puedo hacer o que no traerá alegría a la larga! Parece tentador asumir mucho trabajo, incluso si realmente no te gusta ("¡Oh, esto es bueno para el equipo!", "¡Bueno, alguien tiene que hacerlo!"). Por supuesto, a veces asumo tareas solo porque deben completarse, pero creo que para la salud del equipo es realmente importante que los empleados hagan lo que generalmente les gusta y lo que pueden hacer a largo plazo.

Por lo tanto, tomaré pequeñas tareas que solo deben hacerse, pero es importante no decir: "Oh, por supuesto, pasaré la mayor parte de mi tiempo en lo que hago mal y lo que no me gusta, no hay problemas" :). Y si "alguien" necesita hacer esto, tal vez solo significa que necesitamos contratar / entrenar a alguien nuevo para llenar el vacío. :)

¡Todavía tengo mucho que aprender!

Aunque siento que estoy empezando a entender qué es un "ingeniero principal" (ya 7 años en mi carrera), pero todavía siento que todavía necesito aprender mucho más sobre esto, y me interesaría saber cómo otras personas definen los límites tu trabajo!