{"en"=>"OurBit", "es"=>"OurBit"}

Growth Talent

Mon, 20 Jul 2020 00:00:00 +0000

We often find companies or teams reluctant to hiring growth talent (A.K.A Juniors or Trainees). Among the typical excuses, the most common ones are “the team has a very aggressive roadmap” and “the problems the team solves are too complex.” Although these might be legit, I’m biased towards thinking that most of the times it’s just management unable to working with different seniority or insecure about the ROI.

But this is a fact: We all have been growth talent (we might still be at some skills). It doesn’t matter when it was, or how talented we are right now, there was a time in which we gave our first steps in our field. It’s also a fact that, if nobody hires new talents, nobody will continue with the area once we (the experienced) retire. Finally, in fields such as software, there are more job offers than people fulfilling these. It means that starting up and training growth talent is not optional.

How to identify growth talent

In my experience at evaluating candidates, I am biased towards looking to professional achievements over academics. It’s a policy that helped me identifying and hiring great professionals and building high-performance teams. So, with that bias, how is it possible to evaluate talent without professional experience?

Although it might sound obvious, the key is looking for potential, meaning, the probability for any given person, in the proper environment, with proper mentorship, and required resources to achieve excellent results in a relatively short period (and with “relative” I mean an acceptable ROI).

There are some visible attributes we want to pay attention to when identifying potential:

Willingness/Passion for doing: professionals trying to learn and make some experience will usually have found personal and open source projects to contribute to
Actively participating in communities: a learning professional will try to connect with others (probably more experienced ones) looking for help and mentorship
Learning: to talk about what they have recently learned (workshops, tutorials, careers, etc.) can help us to understand their determination to become a professional
Analytical/logical skills: there are some attributes that, although can be learned and perfected with time, can be considered foundational for the software industry. Identifying problems, solution design, and finding defects are some capacities that most of the competent professionals count with since the beginning.

Even though this is a general description (and there could be so many other attributes to consider), it’s hard to think of the right growth talent candidate lacking all of these.

How to work with growth talent

Short (and a bit useless) answer is “just like with any other professional.” While that’s true, there might be other concepts that worth describing. For instance, if you think that a more experienced professional must have more ownership/responsibility than a growing one, I’d like to propose a different approach. All team members are responsible for their work and the team results. In other words, everyone is the owner of what they build. Instead of associating responsibility with seniority, let’s think it in the following way: the senior professional is responsible for the most complicated thing. At the same time, the growing one is equally responsible for a simpler one. Afterward, complexity will increase, but responsibility will remain the same. In a harmonious counterpoint, what will do vary is “autonomy.” Although every professional should know when is the right time to ask for assistance (not too soon, not too late), it’s expected from experts to solve a more considerable amount of problems by themselves. It’s crucial to identify agile communication channels to avoid blockers that could be very frustrating for anyone trying to evolve (in addition to jeopardizing the project roadmap).

About the company

Every time an organization shouts not having room for hiring growth talent, I use to think that it’s a symptom of a more significant issue. Let’s first stress out that people and their culture build the organization. The most experienced professionals should be balanced in their soft and hard skills. At some moment of our careers, unwillingness to mentor others is a lousy sign. However, it’s valid for a reduced group or, otherwise, we would be saying that every competent professional should be interested in teaching. But, if the entire organization (or most of it) is formed by uninterested people, there is an imminent issue: If there is a group with a null drive to perpetuate, that group is contempt to extinction. In other words, professionals simply don’t pop spontaneously and forever. Either we make them, or they won’t exist. It’s also true that we must make mentors. If companies don’t prioritize it, it’s expectable that such an important aspect might remain unattended by many of us (which would start a loop).

Of course, there are some prerequisites for being able to foster talent within a team. A good indicator is the ratio of potential talent of the organization. Different levels of complexity might require a higher or lower value for this indicator. We should also take into account the phase the company is going through. It’s different having a 1/5 ratio (one expert, four growth) on a team with momentum than one on ignition.

Boosters

Companies that already know how to foster talent usually design short term programs for massively hiring and ramping them up with an acceptable impact. These programs imply costs (salaries, trainers, materials, etc.) With maths well done, these costs have high ROIs in minimal periods (usually less than six months).

Talking to growth talent

If you are willing and have a chance, my advice for you is to come on board the industry:

Take training (there are high-quality ones for free)
Publish your exercises (GitHub, GitLab)
(Think and) Have ideas and execute them
Copy projects
Apply to some positions
Join communities and ask for guidance

This market is continuously growing (more job offers and more specialties range), and it doesn’t seem to have a soon break.

Some final thoughts

In my opinion, the term “Junior” is not very representative, and it could be a bit demotivating. It also has a (not that) tiny relationship with people’s age. Lots of companies opted for removing from the entry-level positions and started using modifiers for more expert positions (Senior, Staff, Principal, etc.) I like to think of this kind of professionals as “potential” and “new.” Those who are on their way to becoming future experts. Because of that, I propose the term “growth talent” (analogously to “growth markets”), and I hope I hear about it more often than “junior professionals” or “young professionals.”

Talento emergente

Mon, 20 Jul 2020 00:00:00 +0000

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.

Pero es fáctico que todos fuimos (o somos en algún área) talento emergente. No importa cuándo haya sido, o qué tan talentosos seamos en la actualidad, en algún momento hicimos nuestras primeras experiencias en nuestro campo. También es un hecho que si nadie contrata nuevos talentos, quienes nos dedicamos a esto, algún día nos retiraremos y nadie continuará la disciplina. Por último, en profesiones como informática, hay más oferta laboral que personas para cubrirla. Es decir que, iniciar y capacitar talento emergente no es opcional.

¿Cómo identificar talento emergente?

En mi experiencia, al momento de evaluar candidatos, me inclino por observar los logros profesionales por encima de los académicos. Es una política que me permitió identificar y contratar profesionales y formar equipos de alto rendimiento. Pero ¿cómo se puede evaluar profesionales sin experiencia previa?

Aunque parezca una obviedad, la clave se encuentra en identificar el potencial, es decir, la probabilidad de que una persona, en el entorno correcto, con el acompañamiento adecuado y los recursos necesarios, alcance resultados en un período de tiempo relativamente corto (y el “relativo” está atado directamente al retorno de la inversión). Para identificar potencial, existen algunas características observables a las cuales debemos prestar atención:

Ganas/Pasión por hacer: generalmente, los profesionales intentando aprender y ganar experiencia, habrán encontrado proyectos personales y/o comunitarios (Open Source) a los cuales contribuir.
Activos en comunidades: un profesional intentando formarse, intentará conectar con otros profesionales (posiblemente con más experiencia) en busca de ayuda y/o mentoría.
Aprendizaje: conversar acerca de lo aprendido recientemente (cursos, tutoriales, carreras, etc.) nos puede dar una idea del compromiso de la persona para convertirse en un profesional.
Capacidad analítica/lógica: hay cualidades que, si bien se perfeccionan con el tiempo, pueden considerarse fundacionales para el rubro del software. Identificar problemas, diseñar soluciones y encontrar defectos son algunas de las capacidades con las que, la mayoría de los buenos profesionales, contaron desde sus inicios.

Si bien es una generalización (y pueden existir muchas otras características a listar), sería difícil pensar en un buen candidato (parte de talento emergente) que no cuente con (al menos una de) estas.

¿Cómo trabajar con talento emergente?

