“In theory, there is no difference between theory and practice. In practice, there is.” —Yogi Berra

I’ve heard a lot over the past decade about the war for talent and how to win it. It’s a common presumption that we are short of critical technical skills and that we must seek out and retain the skills we need wherever they are.

This is one of the trends that have driven the globalization of labor since the early 1990s. I’ve been a proponent of the theory for most of that time and worked hard to make it effective. I still have no problem with the theory, but the practice has turned out to be more challenging.

Global labor cost arbitrage opportunities are steadily eroding. In other words, the total cost of operation after factoring in the process costs and infrastructure investments needed to maintain productivity levels still favors offshore resources, but the gap has been narrowing over the past decade. So, it’s time to revisit some of the basic principles of human capital management in software engineering.

It’s always been the case that co-location is the best option for a software engineering team. The creative process works best when there is plenty of ad hoc sharing, casual interaction and instant issue resolution available. Co-location obviously doesn’t guarantee success (plenty of dysfunctional behaviors happen in close proximity), but it does seem to be a good place to start.

The more distributed the team gets—even with good communications, common processes, good managers and effective support infrastructure—the bigger the productivity tax that the overall development process has to pay. As long as the raw labor cost difference between dispersed locations was significant, that tax didn’t matter; you still came out way ahead overall. As cost differentials narrow, it gets harder to justify the additional overhead.

Over the years, I’ve looked at several powerful counterexamples where distributed teams matched or bettered the performance of co-located teams, but none of the examples seem to be very scalable, persistent or easily generalized. What else can we do if we don’t want, or can’t have, all our developers in one place?

One possibility is having the teams in different locations each be dedicated to a specific project or product. At first glance, this looks like a pretty good model, but it will incur some program- and portfolio-level coordination and management costs. Maintaining a uniform cultural model will be a challenge.

Another issue with distributed development is the potential for the engineers and their managers to become separated from the day-to-day concerns of the business. A kind of organizational entropy develops in dispersed organizations. Unless managers work hard to keep alignment going, the more distant parts of the engineering organization seem to lose their focus over time. This can be fixed, but it requires time and constant communication.

Hence, I’m back to preferring co-location of engineering resources, as well as of IT and the business. Inevitably, there’s the potential of missing out on some talent that cannot be co-located with others on the team. That’s another difficult trade-off—one that will be increasingly difficult to balance out over the coming decade, as the local workforce becomes less willingly mobile and more demanding of a dispersed organizational style.

All of us are going to have to get together to solve these issues, and it isn’t going to be easy.

test