Digital transformation - part 3 - My view

What is digital transformation?

Digital transformation is using technology to create new or modify existing business processes, culture and customer experience to meet changing business and market requirements.

It can be summarized as the reimaging of business in the digital age.

Key Takeaway: Digital transformation is the use of technology to create new or modify existing business processes, culture and customer experience in response to changing business and market requirements.

Why should companies consider digital transformation?

Personally, I have seen the power of digital transformation and it really sets you up for working in an agile, cross-collaborative way that pushes a company towards the journey of growth.

It also allows value add to every customer interaction and can give a better customer experience. In most cases, companies push towards digital transformation as it helps to stand out against competitors.

The big add for me is the fact that data collected via digital transformation means that companies can make more informed decisions, and at the same time they can understand more about their customers. One brand that comes to mind is Tesco and their use of the Clubcard. This allowed them to recommend offers to customers based on what they buy generally and it enticed customers to come back when they had previously left for competitors.

Key Takeaway: Companies pursue digital transformation to work in a more agile, cross-collaborative way, to add value to customer interactions, and to use the data collected for better informed decisions, as Tesco did with Clubcard purchase data.

My view

Digital transformations work where leaders want to go back to the fundamentals, they focus on changing the mindset of its members as well as the culture and processes before they decide what digital tools to use and how to use them.

When in an enterprise environment I found that it was essential to retrain employees around digital, cloud, CI/CD, devops, AI tooling and other modern technology.

Whether in an enterprise or a startup environment I found that DevOps was a big tool in the digital transformation toolbox. Devops leaders galvanize software development, by merging development with operations across the devops lifecycle, enabling companies to continuously iterate software to speed up delivery.

Devops was key to our digital transformation in a start-up environment and I have seen exactly the same in an enterprise setting.

I have recently also seen the value of data scientists and data architects. The key reason is that companies seek to glean insights out of vast data, and transformations lean increasingly on machine learning and artificial intelligence (AI).

The AI part of this work has changed shape since 2022. Programs that once aimed at dashboards and predictive models now place AI agents inside the process itself, where software drafts a response, routes a case or triggers a downstream job without a person in the loop. That makes the cultural question sharper, not softer. Before the tooling decision, leaders need a written answer to two questions: what the agent is allowed to do on its own, and who owns the outcome when it gets something wrong.

Digital transformations generally succeed where they are led from the top and are accepted bottom up. In our startup setting, I found that when the whole team is invested it means that there is more chance of success. What was great was that we had a clear vision to add/improve our digital products, and this went a large way in attracting new talent. With the right culture and mindset, we found that the innovation just kept growing.

It was important to reflect weekly, this allowed us to change our path and thus focus on another change to add more value. For example if we focused on the mobile app and adding new options, if users found a defect which halted them reading articles we would shift our priorities.

The key tip I would give leaders is to really focus on the cultural aspects, with the right culture it will mean that you have a higher chance of success. What was important was that the team feel valued, respected, listened to, and are in the best environment to do their best work. I liken this to a plant where if it is in the right environment, with the right soil and right nourishment, it will surely flourish.

Key Takeaway: Digital transformation succeeds when leaders change mindset, culture and processes before choosing digital tools, and when the change is led from the top and accepted bottom up.

Applying this to Quality Assurance

Digital transformation in a startup and enterprise environment can be different.

For instance, when I worked in a startup it was pushing more towards agile processes and what was key was that we really accelerated on automation, also ensuring that engineering and QA understood the automation and they could run it together. The test automation framework selection was a group decision rather than just QA, this led to group acceptance and it pushed us to digitally transform as a team in an agile environment.

In contrast, in an enterprise environment, it was key that the assurance aspect was first, that there was buy-in for stakeholders first to prove that we knew what we were testing, whether it was prioritized with product and we were ensuring that we had no escaped defects first. Once the basics were in place they wanted to see a clear framework selection, with a proof of concept and key success criteria for the selection of the framework.

In a startup, I would say there was more appetite for experimentation and if one framework failed it was fine to try something else, though with data we could make this decision quickly.

In an enterprise environment, there was less appetite for risk and it meant that the framework selection had to be well thought out as the impact of getting this wrong was more wide facing.

