How Dev Works

Insights on software development management

Contractors, Outsourcing and Organic Teams: How to Avoid the Babel Tower Effect

1 Comment

building collapsing

The Babel Tower.
Yep, definitely the Babel Tower. That’s what I thought and it was no surprise.

One development team located in India, another QA team based in East Europe, two more groups in Israel and on top of that – a few contractors who have never worked together… Could a group of about 30 people, scattered over half a globe, create a working product within less than a year?

As always, the answer would be “It depends”.

In this post, I talk about what I learned while managing a project, lacking resources and knowledge, which turned to be a success thanks to hiring the right contractors, and working with an outsourcing team.

One more word before we begin: It is not an advertisement for contractors. It is not a recommendation to outsource. It is simply food for thought for development managers, who find themselves in the position of trying to figure out how to succeed under challenging conditions.

During this particular project, we had to dive into the internals of a large ERP system. We had to extract data using undocumented APIs and rely on trial and error. The result, cross-referenced with data pulled from database servers, web servers and J2EE application servers, was presented to the user.

Right from the start, it was obvious we were short of at least one development team. Moreover, the engineers were not familiar with the ERP system (a course did not help) and on top of that, the client technology was relatively new and unstable.

One option was to recruit engineers and ERP experts, but the process was too long. Besides, expanding the development department was not an option. Thanks to LinkedIn, we found two ERP experts. After several days of interviews and negotiations, Meir and Haim joined us. While they were figuring out what needed to be done, the ‘regular’ team members watched them and got a hands-on crash course in ERP Internals.

It took two months to crack the system. When it was over, we had a solution as well as a well-trained team of ERP professionals.

Meir, Haim – thank you!

This took care of the lack of knowledge, but we had to think of a different solution to make up for the lack of engineers. Technically speaking, the client and the server were loosely coupled so as long as we maintained a clean API, we could develop the client without affecting the server. It made outsourcing the client development a relatively safe alternative.

We engaged an outsourcing agency and recruited four client-side developers. Since the outsourcing team was located off-shore, we had to adjust our working procedures. We had to change how we updated our code base, keep good communication (a ten-minute daily “stand-up”, agile style meeting between our contact man and the outsourcing team took care of it) and nurture cooperation. But this is a topic for another post.

I am emphasizing the fact that the outsourcing team was working on an isolated component (the client), because this was the secret behind the quick ramp-up time. On other occasions, the outsourced or off-shore team may be developing a component which is tightly coupled with the entire system. If this is the case, you should expect a much longer ramp-up period, before the teams can work effectively together.

A few more words before I wrap up – there are many ways to work with contractors. For example, it can be done on a weekly basis (e.g. half a day, once a week). Another way would be full time over a shorter period of time. In long projects, working on a full time basis kept the team and the contractors focused and worked best for me so Meir and Haim worked with us full time. They participated in all our achievements, celebrations… and crises. We treated them like any other worker and got, in return, 100% commitment and willingness to work above and beyond what you’d expect from a ‘guest’. They were simply part of the team.

Here are a few points worth remembering:

  • If you identify a distinct subject in which you lack knowledge (e.g. Windows Internals, storage, a specific DB, Etc.), you may find that working with a contractor who can teach your team on-the-fly can be a fast, cheap and effective way to get the job done.
  • When working with the right consultant, knowledge won’t be lost. The opposite will happen – your team members will learn new stuff and knowledge will flow into the system.
  • Not enough engineers to get the job done, but outsourcing is an option? If you find an area which is loosely coupled from the rest of the project and is not related to the core of the product, outsourcing could be a good solution.
  • If you choose to work with contractors or outsource teams, be sure to treat them as if they are part of your regular team.
  • If outsourcing and off-shoring are not a standard in your company, remember to stop and think how to adjust the existing processes to the new situation. Issues such as working on a shared environment, delegation of tasks and responsibilities, information flow, code base management and many others matters require planning and forethought. This is a separate topic which touches people, processes, and even technologies, and I will talk about it in another post.
  • Similarly, make sure the rest of the team knows everything there is to know about the role of the contractors and outsource engineers. Otherwise, this might be the beginning of a long chain of misunderstandings, not to mention the feeling of being threatened which will shoot down any possibility of cooperation.

Good luck,
Ilan

One thought on “Contractors, Outsourcing and Organic Teams: How to Avoid the Babel Tower Effect

  1. Vineet Luktuke's avatar

    Nice post Ilan… If you remember, we worked together in one of the organization and I am a big fan of yours coding especially vec_mod.

Leave a comment