Applying Musk’s Five Engineering Principles to Data Protection
The interview explored a number of interesting ideas (including the manufacturing and design process of SpaceX and its various rockets). Oneinteresting nugget to me was the discussion of Musk’s wider engineering philosophy, which easily applies to incorporating the data protection principles of Article 5, and Article 25’s Data Protection by Design and Default philosophy.
Musk’s Five Engineering Principles
First, let’s explore Musk’s five principles:
- Make the requirements less dumb: If you’re engineering a process, you’ve probably been given a set of requirements or instructions and told to do those. Don’t just accept the given design at face value – interrogate, ask why thing X or process Y needs to be there (and keep asking why). Simplify and understand exactly why each thing is necessary to get to your end goal.
- Try hard to delete parts or processes: This one is key. As humans, we bias towards adding ‘more’ just in case – ‘This idea seems really cool, and I’m sure we’ll come up with a use for it … someday’, we tell ourselves. Instead, we should be ruthless – if something makes no sense, or has no purpose, take it out. If you’re not clear on the process, take it out (and if the thing breaks, you’ll discover why it’s important and can put it back in again). Additionally, requirements or constraints need to come from a person – not a nameless department. You need accountability, and someone who can be asked why. Musk states that if you’re not trying to put things back in at least 10% of the time, you’re clearly not deleting enough.
- Simplify and optimise: Why isn’t this Step 1, you might ask? Musk explains that the pitfall of engineers is that they often spend a great deal of time optimising things that shouldn’t exist in the first place. Better to spend your cycles doing this after you’ve cut away all the fat of your product or process.
- Accelerate the cycle time: When you’ve done the hard work of items 1-3, emphasize the need for urgency. While the Move Fast/Break Things model sucks (particularly out the gate), the converse – where you lack a sense of urgency or purpose – can be equally damaging. But only do this when you’ve done 1-3.
- Automate: Once you get yourself to a minimum viable product, problems have been ironed out, and things are going smoothly, then you can work on automation.
Musk emphasized (repeatedly) that these five steps need to go in order – starting with automation before optimisation, or acceleration before paring down dumb requirements will lead to failure. Although Musk’s principles have their roots in manufacturing, the same ethos easily applies to data protection.
Max Profit, the VP of Sales at ResourceHumans, an online HR SaaS solution, wants the engineering team to develop a new fancy CRM and sales pipeline solution. He’s got a wishlist. Specifically, the new application needs to:
- Be the single source of truth for all customer record information.
- Integrate seamlessly with the sales team’s email, extracting all contact information, message subjects, attachments, etc.
- Integrate with ResourceHumans VOIP solution, so calls that match a customer’s number get added to their customer record.
- Use AI to pinpoint where in the sales process a deal is (prospect, lead, pre-contract, customer).
- Derive insights about the client, like when they access the ResourceHumans platform, what parts of the product they use the most, and sentiment they’ve shared online about the product.
- Automate and streamline the sales process through document prep, quote/proposal delivery, sharing onboarding materials, product marketing, reporting and contract renewal messages.
As you can see, that’s quite a list! If you’re the person tasked with trying to comply with the GDPR by implementing the principles of Article 5 and data protection by design & default, you’re probably crying into a beer at this point.
Let’s use this example as a means to apply Muskian engineering principles, with an eye towards data protection.
Make the Requirements Less Dumb
There is … a lot of dumb here. We should go back and ask the VP to explain the following for each one of these requirements –
- Why do you need this?
- What’s the purpose?
- How will this help your team do its job more effectively?
- What are the business needs that aren’t currently being met?
- Is this really necessary, or just nice to have?
While it’s easy to understand and appreciate some of Max Profit’s requirements, it’s important to have a clear understanding as to how and why data is being processed, and why it’s necessary. Is the sales team really going to be spending their days pouring over the data or more realistically just looking at the general contact details, the status in the pipeline, and then sending out proposals and follow-ups?
In the data protection world, this touches on the purpose limitation principle in Article 5(1)(b) and Article 25(1) and (2) of the GDPR – personal data must be collected for specific, explicit and legitimate purposes only, and that systems and processes should be designed with privacy by default.
Try Hard to Delete
Let’s say we convince Max to realign his requirements with reality. The next question is, what can be cut? The VP informs us that the CRM tool must be able to scour and extract customer details from Outlook. His people can’t be manually entering things, after all. It’s 2022, and they’ve got better things to do.
Fine. Let’s consider which types of data need to be extracted. Do we need the full message, or can we build in some integration to Outlook’s existing address book functionality or just extract relevant message details such as the to and from fields, the date and the subject? Can we create links to where the contract lives in SharePoint, as opposed to copying the document wholesale? Can we avoid collecting information about our customers from dodgy data aggregators entirely?
This approach means only data that is adequate, relevant and necessary is kept (Article 5(1)(c)) and ensures that the design of the system extracts only the data that is necessary (Article 25(1)).
Simplify and Optimize
So we’re starting to get to a more privacy-preserving CRM solution. Max isn’t happy, but he’s starting to at least come around. On to the next step – simplifying and optimising. Here, we need to look not just at workflows and productivity, but also data storage and retention.
We already discussed how to limit the data we store (by creating links to the contract’s source in Sharepoint, or by only copying limited information from emails), but we should also build in processes that enforce ResourceHumans’ retention policies, access controls and data classification. Instead of requiring a human to actually delete a prospect, we need to design processes for purging data after a fixed period of inactivity. We also should build in features that allow for easy compliance with a subject access request.
Step 3 is critical, and it covers a lot of what Article 5 (and Article 32) emphasize about data accuracy, security & retention.
Accelerate and Create a Sense of Urgency
While I’m not a fan of the techbro mantra of speed-at-all-cost in development cycles, I do agree with one point Musk has made – that of creating a sense of urgency (read: importance) about data protection and security. It’s very easy to understand why a sense of urgency–and a need to get a viable product to market– is critical when it comes to space exploration. But the same is also true when thinking about fundamental rights and freedoms.
But, this requires us to reframe what ‘urgency’ means. The concept of urgency has two distinct meanings according to the Cambridge Dictionary:
- the quality of being very important and needing attention immediately
- the quality of being repeated and determined in trying to get or do something
We need to develop a culture where all teams are thinking about the importance of protecting and securing personal data and being determined and empowered to do so.
Most of us think of privacy and data protection as a “compliance thing” – a low-priority, non-critical item, that isn’t revenue-generating, and only becomes mandatory if someone makes us do it. Sometimes, this mentality comes from a place of ignorance – people don’t know what “personal data” means or have a narrow view of who is a stakeholder — but sometimes it comes from a lack of clear prioritisation at the top. If ResourceHumans doesn’t empower their development team to think about data protection (through relevant training, tools, support, and shared knowledge), and leadership doesn’t promote data protection and security in the design process, there’s no incentive to make data protection urgent. Let’s fix that.
This ties into the principle of accountability in Article 5(2), and is fundamental to ensuring that Article 25 gets implemented at all.
Finally, let’s talk about automation. Automation can be a tricky thing. In the context of manufacturing cars, it makes a lot of sense. Once you refine the process of building a car, automation ensures consistency, scales up the time to build, and dramatically reduces the likelihood of human-created errors. But not everything can (or should) be automated, especially when doing so would take more time than it’s worth. As I’ve cautioned before, unless the problem you’re trying to solve is routine, ongoing, and something that will regularly take longer than a few hours to do, you’ll spend more time on the automation (creating, debugging, fixing, and yak-shaving) than actually solving the problem. And then you have two problems.
Still, there is a lot of room for automation with regard to ensuring that your technical and organisational controls, for example, are actually being applied, and for limiting the potential for sloppy mistakes to occur. For the CRM project, automation makes a lot of sense when it comes to drafting proposals to clients, and sending out reports internally, both of which have personal data. It minimises the potential for a data breach due to fat-fingering the to: address in an email, Similarly, automation makes sense when designing processes that apply data classificaiton, to ensure data is accurately maintained across systems, and that personal data is deleted (or otherwise made unintelligible) in line with retention schedules (Article 5(d).
Musk’s engineering principles, and the mentality he encourages at SpaceX, can easily be applied in terms of building in data protection by design & default principles.
 As always, there is a canonical XKCD strip that is directly relevant to this piece. https://xkcd.com/1205/