Categoría: Gestión

Claves para mantener reuniones internacionales exitosas

En muchos de mis trabajos he tenido que mantener reuniones con gente de todo el mundo. Muchas veces personas en varias latitudes a la vez, que tienen que avanzar en la ejecución de un proyecto o dar solución a un problema. Creo que tras ellas hay ciertas claves que ves que cumplen los buenos Project Managers, o que no cumplen los malos. Ellos son los responsables, pero son cosas que cualquier asistente a la reunión puede poner en práctica para mejorar su participación, y optimizar el uso de su tiempo.

videocall photo
Photo by Austin Community College
  1. No dejar que la reunión se salga del plan, si surgen temas se toma nota y ya se tratarán cuando corresponda. El tiempo es muy limitado, como para ponerse a tratar temas que la gente no se haya preparado. Al estar en distintas zonas horarias, normalmente las ventanas de tiempo son pequeñas y hay que aprovecharlas al máximo.
  2. Repetir todo las veces necesarias hasta estar seguros de que todo el mundo ha entendido. Cuando hay gente de distintas partes del mundo, normalmente (para mi siempre ha sido así) se habla en inglés, pero ni el nivel ni los acentos de la gente suelen ser iguales.
  3. Preguntar expresamente a las personas, cuando haya cosas importantes con las que deberían de quedarse al acabar la reunión. De este modo te aseguras de que se han enterado. Muchas veces la gente está «conectada» a la conversación, pero sin hacer caso ninguno a lo que se le está diciendo. Cuando oyen su nombre suelen espabilar.
  4. Siempre tener un medio de comunicación alternativo. Se haga por el medio que se haga, siempre está bien tener una alternativa (generalmente un teléfono fijo con manos libres), por si la informática falla. Me ha tocado más de una vez tirar de móvil para conectar a una call porque no iba Internet, lo cual no es agradable si no hay número del país en el que te encuentres para conectar.
  5. Asignar responsabilidades antes de dar la reunión por concluida. Para que todo el mundo sepa cuales serán sus obligaciones una vez se cuelgue el teléfono. Además sirve de resumen, y como en el punto tres, es una confirmación de que todo el mundo ha entendido lo que tenía que entender.
  6. Por último, es importante mandar un correo con el resumen de todo lo hablado. Así si alguien a entendido algo distinto podrá corregir o aclarar, y lo escrito quedará para la posteridad, sirviendo de diario de abordo.

Cumpliendo con estas sencillas acciones, cualquier reunión por complicada que se te antoje; aunque sea con americanos del sur, rusos, indios, y chinos; llegará a buen puerto.

Cómo pasar de 20 a 80 empleados en 5 meses

Hace ya un tiempo trabajé en una startup que había sido recientemente adquirida por una multinacional americana (Ingram Micro, número 68 de la lista Forbes en aquel entonces). Entre otras cosas tuve que ayudar a que creciera, y en el tiempo en el que estuve allí pasamos de 20 a 80 empleados, casi todos técnicos. Además de colaborar en las entrevistas y esas cosas, me pidieron que analizara el proceso de contratación, la formación y todo lo relacionado con las nuevas incorporaciones. Estas son cinco cosas que aprendí.

castellets photo

  1. Es vital que todo siga funcionando, por lo que es importante reservar tiempo de la gente que conoce los productos y la tecnología para que sigan produciendo. En general, será la misma gente que tendrá que encargarse de las nuevas personas que se incorporen, por lo que es muy importante tener en cuenta que necesitarán seguir siendo productivos.
  2. La gente que se incorpore tiene que formarse nada más entrar, por lo que o proporcionas los materiales necesarios para que se autoformen (y largos vídeos de rusos no son lo mejor), o agendas las incorporaciones para que se realicen justo antes de impartir un curso.
  3. La gente tiene que incorporarse a algún proyecto real justo tras su formación. No vale de nada estar continuamente haciendo proyectos básicos en los que no se enfrenten a problemas reales.
  4. Es importante hablar continuamente con todo el mundo e intentar que se sientan cómodos, para tener una visión clara de lo que está pasando y cómo está el ambiente para detectar los problemas cuanto antes. Los momentos con tanto cambio generan muchas tensiones.
  5. A veces, los objetivos y ordenes que se hayan establecido desde arriba van en contra de los intereses de la empresa y pueden llevar a hacer cosas mal. Hay que cuestionarse todo venga de dónde venga, y llegado el caso hay que intentar hacer ver a la gente de arriba por todos los medios posibles qué crees que está mal y por qué. Puede que te equivoques y no tengas todas las variables en mente, pero ya será responsabilidad suya proporcionarte toda la información.

