There are typically two ways to hire a dev shop: product development or staff augmentation.

Product development means that the dev shop owns end-to-end development. They will assemble a team consisting of a product manager, devs, UX/UI, QAs, DevOps, or any other role. The team scales up or down depending on needs. The product manager and probably a lead engineer will be your points of contact, as they gather the build requirements from you and then keep you posted on progress and blockers. For the most part, you will steer clear of any involvement in implementation and team dynamics.

Staff augmentation is when a dev shop assigns you one of their employees (known as a resource) to augment, i.e. expand, your team. Usually the resource is a developer, but it could be any technical role. The resource is on the dev shop’s payroll, but for all intents and purposes, you will manage them and direct traffic. Staff aug is an especially common way of using an offshore dev shop since you get the benefit of low-cost employees without the administrative overhead of hiring and HR. 

So you have two decisions to make when assessing whether to work with a dev shop.

- Do you want to use a dev shop for product development or for staff aug?

- Which dev shop should you use?

If you intend to have them build out your product, hiring them first for a feasibility assessment is a good way to gauge their capabilities. Alternatively, if you’re looking for individuals via staff aug, you want a dev shop that is good at hiring, employee retention, and customer service. In other words:

- Do they find good people?

- Do they keep good people?

- Do they care about your problems and solve them?

You might be tempted by cheap rates and just want to meet candidates who you can interview yourself, but a dev shop that’s skilled in staff aug should be greater than the sum of its parts. It should be more than just a house where a bunch of developers live. It should add value to the relationship between startup and resource, consistently upskill and engage its employees, and have a strong culture across all of its projects. How can you possibly evaluate these things before hiring them?

Rather than listening to sales tell you what you want to hear and give you vague assurances that they know what they're doing, ask these questions:

Is there a time cap on the resource’s hours?

If the dev shop is billing out 100% of the employee’s time, you have to wonder how much communication there is between the two of them.

How do employees engage with the dev shop?

If there is a time buffer between the employee’s working and billable hours, how is that time being spent at the dev shop? Is there mentoring and weekly O3s? Do the engineers ever have time to collaborate with each other on side projects?

Does the dev shop have in-person get-togethers?

Video conferencing is a modern marvel, but people need time together. Meaningful relationships aren't built strictly online.

How spread out are employees geographically?

A dev shop that hires across different countries opens up the talent pool, but can stretch itself thin in terms of cultural understanding, in-person events, and communication across time zones.

Does the dev shop specialize?

Dev shops work with multiple clients at once, so it’s  important that it finds common ground for its employees. Specializing facilitates a shared culture and language across the organization. Considering that they’re spending 90+% of their time with the client, there needs to be some cultural glue bonding employees to the dev shop and to each other.

Will the dev shop request access to your communication channels and tools (Slack, Jira, GitHub, etc)?

The dev shop should be keen on keeping tabs on the work for the sake of client satisfaction and employee engagement. You will need to work out the details, but the intent from the dev shop should be there. 

Is the dev shop willing to provide just one resource for an engagement? 

Allocating just one person to a project is riddled with potential issues. If the employee is a proven contributor and the dev shop has full trust in them, it can work. But isolation from all other dev shop employees compounds risks.

What bandwidth does the dev shop have for scaling?

Large corporate agencies generally have a bench of engineers that they can access to scale and backfill when needed. While it can be useful for clients, agencies can struggle keeping bench employees sharp, engaged, and productive unless there are interesting internal projects to work on.

We prioritize staying lean so that we can reduce our overhead and pass on those cost savings to the startups we work with. Our scaling philosophy is to stay plugged into the dev community personally and professionally so that we can build teams on demand.

Different dev shops have different approaches, but they all need to have an answer for how they scale teams.

What will the communication be between you and the dev shop?

You will be working with the dev shop’s engineer, but you should also expect account check-ins and proactive customer service.

Dev shops often fill this need with junior-level and non-technical delivery managers, account managers, or project managers. While you should want consistent communication from the dev shop, in most cases, it really isn't worth paying extra for this support. Account management for staff aug becomes valuable at scale (at least 10+ resources per engagement).

Our approach is to stay close to the ground action, keep our engineering leads engaged, and do constant training on customer service. Rather than adding layers of account middlemen, I check in with our clients directly.

Will the dev shop share examples of their technical tests?

Every dev shop will have candidates go through a technical screening (take home project, live coding session, online whiteboarding, etc). These tests aren’t a secret and they’re generally not proprietary, so a dev shop shouldn’t hesitate to show you what theirs consist of. Whether they're pulling from LeetCode or another source, the tests should have an appropriate degree of complexity. We’re big fans of progressive assessments which involve structuring tests that build in complexity incrementally. For example: 

- Assign a take-home project

- After submission and review, meet and challenge the candidate to explain the rationale for architectural decisions, code patterns, etc.

- Do an online coding session for the candidate to build something on top of their take-home project. 

Will the dev shop share examples of the engineer’s work?

Just as the dev shop should have no issue sharing samples of their tests, they should be willing to share examples of their engineer’s past work. If the engineer has been working on another client’s project, then they won’t show you the engineer’s commits without getting consent. So what can they show?

- Open-source contributions

- Internal projects

- Interview test solutions

Usually just asking a few of these questions will be enough to identify which dev shops will bring more value to the table. Find a dev shop that will be involved and committed to both you and the employee. Everyone will be better off for it.