Many projects are carried out in a customer-supplier model. That’s when the customer orders an eCommerce platform or other application, and the software house delivers it. However, agencies are often part of a larger software development team structure. I’d like to discuss the psychological aspect of this type of cooperation, including opportunities and threats.
To answer the question posed in the title in one word: no. The cooperation of two companies on one project can’t work perfectly. My subjective opinion is that there’s no ideal way to do it. We should strive for it, but be aware that we’re only human and make mistakes. The key is to be mindful of them.
By presenting a case study of one project, I’d like to show what we can do and think about to make cooperation effective and efficient from the beginning.
A case study on how bias can undermine cooperation
Why am I talking about the cooperation between two companies on one project in this article? From the beginning of my work at Divante, since 2017, I’ve constantly been working with one of our clients. Only a year after my participation in the project started, the client hired the first developer on their side. This had a significant impact on the dynamics of the team’s work together.
A small shift of power leads to anxiety
As a project leader, I became concerned about the project’s future. My role back then didn't involve taking long-term responsibility for projects. Today, after a few years, it’s the opposite. I take this responsibility, but I don’t worry about the future of projects with developers from two sides. I’m not afraid of situations where the client takes over the role of an agency as the project's contractor.
However, four years ago, I had cause for concern. My team was worried about the prospect that they wouldn’t be the most important group in doing their job. We felt insecure that the client would have the tools to monitor our work effectively. We were afraid that the client, having specialists on their side, would be more demanding.
Verifying concerns
The time came when the client, after the first developer, hired a second, then another, and then two more. This gave us a great opportunity to verify our concerns. They turned out to be very accurate.
The client had become more demanding. They started checking and verifying our work. They had the tools to check our work and skills efficiently. A "new" project leader appeared on the client’s side even though the project leadership belonged to us. We were responsible for the execution of the project. But then, we weren’t alone and didn’t feel OK with that.
Well done. We verified our concerns and could pat ourselves on the back because our experience and perspective made us predict the project's future. It’s precious to be able to look ahead in a programming project. Few programmers have this skill. We thought we were able to anticipate problems since we were experts. Paradoxically, there wasn’t any problem.
What didn’t we foresee?
I know that hardly anyone remembers those times, but once, before the COVID-19 pandemic, not every company had a remote-first approach. In our project, we had scrum planning once a week. Meetings were held at our office, regardless of whether there were two or three stakeholders on the client's side or even the entire development team. So, we could feel the consequences firsthand and not virtually. Conflicts began to arise. Developers reading this article will think about code conflicts in areas where we work with the client, but it was about real conflicts where we argued over technical solutions. Usually, both proposed solutions were good.
Unthinkable inside our local team, a deep division and inability to communicate emerged between "our" and "their" developers. There was a huge difference between them. I don't want to speak for the client's team, but I believe they saw it similarly. We were quick to embrace our tribe mentality.
The actual cause of our fears and the positive consequences of increasing the team’s size
There was probably only one reason for our concern: immaturity. I could finish the topic here, but I owe you an explanation.
The enlargement of the team wasn’t based on the client’s lack of trust. We were simply unaware of this, so it affected our attitude more than it should have. Once we stopped for a moment to challenge that assumption, rethink our bias, and remind ourselves that we were playing for one goal, our division started to fade.
After hiring developers on the client's side, so much changed that the team grew so we could carry out tasks from the backlog faster. It wasn’t the client who gained an additional tool to verify our work, but we, as one development team, gained a tool to influence the business and present the technical perspective.
I emphasize that the number of teams didn’t increase. There’s a willful logical error in the article's title because it should start with "Cooperation of an in-house software development team with an agency’s team." There’s one team and one project. There’s an opportunity and not a threat.
Did we make a mistake?
We didn't make such a big mistake. We learn all our lives, so we learned this time as well. We learned maturity, cooperation, and about the joint pursuit of the same goal. When we increase the size of the team, we sometimes look for candidates together, conduct recruitment interviews with them, and decide on hiring. Does it matter whether the developer has the name of this or that company in the contract? Does it matter what the name of the company is above the entrance to the building where they work? No, because we have the same goal, and most of us work remotely. You know what I mean, right?
Food for thought
We learned a lot from this cooperation between companies. If your team struggles in a similar situation, ask yourselves these questions:
- If you’re afraid that the developer on the client's side will watch how you handle your job, why aren’t you afraid of the usual code review from a colleague in the same company? Maybe you’re doing code reviews unfairly.
- If you’re afraid that the client won’t trust you, you might be doing something dishonestly. Maybe you’re not exercising due diligence?
- If you’re arguing about which framework is better, maybe you don't know enough about that? It’s possible that you can’t objectively evaluate it and make a professional determination.
- If you don’t want to play on one team only because you’re afraid of a conflict of interest and the disturbance of the role of the customer and the supplier, maybe you aren’t ready for this type of cooperation?
Heads up. We weren’t born omniscient and experienced, so if we have these types of thoughts, it’s normal. The key to success is positive thinking, professionalism, and maturity.
At the end
The real world isn’t as binary as writing data to a hard drive, even an SSD. The customer-supplier relationship isn’t always firmly separated. On top of that, we’ll work in mixed teams more and more often in the future. So, we need to learn to pursue common goals and cooperate beyond divisions just as we need to keep getting more and more mature.
Published October 12, 2022