La respuesta corta (y algo inútil) sería “como con cualquier otro profesional”. Pero puede haber algún que otro concepto que valga la pena detallar. Si están pensando en términos de ownership y que probablemente un profesional con experiencia deba tener más responsabilidad, les propongo un enfoque diferente: todos los miembros de un equipo son responsables por su trabajo y por el resultado del trabajo del equipo. Es decir que, todos son owners de lo que se esté desarrollando. En lugar de asociar más responsabilidad a los más expertos, puede resultar mejor pensar que un experto es responsable por algo más complejo, y un talento emergente es igual de responsable por algo más sencillo. Luego, se irá incrementando la complejidad, pero la responsabilidad será siempre la misma. En un armónico contrapunto, lo que sí irá variando es la autonomía. Si bien, todo profesional debe saber cuándo es un buen momento para pedir ayuda (ni demasiado pronto, ni demasiado tarde), es esperable que un experto pueda resolver una mayor cantidad de problemas por sí solo. Es importante tener canales de comunicación ágiles para evitar bloqueos que, además de impactar en los tiempos del proyecto, pueden resultar muy frustrantes para quien intenta crecer profesionalmente.

Acerca de la compañía

Cuando una organización dice no tener espacio para contratar talento emergente, suelo pensar que es un síntoma que expone un problema mayor. Destaquemos que la organización son las personas y su cultura. El talento más experto debería contar con un balance técnico y humano que le permita, por ejemplo, trabajar en equipo y lograr sinergia con el mismo. En cierto momento de nuestras carreras, para la mayoría de nosotros, no estar dispuestos a ser mentores es una mala señal. Pero es válido para un grupo reducido (o estaríamos afirmando que quien no esté interesado en enseñar, no es un buen profesional). Sin embargo, si el 100% de una organización (o la mayoría) tiene esa característica, nos encontramos con un problema inmediato. Si la pulsión de un grupo por perpetuarse es nula, está condenado a su extinción. En otras palabras, los profesionales no brotan infinita y espontáneamente. O los creamos o no existirán. También es cierto que hay que formar mentores. Si las empresas no lo ponen como prioridad, es esperable que un aspecto tan importante pueda pasar inadvertido para muchos de nosotros (es un ciclo).

Existen, por supuesto, algunos pre-requisitos para poder formar talento dentro de un equipo. Un buen indicador (resumen) es la proporción de talento potencial del equipo. Diferente complejidad podrá requerir un valor más o menos alto para ese indicador. También podríamos considerar los momentos de una organización. No es lo mismo una relación de 1/5 (1 experto, 4 potencial) en un equipo en movimiento que en uno en etapa de ignición.

Aceleradores

Las compañías que ya descubrieron cómo formar profesionales, suelen contratarlos de a grupos y diseñar programas de corta duración para que puedan incorporarse masivamente a sus equipos con un impacto aceptable. Estos programas representan un costo para las organizaciones (sueldos, capacitadores, materiales, etc.) que, correctamente calculado, tiene un retorno elevado y en un período mínimo (habitualmente menor a 6 meses).

De cara al talento emergente

Mi recomendación es que, si realmente tienen ganas y la posibilidad de hacerlo, se vuelquen por completo a esta profesión:

Hagan cursos (hay gratuitos de muy buena calidad)
Publiquen sus ejercicios (GitHub, GitLab).
Piensen ideas y ejecútenlas.
Copien proyectos.
Postúlense a búsquedas
Únanse a comunidades y pidan ayuda.

El mercado está en constante expansión (más oferta y más variedad de especializaciones) y no parece que vaya a frenarse pronto.

Para cerrar

El término “Junior” me resulta poco representativo e incluso puede ser algo desmotivante. Incluso, tiene una (no tan) leve relación con la edad biológica de las personas. Muchas empresas optaron por removerlo de los puestos de nivel inicial e ir agregando modificadores a los puestos más expertos (Senior, Staff, Principal, etc). Me gusta pensar en este tipo de profesionales como el potencial, lo nuevo, y aquellos que están en vías de convertirse en los futuros expertos. Por este motivo propongo el término “talento emergente” (en coordinada analogía con el concepto de “mercado emergente”) y espero escucharlo más a menudo que “profesionales junior” o “jóvenes profesionales”.

Humans of the Digital Transformation

Mon, 02 Sep 2019 00:00:00 +0000

“Software is eating the world” sentenced Mark Andreessen on August 2011 on his famous essay published by The Wall Street Journal. He made references to a wide range of topics, from which I find this one particularly interesting: Virtually every company should become a software company. This concept has become a cliché, and I’m trying not to make it super extense, but providing some examples on how software companies are leading their (not software) industries (let’s call their vertical industries for abbreviation).

Years ago, while planning your vacations, you probably looked for accommodation by calling or booking directly with the hotel. Some companies like booking.com made it easy by letting you look up at several hotels on a single search. However, the game-changer was Airbnb. Airbnb provides accommodation by owning literally zero places for you to stay. What Airbnb has, is an amazingly available software that let owners publish their homes, and users book them.

What about Uber? How many cars do they own? How many drivers do they employ?

Could we think of Spotify? Do they (or did they) create music? Do musicians work for them?

Amazon, Netflix, the uprising Fintechs?

What Andreessen didn’t address (at least on that essay) is, what would happen with people working on businesses on those displaced industries. That’s probably because this transformation doesn’t seem to restrict people from accessing their usual jobs. It might force a revaluation, in any case.

More recently, progress in automation, robotics, and AI stroke again and raised the eternal question, “What will people work at, once robots replace us?” Before diving in, I must warn the reader: I’m a technology advocate. I apply common sense, arguments, and thoughts, but I’m biased toward accepting what technology offers. So, let’s assume that it is true that humans need to work or the world will fall apart (arguable, right?) Will technology, and specifically software, replace us or will it make our lives better? Can jobs be transformed in a way that we are still involved?

Opinion: Yes, but it means that software will become a commodity. A skill people will depend on, like elemental maths, or reading and writing. In that sense, in the future, not knowing software will be comparable to analphabetism. Nobody would recommend stopping using language, so we have a more inclusive talent pool. Au contraire, the recommendation is to fight analphabetism by educating as many people as possible.

So this is the real gap: How will this workforce be educated in time? Are universities prepared for reducing the go-to-market of a professional? Should we speed up a new educational paradigm that is more pragmatism oriented? Moreover, in a distant future, shouldn’t it be elementary education teaching this? Luckily, around the world, there are already companies and organizations working on it. There are of all shapes and colors: Paid, free, freemium, for self-taught, or academia persona, young and starting or professionals changing careers. I have started a GitHub repo to curate (with the community) a collection of resources for learning software development.

Companies and professionals will need to shift, as well. When I started my professional career, 20 years ago, and these days too, companies look for full-blooded developers. Even people seem to make a massive distinction between those who can code and the “real developers,” born of Von-Neumann’s machines and forged in the eternal fire of the very source code. If software becomes a commodity, some people might treat it like any other skill. The same way that there are mathematicians and literati, when the time comes, we will have software developers and people who code. Moreover, that’s fine.

Not everything will be just peachy, though. As with any other transformation, there will be some people unable or unwilling to get on board. What to do for them? Who are responsible, public or private sectors? Both? Best case scenario, incomes will be covered. Will these people be able to cope with the lack of purpose? Will society, as a whole, be ready to embrace a new life paradigm? I’m unclear about this. However, I’m clear about not letting them on their own. We are responsible for this transformation, in both good and bad ways.

Will it reach every single job? I don’t think so. I don’t believe that absolutely every profession will need it. Once again, think about the one that is farthest from maths (today) or think about music, for instance. Is it far from maths? Not at all. Do all musicians think in terms of maths? Neither.

