You have more software development work planned than your existing team can possibly handle, and you have decided on partnering with a software development provider to give you the additional capacity and capability needed. But how will your existing team react?

This is a key aspect that is often overlooked by executives contemplating this type of strategy. Unless your own staff understand why you are moving in this direction, human nature almost guarantees that the wrong conclusions will be jumped to by some. And this type of FUD (Fear, Uncertainty and Doubt) will, in turn, make success much more difficult to achieve.

Let’s look at some of the most common FUD items, and the reality behind them.

Job Security

Even though most developers these days are quite accustomed to working in teams where some of the team members are remote, some still see remote development as a cost-saving strategy to replace them with cheap alternatives.

The truth is, the vast majority of organisations working with remote teams are doing so not to reduce their development resources, but to increase them. You need more development staff, but the right number with the right skills simply aren’t available locally. Recruitment is costly and time-consuming, with no guarantee that you will get someone who fits in first time. And mistakes in recruitment are even more costly, with regulations around managing underperformers out more stringent every day.

Your existing in-house team is a proven one with deep knowledge of your organisation, processes, clients and applications, so why would you want to lose them? Usually, bringing on a remote team results in existing team members being promoted up the value chain, not laid off. Taking away the more tedious and time-consuming aspects of software development to a remote team can mean that their jobs become richer and more varied.

Communication

Another of the “classic” objections to offshore development. It generally falls into a couple of distinct categories:

• English – “Will they speak adequate English to understand us, and be understood?” Simply put, English is the international language of software development, and (with very few exceptions) no reputable provider of software development teams could be successful with their staff having a good grasp of written and spoken English. Of course, there may be accents, but most quality partners have in-house English instructors, and are constantly improving their staff capabilities.
• Specific terminology – Remote developers are just software developers, so they are very conversant with technology surrounding development globally. Your in-house team may have some specific descriptions for aspects of your environment that have particular meaning to them, and a remote team will, of course, need to come up to speed with your specific usage. But that usually happens quickly at the beginning of the engagement.
• Person-to-person interactions – One of the advantages of in-house co-located teams is the ease with which questions can be asked and answered, and the general level of “water-cooler chat” about projects that occurs. Clearly, that is a challenge for teams with remote and local operatives, and some effort needs to be put into making up for that. Most teams schedule daily stand-up meetings of all members (local and remote) via teleworking tools like Zoom, GTM, Skype for Business etc where all team members can discuss progress, issues and plans, and share screens. Experience tells us that the more such interactions occur, the more integrated and successful the team becomes.
• “Cultural Differences” – With software development now a truly global industry and developers regularly working in teams that cross national and cultural boundaries, this usually a non-issue. Experience tells us that good developers work well with other good developers.

Like everything, a good Project Manager will anticipate the need for more formalised communication at the outset of a project and put in place strategies to mitigate any risks.

An interesting effect that has often been observed when a team expands to include remote members, is that project performance and administrative hygiene actually improves. With established teams there is sometimes such a degree of comfort that good practices (like documenting the decisions coming out of meetings for example) go by the wayside. Adding remote team members often requires going back to these good processes to accommodate them, with the result that the entire team moves back toward best-practice processes.

Stakeholders

If you are like the majority these days who organise their software development along Agile methods, you will be familiar with the concept of self-organising teams where all members have similar levels of authority. Still, there will almost always be a Product Owner or equivalent who will have final approval on how the software works and is built.

That person is usually obvious to a team working in the same office, but when using remote team members, it is important that the team structure and lines of authority are clearly understood by all.

Remote development teams strive to adopt the same collaboration tools and processes as the current in-house team does, and by doing so they ensure that the degree of team integration remains high. All changes made by any team member should be transparent and traceable to all, and the tools available now mean that this level of cross-geography cooperation is easy to maintain.

An remote team is not there to assume the responsibility for making decisions from the existing team, but to join in the conversation, add their suggestions and contribute to the team’s decisions as a whole.

Technology

Usually, an organisation will go to a software development partner with a “shopping list” of skills and experience with the technology stack that they require. Well-established providers maintain teams of hundreds of developers with wide areas of technical expertise to satisfy as many such requests as possible. But what if the technical stack you need is not part of the provider’s skill-set? Quality providers may be asked to provide their opinions on the best technologies to use to achieve specific project outcomes but will not suggest changing your technology simply because it suits them.

We have seen projects that use some fairly old and arcane technologies for good historical reasons or because their established team has strong skills in it. If a provider cannot provision skilled developers in your choice of technology, they may offer to cross-train some of their staff to meet your demand, or even choose to not be involved in your project. But either way, honesty on all sides is key.