El camino para convertirse en VP of Engineering
(honeycomb.io)- La primera VP of Engineering de Honeycomb fue promovida en febrero de 2020 desde el puesto de Director of Engineering, y este camino se pareció más a hacerse cargo de los vacíos que fueron apareciendo conforme la empresa crecía que a una carrera ejecutiva planificada
- En los inicios de Honeycomb, la cofundadora Charity Majors gestionaba a casi todo el mundo, y dos personas con una filosofía similar pero con antecedentes y estilos distintos terminaron repartiéndose las responsabilidades de gestión de R&D
- El ascenso no fue una sola gran transición, sino la acumulación de pequeñas ampliaciones de alcance, y en una startup el camino clave fue ir creando nuevos procesos y responsabilidades
- La preparación para el rol requirió una visión de toda la empresa, una inclinación generalista, la capacidad de moverse entre distintos niveles de abstracción, sentido de responsabilidad, pensamiento sistémico, apoyo al crecimiento del equipo y relaciones amplias
- La imagen de una buena VP of Engineering cambia no según una plantilla estándar, sino según los problemas actuales de la empresa, la composición del liderazgo y de los IC existentes, los retos técnicos y la etapa de crecimiento
Un punto de partida que no fue una carrera ejecutiva planificada
- La primera VP of Engineering de Honeycomb fue promovida en febrero de 2020 desde el puesto de Director of Engineering
- Cuando se unió inicialmente a Honeycomb, su objetivo era trabajar como ingeniera, con el entendimiento de que, si hacía falta, podría volver a un rol de gestión
- Se incorporó cuando era aproximadamente la empleada número 12, y ya sabía que en una startup temprana, mientras más éxito tiene la empresa, más probable es asumir trabajos variados en distintas etapas
- Consideraba que aferrarse demasiado a un cargo específico podía ser más un obstáculo que una ayuda, tanto para la persona como para la empresa
- Eligió Honeycomb porque el equipo parecía inteligente y amable, porque parecía haber mucho que aprender, y porque el producto se veía como algo que había querido en trabajos anteriores pero no había encontrado
- Si el objetivo fuera crecer rápido hacia un rol específico, unirse a una startup después de Series B podría ser más eficiente, pero en este caso se unió a Honeycomb en etapa Series A
Cómo se desplazaron las responsabilidades de gestión
- Al inicio, la cofundadora y entonces CEO Charity Majors gestionaba a casi todo el mundo, desde ejecutivos hasta ingenieros individuales
- Ambas coincidían en gran parte en su filosofía de gestión, pero tenían trayectorias y fortalezas distintas
- Charity Majors tenía experiencia profunda en infraestructura, operaciones, bases de datos e ingeniería backend
- La persona promovida venía de diseño, frontend e ingeniería de producto, y disfrutaba colaborar con product management y diseño UX
- Ambas tenían experiencia en métricas y tecnologías de monitoreo, pero con actitudes diferentes
- A Charity Majors más bien no le gustaba ese tema
- La persona promovida sentía una afinidad muy fuerte por él
- También había una gran diferencia en sus estilos de trabajo
- La persona promovida valoraba las reglas y los procesos, y tendía a planificar y gestionar riesgos tanto en el trabajo cotidiano como en sus hobbies
- Charity Majors tenía un estilo intuitivo e improvisado, brillaba especialmente en situaciones de crisis, odiaba los checklists y detectaba rápido cuándo una regla o proceso dejaba de ser útil
- Conforme Honeycomb fue creciendo, aumentó el trabajo de gestión en R&D, y ambas fueron repartiéndose cada vez más las responsabilidades según las áreas que mejor encajaban con sus antecedentes
El ascenso fue la acumulación de pequeñas ampliaciones de alcance
- El camino hacia VP tuvo muchos pasos pequeños más que un solo hito claro
- Viendo hacia atrás, los cambios intermedios de título servían como señales de avance, pero normalmente no marcaban un cambio drástico en el alcance del trabajo más allá de agregar nuevas reuniones
- En una startup en crecimiento, siguen apareciendo vacíos en procesos y responsabilidades, y problemas que parecen pequeñas fugas pueden convertirse en asuntos que consumen mucho tiempo y atención
- Siempre hay oportunidades para hacerse cargo de problemas nuevos y subir de nivel, pero es otra cosa distinta que la empresa reconozca eso con un nuevo título o rol
- Las dos personas cofundadoras de Honeycomb apoyaban activamente no solo su promoción interna, sino también la de otras personas y el reconocimiento de su influencia
- Si en el futuro buscara otra startup, dijo que buscaría un equipo ejecutivo o fundador con historial de desarrollar internamente a personas de alto desempeño y de reconocer y recompensar rápido a quienes ya generan impacto más allá del alcance formal de su rol
La transición de gestionar IC a gestionar managers
- La transición más interesante de todo el recorrido fue el momento en que pasó de gestionar solo IC a también gestionar managers
- Para quien quiera hacer esa transición, consideraba mejor intentarlo en una empresa donde ya conozca al equipo, la tecnología y los problemas del negocio, en vez de hacerlo en una empresa nueva
- Muchas habilidades previas de gestión directa sí se transfirieron, pero tomó tiempo aprender a “ver” eficazmente a toda la organización a través de una capa adicional de management
- En particular, fue difícil identificar dónde había fricciones dentro de la organización o dónde hacía falta más apoyo
- La experiencia directa con las personas y los problemas de la organización de ingeniería le permitió sostenerse hasta construir, junto con los managers, prácticas y habilidades para evaluar la situación de los equipos
Búsqueda de candidaturas externas para VP y promoción interna
- En un momento en que el rumbo de la empresa estaba algo inestable, también se consideró contratar desde fuera a una VP of Engineering
- Charity Majors lo compartió con franqueza y la involucró en el proceso de buscar y evaluar a la persona adecuada
- Hablaron con varias personas líderes de ingeniería muy destacadas, pero algunas no encajaban con Honeycomb en ese momento y otras no eligieron a Honeycomb como su siguiente paso
- Después surgieron nuevos problemas en la empresa y los problemas anteriores, que parecían imposibles de resolver, se volvieron más manejables
- En ese momento no fue promovida de inmediato, pero sí se detuvo la búsqueda externa
- Las promociones de liderazgo a partir de cierto nivel no deben basarse en la persona, sino en lo que la empresa necesita, y ayudó imaginar en conjunto cómo debía verse una VP of Engineering adecuada para Honeycomb
Rasgos que ayudaron a convertirse en la persona adecuada para el rol
- El pensamiento holístico funcionó como un rasgo importante
- Su enfoque natural estaba en cómo hacer que toda la empresa Honeycomb tuviera más éxito, no solo su equipo
- Trabajaba bien en un entorno donde se recompensa actuar en beneficio de toda la empresa por encima de departamentos, equipos o individuos
- También ayudó una inclinación generalista
- Sentía interés por casi todos los problemas de negocio y dominios dentro de una empresa de software
- Le gustaba poder ver cómo encajan todas las piezas en una startup
- Si hacía falta, no tenía problema en asumir trabajo poco glamoroso y que no llama la atención
- Podía trabajar en varios niveles de abstracción
- Podía captar rápido conceptos de alto nivel incluso sin comprender por completo todas las capas inferiores
- Y cuando era necesario, también disfrutaba entrar en el detalle
- Un fuerte sentido de responsabilidad ayuda en una startup, pero también necesita límites
- Es útil en startups donde trabajo importante puede caer en vacíos entre funciones
- Pero hace falta un esfuerzo constante por cerrar tareas o pasarlas a otras personas para que no se acumulen ni frenen el crecimiento del equipo
- El pensamiento sistémico, orientado tanto a personas como a sistemas técnicos, también estuvo en la lista de factores importantes
- También fue clave disfrutar genuinamente ver crecer a otras personas del equipo
- Le daba energía conectar a personas listas para el siguiente paso con problemas importantes que debían resolver justo en el borde de sus capacidades
- También hacían falta buenas relaciones en distintos rincones de la empresa
- Las personas dentro y fuera de la empresa tenían que sentirse más entusiasmadas con verla asumir el rol que con la expectativa puesta en una candidatura externa
Experiencia laboral que resultó útil
- La experiencia en startups de distintas etapas y tamaños, especialmente startups B2B SaaS, fue útil
- Las startups B2C y B2B enfrentan categorías de problemas relativamente distintas y han desarrollado técnicas diferentes para resolverlos
- Está bien conocer ambos mundos, pero también tiene valor desarrollar especialización en uno de los dos, ya sea B2B o B2C
- La forma de salir al mercado, la estructura organizacional, los problemas de ingeniería y los retos de escalamiento pueden diferir entre B2B y B2C
- También ayudó haber trabajado en todo el stack
- Su experiencia de ingeniería más profunda estaba en tecnologías frontend
- Tuvo experiencias tempranas en varias organizaciones donde se hacía pair programming y se aplicaba una mentalidad DevOps
- Aprendió de ingenieros de backend, infraestructura, plataforma y operaciones, y entendió cómo piensan y qué problemas consideran importantes
- No hace falta ser experta en todas las áreas de ingeniería, pero la empatía hacia varios equipos y una comprensión de alto nivel del dominio ayudan mucho
- La experiencia en herramientas para desarrolladores y monitoreo también encajó con el rol
- Trabajó en tres empresas consecutivas de herramientas para desarrolladores
- Le gustaba genuinamente el producto de Honeycomb, así como varios productos del ámbito de observabilidad, monitoreo y developer tools
- El conocimiento del dominio y la pasión por las herramientas pueden ayudar a colegas y convertirse en una fuente de energía en situaciones desalentadoras
La idoneidad también estuvo determinada por la suerte y la composición del equipo
- La suerte también influyó mucho en que resultara ser la persona adecuada para el rol
- No bastaba con tener habilidades y experiencia complementarias a las de Charity Majors; también fue importante que los senior IC iniciales estuvieran resolviendo bien los retos clave de ingeniería
- Una VP of Engineering con background frontend es relativamente poco común, porque los retos técnicos más urgentes en una startup suelen estar en escalamiento, confiabilidad y arquitectura backend
- Si hubieran continuado incidentes constantes, problemas de escalamiento y grandes problemas arquitectónicos en consultas y storage engines, probablemente habrían elegido a alguien con experiencia más profunda en backend y operaciones
- Gracias a Ben Hartshorne, Ian Wilkes, otros IC sobresalientes y decisiones de diseño sólidas del equipo fundador, había cierto margen técnico, y en ese momento la prioridad máxima del liderazgo era ejecutar la estrategia de producto y mejorar la experiencia de usuario
- En el equipo ejecutivo ya había personas contratadas desde fuera con experiencia en funciones go-to-market
- Christine y Charity, a quienes podía considerarse líderes desarrolladas dentro de la empresa, también tenían experiencia previa como fundadoras o en liderazgo en compañías anteriores, y Charity ya era conocida como una manager sobresaliente antes de fundar Honeycomb
- Si el equipo ejecutivo hubiera estado más inclinado hacia personas nuevas en cargos ejecutivos o promociones internas, quizá no habría habido suficiente margen para desarrollar a otra ejecutiva más
Una VP of Engineering cambia según el contexto de la empresa
- El aprendizaje más importante fue que la imagen de una buena VP of Engineering depende del contexto
- Antes pensaba que se podían enumerar rasgos estándar de una gran VP of Engineering, pero la idea de que casi todas las empresas comparten una plantilla base resultó ser menos cierta
- El trabajo básico que hay que hacer es parecido en la mayoría de las empresas de software, pero el tipo de ejecutiva que debe liderarlo cambia mucho según los problemas actuales de la organización y la composición existente de ejecutivos, managers e IC
- Incluso después de entrar al rol, los requisitos no quedan fijos
- En una empresa en crecimiento, como pasa con otros roles en startups, el rol de VP of Engineering también puede cambiar de forma con el tiempo
1 comentarios
Opiniones de Hacker News
Este fragmento me pareció interesante: “Charity tiene un estilo más intuitivo e improvisado, brilla más en las crisis y odia las listas de verificación” suena casi como una admisión hecha sin pensarlo demasiado.
Dicho de otro modo, significa que la fundadora no tiene las credenciales ni las características que sus subordinados consideran necesarias para puestos de liderazgo.
Si fundas una empresa, automáticamente te conviertes en CEO, CTO, etc., y lo mismo pasa con los fundadores de empresas que hoy son grandes corporaciones.
Un fundador no necesita credenciales específicas para justificar su cargo: se convierte en líder por sí mismo y luego elige a sus amigos como primeros empleados.
La contratación se formaliza mucho después y, por más que queramos creer que la jerarquía es meritocrática, su origen fue claramente caótico.
El pensamiento jerárquico y obediente siempre me pareció extraño, y nunca pensé que mis antiguos jefes fueran “mejores” que yo.
Escalar la escalera corporativa es, en esencia, algo más cercano a la política, y esos textos interminables sobre “qué es un ingeniero senior” también parecen surgir de un pensamiento corporativizado que busca justificar la jerarquía.
Pero con el tiempo tienes que justificar ese puesto haciendo que la empresa tenga éxito sin llevarla a la quiebra.
Eso a menudo es una forma de medir la capacidad mucho más honesta y dura que cualquier evaluación.
Una gran empresa como Google no va a quebrar por culpa de un VP incompetente y flojo, así que necesita sistemas de evaluación.
Vale la pena compararlo con https://gwern.net/backstop.
Yo soy totalmente de ejecución, pero aprendí temprano que las características ideales en un cofundador son lo opuesto a las mías, y lo que se ve aquí es esa diferencia.
La persona descrita es una líder atípica clásica: improvisa, salta de un lado a otro y puede ser dispersa, pero al mismo tiempo es una innovadora brillante y una motivadora que moviliza a la gente.
Una startup exitosa necesita tanto personas atípicas como personas ejecutoras.
Recomiendo Rocket Fuel: https://www.amazon.com/Rocket-Fuel-Essential-Combination-Bus...
Me parece un reconocimiento honesto y amistoso de que existen dos estilos distintos, y reconocer esas diferencias es saludable, no una apelación implícita a la jerarquía.
Más bien, al usar expresiones como “subordinados” y “jefes” y equiparar la fundación de una empresa con la creación de una jerarquía, todo el comentario termina reforzando la jerarquía, pese a decir que la pone en duda.
En la industria del conocimiento, los gerentes no son líderes, sino personal de apoyo.
Los mejores gerentes y ejecutivos de software saben que su función es ayudar a que los verdaderos líderes y expertos —es decir, los contribuidores individuales que hacen el trabajo— puedan trabajar con facilidad.
Una de las funciones de apoyo de la dirección es establecer esas expectativas mediante su propio comportamiento.
Cuando una startup se vende a una gran empresa, se vuelve bastante divertido descubrir que ninguno de los integrantes de la startup habría sido contratado según los criterios de RR. HH. de esa empresa.
Y luego, de repente, esos miembros del equipo de la startup terminan ascendiendo antes que los empleados de la gran empresa, con buena formación académica y aprobados por RR. HH.
Mucha gente está adoctrinada en la cadena de mando corporativa al estilo estadounidense, y demasiadas veces se asume que, si alguien tiene cierto cargo, realmente posee las credenciales correspondientes a ese cargo.
La inflación de títulos está en todas partes y, por lo que se percibe, muchas veces los títulos se usan como mecanismo para justificar aumentos de sueldo y reconocer antigüedad, no como reconocimiento de capacidad.
No pretendía limitarlo solo a Estados Unidos.
En mi experiencia, los criterios que buscan casos de promoción interna son muy raros.
En la mayoría de las startups, cuando se necesita un nuevo nivel en la jerarquía o se abre una vacante porque alguien se va, la opción por defecto es contratar afuera.
La lógica parece ser que, si todos están haciendo bien el trabajo necesario, es mejor no tocar nada, pero, sinceramente, desmotiva muchísimo.
Desanima mucho más que quedar relegado porque ascendieron a un compañero, porque si existe una cultura de ascenso y crecimiento, puedes creer que la próxima vez habrá una oportunidad justa.
Pero si siempre contratan de afuera, mi carrera en esta empresa queda exactamente en el mismo puesto en el que entré.
La lógica parece más bien retener lo más barato posible a personas inteligentes capaces de rendir por encima de su cargo.
Cambiar de trabajo tiene costos reales para el empleado, y son mayores cuanto peor está la economía.
Aun así, hay quienes se van, quienes se desconectan en silencio y quienes simplemente aguantan.
En mi experiencia, muchas veces se niegan a adaptarse y terminan yéndose o siendo despedidos.
Que puedas gestionar un equipo de 10 personas no significa que puedas gestionar una organización de 100, y mucho menos una de 1000.
No digo que este caso sea necesariamente así, pero en algunos casos es una razón legítima para evitar el principio de Peter.
Porque ascienden personas que toleraron esos defectos o directamente no los vieron.
Unas pocas contrataciones externas con la experiencia necesaria para detectar esos defectos probablemente la pasen bastante mal.
La mayoría de la alta dirección llegó ahí mediante promociones internas, y a veces incluso hay personas que pasaron de contribuidor individual a VP; el impacto se nota.
Si entrara alguien que ya haya vivido esa escala en varias organizaciones, claramente ayudaría a la organización.
Era difícil entender qué hizo en la práctica y qué hace ahora en el rol de VP.
Hay muchas frases bonitas, pero no queda claro en qué ocupa la mayor parte de su día actualmente.
Decir que viene de “diseño, frontend e ingeniería de producto” tampoco aporta mucha información.
Yo también soy exactamente ese tipo de persona que hace desde bocetos hasta layouts en Figma, frontend y capa intermedia con SvelteKit, y construcción de APIs con FastAPI, pero no sé qué hizo bien para llegar a VP, de qué se alejó en el trabajo de campo, qué hace ahora y qué es lo que más extraña.
El texto es larguísimo, pero no entiendo bien qué quiere decir.
Para ver el rol que se espera hoy en empresas más pequeñas que FAANG y el camino por el que un ingeniero sube por la vía de gestión, vale la pena consultar “The Manager's Path”.
Pensaba que, a medida que uno se acerca al liderazgo ejecutivo, el trabajo se vuelve mucho más estratégico y rara vez implica ejecución directa, pero el texto enumera mucha experiencia táctica y cualidades que, según dice, lo convierten en un buen VP.
Como persona pobre en la periferia de la tecnología, he visto muchos casos de gente obligada por la empresa a escribir algo, y siempre era así.
Durante la contratación universitaria, hacen que la gente de la empresa escriba uno o dos textos de este tipo para que aparezcan publicaciones recientes en los resultados de búsqueda.
Cumple a la vez dos objetivos: una dosis adecuada de adulación y entusiasmar a posibles candidatos.
https://www.honeycomb.io/blog/becoming-vp-of-engineering-pt2
Este texto es básicamente un ejemplo de sesgo de supervivencia y de su racionalización.
Lo que falta es una perspectiva estadística entre la movilidad interna hacia un puesto de VP y la contratación externa.
Creo que llegar a VP desde dentro, ya sea en una startup o en una gran empresa, es extremadamente difícil.
En una startup, la empresa tiene que tener éxito; en una gran empresa, hay que aguantar años y construir buenas relaciones políticas.
El camino más fácil es no pensar en empezar desde abajo, sino apuntar desde temprano en la vida a roles altos y seguir así.
Si no puedes llegar a la cima en tu empresa actual, puedes crear la tuya.
Si empiezas desde abajo, sigues quedándote ahí, porque esa habilidad no tiene valor en los roles de máximo liderazgo.
Lo intentaron, pero al final no resultó así, y tampoco había un juicio de valor.
Parece que no encontraron un gran candidato y al final ascendieron a quien escribió el texto.
En mi startup anterior también buscamos un VP y al final hicimos una promoción interna; estadísticamente, eso claramente ocurre de vez en cuando.
Creo que quien escribió el texto no estaría de acuerdo con la última frase de que “si empiezas desde abajo, sigues quedándote ahí”.
Dice que la infraestructura de la empresa se mantuvo estable incluso durante la expansión porque “la gente de abajo” hizo bien su trabajo, y que por eso pudo tener más espacio para pensar en estrategia.
No parece una cuestión de arriba o abajo, sino más bien de qué tipo de problemas se te da bien resolver.
Si te gustan la planificación, la gestión y la estrategia, conviene apuntar a puestos donde puedas usar esas capacidades, ya sea arriba, en el medio o abajo.
Por ejemplo, si quieres sobresalir, no te acomodes en puestos de JavaScript; empújate hacia espacios competitivos y, si quieres convertirte en un programador verdaderamente bueno, tienes que escribir código maldito en OCaml.
Como CTO de una startup respaldada por venture capital, mi impresión es que la gente en puestos altos suele ser inteligente, y también incluiría la astucia en la misma categoría.
Pero hay mucha gente igual de inteligente que no está en puestos altos, porque no tuvo la oportunidad.
Si empiezas tu propio negocio, tus oportunidades mejoran, y aunque nadie funda una empresa para conseguir un puesto de VP en otra compañía, termina siendo una buena ruta alternativa.
O necesitas networking, conocer a las personas correctas, y normalmente eso va de la mano con la ruta anterior de emprender.
También está la opción de trabajar en una empresa reconocida como Google y luego irte a un lugar más pequeño para convertirte en pez grande.
O tienes que estar en el radar de tu jefe y del jefe de tu jefe, para ser la próxima persona nombrada cuando tu superior directo renuncie.
Algo que aprendí es que, cuando ves que una empresa asciende y contrata ejecutivos por motivos distintos a la capacidad, es momento de empezar a buscar un nuevo trabajo.
No lo sabía durante las entrevistas, pero en mi empresa anterior los puestos de VP hacia arriba estaban casi monopolizados por personas conectadas con el CEO, sin importar sus credenciales.
Había algunas personas que habían ascendido por mérito o que habían llegado de forma natural durante una adquisición, pero con el tiempo fueron reemplazadas o degradadas de manera constante para abrirles puestos a amigos de los ejecutivos de nivel C, e incluso a familiares.
Un ejecutivo de nivel C con quien era agradable trabajar fue degradado a VP, y un viejo amigo del CEO ocupó ese puesto de nivel C.
El ejecutivo degradado tenía años de experiencia en las mejores empresas del sector y hasta se había mudado con su familia al otro lado del país para este cargo, pero su reemplazo no tenía ninguna experiencia en esa industria.
A ese VP le pidieron que se quedara para que el viejo amigo del CEO pudiera aprender el trabajo y asumirlo, y le “permitieron” conservar sus opciones sobre acciones.
Me abrió los ojos sobre cómo funcionan el nepotismo y la lealtad en algunas empresas.
Esta cita me llamó especialmente la atención
Es la parte que dice que los VP de ingeniería provenientes de frontend son relativamente raros porque los problemas técnicos más urgentes de una startup suelen estar en escalabilidad, confiabilidad y arquitectura backend
En el pasado trabajé en empresas donde todos los líderes venían de backend/infraestructura y el frontend estaba subvalorado, y vi casos en los que la calidad del código de esos desarrolladores backend era bastante terrible
Me pregunto si existe una correlación inversa entre representación en liderazgo y talento de ingeniería
Soy alguien que pasó de ingeniero frontend a tech lead, y creo que los desarrolladores eligen su foco según su personalidad individual y los valores que consideran importantes
La gente que elige frontend y los desarrolladores backend suelen tener personalidades distintas
¿Qué es código terrible?
¿Formato inconsistente o poco agradable, nombres de variables poco descriptivos, código que no está dividido o estructurado de forma clara?
Siento que los desarrolladores frontend tienden a juzgar el código por valores superficiales
En especial, en organizaciones centradas en ingeniería, se gana reconocimiento resolviendo problemas
Muchos equipos funcionan lo suficientemente bien sin una persona clave de frontend, pero a menudo se tambalean si no tienen un ingeniero fuerte de infraestructura o backend, o incluso varios
Esa es la realidad
El desarrollo frontend con frecuencia se codifica como femenino y se considera menos importante
Ej.: https://thoughtbot.com/blog/tailwind-and-the-femininity-of-c...
En la industria tecnológica también hay una tendencia a asociar el liderazgo con rasgos codificados como masculinos
Por eso no sorprende en absoluto que se perciba que liderazgo y experiencia en frontend de algún modo no encajan
La misma dinámica de género también aplica al código
Para mí, parte del buen código es código que es bueno para otras personas y bueno para colaborar
Pero si quieres actuar como un tech bro macho, alfa nerd, puedes hacer cowboy coding en solitario y exhibir tu genialidad
En ese caso, el objetivo no es colaborar de cerca con el equipo y construir juntos, sino convertirse en un contribuidor individual sorprendente que destaque claramente ante la dirección
VP de ingeniería no es un rol que pueda estandarizarse y compararse entre empresas
En mi empresa actual, los directores suelen estar a cargo de organizaciones de hasta 500 personas, y los VP normalmente de más de 1000, a veces de 3000 a 5000
No tiene sentido considerar equivalente a un VP de una startup de 50 personas y a un VP de FAANG con una organización de más de 1000 personas
No digo que uno sea mejor que el otro; las habilidades necesarias son claramente distintas
De hecho, he visto a personas que recibieron el título de VP en empresas pequeñas no entender esta diferencia, postularse a FAANG y quedar en shock cuando les ofrecieron un rol de manager o senior manager
Era completamente absurdo
En mi experiencia, ese VP tenía, según los estándares de una organización grande, experiencia de nivel pasante, pero había entrado temprano
El director era peor, y las dos personas que les reportaban eran competentes
Ojalá los empleados de Honeycomb dedicaran algo de tiempo a mejorar visiblemente el producto en vez de escribir posts de blog
Tuve la mala suerte de usar Honeycomb en el trabajo, y en sistemas que interactúan con más de unos pocos servicios simplemente era inutilizable
No entiendo por qué hay tantas expectativas exageradas alrededor de esta empresa
Estoy leyendo este artículo teniendo en cuenta que un VP de Honeycomb equivale más o menos a un senior manager en una gran empresa tecnológica
Según los estándares de una gran empresa, eso corresponde a un director
Según mi experiencia, los contribuidores individuales crean producto, los managers crean personas, los directores crean procesos y los VP crean políticas
Todos los que están por encima son una etapa de aprobación de solicitudes de presupuesto
Si es que no consideramos que política y estrategia sean lo mismo
Si acaso es una broma sutil de que nadie crea estrategia, entonces es una buena broma