Humanos de la transformación digital

Mon, 02 Sep 2019 00:00:00 +0000

“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.

Años atrás, al planear nuestras vacaciones, probablemente buscábamos alojamiento llamando o reservando directamente con el hotel. Algunas compañías, como booking.com, lo hicieron más fácil permitiéndonos comparar varios hoteles con una sola búsqueda. Sin embargo, quien vino a revolucionar la industria fue Airbnb. Airbnb provee alojamiento siendo dueños de literalmente CERO lugares para que nos quedemos. Lo que sí tiene Airbnb es un software altamente disponible que permite a los usuarios reservar las casas que los dueños han publicado con ese mismo software.

¿Que hay con Uber? ¿Cuántos autos tiene? ¿A cuántos conductores contrataron?

¿Podemos pensar en Spotify? ¿Crean o crearon música? ¿Cuántos músicos trabajan para ellos?

¿Amazon, Netflix, las Fintechs en surgimiento?

Lo que Andreessen no cubrió (al menos en este ensayo) es qué ocurrirá con la gente que trabaja en las industrias desplazadas. Probablemente se deba a que esta transformación no parece alterar la forma en la que la gente accede a sus trabajos. A lo sumo, podría forzar una revaloración de los mismos.

Más recientemente, los avances en automatización, robótica e IA reaparecieron para volver a levantar la eterna pregunta: ¿De qué va a trabajar la gente cuando los robots nos hayan reemplazado? Antes de sumergirnos en esta pregunta, debo advertir al lector: Soy un promotor de la tecnología. Uso el sentido común, argumentos y pensamiento, pero tengo un sesgo hacia aceptar lo que la tecnología ofrece. Entonces, asumamos que es cierto que los humanos necesitan trabajar para que el mundo no caiga a pedazos (debatible, ¿no?), la tecnología, y específicamente el software, ¿nos va a reemplazar o va a mejorar nuestras vidas? ¿Se pueden transformar nuestros trabajos de forma tal que sigamos involucrados?

Opinión: Si, pero significa que el software se convertirá en un producto básico. Una habilidad de la cual la gente va a depender, como las matemáticas elementales, o leer y escribir. En ese sentido, en el futuro, no saber de software será comparable con el analfabetismo. Nadie recomendaría dejar de utilizar el lenguaje para tener una fuerza productiva más inclusiva. Por el contrario, la recomendación es luchar contra en analfabetismo educando a tanta gente como sea posible.

Entonces aquí se encuentra la verdadera brecha: ¿Cómo hacer para educar a esta fuerza productiva a tiempo? ¿Están preparadas las universidades para reducir el tiempo en que un estudiante está listo para comenzar su carrera profesional? ¿Deberíamos acelerar la llegada de un nuevo paradigma de educación más pragmático y orientado a la producción? Más aún, en un futuro más distante, ¿No debería ser parte de la educación primaria? Afortunadamente, ya hay compañías y organizaciones alrededor del mundo que se encuentran trabajando en esta problemática. Las hay de todas las formas y sabores: Pagas, gratuitas, híbridas, para autodidactas o académicos, jóvenes o profesionales que quieran cambiar de carrera. Comencé este repositorio de GitHub para curar (con la comunidad) una colección de recursos para aprender a desarrollar software.

Las Empresas y los profesionales deberán hacer un cambio también. Cuando yo comencé mi carrera profesional, 20 años atrás, y en estos días también, las empresas buscan desarrolladores pura sangre. Incluso la gente parece hacer una gran distinción entre aquellos que pueden programar, y los “programadores reales”, nacidos de las máquinas de Von-Neumann y forjados en el fuego eterno del mismísimo código fuente. Si el software se vuelve un producto básico, algunas personas podrían tratarlo como a cualquier otro conocimiento. De la misma manera que hay matemáticos y literatos, cuando llegue el momento, habrá desarrolladores de software y gente que escribe código. Más aún, eso está bien.

Pero no todo será color de rosas. Como con cualquier otro tipo de transformación, habrá gente que no pueda o no quiera ser parte de ella. ¿Qué hacer por y para ellos? ¿Quién es responsable, el sector público o privado? ¿Ambos? En el mejor escenario, los ingresos estarán cubiertos. ¿Podrá esta gente lidiar con la falta de propósito? ¿Estará lista la sociedad en su conjunto para abrazar un nuevo paradigma de vida? Esto aún no lo tengo claro. Lo que si comprendo es que no debemos dejarlos solos. Somos responsables por esta transformación, para bien y para mal.

¿Aplicará a todo tipo de trabajos? No lo creo. No creo que absolutamente toda profesión vaya a necesitar estos conocimientos. Nuevamente, piensen acerca de la profesión que más se aleje de las matemáticas (hoy). O ni siquiera. Piensen en la música, por ejemplo. ¿Está alejada de las matemáticas? Para nada. ¿Todos los músicos piensan en términos de matemáticas? Tampoco.

Team handoff document

Mon, 11 Mar 2019 00:00:00 +0000

I recently had to hand off the teams I had been managing for the last 2 years. Luckily, it’s because I was promoted and started running a new department that doesn’t include those teams. Thinking about the knowledge transfer to be made, I realized that I wouldn’t be able to track the tons of information to be transmitted if I didn’t make notes. This wasn’t just about what the teams had been doing, but also about what I had come to envision for them in the future. So, I spent a week collecting all the topics that came to mind in order to write a handoff document for each team, as a way to better organize the discussions around this process.

Once finished, I thought I had a great idea for an article. Upon googling about it, I ran into Lara Hogan’s post on the topic, which had a lot of the same ideas in, to my liking, better writing than I thought myself capable of. However, seeing as my process and approach are different, I didn’t feel discouraged but rather inspired to put my own experience into writing. And of course, since I was already a follower of her blog, I would need to think if I hadn’t read about it in the past, and forgot it just to remember it in the shape of “new ideas.”

The process (recipe)

Recap topics to be transmitted. Take one week just to make notes.
Write the handoff document.
Send it to the new manager (write a proper introduction to declare the purpose of the document).
Wait for a confirmation of reading.
Have the first meeting to go through the document. Let the new manager ask questions so the process is more focused on the information she prioritizes rather than what you’d like to share.
Detect which topics require a specific meeting and if more people should be involved.
Run the meetings.
Stay for 1 sprint (we are kind of doing scrum) to show the process and dynamics. Let the new manager drive.
Redefine the next and last 1:1 with your team members to become 1:1:1 (new manager, team member, and you): make a proper introduction, but let them interact. Jump in to clarify. The idea is to have you 3 in the same room at least once so there are no doubts regarding what has been said. It’s also great to assure continuity on some topics such as career path, ongoing projects, etc.
Fade out until you are invisible. That’s how you know that the team you worked so hard to build is safe in informed hands.

The document

Here is a template with the sections I included and a description of each. You might need to tweak or even create a new one from scratch, depending on your particular needs.

Manager Handbook

Description

Provide a quick description of the document, the goals, and intentions. Feel free to include your motivation (even if that means adding a link to this post).

Disclaimer

The new manager probably knows how to do her job. It is important to clarify that it’s not your intention to teach, train, or mentor but to share knowledge regarding a specific context. Mine went like this: “This document aims to transfer knowledge for a particular context, which means, describe the state of the art of different aspects of the team. You will find personal opinions regarding management and the result of building a team answering to a specific management style. By all means, it is not my intention to impose that management style on you. You will probably detect opportunities for improvement (or simply things you’d like to do differently) by yourself. The description of the current scenario should help you to mind the gap and analyze what impact those changes could have so you can make an informed decision. Additionally, I am intending to be as concise as possible so we can use this document during the hand-off period. That means this document is not a substitute for the knowledge transfer and handover processes, but a guide to organizing them.”

