si solo vas a leer una cosa de esta nota que sea esta: algunas personas trabajan lento porque piensan que a todas las tareas de su to-do list le tienen que poner la misma dedicación. creo que trabajar inteligentemente es saber qué items de mi lista determinan el éxito de mi proyecto y cuáles no. Gracias. A continuación otras ideas sobre velocidad.
escribo esto porque muchas veces le digo a mi equipo que quiero que seamos más rápidos y me doy cuenta de que no se entiende por qué. estas son algunas de las cosas que creo que piensan cuando les pido que sean más rápidos: 1) esta persona no entiende lo difícil que es lo que estoy haciendo 2) no puedo hacerlo más rápido porque lo voy a hacer mal 3) si lo hago mal o imperfecto esto quiere decir que trabajo mal 4) la manera de trabajar bien es obsesionarme con la calidad de lo que hago 5) esta persona me está pidiendo que haga algo a medias 6) esta persona me está pidiendo que trabaje después de hora para tener esto antes.
ninguna de estas cosas es cierta. quiero escribir sobre esto en parte porque quiero hacer el ejercicio de pensar qué es velocidad para mí y por qué me resulta tan natural algo que para muchos es contraintuitivo.
(creo que debería hablar de por qué la velocidad importa pero en vez de hacer eso voy a linkear a cuando hablé de por qué creo que importa hacer cosas imperfectas. creo que es otra forma de hablar de lo mismo).
por qué creo que las personas a veces son lentas
1) no saben que la velocidad importa. creo que la primera razón es que nadie antes les ha dicho que la velocidad importa. seguramente porque vienen de entornos laborales con otro pace o porque en Latam no hay sentido de la urgencia en el mundo startup. esta semana le dije a alguien de mi equipo que tenía que resolver algo más rápido y me dijo que le preocupaba que le pidiera eso, que le hacía preguntarse si nos estábamos quedando sin plata o a la empresa le estaba yendo mal. esa interpretación es super razonable porque en el ecosistema startup de Latam no hay sentido de la urgencia. no hay otros haciendo lo mismo que vos (o haciendo productos mejores, o sacando features más rápido). no miramos lo que los demás hacen. no está muy bien visto competir (al menos en Argentina). por fuera de eso por definición una startup siempre se está quedando sin tiempo. esa debería ser razón suficiente para valorarlo.
2) piensan que todas las tareas de su to-do list tienen la misma importancia. voy a dar un ejemplo: estoy tratando de cerrar una venta. cerrar una venta implica varios pasos: hacer una presentación, elaborar un ROI, tener y preparar reuniones, armar presupuestos. si pienso que todos los items de esta lista tienen la misma importancia le voy a dedicar la misma energía a todos. pero el diseño de la presentación, por ejemplo, no tiene la misma importancia que hacer un ROI. un problema que veo es que algunas personas piensan que a todas las cosas que hacen le tienen que poner la misma dedicación. estoy absolutamente a favor del perfeccionismo pero solo deberíamos intentar ser perfectas en las cosas que importan. creo que trabajar inteligentemente es saber qué items de mi lista determinan el éxito de mi proyecto y cuáles no. es importante no dedicarle la misma atención a todo y es importante desarrollar la intuición de qué es lo que importa y qué no.
3) trabajan con herramientas o sistemas ineficientes. creo que es más fácil entender esto cuando hablamos de ingeniería pero creo que lo mismo aplica a procesos mal diseñados. cuando lo que tengo que hacer me toma el doble de tiempo porque hacerlo me genera muchísima carga cognitiva voy a ser lenta. en el código es fácil de identificar cuándo pasa esto: es en los momentos en que una programadora tiene que hacer una tarea y la mitad del tiempo se lo pasa pensando en si hacer lo que tiene que hacer o si reescribirlo todo. yo creo que en estos casos puede ser mejor invertir el tiempo de corregir el sistema de raíz en pos de ganar velocidad en el futuro.
4) no recortan, hacen todo lo que está en su to-do list. hace un montón de años me enseñaron el sistema que se llama get shit done que dice que frente a una tarea lo primero que hay que preguntarse es si la puedo delegar (si se puede, lo hago); si no puedo tengo que preguntarme si la puedo hacer en menos de 5 min (si se puede, lo hago en el momento); si no se puede lo tengo que calendarizar y si no lo puedo calendarizar lo tengo que borrar de mi lista porque eso quiere decir que nunca lo voy a hacer. una parte de ser rápidas es borrar items de nuestra lista. es importante recortar sin asco y saber que si algo importa va a volver.
5) no se ordenan en unidades pequeñas de trabajo. una manera muy normal de ser lentas es perder el tiempo. perder el tiempo a veces es trabajar en cosas que no son importantes ahora. a veces frente a un proyecto grande tenemos la tendencia a comenzar por la parte que nos parece más difícil. es muy importante hacer lo contrario: hay que empezar por la unidad más chiquita y la más fácil y rápida de completar. esto importa porque una tarea terminada nos da la energía para tomar otra tarea. en vez de comenzar por lo grande y difícil hay que comenzar por lo pequeño y lo fácil (el low-hanging fruit). la otra cosa que importa es que el trabajo que tenemos que hacer esté ordenado en bullets chiquitos y asequibles. y es importante ordenarlos de menor mayor (en orden de tiempo que me va a tomar completarlos) y comenzar de a uno.
6) piensan que algo bien hecho es algo que tomó mucho tiempo. yo creo que algo que tomó mucho tiempo, por el contrario, es algo que estamos haciendo bajo supuestos que pueden ser incorrectos. el problema de tardar mucho en completar algo en que estamos a ciegas. recién vamos a recibir feedback cuando tengamos el producto final. y si el producto final nos tomó 3 meses eso puede querer decir que estuvimos 3 meses trabajando bajo supuestos incorrectos. otra forma de pensar en la rapidez es pensar que lo que estamos haciendo es compartir nuestro proceso. hay algo de ego en querer compartir el producto terminado (no queremos que nos critiquen por algo incompleto). es importante que trabajemos en no sentir eso porque nos hace perder el tiempo (además de que es un fantasma: nada le gusta más al otro que la vulnerabilidad de que les muestres un producto incompleto para que te ayuden a construirlo).
7) resuelven problemas que piensan que van a tener en el futuro en vez de problemas que tienen ahora. creo que acá la pregunta importante es cuántos usuarios realmente vamos a tener de acá a los próximos 6 meses. normalmente los roles del lado del negocio tienen alguna estimación de esto. si es un negocio b2b sabemos que la meta de crecimiento mensual es 20% y que eso quiere decir X número de users al mes. hay que armar un sistema para ese número de users. de nuevo creo que es más fácil pensarlo en programación. para mí un indicador de que unx dev que sufre de este problema es que hable de 'escalar' o los problemas de la escala y que justifique su estrategia con la escala. cosas que se justifican con la 'escala': armar sistemas complejos de colas, notificaciones, medición, etc. obviamente la línea es muy fina entre cuándo estas cosas importan y cuándo no. por eso es importante entender el uso real que van a tener las cosas que estoy desarrollando.
habiendo listado todas las cosas que creo que hacen que algunas personas sean lentas podría listar las cosas que creo que nos hacen ser más rápidas. en pos de cumplir con mi propio consejo no lo voy a hacer porque sé que esta nota así como está suma mucho más ahora que yo dedicándole otros 3 días de trabajo. espero que sirva como está y espero poder seguir aprendiendo de este tema para volver a escribir en el futuro.