Cuando era CTO en Tuenti (~ 100 ingenieros), teníamos un par de equipos que se ajustaban a esta descripción. Colectivamente, los llamamos “equipos técnicos”, en lugar de “equipos de productos”, porque sus objetivos principales no eran la entrega de código orientado al usuario, sino más bien objetivos de rendimiento / escalabilidad y servicio a otros equipos.
Los equipos de productos están diseñados para ser generales. Mi objetivo, desde una perspectiva de gestión de ingeniería, era que fueran libres de ejecutar funciones de principio a fin con la menor dependencia posible de personas fuera del equipo. Esto significa que están llenos de generalistas o personas con áreas complementarias de experiencia.
Los equipos técnicos (centrales) son lo contrario. Son expertos con tecnologías / áreas de código particulares. Esto no significa que sean necesariamente ingenieros más experimentados, pero a menudo lo son.
- ¿Cómo te conviertes en ingeniero principal en Google?
- Si los cálculos de la computadora son deterministas, ¿por qué el software de la computadora a menudo es determinista y tiene errores?
- ¿Cuál es un mejor trabajo, programación de software o programación de juegos?
- ¿Puedes decir qué tan bueno es un programador dependiendo de su habilidad para hablar?
- ¿Cuál es la mejor manera de comenzar una carrera en tecnología (UX, UI, ingeniero front-end) sin un título en informática?
En general, estos equipos tienen tres objetivos permanentes:
- Cree bits compartidos y básicos de la base de código (bibliotecas, marcos, etc.) que varios productos deben usar, para que los equipos de productos no dupliquen el trabajo o inflen la base de código.
- Enseñe a otros ingenieros sobre el código y las mejores prácticas. Los ingenieros de los equipos de productos suelen ser generalistas. No pueden ser expertos en cada pequeño fragmento de código y no deberían intentarlo. Los equipos principales son las personas que brindan esa experiencia cuando es necesario.
- Revise el código (y las especificaciones) de los equipos de productos. Asegúrese de que los equipos de productos estén utilizando las cosas compartidas, siguiendo las mejores prácticas, etc.
A menudo, tenían KPI alrededor del rendimiento y la eficiencia, como el tiempo promedio de solicitud, pero, si lo piensa, esto solo rastrea qué tan bien lo están haciendo en cada uno de los anteriores. Si están escribiendo buenas bibliotecas centrales y están ayudando a los equipos de productos a escribir código que use esas bibliotecas de manera eficiente, la latencia debería permanecer bajo control.
Ocasionalmente, cuando un proyecto requiere o se beneficiaría de una experiencia de muy alto nivel en un nicho técnico particular, temporalmente contrataríamos a alguien de un equipo central en un equipo de producto para ese proyecto. Esto fue especialmente cierto para un objetivo de producto que requería cambios importantes en un marco central, por ejemplo.
No reclutamos ingenieros específicamente para los equipos técnicos centrales (o cualquier otro equipo). En una empresa pequeña, no creo que sea una buena práctica “prometer” a las personas nuevas un equipo específico para trabajar. También creo que puede corromper el proceso de la entrevista (por ejemplo, “sí, pero no para mi equipo” debería ser “no”; de manera similar, “sí, porque mi equipo necesita desesperadamente personas” debería ser “no”).
Ocasionalmente contratamos personal nuevo para personas jóvenes o incluso pasantes en equipos técnicos centrales. Depende de la personalidad, los intereses y las necesidades. Pero la mayoría de las veces, estos equipos contaban con ingenieros que estaban creciendo en antigüedad pero no querían ir por un camino de gestión.
Para contrastar los dos en resumen:
- En un equipo de producto, ejecuta directamente objetivos comerciales críticos y cosas que millones de usuarios verán la próxima semana. Pero generalmente no puede reflexionar sobre problemas técnicos esotéricos o jugar con proyectos de código abierto de vanguardia.
- En un equipo técnico, usted es un experto que trabaja en problemas técnicos profundos y fascinantes, habla con sus colegas sobre sus soluciones y les ayuda a resolver sus problemas. Pero no trabajas directamente en cosas orientadas al usuario; Es posible que sus amigos y familiares realmente no entiendan lo que usted hace exactamente.