War and Peace: How to make it work between Business and Tech teams?

What is the common point between all the ventures I have worked for?

Constant frictions, frustrations, if not anger between the Business and Tech teams.

It is quite common indeed to see 2 “startups” within one startup: the Business side and the Tech side. By Business side, I mean the Sales, Operations, Marketing, Customer Support people who are in charge of acquiring clients and run the daily operations. By Tech side, I refer to all the dev, product, engineer people who are in charge of building the technical aspect and ensuring the product is working fine and constantly evolving.

I felt this frustration from my very first Rocket startup. At the time I joined it, it was still a pretty small team so I knew everyone quite well both on the business and tech side. As an Expansion Manager, I was travelling in all the new cities we were launching to build the local team on the ground and ensure brand awareness and client acquisition activities (offline marketing, partnerships). In such a position, I was front row to notice some product bugs and request new product features as I was in constant communication with clients, potential or acquired, who were telling me what was working well / not working / could be improved or added.

I was then lucky enough to have quite a direct communication with my CTO and tech team that I knew well. I could simply send them a Skype message to let them know about any feedback I had. They were very happy to hear from me and being able to get a feeling of how the product was used in different cities of the world through me.

I thought it was an ideal situation but looking back at it, it was far from being ideal — as I was constantly bugging the tech team with my requests / ideas in an unorganised way and had no way to track the implementation of whatever I was asking for.

It was a way to make it work in a setting where there was limited team members and early stage business, but I learnt later on that one could not scale a venture like this.

And my learning about this happened quite fast after — when I joined a couple of months later my third and last Rocket Internet venture as Global Head of Operations, in charge of making sure that daily operations were smooth and constantly optimised.

I joined in a context that was not the easiest — we had just migrated from one tech backend to another, and this was coming with many “bugs” and issues as it often happens in these cases. There was a lot of confusion about how the product was working and integrated to diverse operational tools we were using (Stripe, etc) and it triggered numerous issues for the Business teams who had to handle angry customers and PR people using a broken system.

It also triggered a lot of manual work for the Operations and Customer Support teams I was managing as some automations were not correctly set up and needed to be constantly QAed on our side to make sure the front end was not affected. We were running many key processes out of google sheets and the Customer Support team was overloaded by clients complaining they got charged too much or were misled by our website.

The frustration of my team was very palpable and hard to contain. From the first day, I organised 1:1 with all of them and they unanimously put the blame on the tech teams who were simply not doing the job.

It was my first role in Operations but I understood straight away how Operations and Tech are linked and I decided to go talk to the Tech team to get their view of the situation.

They were sitting in another office where I went to spend the day with them.

Their view was basically opposite to what I heard from the Business teams — they complained they could not work properly on fixing the platform and ensuring its long-term success because they were constantly bugged by useless requests from the Business team.

This very tense situation made me learn fundamental stuff about how to handle the relationship between Business and Tech teams, that I have used in other startups to make it work:

1)Both Business and Tech team have to understand each other: and by “understand”, I mean they have to know which kind of work each team is doing and how:

• Business teams have to understand that the Tech team has specific work methods and can’t constantly be bugged for the most trivial requests — they work in “sprints” of a couple of weeks where they focus on a couple of things they want to get done, and have a clear roadmap and prioritisation scheme mostly validated by top management, if not the CEO him/herself
• As for the Tech teams, they have to understand Business teams, by being in constant contacts “front end” with the clients and partners, have a certain sense of urgency and need to have enough answers to satisfy the clients
• It is two very different world and ways to work but in my view, the best is to make sure they both have a deep understanding of what each other is doing by having a tech person spending a day with the Customer Support team and so on. This could / should be part of the “onboarding” of any team member — everyone should spend a day with the Customer Support team as this is such a key team within any startup, but this is another topic for another article ;)

2) There is a crucial need to set up efficient communication channels between these two teams: both Tech and Business teams need information from each other to guide their respective work.

• Tech teams need to know what is the most important to run the business, what the most important clients want, which feature will enable the startup to raise more money. For this, they need Business teams to give them some feedback and information in an organised way. I have used Jira tickets and ProductBoard to communicate my business needs to tech teams, both are great tools that give you the opportunity to raise tickets, rank them, leave comments, and see the progression of their implementation. So that if a bug happens, I see on Jira the status of its fix and can inform the clients real time about it
• Which leads me to my second point — business teams need to know what the tech team is working on and what it prioritised. For this, the tech roadmap is of course an essential tool. It should be built in collaboration with the different teams of a startup to reflect the overall goal and the different steps to get there. At Stuart, the tech roadmap is probably the most read document of all ;)
• Beyond the Tech roadmap and ticketing tools to raise tech requests, there is also the need to organise daily communication which might happen when the Operations team is facing a bug for instance. It is not optimal that an individual team member talks to an individual tech member through Slack / call. Rather set up some Slack business-tech channels where everyone can raise requests which are answered by different tech team members, so that the ones available are the ones who answer straight away and answers can be read and used by anyone.
• With these communication channels, you don’t even necessarily need to have Business and Tech teams sitting in the same office. I have actually more often seen the opposite situation — not to say some extreme case where tech team is in Asia working from a jungle-type environment while Business teams are sitting in an office in Europe :) But it can hamper the efficiency of tech team to be sitting in the same office of Business teams which are more noisy (Sales, Customer Supports are often on calls) while they need great focus to fix some bugs, and also there is always the temptation for Business teams to come directly to the desk of a dev to ask something (I’d be the first one to fall into this ;))
• If working in two different offices, it is still very important that both teams meet up and have face to face interactions from time to time. That’s how you build solid relationships between team members — even if I’m the greatest fan of Slack (I was actually the one who sent the most Slack messages within the whole Stuart team last year! This doesn’t mean I am not being a productive person, don’t take it wrong ;))

At the end of the day, it is up to the top management to make sure to build a unified and strong team where everyone works hand in hand.Tools like Jira, ProductBoard and Slack can help but it is also a lot about the charisma and vision of the CEO and CTO and how they’re communicating it to the rest of the team. I am lucky enough to work alongside a great CTO at Stuart (cheers to Lachlan Laycock) who has set up numerous transparency measures both within the Tech and Product team and with the other teams to make sure that everyone is aligned. Having a strong CTO with both great technical and management expertise is key to the success of a startup, because without a product that works there is nothing left to sell and use.