Name: TechLead Conference 2023
Start: 2023-03-09T15:00:00.000Z
End: 2023-03-10T20:00:00.000Z

Lera

Petra vos

Sophie Kolbe

Stefan Wille

JSNation Conference 🗓 June 1-5, 2023

Thibault Van den Broecke

Batuhan NARCI

Kevin

Robert

Ricardo Machado

Thijs Broerse

João Portela

Ian Sutherland

Michal Štrajt

Oury DIALLO

Mel Moe

Kyle

Renata Rodrigues

Aman Beg

Denis Radin

Alex Perez

Norm Crandall

Riccardo

Patrick ORGAN

Cesar Villalobos

Andrea Martz

Sofia Markoglou

Yevhen

Ludovic Bouges

Lia Moreira

Michael Chiche

Rishi Narang

Ser un Tech Lead suena como mucho trabajo. Y no del tipo de codificación divertida tampoco. ¿Por qué querrías eso? ¿Cómo se siente cuando lo consigues?En esta charla, Swizec explica por qué dio el paso hacia el liderazgo técnico, cómo cambiaron sus prioridades y por qué significa que está haciendo más ingeniería que nunca. Un mundo completamente nuevo donde escribir código es la parte fácil.

Sobre convertirse en un Tech Lead

The role of a Tech Lead involves shaping the roadmap, helping the team be more effective, and working on important projects. Lessons learned include encouraging idea sharing, avoiding taking on all the work, and focusing on delegation. Tech Leads focus on the outcome, involve the team in decision-making, and make plans based on how different pieces will interact. The role of a Tech Lead is to focus on engineering and guide the team in figuring out how the whole system should fit together. Architecting can become problematic when it loses touch with the coding part, resulting in implementation issues.

Tech lead sounds like a lot of work. And not the fun coding kind either. Why would you ever want that? What does it feel like when you get it?In this talk Swizec explains why he took the step towards technical leadership, how his priorities changed, and why it means he’s doing more engineering than ever. A whole new world where writing code is the easy part.

On Becoming a Tech Lead

Swizec Teller

Seamos realistas: la deuda técnica es inevitable y reescribir tu código cada 6 meses no es una opción. La refactorización es un tema complejo que no tiene una solución única para todos. Las aplicaciones de frontend son particularmente sensibles debido a los frecuentes cambios de requisitos y flujos de usuario. Nuevas abstracciones, patrones actualizados y limpieza de esas viejas funciones - todo suena genial en papel, pero a menudo falla en la práctica: los todos se acumulan, los tickets terminan pudriéndose en el backlog y el código legado aparece en cada rincón de tu base de código. Por lo tanto, un proceso de refactorización continua es la única arma que tienes contra la deuda técnica.En los últimos tres años, he estado explorando diferentes estrategias y procesos para refactorizar el código. En esta charla describiré los componentes clave de un marco para abordar la refactorización y compartiré algunos de los aprendizajes acumulados en el camino. Espero que esto te ayude en tu búsqueda de mejorar la calidad del código de tus bases de código.

Un Marco para Gestionar la Deuda Técnica

Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.

Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

A Framework for Managing Technical Debt

Alex Moldovan

Tus habilidades de comunicación afectan tus perspectivas de carrera, el valor que aportas a tu empresa y la probabilidad de tu promoción. Esta sesión te ayuda a comunicarte mejor en una variedad de situaciones profesionales, incluyendo reuniones, mensajes de correo electrónico, propuestas y presentaciones.

Comunicación Efectiva para Ingenieros

Today's Talk covers the four building blocks of communication: people, message, context, and effective listening. It emphasizes the importance of considering the perspective of others and tailoring messages to the recipient. The Talk discusses different types and channels of communication, and the need to align them with the intended message. It also highlights the significance of soft skills in communication and provides techniques for effective communication and assessing soft skills in tech interviews. Cross-cultural communication and the impact of bluntness are explored as well.

Your communication skills affect your career prospects, the value you bring to your company, and the likelihood of your promotion. This session helps you communicate better in a variety of professional situations, including meetings, email messages, pitches, and presentations.

Effective Communication for Engineers

Naz Delam

