The fallacy of multi-vendor teams

Bring the Guardians of the galaxy and lego-city together and it won't end well

Digital transformation is a fact. And it changes our lives with an incredible speed, leading to an enormous lack of expertise in your companies and every other company around the planet.

It leaves your employees in a state of constant learning while being asked to fulfil their core business. And when a true innovation comes, like agile, like CI/CD, like cloud, like machine learning (though technically that one has been around for longer than me), it might not be possible to seek that direction with the people you have inside your company. And that’s when someone like me comes in.

An external consultant.

But I’m from an external company—an expensive one. And even though we claim to create value and help your company which makes the investment worth it, you probably will not start this relationship with blind trust in this one company, but think about strategies to ensure that if this relationship fails, your company will not.

You will start thinking about the risks. One risk you will identify early is expertise and staffing. Do you want to make your delivery dependent on this one contractor’s ability to provide qualified people? Do you want all the important things you are working on in the hands of a single company? Won’t we give this vendor too much power to negotiate contracts when they know we depend on them? Should we use this also to be cost-effective and have the leverage to negotiate them down?

So after some time, you conclude to bring in another vendor for another project. And everything continues just fine. Then one of the vendors can’t fully staff one of your product delivery teams. You congratulate yourself for your predictive powers and put some people from the other vendor in this team. And then the same thing happens to the other vendor, and you bring in a third vendor.

And eventually, things get worse.

While you do have some leverage on the negotiations for new contracts, it’s not that much. On the other hand, your administrative invest gets up because you have to manage multiple contracts. As the vendors send in more and more people, they will have to establish an account leadership to keep their people happy. All of this will be a driver for costs, and eventually, this setup becomes more expensive than a single vendor.

Those downsides would be fine if the teams would be delivering, but they are not. There are conflicts, quality issues, delivery issues. In a nutshell, those teams are not successful.

What happened?

Focusing on business risks, you completely neglected the fact that those are people, and for them to be successful, there will be many things that have to be considered: trust, a shared culture, team building, and a standard set of principles. There’s science actively working against you.

Let’s take a look at the why.

In her essay “Psychological Safety and Learning Behavior in Work Teams”, Amy Edmondson highlighted how important a foundation of psychological safety is for teams to foster a learning culture that allows for high performing teams.

Team Performance, based on psychological safety, fostering learning behaviour

Team Performance, based on psychological safety, fostering learning behaviour

But what is it that makes those teams fail? Amy Edmondson focusses strongly on leadership behaviour, but how is that misaligned here?

One of the points is that those teams lack a leader. Even if you have a leadership figure coming from your organisation, the reality is that the people in those teams can not depend on this person for their own personal development. Their performance will be measured by their own company, promoting and raising people on their terms, not yours. This is manageable if you have one vendor in a team; it gets more difficult if you have multiple. The reason is that those vendors come with a unique value proposition for both you and their employees. Based on your original goals (which included costs), it might be that one of them is cheaper and thus more cost-sensitive, whereas the other might be focused on specific ways of working. For the cost-sensitive, it’s essential to make sure their people can deliver fast and quickly and tend to create solutions that are closer to prototypes. For the other, quality might be one of the core drivers—a classic clash of goals.

Another example is combining vendors that identify themselves as consultancies who want to work with your company to grow the product, while others come in as coders, wishing to focus on getting stories that they can crunch. Combining those two mindsets is merely impossible and will lead to conflicts.

While in traditional management, that might have been seen as competition that improves the overall product, reality shows that this will reduce the team’s trust and have people working together fight over topics or hide what they are doing. As a result, team performance will drop.

There are cases when this will work. Imaging you need a team that needs strong Embedded, Mobile, XD and Cloud knowledge for an IoT Product you want to create. If no single vendor can provide all the knowledge required, you can staff them following your products; one vendor for Mobile and XD, another one for Embedded and Cloud. But if you haven’t carefully selected the vendors for a cultural and value match, make sure that they don’t have to interact other than on high-level contracts like APIs or Epic-alignments in their daily work.

