The 3 development efficiency problems that keep you from having an optimal setup – an interview with Brite’s Harald Walden

The CTO vs Status Quo series is about drawing attention to how CTOs challenge the current state of affairs in the company to push the business towards new heights … or to save it from doom.

Sorry, you can’t have a universal development efficiency framework 

Everyone wants easy solutions – the next great methodology or library that will make everything work as it’s supposed to. But there is none. Each company is different. And even the same company changes over time.

Harald Walden, the CTO of Brite Payments, has been in the business long enough to experience all the stages of a technology department’s growth.

He believes that the key to an optimal development setup is fostering the right attitude across three areas:

• individual responsibility of each team member,
• smart prioritization of the teams’ work,
• constant adaptability.

From today’s interview, you can expect concrete, practice-backed examples of how Harald achieves this at Brite Payments.

About Harald

Building an efficient development setup is a journey — not a destination

Jakub Piłucki: Hello Harald. I want to congratulate you on Brite’s new funding round of $60 million, with new investors Dawn Capital and Headline coming on board.

I heard that in 2024, Brite is entering a time of accelerated expansion and development?

Thank you. Brite Payments has been on a constant growth journey over the last four years, and we have grown mostly organically during that time.

But, with such an investment, we can grow at a faster pace than before. This investment will primarily help us expand our product offering into new markets. On the back of this, we will increase the number of engineers and our commercial operations across certain key markets.

Part 1 – finding the competitive advantage

Brite is no longer small. You were there in 2019, and you have seen Brite grow from five to over a hundred people.

One of our recent guests discussed product-oriented development at four stages: competitive advantage, growth, sustainability, and evolution. You’ve seen them all in the course of your career. Tell me about creating an optimal environment for developers over time, especially as a company grows.

When the team is small, it’s easy to follow everything that’s going on. When is the right moment for the CTO to abandon the desire to know it all?

There are different stages of letting go of control and knowledge of every detail.

When you have 4-5 developers, you likely have everyone in the same room. You know exactly what they work on down to the function or file they edit. More or less, the same is true for the product.

At the mid-stage of growth, a CTO can still be involved in a lot of the everyday work. I’ve always been in organizations in which the product team has been working together with engineering — even in one room. The product is physically with the team. Everyone knows what their colleagues do. This reduces project overhead as you don’t have to set up meetings to share information.

It’s also easier to get an optimal output from every person inside a team at that stage.

What’s more, from the perspective of a manager, leading such a small team is a much calmer experience. Knowing what’s going on at any moment is reassuring.

A CTO we’ve interviewed before said that when the time comes, you should not only stop supervising coding so closely but also let the team conceptualize features and competitive advantages in peace. Would you agree that developers can be more than just the people who implement stuff handed to them?

Most definitely. And I wouldn’t limit it to conceptualization alone.

I want developers to be responsible for more than just the code. I trust them with DevOps, architectural, or product decisions.

Throughout my career, I’ve hardly ever used the ‘architect’ title for a specific person. Instead, I had the team make architectural decisions. Sure, some senior developers are more likely to make them in practice, but no single person is making the decisions. This is true of both my current and previous organizations.

In my mind, the team also runs the application once it’s released. Since they took part in setting up the architecture, the team also owns the live environment. A group like that is much more comfortable running it in a live production environment.

So for me, the developers are not only the ones who write code and add product features, but also the ones testing, driving architectural decisions, and running the live service.

Usually, companies have a separate architect. Your approach feels much more democratic.

Developers have a lot of managers who want to decide what they should do and how. I’ve been a developer myself, and I know how much that can take away from the enjoyment of developing software.

I’m trying to give developers more freedom. Our product owners steer the general direction of the development, including what features to build, but how the problem should be solved is on the developers.

It seems that you’re moving towards self-managed teams. It’s a trend I’m hearing about a lot these days. And I’m happy about that. But did you also set up your IT that way because if one architect leaves the company, you could lose a lot of know-how?

That definitely adds to it. Limiting operational risk is an important job for a CTO. And having one person in hold of all the knowledge is an operational risk. For us, knowledge retention is crucial.

We’re running an on-call setup. Participants are responsible for fixing whatever problems may arise outside of office hours. The more a person knows, the easier it is for them to fix things.

