I have always been fascinated by the choices people make. The decisions we take often reveal something essential about who we are. Consider the driver who speeds past you, weaving recklessly between cars, only to stop at the same traffic light. Or the driver who rushes to beat a red light, only to end up blocking the intersection and preventing others from moving forward. I often wonder what quick calculations guide these moments, and the ways people arrive at them continue to intrigue me.
I once worked with a group of genuinely well-meaning people at a young company. Everyone was eager to contribute, but despite their good intentions, the results were often unhelpful. Clients were confused because there were no clear guidelines, and no shared, structured method for our work. The experience reminded me of a family-owned Vietnamese restaurant I visited soon after it opened. The family wanted so much to please every customer that they nearly tripped over one another while serving. Their enthusiasm was touching, yet it came at the expense of the one thing that mattered most, the food itself. A year later, the restaurant had closed. The startup, despite significant funding, met a similar fate.
This raises a difficult question: what do you do when you encounter drivers who block intersections or well-meaning coworkers who cause confusion rather than clarity?
In situations like these, I rely on the CESEA framework to guide my decisions:
- C: Check myself and my actions
- E: Practice empathy
- S: Set clear boundaries
- E: Establish shared expectations
- A: Act on decisions
The Dilemma of Invisible Work
Some time ago, I faced this same dilemma with my own team. We were responsible for collecting data from multiple systems across the company and turning it into meaningful insights. The real difficulty was not the analysis itself. It was the organizational challenge to create a single source of truth (SSOT). Instead of a clear and coherent data architecture, we were repeatedly pulled down into one organizational or technical rabbit hole after another. We chased data through legacy systems and fragmented tribal knowledge, often uncovering duplicate or conflicting records with no clear data owner.
This challenge is common in data work, yet the underlying pattern appears in many other places, from infrastructure to security to quality assurance. Essential technical work often remains invisible to stakeholders. They frequently form expectations based on limited visibility into the reconciliation process, which makes the true complexity of the work appear opaque and confusing.
When I pressed the team to share our process, they hesitated and said they did not have time. They believed their effort was better spent wrangling with the data than documenting the struggle. From my perspective, we were stuck in a cycle. The team was so busy performing heroic manual reconciliations that they did not have the capacity to document the work and demonstrate its efficacy to stakeholders, or help them understand the deeper issues of unclear data ownership and the absence of a single source of truth. Successes then seemed effortless, and delays seemed failures. The reality was unmistakable. Making the work visible was not optional. It was the essential first step toward addressing organizational and architectural problems, and it was therefore part of the work itself. This openness also allowed us to manage stakeholder expectations by helping them understand the process and the issues that shaped our progress.
Applying the CESEA Framework
I applied the CESEA approach, starting with C, Check myself and my actions, and E, Practice empathy. I asked whether I fully understood the situation and their perspective, and how I could support them as we worked toward S, Set clear boundaries, and E, Establish shared expectations. Each question clarified what needed to happen for the team to succeed.
At first, there was pushback. Some team members questioned the purpose because of the volume of work on their plates. I explained that transparency would help stakeholders understand the process, enabling us to manage expectations. Others asked how to balance this effort with ongoing tasks. I framed it as a critical choice: invest time now to document the SSOT problem and educate stakeholders, or continue trying to meet impossible expectations while confusion and systemic data debt persisted.
We also discussed what realistic stakeholder responses might look like. I explained that understanding rarely comes on the first attempt. It requires repetition, examples, metaphors, and analogies. The turning point came when the stakeholders contacted one of their partners for help with data acquisition. When that partner described how messy their data was, with duplicate entries, conflicting schemas, and an overwhelming amount of manual work required to even approach an SSOT, and how much they would value our support, the stakeholders began to see that the problem was real, and that solving it would create benefits for everyone involved.
It took months of steady effort to align our team and stakeholders, but the results justified the investment. The clarity we built revealed the core SSOT challenge, improved outcomes, strengthened trust, and encouraged better collaboration across the company. Documentation and communication continued, and the team came to understand that these tasks were not separate from the technical work. They are what give the technical work its meaning and its impact.