You should always include one. It’s free and it helps the reader understand how the document is structured

The Team

Dynamic

Explain the logic of the team. How are they working? What are they used to do? What are their core values? Are they autonomous and self-governed? How do they handle communications? Consider splitting the topics into subsections.

Individuals

Take some time to write about each team member. Take into account that, even if this document should be confidential, leaks happen. Don’t put information that should only be transmitted during a meeting.

I repeated this structure for each team member:

Person (Role)

Context

What is she doing on the team? Is she taking more responsibilities than the job description ones? How did she get here? Tell the story.

Action Items

Describe the action items that came up from the last performance review (or any other milestone). Continuity is also about following these up.

Strengths and Weaknesses

It’s important for the new manager to understand to which areas she should give more space, and to which ones she should pay more attention.

The Process

Describe how the team organizes its work. Is it divided into iterations? Which ones? Years, quarters, sprints? What is the source of requirements (backlog)? Which methodology is being used? How does the team plan? Who estimates? How is the team capacity being calculated? Do you have recurrent meetings? Do these meetings have a particular structure? Which metrics are being taken? How are these being analyzed?

On-going projects

Describe the big assignments the team is already working on. What is the state of each project? Is there a story worth telling behind that? Is there any documentation to read? Who is working on each project?

Vision

Share your strategic plans for the team. Include stakeholders to consider, if you have already spoken about it with them, if it’s just an idea or something that has been explored, etc.

Conclusion

I’ve recently applied this to two teams. It took some time to put all the information together but it’s worth it. At the end of the process, it saved more time, we didn’t miss anything important, and important topics are now documented. Furthermore, it’s an excellent way to guarantee that the transition goes as smoothly as possible and that the teams you have worked so hard to build are safe in informed hands. Additionally, this is a great and professional way of “wishing” the new managers good “luck”!

You can read this post on Life at Avature Blog too

Documento de transferencia del equipo

Mon, 11 Mar 2019 00:00:00 +0000

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.

Cuando terminé, pensé que era una buena idea para un artículo. Luego de googlear un poco, encontré este post de Lara Hogan acerca del tema, el cual estará por siempre mejor escrito que el mio. Sin embargo, como mi enfoque y proceso fueron distintos, esto no me desalentó, por el contrario, me inspiró a escribir mi propia experiencia. Y por supuesto, como soy un lector de su blog, tendré que repensar si no lo había leído antes, para luego olvidarlo, y más tarde recordarlo en forma de “nueva idea”.

El proceso (receta)

Anotar todos los temas a transmitir. Una semana solo tomando notas.
Escribir el documento.
Enviarlo al nuevo manager (escribiendo una introducción que explique el propósito del documento).
Esperar confirmación de lectura.
Tener una primer reunión recorriendo el documento. Dejar que el nuevo manager haga preguntas. De esta manera el proceso está más enfocado en sus necesidades en lugar de en nuestros deseos de compartir algo que consideramos importante.
Detectar los temas que requieren una reunión específica y, si es necesario, involucrar más gente.
Tener dichas reuniones.
Quedarse 1 sprint (estamos aplicando algunas prácticas de Scrum) para mostrar el proceso y la dinámica. Dejar que el nuevo manager maneje.
Redefinir laa siguientes 1:1 con los miembros de nuestro equipo para que se transformen en 1:1:1 (nuevo manager, miembro del equipo, y uno): Hacer una presentación adecuada, pero dejarlos interactuar. Interrumpir si fuera necesario aclarar/acotar. La idea es que estén los 3 en una misma sala al menos una vez para evitar dudas acerca de lo que fue y lo que no fue dicho. También es una buena manera de asegurar la continuidad de ciertos temas tales como planes de carrera, proyectos pendientes, etc.
Desaparecer gradualmente. De esa forma sabemos que el equipo para el que trabajamos tanto, está en buenas e informadas manos.

El documento

Este es un template con las secciones que incluí y una descripción de cada una. Quizás necesites hacer algunos cambios o incluso escribir uno desde cero, dependiendo de tus necesidades puntuales.

Manual del Manager de

Descripción

Incluir una descripción breve del documento, sus objetivos e intenciones. Es recomendable también incluir la motivación para hacerlo (incluso si eso significa incluir un link a este artículo).

Consideraciones

Es probable que el nuevo manager sepa cómo hacer su trabajo. Es importante aclarar que no es nuestra intención enseñar, entrenar, o ser un mentor, sino transferir conocimiento respecto de un contexto puntual. Por ejemplo, mi versión incluía: “Este documento apunta a transferir conocimientos en un contexto, es decir, describir el estado del arte de diferentes aspectos del equipo. En el mismo se incluyen opiniones personales acerca de management y el resultado de haber construido un equipo siguiendo un estilo puntual de management. De ninguna manera es mi intención la de imponer ese estilo. El nuevo manager podrá observar y probablemente detectar oportunidades de mejora o simplemente aspectos que le gustaría conducir de forma diferente. La descripción del escenario actual debería serle útil para comprender las diferencias y analizar cómo podrían impactar dichos cambios, y de esta forma, tomar una mejor decisión. Adicionalmente, es mi intención ser tan conciso como sea posible. De esta forma, podemos utilizar este documento durante el período de transición. Esto significa que este documento no es un reemplazo para el proceso, sino una guía para organizarlo”.

Tabla de contenidos

Siempre se debería incluir una. Es gratis y ayuda al lector a reconocer la estructura del documento.

El equipo

Dinámica

Explicar la lógica del equipo. ¿Cómo trabajan? ¿Qué están acostumbrados a hacer? ¿Cuáles son sus valores? ¿Son autónomos y autogobernados? ¿Cómo manejan la comunicación? Considerar dividir estos temas en subsecciones.

Individuos

Dedicar algo de tiempo para escribir acerca de cada miembro del equipo. Tener en cuenta que si bien este documento debería ser confidencial, la información a veces se filtra. No incluir nada que debería ser transmitido únicamente durante las reuniones con el nuevo manager. Las siguientes subsecciones se repiten para cada miembro del equipo:

Persona (Rol)

Contexto

¿Qué está haciendo en el equipo? ¿Tiene más responsabilidades que las del su rol? ¿Cómo llegó hasta aquí? Narrar la historia.

Acciones a tomar

Describir las acciones a tomar que surgieron durante la última revisión de rendimiento (performance review). Darle seguimiento a estas acciones es parte de la continuidad entre managers.

Fortalezas y debilidades

Es importante que el nuevo manager entienda en qué áreas debería dar más espacio, y en cuáles debería prestar más atención.

El proceso

Describir cómo el equipo organiza su trabajo. ¿Se divide en iteraciones? ¿Cuáles? ¿Años, trimestres, Sprints ? ¿Cuál es el origen de los requerimientos (backlog)? ¿Qué metodologías se están usando? ¿Cómo se lleva a cabo la planificación? ¿Quién estima? ¿Cómo se calcula la capacidad del team? ¿Hay reuniones recurrentes? ¿Tienen alguna estructura particular? ¿Qué métricas están tomando? ¿Cómo se están analizando?

Proyectos en desarrollo

Describir los proyectos en los que está trabajando el equipo actualmente. ¿En qué estado están? ¿Hay alguna historia detrás que valga la pena compartir? ¿Hay documentación? ¿Quién está trabajando en cada proyecto?