¿Os habéis enfrentado alguna vez a un entorno como esté con un crecimiento tan rápido? ¿Qué aprendisteis vosotros?

Me la suda la tecnología

Todos hemos asistido a interminables debates sobre que tecnología es mejor, sobre que plataforma es mejor, sobre que lenguaje es mejor. Sin embargo, tras muchos años trabajando en una gran cantidad de proyectos de lo más variado y asistir atónito a otras tantas flamewars, he de decirlo: me la suda la tecnología.

Cada proyecto es un mundo, y en todos los casos hay múltiples factores que hacen que una tecnología se amolde mejor que otra. Pero igual que cada problema tiene múltiples soluciones, cada solución se puede implementar con múltiples tecnologías.

Hay técnicos que sólo se fijan en los factores técnicos, pero en cuanto has tenido un pie en negocio sabes que hay mucho más en lo que pensar.

Pongamos por ejemplo un caso sencillo: Ikea decide que va a dar un servicio de diseño de hogares, para lo que crea una bolsa de empresas y diseñadores freelance. La idea es que los diseñadores vayan a las casas de la gente y les ayuden a elegir los muebles y a comprarlos.

Las soluciones son múltiples: Ikea podría darles equipos iguales a cada diseñador; los diseñadores podrían llevar su propio equipo. Alguien en Ikea decide que es mejor la segunda opción. Aparece un nuevo problema y es que los clientes no siempre tienen conexión a Internet: se puede hacer un software que funcione en local y cuando haya conexión haga los pedidos; también los diseñadores podrían tener un pincho 3G para garantizar la conexión y así poder tener una simple web para que hagan los pedidos. Alguien en el departamento de ingeniería le hace ver las dificultades de la primera solución a un directivo y este consigue que se haga una partida para los pinchos, por lo que se quedan con la segunda opción. Por tanto, la solución final será hacer una simple web.

Para hacer una web las opciones son múltiples. Aquí podríamos entrar en una flamewar interminable sobre si PHP, .Net, Ruby on Rails, Node… También sobre si tener servidores propios o usar alguna plataforma cloud; si usar MySql, SqlServer, una base de datos NoSQL o guardar la información en archivos de texto plano. Las distintas opciones considerando todas las posibles combinaciones son muchísimas, y por mucho que nos guste más una tecnología que las otras, ninguno de los argumentos que se suelen usar en las flamewars debería de influir de verdad en la decisión. La verdad es que la tecnología en una solución tan simple como esta os la debería de sudar. A mi me la suda.

¿En qué nos deberíamos fijar si fuésemos el responsable tecnológico de este proyecto en Ikea? Hay que ver inicialmente si Ikea ya tiene otros proyectos y como se han hecho, con qué tecnologías se manejan mejor sus desarrolladores, etc. Si no los tuviese, podríamos mirar al mercado, ver que tipo de técnicos va a ser más fácil contratar por ejemplo, o si se espera que el proyecto evolucione y crezca o si hay previsión de otros proyectos y de que tipo serían… Hay múltiples factores que deberían afectar a la toma de la decisión, y la gran mayoría no vienen marcados por la tecnología sino que vienen marcados por los factores de negocio.

Por tanto, cuando os volváis a ver involucrados en una de esas de si «el este mola más», dejad de darle vueltas a qué lenguaje es más cool o que plataforma usa la empresa X. Plantearos los factores de negocio en casos concretos y las guerras dejarán de ser tan cruentas y se volverán mucho más objetivas y productivas. Cuando os digan que «mi tecnología mola más» responded con este grito: me la suda la tecnología.

Las cosas que hicimos bien

Este fin de semana tuve la visita de Juan, uno de mis exsocios de GPMESS. También resulta que estos días estoy leyendo «From impossible to inevitable» y en el trabajo, actualmente, me tengo que enfrentar a modelar lo que se hace con los socios y como se venderá después ese trabajo que estamos haciendo. Estas han sido algunas de las coincidencias en el tiempo que me han hecho darme cuenta de que hemos hablado largo y tendido de lo que hicimos mal en GPMESS pero nunca he expuesto aquellas cosas que hicimos bien. Intentaré repasar y justificar aquí una de ellas.

