From Privacy Engineering by Nishant Bhajaria

This article series explores incorporating privacy into your design from the beginning using automation.


Take 40% off Privacy Engineering by entering fccbhajaria into the discount code box at checkout at manning.com.


See part 1 if you missed it.

Why do accomplished companies and brilliant engineers find privacy so hard? They have skills that lead to amazing products and growing profits–why can’t they plan for privacy success as well?

It is time to set some context.

Too often, companies that make a mess of privacy do so not out of malfeasance or even incompetence, but dissonance. Companies tend to assume that the same techniques that make their individual teams successful will be effective when it comes to pan-organization and cross-functional initiatives like privacy and security.

And sadly, too many hands-on technical leaders use terms incorrectly and therefore fail to appreciate what that means when it comes to changes to data protection and privacy. This subsection explains why companies ranging from SMBs to major businesses that are otherwise major trend-setters struggle when it comes to privacy.

The phrase “big data” is more ubiquitous than just about any other tech jargon, but often leaders don’t have an understanding how and why their teams need data, or how/if that data leads to beneficial business outcomes or even how one might find a balance between the risks and rewards attendant to data.

Just as privacy is connected to the human instinct of trust, we will connect privacy outcomes to specific decisions around data that your company makes. These are decisions around:

  • What data to collect
  • How to access it
  • Who to share it with
  • What use to put the insights that data allows us
  • How to manage the risks appropriately

This understanding of data and privacy will set readers up for the other chapters in the book, where will discuss processes, tools and teams that will help make your business successful while helping build and grow customer trust.

This article will explain how companies have evolved in terms of the innovation that occurs within and how the external world and its associations related back to the companies.

However, it would be helpful to set the stage for how work occurs in the trenches because the hands-on cross-functional leaders who drive privacy will need this information to implement the strategies and tools necessary for privacy.

When I first started my career as an engineer, programming occurred within a sandbox. There were limited data points, and defined, designed, and preordained outcomes. These made their way from top down and rank-and-file engineers executed against them. This execution phase lasted for a defined period of time after which it progressed linearly to testing and product release. FIGURE 1 shows clearly what was a very linear and predictable process and one that was inherently top-down.


Figure 1. Traditional Software Development


As FIGURE 1 shows, the company’s mission was highly determinative for what the company’s product roadmap was. The roadmap was then the source for specific requirements for products and features, and the engineering teams executed on that mission. The product was then targeted for release. In my earliest days as an engineer at Sprint, Intel, WebMD and other small companies, this is how things worked. There was no real feedback loop, where my ideas informed the vision of a roadmap. This was one of the reasons I gravitated towards product management, so that my ideas were part of the mix when the important decisions were made.

The upside of this model was that it was predictable and repeatable. The downside was that you could spend ages building a product and then wait for feedback in terms of market acceptance or rejection after having invested a lot of resources, but with limited ability to improvise along the way.

Later in my career as an engineer, the development process became more innovative, unregulated and unpredictable. FIGURE 2 paints a picture.


Figure 2. The modern dynamic innovation process


Towards the early 2010s, as trends like agile development and SCRUM started taking root, engineering innovation evolved as well. Companies could still adhere to the top-down development model, but right alongside that, as FIGURE 2 shows, teams and engineers could experiment with ideas and innovate in byte-sized chunks.

As you can see in FIGURE 2, modern businesses could build products in the traditional vein, where an SVP or C-Level leader could champion a product; their vision would feed into the roadmap that dedicated teams could dutifully execute. Concurrently, a team of engineers could explore a new idea, one that may or may not be related to the company’s known area of expertise. This innovation often occurs on a piecemeal basis, whereby small bits of the product are released incrementally for feedback. Each round of feedback generates possible new investment and feedback. Such projects often do not follow the typical processes around how data and IT assets are handled, for example.

In this new model, engineers and product managers could experiment with new products, atypical features and personalized offerings. If the idea failed, the cost was contained, and if it succeeded, the idea could flow into the larger roadmap and strategy. This flexibility is a double-edged sword; it breeds new ideas but could also make it hard to identify deviations from best practices in privacy and security.

There were other changes that were to come as the 2010s unfolded, and as an outcome of those changes, we are looking at a world where engineering is more dynamic, democratized and disorganized. The relationship between producers and consumers of digital experiences has been changed profoundly by four factors:

  • Explosion of social media, especially identities like Google and Facebook that allow users to access several internet platforms
  • Rising penetration of internet connectivity, especially in more densely populated countries that are becoming more prosperous
  • Easier access to mobile computing with various types of mobile devices and
  • Faster data storage and retrieval capabilities powered by cloud storage vendors

As a result, engineers, product managers, designers and data science experts are able to build products much more incrementally, push them out quickly and learn from them rather than waiting for leadership input every step along the way. Touch points for senior technical leaders occur after several tactical decisions, advances and retreats. These touch points also occur in silos: on a per product or per geo or per business line basis.

This mode of operation has produced a product windfall: accelerated timelines, more choices, increased responsiveness and personalized products and at times even lower prices. Decentralization, at least to a significant degree, has shown a positive correlation to innovation.

CALLOUT  Unlike the 1990s and the 2010s, the modern software development process is more incremental and chaotic and a lot less predictable. This means faster development but can cause more privacy challenges, since knowledge and authority are often fragmented.

This dynamic also removes visibility from executives and their technical leaders of all the smaller decisions that lead up to any particular status quo. And it complicates further the task of centralized teams, since their plans have to account for the implications of all these decisions across several disciplines and several times over time.

This is why privacy is hard, and we often end up with a scenario where the innovation and speed of development bears an inverse correlation to our ability to provide privacy and security to our customers.

“How did we get here?” is a question whose answer derives from this set of dynamics.

This is especially the case with privacy, where many companies do not think of privacy as an early investment. Quite simply, the habits and processes that lead to business success in tech are not suited to provide for good privacy practices. This book helps reconcile this tension by teaching hands-on privacy skills to cross-functional technical leaders, and ensure that innovation and trust go hand in hand.

In order to understand how these high-level strategic directions map to operational decisions and details, part 3 describes a scenario around how data and decisions around it could help and then hinder your company, its growth and its relationship with customers.

If you want to learn more about the book, you can check it out on our browser-based liveBook platform here.