Skip to main content

Some of the challenges of being involved in outsourcing as a developer

For the past years I have talked and interacted with a lot of developers involved in outsourcing, gathering some nasty or challenging parts of their experiences. Fortunately I didn't run into all of them, at most 2 or 3, and not the whole time. Still it takes some skills to overcome them.

Firstly, when you work as a developer in outsourcing you pretty much have 2 sets of bosses and managers. One set is at your main company that pays you directly and another set is at the client for which you are actually developing software and whom signed a contract with your company to provide him with some developers, like me. We call him a client but actually there are multiple people at the client involved in the development process. There is usually a product owner that gives you the requirements, stories and things that you need to develop. Besides him, there is usually a technical person too, a technical leader that establishes the development stack. These 2 people can contradict themselves.

For example the product owner might want as many features developed as possible while the technical lead might want to use new technologies, rewriting some of the old things in the application. Sometimes the client can also demand consultancy from you but at the same time if you come up with suggestions he might feel like you are trying to steer the software and business away from what he wants.

This is already an issue but it's just the beginning because there can be also a technical lead in your team and direct company. Or there can be another person in your direct company that wants you to learn something different that the technical lead from the client wants. And in general, there will be at least 2 separate directions that are established for you, one by the client company and one by your direct company. And you can't really follow these 2 directions at the same time. Sometimes there might be more than 2 directions.

No matter what you do, you can sometimes do bad in the eyes of someone that matters. You have to find the right moment to combine the demands from all of them into one single task. If for example the product owner from the client wants to extensively change a feature, then it might make more sense to write it from scratch and use a technology that the technical lead or another important person wants.

Secondly, usually the client and his people will be quite far from your location and you won't meet them face to face very often. So you will have to rely on video calls and other means of communication. But communication is critical to establish a well relationship between you and the client and his employees. The client should also have some experience using video call tools, presentation tools and so on. Some people don't really have these skills, and are used to talking directly face to face to communicate what they want. When they start working with people 2000 kilometers away they will have some problems adjusting to this. It's really important that they are willing to use the right tools for this and willing to learn some new tools and how to do things differently.

Writing pages of things is not really a good idea because reading a lot becomes tiresome. That's why video calls are much more better. Speaking is much more faster than writing and it involves less effort. But the client has to have the tools and knowledge to use them, tools like Microsoft Teams, Skype or anything else. Or he has to be willing to learn them and adapt. Furthermore, some things are better explained by showing your desktop and application directly. For this there are tools that allow you to do this using desktop sharing. Best one that I worked with so far is Microsoft Teams.

Thirdly, usually with outsourcing, there is a client from the western world contacting an eastern company which can be on another continent or not. And this is where one of the ugly side can arise. The further east you are, the more the client and his employees assume that you live in backwater uncivilized country. This can lead to a general distrust and tension between you and the client. You sometimes need to earn the trust of your client, to make him feel safe and that he is getting something for what he pays.

If the client has its own developers too, then they will get the top treatment and more trust than the contracted developers from the outsourcing company. And this can become quite a challenge. If you have an idea to do something, you need to go the extra mile to convince the employees from the client to let you implement your idea.

After a while this can become really tiresome. Not to mention the fact that as a contractor and outsourced developer you are held much more responsible for any mistake you make than other people employed directly by the client. And you can get criticized more often. I think this distance and lack of face to face communication can cause a lack of empathy. That's why video conferences where you can see the other person are useful. It humanizes the interaction. But you are still sometimes still seen as a bit of a caveman and there will always be a bit of sense of superiority from the client's side. Still, I didn't see this that often but I know people with were criticized a lot more.

Fourthly, you will receive an external software that you need to work on. And that software can be written in a completely different style than you are used to. You can have any sort of surprises. I worked on 2 completely different projects that had completely different approaches to doing things. After I gotten used to the first project, I switched projects, and all that I learned from it was completely useless.

Actually did more harm than good in the second project. I actually had to unlearn all the tendencies that I acquired from the previous project because they were not in accordance to the new guidelines and style from the second project. And not just that, but you might work on applications from completely different domains. And you will need to spend more time to learn the domain of the application. When you work a long time in a product company, you will learn the domain of the product, its users and so on. With outsourcing, you are dragged all over the place. I was lucky enough though to work on applications from a single domain.

Fifthly, you can change your team pretty often. If you are the kind of person that has to put a lot of energy and effort to adapt to a new team and new people, then you are in some trouble. You might land in a team in which you have a lot in common with your colleagues and easily fit in with them. But you might land in a team in which everyone already made friends and relationships with other colleagues. Then you can be isolated.

Sixthly, there are a lot of other small issues that can add up to a lot of pain. For example, usually the person talking to the employees from the client is assumed to have done all the hard work and takes most of the credit. If you like to work from the background and make sure that things go smoothly, then you will be in a bit of trouble. Or if you talk and interact with the client a lot, you will need to put extra effort into making him feel special, welcome and so on. If you need to bring an issue up or to contradict him on something, it might be problematic. Or sometimes you need to put up a show to impress him, to seem really educated and technical.

In the end, there can be some problems with outsourcing and a lot of hard things that some people are not even aware of, having nothing to do with programming. Collaborating at such distances is a skill to learn by both sides. It's might be worth it for some people. Maybe for some people working in a product company with less pay or less interesting technologies might be better.

Comments

Popular posts from this blog

Some software development common sense ideas

 I haven't really written here in a long time so it's time to write some new things. These are just some random common sense things that seemed to short to write about individually but seem really interesting and useful to me or other people 1. There is nothing fixed in software development, all things vary by circumstances and time Remember the documentation that didn't seem that important when you started the project, well after a couple of years one the application has grown and become really complicated, no one actually knows everything about the application anymore. So now you really need that documentation. What happens if you suddenly need much more people to develop the application because of some explosive growth? Without documentation, new developers will just look at the application like they look at a painting. This actually happened to me. Maybe in the beginning of a project, a technology really helped you a lot but as the project grew, it started making things

My thoughts as an experienced developer in this field.

To be honest, I would have never guessed that      I would end up saying these these things, especially jn the beginning of my career. As you become more experienced, you kind of get to see everything and you become less impressed by new things. Honestly there is some sort of repetitiveness in this field and we kind of like to reinvent the wheel quite often, because well, we become a bit too easily bored. Take for example how the web looks now, a lot of it has been borrowed from other places, mostly desktop development, especially the parts about making custom reusable components.  Or from older frameworks, like state management in the UI which actually was first properly implemented in Asp .Net Webforms, as far as I know, something like 20 years ago, where you used to have the dreaded view state.  But most likely something similar existed before that too. I was not that surprised when React adopted initially this idea. Or even less surprised when hooks where introduced that seemed a b

Some things which are often blindly applied and followed by developers which are not always good

This is probably one of the most controversial things that I have written so far but I am just tired of hearing about these things and discussing these things. Other developers that I know share part of my feelings. I would rather hear more about how people built things, overcame challenges or what new interesting ideas and concepts they implemented. Those things are really interesting and innovative, not hearing about the same theoretical things over and over again. I can just read and learn those things from 100 sources on the internet. Firstly, one of the most discussed and promoted things is agile/scrum development. I think I have been through 5-8 workshops about agile development methodology. And each time, some things differed. There is no 100% standard approach to this. Everyone uses their own version of this development methodology and seem to argue a lot that their approach is right and everyone else is doing it wrong. You go to an interview, this will be one of the first 10 t