«¿Talento es igual a formación? No, talento es igual a resultados. La gente de talento son los que aportan por encima de la media y lo demuestran sostenidamente con sus resultados.»
“Si queremos hacer más con menos, hay que innovar seriamente en la función pública, de otro modo, si se hace igual, con menos se obtiene menos.”
“ Es cierto que talento atrae talento y mediocridad atrae mediocridad. Salir de la espiral de la mediocridad es difícil pero se cae en ella con facilidad”
“Mala fama de los funcionarios: Tienen mala fama porque algunos pocos hacen mucho para ganársela a pulso y lo pagan la mayoría. … el sistema de presiones e incentivos es poco serio y muy antiguo. No se deja espacio a una meritocracia de verdad. La suma de seguridades, inercias y ortodoxias se impone a los que ponen todo, que los hay y muchos.”
““un país serio tiene un problema cuando la gente preparada no opta a la política”. ¿Por qué esto es así? ¿cómo empezar a transformar esta realidad? Empeñarnos tanto en que todos los políticos son ineptos y corruptos nos lleva a deteriorar la democracia. … La política está mal pagada, tiene horarios infinitos para muchos y una presión mediática no siempre desarrollada desde la mayor ética profesional. Está claro que hay políticos detestables, pero hay muchos otros que todavía se mueven por una lógica de servicio y que saben sortear dignamente las vanidades del poder. Necesitamos políticos de talla, sin ellos, no saldremos bien parados de este coyuntura.”
«comunicar es esforzarnos para que nuestros interlocutores puedan reproducir el esquema de lo que queremos decirles «. Comunicando «sabemos lo que pensamos, o simplemente, si somos capaces de pensar»
Y acabo con esta, que la podría haber firmado yo (se parece muchísimo a las cosas que digo desde hace más de 20 años)
“Hay que pregonar que hay que ir motivados de casa y que la labor de los jefes sea básicamente no desmotivar y ayudar a la gente a desplegarse alineadamente con la empresa. Motivarse es una responsabilidad individual, no desmotivar es una responsabilidad corporativa.”
Gracias a @UPV, @DOE, @VPT, y @Dadelos Charter el día 16 de junio 2022 participé en un evento de exteriores para reforzamiento de equipos de proyectos.
He intentado «aterrizar» lo observado durante la actividad de una de las tripulaciones para llevarlo al terreno del día a día de los proyectos en los que participo (muchos de ellos en la UPV; en todos ellos influyendo, tanto si lidero formalmente, como si influyo desde un rol menos destacado). Os comparto algunas reflexiones que espero que sirvan como lecciones aprendidas de la actividad.
En primer lugar, quiero contextualizar la actividad en el marco de participación en proyectos. Quizás algunas cosas de lo que hayamos aprendido se pueda aplicar a cualquier actividad laboral. No obstante, haré mis reflexiones pensando en proyectos que cumplan estas características:
Aunque parezca obvio, que sea un proyecto (no la cosas que se hacen en el día a día normal para hacer funcionar el servicio). Es decir, una agrupación de recursos (personas y otros recursos) durante un tiempo definido, con la finalidad de entregar uno o más «productos» (en el sentido más amplio de la palabra) que cumplan o superen las expectativas de las personas usuarias.
Tienen una duración de más de 4 semanas y necesitan la implicación de 3 o más personas
Afectan a un conjunto de personas interesadas y/usuarias internas (y puede que también externas)
Se llevan a cabo dentro de la UPV y pueden ser objeto de auditorias internas o externas
Precisan de una estructura de gobernanza y de unos roles y responsabilidades claramente establecidos
Requieren de una aprobación del alcance y del presupuesto del proyecto
Necesitan cierto nivel de control y trazabilidad
Puede ser necesaria la colaboración de varias organizaciones, o varias unidades organizativas
Incluye actividades adicionales a las de simple construcción/entrega
He agrupado las reflexiones en varios epígrafes.
Tantear el nuevo entorno
Los grupos estaban compuestos por personas que no todas se conocían. La UPV es una organización muy grande y muchas de ellas nunca habían interactuado entre sí. Otras no se habían visto nunca cara a cara, aunque podían haber intercambiado correos o hablado alguna vez por teléfono. De hecho, es posible que durante algún tiempo no sepas el nombre de las personas que te acompañan o la unidad en la que trabajan o las tareas que realizan (una ronda de presentaciones breves suele resolver esta situación).
Esto condiciona las primeras intervenciones en el grupo. Es más probable que haya gente reticente a dar su opinión, o a asignarse un rol, o prestarse voluntaria para responsabilizarse de una tarea. Esto se nota aún más si los roles o las tareas no están muy bien definidas o nadie se siente especialmente capacitado para llevarlas a cabo.
La inercia
Los equipos, como los barcos, tienen su inercia. Cuesta arrancarlos, cuesta pararlos y tardan cierto tiempo en responder a las señales de cambio. Tienes que tener en cuenta esos tiempos de reacción.
Pero la inercia es asimétrica. Las cosas malas, abandonadas a la rutina, tienden a ir a más. Las cosas buenas, abandonadas a la rutina, tienden a ir a menos. O dicho de otro modo. No necesitas esforzarte para que una cosa mala vaya a peor. Sin embargo, tienes que esforzarte continuamente para que algo bueno simplemente se mantenga siendo bueno y no se degrade.
Relacionado con esto, el estilo con el que las personas del grupo se comunican (tanto la persona responsable como todos los participantes) debe adaptarse a la situación. Cuando todo va bien y el grupo experimenta orgullo y satisfacción por estar en el proyecto, es mucho más sencillo. Quizás no tengas que preocuparte demasiado por el estilo que usas porque casi todos se toleran y se integran bien dentro de un ambiente positivo (incluso ciertas ironías o estilos un poco más bruscos). Sin embargo, cuando las cosas se tuercen y el grupo se enfrenta a la frustración de no avanzar al ritmo o en la dirección deseada, es preciso usar estilos que no levanten ampollas en «pieles» que se han convertido en ultrasensibles. Considero que los estilos asertivos funcionan siempre bien en ambas situaciones, pero en las malas, seguramente hay que añadir mas palabras de lo habitual para que el mensaje se entienda y se interprete del modo adecuado.
Comunicación
Una de las barreras de comunicación que se ha visto muy claramente durante la travesía es el empleo de jerga específica y desconocida para muchas de las personas participantes. El uso de terminología específica es muy útil cuando todas las personas la pueden entender porque permite que con una palabra clave se transmita mucho significado. Pero cuando carece de significado para las personas que tienen que intervenir genera confusión. Virar, orzar, trasluchar, escorar tienen un significado claro para las personas habituadas a navegar. Son una barrera infranqueable para las que no están acostumbradas («Órzale…Pero…¡¿Por qué me viras?!»)
En nuestros proyectos debemos hablar en el lenguaje que nos permita a todos entendernos. Si es relevante el conocimiento de una jerga específica se tiene que aprender e interiorizar. Pero hasta que no se consiga interiorizarla debemos aplicar la frase con la que se inicia este párrafo.
Además, en los proyectos los problemas de jerga no son solo de lenguaje… también son de puntos de vista (las diferencias experiencias de uso de la persona responsable funcional, de la usuaria, de la analista, de la programadora…).
Otra barrera es la comunicación incompleta porque damos por supuesto que todas las demás personas pueden completar las frases o descripciones de tareas, porque en el contexto donde la comunicamos es «evidente» que no hay otras opciones. Pero nos olvidamos que es «evidente» solo para personas con cierta experiencia que son capaces de interpretar la situación y filtrar de todas las posibilidades la única que aplica con ese mensaje en ese contexto. Por ejemplo, en una maniobra de viraje, con tres personas sujetando tres cabos distintos, una orden como «afloja» puede significar muchas cosas para personas inexpertas: que afloje la persona A, la B o la C. O que aflojen dos de ellas o que la aflojen las tres. Sin embargo, si las tres son expertas, sabiendo la maniobra que se está realizando y de donde viene el viento, «afloja» solo significa una sola cosa, porque en ese contexto solo hay una opción razonable y descartan cualquier otra opción.
Por lo tanto, debemos acompañar a nuestra «tripulación» del proyecto dando las instrucciones en el formato y con la cantidad de palabras necesarias para que se puedan procesar adecuadamente. Por ejemplo: «Carmen afloja un poco el cabo» o «Manolo y Carmen liberad completamente el cabo».
Un último detalle sobre comunicación. Los «plops». Esas comunicaciones que son como pompas de jabón que chocan contigo, explotan y desaparecen y ni te enteras. Por ejemplo: «¡que alguien me diga algo!» tic, tac, tic, tac, tic tac… y nadie dice nada.
Implicación y aprendizaje organizativo
En los primeros 7-8 minutos de de la tercera regata (desde la preparación para la salida) han aprendido más que toda la hora anterior (o por lo menos han experimentado que tenían ese aprendizaje). Y sin duda han disfrutado más (se notaba en el tono de la voz, actitud y como se animaban entre ellos). En esos minutos han estado pilotando la nave ellos solos, tomando decisiones (más o menos correctas) y poniéndolas en marcha (con más o menos eficiencia).
Tras unos minutos de trabajo intenso y comprometido, ha habido unos minutos de de diversión hablando y bromeando con las tripulaciones de otros barcos. Se trataba de un momento de transición donde estaba todo el trabajo hecho y donde solo se necesitaba la atención de dos o tres tripulantes hasta que llegara el momento de un nuevo viraje. En el momento que se ha solicitado la atención toda la tripulación ha vuelto a su concentración de antes. Eso me lleva a pensar en la importancia de celebrar los hitos intermedios. Un proyecto tiene varias fases y es bueno identificar los momentos donde se han conseguido resultados intermedios y aprovechar para felicitar, animar y distender. Eso no solo recarga las energías para los momentos más intensos, también ayuda al equipo a disfrutar del proceso y no solo de los resultados finales del proyecto.
También he podido observar lo complicado que es recuperarse de un «jarrazo de agua fría». Cuando mejor iba el barco, pilotado por los participantes en posiciones intermedias y luchando por situarse en cabeza, a punto de llegar a la boya de mitad de la manga… Justo en ese momento, una mezcla de decisiones no acertadas junto con una ejecución no muy brillante hacen que el barco pierda viento y se genere una sensación de caos e impotencia. Agravada por el hecho de que el patrón toma las riendas y desplaza al equipo de su posición de «autonomía».
Es como cuando en los proyectos aparece alguien que bloquea el proyecto o cuando, tras muchas horas de trabajo intenso, presentas orgulloso tu trabajo al cliente y te dice que eso no se parece en nada a lo que esperaba y cuando te dice lo que quiere te das cuenta que no es lo que te había dicho, o tu habías interpretado, seis meses antes).
Pero la reflexión que yo me hago es. Si han podido tener momentos buenos alguna vez, esos se pueden repetir. Descubramos las cosas que nos han permitido lograr esos momentos.
Exceso de información vs aprendizaje
En varios momentos de la actividad me ha dado la sensación de que el equipo estaba desbordado de información que no se transformaba en aprendizaje. Por un lado no se digería tanta información de golpe: más de dos o tres instrucciones no se recuerdan si no las conviertes en habito y para convertirla en hábito debes ejecutarlo/ponerlo en acción varias veces. Una vez asentado algo (por ejemplo el efecto de virar de una forma u otra, o el de cazar un cabo mas o menos rápido), puedes pasar a entender y practicar el siguiente aspecto.
Por otro lado, parecía como que la información que llegaba a la tripulación no estaba filtrada por importancia/necesidad para el éxito de la travesía. Por ejemplo, se aportaban muchos datos de cultura general náutica o anécdotas irrelevantes para las tareas a realizar. La tripulación novata estaba 100% atenta intentando recordar cada palabra y darle sentido práctico, pero el continuo chorreo de contenidos irrelevantes hace que se pierda la capacidad de atención para las cosas importantes. Cuando llegaba la instrucción útil, las mentes estaban agotadas y, además, no había tiempo para repetir y asentar la práctica del conocimiento.
Esto es algo que veo en muchas reunión de proyectos. No se va al grano, divagamos y nos perdemos en detalles no urgentes o no relevantes y cuando llega el momento de la información importante ya hemos perdido la atención del equipo o no queda tiempo para asentar esa información de manera adecuada y terminamos la reunión abruptamente confiando en que el equipo sabrá usar la información recibida para trabajar autónomamente hasta la siguiente reunión (la realidad nos suele sacar de ese sueño, una semana o quince días más tarde).
También me puedo aplicar esta regla a mis clases. Todos sabemos que el aprendizaje no consiste en embutir más conocimientos de los que el estudiante puede procesar, practicas e integrar en sus conexiones con conocimientos previos o creando nuevos conocimientos. Por eso dar una lección magistral vomitando aceleradamente la mayor cantidad de conocimientos posibles por minuto, no suele dar mejores resultados que otras formas de instrucción. Ni siquiera cuando los conocimientos «vomitados» hayan sido adecuadamente filtrados e incuestionablemente relevantes, esenciales y pertinentes. Mucho menos si, encima, no se ha hecho un esfuerzo por filtrar aquello que es realmente necesario para el éxito y desarrollo de la persona que aprende.
Aprender a Mirar
Si no somos capaces de fijar un punto que nos sirva de referencia es muy fácil perder el rumbo, ir dando bandazos e, incluso, frenar el barco porque acabas perdiendo grados respecto al viento y te quedas justo en la dirección del viento. Del mismo modo en los proyectos debemos tener señalas claras de los puntos intermedios de llegadas. Por ejemplo pantallas, pequeños desarrollos, prototipos funcionales, etc. En este sentido la metodología scrum/sprints puede ser de gran ayuda al marcar revisiones frecuentes (una, dos o tres semanas) con implementación modular de las funcionalidades.
Las entregas intermedias o los prototipos son como las «lanas» de la Génova. Te dan señales sobre si está alineado o si necesitas hacer unos ajustes finos para optimizar los resultados.
Lecciones aprendidas
Los trabajos de plegar las velas y dejar el barco preparado para el atraque son también funciones esenciales para poder salir a navegar en condiciones la próxima vez. Puede parecer que no es navegar, pero lo es y se nos olvida.
Es lo mismo que pasa en los proyectos, cuando hacemos un cierre adecuado del proyecto (revisando las expectativas cumplidas de las personas usuarias, el esfuerzo y el dinero invertido), extraemos unas lecciones aprendidas y celebramos que se ha completado el proyecto. Todo esto nos permite aprender de la experiencia y abordar el siguiente proyecto con más energía, entusiasmo, seguridad, eficacia y eficiencia.
Si no lo hacemos es probable que se cuelen pensamientos como los que se verbalizaron en mi equipo al acabar la regata: «está claro que navegar no es lo nuestro». Cuando mi visión como observador era radicalmente diferente:
En una hora, un conjunto de novatos habían aprendido a navegar y pilotar un barco
Han descubierto que cosas tienen que practicar para mejorar
Y si hubieran contado con más tiempo para «iterar» el conocimiento, habrían aprendido a navegar con autonomía en mares en calma con poco viento (seguirían siendo novatos en otras condiciones, pero autónomos en esta)
En definitiva, sea cual sea el resultado de un proyecto (incluso si se tiene que cancelar a mitad, o si tardamos mucho más de lo previsto o nos gastamos mucho más dinero del esperado o si no se logra cumplir las expectativas de las personas usuarias), solo se puede considerar un fracaso si no hemos aprendido nada de él. Si, a pesar de no tener éxito, conseguimos aprender cosas para no cometer los mismos errores en el futuro, ya ha sido útil en algún sentido. Obviamente esto no puede servir de excusa para incumplir expectativas continuamente, entonces tendríamos un problema y realmente no habríamos aprendido nada. Pero debemos asumir como normal cierto numero de proyectos sin el éxito esperado, siempre que podamos obtener lecciones aprendidas útiles de ellos.
Otros aprendizajes
El anticiparse (como cuando no esperas a que la vela o la botavara cambie de lado por su cuenta e intentas forzarla con los cabos) frena el proyecto. Tienes que dejar que los usuarios digan lo que quieren y no anticipar soluciones si aún no tienes la información (forzar a que el usuario te diga lo que quiere ayuda a avanzar -es como iniciar una maniobra de viraje o de trasluchada-, pero intentar programar cosas antes de que te digan lo que necesitan o lo que quieren, es como tirar de los cabos antes de tiempo… luego tienes que deshacer el camino, y has perdido tiempo y energías).
Algunas metáforas/analogías entre navegación y proyectos
El viento son los estudiantes y/o empresas (las personas usuarias externas a las que proporcionamos servicio de aprendizaje o transferencia), las velas son el personal que ofrece el servicio directamente (normalmente PDI o personal de investigación), el resto es barco.
La sensación de ir deprisa (el viento en la cara) es una ilusión. Vamos más deprisa cuando nos desplazamos más rápido, no cuando tenemos sensación de ir rápido (o hacemos muchas cosas que en el fondo no generan ningún movimiento).
A veces nuestra única función es hacer peso para que el barco vaya más equilibrado (es una función que puede parecer aburrida o que no haces nada o que, aparentemente, no aporta, pero es necesaria para ganar algo de velocidad extra).
Asumir el trabajo del día a día de otra persona, para que esa otra persona –con capacidades diferentes a las mías- haga lo que sólo ella sabe/puede hacer, también es ayudar a que salga adelante un proyecto (que es necesario para nuestra unidad). A veces mi papel en el equipo es permitir que otra persona libere el tiempo para poder hacer otras cosas por el equipo.
Hoy me ha tocado firmar algunos documentos y me llama la atención un detalle curioso.
El formulario obliga (o al menos incita) a poner lugar y fecha de la firma. Pero al final estoy obligado a usar firma electrónica, de modo que, las fechas no van a cuadrar (porque el formulario lo rellenó otra persona que me lo manda por correo y yo, cuando puedo, lo reviso y lo firmo).
Si voy a firmar electrónicamente no tiene sentido poner la fecha «a mano» porque ya saldrá en la firma.
Si la fecha no es relevante, ¿para qué piden que perdamos el tiempo poniéndola?. Si es relevante y no nos dejan firmar «a mano» (porque no nos admiten ya esa forma de firmar), ¿para que nos piden que perdamos el tiempo poniendo la fecha si ya va a incrustarse de serie con la firma electrónica?.
Por otra parte, te piden que pongas el lugar donde estás firmando el documento. No entiendo la necesidad de indicar si estoy firmando en Valencia, en Madrid, en un AVE entre las dos ciudades o en un pueblecito costero. Supongo que es relevante cuando firmas contratos por temas de jurisdicción ante reclamaciones… Pero para un documento interno de la universidad ¿realmente sirve para algo o es solo que alguien, algún día, lo puso y no saben ni para qué lo pusieron?
Igual pensáis que estos dos detalles son de tan poca importancia que para qué me molesto en escribir una entrada en mi blog, si el tiempo que gasto al año poniendo esos dos datos inutiles es mucho menor que el que tardo en escribir esta entrada.
La explicación tiene que ver con la mejora continua:
Con cierta frecuencia alguna persona decide que la incongruencia de fechas es un error de forma y paraliza el proceso de trámite hasta que se subsane. Eso implica escribir un correo al que ha firmado, que tiene que escribir otro correo al que ha redactado el documento (que es el que tiene el original editable), que se lo devuelve al que firma, que firma y se lo remite a la persona que ha paralizado el proceso. Todo esto significa bastantes minutos de trabajo, muchas horas (a veces días de retraso) y, a veces, hasta que se llegue tarde a un trámite y se pierda algo (por ejemplo 20.000 euros porque no puedes facturar a tiempo a un cliente y el fondo con el que iba a pagarte ha caducado). Lo curioso (y sangrante) es que muy probablemente no haya ninguna ley o norma que diga que deja de ser válido un docuemnto por un conflicto de fechas (la fecha de firma digital manda)
Si he detectado dos campos a rellenar que son absurdos, inútiles e innecesarios. Y el documento tiene como 40 campos a rellenar… ¿cuantos de esos 40 campos son igual de inútiles o innecesarios?
Gracias a un compañero, confirmo que esto era relevante. Tanto que han tenido que emitir una instrucción interna, en el BOUPV de principios de noviembre.. que no está reflejado aún en los documentos que transitan o te puedes descargar a finales de noviembre (¿apostamos que dentro de una par de años siguen circulando documentos de la UPV que piden que introduzcas lugar y fecha?). Por cierto, sigo pensando para qué es preciso poner el lugar… y si es preciso, ¿porqué no lo incorpora la firma electrónica? (seguramente porque no sirve para nada y por eso no se preocuparon por incorporarlo)
Pertenezco a una organización que tiene contrato corporativo de Office 365. Una de las aplicaciones incluidas en la suscripción es Ms TEAMS. Muchas personas de mi organización no habían necesitado usarla antes de la pandemia COVI19. Pero el teletrabajo y la teledocencia forzada obligo a que se convirtiera en una de las aplicaciones más usadas durante los ultimos 18 meses. Pero la frecuencia en el uso no significa que se use bien, ni eficientemente. Al menos en mi caso he visto crecer una maraña de «TEAMS» cuando hubiera sido mucho más sencillo, práctico y eficiente organizar canales (publicos o privados) dentro de un «TEAM» en lugar de optar por un crecimiento asilvestrado e interminable. Doy por perdida esa batalla y ya asumo que cuando alguien quiera hacerme una videollamada, creará un TEAMS en lugar de simplemente hacerme una llamada en el chat, o que tendré decenas de «teams» donde las personas participantes son básicamente las mismas, o que convivirán los mensajes del chat de TEAMS con los de Whatsaps y mails, todos mezclados en un caos irrecuperable. En el fondo, yo creo que ni sabemos, ni nos creemos de verdad lo que implica «trabajar en equipo», que tiene muchas capas, pero una de ellas es la de crear unos canales y procedimientos de comunicación consensuados y eficientes.
He pensado en preparar un ¿decálogo? de buenas prácticas si vas a trabajar en equipo con TEAMS. Como no tengo el tiempo de hacerlo todo de golpe, voy a ir editando este post con las cosas más urgentes (o sangrantes) que se me ocurran.
1. Las versiones no se limitan solo al control de cambios
Para mi una de las grandes ventajas de espacios de trabajo como TEAMS (github, alfresco o cualquier otro repositorio) es que permiten un versionado de documentos. Esto permite acabar de una vez por todas con los insufribles cadenas Documento.v1; Documento v1b; Documentov2; DocumentoV2resvisdoxRTF……
Si editas en linea, mantiene versionados de lo que guardas en cada sesión de trabajo. Si trabajas localmente, solo tienes que tener la precaución de no cambiarle el nombre al documento y te genera un versionado automático cuando lo subes (no machaca lo que ya hay, crea una nueva versión, indicando fecha y persona responsable de la versión).
2. Editar un archivo compartido en la nube para editarlo simultáneamente con otras personas no es descargartelo en local
TEAMS ofrece tres formas de abrir un documento en la nube (es decir, que la edición concurrente es posible y se gestiona relativamente bien las aportaciones simultáneas de mas de una persona editando el documento- siempre que no estén en la misma linea, o mismo párrafo-):
Dentro de TEAMS (la mas limitada en opcioneS)
En la app de escritorio (todo el potencial de la aplicación de escritorio pero el documento compartido)
En navegador web (algunas funciones de escritorio no están disponible)
Abierto en TEAMS:
En la aplicación de escritorio:
En navegador:
Si lo que haces es descargarlo en local y editar una copia en TU ORDENADOR, dejas de sincronizar con todas las personas que hayan hecho cambios entre tu descarga y que decidas volver a subirlo a TEAMS (si es que te acuerdas de hacerlo) y eso crea conflictos de versiones que luego consumen un tiempo enorme para conciliarlas.
Postdata: obvamente, si eres la unica persona que va a «meter las zarpas» en el documento, puedes descargarlo localmente y cuando acabes subirlo al TEAMS, eso no generará ningun conflicto de edición… pero como haya al menos una persona editando al mismo tiempo que tu, ya es otra cosa.
Postdata: si abres un documento en la nube (cualquiera de las tres modalidades) es importante que no os dejéis sesiones abiertas cuando salgáis corriendo a hacer otras cosas (que se quede el documento «abierto» aunque no cambies nada… eso bloquea el documento para subidas de versiones creadas offline (y nadie puede «expulsaros» de la sesión, podéiss quedados semanas bloqueando el documento si no apagáis el ordenador)
Llevo tiempo oyendo hablar de Objectives and Key Results (OKR), pero nunca me había preocupado demasiado de este tema. Estaba habituado al Despliegue de objetivos, formulación de objetivos SMART y Key Performence Indicators (KPI). La verdad es que no sabía si esto era un nuevo rótulo para lo de siempre o si realmente es algo nuevo y diferente de lo anterior.
Hoy he decidido empezar a bucear un poco más en el termino, sus orígenes y su trayectoria. Veremos hasta donde me lleva todo esto. De momento os comparto mis primeras observaciones (que supongo que tendré que ir rectificando y completando). Quiero centrarme en datos y no en la interpretación o la impresión que esos datos me generan (porque aún no tengo la certeza de que sean los adecuados).
Lo primero que he hecho es poner OKR en google. Obviamente salen un montón de resultados y, todos los situados en posiciones relevantes (he navegado por las 5 primeras páginas de resultados), están vinculados a OKR y Performance Management. En muchas de ellas se vincula o se ponen ejemplos de OKR de GOOGLE (es curioso que con tanta empresas como hay, casi todos los ejemplos sean de la misma… supongo que muchas páginas beben de la misma fuente).
A continuación he entrado en google académico y con la misma búsqueda (OKR) ninguno de los resultados de la primera página tenía nada que ver con gestión de rendimiento. Si cambio la busqueda (okr performance management), aparecen 2600 resultados y los de la primera página están todos vinculados a Performance Management. La mayoría de los de la primera página parece que se dedican a comparar OKR y KPI. En una mirada más detallada, todo lo que he mirado en la primera página eran comunicaciones a congreso (no parecían con una revisión por pares rigurosa) o capitulos de libro (seguramente de congresos) o aportaciones a repositorios institucionales.
Por último, he entrado en WOS y SCOPUS. En ambas he buscado por OKR y salen muchos resultados. Ninguno tiene nada que ver, ni de lejos con Management (ni siquiera las revistas en las que se publican). Por confirmar con más detalle, he buscado con TITLE-ABS-KEY ( okr AND «performance management» ) y no sale ningún resultado (ni en WOS ni en Scopus).
De modo que tenemos un termino, que cuando se usa vinculado a performance management cuenta con una gran presencia en Google, baja presencia en google scholar (en medios de difusión que, probablemente son de segunda o tercera fila), y ninguna presencia en publicaciones académicas de revistas indexadas en WOS o Scopus.
Voy a dejar madurar un poco el tema. El inicio no ha sido muy prometedor
Marin-Garcia, J. A., Ruiz, A., Maheut, J., Garcia-Sabater, J. P. (2021). A data generator for COVID-19 patients’ care requirements inside hospitals: data paper. WPOM-Working Papers on Operations Management, 12 (in press). https://doi.org/10.4995/wpom.15332
Esta semana he empezado a preparar la documentación para una futura oposición a Cátedra de Organización de Empresas. Aun no hay fechas, pero tengo bastante trabajo por delante.
He decidido aprovechar este evento para hacer un ejercicio de reflexión que llevo madurando desde hace tiempo, pero que nunca había sido urgente concretarlo. Por lo tanto, no voy a preparar el «papeleo» de la oposición. Lo que voy a hacer es un mapa estratégico (Bryson et al, 2014) de mi papel como funcionario al servicio de la sociedad y, a partir de eso, desplegar un proyecto docente e investigador planteado con sentido práctico y aplicable.
Continuando la linea que inicié en anterior oposición (hace ahora 20 años), voy a distanciarme del formato de los proyectos que se presentan habitualmente. Voy a aplicar el mismo enfoque con el que abordo la elaboración de solicitudes para proyectos de investigación. Esos proyectos en los que invierto entre 200 y 300 horas en elaborarlos y luego nunca consigo financiación pública. Sin embargo, mi forma de plantearlos me permite luego desplegar de manera muy fácil la investigación (que acabo financiándome yo mismo, ya que nadie más cree en su utilidad). Al menos así, no desperdicio las horas de trabajo invertidas en la creación del documento.
No me atrae hacer proyectos de una forma que no les pueda ver una utilidad clara para mi. Me resisto a invertir una considerable cantidad de horas en generar un documento cuyo destino sea ir a la papelera tras la oposición. Quiero que su escritura me resulte interesante y apasionante. En mi caso, eso solo podrá lograrse si me ayuda a cuestionarme aspectos de mi profesión, me obliga a reflexionar críticamente, me permite descubrir cosas y que me catapulta a actuar enfocado en una dirección relevante.
De momento, he empezado con la lectura de estos libros:
Bryson, J. M., Ackermann, F., & Eden, C. (2014). Visual strategy. Strategy mapping for public and nonprofit organizations. San Francisco: Jossey-Bass
Ramio, C. (2014). Manua para los atribulados profesores universitarios. Madrid: CATARATA
Evans, L. (2019). Catedráticos de universidad. De lideres académcios a académicos que lideran
Y he elaborado un primer borrador (aun en construcción) de mapa estratégico:
El próximo paso es integrar mis anotaciones de de Evans (2019) y Ramio (2014)
Just published Bonavia, T., & Marin-Garcia, J. A. (2019). Spanish validation of the leader empowering behavior questionnaire (lebq). Frontiers in Psychology, 10(2368). doi:10.3389/fpsyg.2019.02368 #HRM#ContinuousImprovement#TalentManagement
The concept of empowering leadership (EL) has attracted widespread academic and practical interest and different questionnaires have been developed to measure it. However, there are no instruments to measure EL in the Spanish language. This article presents the translation, adaptation, and validation of a scale to measure this construct. In addition, it analyzes the relationship between managers’ EL and employees’ job satisfaction. In turn, the study analyzes whether employees who participate in a greater number of continuous improvement (CI) programs have supervisors who favor more empowering behaviors. A total of 739 participants with various occupations from different companies that have implemented CI processes filled out the Spanish version of the Leader Empowering Behavior Questionnaire (LEBQ-sp). Two different subsamples were used to test the relationships between the LEBQ and job satisfaction and CI, by means of Pearson’s correlation coefficient and analysis of variance, making it possible to provide evidence about the validity of the Spanish LEBQ. The confirmatory factor analysis supported the original structure of the six-factor model. The factors show a high level of internal consistency, as well as sufficient convergent and discriminant validity. Moreover, the results show that the more companies invest in formal CI programs, the more important it is for their leaders to adapt their behavior by displaying more EL. The LEBQ-sp is a valid and reliable instrument for use in research and a useful tool for applied purposes in the context of Spanish-speaking countries.
Estrategia de búsqueda:
"internal communication" en titulo, resumen o palabras clave
de revistas indexadas en SCOPUS
Publicado entre 2013 y 2018
en revistas catalogadas en categoria de empresa o economía
255 resultados
Tras filtro manual, 55 seleccionadas
Tras leer los resúmenes, parece que pocas hablan de herramientas concretas. He hecho un mapa conceptual de los contenidos aparentes de los 55 artículos (no los he leído aún, de modo que quizás mi mapa no represente adecuadamente los contenidos).
Respecto a herramientas, la investigación actual se centra en «social media» y la vinculan como herramienta de marketing interno (como una analogía a las capacidades de social media como herramienta de marketing externo). También se investiga sobre los resultados de la comunicación interna, pero parece que suelen abordarla como un todo global y no analizar el efecto concreto de una herramienta específica. Un tercer bloque de investigación se centra en qué herramientas serían más eficientes en contextos de crisis (o cambio o inestabilidad), y qué función puede cumplir en ese contexto. Sin duda esto se debe al pasado reciente de la crisis, pero quizás siga siendo un tema interesante en algunos sectores, donde la crisis dejó un entorno marcado por la incertidumbre o la inestabilidad.
A través de nuestra investigación previa (ver referencias al final) hemos identificado 4 estructuras habituales en las empresas para fomentar la mejora continua:
Sistemas de sugerencias individuales (SB Suggestion Box)
Grupos permanentes de sugerencias (PST Permanent Suggestion Teams)
Grupos de mejora de corta duración (Ad-hoc temporary teams like kaizen events)
Grupos semi-autónomos (SDWT Self Directed Work Teams)
Hemos recogido datos de 856 operarios-as de empresas españolas o sud-americanas en el periodo 2009-2014. En el 78% de los casos existía alguna de las cuatro estructuras, pero solo el 65% las personas había participado activamente en alguna de ellas en los ultimos 12 meses.
Analizando la presencia y participación en cada una de las estructuras podemos comprobar que salvo en los grupos semi-autónomos, la implicación efectiva es bastante baja (la estructura está activa en la empresa, pero las personas no quieren -cuando es voluntaria- o no pueden participar -cuando es por invitación de los mandos el poder involucrarse en la estructura).
Nuestra intención es continuar con la investigación ampliando la muestra en el periodo 2014-2020 para analizar en cada uno de estos tipos de estructuras:
¿Quienes y cuántos forman esos grupos?
¿Qué actividades o responsabilidades realizan las personas de estos grupos?
¿Qué resultados se obtienen en número de sugerencias implantadas?
¿Qué formación reciben sus componentes?
¿Cómo se recompensa la participación?
¿Qué percepción tienen las personas de estos grupos? (cuando participan y cuando no participan en ellos)
Para saber más:
Juarez Tarraga, A., Marin-Garcia, J. A., & Santandreu-Mascarell, C. (2016). High involvement work programs (HIWP) measurement model validation and its capacity to predict perceived performance. Intangible Capital, 12(5), 1308-1400. doi:http://dx.doi.org/10.3926/ic.837
Juárez Tarrega, A., Marin-Garcia, J., & Santandreu-Mascarell, C. (2019). What are the main concerns of human resource managers in organizations? . Intangible Capital, In press.
Marin-Garcia, J. A., Juarez-Tarraga, A., & Santandreu-Mascarell, C. (2018). Kaizen philosophy: The keys of the permanent suggestion systems analyzed from the workers’ perspective. The TQM Journal, 30(4), 296-320. doi:https://doi.org/10.1108/TQM-12-2017-0176