Knowledge sharing is imperative to optimize knowledge retention. Participating in architectural discussions is one way that employees can acquire and exchange key project knowledge. In my experience, it adds a lot, especially for the more junior team members.

Part 2 – The growth stage

Let’s talk about the consequences of a product’s growth on the setup.

When you divide your architecture by technology, it’s not inherently product-oriented. But when you organize it by business cases, it may require constant updates when you add and remove features.

How can you release software quickly and avoid having to rewrite architecture too much?

That’s the million-dollar question.

In the prototype stage, we had a monolith. If you have 3-10 developers, working on a monolith is easy. But at some stage, you need to start to refactor – or break apart – the code into modular or microservice-like architecture to keep it manageable.

We are at the stage where we have close to 40 developers. We’re shifting from a monolith to a more microservice-like architecture to ensure that we can have more people working on different things at the same time. In a perfect world, that move would have happened slightly earlier, but from experience, I know that choosing the ideal time is never easy.

The difficulty of timing your architectural decisions also has to do with product-related development.

The product is everything at the earlier stages because if you’re not heavily funded from the start, you need to make money. At some point, as a CTO you may be asked what would be the return on investment for rewriting the architecture. And the answer is usually: none for right now. So when you weigh a product-driven initiative against “none”, the choice is obvious.

But at some point, you need to take that leap. Deciding to rewrite your architecture is hard because you step in as the CTO to tell a management team something along the lines of: “My priorities are now more important than yours”. 

Finding the right balance between growing your product and optimizing the code will always be challenging. Because, again, if the business is not succeeding, the most perfect architecture in the world is no help.

What about changing the structure of the team? How has it changed since Brite was a small company? Was it more cross-functional then or now?

Being a CTO when the engineering department has five people is completely different from running a team of 50-100. At first, every team member must be able to do everything. But people start to specialize over time.

At Brite, groups of people are doing similar things in their own smaller teams. Some people work on incoming payments, while others work on business-to-consumer payments – sometimes called payouts, or withdrawals. So, we have structured the teams by product-related divisions rather than technical ones.

This product-related division came to life quite naturally for us. For example, we resisted splitting into a frontend and backend team because our work is very backend-heavy.

It seems that you’re a fan of smaller, semi-independent teams.

The bigger the team is, the more overhead there is.

Over the last four years, we’ve gone from one to two teams to six. We’re continuously discussing where to make the next split, so our teams do not become too big.

What about a situation where you enter a new market. So far, Brite has entered some new markets every year. What steps do you take to prepare your teams in advance?

Luckily, we don’t need to reinvent the wheel.

The product discovery phase is mostly done within the product’s organization. They help us with the differences from one market to another. Technically, it’s not too big of a mountain to conquer.

The main challenge is having enough engineers to maintain existing markets while getting enough people to build for a new market without compromising quality.

Natural leaders may develop themselves at this team stage to help with those challenges. Who gets to be the team lead at Brite and why?

We have two different types of engineering managers at Brite. There are informal leaders and formal leaders. Both groups include people who have developed organically in our organization and those who joined as managers.

Earlier in my career, I made the mistake of always promoting the informal leader into a formal role, which can bring mixed results. In some cases, it worked well, but I also saw it fail.

It’s unfortunate to see a good developer and an informal leader being promoted and then not succeeding as a formal one. You need to think carefully before making such a decision. Not everyone is a born leader or enjoys being one.

It’s not about technical knowledge, as there shouldn’t be a deficit on that side. It’s the other aspects of being a manager, which you might not think of when you’re a developer and only focused on development.

Our previous guests also talked about processes they introduced to keep the setup efficient at this stage, including those that fall under various shades of Agile and Scrum or Shape Up. What processes have helped you scale your teams?

I also leave some of the processes for the teams to choose.

I’ve been in fast-growing companies in the past. I learned that if the manager or the CTO needs to be involved in every single issue, then they restrain themselves as well as the growth of that company.

Currently, out of the six teams we have, five of them run a version of Scrum, and one runs a version of Kanban. Each team is empowered to say: “For us, this doesn’t really work. Can we test something else?”.

As long as the team delivers the value, the actual way of delivering that value is less important to me.

