5 Secrets to Leading a High-Performance Distributed Team

Introduction

Before I start, I just wanted to get an idea about the audience. How many of you have experience working with distributed teams? That’s most of you. So then hopefully what I'm saying will not come as a total shock. Hopefully, you have experienced some of these things yourself.

So, I was asked to share some of my experiences when it comes to leading high-performance distributed teams. And this is something that I have been working with for quite some time. A little bit about myself. I'm currently working in Compello. I've been here nearly seven years now and today I'm responsible for our product strategy and roadmap, and I also manage our DevOps teams.

Experience engaging with offshore teams

I have been working with distributed teams for quite some time. I started with that back in 1999. We were under time pressure to deliver a new product to a big insurance company in Norway and we didn't have sufficient capacity in our local team in Oslo to do that within the time frame. So, we said, okay, we need to get some additional resources on this. And by chance, we came across an offshore company in India based in Bangalore and we said, okay, we have little to lose, let's try this out.

It was a complete disaster because we hadn't done our due diligence. So, we didn't know what that team required to work efficiently with us, and we didn't know how we needed to structure things in order for that team to work efficiently with us. It was a very, very expensive learning experience. I would say we managed to deliver the product, but it ended up that we had to send some of our most senior developers from Oslo to India, to sit together with the team to transfer domain knowledge and do code reviews and everything.

There was a big cultural misfit or gap at the time. I was visiting the team and when I came into the room where we had the developers, they all came to my attention almost like I was a general inspecting the troops, and whatever I asked them, the answer was always ‘yes’.

If we were a little bit unclear when we wrote the specification for a user story, you could be pretty sure that they would do the literal interpretation because they didn't question us, the client. If we wrote something a little bit unclear, the chance was that it was implemented the wrong way, and they had to go back and redo it. That was because their culture was not to question the client. And our culture was not so precise because we were used to working with Norwegian developers, the type that if they saw something strange, they came to you and said, “Are you stupid?”.

So, I learned a lot from that experience. And I said, never again am I going to do it this way. Since then, I've been lucky in that I've been working with teams in many different geographies. I was, for a period, Director of Engineering in Itslearning, which is a learning platform that a lot of you who are parents have some type of relationship with. At Itslearning, we had teams in Russia, Romania, Poland, the USA, the Netherlands and Norway. I was working with 24 different scrum teams across these geographies. That was a good experience in terms of how to manage different geographies, different cultures, different requirements, to the level of detail you have to give the teams for them to operate effectively. Based on my experience, I got a philosophy of how to set up and work with distributed teams, that I have never left.

Relationship with 99x and role at Compello

I have actually been working with 99x for quite some time. I was working at a Norwegian company called Adra Match at the time, now Trintech. In 2011 we set up our first team with 99x. We ran a workshop here in Oslo in August 2011. That was the start of my collaboration with 99x.

Today, I'm working with 99x in Compello. Compello is a Norwegian software company, part of the Visma Group. We basically develop services for simplified invoice handling and intelligent accounting. We have more than 6,000 companies using our solutions with nearly 23,000 users. Our message to the market is that we help businesses save time and cost by automating their incoming invoices. We work together with 99x to do this.

Automation – our North Star metric

We have this guiding principle, what we call our North Star metric and that is automation. Our goal is that across our customer base, we should automate 90% of the supplier invoices you process in your business by 2028. Today, across our customer base, the average automation rate is about 73%. When we started this year, it was at 67%. Next year, we hope by the end of 2025, we hope to reach 80% across our customer base. Having this North Star metric, it's actually a very powerful tool towards the team also because it makes sure that we focus our efforts and measure the efficiency of the things we do towards a very simple-to-understand goal. And that's important.

When you have some simple-to-understand goals, then the team can rally around and understand and see this is what creates value for our customers, this is what we should focus on. So, today I will talk about five different things when you manage these types of distributed teams.

 

#1 Communication is key – get to know each other