“Tal vez estoy engañando a todos... No soy lo suficientemente bueno para esto, y en este punto, es cuestión de tiempo hasta que todos se den cuenta” estas podrían ser las palabras que cruzan por tu mente mientras tu compañero de trabajo te felicita por hacer otro trabajo fantástico al entregar una nueva característica. A medida que creces en tu carrera, también lo hace tu incertidumbre. Dedicas horas extra, aprendes todas las nuevas tecnologías y te unes a todas las iniciativas que puedes, pero al final del día, nunca parece suficiente. En este punto, ese sentimiento está guiando tus acciones y decisiones. Es lo que está impulsando tu carrera. Solo una pregunta persiste: ¿Realmente eres un impostor?

Desarrollo Impulsado por el Síndrome del Impostor

Imposter syndrome is a common experience that can lead to self-doubt and feeling like a fraud. The speaker shares their personal journey with imposter syndrome in school and throughout their career in software development. They discuss the challenges and doubts they faced, as well as the strategies they used to overcome imposter syndrome. The importance of support from managers, celebrating achievements, and sharing experiences to help others are highlighted. The talk emphasizes the need to embrace imposter syndrome and use it as a motivator for personal growth.

“Maybe I’m fooling everyone… I’m not good enough for this, and at this point, it is a question of time until everyone figures it out” these might be the words that cross your mind as your coworker compliments you for doing another fantastic job at delivering a new feature. As you grow in your career, so does your uncertainty. You put in the extra hours, learn all the new technologies, and join all the initiatives you can, but at the end of the day, it never feels enough. At this point, that feeling is leading your actions and decisions. It is the thing that is driving your career. Only one question persists: Are you really an imposter?

Imposter Syndrome-Driven Development

Daniel Afonso

Todos hemos experimentado la solicitud de empleo que nos obliga a realizar una prueba de codificación en línea. Tienes que repasar tus algoritmos, estructuras de datos, complejidad temporal y al final estás estudiando como si fuera un examen universitario. Ahora que somos nosotros los que generalmente entrevistamos a los candidatos, una buena pregunta para hacer es: "¿las pruebas de codificación en línea son el mejor indicador de la competencia y habilidad de un candidato?" En esta charla, exploraremos:<ul><li>- Los problemas de las pruebas similares a Leetcode</li><li>- Lo que deberíamos buscar en los candidatos</li><li>- Cómo la programación en pareja es la mejor manera de ver cómo un candidato trabajaría con el equipo</li><li>- Además, una pequeña demostración de una entrevista de programación en pareja remota</li></ul>

Por qué Leetcode está obsoleto y la programación en pareja para las entrevistas es el camino a seguir

The Talk discusses the problems with online coding tests and the benefits of pair programming interviews. It emphasizes the importance of hiring and growth, including creating a positive interview experience and considering the cost of hiring. The job of a software developer extends beyond coding and requires multiple skill sets. Pair programming provides a more accurate assessment of skills required for software development. The Talk also covers implementing a tennis scoring system and customizing pair programming interviews for different roles and levels.

We’ve all experienced the job application which required us to do an online coding test. You have to brush up on your algorithms, data structures, time complexity, and by the end of it you’re cramming as if it was a university exam! Now that we’re the ones usually interviewing candidates, a good question to ask is: “are online coding tests the best indicator of a candidate’s proficiency and competence?” In this talk, we’ll explore:<ul><li>- The pitfalls of Leetcode-like tests</li><li>- What we should be looking for in candidates</li><li>- How pair programming is the best way to see how a candidate would work with the team</li><li>- Plus a little mini demo on a remote pair programming interview</li></ul>

Why Leetcode is Dead and Pair Programming for Interviews is the Way Forward

Mo Khazali

Casi nadie en el mundo de la tecnología disfruta cuando hay mucha deuda técnica. Y a la mayoría de nosotros nos gustaría que no haya demasiada. Pero, ¿cómo entendemos cuánta tenemos exactamente? ¿Dónde se encuentra exactamente? ¿Qué parte de ella es realmente la más molesta? ¿Cuál sería el beneficio para nosotros si dedicamos tiempo a deshacernos de ella? Cuando se trata de planificar cómo abordar tu deuda técnica, todas estas preguntas merecen respuestas. Especialmente cuando nos preguntan sobre el retorno de la inversión en nuestros esfuerzos para eliminar cosas antiguas molestas y construir un nuevo módulo o servicio brillante. Además, cuando trabajamos en la deuda técnica, queremos abordar primero las partes más impactantes, ¿verdad? Esta charla trata sobre todo eso: cómo medimos nuestra deuda técnica, cómo interpretamos los resultados de estas mediciones para que nos den las respuestas a las preguntas correctas, y cómo guiamos nuestra toma de decisiones con esas respuestas.

