¿Por qué las empresas aún contratan gerentes de productos, DevOps, TPM, atención al cliente y UX que ni siquiera pueden hacer una codificación básica (como secuencias de comandos, HTML, etc.)?

Porque los ingenieros deben centrarse en la “ingeniería” y no en otras cosas.

Si tiene un ingeniero que gestiona productos o gestiona proyectos u otras cosas que no requieren sus habilidades técnicas, entonces ese ingeniero puede terminar sin hacer demasiada ingeniería al final.

Si bien es cierto que los ingenieros pueden pasar fácilmente a cualquier otro rol, mientras que aquellos en otros roles no pueden pasar fácilmente a la ingeniería, esto no significa que los ingenieros serán los mejores en todo.

Un gerente de producto sin experiencia técnica sería completamente inútil como desarrollador o ingeniero, mientras que un ingeniero podría administrar el producto. Sin embargo, el gerente de producto experimentado estaría haciendo un mejor trabajo que el ingeniero al principio. El ingeniero a tiempo puede ganar experiencia en la gestión de productos y convertirse en un mejor gerente de productos, pero ya no será ingeniero.

Piensa en neurólogos y neurocirujanos. El neurólogo no puede realizar cirugías, mientras que el neurocirujano puede hacer consultas sobre trastornos neurológicos. Sin embargo, los neurólogos serían más adecuados para el tratamiento de trastornos que no requieren cirugía.

Con respecto al pago, un producto que no está muy bien diseñado pero que tiene todas las características que la mayoría de los clientes desean es mucho mejor que un producto que está bien diseñado pero que es inútil para la mayoría de los clientes. Debido a esto, los gerentes de productos y otros trabajadores que reúnen requisitos y proponen nuevas características para el producto también son importantes.

Todos los roles que mencionas requieren diferentes habilidades que un codificador. Tome un gerente de producto: su tarea principal es comprender las necesidades del cliente, la dirección corporativa y enviar esa información a los equipos técnicos, en los que reside un codificador. No se requiere codificación.

Eso no quiere decir que no sea útil para un gerente de producto comprender la codificación, así como también es útil para ellos comprender las finanzas, el marketing, los desafíos de ventas y la atención al cliente.

En el mundo occidental, para bien y para mal, tendemos a la especialización en roles; y tiende a encontrar que diferentes personas prefieren diferentes roles, se adaptan mejor a ellos y se vuelven muy buenos en ellos. Es difícil para un programador competir con un gerente de producto experimentado.

Debido a que la codificación básica solo es necesaria para una pequeña parte de lo que se necesita para administrar una empresa, incluso una empresa moderna con amplias capacidades de TI. Otra razón es que muchas personas “programarán” computadoras en idiomas de niveles mucho más altos. Por ejemplo, considere un contador usando una herramienta de hoja de cálculo o algún software de contabilidad. De hecho, están programando, pero está en un nivel mucho más alto que la simple codificación.

Un hecho muy incomprendido es que la codificación es una habilidad básica de entrada de bajo nivel para la mayoría de las organizaciones y, si eso es todo lo que aprende, no es probable que progrese mucho en su carrera. Esta es una diferencia entre lo que aprende en un campo de codificación y lo que aprende al obtener un título en ciencias de la computación o ingeniería de software.

El hecho de que un ingeniero pueda hacer estos roles no significa que sean ellos los que deberían hacerlo.

Trabajo en una pequeña startup y los desarrolladores han cubierto la mayoría de estos roles, al menos en algún momento, pero el rol principal de los desarrolladores es crear el producto de su empresa. Tomarse su tiempo para trabajar en estas otras cosas les quita su papel principal. Por ejemplo, todos hemos tenido que prestar un poco de atención al cliente de vez en cuando, pero ahora estamos contratando a una persona de soporte a tiempo completo para que los desarrolladores usen menos tiempo y atención en tareas secundarias.

Además, es mucho mejor conseguir a alguien con pasión y especialidad para estos otros roles si puede. Pasamos un tiempo sin una persona dedicada de DevOps, pero todos nuestros trabajos son más fáciles y menos estresantes ahora que está a bordo.

También me alegro de no ser los únicos que hacemos UX porque esa es una habilidad en la que alguien más tiene mucha más experiencia. Tenemos varios desarrolladores que podrían convertir una maqueta en una aplicación real. No creo que tengamos a nadie que pueda idear un diseño tan atractivo y útil como él, y este es el tipo de cosas que vende.

