“I don’t like processes. They don’t set you up for sustained success” – Tibber’s CTO Richard Eklund talks delivery speed

The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

Delivery speed optimization begins with alignment

It’s faster to go somewhere by plane rather than by car. But first, you need to decide where you want to go.

Sounds obvious when you talk about your next holiday destination, right? But replace tourism with software development and the idea is not so clear anymore.

The graveyard of failed startups is full of organizations that move fast but in an unknown direction or all directions at once.

Richard is here to tell how he speeds up his product development by:

• measuring the right metrics,
• promoting the idea of individual responsibility,
• providing wide but not boundless freedoms limited by systems.

He does all that while continuously aligning Tibber’s teams towards common business goals by holding highly structured and stimulating workshops each quarter.

Learn about the structure of the workshops and tons of other details of Tibber’s work culture as Richard details his experience in the interview!

About Richard & Tibber

How to increase delivery speed?

Jakub Piłucki: Hello Richard. Let me start with something semi-personal – how has your life been in Berlin? I know that you moved there in 2023 to help set up Tibber’s engineering hub.

I moved there with my two daughters and wife. To be there at the office, to live the life of Berlin and meet all my colleagues and work there – I can’t put a price on that. We all had a great time. 

From a business perspective, this was about building our presence there to attract local talent.

My job was also to make sure that the hub stayed true to our engineering culture. I had to prevent it from becoming a silo. If you have a lot of engineers in one place, you can easily fall into the trap of developing software in a siloed manner.

You also moved to Germany to cooperate with Ford. Not so long ago, Tibber received $100M in series C funding. It looks like your company is growing fast. What’s the first thing on your mind today as the CTO of Tibber? 

Aligning the company, finding a common focus for everyone – it’s my most important job.

Partnering with Ford and getting new investments from green technology ventures opened a lot of new opportunities for us.

When we founded the hub in Berlin, our challenge was to decide what we were going to focus on – which problems to solve and what to optimize for. We need to tackle the opportunities that bring us the most value. There’s only so much we can do at the same time.

Getting up to speed… with speed

From what I already heard about your work at Tibber, it seems that you also credit the speed of delivery with driving a lot of your organization’s growth. Why is it so important to you?

For a startup or a scale-up like ours, speed is the only silver bullet you have. There are no other silver bullets in product engineering, product development, or R&D. The only thing you have is speed. You’re going to make a lot of mistakes and navigate in different directions. And if you don’t have speed, you’re going to fall behind.

That’s the truest answer I can give. In software engineering, when you try to make something new, you have to build and rebuild quickly.

Was Tibber always good at delivery speed? You joined Tibber in 2022, but the company goes back to 2016. What was your opinion on the company’s delivery practices when you joined?

At the time, the whole product development team was five to ten people. When you are small, things are not complicated. When you make a decision, everyone learns about it instantly.

As you grow, you need more systems to be able to move as fast as when you were smaller.

A lot of my contributions have been around growing an engineering organization. My job is to come up with ways to produce business value more efficiently.

You used the word “systems”. Is it the same as processes?

Not exactly. I don’t like processes. I don’t think they set you up for sustained success.

A process to me is a stricter term in the sense that you go through a few stages in a pre-described fashion. Systems provide a familiar space. You use them to help you make an optimal decision. They restrict you a little, but you still have freedom within some bounds.

At Tibber we currently have six engineering systems that aim to help everyone navigate and make decisions. Each tackles a distinct set of issues, but all have something to do with speed. That’s one of the most unique aspects of our engineering culture at Tibber.

To give you an idea, one of the six is the defragmentation system. It sets guidelines for picking new technologies to add to our stack, making sure that there’s limited chaos going forward.

I can see how this can help maintain speed over time. But if you want to improve delivery speed, you need a baseline set with metrics. What metrics do you value in particular at Tibber?

Time to tenth commit was the first metric we implemented when I joined Tibber. 

I was at Spotify for over seven years. I was responsible for ensuring that we had an optimal number of engineers. It’s typical for scale-ups. You got your product-market fit and you need to find an efficient way to scale your business.

Time to the tenth commit is about how quickly your new engineers can get to their tenth commit. I use it to find out if we hire too fast. If the number starts going up, it gives me an indication that I should look into our onboarding and our whole engineering operation. It may also indicate some other issues with delivery speed.

It’s not a flawless metric, of course, since a single commit can be very big or very small. But it gives you an indication. It’s easy to measure, which matters when you start growing your engineering team. It was important for us when we were smaller. Over the years, we’ve mastered the use of it.

We’re implementing more advanced metrics like the Developer Net Promoter Score (DNPS). It’s a qualitative metric. We interview our engineers to figure out how happy they are with the developer experience at Tibber.

