I recently had the opportunity to work with a client who is taking on a massive re-platform of a cyber-physical system. The “cyber” part being a cloud hosted IoT platform built on top of Microsoft Azure (and all of its goodies) and the “physical” part being security and monitoring devices. The team is a global one, with part of the team in Europe and another part in India.

The team in India is largely composed of software developers, testers and the like. They know the software side. The team in Europe is largely composed of hardware engineers, firmware developers and the like. You might be saying to yourself, ‘they are already grouped into silos’! Yes, they are. Consciously so and accepting the risk that organizing in this manner brings on.

The way organizations cultivate human capital is unfortunately in silos and for global organizations, those silos are usually geographically disbursed. Why does this happen? It’s pretty natural actually. When you have a strong and charismatic thought leader, that tends to rub off on people they work with regularly. People like this tend to become a lightening rod that electrifies all around them and usually results in a team or even a capability group developing. The people they work with regularly, typically, live and work in the same city (or at least part of the world). These natural fault lines of human capital are one way that silos are formed within organizations. This is how organizations cultivate the deep skills needed to differentiate their products and offerings within the marketplace.

This is okay. Yes, I know we’re supposed to develop ‘T’ shaped people to avoid creating silos but for every ‘T’-shaped person there was an ‘I’-shaped person in the beginning right? In fact, most organizations have developed human capital in this way. So for most organizations, having islands of geo-distributed ‘I’-shaped people is a reality and it won’t change overnight. It’s the starting point. Acknowledging the naturally forming silos in your organization is the first step towards doing something about it.

We know that ideally we would organize teams around value. Be it a feature or some reusable component. We know that owning the entire vertical slice of something drives ownership and reduces the soul crushing dependencies that normally form between teams. We know this to be good. So how do you move an organization towards something that requires teams of ‘T’-shaped people that can own the entire stack? Baby steps.

The first step my customer took was to organize the team given their current reality. The reality is, all of their software people are in India and all of their hardware/firmware people are in Europe. Unless we can get half of the folks in Europe to move to India and vice versa, we have to play the hand we’ve been dealt. In this state you have to actively manage this boundary between the silos. The benefit of taking a scaled agile approach is that you have an intense orientation towards synchronization between teams and between trains.

Over time, the organization can make investments to develop local talent where there are skills gaps. More hardware/firmware people in India. More software people in Europe. This could be hiring new people or could mean morphing existing people into the new roles (this depends a lot on the appetite of the workforce to reskill). This transition is a slow one but with the focus on alignment and synchronization between teams we will start to see transition happen with the existing teams. We will see software people in India more knowledgeable about the work of hardware / firmware people from Europe and vice versa. This can only happen by creating one team that plans together, executes together and delivers together. The alternative is a game of hot potato.