Adding a team was the wrong strategic decision

Adding a new team without understanding the existing sociotechnical system can lead to strategic failure. This article explores how a top-down decision created misalignment and how an Engineering Manager navigated the resulting challenges.

Adding a team was the wrong strategic decision

Missed communication, lack of sociotechnical system understanding, and more.

I still remember that quarterly leadership meeting, which I was Engineering Manager of a tribe of 4 teams, 3 product teams, 1 platform tribe team.

All of a sudden, in the slides there were a new team.

We have decided to improve the experience for our customers for this tribe products, that’s why we have opened 3 new positions for the new team CX Tribe.

I had a new team that nobody asked me for my input, nor informed me before that decision was made. It just appeared out of nowhere.

This is that kind of situations that ~~sucks~~ are unfortunate.

In that situation, I could have focused on:

Why I wasn’t included in the decision-making, or

Understand the reasons of that team, and how can we leverage it for the challenges we had.

I went for the second.

Simplified conversation.- Aleix: Which is the mission of that team? How will we work together?

Product leader: The goal is to improve our Customer Experience. We take a lot of time to resolve tickets, and our CX team needs better tooling to support our clients. This team will be in charge of a new dashboard.

Conversations are unstructured, therefore, we always need to extract the intentions from the noise.

There were things we were aware of, I just found that the operation model that the decision was made was based on a previous sociotechnical structure.

On the old operating model, the company founded teams based on technology components. A mobile team, a backend team, a web team, and, in this case, a CX team doing a dashboard.

The product had a broken experience due to the handovers between teams, no single team owned the product E2E.

So, we moved towards a team owns the full experience. You can see the full journey to reach this point here.

The new operating model worked well, we had fewer bugs, fewer incidents, we were going in the right direction.

Yet, that decision was made. My main opinion of why that happened is:

Information flows slowly to decision makers. This was due to the new approach was bottom-up, and it didn’t happen in the closed leadership meetings.

Investing in new teams, during 2020, when the budget is easier, and you need less negotiation between parties.

Having a single team to own the CX at the tribe makes a clear focus, clear ownership of the metrics, and makes the reporting faster to the specific leader that’s responsible for that.

The team was created odd

The first odd decision was that the team didn’t report to any of the tribe leaders. They reported directly to our product business vertical product leader. And that created a flawed communication, even though we included the team on all the tribe meetings and ceremonies.

The new team was created without the support to succeed.

The business challenge

Regardless of how that team was created, we knew that CX metric had to be improved. We were driven by two:

✅

Fewer tickets per month. We succeeded on this.⚠️

Reduce time to resolve a ticket. We still had to improve this by a lot. And, indeed, that’s what the new CX team was funded for. 👈

The CX tribe team approach

During the quarterly planning, they presented their approach.

CX team will develop a new dashboard for the whole Payments Tribe using microfrontends with React that will connect with existing authentication tools.

Once that’s finished, each team will have to develop their own microfrontend for CX support.

That didn’t make sense at first, since the team approach and leadership expectations weren’t aligned.

We managed up the miss alignment on expectations. The approach wouldn’t meet the leadership expectations, which impacts our customers and the product experience.

Diagnosis

High lead time to resolve customer support tickets

CX team didn’t have the proper tooling to understand the state of the accounts for them to resolve the tickets autonomously. Each new ticket required a developer to dig into the state for:

Understand what’s not working.

Apply a fix, usually implying API calls or DB changes due to out of sync systems. We weren’t fully consistent due to the high distributed system we poorly designed. We were improving this at good rate.

So, CX had two problems:

They couldn’t answer the customer with

we understand what’s your problem, and we are resolving it. They couldn’t have a predictable way to know when things will be resolved.They had a strong dependency on developers’ availability to look into those issues. Which means, outside working hours, they would have to wait until next day to get the answers and fix.

This caused another issue into the teams.

A lot of distractions and unplanned work to support our customers manually.

The teams and their missions weren’t aligned with new ways of working

CX tribe team was added without understanding the current tribes challenges and structure. The team had to understand the full picture, and start creating human connections to succeed in their mission.

They weren’t autonomous to accomplish their goals, yet they didn’t collaborate with teams to be sure they accomplish it. Instead, they were focusing on the technical challenge of a new greenfield architecture.

Direction

At this point, I had to decide how to accomplish the business goals in this new scenario. And I decided to go with the next approach.

We will develop an internal dashboard per team, they won’t be connected, but they will serve the main CX use cases.

We will train the CX team on this new messy dashboard.

This direction had several implications:

Product teams will develop their own dashboards, protected, but not having a good overall UX for the CX team, but good enough.

The dashboard will only contain the use cases that CX need.

When a CX opens a ticket into the team, we don’t resolve it manually but create a new dashboard feature to help the CX to do it by themselves.

We dedicate the right amount of time to be sure they are autonomous. This means pairing with them, documentation, and so on.

**We will ignore CX tribe team work until it is the right time.**I would focus on containing the noise from the team when leadership asks why we’re not using the dashboard they are investing it.

The internal Dashboard will have the basics that later could be reused for the new dashboard when it is available.

Execution

No internal per team dashboard was happening

During the execution I faced a very strange challenge. The dashboard wasn’t being developed within the teams, it was taking A LOT.

The dashboard wasn’t that complex: View information, perform some API calls. Replicate what we were doing in the DB and API manually but in a web page.

After sometime asking the team to prioritize that, I realized which was the problem.

People weren’t comfortable with frontend development**. **Indeed, some shared that they were backend developers, and they wouldn’t do any HTML work.

This delayed everything. Starting from 0 were preventing people to develop the dashboard. I didn’t realize this was happening until very late.

You can see how we moved from per stack developer to full stack developer here

So, I adapted to this reality, and I did a hard push to create the backbone of the dashboard using only spring boot templates. Instead of aiming for a React frontend, we just needed a simple HTML template, to call certain endpoints, and ensuring the security.

When the team had some basic structure in place, extending it was a matter of copying the existing structure.

The dashboard wasn’t beautiful but useful.