Herding Cats: The Cross‐Functional Domain Your Privacy Program Runs On

It’s 4:37 p.m. on a Tuesday. A product manager drops a “quick question” in Slack: “We’re launching the new onboarding flow tomorrow. Can you bless the data collection language tonight?”

Before you can respond, security pings: “New logging pipeline goes live this week. Can we store full request payloads for debugging?” Marketing wants to “just add” a new pixel for a campaign that starts Friday. Procurement forwards a vendor contract with: “They need signatures by end of day. Can you take a fast look at the data terms?” Support asks whether the new CRM integration changes DSR search scope.

If this sounds like your average Tuesday, you may have a Herding Cats issue. These teams not trying to make your life difficult. They’re trying to ship. And you’re trying to keep the program from being paper strong and system weak. This is the part of privacy work you won’t find in IAPP textbooks. There is no privacy domain that tells you how to implement cross-functional relationship management into your privacy program.

Sure, we all know that cross‑functional collaboration is the daily reality. Privacy decisions are often implemented by other people, in other systems, on other timelines. It’s not glamorous, and it makes you feel like your privacy team is trying to butt into or manage another function’s work in a way that interferes with the rest of their job. Unfortunately for all of us, it’s often the difference between a privacy program that exists in policy and a privacy program that exists in reality.

I call it the Herding Cats Domain.

I don’t say this because your colleagues are “cats” that need to be controlled. They aren’t cats because you own them and need to make sure they are fed and given scratches. I say this because they’re independent. They have overlapping goals, different language and rhythms. You might sometimes feel like your job as the privacy function is to impose your will on them, but it’s not. It’s to make it easy for other functions to do their work in a way that still satisfies privacy requirements and to make sure privacy decisions are informed by technical and operational reality.

One of my biggest challenges as a privacy lawyer advising clients is to make sure my privacy team clients have the skills to engage with their own herd of cats in a constructive and effective way. In that sense, I literally coach their privacy teams on cross-functional cooperation. I try to make this type of non-legal advisory coaching available to a broader audience through The Privacy Design Lab, specifically the Design Studio membership. I’m bringing some of that knowledge to you today, although if you think you need privacy coaching for your cats, check out The Privacy Design Lab Design Studio membership, because that’s a cost-effective way to get all of these insights and more trainings specifically on this aspect of cat-herding.

The mistake most teams make is assuming the solution is to have better communication. Communication is important, sure, but if your structure is weak, all you’ve done is schedule more meetings to talk about the same ambiguity. Cat-herding gets easier when you stop trying to convince every cat to love governance and instead build a path that makes it hard to wander off.

You don't have to read everything — just the right thing. 1440's daily newsletter distills the day's biggest stories from 100+ sources into one quick, 5-minute read. It's the fastest way to stay sharp, sound informed, and actually understand what's happening in the world. Join 4.5 million readers who start their day the smart way.

Join for free today!

When a privacy change touches multiple systems, the default organizational behavior is to diffuse responsibility. It’s nobody’s fault because it’s just how matrixed companies work. But privacy suffers because compliance is judged on the outcome, not on how involved everyone felt along the way.

Two things usually go wrong:

The result is what I call the baton drop. A project appears to be progressing (there are meetings! there are notes!), but it stalls the minute you need an actual operational change.

If we have a domain for it, we can design a workflow to manage it. In the workshop framing, design is why we separate the steps. Before you build anything, you do just enough design to prevent rework. I've broken this out to align with the Privacy Change Engine framework (check out the workshop link above to get the full download on the Privacy Change Engine):

Cat-herding becomes manageable when you convert a fuzzy “privacy issue” into concrete workstreams that a specific role can own. And I don’t mean privacy can own. I mean system and function owners. These include real workstreams that look like, for example, the following:

Once you do that, people can opt into a real task instead of a vague responsibility cloud.

Rule 1: Roles, not names.

If your current process is “ask Sarah,” your process will fail the second Sarah has a vacation, a promotion, or a life. Use roles because roles are durable. “CRM Admin” survives role changes. In my experience, that one person who knows where all the bodies are buried will inevitably leave the company and stop answering your requests for assistance.

Rule 2: One accountable owner per workstream.

Shared accountability is how you get stellar meeting attendance and zero deliverables. One “A” on the RACI matrix doesn’t mean one person does everything, so there’s no cause to freak out if you end up in that little box on the spreadsheet. All it means is that one role owns the outcome and will chase dependencies.

Rule 3: Always capture system owners.

Ask, explicitly: “Who can actually change the setting? or “Who distributes operational updates?” If your accountable owner can’t access the admin console or updated the processes with the team, you’re not done. The system owner might be different, and that’s perfectly fine. What’s not fine is discovering that in week three of a three week project.

Rule 4: Decide escalation triggers before the panic.

Escalation is a design feature. If a change involves sensitive data, minors, cross-border transfers, new tracking, AI model training, or a compressed contract deadline, you should pre-design who gets pulled in and when. Otherwise people will over‑escalate (gridlock) or under‑escalate (regret). 

It may seem like the most annoying part of your job, but here’s the encouraging part. If you feel like you’re herding cats, it usually means your privacy program is doing the hard work of crossing functional boundaries. That’s what mature programs do. Immature programs look calm because they aren’t integrated. (And calm is not the same as compliant.)

The goal isn’t to eliminate the cats. The goal is to build a repeatable operating pattern where the cats can roam, but the work still lands. So instead of trying to abstract buy-in from individuals, you build a system that makes it easy for stakeholders to contribute:

That’s how you turn “privacy slows us down” into “privacy is how we ship without regret.”

Finally, reminder that the opinions expressed in this article are the opinion of The Privacy Design Lab. They are not legal advice, and no attorney-client relationship is formed by reading this article or downloading the 10-Minute Cat-Herding Brief. If you need to consult legal counsel, you can book a consult with ARLA Strategies or other legal counsel you trust!

If you’re tired of privacy advice that only works in theory, you’re in the right place.

The Privacy Design Lab exists for people who want to practice privacy, not just talk about it. It focuses on practical, repeatable ways teams actually learn. We offer hands-on workshops, downloadable systems, and the Design Studio community where teams and practitioners can go deeper. Paid Fieldnotes subscribers get access to our full archive, plus supporting materials you can actually use.

If that sounds like your kind of work, we’d love to have you.