Late last year, Berlin-based Käuferportal went through a rebranding initiative to become Aroundhome. On the outside, this fast-growing seller of home products and services was just changing their name. But on the inside, the change meant much more, especially for CTO Steffen Heilmann and the IT team.
Käuferportal had been very successful, growing to more than 500 employees in 10 years. When the business started in 2008, the focus was on B2B products like coffee machines and copiers. In 2011 the business focus started shifting to B2C products, including high end items such as stairlifts. In the following years, more and more products were added, many of which had to do with home improvement, like kitchens, windows, and solar panels.
Not only was the company's original name thought to have very low brand awareness, it was no longer in line with the new strategy. This led to the renaming of Käuferportal (which translates to "Buyer Portal" in English) to Aroundhome in late 2018.
Today, Aroundhome is Germany's largest seller of products and services around the home, and helps millions of people to find the right service companies in their neighborhood.
From an IT perspective, the rebranding was one of the toughest challenges we could face. On a Monday morning, the new name was to be reflected in every single interaction and communication channel. This would include changes to emails sent to customers, internal email, the website, TV commercials, and much more. In summary this was a large-scale change with high stakes, and large potential business impact.
The change could only be done in a “Big Bang” approach, and could not be fully tested beforehand. Also, we faced a fixed timeline because new TV commercials announcing the name had been produced, and timeslots purchased in advance.
IT is Where Rebranding Came Together
The rebranding project was started a half a year earlier, and most of the organization was involved in one way or the other. However, IT was where everything came together.
We needed to develop and deploy a new website using the new corporate design. Also, we needed to make sure that our marketing emails not only used the new logo but were updated to reflect the new brand’s messaging and tone. We had to set up reports to understand the impact of the new brand and the effectiveness of our TV campaigns. And on top of this, both employees and external partners would need to switch to new email addresses and logins on the very same day, but would still need access to emails received before the switch. And of course, all of this would take place while were continuing to grow the business!
Two months before the brand switch, the IT leadership team got together to set up a joint IT plan and prepare for the big day. As a first step, we took plans from the individual IT teams, put them next to each other and talked about the most critical points in each plan. At that time, we realized a few important things:
- All our various plans relied on receiving certain information or input from elsewhere in the organization before certain dates. Across almost all of the teams, input from the business was late or overdue. Additionally, there were a few crucial unmade decisions that would have wider implications.
- The teams had been very much focused on their direct areas, but interdependencies between teams had not been addressed holistically. For example, if the branding team were to change the URL link structure, this would not only impact our CMS team (responsible for the website) but also IT operations and the team responsible for sending out marketing emails.
- Overall priorities were unclear: Which tasks were absolutely necessary for the switch? What steps could be implemented later?
IT Master Plan for Brand Switch Day
In order to improve the situation, we collated the plans into one overall IT plan. This did not include the whole rebranding project, but focused specifically on what IT needed to do in order to support our big brand switch day. We used this overall IT plan for our interaction with the business leaders. It helped us communicate the need for speedy decision making, especially around the topics with wider implications, like domain names and link structure.
We created a summary of all the major open decisions, then used this list to discuss options with management. Once they understood IT's requirements, and the importance of their input, they quickly made those decisions so we could continue with our preparations.
The overall IT plan also included a communication plan for brand switch day. How would we communicate with one another when e-mail was to be down while primary domains, logins and email addresses were getting updated? At what points did the teams needed to get back together?
In order to minimize risk during the switch, we also conducted a scenario analysis: What would happen if something went wrong? How would we recover? Could we roll-back? Which skills would we need on hand?
We made sure to maintain frequent interactions with our main stakeholders from the business. We needed to understand what the business requirements were, and what their timeline was. This tight integration helped us when management decided that the new website would be much larger than originally planned. 20 pages became 250 pages that had to be adjusted, all during the three week period initially reserved for bug fixing.
Through the tight integration with business stakeholders, IT quickly learned about any changing requirements. Since we knew best what would be needed, we drove not only the implementation but the collection of input and design. As a result, we managed to greatly improve the quality of the website very quickly and in time for the rebranding. This process was very intense for the entire IT team. Without their strong will and perseverance, we could not have succeeded.
We planned not only the day of the brand switch, but also day two. The brand switch was to happen on a Sunday, so when employees came in on Monday morning, the new name would be implemented. We arranged to provide "floor walkers" who would patrol the offices on Monday morning, available to help anybody with questions or problems. This way, we'd be able to help our users more quickly, and provide a fast and effective feedback channel should a major incident arise.
Brand switch day went very well. Everybody knew what they were expected to do. Early on, however, we came across a problem: the application deployment pipeline was building up a backlog that was growing and growing. We were redeploying all of our applications, some of them multiple times, and the pipeline was not scaled for such a load.
Luckily, we had one of our most senior resources available. Assuming that something unplanned would come up, we had him on stand-by for the day. Therefore, once we realized the problem with the deployment pipeline, he was available and able to solve the problem.
In the end, brand switch day went very smoothly as a result of the preparation and the unwavering perseverance of the team. Day two, when employees returned the office, also ran smoothly.
Here are a few things I would recommend to other CIOs facing a similar change:
- Establish an IT plan that shows dependencies between IT teams. The project-plan was fine for overall project planning, but did not reflect these dependencies.
- Create and keep direct interaction with the business stakeholders. This enables a quick response if business requirements change, as well as also the ability to get decisions from management quickly when required.
- Expect the unexpected: Keep some of your resource in reserve for the switch day, so if something unexpected comes up, you have the right resources to deal with the situation fast.
- Think about communication both within the teams during the switch, but also with the business leaders. Provide frequent updates to them during the switch to help them understand the progress being made.
- Plan also for the day after the switch. Include plans for an intensive care period to reassure the management, and to have resources available to respond to and resolve new issues that arise.