Jonathan Wilde on Building Engineering-Friendly Privacy Programs

What is your role, and how does it relate to ensuring data privacy?

I am a tech lead manager. And I've supported data privacy workstreams and programs at social media companies large and small.

‍

The role is fundamentally about facilitation across legal, policy, and engineering, where legal and policy come up with requirements for the organization. And as a tech leader, typically a manager, you help with the how, setting up the right safeguard, and how you make it easy for product teams to get by in trade execution across the organization, maybe these types of questions. 

Tell us about your approach to building privacy programs

I think that data privacy initiatives and data privacy programs shouldn't be zero-sum. It's not sustainable to be the team that just goes around only telling people to do more work or only goes around blocking projects. Rather, you want to achieve a win-win for the surrounding teams in your organization. Can you find cost savings for finance with data minimization? Can you make the website faster for consumers by reducing the number of third-party scripts and cookies that you're using? Rather than just installing a cookie banner and calling it a day? Can you make the developer experience better with things like data schematization? And of course, there are always trade-offs that happen. And when you have these moments, you don't want to just endlessly keep saying no or giving a vague reason, you want to highlight the risks to the product team where there is that trade-off in a way that's coherent, and makes sense to them. And we're collaborating with them as you brainstorm alternatives together.

How do you measure and prioritize data privacy risks?

So this always varies by product, the category that you're in, and the stage of the company's growth. So let's suppose for a moment that you're building a consumer mobile app and you're just starting out, you're one engineer startup, and your primary risk is actually that you just got the product wrong. So after you've shipped the initial best practices, you've got your delete button for the App Store, you got your privacy policy, and so on down the line, I'd really focus on customer complaints through support through App Store reviews through Twitter, and just get an idea of what are the privacy behaviors that are really surprising to your customers and prioritize those and making those better. And then, as you get a bit larger, you start to have issues with how you scale your best practices as you grow. How do you make sure that teams have deletion when they're supposed to, how do you keep your technical privacy systems working efficiently and correctly as you scale, you might prioritize anything from checklists to libraries, to alerting to the documentation, depending on what you're seeing with the reliability and the structure of your organization. 

‍

And as you get much larger, the risk shifts towards managing history and complexity, your code might be really old, and there might be lots of teams changing complex systems at the same time. And there are risks of promises being made five years ago, or even five days ago, getting broken by accident. And human processes really struggled to scale at spotting this both from an efficiency perspective and as well as an accuracy perspective. And it's critical to prioritize the technical safeguards and automation to make sure that you're keeping your obligations and commitments. And of course, this varies by sector as well. For example, if you're building a SaaS product, you might want to use your sales team is a canary in the coal mine? What are the privacy risks that are keeping your prospects from closing? Is it that you're missing SOC 2, is that they're looking for particular data retention pieces? And so your metrics and prioritization are always incredibly contextual, to your organization, your company stage, and the market that you're operating in. 

What’s one thing that has surprised you in your data privacy work? 

I think one of the really surprising things has been, while there are a ton of great data privacy educational resources targeted at legal and policy folks, there's a pretty huge gap on resources focused on engineers. And the ones that are out there today typically focus on the needs of midsize organizations where the demand has been in the past. But in this new world, where everybody really needs to care about it, regardless of their company size, you start to see a lot of those ideas fall apart as you try and pull them into startups or fast-paced massive companies as well. So in reaction to it, I've started a blog and newsletter about this. Super early days for the project, and I'm really excited to share more of the privacy engineering learnings that I've seen from being in the industry over the past couple of years and seeing the state of all, you can check it out it jwilde.me‍

What are some challenges you have faced, and how have you overcome them?

On challenges that the space is just, it's changing so fast, and it's a natural reaction. But when you go to a partner team say, hey, we need to go deal with this new requirement, they might be really surprised they might be this might be the first time they're hearing about this. They may not have dealt with this at a previous company. So it's unfamiliar. And that's natural. And so it's really important to work closely with your legal and policy team to prep concise explainers and engineer-friendly terminology for the why bypass, why are we doing this? What's the new law that's prompting a change, what's the intent of the regulators that are pushing for this. And once you get that communicated really well, it's much easier to get buy-in and get people engaged in the process than if folks are just told to do it just because.

