Recently, the Maark engineering organization held an internal Developers Summit for our globally dispersed team, all gathering together for two days in Portugal. Setting aside everything I learned regarding international travel in the age of Covid, for which I could write another entire blog post, I thought it would be valuable to collect my thoughts on lessons learned through meeting at the summit. This does not mean lessons learned through the actual technical or procedural discussions we held – these were valuable for entirely different reasons – but rather lessons learned from simply holding these discussions. And doing so in person.

Nothing Can Replace the Human Connection

As noted above, we are a globally dispersed team with developers in the U.S., South America, dotted all over Europe, and with some fantastic folks in Turkey as well. When we collaborate it is nearly entirely through video conferencing software. Schedules, cost, and global pandemics all make in-person gatherings difficult. We had team members hired within the last eighteen months who until our summit had never met face to face. As a recent addition to Maark myself, I had only met many of the members of my team through a digital screen. I cannot overstate how quickly and successfully folks bonded by simply being in the same room (or same bar) and not confined to their homes, their desks, and their laptops.

The summit was not at a castle, but we visited one. (Photo by Slawomir Krolik)

There is a separate persona that often presents itself in digital messaging, and I think to a lesser extent it is there in video conversations as well, where how one communicates and interacts is buffered by the technology. This is erased when meeting together, and I believe invaluable in creating the feeling of a team. We are social animals and need that community. Even engineers.

Mixing Remote and In-Person Produces Mixed Results

Remote collaboration technology is still in its infancy and flawed. We found this out when trying to pull in our remote team members who were unable to make the summit during a special session. You can acquire better software and equipment to alleviate some of the pain, but the core of the issue with a mix of remote attendees and in-person attendees is that the weight of focus is on those present in the room. Raised hands are missed for those remote. Voices are drowned out (again, often by the “features” of the software that are intended to make things clearer).

Escaping a small virtual room while in a large conference room. (Photo by Josh Beauregard)

Demonstrating this on a smaller scale, we took part in a collection of virtual escape rooms with the engineers split up into teams of seven or eight, each with a mix of present and remote players. Although my intention was to have an equal distribution of remote players on each team, I miscalculated for one team which had seven present and one remote. You might argue it was purely skill (all our engineers are smart, after all), but this team that had nearly everyone present in the room solved the puzzles and escaped a good ten minutes faster than the teams that were more mixed, where there was more of a difficult time in managing communication between the players across the globe. Hardly a scientific survey, but telling nonetheless.

Language is More Nuanced than Expected

I am and always will be forever impressed by those who speak multiple languages, professionally, every day. What has escaped me is that despite such fluency there are aspects of any language that get lost when it is a second language. This was not so apparent to me in one-on-one calls with team members where the conversation seemed free and understood. However, there were instances at the summit, generally when some exercise instructions were presented, when the breakdown in communication readily presented itself.

One example was a simple introductory exercise where I wanted each developer to write down one interesting fact about themselves (then other teams would try to match facts with individuals). Initially I was hoping to deliver a “slides free” conference but realized that having some visual instructions for some aspects could be helpful. But in order to not throw lots of words onto a slide I tried to keep things concise, and therein lay the problem.

It’s not a list, it’s an array.

This slide was supposed to be just a demonstration that developers could literally write anything down. That’s what my verbal instruction had been. But then the slide presented a list. And that list did not contain the all-important conjunction “or”. All of a sudden I had developers scratching their heads how on earth they could write a fact that encompassed all of these characteristics. It’s a small exclusion, and maybe it would only be problematic for more literal-thinking programmers, but it caused issues in implementation. Not only did this alter how I presented the rest of the summit (moderately successfully, I hope) but also gave me a good indication of the level of detail and clarity needed for communication in our everyday project work.

Facilitation in Discussion is Key

We had some great discussions in our sessions at the summit, but they did not always start out as great discussions. I was often met with lots of stares and silence as we began a new topic and I requested feedback or contribution in some way. Did no one have an opinion to share? Of course if you’ve ever worked with engineers you know that is definitely not the case. However, there was always a bit of time and encouragement that I found was needed to get the ball rolling and then, if I may mix metaphors, the flood gates were open.

This may be true for groups in any discipline, but for me it was a reminder that a meeting to discuss something that requires input from the whole team shouldn’t necessarily be quick, even knowing that meetings are not a favorite for most developers. To truly engage the team and elicit responses takes strategy and encouragement and, yes, time. A general, “What do people think?” will often be met with silence, and this should not be taken as tacit approval. Opinions are always there, so the summit taught me I should work to draw them out.

Teams Need More than Work to Come Together

We’ve got a great crew at Maark, and they work well together on their projects. If all that exists between them is their projects, though, the connection I feel is limited. I mentioned at the opening that the change in the bond of the team was apparent and almost immediate when we gathered together. Perhaps it was the fact that it had been so long since we gathered, or that in general the pandemic had greatly limited any such interactions and people were starving for it. But I also noted that bond was strengthened more between our sessions–on breaks, at meals, at drinks at the end of the evening. These social excursions, even for ten minutes over coffee, solidified the team that we were building through our projects and technical discussions, and I can’t overemphasize their importance.

Either a discussion on CI/CD or a discussion on whiskey. (Photo by Slawomir Krolik)

In our remote work world we’ve lost a bit of that water cooler interaction that used to subtly expand our relationships at the office. Although we have constant and instant communication through different tools it is simply not the same as meeting and speaking with someone face to face. As we continue to work in a global office space and more and more move to a remote working lifestyle it is important to find these times, like our summit, where a team can come together and build something stronger.