Experiencia enterprise

• Tras trabajar 1 año en una gran empresa, percibió una diferencia marcada frente a sus entornos previos de startup y SME
• A medida que se vuelven más complejos la identificación de responsables y los procesos internos, cosas que no eran problema en organizaciones pequeñas se convierten en problemas imposibles de resolver
• La desigualdad en el desperdicio de recursos y los criterios de contratación provoca problemas en la eficiencia y la motivación de la organización
• Conceptos clave dentro de la organización, como la urgencia del trabajo y la gestión de seguridad, se deforman en prácticas formales y procedimentales distintas de su significado real
• Incluso en medio de diversos problemas, encontró experiencias positivas como el desarrollo de capacidades y el crecimiento profesional

---

Un año de retrospectiva sobre la experiencia enterprise

Diferencias entre una gran empresa y una startup

• Pasó el primer año en $ENTERPRISE experimentando las diferencias frente a startups y SME (pequeñas y medianas empresas).
• Más tarde entendió que la falta de experiencia previa en desarrollo de software interno no era una crítica, sino más bien una señal positiva.
• Organiza sus observaciones para presentar la realidad del entorno laboral en una gran empresa.

Lo que no era problema en una empresa pequeña se vuelve un gran problema en una gran empresa

• Al resolver errores relacionados con herramientas, identificar al responsable o encargado toma mucho tiempo.
• La falta de intercambio de información dentro de la organización y los cambios de responsables generan ineficiencia y desperdicio de costos.
• Una solución temporal es el override de configuración local, pero en el fondo se trata de una limitación estructural de la organización.

La irracionalidad en la asignación de recursos

• A diferencia de la experiencia de trabajar en empresas pequeñas sin presupuesto suficiente, en una gran empresa es frecuente el desperdicio excesivo de recursos.
• El fracaso de proyectos de corto plazo y el uso innecesario de la nube terminan en desperdicio financiero.
• La gestión de presupuestos y recursos alejada de las necesidades reales termina debilitando la motivación laboral.

Estructura inconsistente de colegas y contratación

• En las startups, la contratación basada en capacidad mantiene un estándar relativamente consistente.
• En las grandes empresas, la contratación y las reestructuraciones sin relación con la capacidad son algo habitual.
• Se dan casos en los que ciertos cargos no guardan relación con la capacidad para el trabajo, o en los que la organización se mantiene sin importar la calidad de los reportes.

Cómo se interpreta la urgencia del trabajo

• En las startups, la urgencia clara era el criterio, pero en las grandes empresas hace falta interpretar los múltiples niveles de significado del trabajo.
• Además de situaciones realmente urgentes (por ejemplo, una caída del servicio), aparece con frecuencia una urgencia formal.
• En medio de estos procedimientos, se requiere la capacidad de identificar la verdadera prioridad del trabajo.

Gestión de seguridad convertida en formalidad

• Los procesos de seguridad cumplen un papel importante en la organización, pero en la práctica se enfocan en reportes formales más que en el riesgo real.
• El trabajo de seguridad despojado de sentido se vuelve cotidiano para cumplir objetivos numéricos o métricas.
• También existe ineficiencia en la comunicación entre ingenieros y responsables de seguridad.
• Se subraya el peligro de una cultura en la que todos solo valoran los números.

La falta de sentido de los rangos

• Son comunes los cargos duplicados, como "Head of Architecture", y los roles no están claramente definidos.

Una cultura organizacional que considera la incertidumbre una debilidad

• En medio de grandes reorganizaciones y reestructuraciones frecuentes, para los líderes decir "no lo sé" se vuelve casi un tabú.
• A pesar de la complejidad del dominio, en el liderazgo solo se priorizan la inmediatez y la confianza.
• Como resultado, se fija una estructura en la que los errores del pasado se repiten.

Equipos de ingeniería aislados en silos

