viernes, 24 de junio de 2022

Paper-Book: resumen de el nuevo nuevo juego de desarrollo de productos que dio origen a Scrum

Si quieres conocer realmente el corazón del marco de trabajo Scrum debes leer el paper de Hirotaka Takeuchi and Ikujiro Nonaka que le dio origen a principios de los 80. Aunque si no lo lees aquí te comparto un resumen.

En su estudio y paper “The New New Product Development Game”, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con el avance en formación de scrum de los jugadores de Rugby, a raíz de lo cual quedó acuñado el término “scrum” para referirse a ella.


Estos autores ofrecen el enfoque de Scrum como alternativa al enfoque tradicional secuencial (cascada) o al de "carrera de relevos" para el desarrollo de productos en contextos de requisitos inestables donde se necesita velocidad y flexibilidad. Su enfoque es uno holístico, compuesto por un núcleo de seis características: 

  1. Libertad con exigencia (Built-in Instability): significa que la alta dirección crea un elemento de tensión en el equipo al darle gran libertad para llevar a cabo un proyecto de importancia estratégica para la empresa y al mismo tiempo establecer requisitos muy desafiantes. Es decir: dar gran libertad y requisitos muy exigentes.

  2. Equipos autoorganizados: es un equipo que exhibe tres condiciones: autonomía, autotrascendencia y fertilización cruzada. En el día a día, la alta dirección rara vez interviene; el equipo es libre de establecer su propia dirección. En cierto modo, la alta dirección actúa como capitalista de riesgo. O como dijo un ejecutivo: “Abrimos nuestro bolso pero mantenemos la boca cerrada”.

  3. Fases de desarrollo superpuestas: es la integración de diferentes profesionales de una cadena de valor para lograr objetivos comunes, en vez del trabajo aislado y en secuencia. Aquí se indroduce la idea del rugby, las fases se superponen considerablemente, lo que permite que el grupo absorba la vibración o “ruido” generado a lo largo del proceso de desarrollo trabajando como bloque unido.  Un equipo trata de recorrer la distancia como una unidad, pasándose el balón de un lado a otro.

  4. Control sutil: El control sutil significa seleccionar a las personas adecuadas, crear un entorno de trabajo abierto, alentar a los ingenieros a salir al campo y escuchar lo que los clientes y stakeholders tienen que decir, establecer un sistema de evaluación y recompensa basado en el desempeño del equipo, manejar las diferencias de ritmo a lo largo del proceso de desarrollo y tolerar y anticipar los errores. La gerencia establece suficientes puntos de control para evitar que la inestabilidad, la ambigüedad y la tensión se conviertan en caos; y al mismo tiempo, la gerencia evita el tipo de control rígido que perjudica la creatividad y la espontaneidad fomentando el ‘autocontrol’. 

  5. Aprendizaje múltiple (Multilearning): significa dedicar tiempo al aprendizaje individual constante fomentando la iniciativa y el aprendizaje práctico por parte de los empleados y ayudando a mantenerlos al día con los últimos avances. Además incluye el aprendizaje en otras áreas de la experticia de cada profesional.

  6. Transferencia organizacional del aprendizaje: este incluye el impulso para acumular conocimiento a través de niveles y funciones es solo un aspecto del aprendizaje y el impulso por parte de los miembros del equipo para transferir su aprendizaje a otros fuera del grupo. El conocimiento también se transmite en la organización al convertir las actividades del proyecto en una práctica estándar.


Luego Ken Schwaber y Jeff Sutherland dan forma al marco de trabajo Scrum. Pero esa es otra historia.



Referencias:

miércoles, 22 de junio de 2022

Libro: reseña de El Arte de Hacer el Doble de Trabajo en la Mitad de Tiempo

 



Título: Scrum. El Arte de Hacer el Doble de Trabajo en la Mitad de Tiempo.
Autor: Jeff Sutherland.


Resumen del libro


Este libro de Sutherland está enfocado más en los aspectos de mentalidad y argumentaciones a favor del marco de trabajo Scrum, más que técnico, es decir que es más teórico que práctico. 


La propuesta del libro es extender el marco a la gestión de las organizaciones. Para el autor, Scrum puede contribuir a revolucionar la forma en que trabajan las empresas de prácticamente todas las industrias.


