In Communication we Trust

Building trust is activity that never stops. Trust arises from strong relationships, and relationships need to be built, maintained and nurtured. Management literature mentions trust often, but no one really tells you what it is and how to “get it”… and I’m not about to do that either. I rather tell you what it means for me and how it works for me in managing offshore Engineering organization.
In the center of my relationship with my peers in Ukraine is information sharing and extensive communication. Of course there is the limit of what I can possibly share, and of course I do not share all the information with everyone, but I try to be as honest as I can in the communication and share the right information with right people. Honesty is very important factor here: if I decide to share information – I’ll be honest about it, and will not fabricate a story. Otherwise I won’t share the info at all… and when I don’t, I explain why I cannot share the info or cannot share it yet. Honesty from my side breeds honesty from their side and this allows for healthy dialog to take place. All this breeds transparency in relationships and breaks communication barriers leading to successful offshore engagement.
Another technique that helps me in trust building is emphasizing the expertise of the offshore team in certain area and make it visible to both local and remote teams. Offshore team needs to see that there is transparency in work assignment, which shows that we rely on every engineer the same for work to be done regardless of physical location. Delegating process improvements analysis and proposals is yet another successful technique. When we would like to make adjustments or improvements in how we work in certain area, we won’t just come up with the process and impose it on the offshore organization. On the contrary, we would ask their opinion, and in many cases will ask them to come up with the process. Brilliant folks as they are they usually come up with ideas that after some massaging get incorporated into our daily lives. Environment that this kind of relationship creates ends up causing offshore team to identify themselves more with our company and feel really part of the same organization.

Extended Teams

Many problems related to offshore development that are reported in the industry often being explained by culture difference, lack of communication, time zones etc. From what I’ve learned, many companies reporting such problems do not have optimal team structure. Popular models include complete outsourcing of engineering team or outsourcing of one function only (QA being very popular). To “protect” from failure, these companies often build in SLAs into contracts.

Popular as these models are, the outcome of such engagements is rarely optimal for both sides, with [yes – you’ve guessed it!] poor communication framework built into these models.
Alternative model with much more chances for success is what I call “Extended teams”. In this model, offshore teams are not silos, but actual extensions of the onsite teams. The idea is that from management point of view, the only difference is – location. This allows engineering management perform planning based on skills and availability and not location. Of course if you work with Indian offshore company, this will be much.. much more difficult due to the time difference, but in our case, working with a Ukrainian company the time difference proved to be a non issue in most cases.
Good communication is built into this model, as feature teams, including members from both sides of the ocean HAVE TO communicate often and effectively to produce good results. Now here is a caveat: for several years this was working for us and proved to be successful. As our organization is moving towards Agile product development we need to decide whether this mixed mode is the best approach or should we move towards collocation, building complete teams in one location to the degree possible. Moving to collocated teams in offshore location will actually improve the team members interaction and communication, but will require more oversight by onsite architects. It becomes more complicated when we consider shared resources available onsite only, but need to be part of Agile teams.

More update on that later on my Agile Transformation blog.