[{"content":"Soy el VP de Tecnología y Seguridad de una farmacia de venta por correo. Es temporada de evaluaciones, lo que significa que muchos desarrolladores están a punto de molestarse por su aumento, su título, o ambos. La mayoría de los ingenieros que conozco o ignoran los títulos por completo o tratan todo el proceso de evaluación como teatro. Algo de eso es justo, y mucho cae sobre un mal liderazgo. Pero debajo de las quejas hay una idea que explica casi todo.\nLa mejor versión de ella que he escuchado vino de un VP de Riot Games. Hizo una pregunta simple: ¿cuál es tu radio de impacto?\nEl radio de impacto Tu salario sigue cuánto daño podrías hacer, y cuánto riesgo cargas cuando lo haces.\nA un desarrollador junior le entregan un solo componente dentro de un front end. Si lo rompe, el radio de impacto es una pantalla. Radio pequeño, responsabilidad pequeña, sueldo pequeño. A medida que subes, el radio crece. Un ingeniero principal guía gente, diseña la arquitectura de proyectos, y es dueño de sistemas en los que se apoya toda la empresa. Por eso un principal suele ganar dos o tres veces lo que gana un desarrollador normal, y mucho más que un junior. El dinero sigue a la responsabilidad y la rendición de cuentas. Trabajar más duro no lo mueve.\nEsta es la parte que los desarrolladores odian escuchar, porque todos quieren que su valor suba para siempre. Hay un techo de cuánto radio de impacto puede cargar una sola persona sin gestionar a otras. He visto a muchos ingenieros decidir que el proceso de evaluación es estúpido cuando lo que de verdad se encontraron es ese techo.\nLa trampa del ingeniero principal Aquí está el giro cruel. Si haces bien el trabajo de principal, encoges tu propio radio de impacto.\nUn gran principal le quita el riesgo a todo. Construyes los sistemas y las barreras de protección para que lo aterrador deje de serlo. A las empresas les encanta eso, y empujan en la misma dirección: cada proceso que agregan está diseñado para quitarle la rendición de cuentas a cualquier persona y repartir el riesgo. Así que si hiciste bien tu trabajo, las cosas fluyen sin problemas y cualquiera puede entrar y seguir donde lo dejaste. Te has convertido en alguien reemplazable por tu propia ingeniería.\nHe visto a ingenieros principales ganar 200 mil cuyo día a día es genuinamente aburrido, en el mejor sentido posible. Nada se cae. Pasan el tiempo en trabajo nuevo y casi nunca revisitan nada. Eso es justo lo que esperaría de un principal, y es enormemente valioso, pero solo hasta cierto punto. Cuanto mejor te vuelves en prevenir el daño, más pequeño se lee tu radio de impacto en el papel, y más presión a la baja pone eso, en silencio, sobre tu salario.\nAsí que llegas a un equilibrio. De un lado, cuánto daño podrías hacer. Del otro, cuánto estás trabajando para asegurarte de que nunca pase ningún daño. Haz bien el segundo trabajo y le pones techo al primero. Las únicas formas de pasar ese techo son gestionar gente o trabajar muchas más horas, y una de las dos escala mejor que la otra.\nEl mercado empuja la misma palanca La presión no es solo interna. El mercado laboral empuja exactamente en la misma dirección.\nAhora mismo, si necesito un desarrollador de .NET o un ingeniero de front end de React, puedo lanzar un dardo en cualquier dirección y darle a uno bueno. Cuando abro una vacante, atrae unos 300 postulantes al día. Nuestro software de reclutamiento cierra automáticamente la vacante tras 1.000 postulantes, y últimamente eso toma unos tres días. Así que las mismas habilidades que antes se sentían escasas ahora están a unos clics de ser reemplazables, lo que se suma a la falta de riesgo que ya te montaste tú mismo.\nY este es el lente que me quedaría a medida que la IA se hace cargo de más del día a día. Cuando un modelo puede escribir el componente, el radio de impacto se vuelve la única medida duradera de cuánto vales. La pregunta deja de ser \u0026ldquo;¿puedes escribir este código?\u0026rdquo; y se vuelve \u0026ldquo;¿qué le pasa al negocio cuando tú eres dueño de esto, y qué pasa cuando ya no estás?\u0026rdquo;\nDos caminos hacia arriba, y uno no es para todos Desde el techo del principal, el único camino real hacia arriba es el liderazgo, porque gestionar gente es como vuelves a hacer crecer tu radio de impacto de forma legítima.\nQuiero ser honesto: el liderazgo no le va a todos. Mucha más gente quiere ser desarrollador que quiere ser gerente, y eso es sano. Cuando alguien como Primeagen dice que no tiene ningún interés en la gestión, lo entiendo perfectamente. Forzar a un gran ingeniero a un asiento de liderazgo que nunca quiso es como pierdes a un gran ingeniero. Las cuentas del radio de impacto explican el techo. No te obligan a treparlo.\nLlévalo a tu evaluación Saber todo esto cambia cómo deberías entrar a tu evaluación.\nSi tienes un líder técnico que valga la pena, esta es justo la conversación que quiere tener. De verdad quiero que un desarrollador me diga dónde cree que está su radio de impacto frente a dónde lo tengo ubicado. Si cree que está operando muy por encima de su alcance, esa es mi señal para hablar de compensación y dejarlo donde debería estar. Si está rindiendo por debajo de su alcance, ese es mi trabajo de nombrarlo, y de arreglarlo haciéndolo crecer.\nPuedes empezar eso tú mismo antes de siquiera sentarte con tu jefe. \u0026ldquo;He estado haciendo trabajo básico de front end y quiero ser dueño del back end y tocar la base de datos.\u0026rdquo; Eso es un argumento de radio de impacto, y un buen líder ya debería estar buscándolo. Porque hacer crecer a tus desarrolladores es la mayor parte del trabajo. Si no estás haciendo crecer a la gente bajo tu cargo, de verdad no sé qué crees que es el liderazgo. Todo en este campo cambia constantemente, y siempre hay más para que alguien se haga cargo.\nLo que no voy a aceptar es a un ingeniero senior o principal cuyo radio se ha ablandado. Entré a una empresa donde los desarrolladores no hacían más que .NET y tenían que abrir un ticket con un DBA para hacer un cambio de esquema. A nuestra escala eso es ridículo. Tenemos un millón de pacientes. No somos Google, ni somos Epic, e incluso Epic reparte su carga de trabajo entre los sistemas de salud a los que sirve. Un senior que no toca SQL ha dejado, en silencio, que su radio de impacto se encoja, y lo va a sentir en la evaluación se digan las palabras en voz alta o no.\nUna última cosa, porque es la parte que nadie en la cima quiere admitir: la gente deja a sus líderes. Esa frase es 300% cierta. Cada vez en mi carrera que un gerente le ponía techo a mi crecimiento, me fui. De un trabajo me fui a las tres semanas, y se pasaron los siguientes tres años pidiéndome que volviera. Si tu líder es lo que limita tu radio de impacto, ese es el dato más importante de toda tu evaluación, y es el único que nunca te van a anotar.\nAsí que antes de tu próxima evaluación, calcula tu propio radio de impacto con honestidad. Después pregúntale a tu jefe cómo hacerlo más grande. Lo peor que pueden decir es que no, y lo que digan te dirá todo sobre si quedarte.\n","permalink":"https://barajas.blog/es/posts/developer-blast-radius/","summary":"La mejor definición de salario que he escuchado vino de un VP de Riot Games. También explica por qué hacer bien el trabajo de senior te pone un techo a tu propio sueldo, y qué hacer al respecto en tu próxima evaluación.","title":"¿Cuál Es Tu Radio de Impacto?"},{"content":"La primera vez que pasé de ingeniero senior a dirigir un área de tecnología, el título que me dieron fue director. No querían entregar un VP, y nadie iba a ser CTO. Los desarrolladores dirigían el lugar según quien tuviera la opinión más fuerte ese mes. Ese era el trabajo: subirte a un auto en movimiento y encontrar el volante.\nLa mayor parte de mi experiencia es en empresas pequeñas con problemas técnicos y de producto profundos. En dos de las cinco, los fundadores eran farmacéuticos que se pusieron a montar una empresa de tecnología. Sale más o menos como te imaginas. Gente a la que le encanta ir a restaurantes abre un restaurante, descubre que es mala dirigiéndolo, y ya lleva dos años metida antes de que alguien lo diga en voz alta. La misma historia en farmacia.\nAsí que esto está sesgado hacia el lado desordenado del espectro. Si acabas de aceptar un rol de liderazgo en una empresa tranquila y bien dirigida, felicidades, y casi todo esto sigue aplicando, solo que vas a tener más tiempo para hacerlo.\nAsí dirijo los primeros 90 días.\nGuarda los martillos La parte más difícil de los primeros 30 días es no hacer casi nada.\nEres ingeniero. Quieres arreglar cosas. Como ejecutivo deberías rara vez estar arreglando algo, y probablemente nunca deberías escribir código. Si estás escribiendo código, estás cubriendo un hueco de personal, y el liderazgo tiene que enterarse.\nTu verdadero trabajo en el primer mes es observar y tomar notas. Siéntate en las reuniones, sigue el proceso que tengan, y aguanta las ganas de ofrecer soluciones hasta que alguien las pida. La forma más rápida de perder a la sala es que alguien diga \u0026ldquo;ni siquiera entiendes cómo hacemos las cosas aquí,\u0026rdquo; y tendrá razón, porque todavía no lo entiendes. Algún arreglo que parece obvio el día tres resulta imposible una vez que estás metido en el barro el día veinte.\nTambién vas a conocer a la gente muy comprometida con su propio proceso. \u0026ldquo;Solo se rompió este sprint.\u0026rdquo; \u0026ldquo;Lo arreglaríamos si tuviéramos tiempo.\u0026rdquo; Después hablas con todos los demás y te enteras de que se rompe cada sprint y siempre lo ha hecho. Tu ventaja como la persona nueva es la perspectiva de afuera, y tiene fecha de caducidad. Úsala antes de volverte parte del paisaje.\nLa única piedra que sí volteas Hay excepciones, y las reconocerás cuando las veas.\nUna mañana estaba leyendo un pull request y vi a alguien escribir una inyección SQL directo en él. Puse el límite ahí mismo. No me importa si nos cuesta un millón de dólares, no puedes desplegar a sabiendas el vector de ataque más explotado de internet. Cualquier cosa que sea un agujero de seguridad activo o un incendio regulatorio se atiende ahora, no en tu informe de los 30 días.\nY después, de todos modos, se convierte en uno de tus puntos, porque \u0026ldquo;el equipo desplegó inyección SQL y ni se inmutó\u0026rdquo; te dice algo real sobre dónde estás parado de verdad.\nSíntoma, causa, y luego el 80/20 A los 30 días le debes un informe al CEO. El mío siempre tiene la misma forma: mis cinco problemas principales, el síntoma que todos ya sienten, la causa que está por debajo, y el arreglo más pequeño que rinde más.\nNunca llegues con \u0026ldquo;el número uno es una reconstrucción de siete meses.\u0026rdquo; Así te ignoran. Llega con la cosa de una semana y la cosa de un mes que le mejoran la vida a todos, y guarda el trabajo estructural feo para después de haberte ganado algo de confianza.\nEl triunfo rápido al que recurro una y otra vez es la observabilidad. Mi empresa más reciente no tenía nada de monitoreo de rendimiento de aplicaciones. Cuando algo se rompía, la gente abría los archivos de log y se ponía a leer. Nunca eran los primeros en enterarse, y todo tardaba una eternidad en arreglarse. Hice la pregunta obvia, ¿no estaría genial saber exactamente qué está fallando y por qué?, y luego les dije que es una prueba de concepto de un día. Teníamos OpenTelemetry corriendo para el final de la semana.\nNadie celebra nunca una semana de trabajo que rinde tanto. Ese es el punto. Los triunfos rápidos son cómo compras el capital político que vas a gastar después en el trabajo aburrido e importante. Porque eventualmente los triunfos fáciles se acaban y solo queda lo poco glamoroso: un ciclo de vida de desarrollo de software de verdad, monitoreo de dependencias, las cosas que ningún cliente elogia jamás. Un equipo de seguridad te pedirá tu SDLC y lo archivará. Ninguno de ellos te va a decir que lo bordaste. Te toca a ti ser el campeón de ese trabajo.\nHay una frase en la que pienso mucho, y olvido quién la acuñó: cada tres años todo en tecnología se vuelve el doble de fácil. Una variación de la ley de Moore, pero cierta. El APM era prácticamente inalcanzable hace diez años. OpenTelemetry no existía, estabas mirando Datadog o New Relic y un presupuesto de verdad. Hoy estás loco si no lo tienes. Muchas de tus ventajas \u0026ldquo;secretas\u0026rdquo; son solo saber qué se abarató mientras nadie miraba.\nAprende cómo lee tu CEO La mitad de este trabajo es traducción, así que aprende el formato antes de escribir el informe.\nHe tenido CEOs visuales que quieren un mapa de la aplicación: así encajan las piezas, aquí están los cuellos de botella, aquí es donde se está incendiando. He tenido CEOs que quieren exactamente seis viñetas, y si escribes una séptima, el correo no se lee. Suena quisquilloso. No lo es. Son personas ocupadas que no quieren una pila de problemas encima, y descubrir su formato temprano es la mayor parte de hacerte escuchar.\nUna cosa más que a los ejecutivos no les importa: problemas que todavía no puedes nombrar. Decirle a un CEO \u0026ldquo;hay deuda técnica en algún lado que no hemos encontrado\u0026rdquo; solo le entrega una preocupación para cargar. Siempre hay suficientes problemas conocidos como para que nadie tenga paciencia para los hipotéticos. Sigue cavando hasta que la preocupación se vuelva algo específico y accionable.\nDía 60: lanza los triunfos baratos El segundo mes es para implementar de verdad. A estas alturas ya le entregaste al CEO tus soluciones y tus triunfos rápidos, y la regla del 80/20 toma el control. Si un arreglo es el 20% del esfuerzo y resuelve el 80% del dolor, eso es lo que se va a hacer. Intentar forzar primero la solución más rigurosa es pelear contra la gravedad.\nMantén tus cambios en arreglos técnicos y proceso ligero. ¿No hay plan de respuesta a incidentes? Escribe uno. ¿No hay alarmas ni monitoreo? Agrégalos. Lo que no haces en el segundo mes es entrar marchando a anunciar que vas a convertir a toda la empresa de cascada a ágil. Si vas a tocar el proceso, átalo directamente al dolor que está causando, nunca a tus preferencias.\nAquí también es donde empiezas a guardar capital para después. Avísale al CEO con anticipación: lo haremos a tu manera, y como estamos usando cascada sin observabilidad, esto va a tardar dos meses en vez de uno, y aquí está exactamente por qué. Dilo con hechos, sin quejarte. Después sigue su proceso en público. Cuando la cosa tarde los dos meses que predijiste, apuntas al registro. Así te ganas el derecho a empujar por la decisión más grande después.\nNo necesitas una metodología en particular. Necesitas una cadencia. Kanban, scrum, notas adhesivas en una pizarra, me da igual, mientras las cosas se entreguen en un calendario ajustado y predecible, semanal o quincenal a más tardar. Elige una y mantenla.\nY el calendario de releases rara vez es del todo tuyo. En farmacia no puedes desplegar en diciembre, porque el seguro de todos cambia el 1 de enero y el 10 de enero. Si despliegas un cambio que rompe algo esa primera semana de enero, has creado un caos dentro de los reclamos y la dispensación. Por eso los congelamientos de código en empresas de salud empiezan en diciembre. Quieres un mes entero de que nada cambie y nada se rompa.\nDía 90: todos tienen un plan hasta que les pegan Para el tercer mes deberías tener unos cuantos triunfos implementados y un control real sobre la lista de problemas. También vas a tener una pila de problemas nuevos, porque la mitad de tu prolijo plan de 30/60/90 no sobrevivió al contacto.\nMike Tyson tenía razón. Todos tienen un plan hasta que les pegan en la boca. He redactado planes de 30/60/90 y los he mantenido casi del todo. También los he redactado y nunca más he vuelto a mencionarlos, porque la empresa tenía tantas caídas que el único plan real era apagar incendios y poco a poco adelantarse a ellos. Si tu empresa no puede prometer honestamente qué va a estar haciendo dentro de un mes, tu plan de 30/60/90 es decoración. Una empresa que puede entregarte una hoja de ruta de tres meses y de verdad cumplir hasta el 80% es una empresa estable, y llevar una hasta ahí suele tomar unos dos años y mucho compromiso de todos.\nAquí está la parte que nadie te cuenta a la entrada. La mayoría de lo que parece un problema de tecnología es un problema de producto, un problema de priorización, y un problema de liderazgo disfrazado de tecnología. La tecnología está en el fondo de la empresa. Cada mala decisión que se toma más arriba rueda cuesta abajo y aterriza sobre tu equipo, y no hay forma de escapar, es gravedad. Un equipo de liderazgo anterior claramente se dejó engatusar con un mal proveedor de redacción de datos, lo firmó en noviembre con una fecha límite de fin de año, y la cuenta cayó sobre ingeniería. A mí no me tocó nada de la comisión, y el producto encima era malo. Gracias por eso. (Escribí más sobre las ideas que ruedan cuesta abajo aquí.)\nAsí que cuando algo que debería tomar dos semanas toma tres meses, la causa casi siempre es proceso o priorización, y esa es la pelea que de verdad tienes que ganar. Sigues su proceso en público y le dices la verdad al CEO en privado. Cuando te dan la razón, y te la van a dar, a veces eso fuerza una decisión difícil, y a veces esa decisión termina con el puesto de alguien. Esa es la parte genuinamente incómoda del trabajo.\nPero el equipo de tecnología es aplastado por todo lo demás de la empresa por defecto, porque todo rueda cuesta abajo. Alguien no cumple una fecha, alguien cierra una venta, alguien firma un proveedor, y todo aterriza sobre ti, y eres tú quien queda mal aunque todos los demás se hayan portado mal. Si no peleas por tu equipo, lo aplastan.\nEse es todo el trabajo en los primeros 90 días. Observa más de lo que arreglas, lanza los triunfos baratos, aprende cómo lee tu CEO, y empieza a construir el argumento para las cosas que de verdad importan antes de que alguien esté listo para escucharlo.\n","permalink":"https://barajas.blog/es/posts/first-90-days-running-technology/","summary":"El trabajo dejó de ser \u0026lsquo;arréglalo\u0026rsquo; el día que aceptaste el puesto. Así paso los primeros tres meses dirigiendo un área de tecnología sin quemar mi credibilidad en la primera semana.","title":"Tus Primeros 90 Días Dirigiendo Tecnología"},{"content":"Soy el VP de Tecnología de una farmacia de venta por correo. Si diriges un área técnica, ya conoces a la persona que voy a describir: la que aparece con una idea. Hay dos tipos: los que saben que involucra a mi equipo, y los que todavía no se han dado cuenta. Ambos terminan en mi escritorio.\nLa versión corta de cómo manejo esto:\nInvolúcrate temprano, porque el trabajo rueda cuesta abajo hasta IT pase lo que pase. Hazles demostrar la demanda y los números antes de que nadie construya nada. Mata los lanzamientos a lo grande. Valida con una puerta falsa en su lugar. Protege el trabajo que ya comprometiste diciendo que no. El resto es cómo lo hago de verdad.\nEl refrigerador que necesitaba un sysadmin Nuestro equipo de operaciones estaba consiguiendo un medicamento de distribución limitada. El fabricante dijo que sí, que podíamos venderlo, pero que tenía que vivir en este refrigerador específico. Bien. Llega el refrigerador, el medicamento entra.\nEntonces: \u0026ldquo;Ah, por cierto, abran el puerto 22 para que podamos entrar por SSH al refrigerador, y el 443 para el servidor web con el que lo monitoreamos.\u0026rdquo;\nAsí que ahora el refrigerador necesita a IT para funcionar. No lo puedes enchufar a la pared como una tostadora. Dale una semana y la tostadora también va a necesitar un ticket.\nEsa es la parte que nadie te advierte. El trabajo te encuentra lo hayas invitado o no. Rueda cuesta abajo, y pelear contra eso es pelear contra la gravedad. Si te pierdes la conversación temprana, te llega al equipo ya formado del todo, sin que nadie se haya preguntado si debería existir.\nDos razones para decir que no Siempre hay un millón de razones para hacer algo. Expandirse a un mercado nuevo. Pegarle una función al portal. Todas suenan geniales en la sala.\nPor lo general solo hay dos razones para no hacerlo, y son las mismas cada vez:\nNadie lo quiere. Los números no dan. Tu costo de adquisición de cliente es de $150 y tu valor de por vida no, así que pierdes dinero en cada registro y todo el asunto está bajo el agua. Así que cuando aparece una idea, dale la vuelta: ¿cómo estás validando esto? Yo me apoyo en la Startup School de Y Combinator para el marco. Las startups optimizan cada decisión alrededor de quién hace qué y cuándo, porque no hay nadie de sobra para hacer el trabajo. Esa disciplina es justo lo que se evapora cuando una empresa tiene suficiente dinero para absorber malas apuestas. Devuelve la carga de la prueba al principio, antes de que nada de eso toque ingeniería.\nLos lanzamientos a lo grande casi siempre fallan A algunas culturas les encanta el lanzamiento a lo grande: una gran revelación, todo de una vez. Nunca he sido parte de uno en una empresa de salud donde alguien de verdad usara la cosa al día siguiente. Hay mucha más logística en cómo se construye y se adopta algo aquí de lo que la gente espera. A menos que vendas directo al consumidor, no vas a tener cien mil usuarios el primer día. Tendrías suerte de tener dos.\nUn lanzamiento a lo grande es software desplegado de a un año a la vez. Te saltas el iterar, la investigación de mercado, la validación, y envías el año entero de un solo golpe. ¿Quién necesita sprints? ¿Quién necesita entrega continua? Solo mándalo y reza.\nEl marketing decide si algo de esto funciona Cuando el liderazgo viene con \u0026ldquo;queremos hacer esto, queremos hacer aquello\u0026rdquo;, una pregunta lo atraviesa todo: ¿cuánto cuesta adquirir cada cliente? Si no lo saben, todavía no vale la pena hacerlo.\nCada producto vive y muere por el marketing, y todos tienen un techo de gasto en publicidad. Google ha afinado su algoritmo para saber el precio exacto que vale un clic, y va a hacer su dinero hagas tú el tuyo o no. Apuesta contra eso sin conocer tus números y te quiebras mientras Google no.\nUna frase de ellos, una década de ti La otra cosa con la gente de ideas es la asimetría. Alguien dice \u0026ldquo;quiero un cohete que aterrice y se pueda reutilizar después del lanzamiento.\u0026rdquo; Tres segundos de decir. Una década de construir.\nCada día la cima de la empresa genera unas cuantas frases. \u0026ldquo;¿No estaría genial si tuviéramos X?\u0026rdquo; \u0026ldquo;Deberíamos tener Y.\u0026rdquo; Cada una puede ser dos o tres años de ingeniería. Y no siempre es el equipo de liderazgo. Es la junta, la empresa matriz, algún factor externo, quien sea. La fuente no importa. La asimetría sí: un flujo constante de frases baratas pisoteará con gusto una cantidad finita de capacidad cara.\nDevuélveles el trabajo La única forma de pelear contra esa asimetría es devolver el trabajo. ¿Tienes una idea? Genial. Aquí está el proceso.\nEmpieza con unos tres meses de que ellos escriban un plan de negocio y dimensionen el mercado. Después corres la meta del equipo técnico todo lo posible hacia la izquierda. Sin construir. Una página de aterrizaje. Un sitio de puerta falsa, sin ninguna funcionalidad y con una lista de espera. Mándale un correo a unos cuantos miles de pacientes: aquí hay una idea, aquí está el enlace para registrarse, aquí tienes $10 de descuento en tu primer pedido.\nSi diez dólares gratis no logran que alguien cruce la puerta, estás en serios problemas. Estás a punto de gastar dinero de verdad anunciando un producto que ni siquiera puedes regalar.\nAlguien tiene que decir que no Aquí está por qué todo esto importa. Una empresa grande tiene un colchón de dinero, así que una mala apuesta no te mata en el momento en que la haces. Lo que no tiene es tiempo ilimitado. La capacidad de mi equipo ya está comprometida hasta el año que viene. Si paráramos todo el trabajo nuevo hoy, el backlog sigue teniendo un año de profundidad. Eso no es una forma de hablar.\nAsí que alguien tiene que decir que no, porque el trabajo que ya está en la cola casi seguro vale más que cualquier idea que venga rodando esta semana. Decir que no a lo nuevo es como proteges el tiempo que ya prometiste a las cosas que importan.\nLa mayoría de la gente no se da cuenta de cuánto de esto ya está resuelto. No voy a fingir que YC es perfecto, pero le gana a quemar un trimestre y un presupuesto para reaprender la misma lección. Cuando no puedo ganar la discusión yo solo, mando el enlace. Es un curso intensivo de veinte minutos sobre cómo validar una idea, y aguanta bien para una empresa grande y establecida. Róbatelo: Startup School de Y Combinator.\n","permalink":"https://barajas.blog/es/posts/dealing-with-idea-people/","summary":"Siempre hay alguien con una idea que termina siendo el problema de tu equipo. Así hago que demuestren que vale la pena antes de escribir una sola línea.","title":"Todo Rueda Cuesta Abajo hasta IT"},{"content":"Soy Michael Barajas. Soy el VP de Tecnología y Seguridad de una farmacia de venta por correo, y aquí escribo sobre la parte del software que nadie transmite en vivo: dirigir al equipo.\nPasé cerca de diez años construyendo software, sobre todo en el sector salud, antes de pasar a un rol de liderazgo. La mayor parte de mi experiencia es en empresas pequeñas con problemas técnicos y de producto profundos, de esas donde los fundadores eran farmacéuticos que se pusieron a montar una empresa de tecnología y ya llevaban dos años metidos antes de que alguien lo dijera en voz alta. Resulta que es un gran lugar para aprender.\nHay mucho contenido bueno de desarrolladores y muy poco desde el asiento donde la ingeniería se cruza con el liderazgo, así que ese es el hueco que vengo a llenar. Por ahora eso significa cosas como cómo son de verdad tus primeros noventa días dirigiendo un área de tecnología, por qué tu salario sigue tu radio de impacto, y cómo hacer que alguien demuestre que una idea vale la pena construir antes de que caiga sobre tu equipo. Hay un tema que siempre vuelve: la tecnología está en el fondo de la empresa, y cada decisión que se toma más arriba rueda cuesta abajo hasta llegar a ella.\nCorreo: michael@aioperable.com Código: GitHub Este sitio funciona con Hugo y el tema PaperMod, servido por Caddy en un droplet de DigitalOcean.\n","permalink":"https://barajas.blog/es/about/","summary":"Acerca de Michael Barajas","title":"Acerca"}]