Visión

Compartir lo planes estratégicos para el equipo. Incluir puntos de contacto (stakeholders) a considerar, si ya hubo contacto con ellos, si es solo una idea o algo que ya fue explorado, etc.

Conclusión

Apliqué recientemente este proceso a dos equipos. Si bien me tomó algo de tiempo juntar toda la información y redactar el documento, al final del proceso, ahorré más tiempo del que habría utilizado en reuniones sin guía, no quedó nada importante afuera, y los temas importantes quedaron documentados. Mejor aún, me resulta una manera excelente de garantizar que la transición sea tan prolija como sea posible y que los equipos que a los que invertí tanto esfuerzo, queden seguros y en manos informadas. Adicionalmente, es una gran forma de “desearle buena suerte” a los nuevos managers.

También podés leer este artículo en Life at Avature Blog

Doing my part (this far)

Thu, 08 Mar 2018 00:00:00 +0000

Abuse against any minority is wrong. It has always been wrong but these days it is simply unacceptable. Do you see how simple that enunciate is? This is something we might all agree and yet, abuse is still there.

I am a white man in my 30s and it is hard for me to find my place in this fight. I am a child of the patriarchy and I’m sure I’m full of (sh)it. I’m also sure that I don’t want to be part of the problem. I’m also sure that I want to be part o the solution.

