7 Hidden Secrets for Working with Third-Party Dev Teams

There are so many horror stories of companies who were thoroughly disappointed with their development outcomes using outsourced off-shore software development companies. For example, a San Diego start-up developing a Telehealth application cited a low-ball development price of less than $30K that would include video conferencing with doctors, along with creating a medical record that could be integrated into the client's EHR system. One year later, they are suing that company and have already started developing with another company along the same vein, making the same mistakes as before.

If you Google for tips on successful offshoring, you'll find articles produced by the outsourced development organizations themselves. Most follow the obvious tips: provide specific details, communicate clearly, set clear goals. These are obvious to anyone experienced in software development. We've developed a different list -- seven hidden secrets that come from decades of experience using off-shore, near-shore, and on-shore developers, viewed from the customer's perspective.

Secret #1 — Technical Lead Is Near You

While the development resources can be off-shore or near-shore, the best way to ensure success is to have the technical leadership in a close time zone -- within 3 hours. The most important person in the development process is your technical lead. That person must be extremely strong and is essential to fill the gaps that will absolutely occur during development. Being in a similar time zone, they can be readily available for the rapid and constant adjustments that occur during development. The technical lead is the primary communication conduit between you and the project team, and their technical competence can make or break the project.

Secret #2 — Embrace Exactness

Off-shore and near-shore resources create a natural barrier due to language, cultural, and time zone differences. What may be obvious to you will be interpreted differently, even with written specifications. The more exact you can be, the better the outcome. Two tools produce exactness: prototype builds and functional requirement documentation. Prototype building is essential. Tools like Figma, Adobe XD, InVision, and Sketch simulate the end application and provide an obvious guide to UI and user flow -- but what is less obvious is that prototyping makes a significant impact on back-end architecture, which is significantly harder and more costly to change mid-stream. Prototypes are also essential for early customer feedback and can be used as a demo for sales teams before the real application is available.

Secret #3 — Product Management

Whether you hire a seasoned Product Manager or not, an excellent product management function is essential. Building the wrong product has the most impact on wasted development costs. Many organizations mistake the technical lead for a product manager -- they are entirely different skill sets. Technical leads provide direction on implementation, not which features to include. They don't tie features to business success. An expert Product Manager bridges the gap between business and technical worlds, translating business needs into requirements the development team can consume. Excellent product management results in reduced resource waste, avoids scope creep, and focuses on the MVP to ensure projects are completed on time and under budget.

Secret #4 — Be Involved

Some outsourced companies only allow you to interact with the project manager and technical lead. This puts the development process at arm's length and increases the risk of an undesirable outcome. Choose a partner that allows close collaboration in the development process. While you don't need to micromanage the developers, being intimately familiar with project implementation and ready to address issues immediately is essential. At a minimum, a technical lead from your own team should participate in daily scrums. You should review Agile user stories to ensure they are correct, or generate the user stories yourself for the outsource team to follow.

Secret #5 — High-Level Docs

There are two high-level documents especially important for medium and high-complexity software applications (defined as requiring a team of 5 or more developers). First: a software architecture document covering the block diagram, technology stack, developer tools, cloud services, data models, and programming languages. Second: a data pipeline architecture document encompassing data sources, ETL/ELT process, pipeline automation, data integrity, data security, and data provenance. These documents are often skipped in the rush to start development -- and that shortcut almost always costs more time than it saves.

Secret #6 — Create a Winning Team Culture

The Golden State Warriors won 4 championships in 8 years in part by creating a winning team culture. A winning culture means the team is more important than any individual, leaders check their ego at the door, and every member is considered important to success. Make the experience enjoyable -- the team members you select should meld with your working style and bring levity to the atmosphere. Create an environment of learning and growth. Treat each outsourced team member as part of your own organization, even if they technically work for the development company. Make them feel as important as your in-house employees.

Secret #7 — Plan Tomorrow Today

It is always difficult to know what the future holds, particularly when you are scrambling to bring a project in on time and under budget. However, to the best extent possible, future product plans should be explored near the beginning of the project to ensure the final architecture can support them -- or has a reasonable path for minor modifications in future releases. Major changes to the back-end based on future requirements are extremely painful and create a ripple effect across the entire product and customer experience. Even worse, essential new requirements may be abandoned because the ROI does not justify the development cost when the architecture wasn't designed for them.