More and more, these days, organisations involved in building software solutions for their clients (both internal and external) are urged to consider partnering with software development providers. There are some very good reasons why this might be a good strategy, but it is important to understand that not all providers are created equal, and not all client organisations are prepared for the changes that introducing an external managed team will usually bring.

Over the last three decades, we have seen many such partnerships yield great long-term results, but equally we have seen many relationships that have not met expectations. Here, we will look at some of the most common mistakes that can have unfortunate consequences for companies considering this type of arrangement.

Choosing the Wrong Development Provider

The “pitch” is often broadly similar – low cost developers capable of anything you can think of. But how do these providers work? Essentially, there seem to be two basic models at play.

Firstly (and perhaps most commonly), some such providers actually have few (or even no) developers on staff. The business model is simplicity itself – you provide the skillset and experience that you need in a remote team, and they go to their local contractor market to identify and engage a team that matches. The provider adds a margin to the contract rates that they are paying and resell the team to you. Perhaps they have office space where this team will be housed, but often the contractors will work remotely as your remote team with little support. The contracts with the developers are generally limited to the length of the engagement with you and having them as long-term staff is not part of the plan. Let’s call this model Contract Reseller.

On the other hand, long-established development houses tend to recruit staff into full-time employment ahead of demand, and consequently have much more control over the recruitment, training and development of their staff. This is a higher risk and more complex business model for the provider, since it necessarily requires them to be continuously recruiting, training and retaining permanent staff in the hope that they can be sold to clients. The benefit, though, is that these providers know their staff very well, and all of their employees reflect their corporate standards through training and experience. Let’s call these Software Development Partners.

Contract Resellers might be an option if you need quick and cheap access to one or two developers with specific skillsets for a short period, but the nature of contractors is that developing a longer-term integration with your local team might be difficult. The nature of contract labour is that they are inherently temporary – contractors are usually looking for the next contract in the real world, and if you decide to extend your 3-month team for another 3 months, the same developers may or may not be available. Even if they are, the rates may not be the same. The standards that each developer applies to his or her work are likely to be different, since they will all have different backgrounds, and Contract Resellers rarely have corporate standards in place or enforced. It doesn’t suit the model.

If you are looking to form a long-term high-trust relationship with a development provider, a Software Development Partner is probably a better option. With a much more stable workforce and staff trained and assessed against known corporate standards and accreditations, developers in these organisations are more likely to be on a career path with the provider, so be available to become an established team member for you over the longer-term.

Using a Remote Team as a Black-box

There are two ways to approach using an external software development team – as either a stand-alone team tasked with a particular piece of work in isolation from the rest of your company or as an integrated extension of your existing local team.

In the first approach, the external developers operate as a “black box”. You provide them with a scope of work at the beginning and wait for them to send back the finished product in days, weeks or months. In the meantime, little interaction is undertaken with the remote team and we all hope that we get a good outcome. A decade ago, this was the standard approach to using external developers.

The other approach involves actively integrating the external developers with your existing team. They become an extension of your workforce, as though they were physically in the next room. They are exposed to your corporate culture and get to understand the totality of the project, the part they are to play in its success, and the needs of your clients. They are managed directly by your local team lead and are generally participants in daily or weekly team meetings with all their colleagues.

Unsurprisingly, the latter strategy almost always yields better results over time. With a better understanding of the goals of the project, access to real-time updates on how it is going and changes occurring, and feeling of belonging to your team, integrated development team members regularly become part of your corporate “family”. In doing so, they are generally far more productive and responsive to your requirements.

Considering Only the Hourly Rate

Few people in business believe that cheapest is always best, yet many seem to approach securing software developers this way. If the hourly rate is the sole reason for engaging a development partner, there are plenty of providers ready to engage in a race to the bottom on pricing.

Engaging a team from a long-established Software Development Partner can easily result in a 30-40% saving over equivalent local staff, but this should never be the prime driver for considering this option. The idea of replacing all of your valuable development staff with cheap replacements probably won’t work and may result in you divesting your technical expertise and maybe even Intellectual Property to someone else.

There are always organisations or individuals prepared to undercut everyone on price alone, but the reputation and history of a development partner, as well as their cultural fit with your company, is at least as important to achieving great results.

In a successful company like Mitrais, there are a host of team members who contribute to that success. Many are obvious to staff and clients due to the high profile of their roles, but some of the most important are rarely seen or acknowledged.

As CIO, Hartoyo heads up the IT Support Team. The fact that they can be almost invisible to the organisation and clients on a day to day basis is a testament to how well they perform their roles – generally things simply work, and when they don’t, his calm influence is a real asset.

But how does such a quietly competent operator as Hartoyo come to be?
Born in Bali, Hartoyo undertook his primary and secondary school on the island. On graduating high school, he was able to continue his education at the University of Arizona (yes, he was a Wildcat!) majoring in Management Information Systems. He became immersed in the innovative culture that existed at that time, working with some of the most renowned Unix Wizards (“real-life geeks” Hartoyo says).

Hartoyo became so involved that he took to collecting examples of differing platforms in his room. Having working Sun Solaris, Apple PowerPC, Dell Pentium Pro machines had an unexpected benefit. They generated so much heat that Hartoyo never needed to turn on the heating – he was always toasty warm in the chilly Arizona winter!

Like a lot of IT professionals, Hartoyo was initially attracted to IT via games. Starting with Nintendo/Sega consoles, he quickly became interested in the much richer variety of gaming titles available on the PC’s DOS platform. Wing Commander became his favourite pastime, and he was an avid player at that time.

Interestingly, now that he is a respected IT professional, his enthusiasm for gaming has not diminished, and it remains one of his favourite downtime activities. These days, though, his interest is piqued by considerably more sophisticated historical warfare simulations, and he has a strong passion for historical hoplology (the study of arms and armour). He finds that this compliments his gaming hobby nicely.

Within Mitrais, though, Hartoyo and his team are simply known as the “go to” guys on all matters relating to IT and Networks. He is equally at home managing the considerable internal demands of Mitrais staff (both reactive day to day problem solving and longer-term strategic planning), and the wildly varied requirements of Mitrais clients (for whom we regularly need to create and maintain a dazzling array of virtual environments that mirror their own). However, Hartoyo still retains the ability to focus on and manage vital organisational elements like disaster recovery and network security.

Perhaps he runs his team like one of the armies in his beloved battle simulations, and that is the secret behind the team’s consistent performance?

One of Hartoyo’s favourite quotes might give us a glimpse into his management style. As the 15th century Italian writer, Niccolò Machiavelli, said, “He who wishes to be obeyed must know how to command.” And if that sounds like a quote from the game Total War: Medieval, it works, so we can forgive that!