5 Tips for Working with a Remote Development Team
Hiring a remote development team has many benefits. It helps you reduce costs, broadens your talent pool and, if things go smoothly, it can result in a big productivity boost. But in order to work successfully with developers at a distance, you need to be good at communication and set clear goals and expectations. Let’s look at some of the best practices we’ve learned to implement at Squads.
Start with a smart briefing
A good briefing is crucial. It could set clear deliverables, a timeframe for the project, and guidelines the team should follow to communicate with you and present results. When sharing a briefing it is very important to look for the right balance between precision and simplicity. The simplest extreme is to offer only a simple one liner and see where collaboration gets you. The complex extreme is to write a full spec of what you want to build and leave no room for interpretation. Depending on the risks you face in your project, the best solution lies somewhere in between those extremes. The less you set the project in stone before you start, the more you may change your mind along the way. Changing your mind is good if the change is a result of deliberate learning. It may be bad if it is the result of accidental learning.
Provide fast feedback
Don’t wait too long to communicate feedback. Give praise where it’s merited and never shy away from expressing discontent when things are not going as expected. The faster you communicate grievances, the easier it will be to deal with them. At Squads, we strive to gather feedback frequently by delivering work in weekly demos. You can read more about our way of working here.
Keep it simple
The faster information flows between individuals, the faster a group can respond to change. Increasing the speed of information increases the intelligence of an organization. A digital organization has to record information as it gets transferred. But recording everything can get too bureaucratic. Forgetting things makes room for new ideas and also helps us to respond faster to change.
In a remote setup, forgetting is harder, and we have to make sure we don’t fall into the bureaucracy trap. When we store things we should be conscious of where we store them and keep them out of the way of new ideas. Don’t put everything in the same wiki that you plan to keep well organized. First, well-organized wikis are a myth. Secondly, the well-organized wiki can invite team members to always take the road most traveled by. The better the instructions are, the less likely workers are to find creative new ways to do things. Sometimes, e.g. in a factory, this is a good thing. In most IT companies, detailed procedures will slow down innovation.
It is natural to talk about things. It is artificial to write them down. In groups, human beings tend to talk about problems, but they don’t tend to plan to solve them in a structural way. This is an acquired skill. In almost any collaborative setup it is a good advice to make things visible.
Agile coaches will tell you to put stickies on the wall. Having a standup at a physical board is much more visual and engaging than having a standup in front of a computer. In a remote set up, this is a luxury we cannot afford. We must go digital.
When making things visible, it is important to ask: “Visible to whom?” Many organizations have failed at remote work by favoring optimizations for on-site teams. Physical information artifacts are one such optimization.
If you want remote teams to be successful, everything must have a url.
Asynchronize where possible
Meetings are toxic. Some years ago I decided that I would not go to meetings longer than 30 minutes or with more than five people. If a meeting is longer, I usually leave. If there are more than five people, I usually don’t show up. I’m pretty sure I haven’t missed anything important.
Meetings should have a clear agenda and goal. The best way to get out of a meeting is to achieve the goal before the meeting.
For example, I could have had a meeting to start this article. The goal of that meeting would be to produce an outline and a title. Instead of planning a meeting and distributing an agenda, I could asynchronize. I could write an imperfect outline and distribute that to the people I need input from. They could then comment on the document — there’s awesome tools for that nowadays. This frees all involved to manage their own time and avoid interruptions. That is beyond awesome if you’re doing creative work.
Collaborative work and meetings are not the same. Sometimes breakthroughs can only happen when we synchronize. Work in pairs, work in mobs, but always work to avoid meetings.
Are you looking for a remote team to build or enhance your product? Talk to one of our experts to find the right talent.