I could have spent hours on this and I could probably put up 20 factors, but if I wanted to pick up one that I think is most important, based on all my experience, it is communication, it is getting to know each other. Because even though engineers, and software engineers, tend to be more introverted than extroverts, most of all we still are people, we are cultural beings, we are social animals and for us to work productively together, we need to know each other a little bit, we need to be able to trust each other, we need to understand each other's culture.

Invest in travel – no substitute

So, for me, I've always insisted when I started working in a new software company that unless we are willing to invest in actually travelling, meeting each other, and building personal relationships, I don't think we will succeed. So that's really important! I believe that you need to visit each other regularly, especially in the beginning, either at the beginning of the engagement with a new team or when you're starting a new project. Even though virtual arenas work very well when a team is well established, you can’t do that in the beginning, when you need to build that trust, build that understanding, build that domain knowledge, nothing can replace those personal interactions that you get. There are also things that happen after work, you're going out, sharing a meal together, doing some activities, I think that is key in building a high-performing team.

The reason why I chose this picture is because I've been working with 99x teams mainly based in Colombo since the fall of 2011. So that basically means in 11 of the last 13 years, I've been working with teams in 99x. During those 11 years, I have visited Sri Lanka 14 times. It will be 15 times when I visit in January 2025. Through the years, I have stayed 15 weeks in this hotel – the Cinnamon Grand. So that’s nearly four months I spent there. When I come, they greet me by name in the reception. The guy at the door welcomes me back. It almost becomes a home away from home from it while I'm there. I'm fully convinced that we would never have achieved the results we have done together with our teams if we hadn't invested the time to visit each other.

Engage and connect informally

Aside from that, of course, when you have established relationships, you must maintain them. Of course, you need to use tools like Slack or Teams or whatever to make it easy to keep communication going. Also consider the informal one-on-ones during the day, not only during your formal standups and other things. I encourage people to activate their cameras, even though it might be when you're working from home office, you're not shaved today, maybe not even brushed your hair. It's so much easier to have that relationship if you also activate your cameras,and look at each other in the eye.

Take an interest in those you work with

What is also so important is to take an interest in the people you work with. When we talk about our team in Colombo, it's not us and them, it's we. Earlier, where our team sat, you had to go up the stairs and on top, there was a big Compello logo. They identified with our company; we identified with them, and we took an interest in each other. When someone in the team has a birthday, we recognize that. If someone is having a loss in the family, we recognize that just like you would do with a colleague in your office. We take the same interest in the people remotely as we take in the interest of the people that we sit next to in our own office.

Also, of course, we need to be aware of and recognize each other's cultural differences and that is different from each geography I've been working with teams in. It's very different. I had quite a few teams in St Petersburg, Russia for a few years. They were really good engineers. But for us as Norwegians, they came across as almost arrogant in their approach. You have to take another approach when you work with those things because the things they valued were like precision, it was engineering rigidity, quality, and structure.

So, if you came with a little bit of traditional Norwegian, wishy-washy approach, you would not be respected by those teams. You had to adapt your style towards those themes to get the best results. But when you did that, you got amazing results because you recognized that this was a little bit different culture and we had to adapt to work with that culture. That is the same wherever you go and do work with distributed teams.

Cultural adaptation – a strength of 99x

I think this is something that 99x has been quite good at because traditional Asian culture is quite hierarchical and in many Asian countries it's quite difficult to say ‘no’ to someone who is higher in the hierarchy or question someone who is higher in the hierarchy. That's actually something that distinguishes 99x from all the companies I've been working within Asia. 99x is probably the one that is most like what it is to work inside a Norwegian software company. They spend a lot of time building a culture inside 99x where they encourage people to speak up, to contribute and to question, and not just silently accept everything.

Be patient and allow people to adapt

We can see that when we get new team members in, it takes some time for them before they get comfortable in that environment. When we have someone new coming into the team, it will take some months before they really are able to speak up in a standup or do things like that. But since there is already a culture like that internally, over time they grow more comfortable with it and do that.

Feedback – a two-way street

I think it's very important that you have regular feedback mechanisms to get input from your team so that you can continuously improve your process. Feedback should not be a one-way street that is always initiated from you here in Norway. It should come just as much from the remote team that you're working with.

 