Speeding up

Once you know what you want to measure, you need to eliminate bottlenecks. Let’s talk about them starting with coding. What are some practices seen in the coding phase that can impact delivery speed positively or negatively?

In my experience, developers deliver faster when you help them collaborate with other teammates. At Tibber, we do a lot of pair programming.

However, it’s not always possible to provide a human partner. That’s when another of our six systems, the AI system, comes in. We use co-pilot for every developer that joins Tibber. It works great.

Peer reviewing and a culture of sharing work also encourage people to collaborate.

You also can’t have a strong delivery process without solid deployment practices. How do you ensure high standards?

Again, you need to help your people be at their best. We have a team that happens to own both developer productivity and CI/CD pipelines at the same time. That ensures that they care about their responsibilities.

There are other things you can do. We measure our deployment frequency. We still have some improvements to make there. It’s one of our goals for the near future. 

We also automate tests to make sure that our deployment goes smoothly.

You already said one thing or two about technological choices and their potential to bring chaos that may affect delivery speed. How do you choose your technologies?

We have another system that is relevant here. We call it the RFC or request-for-comment system.

When you want to recommend a technology, you write a document that describes your motivation, rationale, security considerations and budget, among others. We share it with the whole engineering team. The goal is not to criticize it, but to build upon it. It’s always about contributing to the idea. When we make it as good as possible, we decide whether we go for it or not.

Are you trying to be sure everyone on the team is involved in this? We talked to some CTOs about a democratic approach to decision-making. The majority seem to agree that it is the right way to go, provided only people with the knowledge and sense of ownership get to participate.

If you want to, you can contribute to the idea of someone else with your experience.

It’s all about putting our ideas together. We are so much stronger as a team. We build on each other’s ideas.

So you give your people a lot of freedom and choice about how they want to do things. Empowered teams with a sense of ownership for their project seem to be the order for the day at innovative companies. We heard a lot about the potential of self-managed teams for improving efficiency. Such teams can move on their own a lot, which helps get rid of overhead that also affects delivery speed. What is your opinion on self-managed teams?

I like this approach a lot. But going back to what I said before, I believe that C-level managers and engineering leaders should only give autonomy to their teams when they manage to create organization-level alignment first.

If you’re unable to align your company towards common goals, you can’t afford to have self-managed teams. It will not work. With a lot of freedom and no alignment, everyone will move in different directions. It will be a mess.

I can’t stress it enough. Alignment is the foundation of well-functioning self-managed teams.

How do you create that kind of alignment that would allow self-managed teams to move towards the same goals? Is there a framework for it?

We’ve developed a framework on our own. We call it the Tibber Dance Week. 

The leadership starts the week on Monday morning by outlining targets and goals for the quarter. The goals aren’t all equal. We prioritize and rank them. There also shouldn’t be too many of them. Up to four is enough for our size of organization.

The rest of the week is about planning and resolving dependencies. We set out key initiatives for individual teams. They get familiar with their priorities and figure out solutions.

On Thursday, we have something that we call the Dance Hall. It’s a chaotic Google meeting with a big Miro board. It outlines the efforts of the company and what everyone needs to do to reach their goals. Within this framework, the team gets to have the autonomy to decide solutions that will help them achieve their goals.

This is our way of creating alignment. It works for us because we do it regularly and we got good at extracting value from it through a lot of trial and error.

Once, we found out that the commercial organization needed to be included more, or that customer support needed another way of giving input about product priorities. Every quarter, we learn something new.

You mentioned leadership. I’m also interested in the people who lead teams on a day-to-day basis. What are some critical roles that ensure timely delivery?

We have some special roles, but we don’t have a lead architect. Instead, we have the staff engineer as an example. This person is also essential for architecture.

The staff engineer is an area-level role. They are responsible for what we call a product area.

Their main task is to help untangle the complexities of technology. As we grow and build, we add more and more complexity to our code and architecture. We need the staff engineer to think of ways to simplify it so that everyone can add new code faster.

There is also the engineering manager’s role. They oversee the accountability of technical delivery. There’s an important distinction between accountability and responsibility that we apply.

At the end of the day, everyone is responsible for timely delivery. We don’t want to take the responsibility away from any individual. That’s why we don’t have tech leads. Or to put it in other words, every developer at Tibber is a tech lead and responsible for their team’s delivery.

You said a lot about fostering the right attitude through systems and some general practices. However, without the right skills, attitude alone is not enough. How do you help your teams get the skills to deliver fast?

This is about your acquisition strategy – the way you do interviews, the questions you ask, the competencies you validate for. You need to find the best approach and then use it to standardize the interview.

