You have 1 article left to read this month before you need to register a free LeadDev.com account.
The German e-commerce company has adapted the concept from Thoughtworks to track emerging technologies across its engineering teams.
In a world where Amazon Web Services (AWS) has a catalog of more than 200 cloud services, and there is an open-source solution to almost any engineering problem, how do you keep track of what technology is being brought into the organization, and ensure that engineers learn from each other’s experiences?
While many engineering orgs will have a strict technology selection process that prioritizes a shared set of languages and services for consistency and maintainability reasons, Zalando, the European fashion and lifestyle e-commerce company, wanted to embrace a collaborative approach that enables 2,000+ developers to make responsible technology choices in the open.
What is the Zalando Tech Radar?
Zalando adapted the Thoughtworks Technology Radar into its own Tech Radar shortly after it embarked on a major cloud migration with AWS in 2015, starting life as an Excel spreadsheet. Before that migration, the tech stack was fairly simple – mostly Spring, Java, and Postgres – whereas moving to the cloud opened up an irresistible menu of technology options for teams to choose from.
The result looks like a radar screen, with a set of concentric rings with Adopt at the center, working outwards to Trial, Assess, and Hold. It’s an effective visual representation of where certain technologies sit in the adoption cycle and can be adapted for internal use. Each ‘blip’ on the radar is a technology with an associated documentation site, which details pros, cons, restrictions, usage, and lessons learned by engineers with experience using the technology. These contributions are then supplemented by usage data from AWS accounts, source code repos, and Zalando’s infrastructure platform.
A technology can only reach the Adopt stage once there is high confidence that it fits Zalando’s needs at scale, with low risk, and that any additional infrastructure investments to make it easy for teams to use have been identified. Trial means there has been some success in pockets across the organization and there is an appetite for a wider trial. Assess is for promising technologies with clear potential but are so far unproven and risky. And Hold means the technology is not a strategic fit anymore, proved to be difficult to operate, or doesn’t have clear value beyond any existing pilots.
How do you get something on the radar?
An engineer can ‘pitch’ using an issue template stored in GitHub to get a new technology onto the radar or have it move rings. These include common moderator questions around use case fit, key differences from alternatives already on the radar, conformance to a set of selection principles, and any evidence of support within the engineering community at Zalando.
If this is successful, the pitch might progress to a production readiness assessment evaluation. This process is designed to connect teams trialing new technologies with other engineers who may have experience with similar use cases or other technologies in order to compare notes and create a company-wide view.
The primary aim here is to start conversations and discussions about technology choices between engineers across the organization. “For us, it’s a tool to drive those conversations, to visualize technology choices, and to also explain where technology choices matter and where technology choices are something that you will discover may not be the best idea,” Bartosz Ocytko, Executive Principal Engineer at Zalando told LeadDev. “It’s not intended to be a super rigid process, it’s intended to help drive the right discussions.”
To help keep these discussions productive, Zalando’s technology selection principles are designed to help steer engineering teams toward making technology choices that benefit the whole company and not just a single team or use case. For example, one principle is “favor what is proven”, which pushes teams toward existing defaults instead of just adding new technology to the radar.
“Choices around languages or infrastructure are not team choices, but company-wide choices,” Ocytko said. “This is typically very tricky for engineers, especially on the language side, because preferences on which language to pick tend to vary by the individual and it’s very easy to get into discussions that aren’t really rooted in what the company needs.”
If the technology moves to the trial phase, engineering heads are asked to sponsor and eventually commit to being accountable for divesting from non-promising technologies and are tasked with removing failed experiments from the Zalando technology landscape.
Any ring changes are then voted on by a panel of principal engineers, who act as moderators, ensure incoming selections are appropriate and assessed correctly, and initiate working groups to develop guidelines around emerging technologies. “The idea is to be supportive of teams to drive and support innovation, so you really need a good argument as to why this wouldn’t be a good idea to even try it out in a single team,” Ocytko said.
Finally, bigger changes to the tech radar are discussed with the principal engineers on a quarterly basis and decisions are shared with transparent rationale.
Once something has been adopted, the leader of that team is now responsible for the long-term impact of that decision. “In the early phase of technology adoption we’re collecting the commitment of our engineering heads, that if the trial will not work out, they commit to removing this technology from the landscape,” Ocytko said. “That’s important because over time, through attrition, the person who makes the call is not in the organization anymore and the team has to live with the decisions that have been made in the past, which is tricky.”
Of course, every now and again a technology will slip under the radar. To try and catch these instances, the cloud infrastructure team will flag when a new AWS technology is requested in a production cluster and ask the team to create a Tech Radar entry. Naturally, this isn’t the optimal time for a blip to be landing on the radar, “but it’s the last resort,” Ocytko said. “Typically, you’re expecting those discussions will happen earlier, and they do. The principal engineers are also meeting on a regular basis in order to see where we are with the Tech Radar.”
Adoption challenges abound
While the Tech Radar gained some strong evangelical support, the voluntary nature of contributions meant adoption was patchy. “In an organization with more than 2,000 engineers, you really need to show people the way,” Ocytko said. “They won’t be sufficiently connected in the organization to know who to ask, or are afraid about if it’s a good thing to ask about.”
Instead of enforcing contributions through hurdles and added points of friction, Ocytko and the other principal engineers started by reassessing the incentives and ensuring that contributions were recognized, for example when performance review season arrives.
“We made sure that the contributions to the Tech Radar are rewarded as part of our job descriptions and recognized as community contributions,” he said. However, “you can create all kinds of incentives, but if you don’t have the right culture, then you will not achieve anything,” he warned.
How to get started
Zalando has open-sourced the code to generate a Tech Radar visualization, complete with HTML, a JavaScript library, and a JSON file to configure the dimensions and ring assignments.
However, as with most projects, the challenge of setting up your own Tech Radar will likely fall on the people side, and not the technology. “I think the most difficult thing is deciding for your organization who is the right group of people who are going to make the choices and moderate the discussions and decision making,” Ocytko said. Start by setting some principles for technology selection. Do you want the process to be collaborative and transparent, or more top-down and strict?
And what have Ocytko and his team learned through this process? “I wish I had known how much time it takes to have really good discussions and help engineers raise the arguments that will contribute to those discussions being fact-based.”
