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.
Not enough dashboard adoption by CX team
We did the dashboard, it was resolving the tickets, it wasnât being used by the CX team but by our product manager.
The product manager, she is a lovely person, preferred to take all the burden by herself over passing the tickets into the developers.
We succeeded on freeing the developers from unplanned repetitive work, but now our PM was super busy, and probably burning herself out.
We asked why she was doing that, and how can we help her.
The problem was that CX was used to passing the tickets to our team. Now the tickets were resolving faster (since the dashboard made something super trivial), so, the business objectives were accomplished.
But in the wrong way.
This usually happens, OKRs looks good, but the approach creates the wrong culture.
We had to intervene to accomplish the same OKRs but with a better approach.
CX resolving the issues by themselves, not by our team members, regardless if they are devs, product, or design.
So, we started pairing with CX team, do proper training, and documentation. We showed them that it was less painful to make it using a messy dashboard that resolved their issues fast, rather than opening tickets into our Jira board.
The key area was to kind of use Jira during the process, because thatâs the system they used to report their progress. We adapted a little the process to help them show their progress and impact. That boosted the adoption by a lot.
Once that was done, almost all the tickets were solved at CX team level, reducing by a lot the unplanned work for our team.
Within a month, we achieved the OKR of âReduce time to resolve a ticketâ to within hours compared to days.
What could we have done differently?
Two main things went wrong here.
We invested into a team to create a dashboard that nobody used. We wasted human time and system resources.
Created a dashboard outside the common legacy CX tooling increased adoption friction.
Leadership invested into a new team because that was the operating model we had back then. Each leader had a budget, and they used it to create their own teams they had clear ownership of.
Instead, I would have had added dedicated team members into each team in order to understand the whole product domain, and adapting it to the CX needs instead of creating more communication and managing structure.
My decision of burning money
I knew that by ignoring the CX tribe team creating their own tooling meant that we were burning money, in terms of peopleâs time and system resources.
At some point, I had to decide which problem to address, and burning money was the cheapest approach to overcome our business high stake challenges.
Sometimes feels like wasting that is the wrong approach, nobody wants to feel they are wasting resources. But looking back, the decision we made was the approach that wasted the less of resources and peopleâs time.
By focusing on the new ways of working, and the team being autonomous to deliver a solution within the same quarter, indeed, same month, had the biggest customer and business impact.
The friction with leadership team
This created friction within the leadership team during the whole quarter.
Because we were asked to use what they decided to invest.
But here I followed the Team Topologies Platform principle. Do not force adoption. If the platform isnât good enough, the best we can do is drop it.
At first, this was a very odd decision for other leaders. It felt like I didnât care about the teams job, but the goal was to show a better way to solve the same thing with the new operating model we had invested for the past months.
This turn out to be a great business case, and we started replicating the approach.
What started as a temporal dashboard, I think it had been there for way more years that we would have expected. đ
The end of the CX tribe team
That team were in place for 5 months, after seeing no much progress but the product teams resolving those CX metrics by themselves, the leadership team decided to dissamble the team.
Edit for context clarification on 27th April 2026
Previous content has been left as it is.
The goal of this post is about showing how we make decisions based on imperfect information. Mistakes were done, and those were part of the journey.
Notice that diagrams are a simplification of the reality and they do miss information.
Where the CX tribe team came from?
Big companies have a lot of business units and reporting structures. Not all of us can be part of all the decision making, and sometimes you gain the information on the last responsible moment.
My managers and myself were in a high pressure times, and we cannot forward all the information at the best moment.
One might not like to gain the information âlateâ, when the decision is already done, but itâs part of the job.
The important aspect here is how we involved the team into the tribe.
The misalignment goals and duplication of effort
We had the misalignment on how we could handle the business challenge of:
â ď¸ 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. đ
Here we had two duplication of effort planned:
At Tribe level with each team with their own dashboard đ What we had planned until the new info came.
CX tribe level team to create a unified dashboard
The misalignment was in the delivery time, and teams involvement.
We needed to reduce the Key Metric of lead time to resolve a ticket, the CX tribe level team had 3 months to deliver a functioning dashboard that then each team had to develop their own features.
Speaking with the other EM, we notice some things:
They missed a lot of information until we spoken about what was being developed and the current status of the project. What looked easy at first, turned out to be a bigger project than expected due to all the distributed logic problem and technical debt.
The new team was understaffed and didnât have all the resources to succeed. They required help from all the tribe teams to develop their features into the new dashboard, but this wasnât a product priority for some quarters.
Doing the dashboard while hiring was a huge challenge, the hiring process was too long for the team mission delivery time.
If we had to improve the Key Metric within the same quarter we had to do something else.
Then it was when we followed the approach of:
Develop internal per product dashboards, even though we would drop them later, with reusable APIs that the new dashboard could call later on.
We reduce another point of collaboration between teams, because there was already a lot going on, and we didnât want to add yet another priority into the table.
We delayed the problem of integrating to the new dashboard until later.
When you have 5 high priorities and you have to choose your battles
I remember on those times that we were in constant pressure to deliver a high impact product initiative. I had to decide which battles to fight. I recall this one to be one of those where more collaboration wouldnât help, or, at least, I couldnât support it good enough to succeed.
In this scenario, and based on all the information I had back then, duplicating components instead of collaborating seemed a good option.
We duplicated components, with an API first approach, to collaborate later.
The later never came
The new dashboard took way longer than expected due to all the team dependencies, within our tribe, and with other teams.
This was important for CX, but it didnât have enough business attention and resources for it to succeed.
What happened is that the internal dashboards kind of did the job for the CX team to support the clients, and we didnât continue with a more unified dashboard (maybe it was later, but not when I was in the company).
At the end, it was a two people team, understaffed, and without the proper support for multiple parties, me included.
Because the business goals were meet, we decided all together that was OK to stop investing in the initiative.
The dashboard
Each team had their own dashboard, but we had some principles after some iterations:
The information and actions have to be developed with an API first approach.
The dashboards had to be linked togeter from one and another to help the CX team to have an easy navigation.
They have to be protected and use SSO from the company to not force the people to log in to each one with different credentials.
Which it turned out to be a mix between Spring Boot templates and Vue components. The goal was to reduce yet another service to be deployed an managed.
This post is gaining more traffic than usual. I will add some clarifications soon to understand some decision making đ