The standardization of the interview process for all engineers has always been important to us. All our applicants need to meet the same requirements of experience for a position. They also get the same questions and tasks. If we can’t do that, we are not fair, and we cannot assess candidates in a non-arbitrary way.

Sustainability

In a push for quicker deployments and releases, a company may become less sustainable across multiple fields. Let’s start with the technical aspects. Has Tibber ever struggled with technological debt?

It is a constant challenge. The defragmentation system I mentioned earlier helps us deal with technical debt.

As you grow and get more engineers, you are even more susceptible to fragmentation, because almost every developer likes experimenting with software.

That’s not a bad thing. Developers try to find a tool best suited for a particular problem. The technology naturally fragments in different directions that way.

Still, fragmentation slows you down. It may result in an unmaintainable codebase. To prevent that, you need a harmonizing standardization force that counters this. That’s what the defragmentation system is.

It has three buckets into which you can put in technologies you consider using. One is called: “This is the way”. Yes, we really like Star Wars. This bucket contains technological choices we all need to follow. It includes information about where we host our services or which frameworks we use for particular things. Other buckets of decision elasticity are “Golden Path” and “Squad Local”.

The goal is to not fragment a technology that is immensely expensive to break up. For example, since we use AWS, we want to make sure that our engineers host their services there. The same goes for Terraform — our infrastructure-as-code software.

The problem with technical debt is that it’s not objective. We tackle this challenge by working together to sort through different tasks and stories and tag them depending on whether we consider them technical debt or not.

It’s also my job as a CTO to make everyone see the importance of a balance between speed and technical debt. We need product-business alignment so that we don’t overwhelm our teams with technical debt when we make technical leaps.

You also need to align software delivery with security. Does the fact that you have a physical product play a part in how you approach it?

The RFC system I mentioned includes ‌security. If you try to recommend a new piece of technology, you need to cover security aspects.

We pay a lot of attention to penetration tests. That is a healthy practice to have for both hardware and software.

Going back to developer experience, it’s immensely important to include security steps as part of the CI/CD pipeline. We have various systems in place to do that. That should help the developer feel safe when they deploy or build code. That’s one of the ways we try to create an optimal environment for developers to produce their code.

For a green tech startup, a mission can also play a big part in enhancing developer experience. Tibber’s mission is to give people more power and insight into their energy usage so that they can be more energy-efficient, save money and use more renewable energy. Did the mission survive the push for efficiency and profitability?

The mission statement never changes, but at some point, becoming profitable must fit into it neatly. You can’t function in the long term if you don’t have a working business model.

At an early stage, you might have funding and a strong focus on getting your product development going and creating a product-market fit. It’s easy then for product, engineering, and R&D people to forget about commercial aspects. We need to be great at that aspect as well.

An organization’s mission goes hand in hand with work culture. Tibber’s recruitment tactics are an example of that. The company website proudly admits that your solar battery is designed in Scandinavia. It seems that Tibber is making a statement here about a Scandinavian way of working.

Do you think that your organization’s culture is very Scandinavian?

There’s a kind of humbleness about our culture. We are happy that you want to work with us. To make a change. It makes us excited. But at the same time, we don’t focus solely on our work.

A very Scandinavian thing to do is to be understanding about having children by giving the employee the time off they need to be with their family. That’s how we do things at Tibber too.

We have a lot of people in the engineering organization. As you grow, you hit a stage where you may get kids. We love that. Life is about a lot of things. Doing fulfilling work also means you need to feel fulfilled as a human being.

Resources

Can you recommend some books or courses that helped you improve your software delivery know-how on the way?

I recently read a great article from the Pragmatic Engineer about measuring developer productivity. It has tons of practical real-world examples. I would urge any CTO to read it.

What makes it particularly useful is that it differentiates between big tech companies, scaleups, and startups. Each company type has different developer productivity needs. Your approach needs to reflect that.

What’s next? Three actions for CTOs to take

What do you think about Richard’s approach to sustainable delivery and speed optimization? Would you like to bring some of the traits of Tibber’s work culture into your organization? Try this:

1. Organize periodical get-togethers

They should be designed to keep everyone up-to-date with goals and priorities for the mid- and long-term. Take inspiration from Tibber Dance Week!

2. Pick easy-to-track metrics

Being consistent is more important than being comprehensive, especially at the beginning. Find something about your delivery you can measure and improve and go for it! Tibber picked time-to-tenth commit as their easy-to-measure high-return metric. What’s yours?

3. Try a system-based approach

In your quest to build and deliver, try using systems rather than processes. Instead of providing step-by-step instructions, set boundaries and let people move freely within them to lessen overhead and promote self-reliance. Review the concept of Richard’s six engineering systems!

So do hurry up, but don’t rush it!