Una Guía Rápida y Completa para Medir tu Deuda Técnica y Utilizar los Resultados

This Talk discusses the measurement and interpretation of tech lead, focusing on tech debt. Tech debt is a tool to temporarily speed up development but can have negative consequences if not managed properly. Various tech debt metrics, including heuristic metrics and second-tier metrics, can help identify and manage tech debt. Tech debt interest is crucial for measuring the impact of tech debt and allows for prioritization. It is important to collect and analyze tech debt metrics to ensure software and team health.

Hardly any people in Tech like when there's a lot of tech debt. And most of us would like when there's not too much of it. But how do we understand how much exactly we have of it? Where exactly does it sit? Which part of it is actually the most annoying? What would be the benefit for us if we spend time getting rid of it? When it comes to planning how you tackle your tech debt, all these questions deserve answers. Especially when we're asked about the ROI on our efforts to eliminate some annoying legacy stuff and build a new shiny module or service. Also, when we work on tech debt, we do want to tackle the most impactful parts of it first, don't we? This talk is about all of that: how we measure our tech debt, how we interpret the results of these measurements so that they give us the answers to the right questions, and how we guide our decision making with those answers.

A Quick and Complete Guide to Measuring Your Tech Debt and Using the Results

Anton Kazakov

Sé que los desarrolladores sienten dudas al elegir el rol de IC sobre un gerente o viceversa. Hablaré sobre mi propio camino para encontrar mi propósito haciendo las cosas que me gustan.

Propósito: Lo que aprendí al renunciar como líder de equipo dos veces

The Talk discusses the importance of finding purpose and learning from past experiences in software development. It emphasizes the need to test different areas and reflect on experiences to find direction. Understanding one's purpose and the value it brings is crucial. Mistakes are seen as valuable insights for improvement.

I know developers feel doubts of choosing the IC role over a manager or vice versa. I'll tell about my own road how to find own purpose doing things I like.

Purpose: What I Learned from Stepping Down as Team Lead Twice

Alex Ptakhin

A medida que trabajamos para construir la mejor solución de ingeniería de software posible, nos encontramos con muchas decisiones que debemos tomar. A diario. A veces esto implica conversaciones muy activas y apasionadas, que a veces pueden tomar un camino negativo, creando un mal ambiente en el equipo. Además, es una gran pérdida de tiempo. Pero ¿qué pasaría si esas decisiones diarias pudieran ser mucho más fáciles y simples? En esta charla intentaré abordar y eliminar los puntos dolorosos de la toma de decisiones en la ingeniería de software y mostraré cómo ayudé a mi equipo a beneficiarse de un proceso de toma de decisiones más ligero.

La Teoría del Juego en la Toma de Decisiones de Software

Today's talk is about the Game Theory of Software Decisions, exploring how game theory can be applied to software development. The speaker shares tips on creating a productive team environment and effective decision-making. They emphasize the importance of letting go of unimportant things and focusing on what's best for the project. The talk also discusses handling coding dilemmas and decision-making, suggesting strategies such as defining KPIs and consulting a neutral jury. The speaker concludes by emphasizing the importance of staying rational, bringing data, and maintaining professionalism in software development.

As we’re working to build the best possible software engineering solution, we encounter many decisions we must make. Daily. Sometimes this involves very active and passionate conversations, which might sometimes go down the negative path, creating a bad atmosphere in the team. On top of that, it’s a huge waste of time. But what if those daily decisions could be much easier and simple? In this talk I’ll try to attack and eliminate the pain points of decision making in software engineering and will show how I helped my team benefit from a lighter decision making process.

The Game Theory of Software Decision Making

Ziv Levy

Comienzas como desarrollador junior, entregando líneas de código felizmente. La vida es fácil, te encanta tu trabajo, estás aprendiendo mucho. Y luego alguien se acerca a ti y dice: "Necesitamos un líder técnico para un nuevo equipo, y tú eres la persona más experimentada disponible". O te vuelves miserable o encuentras tu nuevo llamado, pero tu trabajo ya no es realmente lo que era antes. Y luego alguien se acerca a ti y dice: "Estamos buscando un nuevo gerente de ingeniería, y tú eres la persona más experimentada disponible".¿Es realmente el camino de carrera más óptimo? ¿Qué podríamos hacer de manera diferente? Veamos tus talentos y los talentos necesarios para el trabajo.Hay muchos trabajos diferentes en tecnología: escribir código, liderar equipos, gestionar personas y proyectos, ayudar a otros a usar tu tecnología, enseñar, investigar, depurar.

