Can GICs Transform For Real?

Can GICs Transform For Real?

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.

Shree Damani

Global Sales Leader | Growth Driver | Advisory Board Member | Life long learner

7 年

Awesome post Sreeram. Very insightful as always!

Srikrishnan Sundararajan

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.

要查看或添加评论,请登录

Sriram Narayan的更多文章

  • The Fog of Impact

    The Fog of Impact

    Imagine a multiplayer video game in which players compete to shoot goblins that appear in a foggy landscape. Some…

    2 条评论
  • Has Agile Killed the Business Case?

    Has Agile Killed the Business Case?

    If you are a single-product startup, you probably don’t need to write a business case for every new feature or…

    6 条评论
  • Don’t grow into Product and Engineering

    Don’t grow into Product and Engineering

    A startup usually begins life as a single-digit strong team with no boundaries. As they grow, they might soon find…

    9 条评论
  • Jugaad Product Development

    Jugaad Product Development

    Any business leader will tell you that regular product development takes too long. Setting hard deadlines rarely works.

    5 条评论
  • Guns and Deadlines

    Guns and Deadlines

    Does the practice of setting hard deadlines improve the predictability of software delivery? It depends on the team…

    4 条评论
  • How to transform the agile CoE

    How to transform the agile CoE

    Agility in innovation is a great marker of business agility. Innovation lead time for digital capabilities is the time…

    1 条评论
  • The agile CoE is about to die

    The agile CoE is about to die

    Update March 2023: Also see a follow-up post to this one here, titled "How to transform the agile CoE" Capital One, a…

    25 条评论
  • The flywheel and the slywheel

    The flywheel and the slywheel

    A flywheel multiplies value, a "slywheel" obfuscates it. If you can’t get a flywheel effect going within your…

    2 条评论
  • Visualizing Paths to Value

    Visualizing Paths to Value

    Customer obsession doesn’t always contribute to commercial success–the previous post made this point. Which means it…

    2 条评论
  • Commercial Impact Trumps Customer Obsession

    Commercial Impact Trumps Customer Obsession

    My previous post shared a way for technology leaders (Product, Data, Digital, or Engineering) to engage with commercial…

    4 条评论

社区洞察

其他会员也浏览了