The Secret Sauce of Successful Digital Transformation
Suvro Upadhyaya
Senior Technology Leader - Capturing customer's imagination by building Customer Focussed, empowered one-team to create & implement tech strategy.
According to 2021 study by the McKinsey consulting company, 69% of digital transformation fail. So, what is the secret sauce of success for the rest of 21%. Any new technology e.g. blockchain / AI that promises to revolutionise the way we do things brings in its fold digital transformation challenges. I firmly believe, to reap exponential benefits, one need to concentrate on what it takes to succeed. This article talks about my experience of leading successful digital transformation in three different organisations. The article is going to delve into the following:
While the emphasis here is on digital transformation, as change is massive and different aspects comes into play in more magnified way. I think different aspects are really the same while leading any product / SAAS engineering functions.
Why Digital Transformation:
Reflecting back, what prompted digital transformation, what was the need of it. Ask any software engineer / operational engineers true to their salt, in any complex running product / services, big changes has big chances that things will go wrong. If it is a mission critical system, it is like doing open heart surgery on an athlete while the athlete is running. So, why change ?. After all things have been working for so long. Let me tell you, in the world of software engineering, boring predictable, working reliably, is “cool”. There is nothing “cool” about digital transformation unless you can articulate “why”.
Few things that I have experienced, there can be many. The need may come because -
Any of the above needs needs to be weighed against the cost of change as well as risk to operations, reaping benefits by managing resistances. Having said that decisions are not necessarily based out of the facts. Many factors eg. Cultural aspects, how the management is rewarded plays into decision making. eg. Cultural aspects of long and short term orientation of the decision maker also comes into play and it plays on what view one takes to manage the future risks vs. Benefits that we are going to get now. We see that in different spheres in the business. eg. In eastern culture like Japan, long term orientation takes precedence, so more importance may be placed on managing risks (that can have potential future issues) over for example lesser revenue this year. It affects self too and we all have the bias and react to different biases in positive / negative way depending on our alignment to “our truth”.
Building blocks that is required for digital transformation:
Why some digital transformation succeed and some digital transformation fail. Reflecting back, I had been a bull in a china shop very early in my career and subsequently, had the pleasure of leading XL sized digital transformations (100+ multi-disciplinary and faceted) in three different organisation with varied domains, e-commerce, telecom and insurance. In my opinion, successful digital transformation happens when several aspects from people, culture as well as technology aspects, process aspects, operational aspects are baked in together. And just like baking a cake, you cannot bake a cake too fast or too slow, it requires planning, correct ingredients, processes and good baking. One needs to have a balanced perspective across all aspects. Constraints of cost and time of doing transformation does play a part. So, efficiency of doing it right helps. This is a good Segway to think about how organisation achieve efficiency and in which aspects.
Let me be provocative - digital transformation is really about people and not so much about technology
What is our Purpose & Internalising the purpose in the team.
If you ask a business leader, what does success looks like, it would mean fastest, highly scalable, customer experience surpassing everything in the world, ROI that is green at launch, most secure, can bounce back irrespective of failure and at a very low cost. Truth of the matter is that one cannot satisfy everything. It is at a cost of different goals. A thorough understanding is needed before you launch and be very prepared for every scenarios, howsoever you think it is remote. E.g. In eBay, we were developing AI driven IVR workflows to partly self-service customer calls. As technical initiative, we were managing resistances as it would potentially displace the need to service the calls and we really needed help in identifying the usecases that the same group of people has deep knowledge on. We also put huge focus on having great UX during Interactive voice response (IVR) development. We did succeed hugely on that front. We should have been happy right!!.. The response was so overwhelming that we did not had money to cater for increased traffic resulting from the fact that customers felt we are engaging through our channel. Although, many of the puritan product managers may be squeemish, but we had to stop customer experience improvements and concentrate on automation. We had to delay the launch as we could not budget for increased customer calls due to increased NPS score. Scenario planning, having a good agreed criteria between all stakeholders (customers, organisation, people implementing it) of what would success looks like is a must. I think it is a must for any project. One such example may be -
In British Telecom on the other hand, when we were trying to automate to reduce cost of operations both for us and our partners for a greenfield project, cost of the project was running very high. So, in parts we decided to reduce the automation and achieve the goals of project, to be taken up later once volumes demands it.
There is a need to have a balanced approach and common view (of both the organisation and important stakeholders) of what success means as that will inform technical strategy to solve for business needs. Usually, what I have seen is that lot less importance is placed on having this discussion early on or even if you are in agile mode, on continuous basis. Lot less discussion is on calling out the elephant in the room ie.. personal / cultural bias with which we see the change, our short term / long term approaches, calling out organisational norms that may have got so cemented that we may be harming ourselves. Worse still, this step is stepped over and assumed purpose becomes the purpose without debate. This definitely has impacts and no wonder after spending large amount of money, we are left wondering why digital transformation did not succeed.
Blockchain is a paradigm shift and it is a bleeding edge technology. Effective use of technology in solving real problem is must. We must ask "So What". e.g. Building an app to pay for a coffee using CBDC when existing mechanism exists and the problem has been solved very efficiently, may be a futile exercise, though possible. Allowing people to debate, form thoughts in a safe way is must. Also, there is a huge need to understand customer’s, organisational and important stakeholders perspective to understand what we need to solve that will delight all the stakeholders. Some perspectives, there will be synergies and everyone will overwhelmingly agree. Some perspectives may be at odds. Some perspectives may just be fear of change that may be unfounded. For example, when computers were introduced in Banks of India, when I was growing up, I still remember, there were nation wide strikes. Now, it is not only mainstream but it is handling volumes that could not have been possible if computers were not introduced. I saw the same in eBay. There were fears that automation will replace jobs, getting the required usecases were hard. It took substantial efforts to build the relationships, gain trust, endless efforts on actually listening through the calls as teammates handled the calls to get the required usecases that were effective. The fact of the matter is that once the inefficiencies and customer friction points were removed, the total volume of calls actually increased rather than decreased because the customers who thought “I could not be bothered with such a bad customer experience”, started engaging and brought their business to eBay. Exchanging perspectives in open and honest way, addressing the success criteria that keeps stakeholders interest in mind helps a lot.
Internalising the purpose while building Empowering Culture
On the other hand, different team members depending on experience levels / motivation, internalize goals differently. An engineering manager with business focus may say that the above business goals is our objective. However, an engineer/technical architect listening to the same objectives, he/she may be thinking about good modular architecture / use of microservices approach and ability to learn new techniques, great automation end to end as the desired objective. Congruency of overall objectives vs. Personal goals/ internalized objectives are must. Continuous dialogues are a must. If you are building a culture where teams are going to internalize the objectives as their own, it takes time for the ownership to build. Some conflicts are expected. On the other hand, if there is an emergency going on, you may say – “This is the direction, follow me”. It can be a very valid way for short term gain, but in long run, it is hardly sustainable.
Change Resistance and the need to carry the stakeholders along the journey.
While doing so, we need to carry the team and the stakeholders in the journey. This takes time. Any big change has inherent risk, it also introduces change the team, organisation, business dynamics and even how the customer’s customer may see the change. If not anything, just fear of change will make the project not fly. History is strewn with failures because of the same. Some literatures https://www.mdpi.com/2071-1050/12/21/8882 point to the same. Blockchain absolutely makes sense for insurance, trade finance, digital currency. However, with the new technology, it is a big change, we need to explore what is in it for them.. not only the customer who pays the bill but the ecosystem itself who sustains it. Unless, we address / communicate the value, we will continue to have organisation that does not go beyond POC / go bankrupt. It becomes very interesting when we see the some customers of the supplier may be thriving with the software provided and yet some are not able to manage the resistance.
Building Mutual Respect and Trust
When you go and play football / even if you are not a player, if you watch a game, you will see human relationship at play. A good team is one where everyone is committed towards a goal. Imagine this, your team is if you have received the ball, you either believe that you are best positioned to use the opportunity or you pass the same to your team mate who are best placed to bring the next opportunity. When you do the later, you are placing trust on that person. Imagine that the person fails to convert, the best way to destroy the teamwork is to start blaming. As a team, you need to win, not gloat over the mistakes. Trust is a journey. In the mind of the team, there is no doubt on objective / ability of the team to achieve it. Any small iota of doubt should not be there. Does it mean that the team is perfect, far from it. While building strategy, practising, playing team’s skills are at play, people come together to make best use of it, give tips, upskill, rearrange, reinvent. It is part of the discourse, disagreements, agreements, negotiation that the team becomes a team. A big part of the same is to have mutual respect and trust between team members and within cross-functional team members. The discourse will evolve / devolve depending on the same.
Strength of Character – Grit
Believe me, irrespective of how meticulous you plan, not everything will go according to plan. While doing a big program in British Telecom, my manager, CTO, BT Ireland, was chuckling, we are role models of players in Japanese obstacles game, the one where very difficult obstacles are placed and very suddenly more difficult obstacles come up out of nowhere. It is where having a cool mind, plans in place and keep the team inspired, work with them, have the empathy while not to leave the point of concentration go out of mind.
Some aspects of engineering is so inter-twined with people aspects eg. Collaboration that I will address it as part of engineering.
Ofcourse – Digital Transformation is also about technology and processes
领英推荐
Be the customer – Building Customer Experience that the customers will love
One of the very good practices that I have heard from Amazon is that in every meeting there is an empty chair that represent the customer. One can ofcourse have that empty chair in all the meetings, while talking about the requirements, designing, testing etc. Empty chair does not speak, it needs your voice and a strong one.
We need to foster culture where the understanding of the customer segment is understood. For example, if our customer (B2B / B2C) is one that does not have much IT capability but requires to interact with the product / service, it is but natural that user experience through web front end / voice is what is required. In doing so, make it easy. Intuitive user experience, measurable through metrics would make it easy not only to engage the customer but also make sure that the customers are achieving their objectives. To make it successful, understanding profiles of the customers (age/education/culture etc.) who are going to use, in-screen self-help/tips makes it intuitive.
If on the other hand, if our customer is very IT savvy and it requires integration, API driven approach is very much required. If we need to combine both segment ofcourse, website on top of API is must. Many a times, we might not have thought about it and therefore adoption becomes a problem.
One of the beautiful methods we used in IVR development in eBay was “wizard of oz” testing. We interviewed actual customers while we simulated applications before 1 single line of code was written. The feedbacks that we received was invaluable in achieving adoption.
From culture perspective, we need to inculcate a culture where strong opinions are heard, debated in safe way.
Future Proof Architecture but do not boil ocean, what culture should we have as an organisation
Architecture to be built should be ofcourse to answer, what we are going to solve for. However, it is not enough. We should be build something that we can adapt for future requirements. Such requirements should be compelling, while making sure that we keep within reasonable budget. Architecture is like building roads for a city. If you build just the roads, houses will build around it and it will be very difficult/costly to expand the road width. It will be easier if roads may have some extra grounds to have some expansion potential depending on population and buying potential increases.
One of the biggest mistake that we can do is to try to to be pristine and try to be super-adaptable for any scenario in the world or conversely just do what we need to do and deal with the impacts later will also lead to digging holes that is very difficult to get out of. Boiling ocean early means much money has been burnt with no ROI in immediate future. On the other hand, high technical debts, non-adaptable design is a sure-shot way to burn hands. Judgement call is required to do just enough with ability to expand for later. This requires planning, debating, carrying teams along. Also, it requires cross-collaborating with finance, marketing, product management on to do compromises, understanding each other’s perspectives. “My way or high way” by any of the core internal stakeholders will lead to sub-optimal solutions. Therefore, from culture perspective, it is a must that we engage in dialogues, debates, negotiate a way forward.
Innovate
This is an area that generates most benefit if done properly. The question however is what to innovate or which area to innovate, how would the engineering team know that it needs innovation there. One of the saying of Jeff Bezos that I always think about is – “If you do not listen to the customers, you will fail and if you only listen to the customers, you will still fail”. As a leader, you will be limiting yourself severely, if you are the only one that does the thinking. Further, there is a gap in skillset. Marketing, product management knows what is the opportunity area that needs to be solved by customer interviews/comparing with the competitors. If you are dealing with SAAS product, opportunity areas where you can have more efficiencies, can only be discovered when you work with business and tech operational folks who deal with the software daily. All these folks may come to you with opportunity areas to solve for and many a times, solution suggestions. From engineering perspective, it is important to listen but resist the temptation to solve through the solution as suggested. It may be absolutely right suggestion to go from Dublin to London by taking a British airways flight, however from engineering perspective, it is important to figure out if we want to take the suggestion or may be Ferry along with car / luxury liner is the best approach.
The reason is that every team has their blinds on. What we do not know limits the solution. So, it is very important to foster a culture where we are having constant dialogues on the opportunity areas to solve for but also technical advents that are happening. Inviting different cross-functional teams to talk to the engineering folks, sometimes attending different conferences where technology leaders talk about how different technology can be used helps to unlock. Importantly, the ownership and pride of the engineering team helps to unleash the required spark. This does require some space for the engineering team to think. “Always Emergency” is a sure sign that will kill any chance of innovation happening.
Design for Failure, Serviceability and Metrics driven Operational Excellence -
From technical perspective, things do not end by just serving the functional specifications that we need to solve for. Ofcourse, solving for non-functional aspects eg. Customer experience, security, data privacy, GDPR, Performance, reliability, failovers, scalability are a must.
In my opinion, one of the engineering principles that gets overlooked most is – How would you know if the error/incident (including security) has happened and if it has happened, do you have enough metrics / tooling available to know it. You may think that in case of SAAS, things are easier as you have control on the access of the operational environment. However, if you are not measuring a metrics, you do not know and you are flying blind. In case of product that is getting deployed in production, you do not even have the luxury to know. When things bomb, it will be so difficult to figure out circumstances when / how it bombs. More than half of the journey of bug resolution is to find out circumstances in which software was behaving crazy. These aspects, engineering needs to drive as part of requirement and is typically not part of product management functions. What metrics should we measure and what kind of logs etc. should we log. If we are not carefully designing that, it is very difficult to be proactive. Ofcourse, we need to be thinking
Budgets are never enough, software is like a iceberg. 2/3rd of the software is what you do not see / feel but are necessary part of the software. So, a balanced approach, debating to exchange perspectives are a must, prioritizing these features which will never be demanded of the engineering team is a must.
From culture perspective, engineering should move from “order-takers” to “equal partners”. This is extremely important. In some organisation culture, I have seen engineering is seen as “more than an equal partner” where what engineering says go. This sometimes, ofcourse causes issues as we may not always be delivering product to best of the market fit (seen that too). In other organisation culture, we only just do what market wants to see. Dare I say, product / SAAS will never achieve the maturity it deserves. Ofcourse, moving the culture requires empowerment and also engineers to be thinking like product owners.
The other aspect is really about business operational metrics. It is just not the reports that the customers want to see but it is also about where in the distributed engineering, things may not reconcile and will require manual efforts. Such aspects absolutely needs to be baked into product requirements by the engineering team.
Improve Efficiency through Continuous Improvement
Efficiency in both objective (eg. Failures, SLA achievements ) and subjective (eg. Team morale, teamwork, cross-collaboration) is required. For objective measures, KPIs needs to be built and communicated in engineering and business processes. For intangible aspects, eg. Culture, empowerment, team morale, cross-collaboration, it is important to have pulse through taking regular feedbacks. It is important to discuss them and do continuous improvements. It is important to face the brutal truth, talk openly and directly in safe way and improve.
Migration – Big Bang Approach vs. Slower, Measured, Stangulation Pattern
If existing customers are accessing the services, big bang approach is a very risky approach. Though sometimes that may be the only viable approach. It is always good to have two platforms running and a part of the traffic to go into the new service, reconcile in the meantime, measure the KPIs and slowly move the traffic to the new service. This approach, called stangulation pattern removes the risk to a great extent. The new service if not working out for any reason (both functional and non-functional errors), will limit the blast-radius of impact. Besides it is a smoother way to have a continuous improvement.
Finally, Rome is never built in a day. Leaders need to be aware of the shadow they are casting. Patience, working through a plan or roadmap, achieving the same, and communicating value throughout the organisation is required. Again, nothing will be pristine. Depending on where you are in the journey, importance will be placed in certain aspects more than the others. Important thing is to have a frame of mind to balance out the different perspectives every so often to achieve the goals otherwise, we will be part of the 69% metrics of digital transformation failures.