¿Realmente tienes que convertirte en un gerente para avanzar en tu carrera?

The Talk discusses the misconception that software career is a linear progression and shares a story of a software engineer turned engineering manager who wasn't happy. It explores the complexity of describing personality types in software engineering and the importance of considering talents, job meaning, and skill development when making career decisions. The Talk also emphasizes the significance of finding meaning in one's job, job crafting, and exploring different career paths. It concludes with the idea of challenging assumptions, assessing talents, and introspection for effective job crafting.

You start as a junior developer, happily delivering lines of code. Life is easy, you love your job, you are learning a lot. And then someone approaches you saying: "We need a tech leader for a new team, and you are the most experienced person available". You either become miserable or find your new calling, but your job is not really what it was before. And then someone approaches you saying: "We are looking for a new engineering manager, and you are the most experienced person available".Is that really the most optimal career path? What could we do differently? Let's have a look at your talents and the talents needed for the job.There are many different jobs in tech: writing code, leading teams, managing people and projects, helping others use your technology, teaching, research, debugging.

Do You Really Have to Become a Manager to Advance in Your Career?

Marek Kalnik

Muchos de nosotros, al cambiar de trabajo o aceptar una promoción, nos sentimos abrumados por la oferta y o bien no pedimos más o pedimos un porcentaje más que la oferta. Hablemos sobre por qué eso no es suficiente y cómo podemos cambiar nuestra actitud hacia la negociación.

Negocia como si tu vida dependiera de ello

The Talk discusses the importance of negotiation, particularly in relation to the gender pay gap and gender parity. It emphasizes the need to address global reasons for negotiation and the impact of inflation and the cost of living. The Talk also highlights the values to consider when negotiating and provides tips on preparing for negotiation, making offers, and discussing perks. Recommended reading and references on negotiation are also provided.

A lot of us when changing jobs or accepting a promotion feel overwhelmed by the offer and either don't ask for more or ask a percentage more than the offer. Let's talk about why that's not enough and how we can change our attitudes towards negotiation.

Negotiate Like Your Life Depends on It

Shivangi Das

Vamos a desechar todo y empezar de nuevo. Suena genial, ¿verdad? Aunque esto puede sentirse muy bien, rara vez acelera algo. Te mostraré por qué una reescritura completa generalmente no es lo que quieres.

La Trampa de la Reescritura

The Talk discusses the 'rewrite trap' in software development, where the urge to start from scratch often leads to poor outcomes. It emphasizes the importance of understanding the existing project before making big technical decisions and the benefits of gradual improvement. The Talk also highlights the challenges and pitfalls of a complete rewrite, such as false sense of productivity, problems with edge cases, and the accumulation of tech debt. It stresses the need to understand the system and its influences, cater to the needs of stakeholders outside of engineering, and focus on creating value.

Let's throw away everything and start fresh. Sounds great, right? While this can feel very good it rarely speeds up anything. I'll show you why a complete rewrite is usually not what you want.

The Rewrite Trap

Philipp Giese

La mentoría tiene la reputación de llevar mucho tiempo y trabajo. Pero, ¿y si no fuera así? Aquí te presentamos formas de conseguir un mentor, ser un mentor y cómo navegar por ello. Siempre he trabajado en conseguir mentores en cada etapa de mi carrera como ingeniero. Tengo mentores que ni siquiera saben que lo son. Pero me gusta así. Explicaré cómo conseguir un mentor en cualquier etapa de tu carrera como ingeniero y cómo ser un buen mentor/mentorado.

Cómo conseguir un mentor sin decírselo

This Talk explores the topic of mentorship, focusing on how to get a mentor without explicitly asking. It discusses the qualities of a good mentor and the importance of being a good mentee. The benefits of mentorship include personal growth, career advancement, and fostering a collaborative work culture. Strategies for finding mentors and mentees are provided, along with tips for navigating mentorship conversations. Overall, mentorship is seen as a powerful tool for learning, growth, and mutual support in the field of software engineering.

Mentorship has a reputation of taking a lot of time and work. But what if it wasn't? Here are ways to get a mentor, be a mentor, and how to navigate it. I have always worked on getting mentors in every corner of my engineering career. I have mentors that do not even know they are my mentor. But I like it that way. I will go into how to get a mentor at any stage of your engineering career and how to be a good mentor/mentee.

How to Get a Mentor Without Telling Them

Erin Fox

