How to Prepare for Outsourcing Development

You’re about to hire a software development outsourcing company. You’re talking to them about your project, already thinking about managing the remote team.

but wait … There’s another problem!

How are you going to communicate this news to your in-house team? How are they going to react? Is it possible to reassure them that they are still needed? And most importantly, are they going to be able to successfully cooperate with the outsourced specialists?

These are the questions we’re going to tackle.

Job Security

When it comes to software development, the idea of an in-house team working alongside outsourced developers isn’t anything new or unusual. And yet, in-house developers often fret about the possibility. It seems that this topic is a bit of a taboo, isn’t it? What exactly is the reasoning behind all those worries?

There are many reasons for that, but the chief one is of course the fear of losing their job. And that’s where we get to one of the biggest misunderstandings about outsourcing. Usually, clients outsource not because they want to fire someone, but because they need more developers and the local market can’t meet their demand.

There aren’t any proper developers on their local market.

There may be some out there, but perhaps not the ones they are looking for in terms of skill and technology stack. Also, the recruitment process may take a lot of time, hiring n house is usually expensive when you consider salaries, insurance, all that comes with full time employees, and there are plenty of scale issues when it comes to in-house developers.

But the good news for in-house devs is that if any of the reasons above apply, there is no way they’re going to be laid off. After all, if they are in need of more devs why would they fire those they already have?

Based on my experience, nobody has ever been laid off because a company brings in a dedicated team.

To the contrary – as the team grows in size, many in-house devs end up taking on collaborative and lead roles, always working on the same project with the outsourced team in some capacity. Some have even been promoted. This is why it’s so important to give your team the entire context of why you introduce software development outsourcing. Even if they don’t directly ask for it – because all these negative thoughts almost certainly creep into their heads.

Authority

Sometimes, leading in-house developers can be the ones who championed certain technologies in the organization. They may even have emotional relationship with the code they wrote. They may insist their code not be touched. What then?

Yes, it’s true that many developers try to treat their code almost like it is their child and they are not willing to “give it away” to anybody. But it’s all a matter of giving those in-house developers the right perspective.

What we do as the outsourcing team is have our developers talk to your team to explain why it may actually be beneficial for all of us. We’ll give our best to improve/refactor the software, so that they can have more time on doing and learning new things. Last but not least, all the changes we make can be viewed and accepted by them as part of code review sessions – so that they retain the feeling of value and control over its development.

It’s often said that the key to fruitful cooperation is earning trust of lead devs. What does Dot Com, as a software development company, do about it when it comes to working with in-house teams?

All people who take part in the project need to feel that their opinion is important. That they have a say in it. It’s vital to make good use of every opportunity to build a relationship with a lead dev from our client’s company. All in all, if he or she feels comfortable working with us, we have the best possible ally in the organization.

Still, some feelings can get hurt, reputation being on the line…

Yes and no. The truth is that it usually turns out to be beneficial for everyone involved. The usual main concern in such situations is that we may see that their code is actually quite bad. However, it is in fact a good opportunity to suggest refactoring. The in-house team may have had that in mind already, but they lacked time and authority to actually make it happen. Our presence may become a catalyst for some major positive changes in the organization.

When conflicts do happen, who will the CTO will listen to – the in-house team or the outsiders?

At the beginning of every cooperation, the burden of proof will lay almost solely on us as the outside team. We’re going to be listening, collaborating, advise and take the direction of the the in-house team and decision makers. The opposite is rare. Later on, we usually strive to gradually achieve the status of a partner and cooperate with the in-house team on equal terms.  We understand that gaining trust takes some time and we will need to prove our skills.

We never try to force the in-house team to do anything.

Communication

If both teams are involved with the project, they’re going to have to communicate somehow. What are the most important aspects of it to consider?

Yes, lack of communication is from my experience the key source of all the later issues – that’s why we always put the biggest effort on making sure everybody in the team can understand each other.

There are many aspects to it:

• Common language – in-house devs are often worried that their new friends aren’t going to speak English well. This is usually not the case with our developers who consider English to be an essential tool in our work.
• Common project-specific language – aside of English, there are also words and expressions that can only be understood by members of a certain team. There may be certain project-specific ways to call various parts of the UI, processes and more. We realize that and work to use common verbiage as quickly as possible.
• Cultural aspects – I believe that this one is often feared for no good reason. We have worked with people from all over the world and we never had a problem cooperating smoothly and understanding each other’s intentions.
• In-person interactions – as we work remotely, one of the most common communication obstacles is people prefer getting acquainted on face-to-face meetings. We are usually the ones to insist that the live meeting be organized from time to time (especially at the beginning of the cooperation) – either in our office or in the client’s office. Even if it’s just one meeting, it’s going to make a huge difference in how both teams think about each other. The cooperation becomes a lot more real.

