Software outsourcing is a valid option for companies that are looking to scale up their product development and find the needed talent faster, but it’s one that comes with significant risk. Almost a quarter of software outsourcing relationships fail within the first two years and 50% within 5 years. As a result, IT leaders experience many concerns in the process of deciding whether to outsource their software development or not and which partner to choose.
Throughout our history, we had the chance to speak to CTOs of startups, mid companies and multinational ones. Regardless of their size and particular industries, IT leaders share similar concerns and fears when it comes to IT outsourcing. So we thought it’s the right time to address them in an article. And let you know what is feasible when it comes to software outsourcing and how you can tackle the risks that come with an outsourcing collaboration.
#1 It’s difficult to manage a remote team
If you choose a long-term outsourcing collaboration model, the best option in terms of efficiency is a dedicated (remote) team.
And managing remote teams is indeed more difficult than working with people in the same room, as the past year of working from home has proven to us. No communication tool can recreate the exact level of engagement of a live interaction. (And we all probably miss being able to have a quick 5 minutes impromptu chat instead of starting an email or Slack thread).
That being said, managing teams remotely can be simplified and efficient, when these conditions are met.
- Working in an Agile environment. Daily stand up meetings help you communicate closely with the remote team, identify any issue a team member is facing and address that. It’s a very transparent way of working, and everyone in the Agile team is accountable. Other meetings such as the Sprint planning, Sprint reviews and Retrospectives help align the remote team around the same goals and be on the same page.
- Similar working culture. It’s easier to work with teams and people that share a similar working culture, because you know what to expect. People that work with little supervision require less management time.
For us in Wirtek, our core beliefs are: ask questions when we need to (because it speeds things up), suggest better solutions when we see them and challenge our clients’ ideas (leading to a better outcome in the end). It’s a working style that made our collaborations effective and long lasting.
- Communication style. If you work with a remote team that is transparent about issues and flexible in finding solutions, the collaboration becomes easier.
- Lastly, having someone as the local lead in the remote team, to manage the day to day tasks so that you don't have to, can save a lot of time.
And this takes us to our second concern, CTOs or Development directors want to know the people they work with.
#2 We want to know the people we work with
We believe that in a long-term outsourcing collaboration, knowing your remote team is not just nice to have, it’s an important predictor of how successful the relationship will be.
When you know the people you work with on a personal level, you can build trust and a secure working environment. In this environment everyone’s ideas are welcomed, people feel motivated to be proactive, come up with better solutions and address problems early on - regardless if they are Wirtek’s employees or client’s employees. They feel part of the same team, motivated and committed to contributing, not just delivering working hours.
We experienced the benefits of this approach first hand and it’s one of the reasons why six of our clients have been with us for over 10 years. RTX, one of our longest partnerships, thinks of people in Wirtek as their own colleagues. The team we built for RTX has been very stable - only three replacements in 13 years - and this is the best argument that remote teams can work as if they were your own employees.
So if you are worried that you won’t know the people in your remote team, remember there are solutions: onsite onboarding for new colleagues, knowledge sharing sessions, daily communication, in-person meetings and team building events.
#3 It takes too much time to onboard a dedicated software team
The reality is that if you need help with software development here and now, a dedicated team is probably not the best solution. You could potentially benefit more from a collaboration on a defined period of time - such as a fixed project. It can be the case if you are building your DevOps infrastructure, need to develop a mobile application or need to integrate an API into an existing product, for example.
On the other hand, if you are looking for a long-term solution, then a dedicated team can be the answer. And the time needed to build that dedicated team is an investment worth making: you end up with a dedicated team that gives you the flexibility to scale up development and release product functionalities faster. You get access to the needed skills long term, after the initial investment.
In general, building a dedicated team for our clients takes around 3 months after signing an agreement. In some cases, we might be able to build a remote dedicated team faster if we have the right people available in-house (say they are just finishing a project). Additionally, because our recruitment team is continually looking for engineers in the market, we have a network of candidates that allows us to shorten this three months ramp-up time.
#4 Transferring knowledge to an outsourced team will take years
Transferring your in-house knowledge to your dedicated team is important - the remote team needs to understand your product and industry, how your end-users interact with the product. But you need to remember that this process doesn’t have to happen all at once.
The most efficient approach is to start working with a remote engineering team on a specific area of your product - and build up from there. It’s a good starting point, and the remote team will have the chance to learn the particularities of your platform and business.
Whenever possible, we propose to bring a software architect on the team, so he can learn the product’s architecture and make improvement recommendations (if it’s an existing software) or create the product’s architecture. The architect can then further transfer the knowledge to the rest of the team members as they join.
Code reviews are another great opportunity to transfer knowledge to the dedicated team. Every new engineer that joins the remote dedicated team does code review with the purpose of learning & sharing the knowledge with his team, beyond identifying and correcting potential errors in the code.
#5 It’s difficult to write down specifications
Sometimes potential clients are scared away from outsourcing their software development by the fact that they don't have detailed specifications or no specifications written at all.
In a dynamic environment, where customers’ needs change fast, you need to stay agile and respond to their requests for features. So writing product specifications upfront is not efficient and realistic. But in reality, this is not as much of an impediment to outsourcing as it is an opportunity.
When our new clients don’t have specifications, a Scrum master or proxy product owner in Wirtek sits down with our client’s product owner and works on defining them. This offers us the opportunity to learn our client’s product as well as the industry at the same time.
#6 Our product is too complex to outsource
We often hear from potential clients that their product’s complexity is preventing them from outsourcing their software development.
And indeed, you don't want to start up an outsourcing collaboration by digging into the very heart of the product, as, of course, there is a lot of risk involved. The outsourcing development team needs to build up knowledge about the domain first, learn the existing toolchain and code.
A better approach is to identify a less complex area of your product on which the outsourced team can start working. Or start out with software testing before moving to development.
When your outsourcing partner learns about your product, demonstrates that they are technically capable and knowledgeable, and you realize that, in fact, you function well together, you can move to more complex areas of your product.
We have used this approach with several of our customers, with Spectralink for example we started working on doing conformance testing for their telecommunications equipment and over time, they entrusted us with more work. Today we are also doing embedded development for them.
#7 Software outsourcing equals poor product quality
We learned that this is perhaps one of the biggest fears companies have when it comes to software outsourcing.
And it’s a valid one: an outsourcing company that doesn't have the technical skills and the right processes in place can end up delivering low-quality functionalities.
So before embarking on a collaboration, take the time to understand how the outsourcing partner handles QA, communicate what QA means for your product and what you expect to happen.
For us in Wirtek, quality assurance means more than just the quality of the code deployed: it’s about the quality of the documentation, how we formulate specifications all the way to defining acceptance tests and testing.
Software development outsourcing is indeed risky and requires a long-term investment.
But if you manage to find the right partner, with the right working culture and communication style, who is willing to be transparent and work integrated with your in-house team, you will be able to reap the benefits long term.
