4 Tips for Managing Offshore Software Teams
4 Tips for Managing Offshore Software Teams
Tips for a successful offshore development team
With remote work becoming common, employers can go further afield—increasingly offshore—to find a workforce. Software development is especially suitable for remote work between members of far flung teams. We have applications like Git, SSH, remote desktop and other collaboration tools. However, offshore teams are not a drop-in replacement for their local counterparts. They present their own challenges to manage and help guide towards success. These are 4 tips to help manage a team to get there.
1. Do not take degrees and qualifications for granted
Recruitment is difficult. The truth is that most people do not know whether someone is likely or not to succeed from a few hours of discussion. For that reason employers defer to a candidate’s degrees and qualifications to predict their suitability.
University qualifications from less recognised, non-western universities are just not as reliable an indicator of a candidate’s future performance. That's not to say that they will perform poorly, or that fancy degrees guarantee any success, but just that more work is needed to be sure of either of these.
2. Leadership is a rare quality and rarer still offshore
The best people to manage are those that do not need to be managed. This is no different when developing software. Some people can be thrown a problem and will deliver a result. Others need help and prompting along the way, whereas others need constant attention.
Strong leadership comes from people that can take ownership of problems, organise and lead others, and achieve results to a schedule. Technical fields complicate this. No matter the personality and “soft” skills, technical leadership also requires a solid understanding of the technology on which the team is working.
Offshore team members more often lack the leadership and initiative of local staff from the west. We could focus and discuss why this is the case, but I think it’s better to just accept this and manage it.
Teams don’t function without leadership. A popular solution is to leave the development to the offshore team and the management to onshore staff. The level at which to draw that line comes down to the needs and ambitions of the organisation.
There are different approaches to where to draw the onshore / offshore line. An option is that all but the least senior positions be onshore, all the way to an entirely offshore management team. If the technology being developed is strategically important to your organisation the engineering management is absolutely important. This includes code quality and design, testing, devops and the other engineering practices. A company focusing on e-commerce, a technology product, etc. has strategic interests that need to be well managed and leaving the leadership of the team to offshore staff is not in the company’s interests. A different company may not see its software assets important enough to warrent the expense of any local technical leadership. Nobody wants anything other than the best success, but the question is how much do you want to pay for it?
3. Make the best use of your tools
This article opened with a list of software development and collaboration tools. These are important no matter where the team works. Some are especially important for remote and offshore workers. It is worth discussing those whose importance is not immediately obvious.
When you are not walking past someone’s desk several times per day, and perhaps only speaking during the daily standup, it is especially important to know and be aware of what is happening to the team and its members. Online versions of Kanban boards like Jira and Trello have become the de-facto standard for this. Some teams are more or less disciplined when it comes to Jira hygiene. An offshore team can be far less forgiving if a team’s habits are poor.
Some of the key items to keep on top of include:
All work is tracked on Jira.
Stories are tagged or under an epic.
Tickets have story point estimates (story pointed) before entering a sprint or before work is commenced.
As much of the backlog be story pointed as possible.
Stories do not have their points changed once work begins.
There are many more, but the above are the most urgent. The first should be obvious. It should not be the task of management to chase up / ask who is doing what. Good hygiene will make it easy to get abreast of the team’s allocations and make sure that the team is on track.
This point should be clear and relates to the previous one. As a team grows the volume of tasks will grow: feature development, operations support, maintenance and bug fixes, etc. People struggle to keep track of more than just a handful of items. By tagging stories or placing them under an epic you can more easily track the team’s progress against deliverables.
Measurable metrics are the only way to reason about the performance of a team. It is therefore important that work be tracked by such metrics, but also that there be no temptation to change estimates over the course of the ticket’s life. Estimated story points will not always be correct, but by being consistent in the team’s practices and given the law of large numbers these errors estimating effort will even themselves out over time.
4. Cameras help people connect
A team is not an army of robots. They are people that form relationships—usually constructive—and relate to each other as people after periods of working together. It can be difficult to build that with a voice on the end of a call. It is harder to communicate with, build a team with, want to take the initiative for, and go out of your way to help a voice.
Unfortunately it is very easy and convenient to turn off the webcam during a meeting. It can be a little awkward to encourage cameras, but it is important to building a team. It is the first step to encouraging other behaviours that promote collaboration, including knowledge transfers and pair programming.