¿Son los ingenieros de software los trabajadores de cuello azul, frente a los gerentes de producto de cuello blanco?

La definición típica de un collar azul es una persona dedicada a tareas simples y repetitivas donde la antigüedad / experiencia proviene del hecho de que simplemente ha realizado la tarea repetitiva suficientes veces, en oposición a los collares blancos que toman decisiones.

Los ingenieros de software (como cualquier otro ingeniero, como mecánico o eléctrico), en realidad resuelven problemas 🙂 No se dedican a la repetición de tareas, sino a la resolución de problemas, y como Tim lo dijo amablemente, brindan el ” cómo ” al ” por qué ” del gerente de producto .

Ergo, Producto e Ingeniería están a la par, no son superiores entre sí.

Sin embargo, incluso en la ingeniería de software hay tareas repetitivas que involucran solo cierta habilidad, y no implican una resolución real de problemas. Como cortar psd2html o tareas de codificación de rutina similares. Y de hecho considero que tales “desarrolladores” son collares azules 🙂

Me encanta esta obsesión con el estatus social como se muestra en la pregunta. Realmente revela mucho sobre tus valores y lo que te motiva.

Uno de mis profesores favoritos en Cal me dijo una vez: “Nunca subestimes el poder de ser la persona que escribe el código”. No importa lo que decidan los gerentes de producto. Si usted, como ingeniero, implementa algo que realmente funciona mejor, los usuarios lo aceptarán rápidamente y a nadie le importará que no haya sido idea del gerente del producto.

Finalmente, cuando construyes algo, lo que importa es construir algo que los usuarios / clientes valoren. Todo debería fluir de eso. Ve a ver “La red social” e intenta averiguar si Mark Zuckerberg era el gerente de producto o el ingeniero de software.

Sí, ya que los puestos gerenciales, como los gerentes de producto, se refieren a decisiones y compensaciones en el espacio de resultados y consecuencias de tales elecciones. Los gerentes de producto, como todos los gerentes, son responsables de tomar decisiones óptimas en ese espacio.

La distinción entre los trabajadores de cuello azul y los trabajadores de cuello blanco se trata de una compensación basada en las percepciones de los valores de sus actividades. La parte clave del valor es la asunción de riesgo. Es la toma de riesgos lo que se reconoce como esencial para generar ganancias y riqueza en general, en todas las actividades de economía y finanzas.

Se supone que los trabajos manuales son de muy bajo riesgo, un producto fácilmente reemplazable. Cuanto más alto sube la cadena de gestión, se perciben los resultados más valorados de los riesgos asumidos, ya que cada vez hay más dinero y riqueza en juego.

Al compensar la toma de riesgos, lo que cuenta son las percepciones, ya que no hay una manera clara, ni motivación, de separar otros factores, incluida la posibilidad, de determinar cuántas opciones de gestión son realmente responsables de los buenos resultados.

Las personas involucradas en la gestión entienden intuitivamente esta relación y realizan un arbitraje clave. Tratan de aprovechar los resultados positivos no relacionados con sus decisiones y rechazan la responsabilidad de los resultados negativos alegando que estaban fuera de su control.

Las finanzas son un gran ejemplo de un campo importante que se basa en gran medida en este arbitraje. La política es otra. Pero ese arbitraje no existe solo en las finanzas y la política, está en todas partes.

Las personas que están preocupadas y lamentan los bajos salarios no aceptan el papel clave de las percepciones de los riesgos. Su aversión al riesgo los aleja de cualquier tipo de opciones y decisiones relacionadas con el riesgo sobre sus trabajos y carreras. Asumen que debería ser obvio que hacen el trabajo real y que la sociedad debería aceptarlos y recompensarlos por ello.

Los gerentes no están necesariamente más impulsados ​​por el riesgo, aunque algunos ciertamente lo están. La mayoría de ellos simplemente perciben este arbitraje de percepciones de riesgo e intentan aprovechar la mayor cantidad posible al reclamar créditos implícitamente por todos los buenos resultados, incluidos y especialmente los que están fuera de su control, y rechazar explícitamente los malos resultados por la misma razón.