What has been your experience engaging technical or developer teams?

Developer teams always want to make sure that they're prioritizing the most important thing and implementing the most effective possible solution for any project that they work on. And so once you've worked with your legal team and your policy team to articulate the why really clearly, I wouldn't just go off the bat and tell them to go implement a particular solution. 

‍

Rather, you want to make the process of developer enablement and the process of picking a solution and a strategy to deploy across the organization extremely collaborative, go around and ask different technical leaders in your organization who will have their teams impacted. How would you solve this, and you'll get ideas you hadn't previously thought of, which will make your developer strategy much better. And you'll also make sure that you have an incredibly compelling and crisp explainer of why your ask is the most important thing for the engineers in that part of the organization to work on and how the strategy that you worked with their leadership on developing is the best possible solution that makes the best use of their time. And, really giving them the context where you can work together. And it's a shared solution rather than a top-down mandate.

What are some best practices to share or pitfalls to avoid when trying to ensure data privacy?

The is to always align your privacy strategy, and your developer enablement strategy with the stage that your company is at. Startup solutions frequently don't scale to big company problems. And big company solutions can be too complicated or bureaucratic, implemented a startup. Let's take data mapping, for example, we all do that, as a part of our data privacy programs, the foundation of any data protection initiative is knowing what data you have. 

So if you're just getting started as one engineer startup, to be honest, the best data mapping approach is a password manager. 

‍

Every time you sign up for a new SaaS service, to build your product, you add that SaaS service to the password manager. And it's great because you're always going to remember to do that and keep that updated, or else you can't log in and build your products. And you can go ahead and annotate using tools like 1password to say, hey, oh, these things have these pieces of user data in them. And when you go to draft more documentation, you have that right there ready to go always up to date. As you get a bit larger, you obviously don't want to share passwords, the shared Password Manager is probably not going to scale too well. And your employees might be managing SaaS services instead of you. So you'll need to start cross-referencing more and more data sources probably starting with a spreadsheet. You might look at, for example, corporate card and expense spend to see what SaaS services your employees are purchasing. And that's easy for them to remember to update, they get reimbursed. Build a list of OAuth services that staff logged into via Google workspaces, they save time by using a one-click Login option instead of configuring more usernames and passwords. Or you might even look at key points in your code. 

‍

And as you get to much larger companies, this cross referencing strategy scales at first glance, but it becomes pretty tedious to manage manually in a spreadsheet. And luckily, there's tons of enterprise data mapping tools out there that will automate this for you and make sure it's done right. It's absolutely critical to make sure that you have the right strategy for your company size or you just can't get buy in from your leadership at your organization when the solution is poorly fitted for your stage. 

What predictions do you have for Data Privacy in 2023?

We're going to see the space continue to get more complex and in some ways, more fragmented. There's gonna be more state laws in the US mimicking GDPR and CCPA across more states, we're going to see more laws outside of the US, we're going to see also regulators get a lot more assertive around enforcement, and what that means for companies. And on the flip side, I'm really excited to see that there's more startups including Privado shifting data privacy left so that every company can rapidly ensure a high degree of compliance and product quality far more efficiently than manual work.

What does Data Privacy Day mean to you?

Data privacy day is an important reminder that a truly successful digital economy doesn't just mature on the side of tech innovation, but it also matures on being responsible for the data that we collect, use and store. The day to reflect and learn and explore ways to protect better the data that we use for our businesses. And embrace the fact that data privacy is not a zero sum game, that you can not just find compliance but also win-wins in your day to day work to support stakeholders throughout your organization. And that you can manage data safely while also enabling customers to have the absolute best experience that they can. Really excited about the state of the privacy space and how we're evolving towards a much more technical safeguard-driven approach over time. Really, really excited to see data privacy evolve in 2023 and beyond.