Empleos tecnológicos líquidos
Empleos tecnológicos líquidos
En nuestro artículo de marzo queremos hacer una reflexión sobre las "sociedades líquidas" y su impacto en el empleo tecnológico.
Las sociedades líquidas
Las sociedades líquidas fueron definidas por el sociólogo Zygmun Bauman como aquellas que carecen de normas y estructuras sociales estables. En este contexto, los activos se transforman rápidamente en pasivos y esta situación afecta a activos tradicionales como los vehículos y las oficinas, pero también a los consultores y los empleos tecnológicos.
En el caso de los vehículos, el rápido avance tecnológico y la creciente regulación en torno a los motores de combustión hacen que la compra de un coche no tenga sentido a largo plazo, por lo que resulta más lógico optar por el renting.
De manera similar, en el caso de las oficinas, las empresas deben optar por el alquiler en lugar de la compra, ya que el rápido cambio tecnológico y la inestabilidad del mercado laboral dificultan prever las necesidades futuras de espacio.
Los empleos tecnológicos líquidos
Los consultores tecnológicos son el principal activo de muchas empresas tecnológicas. Sin embargo, el cambio acelerado puede igualmente convertir a este colectivo en un pasivo.
El desarrollo de nuevos productos tecnológicos puede convertir a grandes equipos multidisciplinares en un pasivo si el producto no consigue alcanzar las expectativas. De manera similar, cuando una empresa pierde una RFP para prestar servicios informáticos, algunos de los consultores pueden pasar al nuevo proveedor, mientras que el resto se convierte en un pasivo para su empresa.
Pero también los empleos tecnológicos pueden convertirse en una trampa laboral, si nuevas tecnologías se convierten en el nuevo estándar del mercado. Pensemos en los miles de consultores que todavía hacen el desarrollo evolutivo de sistemas mainframe y de escritorio, cuando la gran mayoría de las aplicaciones hoy en día se desarrollan para un navegador.
Hay que destacar igualmente la importancia de trabajar en varios proyectos y empresas para adquirir criterio sobre buenas y malas prácticas de gestión y liderazgo en ingeniería del software.
La aportación de las consultoras tecnológicas
En conclusión, vivimos en una sociedad líquida en la que los activos se transforman rápidamente en pasivos. Es importante que las empresas y los profesionales tecnológicos se adapten a este contexto y busquen una estrategia que les permita mantenerse competitivos en un mercado laboral en constante cambio.
En este entorno, puede ser importante la aportación de las consultoras tecnológicas, si dejan de ser meros 'proveedores de talento' y consiguen transformarse en 'agentes de desarrollo del talento'. Algo similar a los agentes de los deportistas de élite, que les acompañan en su carrera profesional y les aconsejan sobre su entrenamiento y el momento adecuado para enfrentarse a nuevos retos.
¿Cómo te irá en tu nuevo trabajo? (II)
¿Cómo te irá en tu nuevo trabajo?
En nuestro artículo de diciembre del 22, explicábamos que lo más importante de una oferta de trabajo es también lo más difícil de averiguar en una entrevista. La relación con tu nuevo jefe determinará el 70% de tu experiencia de empleado.
En el artículo de enero del 23, llegamos a la conclusión de que la mejor fuente de información sobre tu nuevo jefe son tus futuros compañeros, y explicamos qué preguntas hacerles. Lamentablemente no siempre vas a tener acceso a ellos.
En este artículo de febrero del 23, explicamos qué puedes preguntar durante una entrevista de trabajo a tu futuro responsable, para averiguar cómo será vuestra relación antes de estampar tu firma en el contrato.
¿Cuáles son las tres mejores preguntas que puedes hacer al líder del proyecto?
Vamos con las tres preguntas que, a nuestro entender, os aportarán mayor información, sin poner incómodo a vuestro futuro jefe.
1. ¿Qué funciones haces como líder del equipo?
Empezamos con una pregunta trampa, para dejarle que se luzca y que hable de si mismo.
Eres un profesional, solo quieres conocer el rol de tu nuevo jefe y la cultura de la organización.
Es el Product Owner
Si su respuesta es:
- Yo no soy un técnico, solo resuelvo las dudas funcionales de los consultores.
- Priorizo las actividades del sprint
Tu nuevo líder es un Product Owner. La empresa ha alcanzado un buen grado de madurez en metodologías ágiles y Scrum.
El cambio de trabajo es una apuesta segura.
Es el Jefe de Proyecto
Si responde algo así como:
- Me aseguro de que haya un buen ambiente de trabajo en el equipo.
- Negocio con el cliente para ajustar la carga de trabajo y que el equipo no se queme por exceso de horas extras.
Es un Jefe de Proyecto que tiene claras sus funciones.
Un buen comienzo de una nueva relación laboral.
Es el Líder Técnico
Si está orgulloso de decir:
- Explico a cada consultor qué es lo que tiene que hacer y cómo hacerlo.
- Superviso que están efectivamente haciendo aquello que les he pedido y les ayudo si están atascados.
Es un Líder Técnico. Su experiencia puede ayudarte a crecer profesionalmente, pero si nadie bloquea la presión del cliente, el proyecto tarde o temprano se transformará en un infierno.
Ten cuidado.
Es un Analista/Programador
Si tiene aspecto cansado y su respuesta es:
- Soy el consultor más veterano del grupo.
- Además de mi trabajo técnico, te ayudaré a irte poniendo en marcha.
Es un Analista/Programador. Esta figura es garantía de problemas.
Para empezar, tiene que elegir entre realizar su trabajo técnico y liderar al equipo. Haga lo que haga, el rendimiento general será bajo, así que la presión del cliente será elevada. Y no hay nadie para bloquearla.
Ten cuidado.
El rol del líder aporta mucha información sobre el grado de madurez de la organización.
2. ¿Qué KPIs utilizas para medir el desempeño?
Me encanta porque es una pregunta de aspecto inocente. Aparentemente quieres conocer los criterios que más valora porque quieres hacer un gran trabajo.
En realidad le estás preguntando por su cultura X (Fixed Mindset) vs Y (Growth Mindset).
Aquí no hay respuestas mejores o peores. Lo importante es conocerte a ti mismo, y que tu cultura sea compatible con la suya.
"No uso KPIs, intento motivar a mis consultores con formación y proyectos que son un desafío tecnológico"
Posiblemente estás hablando con un Líder Técnico con una cultura de tipo Y. En general todos los programadores también tienden a tener cultura Y.
Si tu también crees que al trabajador hay que motivarle todos los días mediante formación, desafíos tecnológicos, feedback positivo y un gran ambiente de trabajo, tu cultura es Y. Os llevaréis genial.
"Los KPIs que utilizo para medir el desempeño de los consultores son..." o "Los criterios para establecer nuestros bonus por objetivos son...".
Seguramente estás hablando con un Jefe de Proyecto de cultura X o Fixed Mindset.
Si tu también crees que los profesionales deben venir formados y motivados de casa, que el bonus por objetivos es la mejor forma de motivar a un consultor, y que al trabajo se viene a trabajar y no a tomar café, tu cultura también es X. Tendrás una buena relación profesional con él. A lo mejor hasta os hacéis amigos.
Recuerda, X no es mejor que Y. Lo importante es que tu cultura coincida con la del líder del proyecto.
3. ¿Cómo gestionáis los picos de trabajo?
Eres un profesional. Sabes que eventualmente habrá picos de trabajo por incidencias en planta o por deadlines. Forma parte de nuestra actividad y lo asumes. Solo quieres conocer cómo se gestionan esas situaciones.
Hay varias respuestas posibles, de nuevo de mejor a peor.
"Aquí no hay presión porque hacemos SCRUM. Las historias de usuario que no se completan durante el sprint, se devuelven al backlog"
Es posiblemente la mejor respuesta.
Tu nuevo jefe es un Product Owner. La organización tiene un elevado grado de madurez en la metodología Scrum y no comete los errores típicos de los principiantes.
Posiblemente te mostrará el tablero canvan con los epics e historias de usuario del backlog, y el progreso de las tareas en el sprint actual. Incluso es posible que te presente a tus futuros compañeros.
Un diez.
"Intento que no haya presión, pero de vez en cuando hay momentos de crisis. Entonces hablo con el equipo y ellos se organizan para solucionarlo".
Otra buena respuesta.
Estás ante un Jefe de Proyecto que entiende que su principal misión es bloquear la presión del cliente.
Pero eventualmente son necesarios esfuerzos puntuales. El hecho de que el equipo sea capaz de autogestionar estas situaciones indica que hay un buen ambiente de trabajo. Posiblemente se ha formado un equipo de alto rendimiento.
Un nueve alto.
"Hay bastante presión al final de cada sprint para acabar todas las historias de usuario planificadas"
La organización está haciendo la transición hacia metodologías ágiles.
Cometen los errores típicos del comienzo del proceso, pero eventualmente se convertirán en un buen sitio para trabajar.
Un seis.
"Cuando hay momentos de crisis, hablo con el equipo y les pido un sobreesfuerzo para lograr los objetivos".
Cuando exiges a todo un equipo un sobreesfuerzo, siempre hay alguien con hijos que no puede mantener el ritmo. El conflicto está servido. Adiós al ambiente de trabajo.
El liderazgo es débil y no consigue bloquear la presión del cliente. Es cuestión de tiempo que esos momentos de crisis se conviertan en el día a día.
Un cuatro y medio.
"Llevamos tres meses haciendo un sobreesfuerzo, por eso te contratamos"
Es sin duda la peor de las respuestas.
El proyecto acumula varios meses de retraso, el cliente está muy nervioso y el líder del proyecto no sabe como bloquear la presión. Posiblemente han entrado en una dinámica de lluvia ácida...
El líder del proyecto desconoce los conceptos básicos de gestión de proyectos tecnológicos:
- El 70% de los proyectos a nivel mundial multiplica por tres su plazo de ejecución o se cancela. El caos es el estado natural de los servicios tecnológicos.
- A más presión, menos talento. Incrementando la presión, el líder del proyecto está destruyendo el talento justo cuando más lo necesita.
Un dos.
En resumen
Un cambio de trabajo no debería ser un acto de fe, pero en demasiadas ocasiones damos este paso a ciegas.
Para cubrir ese vacío, arrancamos esta serie de artículos hace ya tres meses a partir de un #ThinkingBreakfast con el equipo de novanotio. Esperamos que estas reflexiones os sirvan de guía durante toda vuestra carrera profesional.
Nos vemos de nuevo en el artículo de marzo de 2023.
El peor escenario para un proyecto informático es la lluvia ácida
El peor escenario para un proyecto informático es la lluvia ácida
El peor escenario para un proyecto informático no es que vaya con mucho retraso. O que multiplique por tres el coste presupuestado. O que el cliente esté muy enfadado.
Eso ocurre en el 80% de los proyectos, tal como anticipa Pareto y nos confirma The Standish Group en sus informes 'Chaos Report'
El peor escenario para un proyecto informático es la lluvia ácida. Y el Jefe de Proyecto es el único responsable.
Bienvenido a una sesión de méntoring de novanotio.
La lluvia ácida
Pero, ¿Qué es la lluvia ácida? Es la situación en que la resolución de incidencias interrumpe continuamente los trabajos de desarrollo.
Por supuesto, siempre hay incidencias en los entornos de producción. Por eso hay equipos de operaciones encargados de monitorizar los procesos, levantar las aplicaciones o corregir entradas inconsistentes en las bases de datos.
Cuando el equipo de operaciones no es capaz de restablecer el servicio, se produce una incidencia crítica que el equipo de desarrollo debe atender de manera urgente.
De la atención de incidencias a la lluvia ácida
Todos los desarrolladores hemos tenido que atender incidencias de producción en algún momento.
El problema aparece cuando esas incidencias son tan frecuentes que fagocitan el tiempo del equipo de desarrollo. He visto grupos dedicar mas del 70% de su jornada a solucionar incidencias.
Cómo se origina la lluvia ácida
La lluvia ácida tiene la misma dinámica que la bola de nieve que rueda ladera abajo. Crece y crece hasta convertirse en un monstruo ingobernable.
Es sencillo entender el hilo de pensamientos del Jefe de Proyecto que desemboca en esta situación:
- Quiero que mi cliente esté satisfecho.
- Y necesito que el proyecto no se retrase todavía mas.
- Así que, tenemos que solucionar rápidamente esta incidencia de producción.
- Y, además, hay que cumplir la planificación que hemos acordado.
Es una línea argumental con la que todos estaríamos de acuerdo, salvo por dos importantes detalles:
- Hagas lo que hagas, el 80% de los proyectos multiplicarán por tres su plazo y su coste. Lo predice Pareto. Lo confirman año tras año las estadísticas de nuestro sector. No puedes escapar del principio de Pareto como no puedes escapar de la ley de la gravedad.
- La cuarta ley nos advierte que alcance, plazo y calidad están interrelacionados, de forma que si fijas dos de ellos el tercero se degrada. Si mantienes el plazo y amplías el alcance (todo lo planificado más la resolución de las incidencias), la calidad se degrada.
La lluvia ácida aparece cuando sacrificas la calidad
El origen de la lluvia ácida es un Jefe de Proyecto que, presionado por su cliente, sacrifica la calidad.
Ese código desarrollado a toda prisa y que se pone en producción sin apenas pruebas, va a generar nuevas incidencias en producción, que poco a poco, van a consumir el tiempo disponible para el desarrollo.
Por eso, introduciendo presión en el equipo de desarrollo, no aceleramos los trabajos, sino todo lo contrario.
Por no hablar del incremento de la rotación, que aparecerá como un nueva causa de retrasos del proyecto.
Cómo soluciona Scrum el problema de la lluvia ácida
Scrum soluciona el problema de la lluvia ácida mediante dos mecanismos.
- El primero consiste en planificar dentro de cada sprint un cierto tiempo para atender incidencias en producción.
- El segundo es obligar a que sólo se entreguen al cliente los desarrollos que superen las pruebas funcionales.
Scrum asume que hay que atender incidencias y que no se van a completar todos los trabajos planificados para el sprint. Pero se asegura que aquello que se entregue esté convenientemente probado.
Scrum evita la aparición de la lluvia ácida asegurando la calidad.
Y para asegurar la calidad sacrifica el alcance . Es decir, aplica la cuarta ley de gestión de proyectos informáticos.
Resumen
La posición de Jefe de Proyecto no es sencilla. Con independencia de tu experiencia o la de tus desarrolladores, el 80% de tus proyectos van a sufrir importantes retrasos y sobrecostes.
Si intentas acelerar los proyectos metiendo presión a tus equipos, vas a empeorar la situación.
No solo ralentizarás los desarrollos porque los programadores están cansados. Aparecerán efectos de segunda ronda como la lluvia ácida y la rotación, que dilatarán todavía más tu planificación.
Si has seguido las sesiones de méntoring de novanotio, ya sabes cómo evitar la aparición de la lluvia ácida:
- Garantiza la calidad, sacrifica el alcance (4ª ley de gestión de proyectos informáticos).
Y además:
- Quita presión a tus equipos de trabajo (3ª ley de gestión de proyectos informáticos).
- Prioriza los desarrollos que mas valor aportan (Principio de Pareto).
- Y gestiona las expectativas de tu cliente (1ª ley de gestión de proyectos informáticos).
La metodología Scrum puede ayudarte a conseguir todos estos objetivos.
Gracias por compartir el artículo si te ha parecido interesante y nos vemos en la próxima sesión de méntoring de novanotio.
¿Cuál es la jornada laboral más adecuada para el sector tecnológico?
¿Cuál es la jornada laboral más adecuada para el sector tecnológico?
El debate sobre la jornada laboral
La pandemia y la escasez de talento en el sector tecnológico han reavivado el debate sobre la jornada laboral y el teletrabajo.
Esta discusión corre paralela a los cambios que están experimentando las sociedades occidentales, con la progresiva desaparición de los empleos industriales.
Es una paradoja. Mientras en nuestro sector lo que faltan son profesionales y el problema es cómo retenerles, en todos los demás lo que escasea es el trabajo, así que el problema es cómo redistribuirlo. Distintos casos, ¿una única solución?
En este artículo vamos a analizar cual sería la jornada laboral más adecuada para el sector tecnológico, usando las mismas técnicas de gestión de proyectos que enseñamos a todos nuestros consultores.
Bienvenido a una sesión de formación de novanotio.
La jornada laboral y la segunda ley
La segunda ley de gestión de proyectos dice 'One Project, One Team, One Site'.
Esta ley pone de manifiesto la importancia de las relaciones personales en el mundo de la tecnología. Esto es especialmente cierto en el desarrollo de software, pero aplica por igual al resto de ámbitos de nuestro sector.
Para completar tu trabajo, necesitas la aportación de otros consultores que tienen una lista interminable de tareas pendientes. La mejor -la única- forma de que te atiendan rápido es que seáis buenos amigos. Y estos vínculos emocionales solo se forjan con el contacto directo y cotidiano.
En resumen, el trabajo presencial es muy importante.
La jornada laboral y la tercera ley
La tercera ley de gestión de proyectos dice Presión x Talento = Constante.
¿No os ha ocurrido que un problema que no podéis resolver en ocho horas, a la mañana siguiente lo resolvéis en cinco minutos?
Eso es talento.
Y Putnam, después de muchos años de investigación para el gobierno americano, llegó a la conclusión de que los proyectos sólo avanzan con esos 'Momentos de Talento'.
La tercera ley constata que cuantas más horas trabajes, más cansado vas a estar, menos momentos mágicos vas a tener y más despacio van a avanzar tus proyectos.
Desde este punto de vista, una jornada continua de cinco o seis horas al día sería la ideal.
La jornada laboral y el estado de flujo
En nuestro sector, el máximo rendimiento se consigue en estado de flujo, esa agradable sensación que experimentas cuando estás totalmente concentrado en tu trabajo y pierdes la noción del tiempo.
En las condiciones adecuadas puedes conseguir tres o cuatro horas diarias de concentración ¿Cómo podemos maximizar ese tiempo?
- Necesitas silencio y un entorno sin distracciones, algo que se ha perdido con las praderas abiertas y los dispositivos móviles.
- Además, si tienes que ir a la oficina, desperdicias la hora más productiva del día conmutando.
- No tiene sentido madrugar, porque si estás cansado no te concentras (tercera ley).
- Es imposible concentrarse después de comer, porque la sangre está en el estómago ayudando a la digestión y no en el cerebro.
Podemos sacar dos conclusiones: El teletrabajo es mejor que la jornada presencial, porque puedes levantarte más tarde, estás en un entorno más silencioso y, sobre todo, no tienes que ir y volver de la oficina. La jornada continua es mejor que la jornada partida.
La jornada óptima teórica para nuestro sector
Aplicando todo lo anterior, la jornada perfecta para el sector tecnológico sería una combinación de actividad presencial y teletrabajo, en una jornada continua de treinta horas.
En teoría, la jornada continua de 30 horas es preferible sobre la jornada de cuatro días semanales. Si solo puedes concentrarte unas tres horas al día, con la jornada de cuatro días pierdes el 20% de tu tiempo productivo.
Ambos esquemas de jornada reducida (jornada continua y jornada de cuatro días) te ofrecen más tiempo para descansar. Los días de trabajo presencial favorecen la coordinación y la formación de vínculos emocionales. El teletrabajo te aporta días de mayor concentración.
Olvídate del café. Las nuevas herramientas de mejora de la productividad individual son el descanso, la risa, el silencio, la meditación y los deportes de riesgo.
Los problemas de la jornada continua de 30 horas
Hemos visto que la jornada que mejor se adapta a nuestro sector es la jornada continua de 30 horas con teletrabajo parcial. Varias empresas han intentado adoptar este esquema, pero los intentos han fracasado. Paradigma Digital lo intentó en 2016 pero tuvo que volver a la jornada normal en 2018. ¿A qué se debe esto?
En todos los casos, la adopción de la jornada continua mejoró la productividad individual y la satisfacción de los trabajadores. ¿Qué fue entonces lo que empujó a las empresas a dar marcha atrás? ¿Por qué esa mejora de la productividad individual no se tradujo en una mejora de la competitividad empresarial?
Varios factores pueden explicarlo:
Gestión de los esfuerzos puntuales.
Con una jornada reducida, ¿Qué sentido tiene hacer sobreesfuerzos? ¿No estamos montando todo este esquema para tener mas tiempo libre?
Ante una crisis puntual, es sencillo prolongar la jornada tradicional hasta las 50 o 60 horas semanales. Pero en la jornada continua, la comida marca una frontera muy clara entre trabajo y descanso.
Uno de los requisitos para el éxito de cualquier jornada reducida es que los clientes no sufran impacto en la calidad del servicio. Es inadmisible que no se puedan atender crisis por las tardes porque no queda nadie trabajando.
Esto puede explicar el éxito relativo de los esquemas de cuatro días frente a los de jornada reducida. Igualmente se reducen las horas semanales, pero es más sencillo gestionar incidencias y crisis. Solo tienes que pedir a la mitad del equipo que trabaje de lunes a jueves, y a la otra mitad que lo haga de martes a viernes.
Capacidad del equipo de management
La principal función de la dirección y los mandos intermedios es el control y seguimiento de los procesos mediante interminables reuniones. Si la plantilla no está operativa, no se pueden reunir con nadie.
Este es uno de los problemas que las empresas reportan de forma recurrente. Con la jornada continua de 30 horas, los gestores pierden buena parte de su capacidad de dirección. La lista de problemas pendientes crece hasta hacerse ingobernable.
Aquí también funciona mejor la jornada de cuatro días. Los gestores siempre tienen al menos a una parte de la plantilla disponible para reuniones.
Apoyo tecnológico a compañeros y otros equipos
Este punto es parecido al anterior, pero aplicado a los expertos tecnológicos.
Como hemos visto, una hora de la persona que mejor conoce el problema puede ahorrar semanas de esfuerzo a todo un equipo. Aquí es donde hay que buscar los incrementos de productividad. Si solo haces tu labor técnica sin relacionarte con nadie, puede que seas muy productivo individualmente, pero la empresa pierde competitividad.
Las horas de baja productividad son la ocasión perfecta para ayudar a los compañeros, formar a los recién incorporados o aportar tu conocimiento en otra de esas aburridas reuniones con jefes de proyecto.
Resumen
El trabajo técnico tiene muchas facetas:
- Tu trabajo técnico.
- Atención a crisis e incidencias puntuales.
- Apoyo a los compañeros.
- Creación y clarificación de la especificación.
- Desarrollo de vínculos emocionales.
- Apoyo a la dirección.
- ...
El desafío es encontrar un esquema que permita desarrollar todas ellas disminuyendo la carga de horas semanales.
En teoría debería funcionar la jornada continua de 30 horas, combinando teletrabajo y actividad presencial. En la práctica se están consiguiendo mejores resultados con la jornada de 4 días.
¿Acabaremos teniendo fines de semana de tres días?
Cultura de una empresa. Fixed Mindset vs Growth Mindset
Cultura de una empresa. Fixed Mindset vs Growth Mindset
En este artículo vamos a ayudarte a diferenciar las dos principales culturas de empresa que existen, Fixed Mindset y Growth Mindset, y en cuál encajas mejor.
Es importante que conozcas cómo eres, porque encajarás mejor en empresas con una cultura similar a la tuya. Si te equivocas, te encontrarás a disgusto con cada decisión, pensarás que lo hacen todo al revés y terminarás quemado.
La buena noticia es que puedes adivinar la cultura de una organización antes de firmar un contrato laboral. Aquí te damos pistas de cómo hacerlo. ¡Tienes que estar muy atento a los comentarios de tus futuros jefes y compañeros!
1. Concepción del talento.
Los partidarios de la cultura Fixed Mindset creen que el talento es innato. Los reconocerás por la frase ‘puedes enseñar a trepar a un pavo, pero es mejor contratar a una ardilla’. Los Fixed Mindset contratan talento.
Los defensores de la cultura Growth Mindset creen que el talento se desarrolla. Defienden que cuanta más formación reciben sus colaboradores, mejor desempeñan su actividad. Los Growth Mindset desarrollan el talento de sus equipos.
2. Formación
Los Fixed Mindset piden certificaciones de los conocimientos técnicos.
Los Growth Mindset invierten su tiempo con sus colaboradores hasta que son capaces de trabajar de manera autónoma.
3. Liderazgo
Los Fixed Mindset utilizan sistemas de castigo y recompensa. El bonus por objetivos es su herramienta para mejorar los resultados.
Los Growth Mindset utilizan la motivación, la confianza y los desafíos. El feedback positivo es su herramienta para incrementar la productividad.
4. Si los proyectos van retrasados…
Los Fixed Mindset exigen un sobresfuerzo al equipo,
Los Growth Mindset protegen a su equipo y gestionan las expectativas del cliente. Es frecuente que el equipo decida quedarse unas horas sin que nadie se lo pida.
5. Motivación
Los Fixed Mindset creen que los buenos profesionales vienen formados y motivados de casa.
Los Growth Mindset saben que a los buenos profesionales hay que formarles y motivarles todos los días.
¿Es Growth Mindset mejor que Fixed Mindset?
Es obvio que ambas culturas de empresa, Fixed Mindset y Growth Mindset, son muy diferentes, pero, ¿es mejor una que otra?
Definitivamente no. La cultura Growth Mindset no es mejor que Fixed Mindset ni viceversa. Hay fantásticas compañías de ambos tipos. Lo importante es que tengas claro en cual encajas mejor. En este artículo de nuestro blog te ayudamos a descubrir cómo eres usando el test de Gallup.
Sin embargo, hay actividades donde un enfoque parece más adecuado que el otro.
Como norma general, si el resultado obtenido es proporcional al tiempo de trabajo, como ocurre en las fábricas, el modelo Fixed Mindset funciona con notable eficacia.
Si por el contrario, no hay relación directa entre el tiempo empleado y el resultado obtenido, como en el desarrollo de software, es más conveniente el enfoque Growth Mindset.
Enlaces de interés
Esta discusión entre Fixed Mindset y Growth Mindset es sólo la punta del iceberg sobre cultura empresarial. El libro más completo que he encontrado sobre el tema es ‘Brave New Work’ de la consultora americana The Ready.
Te invito también a que descubras en este enlace cómo una pobre cultura empresarial puede destruir equipos y desmotivar a los trabajadores.
¡Suerte en tu aventura profesional!
¿Qué diferencia a un empresario de un emprendedor?
¿Qué diferencia a un empresario de un emprendedor?
Puedes perder mucho dinero si estás pensando en emprender y no conoces la diferencia entre un empresario y un emprendedor.
Eso le ocurrió a algunos de nuestros ex-consultores. Profesionales brillantes, con buenas ideas y excelente capacidad de desarrollo, que se lanzaron al mundo del emprendimiento. Crearon fantásticas start-up pero las gestionaron como si fueran empresas. Y descubrieron por las malas la diferencia entre empresarios y emprendedores.
Por eso hemos añadido esta sesión a nuestro proceso de mentoring Novanotio Certified. Para preparar a los consultores de novanotio que en algún momento de su carrera decidan crear su propia start-up.
Son tres ideas muy sencillas, pero por su transcendencia nos ha parecido importante compartirlas con la comunidad tecnológica.
Lo que dicen otros post sobre las diferencias entre emprendedores y empresarios
Hay centenares de post sobre este tema, algunos francamente buenos, pero no aciertan a poner el dedo sobre la llaga correcta.
Una forma de diferenciarlos suele ser argumentando que un empresario está trabajando en un entorno conocido en el que ya hay un mercado definido y una competencia y un emprendedor es aquel que abre un nuevo camino, en el que no hay competencia y trabaja contra la incertidumbre.
Otra de las diferencias que se marcan habitualmente es la innovación pero ¿Podemos decir que ningún empresario innova cuando monta una empresa?
A veces lo que se tiene en cuenta es el tiempo. Emprendedor sería alguien que monta un negocio que antes no existía y empresario es el que tiene un negocio desde hace años, pero ¿Cuándo pasaría un emprendedor a ser empresario? ¿Cuándo hubiesen pasado 2 ó 3 años? ¿Cuándo el negocio esté consolidado?
Quizás la definición más aproximada que he encontrado propone que el empresario trabaja para conseguir beneficios, mientras que el emprendedor busca la transformación de la sociedad, ‘dejar huella en el universo’.
Los empresarios buscan beneficios, los emprendedores buscan financiación
La verdadera -y peligrosa- diferencia entre emprendedores y empresarios es su definición de éxito.
Para un empresario, el éxito es la cuenta de resultados, PyG, EBITDA, bottom line, o como quieras llamar a los beneficios. Punto.
Apuesta su capital y crea una organización con el único propósito de ganar dinero año tras año.
Sin embargo, para un emprendedor, el éxito es cuánto dinero ha conseguido de los inversores. Punto.
Le da igual el volumen de negocio, el margen bruto, los beneficios o el número de usuarios.
La start-up de coches eléctricos Rivian pudo levantar seis mil millones de dólares y alcanzar el éxito sin hacer una sola venta, sin tener un sólo usuario y con pérdidas multimillonarias.
Cuando eres un emprendedor sólo vives para la siguiente ronda de financiación. Si consigues el dinero, dispones de unos meses mas. Si no lo consigues, mueres. Y la tasa de mortalidad es del 99%.
Los empresarios invierten su dinero, los emprendedores el de otros
Y esto es lo que repetimos una y otra vez a los consultores de novanotio . Si creas una start-up nunca la financies ni con tu tiempo ni con tu dinero. Si lo haces, lo estás tirando a la basura en el 99% de los casos. Eso no es riesgo, eso es certeza.
Si tienes una buena idea, busca financiación en el mercado de capital riesgo. Si no lo consigues, o bien no eres un buen vendedor, o bien la idea no era tan buena. En ambos casos, has ahorrado un montón de tiempo, dinero y energía que estarán mejor empleados en tu familia y en tu hipoteca.
Los empresarios buscan el break-even, los emprendedores la venta de su start-up
El break-even es ese momento mágico en que los ingresos superan a los costes, y comienzan a generarse beneficios.
Pero recuerda, los beneficios son el coto privado de los empresarios. Los emprendedores no buscan beneficios, buscan inversores.
Cuando recibas la oferta adecuada, vende todas tus acciones y monetiza tu esfuerzo. Si rechazas la oportunidad porque quieres transformar tu start-up en una empresa, lo perderás todo en el 99% de los casos.
EL EXITO con mayúsculas es levantar tres o cuatro rondas de financiación y luego vender tu start-up a un gigante empresarial.
Entonces ¿Cómo ganar dinero en el mundo del emprendimiento?
Para ganar dinero en el mundo del emprendimiento solo hay dos caminos.
El primero es el que ya hemos comentado. Ten una idea. Encuentra financiación. Ponte un salario. Trabaja duro. Busca más financiación. Vende tu start-up. Si las cosas salen mal, alguien está pagando tu nómina. Si salen bien, das la campanada. El riesgo es de otros, el dinero tuyo.
El segundo es invertir en un centenar de start-ups. Por pura estadística una de ellas triunfará. Aparecerá una gran empresa dispuesta a comprar tus acciones. Las plusvalías cubrirán las pérdidas de los noventa y nueve fracasos y todavía quedará un buen pellizco para ti.
Para continuar sobre este tema
Dejo algunos enlaces internos a nuestra web que quizás te interese visitar si estás pensando emprender en el futuro.
El primero de ellos es a nuestro proceso de mentoring Novanotio Certified, en el que explicamos a nuestros consultores cómo gestionar proyectos, cómo liderar equipos, o como dirigir start-ups.
El siguiente es a nuestras ofertas de trabajo. ¿Te apetece continuar tu carrera profesional en uno de nuestros proyectos y participar en nuestro proceso de mentoring? Espero que encuentres alguna perfecta para ti.
Quiero preparar un artículo sobre aspectos morales del emprendimiento. Quizás estas ‘huellas en el universo’ están manchadas de barro. Si estás interesado en este tema, envíame tus opiniones a juandiego.lopez@novanotio.es.
Y por supuesto, te invito a que leas algunas entradas más de nuestro blog, en el que poco a poco estamos volcando nuestras experiencias de veinticinco años en el mundo de la tecnología.
Salidas profesionales de la ingeniería informática
Salidas profesionales de la ingeniería informática
En esta serie de artículos vamos a analizar las posibles salidas profesionales de la ingeniería informática.
Hemos incluido este tema en nuestro mentoring Novanotio Certified porque buena parte de los jóvenes consultores no tienen claro hacia dónde orientar su trayectoria. Quieren más responsabilidad y, por supuesto, quieren mas dinero. Pero no tienen claro a qué responsabilidad se refieren. Ni cuánto les va a costar ese dinero.
Cuando les preguntamos, la mayor parte responde que quieren llegar a ser ‘responsables de proyecto’ o ‘gurús tecnológicos’. Como veremos, hay varios tipos de ‘responsables de proyecto’. Y también algunos riesgos en la carrera de los ‘gurús tecnológicos’.
Estas son, a grandes rasgos, las cuatro posibles vías profesionales de los ingenieros informáticos.
La carrera tecnológica pura
Nunca te va a faltar trabajo.
Es la puerta de entrada. Todos empezamos programando, administrando sistemas o haciendo hacking ético.
Es también la trayectoria profesional más agradecida. Todos los años incrementas tus conocimientos y tu valor para el mercado. Cada vez eres capaz de asumir retos más complejos. Todas las semanas recibes docenas de ofertas laborales. Tengas la edad que tengas nunca te va a faltar trabajo. ¿No es genial?
Lo difícil de la carrera tecnológica es no salirse de ella. Frases como ‘Hazte cargo de estos becarios’ o ‘Acompáñame a visitar al cliente’ son resbaladizos toboganes por los que alejarte de la consola.
Con perseverancia, pasarás de Becario a Consultor Junior, Consultor Senior y, finalmente, Especialista Tecnológico. Hay algunos baches al final del camino, en este artículo te explicamos por qué tu salario como Especialista Tecnológico tiene un límite.
Los líderes técnicos
La carrera que se desvanece
El liderazgo tecnológico es una de las trayectorias preferidas por los jóvenes consultores. Diseñar los sistemas y ayudar a los equipos técnicos a construirlos.
Aquí se llega con poco de paciencia. Con la rotación de nuestro mercado, cuando llevas cuatro o cinco años desarrollando un módulo eres quien mejor lo conoce. Cuando se incorporan nuevos programadores, ¿quién mejor que tu para explicarles por dónde empezar?
¿Qué ocurre en el siguiente paso? Cuando te conviertes en el líder técnico de todo un gran proyecto, conoces muy bien tu módulo y desconoces todos los demás. Ya no puedes ayudar al resto del equipo en su labor técnica.
A partir de aquí, creces en el conocimiento funcional de los sistemas, pero desconoces los detalles de su implementación. Jefes de Programa, CIOs, CISOs y CTOs son líderes técnicos que cada vez saben menos de tecnología.
Por eso el liderazgo tecnológico es una carrera que se desvanece. En el proceso de desarrollo Scrum, la responsabilidad del diseño es de los squads de desarrollo. En buena parte de las empresas, los CIOs, CISOs y CTOs ya no reportan al CEO sino al director de operaciones.
Los gestores
A mayor responsabilidad, menor empleabilidad.
La carrera de gestión es la gran desconocida. En el imaginario colectivo, las funciones del Jefe de Proyecto se mezclan y confunden con las de los líderes técnicos. Buena parte de los gestores creen que su responsabilidad incluye el diseño funcional y la arquitectura del sistema. Error.
El Jefe de Proyecto es en realidad un firewall. Sus tres desconocidas funciones son:
- Cobrar al cliente cuando todavía queda muuucho por hacer.
- Proteger a los técnicos de la presión del cliente.
- Motivar a los consultores y mediar en sus conflictos.
Ya lo se. Si tenéis algo de experiencia, casi puedo escuchar vuestras risas según escribo estas palabras.
Como veis, son necesarias habilidades de psicología y negociación. Vuestros preciosos conocimientos técnicos no os van a servir de ayuda. Las únicas matemáticas que vais a usar son los tantos por ciento.
Por encima del Jefe de Proyecto aparecen las figuras del Gerente y finalmente el Director de Operaciones, también conocido como COO. Más capacidad de negociación, más tantos por ciento y menos ofertas de trabajo. En el área de gestión, a mayor responsabilidad, menor empleabilidad.
Las ventas
Aquí
En una empresa, no pasa nada hasta que alguien vende algo. La función de ventas es el motor de la empresa.
En este área son fundamentales las habilidades de comunicación y de influencia. Tu trabajo se resume en mirar a tu cliente a los ojos, señalar la línea de puntos y decir ‘aquí’. Si estampa su firma, te has ganado tu comisión y toda la empresa se pone en marcha.
Pero antes de esa firma sobre la línea de puntos tienes que superar algunos obstáculos.
- Debes convencerle de que tu organización posee los conocimientos para poder ayudarles. Te ayudará haber pasado unos años en el área técnica.
- Tendrás que mejorar los precios de la competencia. ¿Cómo pueden ir siempre por debajo de costes?
Llegará un momento en que, para conseguir tu comisión, aceptarás plazos imposibles y presupuestos ridículos. No vas a tener muchos amigos en el resto de la compañía.
Sobre Preventas, Business Analyst y Account Managers aparece el Director de Desarrollo de Negocio o CBDO. Su misión es consolidar los mercados ya conquistados y descubrir nuevos nichos de oportunidad. Todo un reto en un sector que está en permanente revolución tecnológica.
¿Qué carrera es mejor para mi?
Ahora ya conoces las cuatro salidas profesionales de la ingeniería informática. ¿Cómo decidir cual es la más adecuada para tí?
Los programadores estamos acostumbrados a la estrategia de prueba y error. Pruebas un área y, si no te gusta, vuelves a la programación.
No es tan sencillo. La responsabilidad es una droga que crea dependencia. Una vez que la has probado no es fácil dejarla. Conozco pocos casos en que, tras una mala experiencia, alguien haya solicitado un paso atrás.
En este artículo explicamos cómo descubrir qué carrera puede ser la mejor para ti, usando el test de fortalezas de Gallup. Quizás deberías leerlo antes de deslizarte por alguno de los toboganes.
¡Mucha suerte en tu aventura profesional!
Las cuatro leyes de la gestión de proyectos tecnológicos
Las cuatro leyes de la gestión de proyectos tecnológicos.
Estas cuatro sencillas reglas son la base de la gestión de proyectos tecnológicos.
Son solo 35 palabras, pero necesitarás algunos años para dominarlas y aplicarlas correctamente. Si deseas convertirte en un buen Jefe de Proyecto, serán tu credo. Apréndetelas de memoria y practícalas cada día.
1ª ley. Las especificaciones son inciertas, imprecisas e infinitas.
La primera ley es la responsable de que fracase el 80% de los grandes proyectos informáticos en todo el mundo. Esta cifra se mantiene estable desde los años 60 hasta hoy. Las nuevas herramientas de desarrollo y las diferentes metodologías no han conseguido mitigar este desastre.
Nos avisa de que el cliente no puede saber lo que quiere. Los sistemas informáticos son demasiado complejos. La especificación siempre estará incompleta. Por eso son inciertas.
Nos advierte de que no existe un lenguaje de alta precisión para comunicar las instrucciones técnicas. Los arquitectos disponen de los planos, un lenguaje de muy alta precisión. Los ingenieros informáticos sin embargo usamos el lenguaje natural, que es interpretable. Por eso son imprecisas.
Nos alerta de que un proyecto nunca termina. Siempre quedan errores que corregir y mejoras por implementar. ¿Alguna vez has puesto la última línea de código de un programa? Por eso son infinitos.
Cómo usar la primera ley:
- Especifica menos y haz más prototipos.
- Relaciónate más con tu cliente.
- No discutas el significado de un párrafo.
- ¡Haz que abone las facturas cuando todavía queda mucho por hacer!
2ª ley. One project, one team, one site.
Como el cliente no puede saber lo que quiere, y no disponemos de un lenguaje de alta precisión, las relaciones personales cobran especial relevancia.
La especificación se construye según avanzan los desarrollos, y los vínculos emocionales son la clave para distribuir ese conocimiento.
La segunda ley nos indica cómo construir esos vínculos. Los analistas funcionales, programadores, testers e incluso el cliente deben estar en la misma sala. Y mucho mejor si cada consultor trabaja en exclusiva para el proyecto.
Las software labs, las organizaciones matriciales y los equipos distribuidos son ineficientes.
Un apunte de Franz Hassmann, CTO de BBVA Next. Mejor si los equipos son pequeños, de entre 5 y 9 componentes.
3ª ley. Presión x Talento = Constante.
Durante miles de años hemos dirigido organizaciones gestionando la presión. Con el nacimiento de la informática necesitamos, por primera vez en la historia, gestionar el talento.
La tercera ley anticipa que si incrementas la presión de trabajo, disminuye el talento y los desarrollos se retrasan.
Así que olvídate de los bonus por objetivos y de exigir horas extras. Esas son herramientas de gestión de la presión.
Debes gestionar el talento. Ofréceles retos. Usa el feedback positivo. Bloquea la presión del cliente y deja que el equipo encuentre su ritmo de trabajo.
4ª ley. Alcance, Plazo y Calidad. Si fijas dos de ellas, la tercera se degrada porque es la variable de ajuste.
Recuerda, las especificaciones son infinitas.
Así que algo tienes que sacrificar. Puede elegir entre el alcance (entregar menos producto), el plazo (retrasar las entregas) o la calidad (entregar algo sin apenas pruebas).
La cuarta ley nos propone que alcance, plazo y calidad están interrelacionados. Si fijas dos de ellos, el tercero se degrada.
Nunca, nunca, nunca sacrifiques la calidad. Nunca fijes alcanzo y plazo.
SCRUM por ejemplo fija plazo y calidad, el alcance queda indeterminado. Se factura por cada sprint.
TIME & MATERIAL, los servicios profesionales de toda la vida, fijan alcance y calidad, y es el plazo el que queda indeterminado. Se factura mensualmente por el esfuerzo dedicado.
Si haces PROYECTOS CERRADOS, perderás dinero en el 80% de los contratos.
Enlaces de interés
Son solo cuatro reglas sencillas de aprender. Sin embargo, muchas organizaciones todavía preparan extensos documentos funcionales, deslocalizan parte de los equipos y trasladan la presión del cliente a sus desarrolladores.
Os dejo los enlaces a las fuentes de las cuatro leyes. Si comprendéis los fundamentos de cada una de ellas, os será más sencillo adaptarlas a vuestra organización.
La primera ley tiene su origen en ‘The mythical man-month’ de Brooks. Quizás el primer libro sobre ingeniería del software. Escrito a finales de los sesenta y una referencia obligada a día de hoy. Se complementa con ‘Introducción a la PNL’ de Seymour, un libro sobre psicología del lenguaje.
La segunda ley procede del fantástico libro ‘Peopleware’ de DeMarco. Posiblemente el primer ensayo sobre programación y productividad. Muy entretenido.
La tercera ley procede de un clásico sobre la motivación. ‘Drive’ de Daniel H. Pink. Igualmente divertido y ágil.
La cuarta ley procede tanto del libro de Brooks como de ‘Agile Software Requirements’ de Dean Leffingwell. No son fáciles ninguno de los dos, pero merece la pena el esfuerzo.
Te animo a compartir con todo nuestro sector tus experiencias en los proyectos en los que has participado. ¿Se han cumplido las cuatro leyes? ¿Añadirías alguna más?
¡Suerte en tu carrera de gestión de proyectos tecnológicos!
Fundamentos de SCRUM
Fundamentos de SCRUM
Es importante que domines los fundamentos de SCRUM si quieres implementar con éxito esta metodología.
Seguramente ya has leído libros y blogs que explican los diferentes procesos de SCRUM. El desarrollo en sucesivas iteraciones o sprints, el daily, el Sprint Planning, la retrospective, etc.
Si no conoces los fundamentos de SCRUM, lo mas probable es que cometas los mismos errores que la mayor parte de las organizaciones. Acabarás por implementar SCRUM como si fuera una religión y apenas conseguirás mejorar la productividad.
En novanotio defendemos que hay cuatro sencillas reglas que ayudan a gestionar con éxito los proyectos tecnológicos. Es una buena idea que revises nuestro artículo sobre las cuatro leyes antes de continuar con esta lectura.
En esta entrada vamos a analizar las relaciones entre las cuatro reglas básicas y los procesos de la metodología. Una vez que comprendas los fundamentos de SCRUM, estarás mejor preparado para implementarla en tu organización.
Relación entre SCRUM y la 1ª ley.
Las especificaciones son inciertas, imprecisas e infinitas.
La primera ley nos advierte tres cosas:
– Que el cliente no puede saber lo que quiere. El tiempo invertido en especificar suele ser tiempo perdido.
– Que una especificación redactada en lenguaje natural (castellano, inglés, alemán, etc.) es interpretable.
– Que no es posible finalizar los trabajos. Siempre queda algo por hacer.
¿Cómo responde Scrum a estos tres desafíos?
– El diseño es muy liviano; los requisitos se capturan en Epics, Features e Historias de Usuario, cuya extensión es de un párrafo.
– Para interpretar la especificación, se incorpora al squad un representante del cliente, el Product Owner,
– El Product Owner prioriza los trabajos para que el Retorno de Inversión sea el mayor posible, dentro del presupuesto.
Relación entre SCRUM y la 2ª ley.
One Project, One Team, One Site.
La segunda ley dice que para mejorar la productividad, todo el equipo de trabajo, incluido el cliente, debe estar en una única oficina y dedicarse en exclusiva al proyecto. La convivencia construye vínculos emocionales y relaciones de confianza que son imprescindibles.
¿Cómo construye Scrum los equipos?
En Scrum, los squads de desarrollo están formados por entre cinco y nueve consultores, cuyos puestos de trabajo están próximos entre sí. El Product Owner, que es el representante del cliente, es un miembro más del equipo.
Relación entre SCRUM y la 3ª ley.
Presión x Talento = Constante.
Talento y presión son antagónicos. Cuando uno crece, el otro disminuye.
La tercera ley nos recuerda que en el desarrollo de software debemos priorizar el talento sobre la presión. La velocidad de desarrollo depende del número de buenas ideas, no del número de horas de la jornada.
¿Cómo fomenta Scrum el talento?
Para eliminar la presión, en Scrum no es obligatorio completar todas las Historias planificadas para el sprint. Algunos desarrollos no superan los test y vuelven al backlog.
Relación entre SCRUM y la 4º ley.
El triángulo de Acero.
La cuarta ley nos enseña que Alcance, Plazo y Calidad están relacionados de tal forma que, si fijas dos de ellos, el tercero se degrada.
Tradicionalmente un contrato fija el alcance y el plazo. ¿El resultado? El 80% de los grandes proyectos son un fiasco.
Así que, como cliente, debes elegir entre:
– Sacrificar el Alcance. Ciertas funcionalidades no se construirán.
– Sacrificar el Plazo (y multiplicar el coste). El sistema se entregará muuucho mas tarde de lo planificado.
– Sacrificar la Calidad. El sistema tendrá errores en producción y será complejo de operar.
¿Qué variable sacrificamos en SCRUM?
La metodología SCRUM determina que la variable sacrificada es el Alcance.
La gran aportación de SCRUM es modificar la definición de éxito de un proyecto. Ya no tenemos que cumplir un alcance dentro de un plazo y con una buena calidad. Cosa que, por cierto, es imposible.
Éxito es conseguir el mayor retorno de inversión posible, dentro del presupuesto y en un plazo acotado.
¿Puedo mejorar la eficiencia sin usar Scrum?
Si conoces los fundamentos de Scrum, puedes utilizar los principios básicos de gestión de proyectos y mejorar el rendimiento de tus proyectos sin necesidad de implementar la metodología.
Pero SCRUM es la palabra de moda. ¡Aprende a implementar esta metodología y tu valor para el mercado se multiplicará!
Cómo orientar tu carrera profesional usando el test de Gallup
Cómo orientar tu carrera profesional usando el test de Gallup
En el entorno tecnológico es fácil tener una primera promoción
Estás haciendo un gran trabajo como programador, y como premio te han propuesto cambiar de actividad. Quizás te han pedido que lideres a un grupo de consultores. O tal vez que asistas a una reunión de ventas.
En el entorno tecnológico es fácil tener una primera promoción. Descubrirás que hay roles que te son tan naturales cómo respirar y otros en los que, a pesar de tu esfuerzo, sólo recibes disgustos. ¿Cómo saber si la jugosa manzana que te ofrecen está envenenada?
El test de fortalezas de Gallup
Vamos a estudiar cómo orientar tu carrera profesional usando el test de fortalezas de Gallup. Si todavía no lo has hecho tienes el enlace aquí. Considera estos veinte dólares como una de las mejores inversiones de tu vida.
Este test te descubre tus principales fortalezas, es decir, los tipos de talento que has desarrollado de forma natural. Gallup distingue entre treinta y cuatro fortalezas que se agrupan en cuatro ámbitos:
- Fortalezas de ejecución. ¿Qué es lo siguiente que tengo que hacer? Si tu única recompensa es un trabajo bien hecho o no puedes dejar una tarea a medias, eres un auténtico ejecutor.
- Fortalezas de pensamiento. ¿Cuál es la mejor forma de hacer las cosas? Si no puedes dejar de estudiar o tienes una potente capacidad analítica eres todo un pensador.
- Fortalezas de relación ¿Cómo construyo relaciones? Si rápidamente sabes cómo son las personas, o para ti lo más importante es el ambiente de trabajo, tienes este tipo de fortalezas.
- Fortalezas de influencia. ¿Cómo consigo convencer a los demás? Si siempre tienes en la boca la palabra adecuada considérate un influencer.
¿Qué fortalezas ayudan a desempeñar los distintos roles tecnológicos?
No todos los roles tecnológicos precisan de las mismas fortalezas. Según el resultado de tu test de Gallup, te sentirás más cómodo en unos u otros puestos.
Si tus fortalezas son de pensamiento y relación
En los primeros test de Gallup que realizamos, descubrimos que los mejores programadores combinaban fortalezas de pensamiento y relación.
Pronto nos dimos cuenta que, para programar, los vínculos emocionales son muy importantes, porque facilitan la construcción de las especificaciones y la coordinación de las tareas.
En resumen, si tus principales fortalezas son de relación y pensamiento, la programación se te dará bien de forma natural.
Si tus fortalezas son de pensamiento
Sin embargo, si la mayoría son de pensamiento, estarás más cómodo en roles con más complejidad y menos relación, como la administración de sistemas o la ciberseguridad.
Si tus fortalezas son de relación
Si tus fortalezas son sobre todo de relación, busca trabajos donde tengas que estar en contacto con el cliente. Los roles de soporte combinan una parte de conocimiento técnico y mucha relación con los usuarios de las aplicaciones y sistemas.
Si tus fortalezas son de relación e influencia
Si a las fortalezas de relación se suman las de influencia, tu sitio está en el área de ventas. Aquí tu misión es crear un vínculo con el cliente y convencerle de que ponga una firma. ¡Como pueden pagar esas comisiones por un trabajo tan sencillo!
Si combinas fortalezas de pensamiento e influencia
La combinación de pensamiento e influencia es interesante para liderar equipos. Te sentirás cómodo en las posiciones de Líder Técnico, Jefe de Proyecto o Gerente.
Si tus fortalezas son sobre todo de influencia
Cuantas más fortalezas de influencia aparezcan en tu test de Gallup, más cómodo te sentirás con cada ascenso. Director de Operaciones, CIO, CTO… El cielo es el límite.
Si la mayoría de tus fortalezas son de influencia, tu sitio está en la alta dirección. Algunos te llamarán trepa o pisacuellos. Bueno, quizás no has sido el mejor técnico, pero siempre sabes lo que tienes que decir. Y esas fortalezas te empujarán a los roles que empiezan por C.
¿En qué organizaciones encajarás mejor?
Si tus fortalezas son sobre todo de pensamiento, estarás más cómodo en organizaciones con cultura Growth Mindset.
Por el contrario, si son de ejecución o influencia, busca empresas de tipo Fixed Mindset.
En este artículo de nuestro blog analizamos las diferencias entre ambos tipos de liderazgo.
Alinea tu trayectoria con tus fortalezas
Cuando tu trayectoria profesional está alineada con tus fortalezas, te pagan por hacer lo que se te da bien de forma natural. En el caso contrario también puedes hacer un trabajo brillante, aunque a costa de un mayor esfuerzo y desgaste personal.
¿Quieres saber que actividades son mas adecuadas para ti? Envíame el resultado de tu test de fortalezas y te daré algunas ideas para orientar tu carrera.