Si eres un ser humano, es probable que en algún momento de tu vida te hayas sentido como un impostor. Uno de los mayores problemas con este síndrome es que es fácil quedarse atrapado con este sentimiento. No es fácil superar el síndrome del impostor. Requiere ofrecerte compasión y vulnerabilidad en lugar de juicio y autoduda. Pero... ¿cómo lograrlo exactamente? Analizaremos técnicas para lograr esto y superar el síndrome.

Cómo superar el síndrome del impostor

If you're a human being, chances are you felt like an imposter at some point in your life. One of the biggest risks we have to deal with in our day-to-day life is failure. Acknowledge your feelings of self-doubt and be specific about why you're feeling this way. Embrace self-compassion and vulnerability to overcome imposter syndrome. Take action by reminding yourself of your qualifications, seeking help from colleagues, and setting realistic goals. Embrace vulnerability, build confidence, and create a safe environment for your team.

If you’re a human being, chances are you’ve felt like an impostor at some point in your life. One of the biggest issues with this syndrome is that is easy to get stuck with this feeling. One does not simply overcome Impostor Syndrome. It requires offering yourself compassion and vulnerability instead of judgment and self-doubt. But... how exactly do you achieve that? We'll look at techniques for achieving this and overcoming the syndrome.

How to Overcome Impostor Syndrome

Ursula Cervantes

El campo de las relaciones con los desarrolladores o DevRel está aumentando rápidamente en popularidad, con roles para defensores de desarrolladores, evangelistas, gerentes de programas y directores que parecen aparecer en todas partes. Es posible que también tenga colegas que trabajen en este campo. DevRel es una disciplina única alineada con todas las partes del negocio, desde ingeniería y producto, hasta marketing e incluso ventas, y actúa como un puente entre la empresa y la comunidad de desarrolladores en general. Nuestros incentivos alineados con el liderazgo de ingeniería son especialmente evidentes en el hecho de que existimos para servir y permitir a las audiencias de desarrolladores, ya sean externas o internas.Para los equipos de ingeniería, trabajar en estrecha colaboración con sus equipos de DevRel brinda una gran oportunidad para comprender mejor a sus audiencias de desarrolladores, elevar el perfil y las habilidades de sus colegas, y hacer que su empresa sea más atractiva para la contratación. Sin embargo, a pesar de que muchos equipos de DevRel son altamente técnicos, debido a la falta de enfoque percibida de DevRel, nuestros departamentos a menudo son descartados como "solo marketing" por parte de la ingeniería.En esta charla responderé la pregunta de "qué hacen las personas de DevRel" y presentaré algunos enfoques sobre cómo DevRel e ingeniería pueden colaborar mejor y derribar barreras para beneficiar a todos, desde la empresa hasta la comunidad de desarrolladores en general.

Lo que los líderes de ingeniería deben saber sobre DevRel (pero estaban demasiado ocupados para preguntar)

DevRel is about understanding the audience and collaborating with different departments. Dev Advocates bridge gaps between engineering and marketing, provide feedback, and stay updated on industry trends. DevRel helps raise team profiles, assists with editing and getting on podcasts, and aims to make engineers successful. Collaboration is key in DevRel.

The field of developer relations or DevRel is rapidly increasing in popularity, with roles for developer advocates, evangelists, program managers, and directors appearing seemingly everywhere. It could very well be that you too have colleagues who work in the field. DevRel is a unique discipline aligned with every part of the business from engineering and product, to marketing, and even sales, and acts as a bridge between the company and the wider developer community. Our aligned incentives with engineering leadership are especially obvious in the fact that we exist to serve and enable developer audiences, whether external or internal.For engineering teams, working closely with your DevRel teams provides a great opportunity to better understand your developer audiences, raise the profiles and skills of your colleagues, and make your company more attractive for hiring. Yet, despite many DevRel teams being highly technical, because of DevRel’s perceived lack of focus, our departments are often dismissed as “just marketing” by engineering.In this talk I will answer the question of “what is it that DevRel people do”, and present some approaches for how DevRel and engineering can best collaborate and break down silos to benefit everyone, from the company to the wider developer community.

What Engineering Leaders Should Know About DevRel (But Were Too Busy to Ask)

Zan Markan

Una forma de obtener una buena queja de tu equipo es mencionar la palabra "proceso". Los ingenieros en particular se preocupan de que el proceso signifique que su impulso se ralentizará o se detendrá, y generalmente tienen experiencia para justificar esa preocupación. Con una comprensión del flujo de trabajo y la individualización a alto nivel, esto no tiene que ser así. Como líder técnico y ahora gerente que ha convertido a muchos escépticos del proceso, estoy emocionado de mostrarte mis procesos para el proceso.

