Whether or not to roll your own UI component library is a common dilemma when developing products
with a unique brand identity. In this blog post, we shed light on how we're solving this at Einride
– and lessons learned from along the way.
At Einride, our goal is to eliminate the 7% of global carbon emissions that come from road freight.
We have learned that making an impact is not just about developing cutting-edge technology - you
also need a unique brand to make your products stand out in the market.
At Einride, we aim to convey our unique brand identity across software and hardware products.
It can be challenging to convey a unique brand identity in digital products, especially when going
through a scale-up phase where experiences and experiments are perpetually developed and launched.
Development speed is vital, which means that building brand-accurate UIs must be quick and easy.
In the early days of Einride, way too much time was spent on creating the most basic UI components –
such as buttons and input fields – time and time again. This considerably impacted our development
speed.
Buttons can cost any company a lot of money.
We knew that having a component library of ready-made and brand-aligned components would
significantly speed up development. That's why we went ahead and created
Einride UI – our own component library. But this led us to another
challenge: How do we strike a balance between investing time in developing a unique component
library, versus investing time in developing the actual product?
How do you convey a unique brand without building components from scratch?
One of Einride's development principles is: "Build what we need, not what we might need".
Considering the vast amount of excellent component libraries out there we could use, is building our
own component library from scratch really the most effective approach? Or is there a better way?
It's tech radar review season at Einride! That means each engineering guild facilitates a workshop
to ensure that their tech radar is up to date, relevant and useful.
In this post we explain what a tech radar is, why having one or more tech radar is useful, and how
we work with tech radars at Einride.
Want to know more? Read on!
A glimpse of the tech radar review workshop board.
Tech radar is a concept originating from ThoughtWorks,
originally for visualizing emerging and declining technologies in the software industry as a whole.
It has since been adopted by product and technology companies as a way to visualize technologies
that are emerging and declining locally within their organization.
Examples of other organizations who have adopted tech radar are
Spotify,
Zalando and CNCF.
A tech radar visualizes technologies as blips on a radar.
The blips are categorized into quadrants based on the type
of technology, and into rings based on the phase of adoption
of the technology.
A blip represents a single, specific technology. It can be a specific programming language, such as
Go and Rust, a specific SDK, or
an entire framework, such as Ruby on Rails.
A blip can also be a technique, a process, or a way of working with technology, such as
CI/CD,
SRE or
A quadrant is a pie-slice of the radar that collects blips of the same kind. Most tech radars have a
quadrant for programming languages, and many tech radars have a quadrant for processes and ways of
working.
A ring on the radar collects blips from all quadrants in the same phase of adoption. Most tech
radars have the innermost ring contain technologies that should be strongly considered for adoption,
while the outermost ring contains technologies that should not be adopted.
The shape of a blip signifies the direction the blip moved in the latest review.
A round blip (●) means that the blip is either new on the
radar, or has remained in the same place in the latest review.
A downward facing triangle blip (▼) means that the blip
moved down in the latest review - i.e. it was moved from an inner ring to an outer ring.
Conversely, an upward facing triangle blip (▲) means that
the blip moved up in the latest review - i.e. it was moved from an outer ring to an inner ring.
Tech radar serves as a visual tool for organizing technology choices and the reasoning behind them.
When used effectively, it provides a combination of quick overview and in-depth documentation of
context and history.
In agile organizations, reorgs are bound to happen. This applies doubly to rapidly growing
organizations where few teams frequently turn into many. This also means that system ownership is
bound to change over time.
Aligning on core technologies and ways of working across the organization ensures that systems can
change ownership between teams, without requiring teams to learn new technologies.
One of the most obvious things to align are programming languages, but in many cases there are also
benefits to aligning databases, SDKs and surrounding infrastructure.
Alignment also improves knowledge sharing and solution sharing across an organization. When team A
encounters a new problem and finds a solution, the probability of team B being able to re-use
elements of the solution increases if they use the same underlying languages, tools and techniques.
New team members can speed up their onboarding by using the tech radars to quickly get an overview
of the key technologies related to their discipline, and why the were adopted.
This also applies to current team members who want to improve their knowledge outside of their core
discipline, such as frontend developers using the backend tech radar to master full-stack
development, and backend developers using the data & ML tech radar to learn data and ML ops.
All technologies were adopted in a context, and context changes over time. Eventually, all
technology choices need to be re-evaluted and challenged, to make sure they are still effective in
the current context.
By writing a short article about every blip, similar to
Lightweight Architecture Design Records,
tech radar provides transparency on the context and reasoning of why a technology was adopted, and
why blips have moved up and down the radar.
Transparency lowers the bar for identifying when the context of a blip has changed, and better
solutions that are more fit for purpose need to be considered.
Einride's mission is to design and develop intelligent technologies for movement, to reduce the
emissions from road transport and offer shipper customers access to the cleanest, safest and most
efficient way to ship.
Einride achieves these goals by developing technologies in several separate product areas; the three
main ones being the Saga platform, which enables Einride's their
Electric Freight and Autonomous Freight
products.
To align and knowledge share between these separate areas, Einride uses the organizational concept
of "engineering guilds". Tech radars have gradually become the primary tool for recording and
visualizing technology decisions made in the guilds.
The common definition of an "engineering guild" in a technology organization is an organization-wide
forum where developers from the same discipline share knowledge and best practices, and where
technology choices and ways of working are discussed and aligned.
The first engineering guild founded at Einride was the Frontend Guild. It originally started as a
Slack channel, where some of the early topics included GraphQL vs. REST for API technology, and
aligning on which date and time library to prefer across the whole organization.
The first guild to start having formal guild meetings was the Backend Guild. This coincided with
Einride's global expansion, and some of the early topics covered were multi-region cloud
architecture, and aligning on Terraform as the preferred technology for infrastructure-as-code.
The Data Guild soon followed, where one of the big initial topis was data mesh architecture and how
to best implement. This was followed by alignment on what programming languages and SDKs to prefer
for building data pipelines.
The Autonomous Platform Guild at Einride was founded in an effort to create a forum where the
aspects of software engineering that are specific to autonomous vehicles could be the main focus.
This guild started later than the other guilds, and the initial focus of the meetings was to map out
all the already existing best practices and ongoing technology adoption initiatives going on across
the teams developing software for the Pod.
Each major engineering guild at Einride maintains their own tech radar. This is different from how
most organizations work with tech radar, since it means that Einride has several tech radars, as
opposed to a single one.
The motivation for structuring tech radars in this way is simple; it's practical! Making a tech
radar is a big undertaking, and maintaining one over time even moreso. But when combining tech radar
with guilds, building and keeping the radar up to date can be part of the guild's way of working
with recording, formalizing, and visualizing technology decisions.
Most guilds keep their radars up to date as part of their ongoing work, adding blips to the radar,
or updating existing ones as conclusions and decisions are made in guild meetings.
However, at least a few times per year, we've found that it's useful to review the radar together
with the organization's current business strategy, as a way to identify technology gaps, and
existing technologies where the underlying context and reason for choosing may have changed.
To ensure that
structure follows strategy,
always start by looking at the business strategy and the goals that the organization is trying to
achive.
This shouldn't take too much time from the workshop, but it's important to have these goals top of
mind and use them to guide discussions on what to put on the tech radar and why.
The first part of the workshop focuses on identifying gaps and proposing new technologies to put on
the radar. Each proposed blip is accompanied with a brief pitch of what gap the technology fills and
why it's an appropriate choice to fill that gap.
Strong pitches for new technologies to put on the radar point to successful experiments from
hack-days, or existing practical examples of how the technology can be effectively used to solve key
use cases within the organization.
Depending on the level of attendance and engagement in the guild, there will likely be too many
potential new blips to discuss, and then we've found that some variant of the
Lean Coffee format tends to work well. Einride uses
Miro to conduct remote-first workshops - we've found it has all the tooling
we need to effectively organize lean coffee voting sessions.
The second part of the workshop focuses on reviewing existing radar blips, to identify ones that
should be moved up or down. This part starts with a voting session, where participarts vote on which
existing entries to discuss moving.
Strong pitches for existing technologies to move up on the radar point to how the technology has
been increasing in adoption since the last review, and reaffirms that it remains relevant to the
current business strategy and goals.
Once again, a lean coffee format is used to discuss the blips in order of most votes.
Some topics may be divisive, and there's always many ways of achieving the same goal. Each tech
radar has roles of responsibility associated which act as tiebreakers and ensure that the content of
the radar is consistent and business-aligned.
This post has explained the concept of tech radars and why they are a useful tool for a technology
organization, with specific examples of how Einride has integrated tech radar together with the
concept of guilds.
If your organization has not yet adopted tech radar or guilds, we hope that this post, and our own
tech radar, can serve as inspiration on how these ideas can be applied in your
organization!
note
If you want to join our team and work on technologies for sustainable freight, check out our
careers page. We are a global, hybrid workplace organization with
engineering offices in Austin, Stockholm and Gothenburg as of May 2022.
