Reorganizing A Multi-National Team to Save A Late Product Launch

Problem

I joined the Paris office of a Quebec-based security company, where my role was to manage a team in charge of a new software solution. This product was really important for the company because there were no other market alternatives at the time, and it led to us signing some big deals with airports. However, the project had gone more than a year without customers receiving any stable version of the product. The customers were very angry and threatened to pursue legal action.

The product director who had been leading the team until I joined had just moved to Montreal to create a new team. The director had appointed a deputy in Paris to assist the transition. Testing and infrastructure were located in Montreal. The Paris team was divided into 2 teams - front-end and back-end. Functional specifications were being made in Montreal, but the development cycle was assimilated through the waterfall method to the Paris team. It wasn’t working.

The product director had lost trust in the Paris team and a noxious atmosphere was blocking productive discussions. The Parisian team was revolting against the product director and his deputy, so they refused to continue working under these conditions. The team pointed out the lack of transparency, poor communication from the hierarchy, and unrealistic deadlines. All the Paris team members felt that they were too far from Montreal and thought that their team was going to be dismantled.

When I came, I was really surprised to see that none of this was told to me ahead of time, so I had a lot to figure out on the job. Issues were hidden because of poor communication. The ambiance was very bad, the team was very frustrated. 

Actions Taken

When I started, I had the information that the customer wanted to move to legal action. It was a concrete problem that I needed to solve. I started by talking with the customer and with different stakeholders. I worked to identify problems within the team in parallel, and it took several weeks to list all the issues. I broke the problems into the following four categories: customers, team organization and development cycle, project and release cycle, and the management and the team.

For each type of problem, I worked with each of the main protagonists to establish a timeline of the main actions to be taken and prioritize them. For example, I started by reopening the discussion with the customers and creating a new position to engage and talk with them specifically about the features they wanted and to regain trust. The customer is not a toy for us, we had to fix the team to hit these goals. The customer was a yardstick for reorganizational success. 

At our Paris office, front-end and back-end teams were split up and had very different kinds of people, making it difficult to build the features the customers wanted. I created more discussions between the different teams and tried to create a melting pot of culture. They had to work together and move together on the feature. It was my first step in the reorganization and some people who weren’t good tech leaders needed to be repositioned. I had to spend time coaching them through this change. It was very difficult in the first week to integrate these angry teams. 

Then, I identified a part in the development workflow - the QA - that we had to fix because of the time gap between the development and the testing. I asked Montreal to allocate some QA responsibility to Paris for the first iteration of the features. In parallel, I recruited some people to fill these newly formed QA, PO, and QA automation positions in Paris. It was difficult for the project owner in Montreal because he wanted to keep this position, but I convinced him it was needed for the success of the project. I also organized moves between developers in Montreal and Paris to help with team building and project perspective.


Next, I had to reengage the product director to communicate with the team. The main principle to reengage the team was getting them to trust the reorganization and to come to them as a peer. I tried to talk with them without opinion. You need to come without your opinion if you want to develop a context. Only after gathering a lot of information can you have an opinion and the context to make a good decision. 

To make the organization more human and agility-centered, I tried to focus on a core pillar: putting humans and their interactions before the process and the tools. I was able to create some rituals, such as a regular standup with Montreal and a lot of technical discussions. The team members committed to specific deadlines for features. With this alone, we were already effective in humanizing the company because they were all engaged with the project and involved in the say of the process. We asked them what they wanted and how they wanted to improve the process. The process was personalized to these people. This isn’t a top-down decision about the organization, it’s a decision for the organization by the organization. It may be important to give corporate vision top-down, but everyone needs their identity within their own team.

Lessons learned

Team re-engagement was the biggest indicator of success, and the customer, in turn, engaged more with us. We didn’t have a fractured company with multiple teams, we just moved to one project and one team. The project was important to the customer, so it became important to us too. The framework was:

• Isolate problems independently, break them up into small pieces and work in stages
• Open discussions with all the stakeholders so that together we can find suitable solutions for each problem
• Support the reorganization process through communication and trust
• Knowing how to arbitrate with strength when necessary and being able to manage one's hierarchy by framing risks and objectives
• Being able to commit oneself strongly
• Listen to the customer and deploy with Agile pillars