In this blog, we briefly share our experience with team augmentation, specifically engaging with service companies in India. We delve into the process of discovering, connecting with, and collaborating with them. Our focus centers on extracting key insights from this experience rather than providing an exhaustive playbook for implementing team augmentation or outsourcing which you can find in this blog post: https://p2p.jobpairing.com/homepage/2023/10/10/must-have-documents-for-outsourcing/
Background
Over four years ago (in 2019), we started Job Pairing with the goal of creating a platform for matching professionals with common and complementary skills to pair up and share the same job. Our objective was to enable these professionals to reduce their work hours while maintaining their career paths.
We had seed funding and some expertise. Our team’s expertise was mostly in product architecture and design, and project management. However, we literally did not have any software programming skills to develop the front-end (user interface & website) or the back end. We estimated the development effort to be at least 5 person-year.
We looked at three options.
Option 1: Hire software developers in the U.S.?
Hiring local software developers in the U.S., even though ideal, was not financially viable for us. It would have required at least an estimated $500K budget for the first year. And then we needed additional budget for hosting the service, maintenance & sustaining, marketing, etc. on top of that.
Option 2: Hire freelancers from lower-cost regions?
A second option was to hire a few freelancers from lower-cost regions (e.g. India, Pakistan, Bangladesh, etc.) to augment our team. While this option was financially viable, the challenge would be hiring a few software developers who had not previously worked together, and managing them remotely. We saw this option as a high risk and slow process to build the team. A new group of individuals are likely to experience the different stages of Tuckman's team development model: forming, storming, norming, performing, in order to establish effective collaboration. Another significant concern was that if any of the freelancers, for any reason, becomes unavailable, we would have to take time to find a replacement and undergo the onboarding process and train them for the job.
Option 3: Hire a small “team” from a small service company in India?
The last option was to engage a small service company in India who could allocate a dedicated team to our project. We chose this path for several benefits that aligned with our needs. First, we wanted to get a small team of software developers with prior experience working together so they can hit the ground running. Second, working with a service company gave us more confidence that, if a team member was unable to continue for any reason, the company had other resources with similar skills to step in quickly. Last but not least, we preferred working with small to midsize service companies, which typically have lower overhead and a more entrepreneurial mentality.
How do you find a small software team in India?
At that time, no platform existed to facilitate the discovery and connection with small service companies. Major players in India like Wipro (over 250,000 employees) or Infosys (over 300,000 employees) are big cats, have big overheads and charge big money. It was not practical for our purpose and our budget.
So, we focused on smaller players. We utilized our former colleagues and friends from India to get connected to a few smaller service companies. Our criteria was companies with less than 200 employees. After evaluating and assessing their software capabilities and management, we chose two companies to work with: one to develop the front-end (website and the user interface) and the other to develop the back-end services. And we kicked off the effort with established teams in less than 1 month!
As a side note, while searching for suitable service companies meeting our criteria, we identified a gap: connecting small to mid-size businesses in the U.S. (and other regions) seeking software developers with small to mid-size service companies in India (and other lower-cost regions) who have the expertise. Larger clients have their own resources to hire teams globally, and larger service companies deploy representatives in the U.S. and elsewhere for client acquisition. Consequently, we created a new service platform to bridge this gap, the (Peer to Peer) P2P Hiring Marketplace.
Visit https://p2p.jobpairing.com to learn more.
How do you work with service companies?
1. Product Requirements
When working with service companies, especially in remote settings, documenting product requirements in great detail becomes crucial. It helps to prevent misalignments and misunderstandings that lead to reworks and subsequently waste of time and money. We opted for a shared document that provided a series of wireframes for the user interface and the website, along with a set of “mini specs” that defined the platform functionality. We kept these requirements up to date at all times throughout the lifecycle of the project. Regular reviews, conducted in our weekly team meetings, ensured that everyone remained on the same page and aligned closely.
Furthermore, we (the US team) utilized the same documents to guide our acceptance testing (functional, usability and regression testing) for each deliverable and each release.
2. Regular and Frequent Communication
Regular and frequent communication plays a crucial role when collaborating with remote teams. To ensure effective coordination and synchronization, we established a standing weekly team meeting (video call) on Mondays, which we religiously maintained for over four years. Throughout the week, we utilized email for general communication, addressing requests, and answering questions. In case of urgent matters, we leveraged text messaging, with WhatsApp being particularly popular in India, to connect with our team leads and, if necessary, schedule same-day discussions.
Weekly discussion topics included:
- Review major tasks to be completed that week.
- Get a status update for upcoming deliverables and milestones.
- Conduct design reviews, as needed.
- Identify any challenges, risks and issues that needed to be addressed.
- Review requirements and mini-specs, or updates to them.
- Review list of bugs and reported issues for a plan and resolution.
- Review any new change requests or new functionality request to be worked on.
- And other project or people related issues, as needed.
Due to lack of programming expertise in our U.S. team, we did not conduct any detailed design or code reviews, and completely relied on our partner team in India to cover those. Instead, we focused on establishing and maintaining solid requirements, testing and quality assurance, and user experience.
3. The Shared “Tracking Document” for Project Management
The development and release process was staged in three phases: Development, Pre-production, and Production. All new development or bug fixes were first completed and tested in the development environment, then integrated into the pre-production staging server for system and platform level testing by the U.S. team (functional, regression, performance, usability, and user experience), and then moved to production.
For scheduling and tracking purposes, we divided the project into tasks, consolidated several tasks to achieve major functionalities and milestones, and organized these milestones into updates to be released to customers.
To plan and track tasks, milestones, and various releases, we utilized a shared spreadsheet (“tracking document”) containing the following entries:
- id no.
- person who requested the feature or reported the bug
- date submitted
- summary of the task (feature, request for change, or the bug) or milestone
- status
- priority
- target production release (we had established various release “trains” to production)
- steps to reproduce the bug
- developer assigned to the task or milestone
- response from the developer (questions, suggestions, request for additional info, etc.)
- any notes/remarks on the task or milestone
The tracking document was reviewed every Monday with the whole team focusing on the weekly tasks while making an assessment toward completion of the next major milestones and the next release.
Cost savings and other benefits
In our estimation, the development cost for the two platforms (JobSharing and the P2P Hiring Marketplace) was reduced by $600K-700K (over 60% cost reduction) compared to doing the development in the U.S. This decision was make-or-break for our venture.
Another benefit of working with the team in India was the so-called “follow the sun” model, which enabled us to collaborate with the development team almost around the clock. This approach significantly accelerated our development time during the coding and testing phases. For example, during the daytime in the U.S. (nighttime in India), we conducted testing and validation, reporting any bugs or issues through a shared tracking document. Conversely, during the daytime in India (nighttime in the U.S.), the India team worked on developing fixes or new functionalities for the U.S. team to validate or review. This approach worked exceptionally well for us.
Challenges and what we would have done differently.
One area that we (the U.S. team) did not do a good job of was to develop a better understanding of the backend infrastructure for hosting (AWS) and other services (Google Map and SSL). In two occasions the AWS instance went down and as a result our website became unavailable to users. We did not know enough to fire up the instance and get the website running. We had to send urgent messages to our India team so they can take care of the issue in the morning (their time) when they are back at work.
On another occasion, our new SSL identification was not integrated properly, causing the website to display as 'not secure.' We identified the issue but had to wait for the India team to resume work in the morning (India time) to address it.
One thing that we would have done differently is ensuring that one of the team members in the U.S. receives comprehensive training in the backend infrastructure to handle such cases, minimizing downtime.
Last words…
Our experience with engaging small to midsize service providers in India to augment our product development team has been exceptionally positive. We hired a highly qualified team of software developers in less than a month, at a 60% lower cost, and successfully completed and launched two service platforms. Our enduring relationship with these teams is strong, and should the need arise to augment our team in the future, they would be our first choice without hesitation.
We recommend evaluating the option of hiring a team from a small-mid size service company in India or other lower-cost regions if your team faces software and IT gaps, and you are concerned about the extent of your funding for the venture. This can be a worthwhile endeavor.
Learn more about team augmentation as a strategy for boosting your startup in this blog.