The Sun Never Sets on Software Development

Heads-up. If I am interviewing you for an L7 product management position at Google, I will probably ask how you would propose splitting a team across several different geographies1. It is a more complex problem than it seems at first glance and requires a good understanding of how to break a service into components and understand how the components interact. It requires an understanding of team dynamics, local expertise, and more.

Global software development is a challenge most of us face these days, and it dramatically impacts how we approach product development. It wasn't always this way. Not too long ago, it was the norm only to develop products at the corporate headquarters. Over time, this changed. At first, it was conceived of as a way to save some money. San Francisco is not a cheap place to live – and American tech workers can cost more than three times engineers in developing markets. Like other industries, tech looked at ways to shift manufacturing overseas.?

In the early days, we outsourced "coding," not "engineering." My first experience with this was almost two decades ago when developing the System Center Configuration Manager UI. We spun up a team of mostly contract developers in Shanghai to port our UI to .NET. Engineers designed the backend and UI framework in Redmond, and the developers in Shanghai did the (mostly formulaic) work of coding things up. Even the management chain was shipped in from Redmond as leaders were asked to rotate into the country for tours of duty (internally called the Marco Polo program).

At the time, I was a developer on the OS Deployment feature. During the day, I would work on the API and UX design and pass things off to Shanghai at night to code the UI. It was efficient – but you can imagine how frustrating it would be for my counterpart in China to have so little autonomy. He was (and is) an amazing engineer with a master's degree in engineering, and he was stuck doing menial work2. Over time, the remote team matured and (rightfully) demanded more meaningful work. More significant end-to-end features (like ConfigMgr Intel AMT support) started being fully developed in Shanghai. The office was viewed as a team of equals – every bit as capable as the engineering teams in Redmond.?

So, these days, while cost is still a factor3, I don't believe it is the only driver anymore. The USA hasn't been graduating enough computer science engineers to fill the demand, H1-B visas are hard to come by, and many engineers don't want to leave their home country. Global development centers are a great way to attract the best talent from around the world. But this presents significant challenges for tech leaders trying to figure out how to distribute large tech projects across regions. In the early stages of a project, we need to dissect the problem and attempt to predict the coupling and cohesion in the design.?

In software engineering, we define coupling as the degree of interdependence between components. Components with complex interactions and shared state are said to be highly coupled, while components that can operate through clearly defined layered interfaces are loosely coupled. As a tech leader, the last thing you want to do is place two bidirectional, highly coupled components in different global development centers with only an hour of overlap in working hours – it just won't work?!

Cohesion defines the degree to which the parts of a component 'belong' together. A shared library with a bunch of arbitrary utility functions (every project has one of these) has low cohesion. In contrast, the Java Math library has high cohesion (since all the parts are related). Cohesiveness within teams is critical. It drives team identity and has a multiplicative effect on productivity (when you work on the same thing as the person next to you in the office – you help each other out, and your output together is more than either of you working separately).??

Coupling and cohesion must be balanced when spitting a project across global development centers. You can't just cleave off components that have low coupling with the rest of the system but are not cohesive (e.g., a team owning the logging system, a slice of the UI, and data export will probably not fly). Nor should you separate cohesive components that are highly coupled (if you can't explain how the components interact in a few sentences and a few simple UML diagrams, you are signing your teams up for a ton of off-hour work or travel). Getting this right is more art than science and where experience helps.

And getting coupling and cohesion right is just the first step. You must also consider specialized skills, career/growth aspirations, experience, availability, and more. Developing software across a global team is hard, and there is not necessarily a perfect solution. So, if I am ever interviewing you and ask this question – give it some thought (and for heaven's sake, don't just immediately answer that you would develop the UI remotely and backend in the US)!?

Be Happy!

Like this post? Please consider sharing, checking out my other articles, and subscribing to my weekly Flegg’s Follies newsletter for more articles on software engineering and careers in tech.

Footnotes:

1. Yes, I said interviewing PMs. At Google, PM candidates need at least one 'technical' interview – which focuses on their ability to interact with engineering. For some reason, I seem to be interviewing more L7 PMs than L7 SWEs.
2. Menial is not actually the right word here. Steven designed and developed the whole Task Sequence editor – which is still being used by tens of thousands of customers today.
3. I downplayed the cost of labour as a reason for remote engineering offices, but it is not fair to dismiss it outright. Directors and VPs at large tech companies are often "strongly encouraged" to carefully managed the average cost per engineer on their team. Often, the easiest way to accomplish this is to prioritize expanding teams in markets with significantly lower labour costs.
4. I guarantee some developers on my current team are reading this right now and are thinking I got the coupling and cohesion all wrong. They may be right -- but I guess time will tell.

Please note that the opinions stated here are my own, not those of my company.