Al principio habla del origen de Scrum desde sus pioneros Hirotaka e Ikujiro, pasando por analogías de la aviación, el ciclo de PDCA y Shu-Ha-Ri. Luego habla sobre las características de los equipos de alto rendimiento, siguiendo con la gestión del tiempo con time-box, cómo disminuir desperdicios para ser más productivos, planificar y estimar trabajo, sobre la felicidad; y estimación y priorización de trabajo.


Sutherland plantea que que el deseo de la gerencia tradicional de “el control y predictibilidad” es inútil. Comenta que todo proyecto implica problemas y golpes de inspiración y, en consecuencia, busca responder las siguientes preguntas: ¿por qué no revisar con regularidad para ver si lo que se está haciendo sigue la dirección correcta y es lo que la gente quiere? ¿Por qué no revisar si se puede hacer mejor y más rápido y qué lo impide? Y a este proceso lo llama ciclo de «inspección y ajuste» de Scrum.


En general Sutherland nos explica Scrum.


Crítica


A favor

El libro nos da argumentos para persuadir sobre la utilidad de Scrum con una lectura menos estructurada que las guías de Scrum. Me gustó que en sus explicaciones toma ideas de Lean para argumentar la eficiencia de scrum. Además, finalmente, nos da varias frases, como memes, sobre la mentalidad de Scrum, como por ejemplo:

  • “Seguir ciegamente los planes es una estupidez”

  • Fallar rápido para poder arreglar pronto

  • Cambiar o morir

  • Inspeccionar y adaptar

  • El éxito se basa en la eficiencia del equipo

  • No hay que señalar con el dedo ni culpar a nadie. Las personas no tienen la culpa de los malos resultados; son los malos sistemas los que tienen la culpa.

  • La multitarea te vuelve estúpido

  • Trabajar demasiado provoca errores

  • Si puedes cuantificar tu felicidad, podrás ver cómo mejora tu rendimiento.


En contra

El título de este libro es bastante controversial. Pues, mi detector de humo se activa cuando oigo títulos con “afirmaciones extravagantes” y su título es de esos. Como lo diría Alistair, el título vende. Todos sabemos que el principio ágil es "minimizar el trabajo realizado", lo que apunta a lograr más con menos trabajo. En general, la gente ya está trabajando lo más rápido que pueden, no se trata de que hagan el doble de trabajo en la mitad del tiempo, eso es un imposible que no buscamos, y por mal atino suele ser lo que entienden muchos ejecutivos. Nadie va a hablar más rápido, programar más rápido ni pensar más rápido. Lo que quiso decir es más valor del mismo esfuerzo de trabajo o lograr más o mejores resultados con la misma cantidad de trabajo. 


Conclusión

Si bien no es un libro innovador ni de gran redacción literaria, es un libro muy recomendable si realmente se quiere entender Scrum desde un enfoque más teórico, de primera mano de uno de sus autores. Debería ser lectura obligatoria para cualquier Scrum Master que realmente quiere ejercer su rol con sabiduría.


Referencia: 




​​


Libro: Gestionar es gestionar el cambio

 


Les comparto el último libro que he escrito relacionado a organizaciones y gestión del cambio.


Este libro nos ayuda a pensar en el rol de los gerentes y estilos de gerencia adecuados para entornos hiper-complejos, algo caóticos y de extrema incertidumbre, como los días de crisis global, pandemia y guerras que han generado contextos cambiantes y desafiantes a nivel mundial. Nos ayuda a re-pensar la gestión del cambio para buscar lograr organizaciones hiper-resilientes.














Referencias:


lunes, 20 de junio de 2022

Retrospective: Medir el Cognitive Loadometer al inicio de una Retro

Sobre la carga cognitiva

Como líderes de equipo podemos medir la Carga Cognitiva de un equipo. En psicología cognitiva, la carga cognitiva se refiere a la cantidad utilizada de recursos de la memoria de trabajo o la cantidad total de esfuerzo mental que se utiliza en la memoria de trabajo, como se refiere John Sweller en el libro "Teoría de la carga cognitiva". Según la teoría de John Sweller la memoria de trabajo tiene un límite, y cuando la carga cognitiva a la que la sometemos es alta… se hace difícil aprender. En otras palabras, es cuan saturados de información estamos para resolver los problemas que debemos resolver. El exceso de carga cognitiva puede deberse a demasiada complejidad en los problemas a resolver, las interrupciones frecuentes en el trabajo, distracciones, cambios de contexto, sobre-trabajo ('Work in Progress' o WIP alto), etc. 

