Software is a young industry, and not a very traditional one. Your team can’t always be expected to behave like teams in other fields.
So it’s no surprise that when a development team hears the phrase, “teambuilding exercises” for most of them it conjures up the idea of a room full of awkward people marginally engaged in a trite set of activities.
But given the resonance of ideas like DevOps it is apparent that the benefits of teambuilding are still sorely needed. Software companies can fall into a very ‘silo’ed mentality. This is often to our detriment, and tearing down those barriers is a big part of a DevOps philosophy.
So there is an impasse; prepackaged, standardized teambuilding exercises fall short of a development team’s needs, and the need for the lessons those exercises try to get across is unmet.
Last year, when I was working on Release! the Game, I realized something; the things we do outside of work, still resonate inside of work. That led me to think that Office Game Nights might be an interesting, albeit nerdy, solution to this issue. But before I explain my dice driven solution, let’s talk a little about traditional team building.
For the sake of discussion let’s say that by and large teambuilding activities all have a similar set of goals:
- Encourage communication
- Create easy references for actual on the job problem solving
- Relieve stress
- Provides a structure for complaints and socializing
How they try to accomplish this varies, but as a general rule they set forward an infrastructure for interaction that is easily explained, and with a mechanic for comparison to the real work day.
For example, in the classic Trust Fall exercise, one person is called out, to fall backwards while their team is called to catch them. Takes a minute to explain, and the concept that we have to rely on and trust our coworkers is applicable almost everywhere.
It’s a fairly simple formula, get the whole office together, present a challenge, collaborate to meet it, and then discuss the vagaries of how you worked together. Your team bonds a bit, and gets some reinforcement on general work principles.
In the case of software development teams we actually wind up seeing these results:
- Sighs, scoffing, and somewhere in the dozens of eye rolls, depending on team size
- Some variation on the phrase, “I could be getting real work done now.”
- Some variation on the phrase, “At least I’m not doing real work right now.”
- One or two sincerely interested participants
Whatever your place on a development team your job will revolve around creating or manipulating complex logic chains to overcome some hurdle. This, in and of itself, is not that much different from any other job, the difference is code.
Code is abstracted, it is just the logic. Code doesn’t need a teambuilding exercise it just needs to be formed correctly, tested reliably and it just works. If it has a problem, communication or otherwise, there is a distinct and detectable source of that issue, and one that, most of the time, has a methodical solution.
That’s a simplified explanation, but the key there is that there is an identifiable problem, and an identifiable solution. That just isn’t the case for the social systems that operate outside of the code. Navigating the personalities and relationships that form in a workplace simply doesn’t have the same amount of landmarks that navigating code does.
The pit fall is in thinking that the software you produce, and your company are the same creature, or at least have the same needs.
Teambuilding isn’t about the product. It’s about establishing a better system for the people who work on that software, and helping them make the connections that will make production run smoother.
Teambuilding and DevOps
DevOps principles demand strong communication between the members of your team. The tools, the methodologies, all need the right environment to be applied in.
So if you want to build a team that can really talk to each other, you need to step away from the standardized techniques, and pick up some new tools.
For team building ideologies to function they require a sincere investment on the part of the participants, but, in most cases, they are so pre-packaged that the exercises themselves lack sincerity.
Openly acknowledge the goals that your teambuilding program is trying to achieve and don’t couch it in the window dressing of corporate training. There are plenty of structured activities that get folks talking, let them blow off some steam, and foster a sense of teamwork that can be easily reflected during your regularly scheduled workday.
(spoiler alert: this is where it gets nerdier)
Board games: sweet dice rolling, card shuffling goodness.
Game nights (or days) are a great place to do some socializing, have a necessary structure around that socializing, and encourage creative problem solving either through cooperation, or competition. There are also a lot of them. The landscape of modern tabletop nerdery isn’t just defined by Napoleonic conflict, or real estate monopolies, there really is something for everyone.
Setting up some gaming is pretty simple. Set aside a few hours, pick out a game or two, pick up and pizza or two, and get a few coworkers on board. Don’t worry if everyone doesn’t jump on board, give it a few iterations to build steam.
Here you can take a lesson from a DevOps release strategy, if your first night didn’t achieve your results, try again with some small updates, a new game, different toppings, etc…
Chances are someone in your office already is into games, especially in the software fields. But, if not, don’t worry it’s pretty easy to get nerds on the hook.