#2 – Build trust and accountability

Building trust and accountability is also very important. What I strongly believe in is that you have to be transparent about your strategy, where you're going, and why you're going there, with your teams.

Communicate your strategy

At Compello, we try to visit at least once a year and when we visit, we always have a session where we go through not only what we plan to do with the product that year, but the overall company strategy with the whole team, including our financial goals, what our target customer base looks like, just like you would do in a strategy session for your own employees in your local office.

We try to go through that in quite detail, just so that everyone understands why we want to achieve these goals, and why we focus, for instance, on this area of the product for the next 12 months. We wanted our distributed team to understand the context because these are highly qualified, skilled people who want to know. Working with highly qualified people everywhere is that they really want to understand why, to get the best results. You must give them that opportunity to understand why.

Define roles and responsibilities clearly

You must define roles, and responsibilities and make sure that everyone knows what those are. So, for instance, we use Confluence as our team wiki and we have a very clear page on what the team structure is, what their roles are, what our responsibilities are under each role and so on. Everyone needs to understand that.

Use objective measures to assess performance

Next, you need to try to use objective metrics to assess performance which is typically quite difficult in an engineering world. That's why I'm quite excited about new tools like Flowyzer. We're also using some other metric tools inside to measure engineering performance.

Distribute types of work fairly

Another area I would say that is extremely important is to distribute types of work fairly, especially if you have a team where you have some developers locally and some developers remotely. If you choose to place all the boring work on your remote workers and keep all the exciting new stuff for your own developers, you can be pretty sure you will have a very high transition rate in your remote team. Why? If you want to have good skilled developers in a team, and if they only get routine, boring work, they will not want to stay in your team for very long and you will not get the best performance from your team. So, distribute work fairly.

You can try to set up teams that combine resources from your locations. That's always like a tradeoff though, because I think there's some studies saying that as soon as you increase the distance by more than like seven meters, the communication overhead increases quite a lot. So, there are advantages of having teams in most roles together, but when you work distributedly, I also believe that there is a benefit in mixing people a little bit across geographies as well.

 

#3 – Set clear objectives and goals

You need to have a way of tracking progress to know if are you on track with what you want to achieve. Because that's also important for your remote team. They want to understand, whether Are we succeeding or not? How can we know if we are succeeding? Implement some measures and goals that can help the team understand if we are going in the right direction. That also helps with the level of motivation and efficiency in the teams.

 

#4 – Leverage technology

Of course, you need to leverage technology. I think that's important, especially if you're establishing distributed teams for the first time. Look at the set of tools you are currently using. Do they support working in a distributed way? Do the tools foster transparency and collaboration? Is that working well for you? Also, ensure that those tools are well integrated so that you can streamline your workloads and avoid any information silos. You don't want that, especially if you are aiming to become a first-class engineering organization and you want to move towards continuous delivery, high frequency of releases, and moving quickly in the market. It is important that the set of tools you use contributes towards that.

I would also say today it would be almost negligent to set up a team and not provide them with tools that they can use to improve individual developer productivity. For instance, we have distributed GitHub Copilot to all our developers across all our geographies, which is integrated into our toolchains. That basically means that you can more quickly, for instance, generate unit tests because you can get AI help to do that based on the code. You can get help to create a lot of routine work, what you call template code that you always have to create. AI tools can help you do a lot of that so that then your developer can spend more of their time on the actual value creation and try to build a culture of continuous learning and improvement.

 

#5 – Build a culture of continuous learning and improvement

When you think about learning, don't just think about that your own employees should be able to develop and learn. Think about that, your whole team needs to be able to develop and learn. That of course does not necessarily mean that you should pay for conferences for your remote employees, but you should make sure that the partner that you're working with, that they have good programs for their employees to develop and learn and that you can learn from each other.

Also, encourage exploration and make it safe to fail in your teams. I think that's very important to improve. You need to explore and when sometimes it doesn't work, you need to say, okay. You have this like in old engineering, right? Fail fast. So, make that safe and encourage people to do some exploration and then share knowledge. This should go across any geographical and team workers.