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?

How to implement a distributed OAuth 2.0 system

Some months ago (more than a year), I was playing with the WordPress REST API. I did an analysis about how to implement a distributed OAuth 2.0 system as an attempt to collaborate with the community. I wrote it as a comment over a discussion post, but I am going to replicate that here in order to save it with my other ideas and works.

  • coolapp.com is the site of the app
  • cooldev.com is the WP site of the developer in which I defined the app as multitenant
  • cooluser.wordpress.com is the WP site of the user who wants authorize coolapp.com to interact

01- User access to coolapp.com and says “Hey, I want to use this cool app”
02- coolapp.com ask for its server and user writes cooluser.wordpress.com
03- coolapp.com ask to cooluser.wordpress.com to identify the user
04- the user writes his credentials in cooluser.wordpress.com
05- cooluser.wordpress.com redirects to coolapp.com with a code saying “Yeah, this man is my man”
06- coolapp.com then ask to cooldev.com and says “Hey, I have a user with a code that wants to acces to the resource cooluser.wordpress.com and I am the coolapp.com (this is my client_id and this my client_secret)”
07- cooldev.com generates a token
08- cooldev.com says to cooluser.wordpress.com “Hey, I just generated this token that expires in 3600 seconds”
09- cooluser.wordpress.com says “I would prefer not to work, but you know, it’s ok”
10- cooldev.com sends the response to coolapp.com with the token
11- then coolapp.com using the token, can now ask to cooluser.wordpress.com to do some stuff

If you look at this diagram

Abstract Protocol Flow
Abstract Protocol Flow

Client = coolapp.com
Resource Owner = cooluser.wordpress.com
Authorization Server = cooldev.com
Resource Server = cooluser.wordpress.com

The RFC says:

“The interaction between the authorization server and resource server
is beyond the scope of this specification. The authorization server
may be the same server as the resource server or a separate entity.
A single authorization server may issue access tokens accepted by
multiple resource servers.”

but with some conversation like the one in 8 and 9 it could be resolved.

Busco nuevos proyectos

Así es, la temporada en eldiario.es llega a su fin, y toca buscar nuevos retos atrayentes y echar una mano en otro lado.

Con un perfil como el mío es fácil pero a la vez difícil. Desde que empecé con mis empresas tengo un pie (muy adentro) en lo técnico y otro (también hasta la rodilla) en el negocio. El otro día lo comentaba con un amiguete: ahora soy lead developer, antes he sido arquitecto de Azure para Produban (Grupo Santander), antes analista en SofCloudIT (Ingram Micro), antes… ¿cómo me puedo definir con una sola etiqueta?

Al final en todos los sitios me he encargado o he ayudado a contratar equipos técnicos, he gestionado proyectos internacionales, mantenido a los equipos focalizados en lo que tocaba hacer en cada momento, he estado pendiente de las innovaciones del entorno para ver como las podíamos aprovechar para hacer nuestro trabajo mejor, he estudiado los requisitos técnicos y de negocio, he diseñado arquitecturas, he buscado clientes, hecho presupuestos… y además siempre hablando de tecnologías variopintas.

Donde creo que más puedo aportar es donde se necesite un nexo de unión entre la tecnología y el negocio dado lo heterogéneo de mi perfil. Aunque ame la tecnología, esta, pierde importancia si no se tienen en cuenta las variables de negocio (tiempos, presupuesto, objetivos, …). Debe ser una herramienta y no un fin. Creo que no hay tanta gente que pueda hablar con un matemático que ejerza de data scientist, con un frontend que habla en javascript dialecto framework X, con un cliente que quiera comprar valor, un inversor que quiera ganar dinero o un CEO que quiera crecer, crecer y crecer.

Lo primero en que me fijo de una nueva posición es en que sea interesante, que el proyecto sea un reto y sobre todo que (aunque no sea conmigo) vaya a tener un futuro y una continuidad. Me gustan las cosas distribuidas, sobre todo los entornos cloud, me gusta pensar en como hacerlas fáciles. Se me da bien encontrar la gente adecuada para cada tarea, así como lidiar con los problemas y mantener a la vez en marcha un montón de cosas, y eso que aprobé raspado malabares en el instituto. Sé delegar (aprendí a la fuerza) y asumo responsabilidades sin estresarme, ya sea porque me las asignen o porque hace falta cuando nadie más toma las riendas. Todo el mundo se alegra de tenerme cerca en los momentos de crisis, por algo será.

Obviamente las condiciones me tienen que encajar, pero en general estudio todas las propuestas y aunque ahora estoy en el centro de Madrid todo es planteable, y no me importaría volver a la Tierruca o a la Terreta, o a cualquier otro lado siempre que sea un sitio agradable.

Con este panorama es complicado preparar un curriculum vitae, porque en general creo que si le paso a alguien mi perfil completo con todas las cosas que he hecho, se puede perder antes de llegar a lo que le interese. Por eso, por el momento he preparado dos, uno para puestos de CTO y otro para los de Team líder que son los que me están planteando ahora, porque por el momento no se me ha ocurrido una forma sencilla y versátil de plasmar toda esa información. ¿Se os ocurre a vosotros algún modo?


EDITO: Gracias a vuestros consejos, he conseguido resumir todo a un «one pager» (de momento sólo en inglés). No es especialmente bonito y por supuesto no tiene el detalle de la información que se puede ver en el perfil completo de Linkedin, pero es un avance. ¡Gracias!


Quiero elegir bien, porque me gustaría encontrar el sitio dónde más pueda aportar y como sé que con sólo dos ojos y dos oídos no se puede controlar todo, os lanzo este anuncio-petición: amiguetes que pasáis por aquí de vez en cuando ¿qué proyectos interesantes conocéis? ¿Dónde creéis que me pueden necesitar? ¿Dónde creéis que podría aportar valor?

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.

Azure Serverless

No, no es una nueva feature de Azure de la que no te hayas enterado. En este artículo vamos a entender que es «serverless» ese concepto tan en boca de todos, y los componentes de Azure que se pueden considerar parte de esta moda.

Seguir leyendo en CompartiMOSS.

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.