Decision-Making Under Incomplete Information: A Case Study of the New CX Team

Introduction

As an Engineering Manager overseeing four teams—three product teams and one platform team—a slide unexpectedly appeared during our quarterly leadership meeting introducing a "New CX Team." This was an unprecedented situation for us.

It was revealed that three new positions had been created specifically to improve the Customer Experience (CX). However, no one consulted me regarding this decision, nor was I informed in advance. It seemed as though it had materialized from thin air.

While such a scenario could be viewed as unfortunate, I faced a choice: either continue questioning why I was excluded from the decision-making process, or adopt a second approach—seeking to understand the purpose of this team and how its presence could address our challenges. I chose the latter.

Context: Evolution of Organizational Operating Model

This challenge was closely tied to a broader shift in our organizational operating model.

• Old Model (Technology Component-Based): The company organized teams based on technological components, such as mobile, backend, web, and a CX team dedicated to dashboard creation.
  • Challenge: Product experiences were fragmented; handoffs between teams meant no single entity owned the End-to-End (E2E) journey.
• New Model (End-to-End Experience Ownership): The organization transitioned to a structure where teams own and are accountable for the entire customer experience across boundaries.
  • Result: Bugs and incidents decreased significantly, and the organization moved in the right direction.

Under this new paradigm, a new team was established in 2020—a critical investment period—with a clear focus on CX metrics. Reporting directly to a specific leader improved decision-making velocity.

Emergence of Challenges

However, several irregularities emerged:

1. Misaligned Reporting Lines: The team reported directly to Product Leaders within the product business vertical rather than integrating into any existing leadership line. This created communication distortions; despite active participation in meetings and ceremonies, the team remained ineffective.
2. Lack of Foundational Support for Success: At inception, the team lacked appropriate tools and sufficient understanding of the current challenges and structural constraints, making autonomous goal achievement extremely difficult.
3. Expectation Mismatch: The CX team planned to build an integrated dashboard using micro-frontend technology. However, this did not align with the leaders' expectations, who envisioned dashboards tailored to each specific product team's implementation needs.

Specific Obstacles Encountered

The CX team faced significant hurdles while handling support tickets:

• Insufficient Domain Understanding: They struggled to fully grasp customer issues and resolve them autonomously.
• Unpredictability: Resolution times were opaque; API key resets and database changes were often required due to poor system synchronization.
• Dependency on Development Resources: During off-hours, they had to wait for developers, causing ticket resolution to spill over into the next day.
• Team Distraction: Unforeseen tasks pulled the team away from their core responsibilities.

Furthermore, dashboard development faced a major bottleneck. Members of other product teams were unfamiliar with frontend development, and resistance to "touched HTML" was pervasive. Consequently, building from scratch proceeded far slower than anticipated.

Adopted Approach

To achieve business objectives, I pursued the following strategy:

• Internal Dashboard Construction: Instead of a monolithic integrated solution, we built distinct, protected dashboards for each team.
• Feature-Limited Design: The dashboard included only the use cases essential for the CX team.
• Automation Focus: We addressed ticket resolution by developing new dashboard functionalities rather than relying on manual intervention.
• Investment in Learning and Documentation: Through pair programming with developers and creating documentation, we ensured the CX team's autonomy.
• Noise Reduction: When questioned by leaders about why an integrated dashboard wasn't used, we simplified our response to streamline operations while maintaining future reusability.

Emerging Insights and Adaptation During Execution

As implementation progressed, further peculiar challenges surfaced:

• Resistance to Frontend Work: The team struggled with existing frontend development paradigms. Rather than forcing a React-based solution, we determined that a simple HTML template capable of making API calls was more pragmatic.
• Scaffolding the Backbone: Using only Spring Boot templates to construct the dashboard skeleton ensured security while delivering functionality. Extensions could then be built by copying existing structures.

The resulting dashboard was not aesthetically perfect but was highly functional. Product Managers began adopting it, significantly reducing unnecessary workload for developers. However, this success inadvertently placed the burden of all tasks on a single Product Manager, exposing them to burnout risks.

Cultural and Process Corrections

A crucial turning point arrived here. While we met our OKR (reducing monthly ticket resolution time), the underlying approach was flawed. I realized, "The OKR is good, but the culture it fosters is wrong."

• Team Involvement: We insisted that developers, product managers, and designers alike actively participated in solving problems directly with the CX team.
• Pair Programming and Training: Leveraging Jira, we adjusted processes to make the CX team's progress transparent and fostered better adoption.

Within one month, we successfully achieved the OKR: reducing ticket resolution time from days to hours.

Lessons Learned from Failure

Several mistakes occurred during this project:

1. Investment in Unused Dashboards: We wasted human time and system resources on building something that wasn't broadly utilized.
2. Marginalization of Existing Tools: The new dashboard operated independently of legacy CX tools, increasing friction for adoption.
3. Over-prioritizing Structural Management: Resources were allocated to communication and structural solutions rather than immediate problem-solving.

I concluded that "burning money" (in terms of human resources and systems) was the least expensive solution when facing high-risk business challenges. Acknowledging "waste" does not mean failing; it signifies identifying inefficiencies. Promoting team autonomy and adapting within the same quarter (even within the same month) delivered significant impact to customers and the business.

Although this created friction within the leadership team, we adhered to the Team Topologies principle: "If the platform isn't sufficient enough, the best response is to abandon it." Some leaders did not understand our stance, perceiving us as uninterested in the team's work, but in reality, we intentionally rejected the integrated dashboard approach to demonstrate a superior solution.

Conclusion

Ultimately, the team operated for five months before product teams continued to solve CX metrics independently without substantive progress from the platform initiative. Consequently, the leadership team decided to disband the experiment.

• Short-term Perspective: Although appearing economically inefficient, we avoided wasting time and resources on dashboard development while reliably achieving business goals (improved ticket resolution speed).
• Long-term Perspective: We left behind reusable components using an API-first approach for future dashboards, preserving potential for integration later on.

Summary: Decision-Making Under Incomplete Information

The key lessons learned from this case are as follows:

1. Information Asymmetry: In large organizations, not everyone can participate in all decision-making processes; information may take too long to reach the responsible parties. While frustrating, this is an inherent part of the job.
2. Management Misalignment and Adaptation: Significant discrepancies arose between the plan (integrated dashboard) and reality (lack of frontend skills, delays). External factors like prolonged hiring cycles and technical debt caused the initial plan to fail.
3. Collaboration vs. Duplication: Collaboration alone failed to yield success, so we opted for temporary duplicate development (proprietary dashboards per team), though this ultimately failed to transition smoothly to a common platform.
4. Prioritization of Resource Allocation: The integrated new dashboard lacked sufficient business interest and resource allocation. Consequently, the two-member undersized team struggled significantly.

Conclusion: Given that we achieved our business objectives, the decision to stop investment was justified. While fear of waste is natural, "strategic inefficiency" can sometimes generate maximum efficiency. Even with incomplete information, responding immediately to current business challenges and respecting team autonomy proved to be the optimal approach.