• Cada equipo de ingeniería (o "imperio") tiene sus propios estándares y su propia cultura.
• Las barreras entre departamentos crecen y se vuelve difícil estandarizar o difundir mejores prácticas.
• La autonomía de cada área actúa como un factor que limita la colaboración entre equipos.

Experiencias positivas

• A través de la participación en la comunidad de ingenieros, amplió su perspectiva sobre el desarrollo de software.
• También hay nuevas fuentes de satisfacción, como el crecimiento profesional, las oportunidades de mentoría y la experiencia con uso a gran escala.
• Se promueven activamente la especialización, la colaboración con colegas diversos y la formación y el desarrollo de capacidades.
• La estabilidad, como el pago regular del salario y la seguridad laboral, también funciona como una ventaja.

Conclusión

• A pesar de la mirada crítica, el valor positivo de las grandes empresas es claro.
• Tiene intención de volver a revisar esta perspectiva cambiada después de que pase mucho tiempo.

[GN⁺]

Opinión de Hacker News

• Siempre hay que recordar la Ley de Remy sobre el software empresarial (enlace relacionado: https://thedailywtf.com/articles/graceful-depredations). Si un software se describe como "enterprise", por lo general no es muy bueno. Dejando la broma de lado, me parecieron interesantes los puntos positivos mencionados al final del texto. Algunos los entendí, pero hubo otros que en la práctica parecen crear todavía más problemas. Por ejemplo, eso de que "hay oportunidades reales de desarrollo profesional": si desarrollo profesional simplemente significa ganar más dinero, entonces mejor decir "puedes ganar más dinero" en vez de darle tantas vueltas. Y si no, me pregunto qué significa exactamente desarrollo profesional aparte de quedar todavía más enterrado en la ineficiencia y los problemas organizacionales que se mencionaron. Y también está eso de que "hacer software que usan millones de personas es satisfactorio"; si ese software es malo o perjudica a los usuarios, dudo que siga siendo satisfactorio

  • Sobre la pregunta de si el desarrollo profesional es solo ganar más dinero: si uno reflexiona mucho tiempo sobre la vida, termina enfrentándose a la realidad de que cumplimos un papel pequeño dentro de un sistema mucho más grande. Pensar en eso lleva a preguntas más profundas, como "¿puedo ser justo en una sociedad injusta?" o "¿cómo puedo tener un impacto positivo en mi comunidad si mi papel es pequeño?". Cada persona responde distinto a esas preguntas. Algunas buscan activamente oportunidades para generar cambio; otras sienten impotencia dentro del sistema y terminan dándole la espalda. En mi caso, creo en lo que hacemos, y el desarrollo profesional dentro de la empresa no se trata solo de dinero, sino de tener más responsabilidad y mayor capacidad para impulsar cambios. En una organización ineficiente, mis opciones son irme, quedarme donde estoy, o meterme más a fondo en la organización para generar cambios positivos. Y sobre la pregunta de si sigue siendo satisfactorio cuando el software es malo o dañino: habrá gente que diga que sí, pero al menos yo no soy así, y creo que lo que hago tiene una función social positiva. La idea es que "hacer software positivo para la sociedad que usan millones de personas es satisfactorio"

  • El desarrollo profesional en una gran empresa significa más que dinero. Por ejemplo, a menudo surgen oportunidades para liderar proyectos de mayor escala o desarrollar internamente productos que antes habría hecho una startup completa. También es relativamente más fácil conseguir experiencia participando en varios proyectos durante años o liderando equipos de mayor tamaño dentro de una gran empresa. ¿Y si el software es malo o perjudicial? Las startups y las empresas pequeñas no son automáticamente mejores; depende de cada caso

  • Si sueñas con puestos como científico de datos investigador o developer evangelist, necesitas una organización que pueda respaldar ese tipo de trabajo. Roles como arquitecto de microservicios no encajan en organizaciones pequeñas, pero en grandes empresas de más de 3000 personas son bienvenidos. Igual que la ruta hacia engineering manager solo tiene sentido cuando hay suficiente personal, también existen oportunidades de desarrollo profesional que surgen por la escala. Hay software malo o dañino, sí, pero tampoco es necesario que lo que hacemos sea software enterprise; de hecho, ojalá no lo sea

  • No creo que el software enterprise sea inherentemente malo. Claro que se puede hacer buen software enterprise, y lograrlo mientras se cumplen requisitos complejos ya es en sí una gran capacidad. Pero rara vez se evalúa en serio cuánto le importa a la organización la experiencia del usuario. Incluso yo, después de más de 7 años en $ENTERPRISE, solo me he encontrado directamente con usuarios una sola vez

  • Sobre si es satisfactorio aun cuando el software es malo o dañino: muchos ingenieros pueden sentirse satisfechos solo por estar trabajando a gran escala, o pueden sentirse tan impotentes que lo consideran algo ajeno a ellos. Al final, para tener de verdad esa escala, casi tienes que pertenecer a una megaempresa, y eso te arrastra inevitablemente hacia estructuras capitalistas como los dark patterns algorítmicos repetidos una y otra vez, la maximización de las ganancias para accionistas, etc.

• Hay algo que faltó mencionar: cuando entra un nuevo liderazgo, tienden a sacar a la gente que ya estaba y reemplazarla con los suyos. Y además, cada año cambian el nombre del equipo, aunque el trabajo real no cambie; solo le agregan palabras como "Innovation", "Discovery" o "Leadership" al nombre del equipo una y otra vez

  • Si van a cambiar tanto el nombre del equipo, mejor dejarle uno fijo como "Pikachu" y ya. Si todos asumieran que el nombre no importa, dejarían de cambiarlo. Cada vez que le cambian el nombre, se pierde muchísimo tiempo y esfuerzo innecesario actualizando documentación y avisándole a todo el mundo

  • En nuestra organización tenemos una librería interna de código de infraestructura hecha con Terraform CDK. Crea automáticamente recursos de monitoreo en Datadog y Pagerduty. Un día eliminé el argumento obligatorio team, porque en la práctica cambiaba casi cada 7 meses

  • Mi rival, cada vez que entra a una nueva empresa, poco a poco se lleva a todo su antiguo help desk y equipo de desarrollo. La razón es la lealtad. Aunque los resultados sean malos, no se quejan ni escalan problemas hacia arriba. Si escuchas a ex empleados que trabajaron en su empresa, siempre cuentan exactamente lo mismo

    1. Diagnostica el problema (dice que el problema es que no hay un CRM nuevo de un partner de Microsoft)
    2. Gasta dinero con la excusa de resolverlo (gracias a ese partner de CRM y a Microsoft, hace 3 viajes al año a Las Vegas)
    3. Falla la implementación del CRM (afirma que el problema es que el alcance no era lo bastante grande)
    4. Vuelve a redefinir el alcance del proyecto (con más beneficios para él)
    5. Cuando está por volver a fracasar, se cambia a otra empresa y deja atrás solo problemas

  • Cuando el nombre de un proyecto incluye palabras como "Excellence", por lo general no me inspira ninguna confianza

• La mayor parte del texto también aplica a instituciones públicas. Salvo por el hecho de que no se trabaja los fines de semana, que sí puede haber oportunidades de desarrollo de carrera (técnica), y que se fomenta el desarrollo de capacidades o la capacitación, en lo demás es bastante parecido

  • La mención inicial a la diversión y a los beneficios financieros tampoco parece aplicar demasiado a las instituciones públicas

• Fue un texto muy divertido e interesante. Llevo unos 3 años trabajando en enterprise. Estoy creciendo técnicamente, pero siento que en realidad estoy aprendiendo más sobre personas, comunicación y burocracia. También me identifiqué con los comentarios sobre el presupuesto y el mouse. Pero gracias a la estabilidad financiera de $ENTERPRISE, simplemente me compré yo mismo el mouse. Tal vez alguien podría quejarse por usar un mouse no aprobado, pero... simplemente lo ignoro, o le resto importancia a esa falsa urgencia de la aprobación del mouse

• Yo no podría soportar una organización así. Aunque me pagaran el triple, en unos meses estaría completamente destruido

  • La compensación es en realidad inversamente proporcional a la cantidad de trabajo que de verdad hace falta

  • Habría que tomar una dosis fuertísima de medicación psiquiátrica (Zoloft) para aguantar

  • A veces pienso en priorizar el dinero, entrar a $ENTERPRISE con un salario alto, ahorrar lo suficiente y luego tomarme un largo sabático. Pero el proceso de entrevistas suena tan pesado que se me van las ganas solo de pensarlo. Ahora estoy en $MIDSIZENOLONGERSTARTUP, y aquí también hay toda clase de rarezas que me agotan a su manera

• Yo también trabajo en un entorno parecido, y sentí que este texto era dolorosamente preciso. Yo pensaba que mi trabajo consistía en resolver problemas y desplegar software, pero en la realidad las "verdaderas prioridades (revealed preferences, enlace relacionado: https://en.wikipedia.org/wiki/Revealed_preference)" de la organización no son esas en absoluto. Igual que el autor contó su paso de una empresa pequeña a una gran corporación, me pregunto si alguien ha tenido la experiencia inversa, de pasar de una gran empresa a una pequeña. También me gustaría escuchar cómo conviene presentar la experiencia enterprise en entrevistas con equipos pequeños

  • En mi experiencia, es como historia de dos ciudades. Yo también me cansé de perder tiempo sin sentido en $ENTERPRISE, y ahora preferiría renunciar al 20% del salario con tal de estar en un lugar pequeño y bien llevado donde pueda lograr algo real. Pero incluso cuando trato de explicar lo que aprendí en los últimos 3 años sin sonar negativo, los fundadores de startups ven mi trayectoria con cierta incomodidad. Las habilidades de supervivencia necesarias en la selva y en el zoológico son demasiado distintas, así que la reacción es algo como: ¿no habrás pasado demasiado tiempo en el zoológico? Por otro lado, las grandes empresas también quieren contratar gente que entienda sus procesos internos y su jerarquía, así que para alguien que viene de startups tampoco es fácil entrevistarse en esos lugares

  • He pasado de una empresa grande a una pequeña, y mientras más crece una empresa, más grandes se vuelven los problemas de personas y política interna frente a los problemas técnicos. En las grandes empresas muchas veces retienen a su gente clave con compensaciones tipo golden handcuffs (enlace relacionado: https://en.wikipedia.org/wiki/Golden_handcuffs), y por eso la gente aguanta más tonterías organizacionales hasta que llega el momento de renunciar a esa compensación. Si presentas tu historia como "dejé la gran empresa porque quería generar un cambio real", por lo general los equipos pequeños lo entienden bien

• Las grandes empresas solo se preocupan por entregar de forma consistente los resultados que ellas consideran correctos. La definición de objetivos también responde a razones muy distintas: cumplir cifras, procesos regulatorios, decisiones de ejecutivos, etc. Es un terreno completamente diferente a la racionalidad humana como solemos imaginarla

• Sobre el texto original que decía "también hay otros imperios", alguien agregó el chiste de que además del Reino Unido (QA manual) y Egipto (pirámides de software), también están Mongolia (un día te lanzan una avalancha de requerimientos y desaparecen), España (por intentar hacer todas las reglas perfectamente, terminan generando todavía más fricción), Japón (te regañan los ejecutivos y te embarcas en aventuras que dañan tu carrera) y China (te pierdes en un laberinto de reuniones y la comunicación es extremadamente hermética)

  • De verdad disfruté mucho este texto, sobre todo la analogía con la guerra contra Mongolia. Incluso históricamente, pelear contra los mongoles tampoco era nada fácil

• Buenas observaciones, y el texto transmite muy bien la importancia de la política de oficina y del papel de la alta dirección

• Llevo 18 meses en $ENTERPRISE. Me duele de lo mucho que me identifico con esto