Archive for October 5, 2010

Building a world class global team 101: start building a culture based on mutual dependence

October 5, 2010 2 comments

This particular scenario happens very frequently.

The software company and its software product portfolio enter a new period of significant growth.  The software products are now sold and used by customers in multiple countries.

One software engineering team based in one country – usually where the product was originally developed and launched – is increasingly unable to maintain product development velocity, especially when product requirements are influenced by unique requirements in other countries.  It’s simply not possible to have the same team operate 24 hours a day.

It’s time to implement a global software engineering strategy:  additional teams based in other countries, working together, using time zones as a strategic advantage.

Companies which have multiple software engineering organizations in several countries are nothing new.  However, they all share one common attribute.  Before a global software engineering strategy led to a measurable improvement in product development velocity, during the early stage of implementing this strategy things actually got worse – not better.

This blog entry is about a practical and proven approach to skip “it’s worse than previously thought” and go directly to “one product, one team, working together – and faster”.

Please consider these steps.

First – perform a clinical review of how the software product is designed and built.

–          Look for opportunities to componentize the software engineering process

Then – create a culture of mutual dependence.

–          Intentionally assign ownership of components which depend on each other to different teams

–          This creates a culture where one team cannot succeed working largely alone.  If one team creates an API and another team consumes it, both teams cannot declare victory all major requirements are met, including ensuring that API cam meet certain scalability and performance targets.  Scalability testing could be done by yet another team in another country.

–          Collaboration by design compels all teams to work together while being driven by the same shared agenda

–          Do not co-locate QA engineering resources with the same team (as tempting as it might be due to convenience).  When QA engineers and software design engineers in test are based in different locations, it takes extra effort for functional knowledge to flow to QA engineers and test feedback to flow in reverse to software engineers.  Yet in this instance distance plays a very beneficial role.  Both software engineers and QA engineers must find and implement the right process to ensure that distance does not present itself as a barrier to success.  Again – collaboration by design …

Finally – implement a build process which supports the culture of mutual dependence

–          To illustrate:  if one team creates an API consumed by others, create a build process which first generates API component and then triggers integration of this component by separate build processes owned by teams which rely on this component.

–          Build failures will immediately trigger collaborative discussions between all teams.   The root cause is not as important as the collaborative process to find the root cause, perform lessons learned, and quickly implement  changes and if needed sustainable improvements.

One of the biggest benefits of implementing a culture of mutual dependence in a global software engineering organization is how quickly one could witness and correct weak links.

The culture of mutual dependence compels every manager – in addition to performing their duties – to become an interested party in the success of every other manager that owns a component or components that everyone relies on.

Those who cannot collaborate and put the needs of the customer and the product above all other considerations will be easily recognized and replaced.