Enabling rapid experimentation while keeping control

For this piece, Ilkka Rämö and Thomas Tunkkari sat down to discuss a range of topics around rapid IT testing and some of the control concerns that IT decision-makers are facing today. They also share a number of tips and ideas based on their own experiences working alongside clients.
In our earlier blog Harnessing the power of DevOps to collaborate with digital sales, Mikko and Rory talked about exploiting full-cycle DevOps as a tool to enable experimentation. In this discussion, Ilkka and Thomas look at experimentation from the perspective of a developer.

Why do we assume that IT people want to have control? Is it fear-related?

Ilkka: We first need to consider what “control” means and what the underlying fear is. Control can mean time schedules. It can mean budget or content. It can mean the wholeness of the architecture of a unified organisation.

Fear in IT experts is more apparent in organisations where IT teams and their activities are separated from the business and digital sales activities. In general, the technology services and platforms that digital sales teams work with are ordered from their IT teams. In this way, IT knows they can deliver what was ordered. This is one example of control.

When it comes to experimentation, it generally happens closer to the business and therefore it’s not an IT operation but a sales operation. That means no visibility or say on the outcome for IT, which brings fear. Not everything is taken into consideration and because it’s something that hasn’t been planned, it becomes scary.

Thomas: Another form of control is a company being invested in a certain ecosystem. For example, consider the Microsoft ecosystem or the Google ecosystem. There are clear benefits to having a single environment of productivity, communications apps and software working together.

What happens when one group within the company isn’t impressed with those tools? They feel their needs would be better met with a different solution. We’ve seen cases in companies where that group may go out and purchase a different set of tools and start using them without IT knowing. This is another example of a loss of control for IT, which brings a level of fear.

It goes even deeper than the productivity piece of it too though, right? Licensing and cost, for example.

Ilkka: Yes, especially in a larger corporation or enterprise. Future IT investments should be run in a controlled way with a controlled process of procurement. Then it’s known exactly which vendors and providers you’re in discussions with and you’re able to run a tendering process to decide which tools are the best choice, based on everything, including their total cost of ownership.

You mentioned experimentation earlier. Talk about the experimentation aspect and what’s involved there.

Ilkka: Ask the question: Are we investing in future solutions, tools and features or are we looking at gaining knowledge? Those are two different things. I find that it’s usually the latter. The idea of experimentation is not to build something new necessarily. It’s the testing of something that should be built. This can help with everything from the procurement processes to the IT processes because we gain a better understanding of what should be done.

You validate quickly with the market if something works and if it brings value or not. Decide with any experimentation if it’s about a final solution or just to gain knowledge.

Thomas: Consider a strict staging and testing environment, so that you’re not compromising anything for quicker output or taking shortcuts and bypassing processes. These will create that fear for IT when they don’t have that visibility, in cases of code changes and deployments.

It may be that parts of the actual code will be utilised later. But from an IT perspective, this is a concern. How do we have the visibility and a changelog of what was done, by whom and why?

Ilkka: Yes, “by whom” is the key part here because it shows the resourcing. If the organisation is shaped in a way that you have siloed digital sales as one entity and IT as a separate entity, then there’s a real problem. IT needs to have the responsibility of the IT systems.

If they aren’t involved in the experimentation phase, then they will need to take something as a handover, something they know nothing about, something they haven’t planned, and won’t have the resources for.

You can’t separate these two entities, because this kind of experimentation is a business operation. It’s necessary to bring in IT capabilities within digital sales’ reach in order to do this kind of experimentation. And there shouldn’t be a handover because it’s operative work when experimenting with something. All required capabilities and IT should be involved early enough in the experimentation so that there are no hidden pieces.

Can you remember an eye-opening, real-life experience where this wasn’t the case?

Ilkka: We recently witnessed a start-up company where quite a big gap had formed between IT operations and the digital sales side. It escalated to the point where the CTO of the start-up wanted to build a wall in between IT and business, demanding that no one from business approach his IT people without going through him.

“It starts by breaking that wall, evolving how to sell the idea and how to convince the IT decision-maker or business decision-maker. Growth hacking for IT doesn’t have to be anything scary, though.” — Thomas Tunkkari

We could sense that this CTO was afraid of losing control. This thinking of, “I’m afraid my IT people aren’t going by my agenda and they’re doing something I don’t have control over anymore.” It’s a sign of moving in the wrong direction. These walls decrease the ability of digital sales and IT operations to have dialogue and test things out in favour of maintaining control.

What does growth hacking mean for IT?

Thomas: It starts by breaking that wall that Ilkka just mentioned, evolving how to sell the idea and how to convince the IT decision-maker or business decision-maker. Growth hacking for IT doesn’t have to be anything scary, though.

It’s looking at how to involve those people in your company, with mapping goals as one of the priorities and convincing everyone to commit to those goals. Business may own something that they want to experiment with, to try to learn, to find out if it’s a good market fit or if the service would work or how to develop an existing service.

Growth hacking is just a different way of doing things — different processes and different types of goals. There might be some minor changes that help break down the conversational barriers. Maybe a person from IT should be sitting down a couple of times a week with some people on the digital sales team, who are running and owning the process.

Ilkka: I would be a bit more radical and say that organisational changes are usually necessary. I’m not talking about organisational charts, of course. But one of the challenges is that if you look at people’s scorecards, where do they get their bonuses from? If those are not aligned throughout the organisation, you’ll see those silos fighting against each other all the time.

As IT experts, we should understand the reason for IT in an organisation. A digital world requires different capabilities, one of those being IT. However, it’s never about the IT goals. We’re doing things from a digital sales goals perspective. And that should be on top of each and every developer’s mind. Which business goals is my work helping? Which business goals are we trying to meet with this assignment I’m working with?

