When was the last time your company dragged you to something described as a “team-builder”? Maybe it was a simple happy hour, or perhaps even a full-day emotions course with trust-falls and crying. Heck, maybe it was an executive retreat in the Himalayas! But did you enjoy it? And more importantly since your company paid for it, did your team get built or at least improve?
How are team-builders supposed to work?
Team-builders are often just excuses to get out of the office for something someone thinks is fun. But more earnest attempts at team-building often end up far removed from the real challenges in the office. At best they offer some self-help, but mostly they’re just a waste of time. For tech companies in particular, these events fail because the purpose of doing them isn’t clear.
Most of these team-builders ask you to make a leap of faith. If you spend more time with your colleagues outside of work, a kinship will form. That kinship will translate back to the office where it will result (somewhat magically) in improved efficiency. Bowling, zip-lining, harbor cruises and wine tastings will help, somehow, pull in the schedule.
What’s the harm in having some fun, you say? For one, it’s bound to be a contrived and awkward social situation. More than once I’ve seen these events damage work relationships just as easily as they improve them. Of course there are occasions to celebrate at work. Let’s just call those what they are: parties.
Let’s agree that an off-site strategic plan review followed by a 3-hour happy hour isn’t “building the team”.
What about more serious attempts at team-building? I once did a two-day off-site leadership training course. We had to organize into groups of four and compete to build the tallest structure using uncooked spaghetti and tape. Someone won (not my team), and then the facilitator reminded the class that children regularly outperform adults at this task. Supposedly this is because their creativity hasn’t been blunted by years of structured learning.
Then came a lecture on your brain. You learn about your two minds: your emotional self and your rational self. The emotional brain evolved first, then the rational mind. The point is to control your emotions and create better outcomes. No doubt this is great to know, and yes, it can make you a better person. But honestly, what does this have to do with tech?
What are we after, exactly?
Somewhere we lost sight of the objective. When it comes to building technical proficiency, nobody’s confused. Want to become a skilled tech person? Study computer science or engineering, get internships, read books and most importantly build products and get better. But when it comes to creating skilled tech teams, apparently you find the answer in the self-help section of the library. Aren’t we trying to create tech teams that produce on-time, on-budget, robust products? If that’s what we want, why isn’t that the focus of the team-building?
Soft-skills are a small part of the answer, but they aren’t the whole answer.
There’s a chasm between the rigor of how technical skills are built, and the vagueness of attempts to build great teams.
The failure of the team-builder is a microcosm of bad tech management in general. Here’s a typical career arc in software: you’re a developer with outstanding skills as an individual contributor. You understand the big picture and can communicate pretty well. So you’re quickly put in charge of small teams, which quickly become big teams. But nowhere along that arc do you receive real training on how to manage people, or in understanding how high-performing teams work. Certainly nothing close to the rigor of your computer science degree. Hopefully you figure it out by observing those around you. If your company has a culture of great teamwork and great leaders, then probably you will figure it out. But you won’t get the benefit of seeing what happens outside your company, or ever learn industry best-practices.
Let’s do something useful for a change
Team-builders don’t have to suck. But to be useful, they need to focus first on your desired outcomes. These outcomes need to be specific and relevant to your team, and they must address your specific challenges. There’s no cookie-cutter answer here: it takes real problem-solving by the people involved. The good news is you already do this. After all, you do it all the time when it comes to making product and technical decisions.
You should see the light that goes on when we show people how to build a great team exactly the way they build a great product! Without the mystical mumbo-jumbo.
In fact, a useful way to think of a team-builder is as a mechanism for updating how your team works. We discussed work versioning in a recent blog post. Think of it this way: your team has plenty of planning meetings for your product. But what about the way your team works? Start with that, and then maybe go for the happy hour. It might suck a lot less.
If you’re interested in team-builder events that don’t suck, and that actually help your team get built, sign up for our newsletter or contact us!