This is the third post in a series exploring the idea of skills you earn vs. skills you learn. The previous posts can be found in my archives.
Almost as soon as we started building the enterprise graph, the question arrived that we probably should have asked first.
If you can measure what people actually do — how they collaborate, where their influence flows, whose judgment the network trusts — then who gets to see that picture? Who controls it? And what happens when the answer to those questions is “the employer”?
This wasn’t a hypothetical concern. The same data that could make an invisible contributor visible could just as easily become a surveillance instrument. The same analytics that might surface the quiet expert who was being systematically overlooked could also flag the employee who was disengaged, or spending too much time talking to people outside their team, or whose network patterns suggested they were about to leave. The capability cuts both ways. And the question of whose interests it serves is not answered by the technology — it’s answered by the design choices made before the technology ships.
By 2014, this had become the question I most wanted to answer in public.
Two futures
In September 2014, I got the opportunity to do a TED Talk in San Francisco. I opened with a scenario that I think still holds up. Imagine a social network that needs advertising revenue from diet products. To maximize that revenue, it feeds you articles designed to reinforce body image anxieties. When it detects a dip in your self-confidence, it pushes targeted advertising at exactly that moment. The platform gets its revenue. The client sells its products. You end up feeling worse about yourself. Everyone wins — except you.
Now imagine the same system, designed differently. Instead of analyzing your behavior without your knowledge and using those insights to engineer a response, it is open and transparent with you — it tells you what it has observed, what it has inferred, and what it intends to do with that information. It’s the difference between someone eavesdropping on your conversation and then using what they overheard to manipulate you, versus someone coming to you directly and openly telling you what they’re trying to do. And here’s the thing: the moment a system is required to be transparent about its intentions, the behavior of the system changes — not because the technology changed, but because accountability did. The act of having to disclose what you’re doing forces you to ask whether you should be doing it in the first place. US Supreme Court Justice Louis Brandeis captured the principle in 1913: “Sunlight is the best disinfectant.” It was true of government then. It is true of data systems now. Transparency isn’t just good for the individual being analysed — it is a corrective force on the organization doing the analyzing.
Same data. Same analytical capability. Completely different outcome — not because the individual gets more choices, but because transparency changes what organizations are willing to do.
I made the case that this was not just an ethical question but a commercial one: we cannot be successful if we exploit and manipulate the people whose trust and loyalty we are looking to earn. That framing was deliberate. Ethics-as-values arguments are easy to set aside when the quarterly numbers are due. But the deeper point isn’t just about commercial self-interest — it’s about the difference between capability and permission. Just because you can do something with data doesn’t mean you should. Transparency is the mechanism that forces that question into the open. An organization that has to tell you what it’s doing with your data has to justify it. One that doesn’t, never has to ask.
Privacy by design, in practice
The concrete example I brought to the talk was the IBM Enterprise Social Network project — the same work that had produced Project Breadcrumb and the enterprise graph analysis I described in the previous post. When I was asked to build a system that would analyze IBM’s internal social network, I made a decision that some colleagues thought was frankly unnecessary: before writing a line of code, we defined the philosophy that would govern every subsequent design decision.
Three principles. Privacy and personal autonomy at the heart of every decision. Openness and transparency with employees as a non-negotiable commitment. Personal empowerment — knowledge is power, and we would put actionable insight into the hands of all employees, not just management.
In practice this meant: employees saw their own analytics first and in full. Management could access aggregated analysis but could not drill down to any uniquely identifiable individual. What an employee chose to share beyond their own dashboard was their decision alone.
People told me this was too restrictive. That we were building a sophisticated analytical system and then withholding most of its output from the people who would make decisions with it. That argument missed the point. The output wasn’t being withheld — it was being given to the right people first.
The results were not what the sceptics expected. Employees who would normally have been suspicious of any management analytics system came to us asking to be included. They offered to share more data. The conversation about how to generate value from social and collaboration data changed completely — from something done to employees to something done with them. And the quality of the data improved, because people who trust a system engage honestly with it.
The most instructive example came from an advocacy program within IBM that wanted access to our analytics to identify employees to recruit into their initiative. When I explained that the analytics were private to each employee, they were initially disappointed. But when we worked through what they actually needed, we realized we could offer them something better than data: a mechanism to reach out to employees directly, explain the program, and let employees choose whether to participate. The recommendations we generated only included people who genuinely wanted to be involved. Not because we’d filtered the data — because we’d asked. The program was better for it.
The line from 2014 to 2026
What I want to draw attention to is how directly these principles map onto the architecture of self-sovereign identity and verifiable credentials — arrived at from a completely different technical direction, but converging on exactly the same answer.
The individual holds their own data. They decide what to present, to whom, for what purpose. The verifier receives what they need and nothing more. No intermediary sits between the person and the use of their own information. The privacy-by-design philosophy I was trying to build into an enterprise analytics system in 2014 is precisely the philosophy encoded in the W3C Verifiable Credential specification.
The technology is different. The principle is identical.
That continuity matters for how we think about implementing proof-of-work credential systems today. The temptation, when the employer is the issuer and the business case is obvious, is to design the system around the employer’s needs: richer staffing data, more credible client proposals, better talent matching. All of those are legitimate. None of them should be the primary design constraint.
A credential system designed around employer needs will produce employer-quality data. A credential system designed around individual agency — where the credential genuinely belongs to the person, where they control disclosure, where the employer’s interests are served through the individual’s interests rather than at their expense — will produce something more valuable: a trusted data ecosystem that gets richer over time because the people in it have every reason to engage honestly.
It’s a virtuous circle. It was in 2014. It still is.
Marie Wallace leads the Digital Identity Innovation practice at Accenture. She has been writing about the human side of data at allthingsanalytics.com since 2011. All opinions expressed are her own.
Marie's Ramblings & Ruminations 