“Results always help get the buy-in. Proving and showing something tangible is a really good argument and the proof is right there in those results.” — Ilkka Rämö

Quite often, if it’s the siloed IT department, the mindset becomes completing a project in a given timeframe or complying with these technical constraints. Those are important aspects. But they are not goals for the organisation as a whole.
The goal of a business is to make more money tomorrow than it does today. You need to know what you can do to achieve that from an IT perspective and what areas of the business you have touched.

How do you think the relationship between IT and digital sales has evolved over the years?

Ilkka: It’s definitely improved on both sides. Results always help get the buy-in. Proving and showing something tangible is a really good argument and the proof is right there in those results.

That has traditionally been the challenge of digital sales. Digital sales teams order something from IT, and then they wait and they wait and they wait and the business keeps running. In the meantime, whatever was ordered is still pending. This is the pain of the sales teams. They don’t know when their need will be fulfilled. Hell, they don’t even know whether it’s going to improve their sales goals. This can be a painful thought to have on your mind.

Closing the gap and doing things in shorter and faster iterations and then seeing something tangible has been a real motivator — especially for the business people.
From the IT side, the pain points have seemingly always been the business requesting something that’s not realistic. To IT, some requests are not based on reality as they don’t understand the constraints or the lack of resources.

In recent years, though, I’ve witnessed many IT people see the light when they are part of a business experiment and see that those tasks they just handled in the backend system prove valuable for numbers. That’s quite motivating and very positive. All of a sudden, they think, “What we do here makes sense because we can prove it right away there”. This helps get the cycle spinning.

What’s the pulse on IT departments you’re seeing today?

Ilkka: Over the last 5 to 10 years, IT departments have slowly but surely started to figure out that it’s not about them. They are now striving more than ever to be more relevant, as some of our other experts in this handbook have also acknowledged.
IT decision-makers know they need to be more relevant for the business of the company. Otherwise, their IT departments may be outsourced due to pressure to save money. Indeed, companies are asking if they even need an internal IT department if their IT isn’t showing business value and enough relevancy.

For an IT decision-maker, this is a positive motivator, but it’s also a scary motivator. IT needs to be there for the sake of the business and not for the sake of their own IT operations.

Thomas: Yes, great points! And in IT experts justifying themselves, I also want to underline the importance of proving concepts and getting to those results with a wider group of colleagues involved. This helps to motivate them to get that trust from other leaders and decision-makers in the company, showing that there are already positive results that IT is bringing to the table.

Becoming less or more relevant depends on the whole business and initial role and current role. We’re seeing more and more cases of in-house developers who are not part of IT but are part of the digital sales team. This is already becoming the way of the future.

If the organisation has a CIO or CTO, are they part of the management team, are they discussing and reporting on C-level? Fairly or unfairly, that’s another way to stay relevant or keep the relevancy.

You brought up the idea of developers sitting on digital sales teams. What should they keep in mind to not be a speed bump or prevent IT from maintaining control?

Thomas: It’s important to understand that each person will have quite a big responsibility to not just deliver the technical solution or the coding solution, but may also be responsible for following certain processes.

And if you make mistakes or your code isn’t up to quality standards, it becomes a bigger issue than just stepping on IT’s toes. It may be that your code is overtaking some of the processes and going straight to the production environment in some form. In a worst-case scenario, if it’s not done right, it could break things, such as an existing functionality if it’s an experiment that’s run against a feature or functionality.

Unlike a traditional development process, in this case, you have a big responsibility to communicate well. That could mean a healthy level of documentation or keeping version control. It’s common in a growth hacking context that you may have more responsibility because you are most likely overriding some of the bigger processes that are in place.

Ilkka: Yes, I agree. And what is a digital business in the end? It’s basically the sales manager, marketing manager, developer and service designer sitting at the same table and solving a business problem together.

They just happen to know different things and are experts in their areas. All of those skills are required in the digital world to do something valuable and it doesn’t make any sense to separate those people because all those skills are needed to reach the goal.

Is it fair to say that an in-house developer sitting with digital sales, rather than with IT, is something that could affect IT’s control?

Ilkka: Yes, this is another example of something that brings fear. This kind of setup could be a source for trouble as it may not be aligned with the full process of building something. One way to overcome any concerns is to put in fast kill-switches, empowering you to cancel the experiment with one click.

Doing something that we might throw away can make an IT decision-maker wince. If you have a limited amount of money and a limited number of people doing the work, and you’re planning to put resources into development items that will most probably be thrown away — well, that’s scary.

That’s the whole reason for experimentation. We want to do it rapidly. We don’t want to spend a year doing this experiment, only to learn we need to throw it away. We’re experimenting for a day and flushing it away after a week if it doesn’t work out.

The total cost of ownership of that learning is a significantly smaller investment than the alternative: thorough planning, the illusion that we know everything, that it is going to work and doing a proper development project. And after all that, learning that this isn’t at all something we needed.

Finding balance is key here. The kill switch and being able to cancel everything helps mitigate the fear of losing control. If we kill something and remove something we did in the last couple of weeks, that’s fine. It was based on the knowledge we gained from the market and that was beneficial. Even if it wasn’t valuable, it was a small investment and now we know it didn’t pay off.

This blog post is part of The Digital Sales Handbook for leaders in IT. The handbook is a crystallisation of the key themes leaders in IT need to understand in 2021 to push their digital-enabled sales forward. The book includes interviews with industry experts from companies including Stora Enso, SAS, UPM and Tiger of Sweden. Learn how your IT can become an active driver for digital sales!