How to Evaluate an IT Staff Augmentation Firm

If you’re a mid-sized or startup-style tech company seeking an IT staff augmentation partnership, who should be making the hiring decisions? With more standard software development, this would usually come from the level of the CEO or CMO. But for more technical work, the CTO will need to do most of the vetting. After all, the goal is to find developers with specific skill sets or coding fluencies to augment your own internal team.

However, you’ll also want to look a bit farther down the hierarchy—for example, to your VP of engineering or even a senior product manager. The reason for this is that you want the people who manage daily tech tasks to be the ones vetting any new developers, because the best form of staff augmentation is when there is no delineation between your internal developers and an external vendor’s developers. They should seamlessly integrate as one, so that you can scale more effectively and achieve technological capabilities you didn’t previously have (in other words, the reason you sought staff augmentation in the first place).

When vetting a standard software development agency, you’re generally evaluating them based on general B2B buying process considerations, such as:

• Their previous work
• Frequency of communication
• Accountability to their deliverables
• Client case studies

But when you’re vetting a firm, it means you’ve already decided not to go with direct hires or traditional, full-service agencies. So, how should you approach a firm differently from the way you would approach your other options?

Similarities and Differences

When it comes to IT staff augmentation, you may undergo a very similar process to direct hiring: vetting individuals on a personal basis, noting their strengths and weaknesses in both software development and communication. Specifically, you want strengths in the coding languages that you require for your project. This doesn’t change.

But the biggest difference comes in the negotiation. When you hire someone, you have to negotiate benefits, 401ks, healthcare, and office space (or, if remote, what equipment you’re going to provide). When engaging with a development agency, the overhead is generally taken care of already, and your negotiation will have one simple focus: the flat price for your desired developer.

By this point in the process, you should already have selected an option within a few time zones of your business.

Nearshore is Best for Staff Augmentation

In terms of speed-to-market, you’re ultimately looking at two factors: cost and time zone. Where you choose to go is going to impact those two factors heavily.

Onshoring, for example, only makes sense if speed is your only consideration—because, say, your budget is big enough to absorb every other risk. Even so, it’s not likely to save you any money, because you’re competing in the same talent pool as that from which direct hires would come. In this case, you may as well go with the direct hire model.

Offshoring only makes sense in a traditional, full-service type of engagement: it’s more hands-off, and you won’t necessarily require so many regular updates from the other end of the partnership. This can be beneficial if you are doing a classic agency model, especially if you find the right developer via that model, but it’s hard to do so in a way that is both cost-effective and conducive to communication.

Nearshoring lends a special efficiency to the IT staff augmentation process as it tends to help companies strike the balance between cost and convenience. The best way to get the most out of the developers you bring on in a staff augmentation engagement is to seamlessly blend them with your own team, isn’t it?

Consider the example of one of my company’s clients, MasterClass: they currently employ about 20 developers in an augmentative capacity. Now, MasterClass has a daily standup—like many development teams do—at 9:00am every single weekday. Because our developers in Uruguay are within a few time zones of MasterClass in San Francisco, these standups are within working hours, which means our augmented staff can always be there.

This has been crucial to staying on the same page, tracking the same deliverables, tasks, sprints, all in the same way; we are collectively able to avoid miscommunication entirely. And, as we know, technology is so fast paced that getting out of sync, even by a day or two, can cause cost overruns and create friction between your partner and internal team. All in all, nearshoring offers the balance between cost and time zone for ease of communication.

Good Signs When Evaluating a Firm

• Prior experience
• Strong resumes
• Bios provided
• Interviews allowed
• Demonstration of skills via code tests
• Technical standards demonstrated via Github repositories
• Previous work examples
• Experience within your specific industry (quick uptake and sensitivity to nuance can save you time - and money)
• Good project management (for example, bilingual project managers who can bridge the language barrier—because sometimes, the most phenomenally talented developers just have more skill with software than with English)

Red Flags When Evaluating a Firm

If a vendor won’t allow you to interview potential developers for your project, you shouldn’t hire any of them. At this point in the hiring process, you’ve probably spoken with a sales representative and seen a couple of bios; it’s later on, closer to the decision time that you will have narrowed your search down from twenty-some vendors to three or five. So, in the final sales stage, it’s more than reasonable to expect veracity. You have established a negotiable relationship with this vendor; it is more than fair to make sure you as a client are getting quality before you sign a contract with them. You don’t want to get rejected from the App Store, have your product break and reflect poorly on you, or end up with software that can’t be built upon in the future, and that starts with trusting your developer.

No previous client work is also a bad sign. Some vendors try to position someone as a senior developer when in truth, they’re still in school or are new to the company. If this is the case, then that likely won’t be the only thing they’re hiding from you. Now, it’s good to have competent junior developers grow and learn through working on your project. However, this is about the honesty of the vendor that employs them—not to mention the resources you can expect to spend later on quality assurance.