I’m posting this article on International Women’s Day for a reason. We are very used to thinking that today we must give a present to “our women”. It’s a day to “treat them like the princesses they are”. Well, irony aside (they are not “ours” and let’s not even dive into the princess thing), we better get rid of these thoughts soon. We can be nice to anybody anytime. Let’s take advantage of this day to think about what it means (https://en.wikipedia.org/wiki/International_Women%27s_Day).

In Argentina, where I live, violence against women is alarming. Every week we watch the news to find that another woman has been kidnapped, abused, and murdered. There are groups protesting and fighting for this problem to be taken seriously by the authorities. These groups have their thoughts, voices, and methods and, the society is not fully supportive of these. That’s not necessarily bad, opinions are just that. But unfortunately, the society is forgetting to keep supporting the fight against gender-based violence regardless of any affiliation. I’m oversimplifying a really complex situation to focus on something that I think it’s important. There are people, like me, that understand that the change also requires from us to introspect, to recognize in which way we are doing it wrong, and to start changing it soon. Doing this is hard (even if we are honestly willing to), and we might need help. We might need to be educated.

Several years ago, my wife and I put these topics on our agenda. Since then, we have been discussing every now and then. I knew by that time about the big stones. I knew that there was violence, discrimination, gender-bias. But there were tons of finer concepts that were way beyond my observable universe. She was incredibly patient with me while teaching me about it. Most of these impossible concepts are now facts to me and I am enormously thankful for that.

It’s still hard to find a way of doing my part, but here is my attempt: Let’s take a well-known-terrain, focus on learning what can be done there, and start doing it. I know companies. I’ve been working at different companies my entire career. I’m currently an Engineering Manager cause and/or consequence of being interested in building organizational cultures. I’ve seen how companies can educate inside out on topics with social impact. Even though gender-based violence is not starting within companies, other concepts that expose patriarchal thoughts could be easily spotted: sexual harassment, unequal pay, and bias for accepting an idea if it comes from a man, just to mention a few.

As part of the role, I should be doing my best to guarantee a safe workplace. So, I spent the last year educating myself about gender-bias problems and strategies to prevent or detect and solve these. During this time I’ve read countless articles and selected some of them to share with you. Some considerations:

I don’t agree 100% with all the contents I’m sharing, but I consider all of them, food for thought. The selection criteria were not based on my opinions but the on value I think they can add to the reader.
I’m placing a comment for every article. I’m not trying to explain anything based on my thoughts, since I don’t consider myself an authorized voice to do so. Of course, I have my own opinion and I love sharing it (feel free to reach me via Twitter if you are curious about it). But the same way my opinions were not part of the selection criteria, I’m trying to get rid of them for the purpose of describing the articles.

I hope that you are doing your best already, but if not, I hope you find this helpful in order to improve.

Articles

Being an effective ally to women and non-binary people

https://codeascraft.com/2016/10/19/being-an-effective-ally-to-women-and-non-binary-people/

This is my favorite one because of 2 reasons:

I’ve always felt that there is some lack of definitions around this subject, and that complicates communicating and educating.
It basically answers my biggest doubt about the subject: How to contribute.

I’m a woman in tech and this is what I want in a company

https://code.likeagirl.io/i-am-a-woman-in-tech-and-this-is-what-i-want-in-a-company-f6177569a287

The list is sharp, clear and still argumentative. While reading it I had an amazing breakthrough: These are all things I also want for me when evaluating a company. Well, isn’t that the true meaning of equality? I understood that being part of the solution is also wanting the same that she wants, and doing my job in order to have the companies I work for, fulfilling these requirements.

This is how sexism works in Silicon Valley

https://medium.com/the-cut/this-is-how-sexism-works-in-silicon-valley-affd91ad8eb

A really detailed deposition about things that happened to Ellen Pao. The narration tells about moments so absurd that I had troubles to process. It’s so outrageous that I had a pulse to write her to ask if there was any story-telling-license. I didn’t. By the way, I don’t think I would have had that pulse if the story was told by a man. Do you see how deep the patriarchal mindset could be buried? I’m ashamed of that and I hope I can keep detecting these glitches until I get rid of them. Well, her career is fascinating and while researching about it, I found that this article is part of her book: “Reset: My Fight for Inclusion and Lasting Change” which I’ll start reading as soon as I finish the one I’m currently working on.

Tech’s dirty (not so little) secret

https://code.likeagirl.io/techs-dirty-not-so-little-secret-86c154ca5b23

If you found Ellen Pao’s article shocking, I’m sad to communicate that it’s not an isolated case. For data-lovers, this article tells us that from a group of 800 surveyed women, 300 have suffered some kind of harassment. Numbers are discouraging but let’s do something about it. Let’s remember that if we are not part of the solution… (see the next article).

Running out of time

https://code.likeagirl.io/running-out-of-time-6cefc7b5bcf6

Written by a former colleague, he reflects about his role in relation to this problematic, how we need to start by assessing and recognizing our limitations and always be willing to understand, learn and change.

I’m an ex-google woman tech leader and I’m sick of our approach to diversity

https://medium.com/the-mission/im-an-ex-google-woman-tech-leader-and-i-m-sick-of-our-approach-to-diversity-17008c5fe999

A complex and thoughtful critic about the approach we are using to tackle inclusion issues. The author arguments that having pipelines with 90% men, forcing to have more balanced teams requires lowering the bar, hiring more less-qualified-women giving arguments to the ones who think that “women are not as good as men in tech”.

Running a business with boobs

https://medium.com/fuzzy-sharp/running-a-business-with-boobs-the-things-i-never-say-ac58a48c674

Closed mindset doesn’t seem to be solved with success cases. This article tells us that not only doesn’t gender bias end when a woman achieves a milestone in her career, but also this gets worst.

The myth of the cool tech girl

https://code.likeagirl.io/the-myth-of-the-cool-tech-girl-7868fa63769b

A bit shocking. Personally, it made me think about colleagues I worked with and that I could partially identify with the description. I wonder if they felt that way and if I did what everything I could have to make that change.

Reflecting on one very strange year at Uber

https://www.susanjfowler.com/blog/2017/2/19/reflecting-on-one-very-strange-year-at-uber

The first of many articles exposing that culture at Uber wasn’t at its best. It started with sexism but after a train of “unfortunate episodes” Uber’s CEO, Travis Kalanick, ended up being removed from this position by June 2017. Had you forgotten about this? We shouldn’t tolerate this behavior from anybody. Not from the newest employee, nor the company CEO.

If gender and race are artificial constructs, does diversity matter?

https://extranewsfeed.com/if-gender-and-race-are-artificial-constructs-does-diversity-matter-61e34c47c097

An analysis a bit (too much for me) philosophical about how the society assigns weights to what should be “pure objectivity”, and how the diversity model is constructed over a paradox that indicates that it should be understood but invisible at the same time. An article I wanted to quit reading several times but that reaches some interesting conclusions.

You Are Not Equal. I’m Sorry

https://medium.com/@dinachka82/about-your-poem-1f26a7585a6f

Is the answer to this article (which in my opinion should be linked in the response). I read the original post and I found a couple of weak points. In the answer, a lot of information. History about how some of the rights were acquired and recognition to the women that fought for these.

Haciendo mi parte (hasta ahora)

Thu, 08 Mar 2018 00:00:00 +0000

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í.

Soy un hombre blanco en mis 30s y se me hace difícil encontrar mi lugar en esta lucha. Soy un hijo del patriarcado y estoy seguro que estoy lleno de patriarcado. También estoy seguro de que no quiero ser parte del problema. También estoy seguro de que quiero ser parte de la solución.

En Argentina, donde yo vivo, la violencia contra la mujer es alarmante. Todas las semanas vemos en las noticias un nuevo caso de alguna mujer secuestrada, violada y asesinada. Hay grupos manifestándose y luchando para que este problema sea considerado seriamente por las autoridades. Estos grupos tienen sus pensamientos, sus voces y sus métodos, y la sociedad no está completamente alineada con los mismos. Esto no es necesariamente malo, son solo opiniones. Pero desafortunadamente, la sociedad se está olvidando de seguir acompañando la lucha contra la violencia de género dejando de lado cualquier afiliación. Estoy simplificando una situación bastante compleja para enfocarme en algo que considero importante. Hay gente, en donde me incluyo, que entiende que el cambio necesita de nosotros. Necesita que nos miremos hacia adentro, que reconozcamos lo que estamos haciendo mal, y que cambiemos rápido. Lograrlo es difícil (incluso si estamos intentándolo de verdad), y puede que necesitemos ayuda. Puede que necesitemos ser educados.

Varios años atrás, mi esposa y yo empezamos a tratar estos temas. Desde ese momento, tenemos algunos debates esporádicos. Yo ya conocía los problemas más grandes. Sabía que había violencia, discriminación y desigualdad de género. Pero había muchos conceptos más finos que estaban muy lejos de mi universo observable. Ella fue increíblemente paciente conmigo mientras me enseñó sobre estos temas. La mayoría de esos conceptos (alguna vez) imposibles, hoy son hechos para mi, y por eso, le estoy inmensamente agradecido.

Sigue siendo difícil encontrar la forma de hacer mi parte, pero acá va un intento: Buscar un terreno conocido, enfocarse en aprender lo que se puede hacer allí y empezar a hacerlo. Yo conozco las empresas. Estuve trabajando en empresas durante toda mi carrera. Actualmente soy Manager de Ingeniería causa y/o efecto de mi interés en construir culturas organizacionales. Vi como en las empresas se puede educar de adentro hacia afuera, algunos temas de impacto social. A pesar de que la violencia de género no empieza (generalmente) dentro de las empresas, en las mismas se pueden identificar problemas que exponen pensamientos patriarcales: diferencias salariales, acoso sexual y sesgo por aceptar una idea si viene de un hombre, solo por mencionar algunos.

Como parte del rol, yo debería estar haciendo lo mejor que puedo para garantizar un ambiente de trabajo “seguro”. Por este motivo, pasé el último año aprendiendo acerca de problemas vinculados con inequidad de género y estrategias para prevenirlos o detectarlos y resolverlos. Durante este tiempo leí incontables publicaciones y elegí algunas para compartir con ustedes. Algunas consideraciones:

No estoy de 100% de acuerdo con el contenido de todos los artículos que estoy compartiendo, pero los considero material para reflexionar. El criterio de selección no está basado en mis opiniones sino en el valor que creo que pueden aportar al lector.
Escribí un comentario por cada publicación. Con este comentario no estoy intentando explicar conceptos porque no me considero una voz autorizada para hacerlo. Por supuesto que tengo una opinión formada y me encanta compartirla (contáctenme vía twitter si quieren saber más acerca de lo que pienso). Pero de la misma manera en que mis opiniones no formaron parte del criterio de selección, intenté despojarme de las mismas para escribir las descripciones de las publicaciones.

Espero que ya estén haciendo lo mejor que puedan, y si no, espero que esta información les sea útil para mejorar.

Artículos

Ser un aliado efectivo para mujeres y gente no-binaria

https://codeascraft.com/2016/10/19/being-an-effective-ally-to-women-and-non-binary-people/

Este es mi favorito por 2 motivos:

Siempre sentí que hay falta de definiciones acerca del tema y que esto complica la comunicación y la educación.
Básicamente responde mi mayor pregunta: Cómo ayudar.

Soy una mujer en tecnología y esto es lo que quiero de una compañía

https://code.likeagirl.io/i-am-a-woman-in-tech-and-this-is-what-i-want-in-a-company-f6177569a287

La lista es clara, concisa y a la vez, llena de argumentos. Mientras la leía descubrí algo interesante: Son todas cosas que yo también quiero ver en una empresa cuando la estoy evaluando. Ese podría ser un gran indicador de “igualdad”. Me hizo entender que parte de la solución es querer lo mismo que ella quiere y hacer mi trabajo para que las empresas en donde trabajo cumplan con esos requerimientos.

Así funciona el sexismo en Silicon Valley

https://medium.com/the-cut/this-is-how-sexism-works-in-silicon-valley-affd91ad8eb

Una declaración detallada acerca de cosas que le sucedieron a Ellen Pao. La narración cuenta momentos tan absurdos que se me hicieron difíciles de procesar. Es tan indignante que tuve un impulso por escribirle para preguntar si había algún tipo de adorno o licencia poética. No lo hice. Dicho sea de paso, no creo que habría tenido el mismo impulso si la historia la contaba un hombre. ¿Qué tan profundo se puede esconder el pensamiento patriarcal? No estoy orgulloso de esto que cuento, y espero poder seguir detectando estas fallas hasta deshacerme de ellas. En fin, su carrera es fascinante y mientras investigaba un poco, descubrí que el artículo es parte de su libro “Reset: My Fight for Inclusion and Lasting Change” que empezaré a leer tan pronto como termine con el que estoy leyendo.

El oscuro (no tan pequeño) secreto de la industria de la tecnología

https://code.likeagirl.io/techs-dirty-not-so-little-secret-86c154ca5b23

Si encontraron chocante el artículo de Ellen Pao, lamento informar que no es un caso aislado. Para los amantes de los datos, este artículo nos cuenta que de un grupo de 800 mujeres, 300 han sufrido algún tipo de acoso. Los números son desalentadores pero hagamos algo al respecto. Recordemos que si no somos parte de la solución . . . (ver el siguiente artículo).

Quedándonos sin tiempo

https://code.likeagirl.io/running-out-of-time-6cefc7b5bcf6

Escrito por un ex-compañero, su reflexión acerca de su rol en relación con esta problemática, cómo necesitamos empezar a evaluarnos, reconocer nuestras limitaciones y estar dispuestos a entender, aprender y cambiar.

Soy una ex-lider técnica (mujer) en google y estoy cansada de nuestro enfoque de diversidad

https://medium.com/the-mission/im-an-ex-google-woman-tech-leader-and-i-m-sick-of-our-approach-to-diversity-17008c5fe999

Una crítica compleja y consciente al enfoque que se utiliza para solucionar problemas de inclusión. La autora explica que teniendo fuentes de candidato donde el 90% son hombres, forzar tener equipos más balanceados requiere bajar la vara y contratar más mujeres menos calificadas, lo que termina alimentando a aquellos que sostienen que “las mujeres no son tan buenas como los hombres en tecnología”.

Dirigiendo un negocio con tetas

https://medium.com/fuzzy-sharp/running-a-business-with-boobs-the-things-i-never-say-ac58a48c674

La mentalidad cerrada no parece solucionarse con casos de éxitos. Este artículo nos cuenta que no solo la inequidad de género no termina cuando una mujer alcanza un hito en su carrera, sino que por el contrario, empeora.

The myth of the cool tech girl

https://code.likeagirl.io/the-myth-of-the-cool-tech-girl-7868fa63769b

Algo chocante. Personalmente me hizo pensar en algunas colegas con las que trabajé y que puedo identificar parcialmente con la descripción. Me pregunto si se sentían así y si hice todo lo que estaba a mi alcance para que eso no fuera así.

Meditando acerca de un año muy raro en Uber

https://www.susanjfowler.com/blog/2017/2/19/reflecting-on-one-very-strange-year-at-uber

El primero de muchos artículos que expusieron que la cultura en uber no estaba pasando por su mejor momento. Todo comenzó con un problema puntual de sexismo, que luego de una sucesión de “episodios desafortunados” terminaron con la expulsión de Travis Kalanick, CEO de Uber allá por Junio del 2017. Te habías olvidado de esto? No deberíamos tolerar este tipo de conductas de nadie. Ni de la persona más nueva en la empresa, ni del CEO de la misma.

Si el género y la raza son construcciones artificiales, ¿realmente importa la diversidad?

https://extranewsfeed.com/if-gender-and-race-are-artificial-constructs-does-diversity-matter-61e34c47c097

Un análisis algo filosófico (demasiado, en mi opinión) acerca de cómo las sociedades asignan un peso subjetivo a características objetivas, y cómo el modelo de diversidad se construye sobre una paradoja que indica que debería ser entendido pero invisible a la vez. Un artículo que quise dejar de leer varias veces, pero que llegó a algunas conclusiones interesantes.

Lo siento, no sos igual

https://medium.com/@dinachka82/about-your-poem-1f26a7585a6f

En respuesta a este artículo (que, en mi opinión, debería estar linkeado en la respuesta). Leí la publicación original y encontré un par de puntos bastante débiles. En la respuesta, mucha información e historia acerca de cómo se consiguieron algunos derechos y el reconocimiento a las mujeres que pelearon por los mismos.

That's not our code

Tue, 22 Aug 2017 00:00:00 +0000

The first time I read about the “Conway’s Law” was in the context of an excellent book: “Building Microservices” by Sam Newman. The law states that: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”.

When talking about Microservices, we usually say that not only are these a way to get independent components, but also to have autonomous teams building and operating those components. It seems we are saying that some properties from our systems (or components, or services, or applications) are also desirable for our organization. Furthermore, speaking about teams’ autonomy, we could end up saying that the same way components should be highly cohesive and lowly coupled to others, teams should mimic that behavior. Well, while this sounds tempting, it could also be extremely dangerous for an Engineering organization.

For components, it is true that we want to encapsulate behaviors in a way that we can request something to be done by knowing how to ask (let’s remember that lowly coupled is not “totally decoupled”). Great encapsulation is usually measured by how good the implementation details are hidden: Component A does not know anything about Component B implementation.

Let’s imagine how this could end up being transposed to a couple of teams. Team A owns Component A and Team B owns Component B. Component A requests a service from Component B by hitting its API. Everything goes smoothly until Component B fails. At that stage, the plot thickens: For Team B, the bug is a minor one, while Team A considers it critical. Now let’s make it spicy: Imagine Team B is overloaded so, nevermind about the criticality, the bug will not be fixed in an acceptable time. Instinctively, anybody could say “Hey, let’s have anybody from Team A fixing this bug on the component owned by Team B” and, assuming that Team A has some capacity to tackle it, that would be a viable solution. However, that would violate the Encapsulation principle at team level.

If we had a strict policy about this, our organization would be limited by a ridiculously inflexible dogma. A component must avoid knowing its peers’ implementation details. That’s good design. But at an organizational level, it’s just poor judgment. As a developer, it won’t hurt to go further and see how that works.

We could re-think this by considering ownership as an organizational concept, but not necessarily an operational one. “This is mine or yours” works like a charm when organizing modules on a monolith, or services on distributed applications. However, when operating, that should be more like a rule of thumb. We should be more strict when working on something planned (like our roadmap) and more flexible for unplanned situations (like emerging bugs).

We can learn from great experiences involving open source libraries. When we start using one of these libraries, we are promised that by doing so, we will be able to focus on our functionality and forget the complexity of handling insert whatever thing that library is supposed to do transparently. Suddenly, you find a bug, and it will kill your architecture unless you hack a smart workaround in your beautiful code that can easily be removed once the bug is fixed. But that’s not the way open source works. Instead of that, you should invest that time in fixing the bug and making the library better. If you do so, you will:

Avoid a hack in your code.
Avoid a hack in others’ code.
Make the library more robust.
Become a contributor and encourage others to follow your leads.
~~Win a Nobel price~~ just kidding, you are just doing your job, but you might get some recognition for that, too.

However, to do so, you will need to understand more than just how that library works. You will need to know how it is built.

Going back to our Engineering organization, you might be thinking: we are a couple of dozens of teams with around ten devs each. It is not the best use of my time to spend it reading the entire code just in case. That is correct. Actually, if every developer did that, there would not be any new features or bugs fixed. Ever.

Luckily, that’s not necessary either. As an Engineering organization, we must ensure that:

Teams that own components are free enough to quickly ramp somebody up on a small piece of them.
The code is as easy to understand as possible. After all, a good and clean code should be readable.
Tech-leads or Architects are involved and they understand and build cross-teams code.
Devs are always curious and eager: “That’s not ours” should be an organizational decision and not just a bad habit.
This happens as little as possible: Breaking the ownership policy should be measured. Tendencies should be identified and acted upon. After all, it is true that this situation is less efficient than working on our own well-known code.
Teams change: Rotate people, take them outside the comfort zone. Most of the time, people want to change from time to time. If you find a group of people that are not willing to do so, show them how good could it be. If the attitude remains, don’t hesitate in going further.

There are other ways Conway’s Law will appear that won’t be this harmful to your Engineering organization. For instance, the described scenario could be seen as “load balancing”.

Keeping the right mindset and the correct culture is key in order to have an organization that understands their boundaries and when it is right to cross them.

Ese código no es nuestro

Tue, 22 Aug 2017 00:00:00 +0000

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”.

Cuando hablamos de Microservicios, solemos decir que su implementación no es solo una manera de obtener componentes independientes, sino también equipos autónomos que construyan y operen dichos componentes. Parecería que además estamos diciendo que algunas propiedades de nuestros sistemas (o componentes, servicios, aplicaciones) son también deseables para nuestra organización. Más aún, hablando de equipos y autonomía, podríamos concluir en que, de la misma forma en que los componentes deberían ser altamente cohesivos y ligeramente acoplados, los equipos deberían imitar dicho comportamiento. Mientras que esto parece una buena idea, puede ser un concepto extremadamente peligroso para una organización de Ingeniería.

Para componentes, es cierto que queremos encapsular su comportamiento de una forma en que podamos solicitar que algo se haga tan solo sabiendo cómo pedirlo (recordemos que ligeramente acoplado no significa “totalmente desacoplado”). Un buen nivel de encapsulamiento se suele medir en base a qué tan bien están ocultos los detalles de implementación: El componente A no conoce nada de la implementación del componente B.

Pensemos la misma situación para un par de equipos de trabajo. El equipo A es responsable del componente A y el equipo B del componente B. El componente A solicita un servicio al componente B mediante su API. Todo va bien hasta que el componente B falla. En este momento, el escenario se vuelve más interesante: para el equipo B, el bug es menor, mientras que para el equipo A es crítico. Ahora agreguemos pimienta: El equipo B está trabajando al máximo de su capacidad por lo que, sin importar la criticidad, el bug no se va a corregir en un tiempo aceptable. Instintivamente, cualquiera podría proponer “Pongamos a alguien del equipo A a arreglar el bug del componente del equipo B” y, asumiendo que el equipo A tiene algo de capacidad para ocuparse del tema, sería una solución factible. Sin embargo, esto va en contra del principio de Encapsulamiento a nivel de equipo.

Si tuviéramos una política estricta al respecto, nuestra organización estaría limitada por un dogma ridículamente inflexible. Se debe evitar que un componente conozca los detalles de implementación de sus pares. Eso es buen diseño. Pero a un nivel organizacional, es más bien una falta de criterio. Como desarrollador, no me va a lastimar investigar un poco más y saber como funciona lo que está del otro lado.

Podríamos repensar esta situación considerando que el ownership es un concepto organizacional pero no necesariamente operacional. “Este código es tuyo” funciona perfecto cuando estamos organizando módulos en un monolito, o servicios en aplicaciones distribuidas. Pero, al momento de operar, esto debería ser solo una “recomendación”. Tendremos que ser más estrictos con esto cuando se trate de trabajo planificado (como un roadmap) y más flexibles para situaciones no planificadas (como bugs que van apareciendo).

Podemos aprender de buenas experiencias que involucran librerías open source. Cuando empezamos a trabajar con alguna de estas librerías, nos prometen que al hacerlo, vamos a poder enfocarnos en nuestra funcionalidad y olvidarnos de la complejidad de manejar inserte lo que sea que esa librería se supone que está haciendo de forma transparente. En algún momento, encontrás un bug en la librería que amenaza toda la arquitectura, salvo que agregues un workaround elegante en tu hermoso código, que pueda ser removido una vez que el bug esté arreglado. Pero esa no es la forma en que se trabaja en el mundo open source. En lugar de esto, deberías invertir tu tiempo en arreglar el bug y mejorar la librería. Al hacerlo:

Evitás un hack en tu código.
Evitás un hack en el código de otras personas (que usan la librería).
Hacés la librería más robusta.
Te convertís en un contributor e incentivás a otros a que sigan tu ejemplo.
~~Ganás un Nobel~~ no tanto, solo estás haciendo tu trabajo, pero podrías obtener algo de crédito por eso también.

Pero, para poder hacerlo, no te va a alcanzar con entender cómo trabaja la librería. Vas a necesitar conocer cómo fue construida.

Volviendo a nuestra organización de Ingeniería, seguramente estás pensando: Somos un par de docenas de equipos con alrededor de diez desarrolladores por equipo. No creo que el mejor uso de mi tiempo sea estar leyendo todo el código por si acaso. Correcto. De hecho, si todos los desarrolladores hicieran eso, no habría ni una sola feature nueva ni un bug arreglado. Nunca.

Por suerte esto tampoco es necesario. Como una organización de Ingeniería, debemos asegurarnos de que:

Los equipos responsables de componentes tengan disponibilidad para ayudar a alguien a entender rápidamente partes de los mismos.
El código sea tan fácil de entender como sea posible. Después de todo, un código limpio y bien hecho, debería ser legible.
Los líderes técnicos o arquitectos estén involucrados, entiendan y construyan código para varios equipos.
Los desarrolladores sean curiosos y siempre proactivos: “Este código no es nuestro” debería ser una decisión organizacional y no solamente un mal hábito.
Esto ocurra tan poco frecuentemente como se pueda: Se debe medir la cantidad de veces que se rompe la política de ownership. Deberían identificarse tendencias y se debería tomar acción en base a las mismas. Después de todo, es cierto que esta situación es menos eficiente que trabajar en nuestro propio código (que conocemos mejor).
Los equipos cambien: La gente tiene que rotar, salir de la zona de confort. La mayoría de las veces, la gente quiere un cambio cada tanto. Si encontrás un grupo de gente que no está dispuesta a rotar, mostrales los beneficios de hacerlo. Si la actitud persistiera, no dudes en ir más lejos.

Hay otras formas en que la “Ley de Conway” puede aparecer, sin ser dañina para tu organización de Ingeniería. Por ejemplo, el escenario descripto podría verse como “balanceo de carga”.

Mantener un buen mindset y la cultura correcta son puntos cruciales para tener una organización que entienda sus límites y cuándo es correcto ir más allá.

{"en"=>"OurBit", "es"=>"OurBit"}

Growth Talent

How to identify growth talent

How to work with growth talent

About the company

Boosters

Talking to growth talent

Some final thoughts

Talento emergente

¿Cómo identificar talento emergente?

¿Cómo trabajar con talento emergente?

Acerca de la compañía

Aceleradores

De cara al talento emergente

Para cerrar

Humans of the Digital Transformation

Humanos de la transformación digital

Team handoff document

The process (recipe)

The document

Manager Handbook

Description

Disclaimer

Table of contents

The Team

Dynamic

Individuals

Person (Role)

Context

Action Items

Strengths and Weaknesses

The Process

On-going projects

Vision

Conclusion

Documento de transferencia del equipo

El proceso (receta)

El documento

Manual del Manager de

Descripción

Consideraciones

Tabla de contenidos

El equipo

Dinámica

Individuos

Persona (Rol)

Contexto

Acciones a tomar

Fortalezas y debilidades

El proceso

Proyectos en desarrollo

Visión

Conclusión

Doing my part (this far)

Articles

Being an effective ally to women and non-binary people

I’m a woman in tech and this is what I want in a company

This is how sexism works in Silicon Valley

Tech’s dirty (not so little) secret

Running out of time

I’m an ex-google woman tech leader and I’m sick of our approach to diversity

Running a business with boobs

The myth of the cool tech girl

Reflecting on one very strange year at Uber

If gender and race are artificial constructs, does diversity matter?

You Are Not Equal. I’m Sorry

Haciendo mi parte (hasta ahora)

Artículos

Ser un aliado efectivo para mujeres y gente no-binaria

Soy una mujer en tecnología y esto es lo que quiero de una compañía

Así funciona el sexismo en Silicon Valley

El oscuro (no tan pequeño) secreto de la industria de la tecnología

Quedándonos sin tiempo

Soy una ex-lider técnica (mujer) en google y estoy cansada de nuestro enfoque de diversidad

Dirigiendo un negocio con tetas

The myth of the cool tech girl

Meditando acerca de un año muy raro en Uber

Si el género y la raza son construcciones artificiales, ¿realmente importa la diversidad?

Lo siento, no sos igual

That's not our code