Analytics in Start-ups, and why I definitely do not work in one (And that’s ok)

Very strangely my analytics/data science/machine learning journey existed always in the team building phases, and so, the above articles hit me especially hard. At some point I will write a longform about my three year analytics / data science / machine learning founding member experience in a start-up style team within a large company as some form of retrospective. In a way, it’s kind of to remind myself what not to do, but I think in combination with the above articles, I can also create a career cookbook of sorts for myself. This is not too say I have a lot of experience or so, and/or people should copy it blah blah blah. It’s fun to write about things you have done! It’s good to be retrospective! And if it helps someone it is a bonus! I think here are some takeaways for the time being (especially reading these oh no this is so close to what I have experienced articles.):

Getting data-centric management

I think there is a common pitfalls teams can fall into in the planning and scoping phases: The management team thinks that we have an absolute data moat and untapped money, backed by statements like “data is the new oil!” Or “We have the behavioural data of thousands of customers!”. But on inspection they don’t know what data they exactly have, or in more interesting cases, don’t know where the data even is! In cases like this, I believe we have an executive body in the middle of transition to a data centric mentality, and just like every nascent thoughts, that needs special care.

To help your compatriots and management get to the data-first mindset, I think you need two radical ways of thinking: One, be ready to be a generalist. Not all problems have cool solutions, and not all questions need niche answers. Sometimes a team just need to be introduced to scripting and chronic! Sometimes, especially in a growing team, a data person needs to shoulder some engineering! Sometimes the data engineers need to understand the purpose and output of models to debug pipelines! The key thing here is, in this kind of situation where we have executive support but not a lot of direction, it really helps to show that the team can “Get Shit Done”. Or at the very least, show that analytics and data products can really bring in value. Although be warned that

Two, be ready to be a vanguard. I think part of this is as a professional you needed really see yourself as someone as a “tastemaker”. Within reason, you should be the one demonstrating what the good tools are, what are the correct approaches to development process etc. Evangelise what you believe in, and make sure what you believe in is suitable for team size and scale. It might step on some toes (For example, my forever disdain of Amazon Quicksight), but if you are correct, you can get the management team and your other colleagues much sooner on board to a data centric mentality with the correct tools and mindset. You also get to use your favourite tools!

Low-hanging fruits

Leading from the previous point of a management team, even the best, most advanced teams will have a bunch of low hanging fruits. Go do them! My favourite example is introducing a SQL based business team to use git to save all their queries instead of using a bunch of text file. It was such a simple and obvious thing but sometimes, if it’s not within their domain of knowledge it can get lost. There is no better way to prove worth by outsmarting tech debt. I do believe all interesting work requires some plumbing, and if your plumbing makes someone’s life better, that’s already way worth it. If you think you can do a data product without the “boring” underlying work, I have a NFT to sell you. So go identify issues and pain points in the data domain you are embedded in, and be “customer” centric. Go make their use of data natural and effortless! Your future self will thank you.

Tools are good, actually

That’s it. I think it’s that simple. It’s very infrequent you find a problem that needs a clean slate solution, and if you do, damn, I think you should go start your start-up!

What is a data team, anyways?

All data teams will eventually have an identity crisis, contributed by either the data team is doing too much, or doing too little. This is always the balance a data team need strike: is the data team doing too much heavy lifting and starting to do things a traditional engineering or business analysis team is doing? Or is the data team not being “seen” enough, maybe perhaps too hidden in experimental and prototype work? Neither is good, as it doesn’t generate the kind of value that will garner executive support. Ultimately, the team needs to be relatively clear about their raison d’être and what expertise they bring to the table, and work towards that as your core competency.

I think there are two great models for a data team non-exhaustive, obviously: embedded or data products. If you are embedded, you are a support function in service of your embedded team. So in essence, you are there to give them answers, or solve their pain points. With data products, you are the stakeholder for a data based product, and either engineering or business is in service to aid you to complete the delivery of the product. In both cases, clarity of who you internal/external customers are, and what the value driver is, will define the scope and plan of the projects and products.

All data challenges are just organisational challenges in disguise

and this is the key key last point. No challenge or problem or product or project exist in its own vacuum; they are all just symptoms of greater organisation challenges. Questions to ask around or yourself to gauge what the actual organisational challenges are from a data work perspective:

• Why is the data splintered across functions? What does that symbolise?
• Who defines long term data strategy? Do we even know?
• How would we bring value to external customer ASAP? How do we balance this with more long term work?
• How best could we defend our choices and decisions, especially when value is not immediate or obvious?
• When is technical debt technical cancer?
• Who supports us, do management see an actual path to value, or are we just a new keyword to fill?
• Is new fun SOTA ways of doing things the actual needed way? Do we need complex things?

And of course there is many more questions to ask to gauge maturity and readiness and support, but these are the soul-searching type questions I would begin with.

But more on this eventually in the long retrospective in building out a data product for 2-3 years.