Probablemente el motivo de no haberlo hecho antes es que es muy fácil justificar lo que has hecho mal (nadie se lo cuestiona y además fueron muchas cosas), pero parece un poco hipócrita hablar de lo que se hizo bien tras un fracaso como aquel. Ahora ya ha pasado suficiente tiempo como para que esto no suene como un intento de escurrir el bulto, a nadie le importa ya GPMESS, así que espero que suene como lo que pretende ser: compartir uno más de los aprendizajes que tuvimos, algo que con el paso del tiempo sigo convencido que hicimos realmente bien.

Para que sirva de aval, no es algo que diga yo, son muchos los autores como Aaron y Jason que plantean lo que os voy a contar. Además, varios de los inversores con los que me senté en aquella época me dijeron con unas u otras palabras «Lo habéis hecho bien, esos pasos son precisamente los que hay que dar, sin embargo…». El pero era siempre el mismo, no habíamos facturado apenas porque habíamos tardado demasiado en los pasos previos y sin un histórico de facturación es muy complicado obtener inversión.

En aquella época por suerte, lógica o intuición, nos preocupábamos de medir todo lo posible e intentábamos tener en boca siempre las métricas piratas: ¡AARRR!

Además evitábamos gastar mucho tiempo y esfuerzo en cosas que no pudiésemos repetir posteriormente. Siempre que nos venían con un «haz un X viral» salíamos corriendo. Buscábamos lo que pudiésemos repetir, lo que pudiésemos multiplicar.

Los primeros usuarios nos costaron 15€, luego 7, luego 3 y finalmente tras muchas pruebas encontramos la forma de conseguir usuarios de nuestro nicho entre 0.7 y 1.2€ en función de la velocidad a los que los quisiéramos. Además sabíamos cuanto duraban con la aplicación instalada, y que al mes nos quedaba un 30% pero que ese 30% de usuarios ya nos eran fieles indefinidamente. Sabíamos que el 67.7% de las notificaciones se abrían, y que el 39.38% se concentraban en las principales ciudades españolas. Además sabíamos que un 15% de los usuarios no nos costaban dinero ya que venían por las recomendaciones de los fieles, que eran nuestros principales prescriptores, y que cuando estábamos bien posicionados en las stores de Android y Apple teníamos otro 20% adicional que nos salía «gratis».

En una aplicación como la de GPMESS, esto era una de las claves: medir todo y fijándose en las métricas buscar modos repetibles de crecer. Desgraciadamente tardamos mucho en llegar a la optimización que nos permitía dar el siguiente paso y no nos quedaba gasolina para dar el siguiente paso (encontrar un modo de monetizar los usuarios de una forma escalable).

Eso es lo que hicimos, y a día de hoy creo que eso lo hicimos bien. Creo que es algo que todas las empresas de ese tipo deben hacer: probar, probar y probar optimizando los procesos para encontrar el modo más barato y aceptable de conseguir sus objetivos de un modo replicable y escalable. De este modo, cuando tengan todos los procesos optimizados podrán enchufar la manguera de dinero y hacer que la máquina empiece a rodar.

Obviamente, si hubiésemos tenido éxito lo aquí contado sonaría más creíble, pero no me creáis a mi y leed a la gente que sabe mucho de desarrollar negocios, a los que han hecho alzarse empresas como Salesforce o 27signals, analizad negocios que han crecido mucho… luego, solo os quedará unir los puntos y estoy seguro de que comenzaréis a medir y a buscar fórmulas replicables.

Normas para la generación de ideas

