Presentation: Dynamic Reteaming: The Art & Wisdom of Changing Teams
Share this on:
What You’ll Learn
-
Find out about the dynamics of teams and how to deal with that.
-
Hear stories and problems other companies have had with team dynamics.
-
Learn about patterns and recommended practices that help when teams change.
Abstract
Let’s debunk the myth that you must keep teams stable or “the same” in order to have a successful company. Changing teams can help reduce the risk of attrition, learning & career stagnation, and the development of knowledge silos. I’ll share original case studies from companies that enable dynamic change to their teams propelled by retrospectives and other humanistic practices. In this talk, you’ll learn tips and tricks for building a sustainable company by changing teams – whether it’s by growing and splitting teams, merging teams, seeding teams, adding new people across multiple teams and more. I’ll also share reteaming antipatterns and what not to do.
Tell me a bit about the work that you do.
I work at Procore Technologies. We're in Southern California, and we make software for the construction industry. I work as Director of Engineering Excellence. In my role, I teach and mentor on Agile software development best practices. I coach teams and individuals to help them get better at what they do. I also facilitate large events and offsites.
Tell me a bit about your talk, what's the genesis of the talk.
The talk is called Dynamic Reteaming. I wrote a book called Dynamic Reteaming: The art and wisdom of changing teams, and the book is trying to just prove the point that for many of us, and I've been in software engineering for 20 years, team changes is a normal thing. It's something that happens; it only takes the addition of one person or the loss of one person to change your team system. Teams are more dynamic than static. Lot of the literature that you might read about teams, whether it's from the software industry,agile or organizational development, might say, well, the best teams are the ones that don't change. And I have found in my career that that's not the case. It's more of a moving target. My talk is about several patterns of team change. Sometimes a team will change deliberately. Maybe it's the team's idea. For example, Sometimes when teams get to a certain size things might feel they're stagnating a bit, and some teams decide that maybe it's better to split into two teams. Then you have two new teams. What can you do to make things easier before a team might split, during the actual team split, and after that happens? One of the patterns is called Grow and split and it's about just that. And it solves a problem of team stagnation or when things feel too big. That's a very common pattern. From my book, Dynamic Reteaming, I include stories from my career but I also have more than 30 hours of interviews from people at different companies. When I hear about the stories more than three times, I consider it a pattern.
My talk is about five patterns, and each of the patterns solves specific problems. If the team feels too big or it's stagnating, we might want to change it or shift it and split it. Another one of the problems is, what if you're in a situation where you're going to be growing, maybe there is a corporate mandate to double in size or grow really fast. How do you manage that? The one by one pattern covers that, as well as some batch reteaming patterns. We might have one team and you add a new person. What are the things that you do to help that new person be successful? What are the onboarding techniques? You might have five new people start on one day. Sometimes we like to spread out or load balance the people to the teams. You have a wave in the system. You might have a problem that is you must grow faster. You must double in size. We might not want this to happen but it's a company decision, so how do you make it easier? How do you deal with with growth? Is is one of the problems. Each problem maps to a pattern. Then you might have as you as you grow bigger and bigger and bigger, sometimes you have other issues.
There are so many people that have joined, this feels like a different company than it used to feel like. Our culture feels different than it used to be. And it's a real problem that I see in many different companies, especially if you're a startup and then you grow. And if that happens really fast you have different groups of people that don't really know each other very well or it might be confusing, like how can I get anything done. Yes, you might have that case. There are specific things you can do for groups of people where we can coach that team system and get the outcome of understanding, we are all one team. Even if I joined last month or I've been here for five years. I have these activities where teams create timelines, the story of our team. I did it with an iOS team, some months ago. And we stand in the order of our hire dates and we make a timeline of when we started and significant events that happened around the time that we started and why we joined the company. And then one by one the people tell the story of the team. And the people that started two weeks ago learn some of the founding stories. We all get to share and have a greater understanding. It raises the positivity. But it really emphasizes the point that we're all here to help the company be successful. How do we get to know each other better and work towards shared goals?
What do you want someone who walks out of your talk to leave with?
I ask people to stand up if somebody just joined your team in the last two weeks, and inevitably most of the room stands up. If I ask how many people left them in the last month, and a lot of people stand up. And I say, look around. They say, yeah, we are dealing with a changing environment more than a static one. When they leave they'll know five patterns and five problems that are solved by applying the patterns, and then we'll have specific practices to make things easier after their teams change.
Similar Talks
Tracks
-
Microservices: Patterns & Practices
Evolving, observing, persisting, and building modern microservices
-
Developer Experience: Level up Your Engineering Effectiveness
Improving the end to end developer experience - design, dev, test, deploy, operate/understand. Tools, techniques, and trends.
-
Modern Java Reloaded
Modern, Modular, fast, and effective Java. Pushing the boundaries of JDK 9 and beyond.
-
Modern User Interfaces: Screens and Beyond
Zero UI, voice, mobile: Interfaces pushing the boundary of what we consider to be the interface
-
Practical Machine Learning
Applied machine learning lessons for SWEs, including tech around TensorFlow, TPUs, Keras, Caffe, & more
-
Ethics in Computing
Inclusive technology, Ethics and politics of technology. Considering bias. Societal relationship with tech. Also the privacy problems we have today (e.g., GDPR, right to be forgotten)
-
Architectures You've Always Wondered About
Next-gen architectures from the most admired companies in software, such as Netflix, Google, Facebook, Twitter, Goldman Sachs
-
Modern CS in the Real World
Thoughts pushing software forward, including consensus, CRDT's, formal methods, & probalistic programming
-
Container and Orchestration Platforms in Action
Runtime containers, libraries, and services that power microservices
-
Finding the Serverless Sweetspot
Stories about the pains and gains from migrating to Serverless.
-
Chaos, Complexity, and Resilience
Lessons building resilient systems and the war stories that drove their adoption
-
Real World Security
Practical lessons building, maintaining, and deploying secure systems
-
Blockchain Enabled
Exploring Smart contracts, oracles, sidechains, and what can/cannot be done with blockchain today.
-
21st Century Languages
Lessons learned from languages like Rust, Go-lang, Swift, Kotlin, and more.
-
Empowered Teams
Safely running inclusive teams that are autonomous and self-correcting