Data Operating Principles

Data leadership playbooks or operating principles?

Embarking on a Head of Data role without previous leadership and people management experience was a challenge interesting enough. Having made a bunch of mistakes and another bunch of good calls, I think it is a good time to write about the experience in the hope that I will have learned something through reflection. Also taking this leap of courage to publish, as some people may who have already been on a similar journey, or are preparing to embark on one might find it a useful input.

The fallacy of playbooks

Before jumping in to the principles, I have to confess I was originally heading somewhere else with these ideas. I had been working in my head the idea of writing a “playbook” for bootstrapping Data teams. In my head, a playbook could be a workflow, or a sequence of actions that can be applied by others in arbitrary commercial environments. But now I think that this would have made no practical sense; technology, market and organisational circumstances are constantly in flux. Moreover no two companies face the same challenges at any given time; companies are high-dimensional dynamical systems of people (mostly people, at the time of writing) with all the unpredictability that brings.

The catalyst for my change of direction was observing leaders in Engineering and Sales fail miserably in making their own self-advertised out-of-the-box playbooks work in a new context. I now think that such playbooks amount to lazy solutionism that tries to provide a silver bullet to avoid the painstaking process of discovery; ultimately a sign of a fixed, rather than growth mindset. As a side note, this pipe dream of blissful automation, which eliminates the need to think deeply about problems is also central to SaaS enterprise sales tactics. That is a topic for another day though.

A useful analogy to illustrate the mental model further can be found in gaming. Any gamer who has played Civilization or Age of Empires knows that it is generally a bad idea to reuse a strategy blindly when starting a new game - even when picking the same civilisation with the exact same strengths. What matters most is adapting to unique game conditions - which are discovered over time through painstaking and dedicated effort to open up the map and clear the “fog-of-war”. Incidentally, this aspect of gaming excites me the most.

Operating Principles are better

But whilst a playbook will be too overfitted to be useful, codifying experience is still a highly worthwhile thing to do. Doing so with higher level principles is the way to go.

Now, I hazard that most of people would have a hard time defining what the word “principle” means: for example, can you confidently say what the difference between “principle” and “value” is? What about “maxim” and “aphorism”? The internets are certainly not in agreement. I feel that “principle” is a bit too grand a concept to use in the context of this essay.

So: I will escape this rabbithole by adopting the term “operating principles” for my list of .. Operating Principles I share below. They should be viewed as useful, context-bound and prone to revision rather than some immutable truth.

In further support of OPs, I have indeed observed leaders apply them with success at their new workplaces in a way that takes into account the nuances of the new environment.

As a disclaimer, this is not an attempt to replicate the DataOps Manifesto, nor have I embraced a specific framework such as Ray Dalio’s for coming up with these OPs; but I will admit to having been influenced by both pieces of work (and to a lesser extent by Kevin Kelly’s Excellent Advice for Living).

Alex’s list of Data Operating Principles (updated: Jan 2024)

1. Embrace the process of discovery and keep an open mind
2. Instil product practices such as discovery, MVP, releases in all Data work
3. Early wins: minimise time-to-value when starting new work to get the wind blowing behind the sails
4. Technical skills should always be polished: occasionally shipping non-critical path work is a good idea
5. Domain expertise trumps technical expertise
6. Be excellent at context-switching but retain the ability to do deep work
7. Recruiting well is the highest leverage activity there is for a manager
8. Documenting a data strategy early is important but do not overcommit
9. Document a Data Capability Model as early as possible
10. Never stop working on becoming a better manager for your team
11. Without a C-suite cheerleader, it will be an uphill battle
12. Nurture the very different CPO and CTO relationships; you report to both even if it does not say so on paper
13. Be flexible on team topology; people’s specialisms are fixed but their deployment in the company should be fluid
14. Market Data capabilities relentlessly internally and externally
15. Stay aligned with Engineering practices: do not reinvent the wheel where possible
16. Continuously educate on the differences between observability and Analytics: it never goes away
17. Get the Data team to a “full-stack” state as soon as possible
18. Personally deploy some work to production as soon as possible
19. Carve out regular time for documentation and build a strong culture around it
20. KPIs are incredibly useful; embrace sooner rather than later
21. Establish consistent technical vocabulary for communicating with stakeholders: educate on performance metrics and non-functional requirements terms
22. Data people and back-end engineers need time and help to collaborate effectively together
23. Get all data sources in the business mapped out
24. Simple apps (like Streamlit and Gradio) are the best way to showcase data capabilities and API features
25. Engineering-Data duality: Data Engineers and Machine Learning are 100% Engineers and 100% Data people

Acknowledgements

Thanks to my colleague Derek Lakin and the writings of Paul Graham for inspiring me to get back into essaying. Derek made me realise that taking the time to reflect in written form is an absolute life and career hack. I will not use any AI here: this would completely defeat the purpose. So, if it’s a terrible read, do let me know, as I would selfishly like to improve my own neural network with your feedback.