Skip to main content

2 posts tagged with "culture"

View All Tags

Building a UI component library: How we balance brand identity and speed

· 9 min read
Filip Tammergård
Software Engineer

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!

· 10 min read

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.

What is a tech radar?

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.

Blips, quadrants, rings and moves

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.

Anatomy of a tech radar.


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.

Why use tech radar?

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.

Alignment, onboarding and transparency

Some benefits of using tech radar we've observed at Einride are: improved alignment, faster onboarding times, and increased transparency.


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.

How does Einride use tech radars?

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.

Engineering guilds at Einride

What is an engineering guild?

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.

Frontend Guild

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.

Backend Guild

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.

Data Guild

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.

Autonomous Platform Guild

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.

Pairing radars with engineering guilds

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.

Review workshops

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.

Overview of the tech radar review workshop board.

Review current business goals and challenges

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.

Pitch new entries on the radar

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.

Move existing entries on the radar

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.

Governance and tiebreaking

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!


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.