- La vida diaria y la trayectoria profesional de un ingeniero están muy determinadas por cuál presupuesto paga su salario: ventas/marketing, investigación y desarrollo, o mantenimiento
- La ingeniería financiada con presupuesto de ventas/marketing está más cerca del dinero y es fácil de medir, pero puede derivar en stack ranking y una cultura de competencia interna
- El presupuesto de investigación y desarrollo es el que más ingenieros contrata dentro de la organización de producto, y prioriza el valor a largo plazo y la creación de activos por encima de experimentos de corto plazo de un trimestre o más
- El presupuesto de mantenimiento suele tratarse como un objetivo de optimización de costos; aquí pueden entrar sysadmins, operación de sistemas heredados, parte de la ingeniería de plataformas y el trabajo en herramientas internas
- Saber a qué presupuesto pertenece tu trabajo te ayuda a incorporar en tus decisiones de carrera los cambios frecuentes del trabajo de crecimiento, la inversión a largo plazo de I+D y la baja prioridad del mantenimiento
Tres presupuestos dividen el trabajo de ingeniería
- Los salarios en ingeniería de software suelen salir de uno de tres presupuestos
- ventas/marketing
- investigación y desarrollo
- mantenimiento
- La naturaleza del presupuesto influye en la forma de trabajo diaria del ingeniero y en la dirección de su carrera
- Esta distinción puede ser útil al pensar en la visión de carrera o en cómo posicionarte
Presupuesto de ventas/marketing: resultados inmediatos y medibles
- La ingeniería dentro de organizaciones de crecimiento suele ser fácil de cuantificar en sus resultados
- suele estar relativamente claro qué trabajo hace subir qué métricas
- En esta categoría entran roles como growth engineer, sales engineer y devrel
- hacen que el producto existente se venda mejor
- ayudan a que la gente conozca las funciones
- ayudan a que los compradores adopten la herramienta dentro de su flujo de trabajo
- Lo que la empresa espera es impacto inmediato
- La ventaja es que resulta fácil entender el retorno sobre la inversión y que el trabajo se conecta de forma directa con los ingresos
- Como es fácil medirlo, también es fácil comparar a las personas entre sí
- puede aparecer el stack ranking entre empleados
- la cultura de competencia interna puede volverse más fuerte que la cultura de resolver problemas en conjunto
- El ritmo de trabajo suele estar centrado en el corto plazo
- el siguiente experimento
- el siguiente cliente
- la siguiente tendencia de marketing
- La empresa evalúa el valor según el múltiplo que genera el dinero puesto en este presupuesto, y en esa búsqueda de optimización puede aparecer un efecto de puerta giratoria
Presupuesto de investigación y desarrollo: activos que se acumulan con el tiempo
- Investigación y desarrollo, o I+D, es el área que más ingenieros contrata
- normalmente está bajo la organización de producto
- en empresas más grandes puede haber organizaciones reales de investigación o científicas
- En esta categoría se incluyen roles como product engineer, researcher y architect
- construyen lo que la empresa vende
- o exploran aquello que la empresa podría vender si funciona bien
- Lo que la empresa espera es crecimiento a lo largo del tiempo
- El entorno es relativamente más calmado
- se busca equilibrio entre funciones para retener usuarios existentes y funciones para atraer nuevos usuarios
- puede inclinarse hacia crecimiento al crear funciones que mejoren la activación, es decir, que conviertan el registro en uso real
- también puede inclinarse hacia investigación al explorar nuevas líneas de producto
- En empresas con un departamento de investigación propiamente dicho, hay personas que trabajan en ideas que no se convertirán en producto durante años
- I+D es, en la práctica, una categoría que agrupa dos presupuestos distintos
- desarrollo e investigación no son lo mismo
- pero comparten el enfoque en resultados de largo plazo
- El período más corto que les importa suele ser el trimestre
- El trabajo del ingeniero se diseña para convertirse en un activo que aporte valor durante los próximos años
- los experimentos más breves son escalones dentro de ese proceso
- Medir resultados es difícil, pero la empresa ve este trabajo como una inversión
- bajo la idea de que, cuanto mejor sea el producto, mejores serán también las ventas y la retención
Presupuesto de mantenimiento: un costo que se quiere reducir
- El mantenimiento, por lo general, ha quedado absorbido dentro del trabajo de desarrollo
- Lo que este presupuesto busca es optimización de costos
- Sysadmins, personas que mantienen sistemas heredados funcionando y, a veces, platform engineers entran en esta categoría
- La empresa ve este trabajo como un costo puro e intenta minimizarlo
- En muchas empresas, los roles de mantenimiento están dispersos dentro del desarrollo de producto
- es trabajo que no recibe una valoración importante
- pero cuando alguien se siente lo bastante afectado, al final se termina resolviendo
- A veces la empresa presenta como si fuera un beneficio especial el dar tiempo a los ingenieros para atender NFR, es decir, requisitos no funcionales
- por ejemplo, dar 2 días por sprint para resolver cosas molestas
- La construcción de herramientas internas también puede entrar en esta categoría
- como paneles administrativos que permiten operar la empresa
- pero que no siempre reciben la prioridad suficiente
Lo que la ubicación presupuestaria señala para la carrera
- El tipo de presupuesto al que pertenece un trabajo determina la experiencia diaria del ingeniero
- El trabajo de crecimiento es medible y cambia con frecuencia
- El trabajo de investigación es más calmado, pero sus resultados son difusos
- El trabajo de desarrollo se valora y se acumula con el tiempo
- El trabajo de mantenimiento se trata como algo que puede recortarse en cualquier momento
1 comentarios
Opiniones de Hacker News
No solo importa de qué partida presupuestaria sale tu salario; entender cómo la organización valora el desarrollo de software también tiene un gran impacto en tu carrera.
Si la empresa es una consultora que vende horas de desarrollo, se valoran la capacidad de manejar relaciones con clientes y la de crear software aceptable rápidamente; si es una empresa de producto que vende software, se valora la capacidad de construirlo y operarlo.
Si es otro negocio que incluye algo de software o que se vuelve posible gracias al software, se valora la capacidad de entregar dentro del presupuesto, pero es difícil ser el protagonista del escenario.
Curiosamente, esta distinción encaja bien con las tres categorías que menciona el autor: consultoría corresponde a ventas/marketing, producto a investigación y desarrollo, y el resto a mantenimiento.
Cuando fui ingeniero sénior en una startup de software, tenía trato de estrella, stock options y la cultura de oficina que uno esperaría; cuando fui consultor sénior en una consultora de IT, tenía que ser más bien un vendedor que hacía buenos PowerPoint.
Había que maximizar las horas facturables, y no convenía terminar los proyectos rápido ni con la menor cantidad de código posible.
Probablemente puedan adivinar más o menos dónde estoy ahora.
Esto no es algo que puedas comprar como un producto de caja; normalmente es una mezcla muy personalizada de varios sistemas unidos a la fuerza, y muchas veces no fueron diseñados originalmente para funcionar juntos.
Cada empresa también lo hace de forma distinta.
Disfruto este trabajo y soy bueno pensando en el sistema completo que cruza varios departamentos.
Para abrirse paso entre los problemas también hace falta conocer la política interna, y justo ahí es donde surge mi valor.
Como programador también soy decente, pero no alcanzo el nivel de especialización de alguien que hizo de la programación su carrera.
En los otros dos casos te conviertes en un costo que hay que minimizar o eliminar.
Solo cuando construyes el producto central de la empresa te vuelves un activo que genera ingresos.
Yo cometí ese error: me llamaron a una reunión, me preguntaron “¿cómo va eso?” y enseguida me dijeron “no me cuentes los detalles”.
Trabajar en el tipo 3 significa crear soluciones aburridas y olvidables, y puedes terminar construyendo soluciones que, aunque técnicamente tengan sentido, sean un suicidio político.
Por ejemplo, si trabajas en un fabricante de hardware, no solo no eres el protagonista: hasta es difícil que te respeten.
El personal de software se considera un costo, y uno que preferirían no pagar si fuera posible.
Aunque entregues a tiempo y por debajo del presupuesto, no te vuelves visible; más bien desapareces del radar.
Me cuesta entender cuando en la cultura tecnológica moderna se dice que el mantenimiento siempre está al final de la lista, que le recortan el presupuesto y que nunca recibe un presupuesto adecuado.
Durante 20 años y en varias empresas escuché eso una y otra vez, pero rara vez estuve de acuerdo.
La empresa sí quiere nuevas funciones para llevar al mercado, pero al mismo tiempo también quiere que el servicio funcione correctamente.
Incluso durante despidos o congelamientos de contratación, he visto que las organizaciones de tipo SRE resisten mejor que las de investigación y desarrollo.
Dicho eso, en una empresa la cultura cambió hacia seguir creando cosas nuevas y no recompensar el mantenimiento de lo existente, y eso llevó a migraciones constantes de herramientas internas, deprecaciones continuas y migraciones a medio terminar.
Cuando quienes habían creado un producto ascendían y se iban a trabajar en el siguiente elemento de su portafolio, incluso aquello que había sido nuevo y brillante pronto quedaba abandonado, y otro equipo creaba un reemplazo.
En seis años, una herramienta interna fue reemplazada cuatro veces por nuevas herramientas internas, y los usuarios quedaron repartidos entre las cuatro.
Se podría decir que fue simplemente una falla de ejecución, pero una cultura que dice que el negocio no valora el mantenimiento es muy dañina y termina siendo autodestructiva.
Supongamos que cada vez que un desarrollador agrega una función nueva, usa 1.000 dólares de espacio en disco y genera 10.000 dólares de ingresos nuevos.
El administrador de sistemas compra un gran servidor de archivos, y digamos que cada servidor nuevo cuesta 500.000 dólares.
En una organización burocrática, el administrador de sistemas le cobra internamente a los desarrolladores el costo del espacio en disco, y cuando hace falta un nuevo servidor de archivos, el dinero ya está disponible.
En una organización bien gestionada y menos burocrática, la dirección entiende que una factura de 500.000 dólares habilita un proyecto que devolverá 5 millones de dólares, y la paga con gusto.
En una organización mal gestionada, a la dirección le horroriza que 500.000 dólares sea caro y no esté vinculado a un proyecto específico; entonces el administrador de sistemas le dice a la siguiente persona que necesita 1.000 dólares de espacio en disco que pague 500.000 dólares, y esa persona se niega.
Al final, el administrador de sistemas rechaza la solicitud y termina convenciendo a los desarrolladores de reducir la retención de logs de 7 días a 3, y de pronto la dirección empieza a recibir malos comentarios sobre el administrador de sistemas.
El entorno que describes más bien parece una realidad en la que el negocio no valoraba el mantenimiento.
Decir “el mantenimiento está al final” no suena tanto a una recomendación de que deba ser así, sino a una descripción de lo que ocurre en la práctica.
El autor no analiza por qué sucede ni si otro enfoque sería mejor para el negocio, pero si de verdad se valora que las cosas funcionen bien y tengan alta calidad, naturalmente uno esperaría otro resultado.
Aun así, si muy pocas empresas actúan de esa manera, es probable que haya una razón relacionada con la alineación de incentivos.
Porque no se le puede vender mantenimiento al cliente; lo que se puede vender son funciones.
Desde el punto de vista de los desarrolladores, el mantenimiento también es un trabajo que se quiere evitar.
Es difícil poner el mantenimiento como un punto brillante en el currículum, y todos quieren ver logros, proyectos lanzados y tecnologías modernas.
Mantener un servicio operando al nivel que exige el cliente es una prioridad alta para todos.
Ninguna empresa quiere recortar SRE hasta el punto de que los clientes se vayan por fallas.
Pero SRE se parece más a las operaciones de una empresa tradicional, es decir, a una función inevitable para ofrecer el servicio, y es distinto del mantenimiento que se pospone todo lo posible.
Desde esta perspectiva, el mantenimiento incluye cosas como reducir deuda técnica, mejorar herramientas internas y acortar el tiempo de iteración de experimentos, y creo que ese tipo de trabajo suele ser subvalorado en relación con su impacto en el producto.
El texto trata de lo segundo, y dice que ir a la categoría 3 es suicidio profesional.
Si no eres una persona de tipo “ascender o salir”, también podrías considerar pasar tiempo en la 3.
Claro que, como el software envejece en el momento en que se usa, quienes creen estar en la 2 quizá en realidad pasen la mayor parte del tiempo en la 3 y solo una parte muy pequeña en la 2.
Aun así, como los presupuestos se asignan una vez al año, o como mucho unas pocas veces, si en ese momento estás en un área clasificada como 2, sigues estando en una mejor posición.
“Ventas/marketing” e “investigación y desarrollo” son categorías que se ven en el reporte anual de una empresa, pero mantenimiento no aparece de esa forma.
Conviene leer los estados financieros de la empresa.
Verás rubros como “costo de ventas” o COGS, “gastos generales y administrativos”, y costos únicos como fusiones y adquisiciones; cada rubro tiene dinámicas distintas y también funciona de manera diferente según la empresa.
También es importante entender la estructura de negocio de la industria en la que estás.
Incluso en este hilo hay muchos casos en los que se juzga que una empresa “no valora” la ingeniería de software, pero es ingenuo comparar una empresa de redes sociales con un margen bruto del 70% con una automotriz o aeronáutica de 15–20%.
Es natural que una industria pueda contratar más ingenieros, pagarles más y ofrecerles más swag y beneficios.
Incluso dentro de la misma empresa, algunas líneas de producto y funciones reciben inversión de largo plazo, y algunas líneas tienen márgenes más altos que otras.
Según el presupuesto, el dinero disponible para productos de software puede variar enormemente.
Los ingenieros deberían mirar las finanzas de la empresa al pensar en su trabajo.
Una empresa no es una organización benéfica ni una iglesia, sino un negocio que tiene que equilibrar flujo de caja, ingresos, estrategia de largo plazo y costos de desarrollo de producto.
Este artículo también es bueno, pero el de patio11 lo explica bien dividiéndolo en centros de costo y centros de beneficio.
Explica de forma convincente por qué conviene estar asociado a un centro de beneficio, y si no lo has leído, también tiene mucho otro contenido bueno.
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
La regla número 2 es asumir, dentro de ese centro de beneficio, un rol que esté conectado de forma confiable con la rentabilidad sostenida.
No necesariamente tengo que generar dinero directamente, pero debe quedar claro que, si dejo de trabajar, el dinero se ve afectado de manera directa.
Es un poco otro tema, pero hace unos años leí el Serverless Handbook de Swizec y me resultó muy útil, y durante mucho tiempo disfruté su newsletter por email, reflexiva y perspicaz.
Él está firmemente en el campo de “aprender haciendo / aprender en público”, y es muy bueno compartiendo el proceso de aprendizaje.
Recomiendo mucho seguirlo o suscribirse.
Históricamente, la ingeniería de software formaba parte de la función de TI, y TI surgió de la contabilidad
Antes de que lo hicieran las máquinas, “computadora” era literalmente el trabajo de una persona
Incluso hoy, en muchos negocios, la contabilidad sigue siendo el principal motor del software y la fuente del presupuesto
En realidad hay cuatro categorías de presupuesto
La 1 es investigación y desarrollo, que normalmente recibe un tratamiento fiscal especial y créditos fiscales
La 2 es ventas/marketing, que incluye ingenieros de preventa y, a veces, trabajo de implementación
La 3 es mantenimiento: desarrolladores que corrigen bugs y trabajan en código que no es de I+D, por lo general sin tratamiento fiscal especial ni créditos
La 4 es operaciones en servicios de hosting, PaaS y SaaS, que normalmente incluye en cierta medida salarios de ingenieros de software
Entender las implicaciones fiscales según de qué presupuesto sale el dinero y qué trabajo se hace es muy importante, y se vuelve mucho más complejo a medida que crece la escala
Creo que el modelo de centro de ganancias vs. centro de costos es mejor
Idealmente, todos los departamentos son responsables tanto de los ingresos como de los costos
Si no se puede medir, es un problema de los KPI
Los KPI pueden estar mal alineados por estar centrados en costos, pero eso no convierte al departamento en sí en un centro de costos
Pero me gusta que se haya agregado la distinción de investigación y desarrollo
Creo que incluso los equipos centrados en mantenimiento deberían hacer I+D para reducir los costos de mantenimiento, igual que un buen equipo de ventas hace I+D para aumentar la ganancia por ventas
Aportan perspectivas distintas y pueden complementarse
En ninguna empresa donde trabajé los salarios de growth engineering salían del presupuesto de marketing
Tampoco existía un “presupuesto de mantenimiento” separado; todo era simplemente I+D/ingeniería
Las expectativas pueden variar mucho según el equipo o el rol, pero eso no es una cuestión de presupuesto, sino de cómo la empresa hace seguimiento de sus objetivos
O estás generando dinero ahora, o estás creando valor a largo plazo, o te estás hundiendo lentamente en un producto existente; es una de esas tres opciones