Can GICs Transform For Real?
Sriram Narayan
Impact Intelligence | Product/Digital/Tech Performance | Author: Agile Org Design (Pearson)
The Global In-house Center (GIC) phenomenon began on the basis of labor arbitrage and grew on the back of talent quality and availability, primarily in India and China but also in Romania, Philippines and Ireland. On the other hand, the business environment has changed significantly since the time these GICs were conceived at parent headquarters.
Winds Of Change
The last ten years has been about big business waking up to the reality of software eating the world via tech platforms, powerful algorithms and mobile apps that eliminate friction in everyday transactions and put buyers in charge relative to sellers, if not to the platforms.
Only a few old-guard businesses have realized that irrespective of the industry they are in, they now need to learn new ways of working from leading tech companies if they are to retain and grow market share.
These “early followers” have re-organized to integrate strategic parts of their tech organization closely with the business. They have reviewed what they outsource and even in-sourced product development in key areas. They have moved away, at least partly, from big upfront plans to a culture of continuous experimentation, iteration and learning.
GICs haven’t participated enough in this sort of change although they have evolved in their own way. The scale of GIC operations has multiplied and their functions have grown to include innovation and data analytics centers. Some innovation centers focus on developing proof-of-concept solutions while others focus on building IP through patents. Do their efforts regularly make a difference to parent business outcomes? That is still a journey.
Stuck In Delivery
Most single and multi-function GICs build and operate software for their parent businesses. They do it as part of market-facing product & platform development efforts, digitization programs, or internal application development & support. However, the role of a GIC is still mostly restricted to delivery of a solution conceived close to global north markets. Earlier stages of the value stream such as problem selection, problem analysis, business case development and solution definition are still mostly performed in the parent organization and handed over to the GIC for efficient and reliable delivery after perhaps a two-day hothouse.
Such a downstream-only role for a GIC is somewhat understandable given their distance—geographic, cultural, and contextual—from the markets. However, this sort of big-batch, non-iterative progression through the development value stream regularly misses the mark in terms of business benefits realized and jeopardizes business results. Considering the vital role of software for business success in the digital age, there is significant opportunity to increase GICs’ span of responsibility with respect to software development.
On the other hand, some stakeholders in parent organizations would argue that GICs’ need to get better at solution delivery before aiming for greater participation or responsibility. The argument isn’t without merit. Even in 2017, software development in GICs is largely supervised by old-school managers and so-called Scrum masters who coerce developers into committing to estimates based on woefully inadequate information and then micromanage teams into meeting those estimates. Considerations of building the right thing and building the thing right take a backseat in the process. In these setups, the number of people who track value is usually disproportionate to the number of people who add value—quite a contrast to the digital-savvy operating models powering the best organizations today.
What Digital Success Demands
In response to feedback from business and diktats from above, several GICs have embarked on large-scale Agile and DevOps adoption programs. They have had limited impact because changes on the ground have been somewhat cosmetic. For example, delivery dashboards report fantastic test coverage but it turns out to be meaningless on closer inspection because the tests have no assertions. DevOps really requires a merger of the change and run organizations into a single hierarchy. Leadership roles such as VP-Development and VP-Operations come under review. This is hard as compared to adopting DevOpsy tools for application release automation which is what ends up passing for DevOps in many places.
Organizations that flourish in the digital economy will be the ones that learn to operate differently. They will be able to exploit short-lived opportunities by adopting an operating model geared for responsiveness over cost-efficiency. Although all organizations will face the pressure to make the transition, only some will succeed. Among other things, it will require a blurring of organizational boundaries between business, digital, product, and IT. It will also require a change in management and governance culture. Therefore, it is going to need leadership by courageous executives to sponsor the kind of invasive surgery required to become a fighting fit GIC adapted to the digital-age.
How do courageous executives lead a transformation? They don't merely provide executive sponsorship from the top floor. They step in to provide courage and direction for difficult decisions. Unless they provide active support, their deputies will seek out non-existent, proven approaches in the form industry-peer case-studies for everything that feels like a change. Who wants to take risks if the boss isn't standing shoulder to shoulder? That's why many so-called transformations are mostly a re-branding of old ways of thinking and working. In the absence of real change, fatigue sets in among the troops as each new wave of not-so-courageous executives, lacking stomach for invasive surgery, sponsor yet another ceremonial transformation.
“Invasive surgery” is used as alternative to the overused term “transformation” in the expectation that it provides a striking metaphor for changes such as: governing for value over predictability, redrawing organizational boundaries to avoid silos inside critical value streams, designing non-counterproductive KPIs, and moving away from project-based funding and execution.
Can GICs find stomach for a real caterpillar-to-butterfly transformation? They better do or they risk jeopardizing the prospects of their parent organizations.
Global Sales Leader | Growth Driver | Advisory Board Member | Life long learner
7 年Awesome post Sreeram. Very insightful as always!
AI, Blockchain, Cloud, Digital Transformation - Practitioner, Trusted Customer Success Advisor, Pre Sales Engineering Leader; KPMG Partner , Tech Transformation Business Consulting ; ex - AWS / Amazon , IBM
7 年Good set of observations. I especially liked the one on DevOps. Many organizations are still running siloed Dev and Ops organizations which limit agility and the ability to compete against their competition in their industry and outside.