From the countless number of products I have helped bring to market over the years, the ones that nearly failed are usually those developed in conjunction with an external software outsourcing vendor. The vendors in question were chosen based on a recommendation from a friend of the executive or because they received some kickback from the deal.
In one case, it led to quick agreements that based the relationship on sheer speculation that the vendor was to be trusted, and thorough vetting was not required.
The first red flag popped when the vendors refused our software engineering teams to review detailed resumes. Instead, we received a card stating that the individual had "X" years of experience with the same technology stack we used. Because of this, the executive team put pressure on the engineering team to get started immediately.
There was not a single test, line of code reviewed, or even questions about code structure and object-oriented programming — not a problem to solve to see how the engineer approached complex problems. The team grumbled a bit and focused on the day-to-day while getting the new front end, back end, and, supposedly, a tech lead ready to ramp up on the systems.
The second red flag came when the first group of engineers started onboarding with our teams. It took days of back and forth with the engineers because they were nine hours ahead. It took four to six weeks to start seeing production delivery. The code that was delivered did not pass testing. And a junior developer replaced the senior tech lead.
Staff had to spend more time coaching, teaching, and guiding the outsourcing team, which took focus away from critical deliverables and ultimately delayed business objectives by several months. The outcome affected the business, losing opportunities and fraying existing client relationships. In the end, we all learned a valuable lesson, and we had to have a heart-to-heart talk with the decision-makers concerning all the problems encountered when our teams could not vet the vendor and its candidates thoroughly.
After that, I made sure to review in-depth every single vendor. Yet I faced enormous challenges regarding vendor transparency on talent, costs, skills, and performance. Other problematic areas I commonly discovered using different vendors were talent assigned to other projects while working on my products, talent rotation, and engineers unavailable when meeting critical production deadlines.
To this day, when talking with technology executives, those similar gaps still come up, so I decided to tackle that challenge and push for greater industry transparency.
In leading a software engineering services organization, a strategy I share with business owners, engineering stakeholders, and economic buyers is to approach software outsourcing vendors with a vetting plan that focuses on total transparency, talent evaluation, onboarding process strategy, training, and retention programs. Furthermore, the vendor needs to be able to understand fully what your needs are. If they don't get it, move on.
So even if you are a small startup or mid-size company, it is helpful to have preliminary documentation on the following, if applicable. Based on my experience, here are a few questions to ask about your business before engaging a vendor.
What are your business overview and objectives?
Spell out what it is that your business is trying to achieve. Also, review why the initiative requires certain technical elements to materialize and maximize ROI.
What does your tech stack look like?
Break down the technology stack you are using or looking to use. This overview guideline is essential and can expand depending on complexity and scope. This includes a full technical stack review, meaning apps and data, utilities, DevOps, and business tools. An essential product introduction might entail:
• Agile PM Platform: Documentation (e.g., Jira, Rally, Trello, etc.)
• Repositories (e.g., GitHub, GitLab, etc..)
• UX: Adaptive, technical feasibility, asset manipulation
• UI: Performance-optimized
• Front End: Performance/ReST APIs focusing on the presentation layer of architecture schema
• Back End: Schema cocreation/authentication/data management
• iOS: Objective C/Swift/React Native/Flutter
• Android: Android Dev Kit/Java /Kotlin/React Native/Flutter
• QA: Test-driven development/unit testing
• DevOps: Docker/Kubernetes
• Security: Best practices
• Compliance: Protocols
• Server Setup: Local, staging, testing, release/production
What does your architecture overview/workflow/diagram look like?
1. Presentation Layer: This entails all the components for users to interact with the application (UI stuff too). It is for processing the user's input and returning the accurate response to the user.
2. Service Layer: This is a transactional boundary and contains both the application and proprietary infrastructure services.
3. Business Layer: This includes the application's core business rules and functionality.
4. Data Layer: It's the bottom layer of the application. It communicates with stored user data.
After signing an NDA and presenting the software outsourcing vendor, your business requirements document should cover the following, which you may want the vendor to address:
• Ability to review resumes
• Ability to review preliminary screens from the resumes proposed
• Ability to provide calibration feedback and pivot the search
• Review preliminary technical screen
• Review technical testing video and actual code of those tests and challenges
• View resource salary requirements, taxes, benefits costs, insurance, and vendor profit (total cost of ownership calculator)
• Review onboarding strategy
- Career growth and retention plan
• Resource equal-replacement contract clause
Doing your due diligence before starting a technical project with software outsourcing vendors is vital to ensure business success. Take time to review all necessary components of such a partnership to ensure goals are understood, and processes are outlined across the team from the start of the collaboration.
Stay away from Vendors that spend more time on sales marketing campaigns (Pay to be listed in CLUTCH and other online media) than investing in their core operations such as technical evaluators, seasoned technical recruiters, and proper tools that can provide you with proactive governance. You will be surprised at the amount of smoke and mirrors I’ve personally discovered by talking to more than 200+ companies that struggle with their current vendors.
Please feel free to reach out to me for more data points and an overview on vendor evaluation criteriaion that can narrow the decision gap while mitigating long term risk.