Alternative strategies for acquiring talent in software development – part 1 – Introduction

Software development talent shortage is a reality most tech leaders grapple with. The Harvey Nash / KPMG CIO Survey of 2016 reports that 65% of CIOs say skills shortage is holding their projects back. 89% of CIO’s are concerned about talent retention, and nearly nine in ten IT leaders (89%) have ‘some’ or ‘great’ concern about holding onto their best staff.

In this post, I’d like to begin addressing these challenges with some pragmatic solutions. My perspective is as a software engineering manager, later a CTO, and today a consultant at TeamFound. I help software companies find developers and technology partners, and manage distributed teams.

There are a few factors that influence talent acquisition in software engineering: geography, skills needed, culture fit, cost, and your engineering team’s process methodology. Let’s focus on geography first.

Geography is the single greatest bottleneck and opportunity

Quick story: when I was a software engineering manager at a fast-growing SaaS startup in Vermont, we had planned to develop a ground-breaking mobile application. We wanted to be first to market. Time was ticking, and we couldn’t hire the right people. Our problem was obvious: we were stuck pursuing the same old talent acquisition tactics, and they simply weren’t serving us.  We needed to think differently. Our CEO was readily willing to adapt to other geographies. He just wanted to get our innovations to market fast.

My story illustrates a common situation. Businesses cannot afford to fall behind in their markets, and a shortage of skilled engineers is holding back key initiatives. This story takes place in Vermont, but you’ll find similar stories in more populated states and metropolitan areas.

Our solution was to find a second geographic location with more available talent. We  began working with a remote engineering team, essentially a second hub of developers. It’s not a new idea. Large companies have been doing it for decades. But the difference today is that it can be done very cost effectively and by much smaller companies.

At its core the strategy is simple: having at least two geographic markets offers you more options than one market, whether you are hiring or contracting talent.

Here are some quick gains we found:

  1. We didn’t have to wait 3-6 months to hire.  We were bringing on new developers within 1 to 2 months.
  2. We could match the skills we needed more easily.
  3. Our cost wasn’t impacted initially, because we weren’t willing to sacrifice on culture and skill-level. But later as we scaled the remote team, we saved significant acquisition and overhead costs.

Distributed team hybrids

I work mostly with businesses that have a centralized engineering or business team. Here are a couple of hybrid distributed structures I’ve had success with:

Two hubs

These are your central office and a remote location. Developers in the remote location sit together in physical proximity. Many managers prefer this model because it does not require a different management style. It retains a lot of the same elements of physical proximity in terms of on-boarding, communication, retention, and culture. A key point is that you don’t have to setup and manage a new office.  You can take a much simpler approach of dedicated contracted teams where a software provider offers management support, including HR activities such as hiring, retention, and training. There are a few surprising benefits to this arrangement:

  1. You’re more free to focus on developing software, rather than managing overhead.
  2. Adapts to business needs. Enables you to more easily control costs based on business demand. In other words, you can ramp-up/down the team as your project demands.
  3. Your acquisition costs are minimal because providers will either allocate developers coming off existing projects, or they have a well developed HR operation with a pre-existing pipeline of candidates.

Central hub and distributed members

You add geographically distributed members to your centralized team. They can be located anywhere. They work from home or a co-work space, or a software provider if contracted. I’ve had success with this model for teams where they have a well practiced process methodology, such as Agile Scrum, along with product management and communication tools that enable remote members to work effectively together. If your team has the flexibility today to work from home at least some of the time, then they’ve probably developed some remote skills and are therefore more likely to succeed in working with other distributed members. Nevertheless, it’s a more challenging model to manage.

In Part 2, I discuss working models for distributed teams, their practical applications, and best practices.

You’re welcome to view case studies and interviews of businesses that launched distributed software teams. If you’d like to discuss your project, feel free to reach out to me.

If you’re a technology lead and you’re looking for the nuts and bolts of distributed team management, have a look below.

Thank you to the stellar software team pictured above.

Guide for Leads of Distributed Teams