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 business and technology leaders find smart, tactical methods to resource and manage R&D and technology execution.
There are a few factors that influence talent acquisition in software engineering: geography, hire or contract, skills needed, culture fit, cost, and your engineering team’s process methodology. Let’s begin with the first two:
Geography and the employee vs. contractor question
Quick story: when I was a software engineering manager at a fast-growing New England SaaS startup, 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 adopt alternative options. He just wanted to get our innovations to market fast.
My story illustrates a common situation. (1) Businesses cannot afford to fall behind in their markets, and limiting our options to local hires is holding back key initiatives. And (2) CEO’s lack the budget flexibility they need to adapt to changing markets.
Our solution was two-fold: to find a second geographic location with more available talent, and to use contracted resources. We began working with a remote engineering team in Eastern Europe, essentially a second hub of developers. It’s not a new idea. Large companies have been doing it for decades. But the difference we found is that it can be done very cost effectively and by a much smaller organization.
Contractors often get a bad rap as “temporary” workers who are not engaged enough or committed to the organization. We found this perception entirely wrong. On the contrary, the culture at our partner’s organization (and in their geography) emphasized proactive decisions, taking ownership, and quality. The developers we worked with were dedicated and highly skilled.
Here are gains we found:
- We didn’t have to wait 3-6 months to hire. We were bringing on new developers within 4 to 6 weeks.
- We could match the skills we needed more easily.
- We were also running remote independent projects where we had no internal skills, such as Android and iOS development.
And what our CEO loved:
- We could ramp-up the team and ramp-down the team based on business and project demands.
- As we scaled the remote team, we found significant cost savings
- Speed!
The hybrid team model
I work mostly with businesses that have a centralized engineering or business team. A hybrid team model refers to local hires and remote contracted engineering teams. Here are a couple of hybrid 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:
- You’re more free to focus on developing software, rather than managing overhead.
- 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.
- 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.
Team Found 