Sin embargo, reconoceré que es realmente agradable si sus gerentes son o fueron ingenieros. Hace una gran diferencia cuando puedes explicarle a tu jefe que la característica que le suena realmente simple es realmente complicada, o que a la larga es mejor pasar unos días refactorizando algún código aunque no agregue Cualquier nuevo valor comercial.

Porque no contratamos gerentes de producto para ser ingenieros o para escribir código.

Reafirmando un poco la pregunta, ¿por qué las empresas contratan equipos de ventas (que podrían ganar el doble de lo que gana un ingeniero), a pesar de que no pueden codificar? Resulta que vender productos es muy diferente de fabricarlos, y la mayoría de los ingenieros apestaría (es decir, fracasaría) si se los asigna a la organización de ventas y se les exige convencer / influir / encantar / entender / persuadir de manera convincente a los prospectos para que compren el producto en cuestión. (Especialmente porque no es perfecto y no es ideal para todos los compradores posibles).

Los gerentes de producto en realidad hacen una serie de cosas críticas que los ingenieros (en su mayoría) no hacen, y a menudo no son buenos, que incluyen:

• escuchando con mucha atención a los clientes / prospectos que dicen que quieren algo, pero no creen en todos los detalles, explicaciones o razones. Resulta que la mayoría de los clientes no saben cómo solucionar problemas / productos, y sus “requisitos” generalmente son incorrectos o incorrectos. Los gerentes de producto intentan convertir montones de solicitudes de clientes individuales en descripciones coherentes de problemas que ellos, junto con el equipo de ingeniería, pueden resolver bien. (Los ingenieros tienden a dar a los clientes lo que se solicita, en lugar de lo que se necesita).
• Los gerentes de producto “corren los números” en ideas de productos para que tengamos una buena idea que generará dinero. Esto incluye dimensionamiento del mercado (estimaciones aproximadas), estimación de precios, análisis competitivo. La mayoría de las ideas de productos propuestas no sobreviven a este escrutinio, ya que la mayoría no generará suficientes ingresos. (Los ingenieros tienden a construir lo que se solicita y pierden sus trabajos más tarde cuando la empresa no puede ganar lo suficiente para pagar los salarios).
• Los gerentes de productos reúnen a todos los diversos grupos funcionales de la empresa (ventas, marketing, ingeniería, soporte, operaciones, capacitación, finanzas …) para respaldar nuevos productos tal como se presentaron. Para estar listo con precios e historias de beneficios y herramientas para identificar si una perspectiva es una buena opción para ese producto. (Los ingenieros tienden a querer vender todo a todos, en función de sus propias percepciones de que el producto es de alguna manera increíble).
• Los gerentes de producto sudan una hoja de ruta a largo plazo para que podamos priorizar primero las cosas más importantes (y más urgentes). Esto nos ayuda a construir de manera más estable y bien, interrumpiendo al equipo de ingeniería con menos frecuencia con sorpresas o interrupciones. Los gerentes de producto piensan que hay 2 o 5 lanzamientos por delante, sabiendo que los productos son bestias de larga vida que necesitan años de cuidado y alimentación, si se les permite sobrevivir a la versión beta beta v0.9.

Tenga en cuenta que la “codificación” no es realmente un requisito para este trabajo. “Tener una profunda empatía y aprecio por aquellos que codifican bien” es un requisito. Si está pasando el día codificando, vea más arriba: su producto probablemente sea DOA incluso antes de que termine de construir y probar.

Los ingenieros creen que hacen el trabajo más difícil e importante del mundo. Los gerentes de producto saben que los ingenieros creen esto, y hacen todo lo posible para no arruinar esa percepción.

(Por cierto, yo era ingeniero, pero ahora no lo soy).

Debido a que estos diferentes roles requieren diferentes conjuntos de habilidades. Ser capaz de “hacer algo de codificación básica” no garantiza en absoluto que la persona en cuestión pueda tener éxito como gerente de producto, en un rol de atención al cliente, etc., etc. Y estoy hablando como alguien que ha trabajado como ingeniero de diseño de hardware y en varios roles de “codificación”, además de ser un gerente de programa / proyecto. No todos los “ingenieros competentes” que brillan como codificadores o diseñadores podrán desempeñar estos otros roles. Y eligió un ejemplo particularmente bueno, porque más de una vez tuve que regresar y solucionar los problemas resultantes de un “documento de requisitos” creado por un ingeniero.

Pregunta interesante: mi respuesta está sesgada hacia la función PM. Para otras funciones, diría “Dios salve a la compañía”.