But there is one more important, often overlooked aspect of good communication. The technical one!

When most of the communication between team members is done remotely, online, we want to make as many calls as possible, as regularly as possible. And with so many calls, the quality becomes a very important issue. Many typical communication concerns of the in-house team can be solved simply by using quality equipment. Extensive conversations become very tiring when the quality of voice and video calls is low. That’s why we have professional services solutions at our disposal to cover the issue on our end.

The chain of command is another important factor to consider…

This is also a matter of good communication. Of course, at Dot Com Development, we have Project Managers overseeing the development teams. However, the Project Manager should only help push some issues forward. All the most important project decisions should be made together by the all stakeholders.

Can the flow of this communication be designed from the start?

This is one of the things that can’t really be put in the agreement that easily. It’s good to follow a certain rule of mine: Let’s be mature about it. It really does wonders for the efficiency of the chain of command. Some processes simply require time to work as expected.

Organization

A common understanding and technology are indeed essential. But it seems that the cooperation between the in-house team and outsourced developers may still fall apart without proper organization. How do you prevent prevent chaos?

Proper tools, methods, structure, governance and attitude. To be more precise, constant contact using collaboration software such as Skype, Slack, Teamwork or any other suggested by the client’s company, as well as Agile- and Scrum-derived events such as daily stand up meetings, 1x/2x per week status calls, bi weekly sprint meetings should be carried out regularly.

It’s quite a lot to have to think about … but it’s actually a good thing, as long as it’s not too overwhelming. This organization of remote collaboration makes the whole project more efficient. Sometimes, when all devs are in the same room there is a temptation not to write the notes after a meeting or document the workflow used or even tasks – with outsourced team you have to keep those things in mind – but that’s a good thing for your project.

Emphasizing good organization is, in fact, one of the major changes outsourcing can bring.

When you teach people how to organize remote work properly, they start applying good practices in their everyday tasks, outside of the remote project. In the long run, the whole company will become more efficient thanks to that.

Technology

How about the fears directly related to software … “Will the new guys use the tech stack that we’re accustomed to?”

Q: What if the client uses or wants to use technology that Dot Com Development doesn’t specialize in? Will you try to convince them to use something else and have their in-house team switch their stack?

No. If there is no technology match between us, we’re simply not going to get involved with that project. We may suggest changes to the technology stack, but, again, only if it’s in the client company’s and solutions best interest. However, when these changes do happen, in-house developers usually tend to become quite cooperative.

Many of these changes are actually highly welcomed by the in-house team. We are often the ones to push improvements such as rewriting the front end to a SPA or implementing an API-based architecture. The in-house devs often have the same ideas, but alone they lack power to get them green-lighted.

Our appearance makes for a good occasion to introduce some much-needed technological changes in the organization of our client.

Summary

So, what do you think? We sincerely believe that now you are more than properly equipped to talk to your in-house team about outsourcing. Just to sum it all up:

• As far as our knowledge goes, nobody has ever been fired because of us.
• It’s all about being on the same page and traveling in the same direction, so the ability to understand each other clearly is essential. Of course, part of it is speaking the same language (English). But there’s more to it. Which leads us to another conclusion, that…
• Communication and technology are connected. As you work together, your outsourced developers will be able to understand your project-specific language, which will make a huge difference.
• Organizational strategy is essential from the very start.
• It’s important to keep in mind that introducing an outsourcing team can become a catalyst for major positive changes in your organization.

The Bottom Line

Hiring a dedicated development team (done right) is a successful, flexible, cost-effective, and convenient alternative to in-house software development. Especially if your business has a small in house team but is not in the primary business of technology development. Let a partnered and dedicated team of  technology professionals do what they do best for you, while your business focuses on the rest of what it does best.

Dot Com Development is an awarded and trusted partner with the expertise and experience to design, build and deliver your business critical solution on-time, on-budget, and to a capacity that exceeds your expectations. Contact us today for a free consult and see if we’d be a great fit to work together. We’d be happy to earn your business the old fashioned way.