Even when the goals are closely aligned, more storming phases in your team will be inevitable, as described by Tuckman’s stages of group development, as the teams will run through identical sequences. Tuckman has observed that teams will inevitably run through the same phases and must overcome them to advance the next. The first is forming, a relatively superficial stage that people use to arrive. Once people start feeling more comfortable, conflicts will begin to pop up as they will try to set their mark, struggle for influence in the group and try to create their space. That’s the storming phase. Finally, out of the spirit to cooperate, the norming phase evolves and will soon be replaced by performing as the final stage.

However, due to the contractual situation, getting out of the storming phase will be far more complicated, and there are multiple reasons for that.

First, assignment in teams for contractors is usually timeboxed. Having people for too long and driving the solution can lead to hidden Arbeitnehmerüberlassung in Germany, which means breaking the law. To avoid getting sued, they are rotated. For the vendors, rotation is beneficial as well, as it results in knowledge spread in the company and satisfying the need for variety that people who get hired as consultants usually have.

On the other hand, rotations will lead to this cycle repeat itself over and over again. A single vendor mitigates this issue by hiring people that are naturally fitting. There is a saying that consultants come in packs that all look the same, and that’s precisely the secret that allows for constant rotations. Even if a person is getting replaced, the new one will know their place and storming will be much shorter. By bringing in multiple vendors, this system is broken.

Secondly, the team will probably not be very balanced. No consultancy will want to afford to send immature people in teams driven by other consultancies, as they run the risk those people would no longer be compatible with the culture in their company, thus making rotations harder. This will result in multiple, strong-minded personalities in the teams that will do their best to implement their way of doing things, ending up in a constant battle with the other contractors' seniors.

And finally, they may lack the motivation to go into a cooperation mode, as the impact of not doing so is small. After a few months, they will probably not see each other again, so why bother?

Even more common and worse, though, are teams that never even get to the storming phase. They end up in an endless forming phase, without developing enough trust to speak up or not caring enough to do so. And the team will never deliver on levels you will need of them. They can be easily identified by being very silent, not really caring for their product, and while they won’t hinder any changes or new ideas coming to the product, they won’t fully support them either.

It’s probably one of the most dangerous situations for your team to be in, as it will not perform, not improve, but work just well enough, so you don’t really notice until you start missing all the commitments the team had set. The stress the team will be exposed to due to the missed commitments will only strengthen the current status quo, as speaking up (and thus entering the storming phase) might become another delivery risk linked back to this very person.

What is it that you should do then?

Don’t put people from multiple vendors into one team if you can avoid it. There might be good reasons to do so, for instance, because its a specialised technology project, and no single vendor can provide an entire team. If you want to have multiple vendors in your company, split them by team. This will allow you not to be dependent on a single vendor while not putting the teams at risk of ending up in an endless storming phase.

However, none of this truly helped you with the issue you had initially - getting something new into your company that you couldn’t start because you lacked knowledge. Thus, the most important advice I want to give you is the following:

Choose wisely when and where to use external contractors. And use them to upskill your own people. Rather than mitigating risks by combining multiple contractors, choose consultancies that match your culture and bring values you want to strengthen and add your workforce to the teams.

By choosing by culture rather than a price tag, rotations will lead to quicker team cycles and avoid ending up in storming phases.

Define clear goals on why and for what you have the vendor. Align with their leadership team to ensure you know what targets their employees have and be conscious of their impact on your team.

In the end, bringing in an external company into your own to solve a complex problem will come with its complexities, as after all, what you do is bringing different social groups together. It’s one of those issues where your foremost thought should probably not be about cost-efficiency.

Consequently, given you - rather than mitigating the risk of a failing vendor by adding more vendors - upskilled your own people, the relief if something goes wrong will be embedded in the one thing that you can always rely on - your own company.

[1] Edmondson, Amy (1999). “Psychological Safety and Learning Behavior in Work Teams”

[2] Tuckman, Bruce (1965). “Developmental sequence in small groups”.

All pictures by Matthias Kainer, and available under Creative Commons Attribution 4.0 International (CC BY 4.0)