Skip to content
It was the project where I turned an original six‑month engineering estimate into a ten‑week delivery.
The project did not collapse in one dramatic moment. It unravelled quietly, through a thousand tiny misunderstandings.
Every day the workflow felt more chaotic. Product features were told verbally to individual engineers. Requirements lived in scattered chats, calls, and assumptions. No one had the full picture. Everyone was busy, yet progress felt strangely unpredictable.
More meetings were added to fix the communication problem.
But more meetings only made things worse.
The real issue was not the number of meetings.
The real issue was that the teams did not share a common language.
The Invisible Task That Triggered Everything
Security was the perfect example of this invisible problem.
The product team knew security mattered, but they were not sure whether the timeline was worth it.
The engineering team followed best practices, but they could not explain the business reasons behind the work.
Security tasks were invisible.
You could not see progress.
You could not demo them.
You could not screenshot them.
And because they were invisible, they created more inquiries, more conflicts, and less teamwork.
Information broke apart. Communication channels fractured.
Everyone was working, but no one was aligned.
The workflow became a textbook communication breakdown: ineffective communication channels, uncontrolled scope change, and requirements shifting informally from one conversation to the next.
The result was predictable:
- Fragmented workflow
- No shared understanding
- Unexpected output
- Not the product the business expected
When communication is fragmented and requirements are unclear, teams fall into a repeating cycle of rework. A well‑known failure pattern in project delivery.
The team fell into a classic rework loop.
A classic communication failure
The Turning Point
Introducing a common language
The breakthrough came when I stopped trying to fix communication with more meetings and instead aligned on a shared language. Security became the anchor.
I introduced the classic CIA triad as the foundation for understanding why security tasks exist.
- Confidentiality
- Integrity
- Availability
Suddenly, security was no longer a mysterious engineering ritual.
It became a business concept with clear meaning and impact.
But the real clarity came when I explained where security tasks actually come from.
The Four Layers Behind Every Security Task
Why these tasks exist long before a developer writes a single line of code
Security work does not appear randomly.
It flows through a predictable chain:
Law → Standard → Company Policy → Procedure
Once the business team understood this chain, the invisible became visible.
Law
The highest level of obligation
Laws define what must be protected. In the United States, examples include:
- HIPAA for healthcare
- GLBA for financial institutions
- SOX for public companies
- State privacy laws like CCPA
Laws do not tell engineers how to build systems.
They simply say: “You must protect this data.”
Standard
Industry expectations that translate law into practice
Examples:
- ISO 27001
- SOC 2
- PCI DSS
Standards define what “good security” looks like.
They turn legal obligations into auditable expectations.
Company Policy:
Leadership’s commitment to the rules
Policies translate standards into internal rules:
- All production systems must use multi factor authentication
- All customer data must be encrypted
- All access must follow least privilege
Policies define what the company promises to do.
Procedure
Where engineers turn policy into tasks
Procedures are the step‑by‑step instructions:
- How to configure MFA
- How to implement micro segmentation
- How to set up audit logging
This is where invisible tasks live.
These were non‑functional requirements, essential, but invisible to stakeholders, and therefore constantly underestimated.
A developer sees “Implement MFA” or “Break price query into server → proxy → database,” but behind each task is the full chain:
Procedure ← Policy ← Standard ← Law
Once the business team saw this, the task was no longer invisible.
It became logical, necessary, and aligned with business value.
Case 1: More rights and more impact require more audit
I explained it through real life.
- One factor authentication: password for your personal email
- Two factor authentication: staff password and one-time device token for company restricted documents
- Three factor authentication: passport, token, and face photo at the airport
The business team initially felt this was bad user experience and extra development time.
But once they understood the principle: more rights and more impact require more audit. The conversation changed.
Security was no longer a blocker.
It became a business safeguard.
Case 2: Micro segmentation and least privilege
I explained why a simple price query required three components: server, proxy, and database.
The business team asked why we could not just query directly to save time and improve speed.
Because micro segmentation protects the system.
Because least privilege prevents lateral movement.
Because shortcuts today become vulnerabilities tomorrow.
Once the business team understood this, they saw the business value behind the architecture.
The Result
Alignment, clarity, and teamwork
With a shared language, everything changed.
- Fewer inquiries
- Fewer conflicts
- More teamwork
- Less fragmentation
- More predictable delivery
Security tasks were no longer invisible.
They were understood, valued, and properly planned.
We documented everything in a Confluence space. This became our knowledge management system, the structured way to reduce fragmentation and prevent repeated misunderstandings.
Teams added comments, shared insights, and reduced knowledge conflicts.
Security tasks were linked to business concepts, not just technical checklists.
Only after this alignment did meetings become productive.
Because now everyone spoke the same language.
Key Takeaways
- Invisible tasks do not break projects. Misunderstood tasks do.
- When teams lack a shared mental model, even simple work becomes chaotic.
- When teams align on concepts, even complex work becomes manageable.
Security was just the example.
The real solution was alignment.
And once we aligned, the project finally moved forward with clarity and confidence.
Why a Pre AI Lesson Still Matters in the AI Era
Even though this project happened a few years ago, the problem and the solution remain fully relevant in today’s AI driven business era. The reason is simple. The failure was never about technology. It was about alignment, clarity, and methodology.
AI can accelerate execution, but it cannot fix a broken workflow. AI can generate tasks, but it cannot define the right ones. AI can write documentation, but it cannot create shared understanding.
The same issues that slowed the project years ago still break AI projects today. Invisible tasks do not disappear just because AI is involved. They become even more dangerous because AI produces output faster than teams can align on what the output should be.
This is why the lesson still matters. AI does not replace alignment, clarity, or methodology. AI does not replace the chain of law, standard, policy, and procedure. AI does not replace the need for a shared mental model.
AI is a multiplier. If the system is structured, AI multiplies clarity. If the system is chaotic, AI multiplies chaos.
The methodology that turned a six month estimate into a ten week delivery is the same methodology that makes AI effective today. The tools have changed. The principles have not.
At the same time, the rise of AI has created a new belief inside many product teams. The belief that one person can now do everything from product to programming. It sounds efficient. It sounds modern. It sounds like AI has removed the communication problem.
But it removes people, not complexity.
Even if one person writes the requirements, designs the flow, generates the code, and deploys it, the responsibilities do not disappear. Requirements still need clarity. Priorities still need alignment. Security still needs justification. Architecture still needs reasoning. Tradeoffs still need discussion. Business impact still needs validation.
AI accelerates execution, not understanding.
When one person does everything, communication problems do not vanish. They simply move inside the person’s head. Misalignment becomes internal. Rework becomes self inflicted. Invisible tasks become invisible even to the person doing the work.
This creates a single point of failure. No peer review. No shared context. No challenge of assumptions. No visibility. No resilience.
AI makes the person faster, not wiser.
The future is not one person doing everything. The future is one person executing faster because the team is aligned, the workflow is structured, and the methodology is strong.
What’s Next
This article showed how invisible tasks, especially security work, can quietly break a project when communication is fragmented and teams do not share a common language. Once we aligned on a shared mental model, the chaos settled, the rework loop stopped, and the workflow finally became predictable again.
In the next part of this series, I will continue the story by walking through this real project from my past experience. I will explain how standup meetings, a well designed Confluence space, and a disciplined Jira workflow worked together to solve the same communication problems described here. It will be a practical continuation of this journey, showing how alignment, documentation, and predictable processes turned a fragmented project into a high performing delivery engine.
About the Author
Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth.
Connect with me on LinkedIn