Purpleglots and Unicorns
How can data people become technical co-founders?
What’s a purpleglot, you ask?
Let’s start with the purple part: Anna Filippova references a metaphor shared with her, in this now well-known article in the data world:
humans with a deep understanding of business context in a particular domain are called red people ❤️. And humans with a breadth of technical expertise are called blue people 💙. Purple people 💜 are the people in between — they have a little bit of both that enables them to translate between red and blue
I really identify with being a purple person - I’ve had to learn whatever it is I needed to benefit the organisation I'm helping at the time. In terms of languages, that includes SQL/dbt, VBA, R, Python and, most recently, a bit of Typescript. I am, of course, nowhere near a master at any of them apart from SQL/dbt, which has been my go to tool for the last 10/3 years respectively.
In recent times, the term “polyglot” has arisen in technology, relating to the use of multiple languages in an environment to solve a problem. However, it is derived from a linguistic definition of people who can speak many languages.
Can data people who aren’t necessarily geared towards product or executive roles be successful technical founders? If purple people move a bit more towards blue without losing their overall sight of the problem, would it allow them to be a technical co-founder such as CTO or founding engineer of some kind?
I feel like we’ve already started to see some people in the data world do this - they wouldn’t identify as software engineers, but have learnt to do the software engineering required to get a product to MVP and beyond. They are still data people at heart and have kept their SQL/dbt, Python or R data skills, but have perhaps picked up some other languages, concepts and frameworks needed to make a product, hence the term “purpleglot”.
Modern data frameworks have helped data people become familiar with concepts such as version control, CI/CD, DRYness, reproducibility, idempotence, modularity, state management… all of which have exposed elements of software engineering to these data people. I would argue that learning these principles inside of these frameworks has more effectively introduced software engineering principles than using python/R in notebooks or data science workflows.
I’m really passionate about data people being able to be technical co-founders, not only because it’s an option that I would like for myself, but because I think we have so much to give in the technical space. Thinking about the architecture of a product from a data perspective and not just a feature-driven perspective can be really valuable in many contexts. If data is the new oil, designing a product from the ground up to take care of data makes sense; allowing for analytics and ML use cases earlier in their lifecycle will be a competitive edge in current and future companies.
Data people are probably also more likely to have a commercial drive to compete in the market than traditional technical leaders, who can be a bit divorced from the commercialisation of the products they help build. Great data people want to use data to help their orgs compete more effectively and develop great strategies.
I have also seen, on a few occasions in my career, that data people often have a better concept of making bets for reward than other technical leaders who may optimise towards cost reduction or risk reduction. Many data people are used to thinking in terms of statistical risk models. We come to work to take capital risks, with the aim that the cumulative expectation of profit from those risks is net positive. You need to be at least a bit of a gambler to be in business: if you can't cope with risk at all, you're probably better suited to the public sector, which isn't specifically focused on risk/reward cycles.
Why do I personally want to do this?
I grew up in London, a city which, when I started my university education, was quite stifled by established institutions mostly organised in general alignment with the class system. The recession came and was used as a reason to not elevate employee wealth. Employees once again became serfs after a very short time of being treated with any value, and being able to genuinely live well. The established companies collectively allowed real wages to stagnate along with the public sector having wage freezes. This system was in desperate need for disruption.
One reason tech startups disrupting markets full of established companies is a good thing, is that it breaks down barriers. Ultimately, you need to be able to perform at a very high level to make it and that has nothing to do with class, gender, race, levels of introversion/extroversion or social status. The story of tech disruption is one of triumph of the underdogs, with which I can identify. Before the recession, graduates applied for internships at established large corporations, now they want to work for Monzo, Deliveroo, Revolut, Wise… the list of tech unicorns goes on.
I know that the term “disruption” has had a bad rep in recent times because of the effect on worker job stability, but as anyone who has been made redundant by a large corporation will know, there is no such thing as job stability. There is only security to be had in being able to solve problems that are worth solving. Disruption itself only occurs through solving a problem, and also in making existing problems easier and cheaper to solve. Imagine if R and Python for data science never happened and we were still stuck with SAS, with ever increasing license costs and little improvement in service.
I feel that disruption in a commercial context is the equivalent of natural selection in a biological context - it’s healthy and necessary: for redistribution of wealth, to prevent monopolies and oligopolies, to reduce nepotism and to stop generally poorly functioning organisations from surviving.