No hay nada inherentemente bueno ni malo en los niveles de aceptación del riesgo. Es una cuestión de elección personal donde todos tienen que encontrar su propio nivel con el que se sientan cómodos. Sin embargo, si se asigna un alto valor a la compensación y al dinero en la vida, que es su elección, es mejor que estén dispuestos a aceptar y jugar el arbitraje de riesgo, o se arriesgarán (juego de palabras 🙂) mucha insatisfacción y frustración con las recompensas de su trabajo. .

Definitivamente, existe un estado mental similar entre los trabajadores manuales que pretenden “hacer un trabajo real” y los “ingenieros” de software que valoran profundamente escribir código y producir algo que funcione. Se sabe que comparten un desprecio por aquellos que prescriben y permanecen indefensos sin sus secuaces. Recíprocamente, aquellos que dirigen y resuelven problemas no técnicos a menudo tienen poca paciencia para los detalles de implementación.

En el pasado, hubo intentos de utilizar a los programadores como trabajadores gruñones, mientras que las personas más educadas pondrían sus mentes en problemas de orden superior, pero la mayoría parecería haber fracasado. Por un lado, aquellos que son contratados para sudar las cosas pequeñas han tenido que resolver problemas. En segundo lugar, han logrado aprovechar sus habilidades y tecnología para interrumpir gran parte de la industria del software. Aquellos que saben cómo han estado definiendo qué más rápidamente que aquellos cuya responsabilidad es instruir qué construir. El mundo del software ha sido diseñado a través de una serie de experimentos desordenados. Los que fueron contratados para pasar por alto el proceso han estado tratando de ponerse al día, como todos los demás. Ningún profesional respetable de ningún campo de ingeniería real permitiría que ocurriera este tipo de inversión.

Mientras esto sucede, se ha abierto otro tipo de inversión. A medida que las herramientas para construir software y los recursos para aprender cómo hacerlo se han hecho más accesibles que nunca, personas de diferentes orígenes se han ensuciado las manos con el software. Ahora es posible construir un sitio web, una aplicación incluso con muy poca capacitación. Un campamento de entrenamiento de seis meses junto con algo de ingeniería de copiar y pegar puede otorgar un valor práctico más alto en la entrega de habilidades que un título en informática de cuatro años. Estas habilidades pueden tener un alcance limitado, pero suficiente para la mayoría de los usos. Debido a que queremos mantener el desarrollo de software simple, hemos estado trabajando para resolver el problema de convertir un campo colar blanco en uno colar azul …

Finalmente, es genial poder construir cosas, pero las tecnologías y los problemas que requieren atención continúan requiriendo una gran dedicación. Tanto, de hecho, que es fácil perder la perspectiva sobre los problemas más importantes: qué problemas se están resolviendo, cómo van a elegir, adoptar, trabajar con la tecnología, cómo nos aseguramos de resolver los problemas correctos y ayudar los usuarios aprovechan la tecnología, y así sucesivamente … Los que abordan estos problemas pueden estar demasiado ocupados para codificar, así como los codificadores pueden estar demasiado ocupados para mirar el bosque. Más allá de cierto punto, el especialista en software deberá recibir instrucciones y obtener los requisitos directamente para que pueda hacer su trabajo. Alguien más diseñará, y él cumplirá. No importa la cantidad de resolución de problemas que deba hacer, siempre puede ser el técnico que atiende las cosas pequeñas.

Es una cosa cultural, de verdad.

Los gerentes de producto proporcionan el “¿por qué?” detrás de una iniciativa particular. Los ingenieros definen “¿cómo?” (a menudo resulta en una gran colaboración sobre el “¿por qué?” inicial en cuestión).

Ambos roles son igualmente importantes: solo tienen enfoques diferentes (¿focos?)

En Inglaterra, si. El sistema de clases es tal que “hacer” es mucho más bajo en estado que “prescribir”.