Desde una perspectiva de reclutamiento de PM: observa diferentes aspectos de una persona, que sus habilidades de HTML / Scripting. La razón por la cual un rol de PM es unir – negocios, tecnología y consumo – no codificación 🙂. En el propio lenguaje de los PM: es una característica “buena para tener”, no una “necesidad”. Si eres bastante bueno escribiendo algunas secuencias de comandos sofisticadas, puedes ganar fácilmente el respeto de los ingenieros, escribiendo tu propio SQL / Python / R para un poco de extracción / análisis de datos. En caso de que no tenga estas habilidades de “codificación”, solo necesita aprender a ser amable / ser un buen ser humano con los ingenieros / otras funciones para ganarse su respeto. Empatice con sus problemas y planifique las iteraciones de tal manera que también apoyen sus necesidades. Antes de que el producto llegue al cliente, satisfará las necesidades de las pocas funciones de su empresa (especialmente en productos de comercio electrónico / SaaS), de ahí que también sea importante resolver sus puntos débiles.

La función general de PM es una amalgama de buenas habilidades con las personas, la capacidad de aprender / captar nuevos conceptos rápidamente, perspicacia comercial, empatía hacia los clientes / miembros de su propio equipo; no gira en torno a la codificación. Es por eso que las empresas reclutan PMs sin codificar el conocimiento.

Contrato gerentes de productos para que los ingenieros puedan trabajar en problemas técnicos difíciles. Contrato atención al cliente para que los ingenieros no tengan que pasar el día hablando por teléfono con los clientes. Contrato expertos en UX para que los ingenieros no tengan que usar su intuición cuando se trata de IA o flujo de contenido. Contrato desarrolladores para que los ingenieros puedan trabajar en un entorno estable en lugar de pasar tiempo reparando el sistema operativo y tratando de descubrir por qué alguna biblioteca no se está cargando. Desde el punto de vista del ingeniero, estos son todos los servicios prestados para que pueda hacer lo que realmente quiere hacer.

Por supuesto, esta perspectiva de primer ingeniero no es como la ve el resto de la compañía, pero podría ser útil para un ingeniero que piensa que el mundo gira en torno a su contribución. No es asi.

Considera lo contrario. ¿Por qué contratar a un ingeniero cuando un producto, servicio al cliente, UX, devops, etc. pueden escribir HTML? Quiero decir, no es difícil, ¿por qué molestarse en pagarle a un ingeniero? La respuesta, por supuesto, es que desea un ingeniero cuyas habilidades técnicas vayan más allá de lo que esas otras personas pueden hacer. Del mismo modo, un ingeniero puede escribir un documento de requisitos para construir, pero el trabajo del gerente de producto va mucho más allá de eso. Descubrí que muchos ingenieros tienen poca paciencia para el trabajo de las personas, el trabajo del proceso comercial y la investigación de mercado que conlleva la formación de una buena visión del producto.

Como gerente de proyectos profesional, me han hecho una pregunta similar miles de veces. Al principio, lo tomé en serio e hice todo lo posible para explicar mi punto de vista. Ya no.

Es una pregunta muy divertida, lo siento,

Del mismo modo, puede preguntar: ¿Por qué nombramos jueces que nunca habían pasado un mes en prisión? Que saben ellos

El hecho obvio es: diferentes roles requieren diferentes entrenamientos y diferentes habilidades. Siempre ayuda conocer el “tema”, pero no más que eso. En mi caso, había gestionado proyectos en industrias muy diferentes y siempre invertía algo de tiempo hablando con los gurús técnicos para conocer mejor su trabajo.

Mi sincero consejo para los técnicos: puede ser un cambio de juego para usted si invierte algo de tiempo en hablar con sus gerentes de producto, DevOps, TPM, etc., para comprender la naturaleza de su trabajo.

Y si invierte suficiente tiempo, puede darse cuenta de que, por ejemplo, un PM puede pagarse más que un ingeniero, por una razón. Dos razones en realidad:

1. Unos cuantos PM solían ser ingenieros e invirtieron en capacitación adicional para convertirse en PM.

2. Existe una Ley inmutable de gestión de proyectos:

“Cuanto mayor es la complejidad técnica del proyecto, menos necesita un técnico para administrarlo. Porque el primer ministro tendrá a los técnicos, mientras que lo contrario nunca es cierto “.

Contratan a estas personas porque ya tienen un complemento completo de ingenieros egoístas, pobremente socializados y con poca inteligencia emocional que piensan que son mejores que los demás y se distraen de la capacidad de la compañía para completar su misión.