I’ve already talked to a couple of Swedish CTOs. It seems that their qualities — such as a democratic approach to problem-solving and individual adaptability — are important for them, so the concept of self-managed teams comes naturally. 

Then again, some criticized the majority vote as one that welcomes people who are not experts or simply don’t care or own a given problem.

Would you say that Brite’s culture is particularly Swedish?

We might be Swedish in how we work. Then again, maybe the tech scene here is relatively small, so many of us know each other from before and work similarly.

I think that our culture welcomes people who want to be involved in discussions. At the same time, we never force the entire company or team to be part of such discussions. If you’re interested in a specific topic and have the knowledge, then it’s more natural for you to be a part of it. We have developers who aren’t as involved because they care more about their code.

If having a dedicated architect or forcing everybody to give their opinion represent two ends of a spectrum, then Brite is somewhere in between. Professionals who are personally invested in a matter and have the right knowledge tend to participate in decision-making.

Also, engineering managers at Brite moderate such architectural forums. That’s part of the engineering manager’s role description.

Does Brite Payments sound intriguing? See if there’s a role for you here.

Part 3 – The sustainability stage

When the architecture and product grow, IT may start accumulating technological debt. Considering the high-velocity nature of fintech startups, companies like yours are at an even bigger risk. Did your teams ever struggle with that?

Every team struggles with that to an extent.

In my experience, technical debt often follows when an important teammate leaves. Typically, organizations have some kind of system or library that a person has a very good knowledge of, and they depend too heavily on that isolated know-how.

At Brite, we have been fortunate to have very low employee turnover. It means we haven’t lost competencies in key parts of the application. Therefore, we’ve not amassed much technical debt in that area.

Time is another important factor in terms of collecting technical debt. Speed is another one. These two intersect. The faster you move, the more likely you add technical debt to the product. You have less time to refactor code that was written quickly and pushed to production. 

I asked that because I heard some startup CTOs think that cutting corners in the name of faster development is fine, especially early on. Brite, which prides itself on security and dependability, may have a different approach. If you can’t compromise on code quality, where can you save time to keep development efficient?

Not handing stuff over between different departments has a big impact.

I came across companies where one set of people developed code. Then, they handed the code to a different group to test it. Then, the testers moved it to a third group that deployed it. Then, a fourth group ran the code in production. In a setup like this, you don’t have the accountability factor because there’s always someone to blame things on.

Cutting corners by giving everyone full ownership of what they do can also save time, and that works for small and mid-sized companies. It’s different for larger companies depending on the architecture.

I was in the computer games industry previously. There, you can cut a lot of corners on the way from development to production. But when you run a financial institution, that is simply not an option.

Often, it’s the CTO who pushes for code quality, while the CPO pushes for faster releases. Some companies choose to combine these roles in one as CTPO. How does it work at Brite, and what do you think about the CTPO role as a CTO who has also held the Head of Product position before?

We have two completely separate entities – a CPO and a CTO. However, a lot of what we do intertwines. At times, we act like one department. Around 90% of the meetings are a combination of product and engineering-related matters.

From my perspective, having a product expert and a more technically-minded CTO separately works well. If you can afford to have these two different departments, I’d vote for such a solution.

If you combine the CTO and CPO roles, a person would still need a lot of technical knowledge. A CTPO would typically be a person with a technical background who has learned the product side of things rather than the opposite.

But I suppose that, as the organization grows larger, even a separate CTO and CPO can’t afford to delve too deeply into day-to-day work.

Within our organization, we have engineering managers and product owners. They are the ones running the actual teams and day-to-day business.

Engineering managers are the ones answering the question: “How”? They moderate discussions on the matter. And there are product owners who define what problems to solve. 

As a CTO, my job in all of this is to try to advocate for developers and ensure a good working relationship with the engineering managers and product owners.

From my experience, I know how hard it can be for a developer to prioritize between what the sales manager, marketing manager, or product manager tells them to do. Narrowing down the interface between engineers and the rest of the organization is very important to me.

Brite has many developers from different corners of the world onboard. This may be a good moment to ask about your attitude toward remote work. I know you have a tech hub in Málaga. Is having a distributed team now an integral part of your work culture?