Muchas veces nos enfrentamos a la necesidad de generar ideas, ya sea para solucionar un problema que no tenga una solución directa, o para crear o mejorar un producto. Sea cual sea el objetivo hay algunas normas que podemos seguir:

  1. No juzgar: Cuando estás generando ideas, ya sea sólo o en grupo, es muy importante no juzgarlas, por varios motivos. En primer lugar si estás en modo creativo no tiene sentido parar todo el tiempo que requiere una evaluación completa. Además no hay que desmoralizarse (ni a uno mismo ni a nadie). Por tanto, si estás generando ideas nada de «eso es una tontería».
  2. Todo vale: Digamos que esto es un refuerzo de lo anterior. Hay que poner encima de la mesa absolutamente todo lo que se te pase por la cabeza, ya que aunque estés seguro de que es algo que no vale por el motivo que sea, esa puede llevarte a ti o a otra persona a pensar en la buena buena, así que es importante que sea lo que sea lo plantees.
  3. Desorden: El desorden ayuda mucho a que el cerebro se ponga en modo creativo, así que busca momentos o espacios alternativos para darle vueltas a ese problema.
  4. Usa las manos: Hacer manualidades ayuda a pensar. Puedes garabatear dibujos, hacer papiroflexia, jugar con una goma o tirar una pelotita. En realidad, cualquier cosa que provoque usar otras partes del cerebro ayudará.
  5. Sólo no puedes, con amigos sí: Siempre es mejor hacerlo con más gente. Las ideas de uno pueden retroalimentar las ideas de otro. Además, con perfiles (estudios, experiencias, culturas) distintos se tiende a pensar en cosas distintas.

La próxima vez que tengas que darle vueltas a algo intenta poner todo esto en práctica y todo será mucho más fácil.

3+1 problemas típicos para que las empresas se vuelvan ágiles

En mi paso por las distintas empresas en las que he tenido el placer de trabajar y aprender, y en mi contacto con muchas otras empresas que me ha permitido ver como trabajan, he observado que se repiten ciertos puntos clave respecto al agilismo.

El primero sin duda, no es un problema per se, pero sus bases sí lo son.

En todas las empresas quieren ser ágiles, todas quieren aplicar Scrum, Lean, Kanban, o cualquier otra cosa que suene a agilidad. Todas siempre están empezando, pero ninguna lo está haciendo del todo, ninguna de verdad.

Esto no es un problema en si mismo, pero sí los cimientos en los que se basa. En ninguna de las empresas que he conocido querían ser ágiles para asegurar su supervivencia en un mundo cambiante, ni para ser más eficientes, ni siquiera para ganar más dinero.

En todas esas empresas, lo que he observado es que, se quiere ser ágil simplemente por moda, porque es de lo que habla todo el mundo, porque hoy en día si no eres ágil es porque estás haciendo una mala gestión.

Esto es un problema obviamente. Es importante que los procesos de cambio se asienten en unas buenas bases, pero al menos es un problema que te lleva por el buen camino. Es el menos malo de los problemas.

El resto sí que son grandes problemas que afectan de manera directa al proceso de cambio que requiere pasar de la gestión que se tenga a una gestión ágil:

Burocracia
La burocracia, esa traicionera que nadie reconoce, pero que efectivamente está en muchas muchas empresas.La burocracia mata muchos procesos, el orden excesivo, la sobredosis de normas provocan que no se pueda mover con velocidad de un punto a otro, que no se puedan probar distintas cosas e incorporar a los nuevos procesos aquellas que funcionen.
Desorden
Sí, aunque parezca que se contradice un poco con la anterior, es tan problemático el exceso de orden como su ausencia total. Para ser ágiles hay que tener orden, hay que conocer en todo momento los «recursos» de los que se dispone y sobre todo el más preciado de ellos que es el tiempo de las personas que ejecutan los trabajos. Si no se tiene cierto orden es imposible ser ágil porque nunca se podrá prever que trabajo se va a poder realizar y a que retos se va a poder enfrentar, y la gente que realiza los trabajos no va a saber nunca a que atenerse, que es lo que debería hacer en cada momento sin preguntar a su micromanager cual debe ser el siguiente paso que tienen que dar.
Miedo
Efectivamente el miedo es un gran problema. Generalmente es el miedo de los mandos intermedios. El medio que les impide enfrentarse a sus superiores para llevar a cabo los cambios. El miedo que les hace no asumir que a veces es necesario perder tiempo en tareas no directamente productivas. El miedo que les hace no asumir que optimizando es posible que se tengan que enfrentar a reducciones de presupuesto o a no cumplir con los objetivos erróneos que les hayan puesto los de arriba. Ese miedo les impide lanzarse a liderar el cambio.

Estos 3+1 problemas son los más repetidos en base a mi experiencia en las distintas empresas que he podido ver como funcionan. ¿Y en la tuya? ¿Quieren ser ágiles? ¿Desde hace cuanto? ¿Son ágiles de verdad o tienen algún problema para conseguirlo?