La medición de la carga cognitiva del equipo puede ayudar a buscar mejorar la productividad ('throughput', 'velocity', etc.), el enfoque ('WIP') y la motivación del equipo e incluso mitigar el riesgo de agotamiento y estrés ('burnout'y posibles rotaciones de profesionales ('turnover').

¿Cómo medirla?


Fabio Pereira nos muestra una manera muy simple de medirla con una escala de 1 a 5.


Al iniciar una retro puedes medirla par sondear cuál es la percepción del equipo de su carga cognitiva. Lo puedes hacer con un Google Form, un tablero Miro o cualquier otra herramienta.






Análisis y acción


Si buscamos mejorar el cómo trabaja un equipo, extensible a una organización, hay que concienciar y trabajar en minimizar la carga cognitiva por debajo del límite de tolerancia. Aquí el equipo debe analizar la situación y proponer acciones de mejora como por ejemplo:

  • Carga intrínseca: generar formación o nivelación de conocimientos, mejorar elección de tecnologías, tener prácticas de pairing o swarming, etc. 
  • Carga cognitiva externa: podemos analizar el WIP y los WIP Límites del trabajo del equipo para aumentar foco, mejorar priorización de trabajo, reducir proyectos o contextos distintos, revisar asignación de trabajo, asignación de personas, etc.




Referencias:



martes, 7 de junio de 2022

Lean: El bar de Pepe

 


El bar de Pepe es atendido por un Barman que prepara pedidos de bebidas a sus clientes. Un día, el Barman comenzó a leer un libro acerca del pensamiento 'Lean', y así comprendió algunos conceptos nuevos para él, aunque datan de muchos años atrás.


Cuatro de estos conceptos son los siguientes: el trabajo en proceso o WIP, que indica los pedidos que se están preparando; el tiempo de entrega de una bebida, o también denominado Lead Time, que es el tiempo total desde el momento en que le hacen un pedido hasta el momento en que lo sirve y entrega al cliente; el tiempo de ciclo o Cycle Time, es el intervalo de tiempo entre dos bebidas que salen de la barra y son entregadas al cliente o tiempo que se tarda el Barman en completar la preparación de una bebida; y el rendimiento o Throughput, que es el número de bebidas que se entregan en un período de tiempo, como si se tratase de su velocidad de entrega.


Proceso Kanban del bar de Pepe
Proceso Kanban del bar de Pepe y sus métricas relevantes

Con estos conceptos aplicó la famosa Ley de Little que dice que "la cantidad promedio de elementos de trabajo en proceso (WIP) en un sistema estable, con WIP fijo, es igual a la tasa de entrega (Throughput) promedio multiplicada por el tiempo promedio que pasan en el sistema (Lead Time)".

Así que calculó su tiempo de entrega basado en su rendimiento individual, estimando una media de seis bebidas entregadas por hora, preparando una bebida a la vez (WIP=1).

WIP = Throughput x Lead Time

1 = 6 bebidas x hora * Lead Time

Lead Time = 1 / 6 x hora

Lead Time =  0,16 hora = 10 min

Así supo que el tiempo en que se demoraba en satisfacer las necesidades de sus clientes era de 10 minutos, su Lead Time.

Pepe, quien gestionaba el bar, le pidió al Barman que trabajara más duro y que atendiera a varios clientes a la vez, porque así sería más eficiente. Le pidió que hiciera 3 pedidos en paralelo.

Luego de un tiempo el Barman hizo el cálculo de su Lead Time considerando el mismo rendimiento individual.

3 = 6 x hora * Lead Time

Lead Time = 3 / 6 x hora

Lead Time =  1/2 hora = 30 minutos

Resulta que descubrió que lo que parecía más eficiente para el gerente era todo lo contrario para el cliente, porque ahora se demoraba media hora en entregar cada pedido.

Así es como el Barman comenzó a convertirse en Bartender aplicando 'Lean'.

Gestiona el sistema, no las personas


Con John Little y su ley se viene contando esta historia de diferentes maneras y diferentes autores, como Cliyahu Goldratt con “The Goal” o Caroli con sus "Whisky, Sushi, Systems and Flow". Pero contar historias es fácil, lo difícil es implementar sus enseñanzas. Este ejemplo es muy simple, pues en las organizaciones el flujo de trabajo es mucho más complejo, con mayores dependencias, diferentes roles, tipos de trabajo y muchas variables en juego. A pesar de la complejidad en la mayoría de organizaciones, las ideas de Little se pueden aplicar en el día a día en cualquier equipo de trabajo o área. Principalmente porque es un principio sistémico y todas las organizaciones y sub-organizaciones son sistemas.


Estos conceptos son útiles para entender el sistema de trabajo de una organización. Utilizando el ejemplo del Barman se dimensiona el funcionamiento del sistema usando estos conceptos, entendiendo que para el cliente el Lead Time es lo más importante, incluyendo tanto el tiempo de espera como el tiempo de proceso. Este último, el Cycle Time, indica el tiempo en el cual el 'ítem de trabajo' fue realmente procesado sin cola de espera. Muchas veces los administradores se centran mucho en el Cycle Time sin prestar atención al tiempo de espera, olvidándose así que en sistemas complejos la suma de todos los tiempos de espera generan un alto costo de retraso. Sin embargo, con Lean se sabe que lo que importa son ambos (tiempos de espera y Cycle Time), y que la felicidad del Barman y del cliente dependen de lograr un sistema estable de flujo con cadencia. Si a la barra del bar llegan más pedidos de los que se puede atender, se dejarán clientes insatisfechos y se exigirá al sistema de más, generando mala calidad del producto, errores o agotamiento del personal. Por el contrario, si su velocidad de entrega (Throughput) es mayor a la velocidad de llegada de pedidos, tendrá demasiada ociosidad. Por lo tanto, la eficiencia está en el balance, donde la tasa de arribos (AAR) debe ser equivalente a la tasa de entregas (ADR). 


Proceso Kanban del bar de Pepe y tasas de entrada y salida del sistema

En un sistema estable, balanceado, no hay divergencia ni convergencia entre tasas de arribos y entregas. El Barman trabaja a su capacidad, saludablemente, en un tiempo óptimo de entrega, satisfaciendo las necesidades de sus clientes. Así el bar se mantiene y puede prosperar.


Diagrama de tasas de entrada y salida de un sistema balanceado y estable



Pero todo sistema tiende a desbalancearse. Si el sistema está desbalanceado, no sirve de nada que Pepe presione al Barman para que trabaje más rápido, haga pedidos en paralelo o realice horas extras. La clave está en el balance, y parte de balancear es controlar el WIP y no a la gente. Gran parte de las veces, el rendimiento del sistema depende más de la estructura del sistema que de los rendimientos individuales de las personas que participan en el sistema.


En un sistema desbalanceado, una tasa de divergencia positiva (entre la tasa de arribos y la de entrega) sugiere que el WIP es demasiado alto y estamos sobrecargados (entran más pedidos de lo que salen). 


Diagrama de tasas de entrada y salida de un sistema desbalanceado



Por otro lado, una divergencia negativa (entran menos pedidos de los que pueden salir) sugiere que el límite WIP es bajo y que la productividad es baja (desaprovechando capacidad).


Sistema desbalanceado con divergencia negativa


Hay algo peor que un sistema desbalanceado y es un sistema muerto. Si una línea se vuelve plana, eso significa que no llega nada a la etapa correspondiente o que nada sale; y cuando nada entra y nada sale es cuando prácticamente un sistema muere. Si un bar no recibe pedidos y no entrega bebidas muere.


Sistema sin actividad
Sistema sin actividad

¿Para qué nos sirven entender estos gráficos anteriores? Pues, nos ayudan a comprender una de las herramientas analíticas más usada en gestión Lean, el Diagrama de Flujo Acumulado (CFD). El CFD nos muestra el nivel de estabilidad del flujo en un sistema de trabajo, ya sea un bar, un restaurante, un equipo de desarrollo de software o un equipo de reclutamiento. 


Ejemplo de un Cumulative Flow Diagram – CFD
Ejemplo de un Cumulative Flow Diagram – CFD



En resumen, como indica John Little (1961) "el número medio de elementos de trabajo en un sistema estable es igual a su tasa de terminación promedio, multiplicada por su tiempo promedio en el sistema".



Finalizando con el ejemplo, si Pepe comienza a tener la mirada Lean como el Barman hará suya una frase que dice: "Gestiona el sistema, no las personas" (Management 3.0). Más gerentes deberían aplicar la ley de Little y gestionar el sistema: minimizar Cycle Time y Lead Time, maximizar Throughput (promedio), limitar el WIP a un óptimo y balancear (igualar tendencias AAR y ADR).






Referencias:







viernes, 25 de marzo de 2022

Los niveles del seniority


 

Los niveles del seniority

¿Junior, Semi senior o Senior? ¿Cuál es tu nivel de carrera profesional o de experticia o de habilidad para resolver los problemas que una organización te plantee? Siempre me pareció que la distinción de niveles de experticia no es para nada algo claro ni uniforme. Pues, no existe una fórmula estándar de clasificación. Cada empresa tiene sus propios estándares; y las que lo tienen, porque muchas lo manejan a ojo.

Sin embargo, parece que la mayoría reconoce los típicos tres niveles: Junior, Semi senior y Senior. ¿Es así? No tanto. Tampoco es un estándar claro. De hecho, en las empresas de tecnología de Latinoamérica es común incluir internamente un nivel amateur o ‘trainee’. Que suelen ser personas sin experiencia, que hacen pasantías o están iniciando y aprendiendo en un perfil dado. Realmente no alcanzan a ser ‘Junior’. Este nivel es como el cinturón blanco en artes marciales. Si eres blanco es porque todavía no tienes ningún color. Ser Junior sería como ser cinturón amarillo. Un naranja podría ser un Semi senior y un Senior color verde.

En general puedes googlear y encontrar frecuentemente esta escala:

  • Trainee: Aquel que está estudiando o finalizando sus estudios y no cuenta con experiencia profesional. Este nivel requiere de supervisión y suele estar acompañado de capacitaciones y seguimiento de otros miembros de la organización.
  • Junior: Aquel que está empezando su carrera profesional y tiene, usualmente, menos de dos años de experiencia en el rubro. Suele necesitar ayuda para llevar a cabo algunas tareas y tiene mucha capacidad de aprendizaje.
  • Semi senior: Aquella persona que cuenta entre 2 a 6 años ejerciendo su profesión de forma ininterrumpida. Es autosuficiente y tiene un buen manejo de sus herramientas y habilidades de trabajo.
  • Senior: Es una persona que cuenta con más de 6 años de experiencia en el rubro, toma decisiones sin necesidad de supervisión e incluso puede capacitar a otras personas.

Aunque, como dije, estos niveles no son un estándar. Y suelen ser algo subjetivo y coyuntural de la empresa en cuestión. Le puedes preguntar a dos personas del mismo área "qué es un Semi senior" y de seguro te contestarán cosas distintas. De hecho hay empresas en la que no se habla de ‘Semi Senior’, sino de ‘intermediate’ o de un ‘Mid-Level’. También dependerá del país, por ejemplo en Brasil se suele tratar a los ‘Semi senior’ como ‘Pleno’. Incluso, empresas referentes en informática como Google, Apple, Amazon o Microsoft no manejan esos niveles en sus planes de carrera.

Aunque la mayoría de empresas notables en el mundo de la tecnología tienen sistemas de nivelación claramente definidos, todavía hay inconsistencias en los niveles entre las empresas. Por ejemplo, Google y Apple tienen ocho niveles en su escala de ingeniería de software, mientras que Amazon tiene seis, Facebook siete y Microsoft trece.


En general, las empresas establecidas expresan los niveles en función del impacto y complejidad que el candidato aporta a la organización. Por ejemplo, cuanto más alto es el nivel, mayor es el impacto y complejidad a que el profesional se enfrenta. Con base en este enfoque, una buena descripción estándar de niveles de carrera es la descrita por Levels.fyi. Esta startup usa datos para decodificar los oscuros “niveles” utilizados por las distintas empresas de tecnología para clasificar los trabajos. En su clasificación estándar de ingenieros de software define los niveles: Entry Level Engineer, Software Engineer, Senior Software Engineer, Staff Engineer, Principal Engineer y Distinguished Engineer.


  • Entry Level Engineer (Junior): Desarrolla y mantiene componentes de menor complejidad con la orientación y el apoyo de miembros del equipo experimentados.
  • Software Engineer (Semi senior): Desarrolla y mantiene componentes de complejidad baja a moderada trabajando en equipo. Recibe una cantidad mínima de orientación y apoyo de sus compañeros de alto nivel.
  • Senior Software Engineer (Senior): Desarrolla y mantiene componentes moderados a complejos. Posiblemente liderar un pequeño equipo o proyecto. Capacidad para asesorar a otros ingenieros, proporcionar orientación técnica, revisiones de códigos, diseñar y entregar proyectos pequeños de principio a fin. El impacto suele estar en el ámbito inmediato del equipo. Esto generalmente se considera un “nivel de carrera”, ya que puede pasar el resto de su carrera operando en este nivel.
  • Staff Engineer (Senior Advanced): Se espera que lidere y sea propietario de iniciativas técnicas complejas. Comenzar a establecer la visión/dirección futura del equipo. Impacta en múltiples equipos relacionados dentro de una organización. El rol cambia más hacia el diseño que hacia la implementación, según el tamaño o las expectativas de la empresa.
  • Principal Engineer (Principal): El impacto se extiende a través de las organizaciones. Encargado de proyectos críticos para el negocio y para establecer la visión técnica para una organización o varias organizaciones. Responsable de revisar y proporcionar comentarios sobre diseños técnicos en una organización. Poca o ninguna codificación diaria. El rol depende en gran medida de las necesidades de la organización o de la empresa y se vuelve vagamente definido. Se espera que funcione de forma totalmente autónoma.
  • Distinguished Engineer: El impacto se extiende por toda la empresa y, a veces, por la industria.

¿Y qué sobre la cantidad de años de experiencia? Aún más subjetivo. Si ya es difícil ponerse de acuerdo en cómo categorizar, menos habrá consenso en determinar la experiencia en años de cada nivel.

Cabe aclarar que no sumamos toda la trayectoria recorrida a lo largo de la vida, sino que contabilizamos cada puesto o perfil ocupacional por separado. Una cosa es Analista Funcional y otra Ingeniero de Datos, son cantidades de años de experiencia distintas. Y se pueden ver como seniorities distintos. Aunque algunas empresas directamente tratan a todos como Software Engineer y suman la experiencia dentro de la empresa. Pero las empresas IT que hacen micro-clasificación tienen cierta particularidad, porque normalmente no cuentan sus años de experiencia como programador, por ejemplo, sino los años en los que maneja determinada tecnología o determinado lenguaje de programación. Así, pueden considerar a alguien como Sr. desarrollando en .Net, pero Jr. en Java, aún cuando en ambos casos es programador. O incluso un ‘Software Engineer Senior’ puede ser Junior en un determinado stack tecnológico (como MERN, J2EE, LAMP, etc.) o lenguaje de programación. O sea que los niveles y años de experiencia se pueden usar tanto para planes de carrera (‘path de carrera’) como también para nivel de experticia en un campo o tecnología dado.

Como pudimos ver, es realmente incorrecto asumir que hay una X cantidad de años que se corresponda con un determinado seniority. Aunque la experiencia en años es solo una variable más, que por sí sola no nos dice nada. Aunque ayuda a evaluar otras aptitudes o características más importantes. Pero… ¿cuáles? Hasta el momento vimos las variables de impacto, autonomía y complejidad. Cuanto mayor seniority, más años de experiencia, mayor impacto, autonomía y complejidad.

Un modelo que puede ayudar para analizar habilidades y competencias es el modelo Dreyfus. El mismo analiza el conocimiento (Knowledge), el estándar de trabajo (Standard of work), la autonomía (Autonomy), cómo se afronta la complejidad (Coping with complexity) y la percepción del contexto (Perception of context). Si bien el modelo de Dreyfus usa otras categorías de seniorities, de todos modos se pueden cruzar estas variables de competencias con los grados de escalafón o seniorities que te plantees.




También se pueden agregar habilidades blandas y sumamos la cereza al pastel y así puedes crear tu propio modelo de niveles de seniority y tu propio modelo de madurez de desarrollo profesional. Como un camino de artes marciales donde llegamos al cinturón negro cuando llegamos a ser ‘principal’.

Una habilidad blanda relevante es el liderazgo. El liderazgo está parcialmente relacionado a la autonomía. Cuanto mayor seniority, mayor autonómia y mayor capacidad de liderazgo. Solo que se trata de liderazgo ejemplar. El de liderar a otros profesionales, principalmente desde el ejemplo y referencia técnica. No todo tipo de liderazgo se correlaciona con el seniority (por ejemplo el carismático). También puede suceder que una profesional con seniority muy alto no sea un buen líder. Por esta razón el liderazgo no debería ser un seniority, sino que es más bien parte de un perfil o rol.

Por último, me gustaría comentar que los niveles del seniority no solo aplican para desarrolladores de software o ingenieros de software, en realidad aplica para cualquier perfil profesional, inclusive para el management. 

Espero que este artículo te haya servido para despejar alguna duda respecto a los seniorities y fue una excusa para mostrar un modelo de seniorities que uso en algunas oportunidades.


Referencias: