Don’t pick individual developers. Pick an entire, expert, solution-driven team

The different models to pick a software development team

The first model is what most people are familiar with: you hire a team and try to develop them over time. Hopefully, the best developers stay for years. This is the most common approach, and drives loyalty and keeps knowledge in-house. All of those are good things. The problem with hiring is that it can be time-consuming, it can be expensive, it can be risky (bad hires), and if your business models or product road maps change, you might not have the right developers on your team anymore. Let’s say most of your projects were cloud-driven for years, and you have very strong cloud developers.

Awesome. But now the executive team wants to do more with machine learning and to get the best developers for those projects, you would need to rehire. Again: it can be time-consuming, costly, and risky. You can see projects fall behind.

So hiring a full-time team is the primary model many companies use, but there are other models -- and in the past 10 years, you’ve seen a huge increase in outsourcing software development. The reason that the software development outsourcing market has been able to grow is because the model serves companies well: it’s less risky, it’s often less expensive than a series of full-time hires, and you get a wide breadth of expertise among the developers you get to work with.

But even when selecting a software development outsourcing partner, there are a few different models to consider.

Some outsourcing companies will list all their available developers and show the CV of each developer -- i.e. what projects he/she has worked on, what companies in the past, all that. You can almost pick and choose different developers by their CV. It is like a sports draft in some ways!

Our model is a little bit different. We trust all of our developers to get projects done for clients, and we trust all of our developers working as an extension of your team, regardless of each developer's experience level. We choose developers per project very carefully.

So, rather than a pick-and-choose CV model, we drive our model on expertise. We work within core industries, such as industrial manufacturing, healthcare, energy, finance, and logistics -- and we work within core tech stacks, including cloud, augmented reality, IoT, and much more.

Ultimately what you get is an extension of your team driven by expertise.

And why does expertise matter?

You should know the answer to this question already, but for some, it’s not so simple. We are changing our relationship to expertise these days because knowledge is so free and available (think Google). It creates a situation where a lot of people can claim to be experts on a topic, or legitimately make themselves experts on a topic through learning channels, such as YouTube or coding courses online. How we think about the idea of “expertise” has changed, and some companies are getting swindled in that deal -- they are ending up with full-time hires and outsourced developers who are not really experts in a given field.

Have you ever seen this meme below?

Foreign Affairs wrote an article in 2017 about the first world “losing faith in expertise,” and The New York Times has done some book reviews about “ignorance now being a virtue.”

So if we are losing faith in expertise … that’s bad. We need to double down on expertise and get people on our teams that really have it. Mark Zuckerberg, the founder of Facebook, has said repeatedly that the difference between an “A-Player Dev” (top Dev) and even a “B-Player Dev” (good but not amazing) is millions of dollars. And that’s true. Especially in highly-technical, fast-moving projects, expertise is a must.

But there is a final wrinkle

If you come across a company using the “select the CVs of the developers” model, what you are selecting for is individual expertise and background. You do not necessarily know how that developer -- the body that you selected -- will perform in the team. Most software development projects, sprints, Kanbans, and backlog management sessions are team-based. Having an A-Player Developer with Microsoft experience is awesome, but what if they cannot work on a team? Some call it “the brilliant jerk.”

So what you need is …

• Excellent individual developers
• Those same developers can work on a team together
• Those same developers can work as an extension of your team
• There is a great deal of domain expertise
• They work as a consultative model, helping propose business solutions to you -- not just fixing code

If you hit these bullet points, you hit a sweet spot. You get big money, important projects done. You beat rivals.

If you want to know more about the process of selecting outsourced software development teams, we put together a checklist to help guide your process: