Building technology solutions with distributed development team: communication challenges
Remote work is becoming the norm in modern companies — which is great, as it introduces almost unlimited opportunities to connect and create, but it doesn’t come without challenges. Here at Satalia, we like to say that we solve hard problems, and building transformative technologies for our clients while being a distributed team of teams across the planet is one of them.
We work together with our clients’ teams as a single coordinated unit. Emphasis on collaboration allows us to scope, prototype, test and implement best in class data-driven systems. It sounds neat, however, it’s not always that easy, especially when the employees are spread across our offices in London (UK) or Kaunas (Lithuania) or operate out of Greece, Luxembourg, China, Germany, America, etc. The team is as remote as it can get without going to extremes.
In this article, I will review some of our many challenges in the context of a remote software engineering product team, which has built a transport and logistics optimisation tool powering the deliveries of many of the worlds’ largest retailers, and which has probably the most sarcastic developers I have ever worked with.
Challenge #1: who’s THAT guy?
Scaling software engineering teams comes with a unique set of problems. In a lot of cases, issues that are related to the product itself become an unspoken priority, and everyone’s attention is focussed on how to make the product better. There’s nothing wrong with being a bit obsessed with the great solution that the team is building, but it’s very dangerous to overlook other aspects, such as the people and the team itself. The “soft” part of software engineering is actually pretty hard. It’s easier to understand processes and structures than human behaviour and psychology.
You may disagree, and you might be right. But if you’ve ever worked with a high performing team with rocket-speed technical scaling abilities, you know what I’m talking about.
This complexity sometimes translates into reality in hilarious forms. Like one day finding a new person on the weekly call, not knowing what the hell he or she is doing there and eventually finding out that this guy/girl is actually your team member! It’s even more bizarre when you’re used to knowing your teammates’ family members by name and their favourite food, and you suddenly find yourself in this situation when you’re not even sure who’s on your team anymore.
We had this problem when our client’s interest in data science components increased, and the related requests numbers spiked. Because of the urgency of the matter, the management side of the team decided to form a new team within a team and onboard some fresh, smart minds which can effectively solve hard data science problems and model the solutions. The engineering team would be located in Lithuania, and data scientists would be distributed across Europe.
This structural and strategic part worked out smoothly.
But what happened on another, human, side, was a different story. We’ve created distance between software engineers and data scientists, which led to quite a few conflicts, misunderstandings, countless emails and a general decrease in the team’s morale. Engineers were not sure which data scientists were working with the same client and vice versa.
It can be and was solved by making communication within the team one of our top priorities in any product development phase. Never onboard new team members while scaling without proper introductions, which should include not only the person’s name and role but also primary responsibilities, background, the purpose of the role and even the obvious reasons why this professional is joining.
Also, do not exclude the team from this decision, especially, if some members of the team are remote. The existing team must feel like they are taking an important part in this agreement, and nothing is being hidden from them.
Challenge #2: From 1 to 10 how happy do you think a developer is spending all day in meetings?
Having a lot of communication is cool but have you ever felt overwhelmed? So did we.
Rainless increase in meetings, as we were aiming to understand each other better, was an unpleasant surprise. Retrospectives, plannings, daily huddles, weekly performance overviews, client aspirations research, business logic exploration, you name it. Add ad-hoc meetings or one-on-ones before team calls, and you get a fine selection of corporate extravaganza. This is just a nightmare for quality focus.
How did we solve it? Drastically cutting off “nice to have” meetings and having crystal clear agendas for every meeting that we kept. First of all — recognise which meetings are must have and which are just nice to have. And get rid off everything that is not critically necessary.
Everything should be made as simple as possible. But not simpler.
-Albert Einstein
We started the witch hunt: meetings edition. We got rid of many information sharing/status update type of meetings and replaced them with thoughtful emails, merged some meetings with others and only left those which made the most sense at that time. It let us cut meetings time from around 40% to 20% on average across the team.
Second of all, meeting agendas. Most of the time people don’t have a common understanding of what it means to have a productive meeting. A ton of different variables makes up the productive human collaboration in a meeting equation, which makes it even more interesting. Start with a clear schedule and meeting goals — what and why should be discussed. Do not accept anything that is less clear than your mind after a good workout. Or to put it in simpler terms, just understandable enough for all participants.
That is a good place to start your quest to effective meetings, and well, this could be a great topic to expand on for the next time.
***
No matter what is happening, you must acknowledge that your technology is being built by humans (if this is the case), and the fundamental yet profound emotional needs of connectedness and clarity are critically important.
Empowering the team, giving them the right tools and building the solutions together helps the remote team feel more connected and makes their work more meaningful.
Finding the right balance of technological and human aspects in the ever-changing software product development universe with a distributed always scaling team might seem like a very hard problem to solve, but well, this is what we do, right?
