El Libro Azul

Cuando Jose Manuel Calderon y yo entramos en la familia Sngular, una de las primeras cosas que recibimos fue El Libro Azul, una especie de «manual del empleado» en el que no solo se detallan las normas y procesos con los que se gestiona el día a día de los empleados de la compañía, sino también la información necesaria -quién es quién, que significa cada sigla- para guiarte en tus primeros pasos dentro de la misma.

El contenido nos pareció tan bueno para entender qué era Sngular que nuestra primera reacción fue preguntar a nuestros nuevos compañeros ¿por qué no publicarlo? Al fin y al cabo si la compañía pretendía seguir creciendo con dobles dígitos año tras año sería absurdo seguir obviando que una de las herramientas más poderosas para atraer y retener talento es, sin duda, un manual público del empleado.

Nuestras voces se sumaron a las que ya lo habían planteado y cuantas más vueltas le dábamos a la idea más sentido tenía. Las empresas invierten una pasta gansa en acciones y campañas de employer branding cuando publicando tu manual del empleado puedes conseguir un enorme impacto con un coste cercano a cero, solo necesitas querer hacerlo.

No sé cuánto le costó a la firma de recruiting técnico Austin Fraser el diseño de su manual del empleado, pero estoy convencido de que los trabajadores de la compañía están tan orgullosos del mismo como para compartirlo con conocidos y amigos. Seguro que eso les ha facilitado más de una nueva contratación con la que amortizar la inversión de largo.

A fin de cuentas, a la mayoría de empresarios les gustaría que sus compañías fueran Tesla pero, probablemente, ni están cambiando el mundo ni repensarlo todo como afirma la compañía de Elon Musk en su anti-manual del empleado. Y, si no puedes distinguirte por lo que haces, al menos puedes intentar hacerlo por cómo lo haces. ¿A alguien se le ocurre algo que permita demostrarlo mejor que un manual público del empleado?

Uno de las mayores resistencias a la hora de publicar un manual del empleado es que este contiene información que, un principio, no iba a ser compartida y que debe ser revisada de cabo a rabo para evitar que la competencia puede obtener del mismo alguna ventaja competitiva. La realidad es que si tu salsa secreta, lo que hace especial a tu compañía, puede replicarse simplemente leyendo tu manual del empleado estás jodido, porque da igual cómo te pongas, tarde o temprano acabará filtrado.

A cambio de ese pequeño riesgo, puedes mejorar hasta el infinito y más allá el encaje cultural de tus candidatos. Si ya saben cómo funciona y se gestiona tu organización, es difícil que alguien que la aborrezca se apunte a una de tus ofertas y es más complicado que al empezar a trabajar descubra algo que le desagrade.

La verdad es que no encontramos ninguna razón para no publicar nuestro Libro Azul, así que, lo hicimos. Pero si está historia acabara aquí no sería más que un estúpido publireportaje que aportaría poco o ningún valor. Lo cierto es que, si algo he aprendido trabajando en la publicación del Libro Azul es el poder de un manual público de empleado como palanca para el cambio.

Porque si un empleado de Sngular lee el Libro Azul que hemos publicado echará en falta parte de la información contenida en la edición existente hasta la fecha.

En esta primera versión, apenas un MVP, se ha decidido no incluir ningún proceso que no sea común a todos los puestos de trabajo -independientemente de que estén en Cáceres, Ciudad de México o Singapur- en vez de esperar a tener una versión especifica para cada una de las regiones -no se disfrutan las mismas vacaciones en Oviedo que en Pittsburgh, por poner un ejemplo, ni la gratificación por recomendar a un nuevo empleado es igual en Dallas que en Barcelona- porque creemos que la mejor forma de asegurarse el desarrollo y actualización de un manual público de empleado es publicarlo. Algo que, salvo algunas honrosas excepciones como el Libro Blanco de Kaleidos, no es muy común el panorama tecnológico patrio. Por eso, por si alguien se anima a publicar el suyo, he recopilado algunas buenas prácticas a la hora de escribir manuales públicos de empleado durante los últimos meses, en los que me he papado decenas de ellos, desde el (precioso) panfleto publicitario de Facebook hasta el (terrorífico) manual sobre la cultura de excelencia técnica en Netflix:

• Debe contar una historia... y no debemos tener ningún complejo en hacerlo... aunque creamos que nuestra compañía es «poco sexy» por ser una consultora informática o una conservera de anchoas. En ese sentido, la referencia -para mi- es el manual del empleado más influyente en la historia de la tecnología, el de Valve, cuya historia -salvando las enormes distancias- tiene muchos paralelismos con la de muchas otras compañías nacionales que podrían sentirse identificadas en este párrafo: «Valve se financia por sí sola. Nunca hemos recibido financiación externa. Desde el principio, esto ha sido fundamental para dar forma a la empresa y a sus prácticas empresariales con libertad». Contadlo.
• Debe ser lo más exhaustivo posible. Para mí el objetivo de un manual del empleado no debe ser tan ambicioso como pretender que alguien se lo lea por completo antes de entrar en la empresa sino que pueda leer especificamente lo que le interese. Un gran ejemplo en este sentido es el manual de GitLab que, por ejemplo, detalla los beneficios generales de los empleados y los específicos dependiendo de la ubicación.
• Debe intentar trascender el formato de manual tradicional. Zappos diseñó su manual de empleado como un cómic y es una maravila. Trello ha ido un paso más allá al usar su propio producto para crear su manual. Nunca repetiremos demasiado que lo contrario de divertido no es serio sino aburrido.
• Debe recoger el feedback de los empleados. Como, por ejemplo, el de Basecamp, que está en GitHub. Si brujuleais un poco veréis que, además de la rama (versión) principal, hay varias más, una de ellas creada por un tal «Bergatron». Pues bien, Bergatron no es nadie de People ni de Management sino el tipo encargado de QA en Basecamp... que ha ampliado la descripción de cómo hacen QA en Basecamp y que, después de ser supervisada y aprobada, se incorporará a la rama principal. En el repositorio que contiene el manual de Basecamp hay 49 contribuidores, desde los fundadores de la empresa hasta el último empleado en llegar.
• Debe ser lo más parecida posible al manual de uso interno... o, mejor aun, ser la única versión existente :) En realidad, sólo hay que sacar datos operacionales como claves de WiFi, códigos de entrada, etc. que pueden estar en la Intranet o Wiki corporativa. Nadie espera encontrar datos sensibles o personales en un manual de empleado, pero al convertirlo en la copia de trabajo incentivaremos el feedback de nuestros propios empleados... y, también, que lo compartan con orgullo. Si mantenemos una versión funcional y otra light o descafeinada para el público ¿no lo verán los empleados como una mera herramienta de marketing? ¿La compartirán en Redes Sociales? ¿Contribuirán a la misma?

Son solo un puñado de recomendaciones, pero lo más importante es tener la voluntad colectiva de reflejar en documento no sólo cómo funciona tu organización sino sobre todo, por qué lo hace. Que no tengamos manual del empleado no quiere decir que no tengamos normas o procesos en nuestra compañía sino que no hemos considerado necesario recopilarlos. Si lo hemos hecho y no nos gustaría que alguien los viera publicados a lo mejor ha llegado el momento de cambiarlos, pero si no es así deberíamos al menos plantearnos por qué no los publicamos.

Este texto se publicó originalmente en la Bonilista, la lista de correo de noticias tecnológicas relevantes para personas importantes. Si desea suscribirse y leerlo antes que nadie, puede hacerlo aquí ¡es bastante gratis!

---

---

---