These are the questions we’re going to tackle today in an interview with The Software House’s Chief Technology Officer, Marek Gajda.

As the CTO at The Software House, Marek oversees and advises on just about any TSH project. Having also previously worked as a full-time programmer, he knows the typical challenges of in-house outsourcing cooperation from both perspectives. I asked him some questions. For convenience, I divided them into a couple of areas of interest.

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?

Marek Gajda: 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 in 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 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, what would they fire those they already have?

Based on my experience, nobody has ever been laid off because of us.

On the contrary – as the team was growing in size, many in-house devs would become leaders, often tasked with overseeing the work of the outsourced team. So, if anything, they got 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 appear in 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, that is true that all 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 usually do is we 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 significant control over its development.

It’s often said that the key to fruitful cooperation is earning trust of lead devs. What do you, as a software house, 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…

I really don’t think so. 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 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. We’re going to be listening to the in-house team. 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

Exactly – the cooperation. 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:

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, especially with Polish developers who consider English to be an essential tool in their work. Of course, the same goes for TSH developers. They are often happy to work with foreign devs, because it is an opportunity to improve even further in this area.
• 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 we will catch up as soon 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 to cooperate smoothly and understand 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 headquarters 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.

That is?

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 hardware 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 The Software House, 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 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

The 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 to prevent chaos?

Proper tools, methods and attitude. To be more precise, constant contact using collaboration software such as Slack or any other suggested by the client’s company, as well as Agile- and Scrum-derived events such as daily meetings and retrospectives carried out regularly.  

Seems like 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

We already covered some of the most important issues when it comes to communication and organization of the in-house and outsourcing cooperation. Let’s now get to the fears directly related to software. “Will the new guys use the tech stack that we’re accustomed to?”

This is an aspect in which we DO want to have a lot to say. That’s why we’re talking about technologies at a very early stage. And we suggest specific solutions as soon as we have a full grasp of the situation.

What if the client uses or wants to use technology that The Software House 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 best interest. However, when these changes do happen, in-house developers usually tend to become quite cooperative. 

Why is that?

Like I said before, 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 frontend 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 greenlit. 

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. We were able to fit just right in various software development outsourcing scenarios.
• It’s all about being on the same page, 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.

Want to learn even more about this subject?

Further reading

If you do want to continuously improve your in-house team:

• read our guide on how to hire software developers,
• expand your knowledge by learning about common fears or SaaS companies over outsourcing,
• learn more about the differences between freelancers, in-house team and software development companies,
• and why Nordic companies specifically are falling for outsourcing.

And most importantly, reach out to The Software House with your next project!