Tongue in Cheek Perspectives on Data Protection

Originally published on LinkedIn, August 2019.

Data protection means different things to different people depending on where they sit in an organisation — and that gap between perspectives is one of the most persistent challenges in making a programme actually work. This post puts ten of those perspectives on the table, illustrated in the style of the classic “tree-swing” diagram.

The Tree-Swing Diagram #

You have almost certainly come across a tree-swing diagram at some point — in a training session, a project management textbook, or pinned to an office wall. The classic version shows a simple tyre on a rope, rendered differently by each group involved: “as specified in the project request,” “as designed by the senior architect,” “as installed at the user’s site,” “what the user actually wanted.” Each panel illustrates how the same solution looks when interpreted through a different set of priorities, constraints, and assumptions — and how rarely those interpretations align.

The diagrams are widely used to illustrate the pitfalls of poor requirements elicitation, departmental silos, and failures of communication between the people who design something and the people who actually use it.

A brief history of the tree-swing #

The origins of the tree-swing cartoon are genuinely uncertain, which is part of what makes it interesting. The BusinessBalls article on early tree-swing cartoons pulls together a useful collection of evidence and recollections that traces the diagram’s history further back than most people assume.

The simplest versions appear to have been circulating on office walls and in photocopied newsletters from at least the late 1960s. One contributor recalled seeing a version in a UK Civil Service newsletter in 1969. Another remembered a copy at a Silicon Valley software company in 1968–69, used to illustrate the gap between what end users asked for and what IT systems teams delivered. A version appeared in the San Francisco Examiner in October 1975, adapted for a school system context — with students in place of customers, teachers in place of marketing, and principals in place of management.

The diagrams found their way into print in several forms. A software development version appeared as early as 1973 in the University of London Computer Centre Newsletter. The six-panel format later appeared in Guide to Good Programming Practice (Meek and Heath, 1979), attributed to “Unknown Author.” John Oakland’s Total Quality Management, first published in 1989, brought the format to a wider management audience. Tom Gilb’s Principles of Software Engineering Management (1988) included a visually distinct version to illustrate the consequences of poor attribute specification.

What is consistent across all the variations is the underlying point: when different groups involved in creating or delivering something never properly talk to each other — or to the people they are supposed to be serving — the results diverge in predictable and often comic ways. The format endures because the problem it illustrates endures.

A data protection version #

I had not come across a tree-swing diagram adapted for data protection, so I sketched one based on my own experiences working across organisations of different sizes, sectors, and maturity levels. The ten perspectives below are tongue in cheek. But only just.

The Ten Perspectives #

It’s mainly a legal exercise — as assumed by some in-house legal teams. Data protection lands on the legal team’s desk and stays there. The programme becomes a documentation exercise driven by lawyers, disconnected from the operational realities of how data actually flows through the business.

Not GDPR again, it’s so last year — as perceived by some inadequately trained employees. Employees who received a one-hour compliance briefing in 2018 and nothing since have concluded that GDPR was a moment, not an ongoing obligation. Training that does not connect to real working situations tends to produce exactly this response.

Minimal compliance — as required by some CFOs. The minimum necessary to avoid regulatory action, sized to budget. No investment in culture, capability, or anything that does not have a direct line to a fine avoidance calculation.

Misinterpretation — as felt by some customers. Customers encounter cookie banners designed to frustrate consent withdrawal, privacy notices written in impenetrable legal language, and data subject access requests that are technically fulfilled but practically useless. They experience data protection as something done to them, not for them.

Scaremongering — as pitched by some law firms. The enforcement landscape presented as an existential threat. Maximum penalty figures quoted without context. Fear as a sales mechanism for retainer agreements.

GDPR compliant solutions — as described by some software vendors. A product that fills in a few fields, generates a stack of documentation, and declares you compliant. See also: ten tips on avoiding privacy tools you do not need.

Protecting our interests, not yours — as some organisations threaten their customers. Privacy notices and consent mechanisms engineered to extract maximum data with minimum transparency. Legitimate interests applied liberally. Data subject rights treated as a nuisance.

ISO 27001 is all you need — as some information security practitioners view data protection. Information security and data protection overlap, but they are not the same thing. ISO 27001 addresses information security management; it does not cover the full scope of GDPR obligations around lawful basis, data subject rights, privacy notices, or accountability. Conflating the two leaves significant gaps.

Every last drop — as requested by some marketing departments. Collect everything, retain it indefinitely, use it for every conceivable purpose. The default assumption that more data is always better, and that consent is a hurdle to be minimised rather than a genuine expression of individual choice.

The bandwagon — as jumped upon by some data protection practitioners. The post-May 2018 surge of newly minted privacy professionals, GDPR consultants, and compliance tools. Some excellent. Some less so. The challenge for organisations was — and remains — telling the difference.

Why These Perspectives Matter #

The gap between these ten views of the same subject is not just amusing — it is the central operational problem for anyone trying to build a data protection programme that actually works. When the legal team, the CFO, the marketing department, and the DPO are operating from fundamentally different models of what data protection is and what it requires, the programme fractures along those lines.

Getting to a shared understanding — across functions, levels, and roles — is the precondition for building something coherent. That is harder than drafting a policy, and it takes longer than a compliance deadline. But it is the work that actually changes behaviour.

If you are building or rebuilding a programme and recognise several of these perspectives in your own organisation, the place to start is not another policy document. It is a conversation about what data protection actually means for your specific business — and what it would look like if it were working well.

Frequently Asked Questions #

What is the tree-swing diagram and where does it come from? The tree-swing diagram illustrates how different stakeholders interpret the same requirement in incompatible ways, typically shown as a tyre on a rope rendered differently by each group involved in a project. Its origins are debated, but versions were circulating in office newsletters and training materials from at least the late 1960s — possibly earlier. It has since appeared in project management, software engineering, quality management, and education contexts. The BusinessBalls article on early tree-swing cartoons is the most thorough account of its history I have found.

Why do different parts of an organisation view data protection so differently? Because each function experiences data protection through the lens of its own priorities. Legal sees liability. Finance sees cost. Marketing sees friction. IT sees it as an information security sub-topic. Customers see it through their experience of consent banners and privacy notices. None of these perspectives is entirely wrong — but none is complete either. A functioning programme has to reconcile them, which requires active effort rather than assuming a shared understanding exists.

How do I know if my organisation has a shared understanding of what data protection means? Ask five people in different roles the same question: “What does good data protection look like for us?” If the answers are radically different — or if the question draws blank looks — you have your answer. Closing that gap is one of the most valuable things a data protection leader can do before investing in tools, policies, or training.

If you found this useful, the Purpose and Means newsletter covers GDPR, data governance, and privacy strategy — fortnightly, in plain language.

Purpose and Means works with organisations on data protection strategy, governance, and compliance - going beyond the legal text to focus on how things actually get done. If you’d like to discuss what this means for your organisation, book a call or explore our services.