The Engineering VP’s 4-Step Guide To Hiring New Subcontractors

The occasional work overloads are not uncommon, especially not to software development teams. If you’ve ever found your team stuck in such piles of work, subcontracting can be a good solution. Businesses have forever used subcontracting to take care of parts (often important) of their larger projects.

While the benefits of subcontracting are undeniable, the process of choosing the right subcontractors is not so straightforward. In this guide, I’ll walk you through a process that guarantees great hires and helps maximize your productivity.

Why It’s a Bad Idea to Tie-up With a Single Subcontractor

It’s very risky to have only one subcontractor because it means that you’re totally dependent on them. If you have just a single subcontractor on your team, you could run into several problems:

  • Insufficient bandwidth: It could be that you need something done really quickly, but your only subcontractor might not be able to accommodate it due to his or her current workload.
  • Price hike: Perhaps your subcontractor could hike his or her service charges, and then depending upon the severity of your need, you might be forced to shell out extra money. The situation could get worse if the new expense disturbs your entire budget.
  • Contract termination: Maybe your subcontractor decides to end the business relationship. Now this one could cause a really big damage to your operations. While you were looking to get some work done, you’ll now have to look for and hire a new subcontractor in the middle of your project. At this point, you could decide to do the work in-house, but this won't be possible without impacting your project’s timeline.

While it’s difficult to foresee such situations, the risks are real. If you don't prepare for it, your projects could suffer in case these risks will materialize. But this problem has a solution: and it’s to keep a backup, i.e., to work with multiple subcontractors. Having several subcontractors onboard minimizes the impact of such situations.

Now that the risks and a potential solution are clear, let's look at a way to choose a new subcontractor as risk-free as possible. With so many incompetent software development companies out there, you have to take hiring seriously.

Remember: a bad hire could sabotage your project.

The Need for a Balanced Evaluation System for New Hires

The answer to making the right hiring decisions lies in developing a balanced evaluation system.

I strongly believe that decisions must be based on facts, though I have found that making factual decisions is surprisingly hard. This natural inclination to base decisions upon how we feel about certain things makes it even more necessary that we develop a system that helps reduce the effect that human factors have on our hiring decisions.

Another important concern that an objective evaluation system handles is: it takes less time for our employees to evaluate subcontractors as most questions can be answered in a yes or a no. This avoids the need of pointless meetings where people argue about evaluation criteria that aren't measurable or are too subjective.

It’s crucial that our employees participate in the evaluation process, but with an objective evaluation system, it’s easier to involve them without disturbing the balance of their existing projects.

4 Easy Steps to Hire the Best Subcontractor

Here's a breakdown of the basic steps that you should take to hire the right subcontractor for your job. Now this process applies to businesses across all domains, but depending upon your specific industry, you could fine tune it to get even better results for you.

1. Start with a Small Project

While evaluating a new subcontractor, it’s best to either use a small project or a noncritical part of a big project.

  • Using a small project is less risky. If the subcontractor fails to deliver, you’ll only lose a small amount of time and money, and you can simply pass this work on to one of your regular subcontractors, or repeat the process to find another new and suitable subcontractor, or decide not to do it at all.
  • If the test project is small, it’s easier and faster to evaluate the performance of the subcontractor. This is a huge benefit because you can easily find people in your team who could participate in the subcontractor evaluation process without causing a loss to their work.

The project should be small in terms of the work volume, but should not be too small. The idea is that it should be just enough to enable you to evaluate the quality of the new subcontractor.

2. Decide the Evaluation Criteria Before the Project Starts

Your aim is to perform an objective evaluation. The best way to do this is to decide the evaluation criteria before a project starts. When you set your expectations at the very onset of a project, you are free of any bias. You’re only deciding what you want out of the project, and you’re not looking at the capabilities of the subcontractor or his / her team.

Good evaluation criteria are measurable: so pick criteria that will result in objective answers. Ideally, at the end of the project the subcontractor should either pass or fail. This way, you won't end up settling for a service provider who doesn't meet your expectations.

To give you a head start, here are some examples of a few good evaluation criteria:

  • We must not find more than X bugs during the Y weeks after the release.
  • We must not make more than X change requests during the Y weeks after the release.
  • Was the project delivered on time?
  • Did the subcontractor stay on budget?
  • Did the subcontractor implement all the required features?
  • Does the delivered software fulfill its performance requirements?
  • The subcontractor must suggest at least X new features or changes to existing features.

Some examples of bad evaluation criteria are:

  • Was the quality of workmanship high?
  • Was it easy to work with the subcontractor?
  • Did the subcontractor provide good documentation?

If you look at the second set of examples, you’ll see that they are all based upon personal standards. They are not quantifiable and won't result in objective answers – that’s why they need to be avoided.

After specifying the evaluation criteria, the next step is to prioritize them. The idea here is to divide the evaluation criteria into two groups:

  • Must pass. If a subcontractor doesn’t pass all the must-pass evaluation criteria, he or she isn’t qualified.
  • Nice to pass. If a subcontractor passes the nice to pass evaluation criteria, he or she earns some brownie points that are taken into account during the evaluation phase in case of multiple eligible candidates.

One more thing: It’s not a good idea to share the evaluation criteria with the evaluated subcontractors. Think of the evaluation system as a strategy that you’d like to keep to yourself.

3. Communicate the Goals of the Project to the Subcontractor

Not all projects are created equal. Some projects will be only relevant for a short period of time, some are not important at the moment, but might be important later on, and some are crucial to your company’s success.

Each project dictates a different approach based on its goals. It might be a perfectly good approach to write the code as fast as possible if the lifespan of the delivered software component is very short. On the other hand, if we have long term plans for the project, a subcontractor must take a totally different approach.

Because we want to see if the subcontractor under consideration will select the right approach for a project, we must communicate the project's goals very clearly. Otherwise, we won’t be able to evaluate if the subcontractor is capable of choosing the right tradeoffs.

4. Evaluate and Provide Feedback

When the project is over, it’s time to compare the subcontractor’s performance against the pre-defined evaluation criteria.  Hopefully, if the evaluation criteria were defined correctly, you’ll be sure of making the right decision in the end.

You should communicate their 'score’ to your subcontractors, and whether or not they made the final cut. If you will continue to work with them, they should know where they fall short. If they failed, it’s still your responsibility to communicate your decision and its reasoning and explain how you believe they could improve their processes and quality of work.

My personal experience is that helping others (even if it's just by sharing honest feedback) earns friends and relationships while building goodwill. With this approach, you can make the rejections still seem like a win to the subcontractors — a win that allows them the chance to plug some shortcomings in their services.

Can We Really Be Objective?

I doubt it.

I think that it’s impossible to totally eliminate the human factor from the equation, but if we try to base our decisions on facts instead of fluffy feelings, we will be less likely to take the wrong call because facts don’t lie. And when the stakes are high, avoiding the wrong decision is very very important.


About the author: Petri Kainulainen is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book. He also shares is thoughts regularly on his blog.