Muchas veces nos encontramos con compañías o equipos reticentes a contratar talento emergente (más conocido como Juniors o Trainees). Entre las justificaciones, la principal suele ser que “el equipo tiene fechas ajustadas” o “los problemas que resuelve el equipo son demasiado complejos”. Mientras que puede que sean válidas, me inclino a pensar que la mayoría de las veces es mera incapacidad de gestionar talento con diferente seniority, o temor a que la inversión no rinda frutos.
“El Software se está comiendo al mundo” sentenció Mark Andreessen en Agosto del 2011 en su famoso ensayo publicado por The Wall Street Journal. De los muchos temas que abarcó, este me parece particularmente interesante: Casi todas las empresas deberían convertirse en empresas de software. Este concepto ya se convirtió en un cliché por lo que, en lugar de extenderme sobre el tema, prefiero presentar algunos ejemplos de cómo las empresas liderando ciertas industrias, son en realidad empresas de software.
Recientemente tuve que transferir los equipos con los que estuve trabajando durante los últimos 2 años. Afortunadamente, fue porque fui ascendido y comencé a dirigir un nuevo departamento que (lamentablemente) no incluye a mis anteriores equipos. Pensando acerca de la transferencia de conocimientos, me di cuenta de que, a menos que tomara algunas notas, sería casi imposible llevar cuenta de la gran cantidad de información a transmitir. No se trataba únicamente de contar en qué estaban trabajando los equipos, sino también de transmitir la visión que tenía para el futuro de los mismos. Por este motivo, comencé a tomar notas de lo que me venía a la cabeza, con la idea de escribir un documento de transferencia como una forma de organizar las conversaciones a tener.
El abuso hacia una minoría está mal. Siempre estuvo mal, pero en esta época, es simplemente inaceptable. Un enunciado simple, ¿no? Es algo en lo que todos podríamos estar de acuerdo. Y sin embargo, el abuso sigue allí.
La primera vez que leí algo acerca de la “Ley de Conway” fue en el contexto de un excelente libro “Building Microservices” by Sam Newman. Esta ley dice que: “Cualquier organización que diseña un sistema (en el sentido amplio de su definición), producirá un diseño cuya estructura es una copia de la estructura comunicacional de la organización”.
Durante un evento realizado el pasado 3 de Mayo de 2017, en Buenos Aires German Küber dió una presentación acerca de API Management con Azure, la plataforma desarrollada y comercializada por Microsoft.
Si ya tengo su atención, déjenme decirles que este no es el artículo donde se vaya a explicar el significado de la teoría, el cual se puede encontrar en un sin fin de lugares. De todos modos se va a tratar de manera general, ya que estamos hablando del tema. Este artículo es más bien acerca de las trampas en las que cae la gente cuando intenta leer gente, y de cómo el mal uso de esta teoría puede llevarnos a perdernos mensajes importantes.
Durante un evento realizado el pasado 9 de Noviembre de 2016, en Buenos Aires Horacio “Qcho” Gomez dió una introducción a GraphQL, la tecnología desarrollada y utilizada por facebook para constuir sus propias APIs.
Es responsabilidad de un Manager de Ingeniería garantizar la salud del equipo medida en términos de cualidades tales como performance, compromiso, responsabilidad y predictibilidad (entre un montón de otras). Sin embargo, esto no puede ser forzado por el Manager. En realidad el esfuerzo del equipo, y su correcta canalización son factores decisivos para alcanzar estos objetivos. Porque estos, son objetivos, ¿o no?
Mientras leía “Elon Musk”, en un colectivo, camino a casa, no pude evitar reirme de un email que envió a todos los empleados de SpaceX acerca del mal o excesivo uso de acrónimos. El asunto del mail era “Acronyms Seriously Suck” (Los acrónimos realmente apestan) (ustedes mismos pueden resolver el acrónimo para esa línea).