Brite is only a little over four years old, so half of the company’s history took place during the pandemic. We had different restrictions in different countries, but even so, during the pandemic, most people in IT worked from home.

When the pandemic ended, developers still commonly requested to work remotely in the interview process.

From my perspective, I focus on the results and deliverables. Whether my developers work from home or the office doesn’t matter, but there are caveats. The one area that suffers the most is the brainstorming meetings. I miss the brainstorming sessions with a whiteboard where everyone can actively participate.

However, other meetings work fine. One-on-ones work completely fine; coding works fine. It also works well if you have meetings where one person speaks and the rest listens.

Remote work also has other benefits for developers. They can just put headphones on and look at their code without having to switch contexts and respond to external interferences. In the office, you will more likely be disturbed at some point during the day. Overall, the pros seem to outweigh the cons, so I fully support a remote or partially remote setup.

That said, our tech hub in Málaga provides a fantastic work environment for our teams and has grown to include many non-tech roles, too.

Part 4 – The evolution stage

Brite Payments has grown a lot since you joined, and with that came a lot of big technical changes. How do you introduce big projects to your developers? Are they happy when something entirely new comes up? 

I like to inform people what’s about to happen. Being transparent with the team is important at an early stage. This gives them some time to get used to the situation so they can start thinking about how to tackle it.

This extra time is very important since we have a somewhat distributed architectural forum. As a big group, we prefer not to rush decisions.

If you want to modify your tech stack or need an expert in a new field, like AI, do you start with hiring/outsourcing or searching for the capabilities within your teams?

Our engineering managers are responsible for making sure that we have the right people in a team to solve the problems that the product owners put forward. How we solve it depends on the situation.

Strategically, I don’t use consultants to build the product in the long term, but they can be highly beneficial for injecting new knowledge and getting experts on board to share their insights.

You are an experienced fintech manager. Naturally, a lot of your insights and examples are informed by your background. But what do you think are the most widely applicable steps that any CTO can take to create an efficient development team?

Three aspects come to mind.

• Protecting developers from being overwhelmed by multiple people trying to tell them what to do. The frustration of not getting a clear message about what to work on can demoralize developers quickly.
• Not getting fixated on a specific “best practice” solution to a problem. I was in the gaming industry before and saw first-hand that some solutions may work great in one context and fail in another. And failures can be costly long-term. I like to say that I don’t always know how to solve something, but at least I know how not to solve it.
• Recruiting people smarter than yourself. If you are the smartest person in the room, it might be the wrong room. I think what’s best for the company is when you have experts or people smarter than you in the areas that they specialize in.

Part 5 – Resources

We also ask about books and other resources that could help expand the points made in the interviews. Was there something in particular that helped shape your mindset?

I am listening to the Darknet Diaries. That’s currently my go-to podcast for understanding or widening my knowledge on security-related topics.

If you’re interested in security at any level, you can get some unique stories from it. Not everything can be easily applied to everyday work. But there are always these bits and pieces that will add to your overall knowledge in the security field. And it’s well worth doing because being a CTO is about much more than just development.

Speaking more generally about this issue, I strongly believe in continuous learning and growth in people.

So many new leaders read one management book and believe that’s all there is to it. While the book may very well be valuable, I think the experience and education together make a difference.

I had a saying at a former company: “If you learned something new, you can leave for the day.” Then, I had to change it to: “You need to learn something that the company could benefit from.” I don’t mean that quite literally. But I wanted to emphasize how important it was for the company that people grow.

That’s the idea. As for the content, any source is good. A book, a YouTube video, a lab project for testing things out, or a colleague who knows more.

What’s next? Three actions for CTOs to take

What do you think about Harald’s experience with building efficient development departments across different stages of an organization’s growth?

If you also want to move towards a development setup that’s tailor-made for the needs and sensibilities of your company, try this:

1. Promote responsibility – every developer should feel a sense of ownership of the code/features they work on. Let them work with it across the development cycle.
2. Foster prioritization – never let developers have doubts about who to listen to. Protect them from groups of interest and be a proper intermediary between them and the rest of the business.
3. Encourage adaptability – don’t be a one-trick pony. A framework or book can be useful, but it’s nothing without experience. Use the available resources to develop your own style.