Procesos para los que evitan los procesos

This Talk discusses the foundation, formation, and iteration of process, emphasizing the benefits and building trust. It highlights the importance of optimizing processes, using life cycles and meetings to streamline workflow and avoid mistakes. Exposing work through demos and documentation fosters collaboration and provides more exposure opportunities. The Talk also emphasizes concise communication, tailoring processes to individual team members, and addressing challenges through effective communication. Automation is recommended to save time and streamline workflow, while maintaining a balance with personal interactions.

One way to get a good groan from your team is to mention the word “process”. Engineers in particular worry that process will mean their momentum will get slowed or halted, and usually have experience to justify that worry. With an understanding of workflow and high-level individualization, this doesn’t have to be the case. As a tech lead and now manager that has converted many process skeptics, I’m excited to show you my processes for process.

Processes for the Process-Averse

Tara Z. Manicsic

Los equipos de ingeniería a menudo enfrentan desafíos difíciles con recursos limitados. Si el trabajo requiere 1 ingeniero, asignamos uno al trabajo. Si requiere 2, dividimos los temas en partes accionables y los asignamos a individuos. Pero hay varios beneficios de hacer las cosas en pares: ayuda a detectar errores y bugs, permite una mejor comunicación y colaboración entre los miembros del equipo y también puede llevar a un código más eficiente y de mayor calidad, ya que los ingenieros pueden desafiar las suposiciones de sus compañeros y sugerir enfoques alternativos.

El poder de los pares

Pair programming is a collaborative software development technique where two developers work together at one workstation. It offers benefits such as easier code maintenance, faster code reviews, and reduced likelihood of bugs. Implementing pair programming involves finding compatible partners, setting goals, and establishing clear communication protocols. To address challenges, provide training and support, involve team members in decision-making, and carefully select partners. Pair programming can help achieve goals like collaboration, knowledge growth, code stability, and maintenance.

Engineering team often face difficult challenges with constrained resources. If the job requires 1 engineer, we put one on the job. If it requires 2, we split topics into actionable chunks and assign them to individuals. But there are several benefits to do things in pairs: It helps to catch errors and bugs, it allows for better communication and collaboration between team members and it can also lead to more efficient and higher-quality code, as engineers can challenge their peer's assumptions and suggest alternative approaches.

The Power of Pairs

Octave Raimbault

Todos hemos pasado por reorganizaciones de empresas, probablemente más de una vez. Si algunas son comprensibles y producen buenos resultados, otras no lo son, creando inseguridades, falta de confianza en el liderazgo, cambios innecesarios e incluso caminos de comunicación o toma de decisiones más complejos. ¿Cuál es la diferencia entonces? ¿Existe una forma probada de escalar o cambiar el panorama actual de las organizaciones de las empresas? Sí, la hay. En esta sesión, repasaré, respaldado por un caso de estudio real en la industria, la Ley de Conway y la importancia del panorama y las interacciones de los equipos, y cómo los gráficos de equipos bien diseñados pueden mejorar la independencia, autonomía y motivación de los equipos, lo que conduce a una entrega más rápida y de mejor calidad.

¿Por qué escalar de abajo hacia arriba? Cómo las interacciones de los equipos deben afectar la estructura organizativa

The Talk discusses the importance of organizational layout and Teams interactions in software development. It explores the challenges of organizational shards and the need for problem thinking to optimize team communication. The concepts of loose coupling, high cohesion, and clear domains of responsibility are explained. The Talk also emphasizes the three essential team interaction modes: working closely together, X as a service, and facilitation. Furthermore, it highlights the significance of understanding domains, boundaries, and domain-driven design for efficient work and fast delivery.

We all have been through companies’ reorgs, probably more than once. If some are understandable and produce good outcomes, others aren’t — creating insecurities, lack of confidence in leadership, unnecessary changes, and even more complex paths of communication or decision-making. What is the difference, then? Is there a well-proven way of scaling or changing the current landscape of companies’ organizations? Yes, there is. In this session I’ll go through, supported by an actual study case in the industry, Conway’s Law and the importance of teams’ landscape and interactions, and how well-designed teams charts can improve independence, autonomy, motivation of the teams, leading to a faster and better rate and quality of delivery.

Why Scaling Bottom-up? How Teams’ Interactions Should Impact the Organizational Structure

Vânia Santos