Assurance has had to change with it. A rules based feature returns the same output for the same input, so a pass or fail assertion is enough. A feature built on a language model does not, so the same test can pass one day and fail the next with no code change. The teams handling this well keep their regression testing suite for the deterministic paths, add an evaluation set for the model driven paths that scores expected behavior rather than exact strings, and sample the results for human review.

Key Takeaway: Quality assurance in a startup transformation relies on fast, group agreed automation framework choices, while an enterprise transformation requires stakeholder buy-in and a proof of concept before any framework is selected.

Why can digital transformations fail?

Some of the key reasons why I have seen failure are due to:

• Resistance, where the team is not invested in the change. The team must be taken on a journey to ensure they are committed, and this ensures more chance of success.
• Ensure there are change leaders. It is essential that there are vocal supporters of your digital transformation.
• There is a lack of a review process. We must review where we are and whether we are on the right path to success and if we are not on the right path then make a change.

Learn how TestMu AI's Unified Testing Cloud can help you achieve seamless digital transformation through efficient and reliable testing.

Key Takeaway: Digital transformations fail when the team resists the change, when no vocal change leaders support the program, and when no review process exists to check whether the program is on the right path.

How do you measure whether a digital transformation is working?

Measure the delivery system, not the tool rollout. DORA now publishes five software delivery metrics: change lead time, deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate (DORA). Read together they answer one question. Is the team shipping more change without breaking more of it. Next to those, hold the two or three business outcomes the program was funded to move. The Enterprisers Project makes a point worth copying here, which is to judge the portfolio rather than each project on its own, because one initiative rarely carries the whole result (The Enterprisers Project).

This matters more now that AI sits inside the delivery path. The 2025 DORA report found that 90 percent of respondents use AI at work, and unlike the previous year it recorded a positive relationship between AI adoption and software delivery throughput (Google Cloud). The same report found that AI adoption still has a negative relationship with delivery stability. More change reaches production, and a larger share of it needs immediate intervention. A transformation scorecard that counts tool adoption alone will read that pattern as progress.

The report puts the result plainly. AI does not fix a team, it amplifies what is already there. That sits directly on top of the cultural point I made earlier. Where code review, automated testing and feedback loops are weak, a higher change volume exposes the weakness sooner rather than hiding it. So pair every speed metric with a stability metric, keep the weekly reflection I described above, and give that review the authority to pause a rollout rather than only record one.

Key Takeaway: A digital transformation is measured by DORA delivery metrics and the business outcomes the program was funded to move, with every speed metric paired to a stability metric because AI raises delivery throughput while weakening delivery stability.

How is AI changing digital transformation programs?

AI has moved the transformation question from which platform to buy to which decisions software is allowed to make on its own. The work now sits inside the workflow rather than beside it.

Coding assistants such as GitHub Copilot and Google Gemini Code Assist sit in the editor and in the pull request, and agent style tooling drafts a response, routes a case or opens a change without a person in the loop. The money question now has numbers behind it. DORA published The ROI of AI-assisted Software Development in May 2026, and for a modelled 500 person engineering organization it puts first year return at 39 percent, on an 8.4 million dollar investment against 11.6 million dollars of value realized, with payback at roughly eight months (InfoQ).

The same model carries two warnings that matter more to a transformation lead than the headline figure. It books a 344,000 dollar negative line for instability, because a higher change volume raises the change failure rate when the delivery infrastructure does not improve alongside it. It also describes a J curve, where teams take a temporary drop in productivity before value arrives, caused by learning curves, the effort of verifying generated code and the process change around it. Budget for that dip, and do not cancel a program while it is still in the trough.

The report frames AI as an amplifier of the system it lands in, which is the cultural point again in a different form. Weak code review and thin test coverage are not hidden by a faster pipeline. They surface sooner.

Key Takeaway: AI raises delivery throughput and delivery instability together, so a transformation program should budget for the early productivity dip, pair every AI speed gain with a stability measure, and fix code review and test coverage before scaling the tooling.

Closing

Thanks for sticking with me on this digital transformation journey. Digital transformation is never easy and it is difficult to put a time frame on this.

What is most important is that there are checkpoints and measures in place so that you have a greater chance of success!