4 Ways to Measure the Value of Your Tech Transformation

Undergoing a tech transformation is a big undertaking for any tech team. Sadhana Gopal, Engineering Manager at Independer, has learned that being able to measure the value of the transformation is just as important as the technical roadmap you create for actually carrying out the transformation. She unpacks how she measures the value of a tech transformation while it’s happening, so that her team can stay agile and adapt to changes as they arise.

Tech transformations are a big undertaking for tech teams. In old companies with lots of old code, these technical overhauls help development teams update their architecture and remove legacy blockers. That said, they not only require a lot of technically complex work, but they also tend to happen alongside business-as-usual. This can make it really challenging for tech teams and their engineering managers to know where to start, how long it’ll take to finish, and how valuable it will really be once it is done.

Sadhana is the engineering manager at Independer, the longest running FinTech e-commerce platform in the Netherlands, and she is leading her company’s tech transformation. At a certain point in their product, she says that her team realised that what seemed very reasonable technical requests from the business were incredibly complex and difficult to deliver. This prompted them to initiate this transformation in their product’s architecture.

However, as important as the technical aspects to how the transformation gets done are, Sadhana’s approach has been to focus on measuring the value of the transformation as it’s happening:

“Creating the roadmap is the easy bit... The hard part is how you are going to measure it, and how you are going to make it ‘small’ enough that you're able to continuously ask yourself, "Does this make sense? Do we want to continue doing this, or do we want to roll back?’ If you don't do that, it's very easy to get lost.”

Sadhana needed to make sure that her team stays on track, and that the things they’re doing in line with the transformation actually have a valuable impact on the business. Experience has taught her that it’s impossible for anyone to predict whether things will crop up and when, and she measures the value it’s creating while they’re doing it.

In order to measure the value of her tech transformation, the four approaches she uses are:

• Give it status
• Break the roadmap into its smallest chunks
• Increase visibility and communication
• Build a ‘SWAT team’

Give it status

If Sadhana wants to know whether the tech transformation is helping her business, she needs buy-in from the entire company right at the start. Having the company share a vested interest in a transformation like this will mean that it’s more likely to be used and interacted with, which gives Sadhana critical user feedback. She explains that:

“Culture eats strategy for breakfast: I can make all the strategy that I like, but if the entire team doesn’t buy-in, and if they don't really believe that this is helping them, then it's not going to work.”

In her experience, the best way to ensure buy-in from the entire company is to make it part of the company’s top-level strategy, as opposed to letting it be a project driven internally by the development team:

“We created this transformation as one of [the company’s] programs, which has a key focus at Independer from a strategic point of view. This was done by management to make sure that everybody knows that this kind of transformation is really crucial for Independer.”

Break the roadmap into its smallest chunks

The trap Sadhana sees many people fall into is building a roadmap that is too concrete in the long-term. “If you get too set in your ways and create a three-year roadmap”, she explains, “I think things become a lot less measurable. You’ll be so attached to it, and you risk getting stuck in a very goal-oriented mindset, which makes it harder to change direction and pivot if need be.”

Instead, Sadhana’s team broke it down into the smallest possible units of work.

“That's how you create a measurable roadmap, you break it down to the smallest possible steps, and then you start working towards it.”

In their transformation, Sadhana’s team divided their roadmap into five main areas, and then broke each of those five areas into smaller and smaller chunks of work until they got down to the minimum units of work that needed to be done:

“We divided the transformation into five areas: Decoupling our architecture, getting better insights into what is actually happening in the site, creating and using more off the shelf components, building a strong agile mindset, and building a strong engineering culture.”

After deciding the five main ‘streams’, Sadhana’s team broke each of those down into smaller tasks, and broke each of those smaller tasks down into even smaller tasks. “We took one product, and looked for the smallest, relatively newest and relatively lowest in complexity, and we said, ‘Okay, now we're just going to decouple this from the rest of our monolith’ — for example — ‘and see how it works. Let's keep it small’.”

By focusing on smaller pieces at a time, it’s easier for Sadhana’s team to see things as they break and course correct early, or see opportunities as they arise and add them to their roadmap. This, she says, is especially important for her team to be able to do because they’re working on many different parts of the architecture at the same time:

“All of them have to go hand in hand for it all to come together. When we decouple, we were also paying equal attention to automating our releases, which meant really paying attention to the way we tested and how we were going to maintain our test architecture. To release products with full confidence, you need to make improvements in all of them rather than just focusing on one thing.”

Increase visibility and communication

Another key part of creating a measurable roadmap is creating enough surface area for teams to engage with her and with each other. Sadhana explains: “We tried to create visibility on different levels of the business and I think, in any transformation of this kind, keeping people really up to date on what is happening becomes really important.”

In order to know whether the business is really getting any value out of her tech transformation, Sadhana needs to ensure that the whole company knows exactly what is happening because it lets them speak up when things go right or wrong.

“I can add a lot of metrics”, she says, “and a lot of dashboards, lead time, cycle time defects... but if I'm not communicating with people, if we don't have the culture of being open and honest, then we are missing information on how this is being perceived by the team.”

If she’s not creating value at every point of the transformation — for her development team, but for the wider team as well — then the transformation is not on track, and Sadhana knows she needs to pivot.

In her team, one of the ways Sadhana increases visibility and communication is to add new meeting cadences to their schedule, as opposed to just adding onto existing meetings in their agendas: “We developed a one-to-two-month roadmap”, she says, “with milestones that each charter would achieve. Then, we’d have bi-weekly calls with each of the charter leads where they report if they are on schedule to reach a particular milestone.”

This also creates many opportunities for ‘small wins’, which help keep the team motivated during such a mammoth technical task, which can easily become overwhelming: “We see the progress as we hit each milestone. That mentally is a huge, huge boost for people.”

Build a ‘SWAT team’

Finally, Sadhana says that a measurable roadmap needs a dedicated team of developers that monitor and roll-out the new architecture across the organisation. “I did not want a distributed model, where one team goes away and does stuff, and the actual product teams know nothing about it.”

Instead, her team put together a ‘SWAT’ team:

“We decided to create an infrastructure team: They work on the roadmap with everyone else, and when they get to a milestone, they go off to a particular product team — which also has that within their milestone — and help embed that change within the team itself.”

The roles in Sadhana’s SWAT team include:

• Front end developers that know a lot about the front end architecture
• DevOps engineers that know about how their systems are deployed on production and the complexity of our whole deployment landscape, and
• Architects that have a lot of knowledge about how their back-end systems work

The SWAT team’s main task is to take each small change, and help various teams integrate it into their system. “They run a little ahead of the rest of the teams”, she says, “and are basically facing the new technology head on.”

This lets them evaluate the tech transformation in small chunks, so that they don’t have to wait until the transformation is finished to find out that something doesn’t work. “We didn’t want to take the ‘big bang’ approach of adopting something really big and then all of the teams needing to take time and effort to adapt to this massive change.”

In Sadhana’s experience, having a team that is specifically dedicated and committed to the tech transformation means that there is a ‘living, breathing tracking system’ made up of team members involved in the transformation itself that can respond to changes or bugs in real-time. Even though this approach takes, longer, it means Sadhana’s team gets a much clearer idea of whether the changes they make are valuable to the team or not:

“Yes, it takes longer, but the advantage is that the whole team is working on the changes along with the SWAT team members. We start small, we keep moving, we test it, we evaluate it — and, if we see value in it, then we propagate it to the different product teams.”

If you have any questions, or would like to reach out to Sadhana, you can find her on LinkedIn!