Nuestro proyecto termina de cumplir 8 años de vida y en este largo camino hemos intentado modificar (eliminar) cada uno de los puntos con los cuales no coincidíamos cuando éramos empleados. Tanto mi socio, el Ingeniero Hernán Amiune, como yo, trabajábamos, mientras íbamos a la facultad juntos, como programadores en Intel y HP. Fue en ese mismo momento que dos aspectos nos llamaron negativamente la atención.
Nos preguntábamos por qué deberíamos perder horas con reuniones e interrumpir el trabajo en forma constante para reportar los avances a nuestros jefes (Project Managers), cuando ellos no disponían de las capacidades técnicas necesarias para evaluar el progreso alcanzado. Sumado a la realidad de que consideramos inviable lograr un balance adecuado entre la vida y el trabajo si trabajamos 5 días y estamos con la familia solo 2.
Definitivamente algo en la metodología tradicional estaba roto.
Incluso, a modo de referencia, en los últimos años nació una nueva tecnología social llamada Holacracy, que está enfocada en el trabajo ágil y con descentralización de la toma de decisiones para lograr trabajar sin la necesidad de tener un jefe. Está metodología es utilizada con éxito, por ejemplo, por Medium, que cuenta ya con más de 40 empleados y recibió 25 millones de Inversión.
Las principales razones por las cuales nosotros decidimos trabajar sin jefes en nuestro emprendimiento fueron:
- Como mencionamos brevemente antes, el desconocimiento técnico de nuestros jefes para evaluar nuestro desempeño generaba una gran desconexión.
- Las contantes reuniones que interrumpían los avances de nuestro trabajo de programación.
- La falta de poder de decisión que no estaba en manos de los programadores (quienes realmente hacemos el trabajo), sino de sus jefes.
Por otro lado, también nos gustaría compartir las razones principales por las cuales consideramos que debemos trabajar solo 4 días a la semana:
- Millones de libros se han escrito en respuesta a “el balance entre la vida y el trabajo“, pero es imposible si trabajamos 5 días y solo 2 nos queda para todo el resto: entretenimiento, familia, deporte, etc.
- Ventaja competitiva para conseguir los mejores nuevos integrantes de alta calidad que formen parte del equipo de trabajo (34 ingenieros / programadores) en nuestro proyecto y aún más importante, poder retener este excelente talento en la compañía.
- Otro aspecto significativo que observamos fue la menor cantidad de licencias que se pedían por enfermedad o por la necesidad de asistir a un turno con el médico. Esto fue algo sumamente positivo para el ambiente laboral. Como indicó el famoso médico Inglés, John Ashton, se debe cambiar a trabajar 4 días a la semana para disminuir significativamente el stress que está dañando la salud de la gente.
- Por último, al llegar el día lunes, todos estamos frescos y renovados para comenzar a trabajar. Definitivamente la calidad de lo realizado es mucho mayor. En la era de la tecnología, específicamente la programación, la cantidad no es lo importante, sino la calidad. Mientras menos líneas de código escriba un programador para alcanzar la funcionalidad deseada, mejor es la calidad de su trabajo.
De acuerdo con la Organización de Economía Cooperativa y de Desarrollo (OECD), los alemanes trabajan menos horas que sus pares de otros países pero son un 30% más productivos. Si lo pensamos desde el punto de vista de trabajar 4 días en vez de 5, en ese caso solo estamos trabajando un 20% menos. Si en esos 4 días de trabajo, hacemos eficientemente nuestro trabajo, posiblemente estemos ganando aún más productividad que si trabajáramos los 5 días.
Personalmente considero que las razones mencionadas son más que justificadas pero el gran desafío está en el “cómo“ las implementamos.
La combinación de trabajar 4 días a la semana y hacerlo sin supervisión de un jefe, lleva a un escenario bastante particular e interesante. Es en base a este contexto que en nuestro emprendimiento tomamos las siguientes políticas de trabajo:
- Exclusivo para Ingenieros: El primer diferencial es que solo contratamos ingenieros (programadores). Es decir, cada integrante de nuestro equipo debe saber escribir código. Desde la persona que realiza atención al cliente hasta quien está encargado de Marketing.
- Rotación Constante: En continuación al primer punto, quien está encargado de atención al cliente un mes, al mes siguiente va a estar encargado de programar y luego el próximo mes de ventas. Por más raro que esto pueda parecer, los beneficios que obtuvimos fueron extraordinarios. Por ejemplo: si un cliente llama y pregunta porque no puede hacer funcionar la aplicación y describe que problema tuvo, ¿quién mejor que un ingeniero para solucionarle el problema?. Sí ellos fueron quienes lo hicieron al programa en primer lugar.
Como dice Steve Blank, Profesor de la Universidad de Stanford, “el contacto con el cliente debe ser directo y constante por parte de quien desarrolla el producto”. - Solo para Proactivos: Esta política se refiere al momento de contratar nuevo personal, solo tomamos ingenieros que no necesiten supervisión para avanzar, ellos mismos tiene que ser emprendedores por si solos. Para poder distinguir uno de los otros, un aprendizaje que compartimos es preguntar en la entrevista: Cuál es el proyecto que más te gusto hacer?. El candidato correcto es quien identifica un problema y explica en detalle como hizo para solucionarlo. El candidato incorrecto, nos va a contar sobre proyecto que le asignó su jefe y como le indicaron debía resolverlo.
- Eliminar Reuniones / Emails: Para cerrar, el punto más importante. Decidimos eliminar por completo las reuniones. Es decir, de ahora en adelante ningún programador va a perder tiempo y cortar su trabajo para asistir a una reunión física o por teléfono.
El problema aquí es que la gran mayoría de los jefes no comprenden que la agenda de un Project Manager esta compuesta exclusivamente por reuniones, salen de una y entran a otra. Por el lado opuesto, la de un Ingeniero está compuesta por bloques de programación. Lo eficiente es que un desarrollador tenga un promedio de 4 horas ininterrumpidas de trabajo para codificar la funcionalidad deseada. Si es interrumpida por una reunión, entonces la eficiencia que se pierde es mucho más que el tiempo de la reunión.
Como comentaba el famoso emprendedor Paul Graham de YCombinator, "el costo de asistir a una reunión por parte de un programador siempre va a ser mayor".
Asimismo, eliminamos los emails, esto quiere decir, que nuestro correo electrónico no va a ser más un To-Do List de tareas pendientes.
Todo esto fue posible gracias a que desarrollamos una herramienta interna muy simple que consiste en un panel de control donde está la lista completa de los Proyectos en forma abierta y transparente sobre los cuales nuestro emprendimiento está trabajando actualmente.
De está forma, todos sabemos exactamente en que está utilizando su tiempo cada integrante del equipo y podemos sumarnos y participar en proyectos que nos interesen aportando nuestro esfuerzo y trabajo.
Pasando de una metodología de “push“ donde un jefe viene y nos indica que hacer, a una de “pull“ donde somos nosotros quienes en función de los objetivos de la compañía nos involucramos voluntariamente para colaborar y avanzar.
Considero que el "cómo" lo implementamos puede variar dependiendo de cada compañía e industria en particular (ya que nosotros somos específicamente de software). Pero todos podemos hacerlo, como vemos en este ejemplo en The Economist, donde una empresa de manufactura pudo ahorrar solo reduciendo el tiempo de las reuniones a un máximo de 30 minutos y 7 personas por reunión, ¡el equivalente a eliminar 200 empleados!
Como nota final, si me preguntan: "¿Cómo comenzar con este nuevo paradigma de trabajo?"
Mi respuesta sería, empecemos por el equipo de trabajo, es decir, solo contratemos a personas proactivas que no necesiten recibir órdenes en forma constante para trabajar y avanzar. Esa es sin lugar a dudas la clave básica y pilar fundamental para que todo esto funcione con éxito.
Acerca del Autor:
Cristian Ángel es el co-fundador de MT, compañía de educación financiera para todo Brasil. Actualmente realizando la expansión regional a México y Colombia. Profesor de Investigación y Desarrollo Tecnológico en la Universidad Católica e Inversor Ángel con foco en emprendimientos móviles para la salud.
Este articulo tiene 7 comentarios
Gracias por el aporte, no sólo es real y aplicable también me ayudo a la toma de decisiones. Cordial saludo.
ResponderMuy bueno :)
ResponderPor supuesto esto solo aplica en el mundo de IT, en sectores multidisciplinarios como Oil & Gas es imposible de aplicar
ResponderIT también es un mundo muidisciplinario.
ResponderMuy buen artículo, mucha información útil, en la que realmente vale la pena pensar, muchas gracias.
ResponderImpresionante
ResponderCreo que esto debería aplicarse en todas partes
Responder¿Qué opinas de este tema? Deja tus comentarios y aportes...