Lean is not dead

Hace unas semanas dije en Twitter que «el punk es la música más emprendedora que existe». A esto, Juan me reto a que lo desarrollara aquí para la posteridad (es más fácil reencontrarlo entre unos pocos posts, que entre un montón de tontos twits):

Bien, probablemente me equivoqué. Emprender es una palabra que abarca mucho, emprender es muchas cosas, y unas son más punk que otras. Sin embargo, creo que sí que hay una forma de emprender en la que encaja mucho el punk.

Punk

Ya hablamos en su día de qué era y de dónde venía el concepto Lean.

También dejé caer ya en su momento, en aquel «libro» que escribí tras el viaje con Yuzz a San Francisco, algún nombre de algún grupo con letras muy emprendedoras como Sioux (que anteriormente era parte de Kaos Etiliko).

Ese «teníamos un plan: si algo no funciona lo vuelves a intentar» es muy de emprendedores, de no rendirse, de aprender del error.

Pero no sólo por sus letras el punk es lean o el lean es punk.

El lean se basa en implementar, medir y aprender. Ponerse manos a la obra y meterse en harina, ver como funciona y qué se puede mejorar, para enriquecer la siguiente iteración de lo que sea que estás haciendo.

El punk, el del principio: el de los Saicos, el de los Sex Pistols, el de The Clash, Kortatu, Toy Dolls, Manolo Cabezabolo, … Todos tan distintos pero con tanto en común. Ese punk era de empezar por dar conciertos, por tocar (aunque no se sepa) e intentar hacerlo cada vez mejor (¡o no! ¡qué más da!).

Además, el punk usa canciones sencillas que se pueden replicar fácilmente igual que lean intenta repetir lo que ya se ha hecho, mejor y a mayor escala.

Otro punto que tienen en común es que ambos, tanto el punk como la metodología lean startup, surgen como respuesta a algo que ya no funcionaba.

El punk viene de esos ritmos del rock and roll que primero representaban la rebeldía y que iban contra el sistema. Ese rock se volvió algo mainstream que ya sólo podían crear los que eran grandes músicos, y que tuvo su muerte absoluta el día que su Rey que había escandalizado a todos con sus movimientos, Elvis Presley, aceptó hacer la mili (aunque fuera bajo presión). El punk es una respuesta a esa comercialización de la rebeldía, de la escandalización, a que sean los de arriba los que decidan que es bueno y que no, muy nihilista todo. El punk lo hace cualquiera que quiera hacerlo y sólo es punk mientras se mantenga rebelde.

Punk

Del mismo modo, la metodología lean startup apareció cuando los desarrolladores (y no los empresarios «de carrera») empezaron a montar empresas en un entorno en el que ya no funcionaba el modo habitual de hacer las cosas. En ese valle del silicio, en ese área tecnológica, en ese mundo cambiante en el que hay una gran incertidumbre y que es imposible anticipar resultados ni presupuestos a tres años, en el que hay que reaccionar a las condiciones variables que alteran el entorno como una galerna. El lean llegó para estructurar un modo de trabajar ágil que tuviera siempre una respuesta a «¿qué es lo siguiente que hay que hacer?» porque los sistemas tradicionales ya no funcionaban ahí, habían sido derrocados.

Otra similitud es que ambas «metodologías» dan distinto resultado cuando se aplican en distintos entornos, en distintos mercados. No creo que haya que ejemplificar que ni ha aparecido el mismo punk en España que en los países anglosajones, así como la aplicación de lean startup no resulta en el mismo tipo de empresas en España que en USA.

La ¿última? de estas similitudes es el inevitable final de quien decide seguir cualquiera de los dos caminos. O acabas muerto o acabas corrompiéndote. No tiene por que ser necesariamente malo ese corromperse, y más con esa alternativa. Es imposible que una empresa que crece mucho y se hace enorme siga siendo lean en todos los aspectos, igual que es imposible que un grupo que triunfa y se hace mainstream y se casa con discográficas potentes y todas esas cosas, siga siendo enteramente punk.

Es el curso de la vida, es como hacerse mayor, preferiblemente lo evitaríamos pero teniendo en cuenta que la única alternativa es morirse tendremos que celebrar hacer años, no ser tan punk o no ser en todo lean.

Imágenes del flickr de Mikel García Idiakez y de Dr Case