Core data team at CARS24 is ~95 strong supporting businesses across India, Australia, Middle East and South East Asia working closely with stakeholders across business, product, marketing & tech. As well as, we even have ~25 data professionals within the CARS24 fintech arm, independent NBFC licensed lending business.

This write up is an try to answer steadily asked questions (especially from friends / leaders within the Indian startup community) around how the information function is currently structured at CARS24, line of pondering behind that and pros & limitations of the identical.

Disclaimer : Thoughts shared are personal & specific to the present context of CARS24 which can or may not hold for other organizations and will potentially evolve for CARS24 as well.

Let’s touch upon following points in the identical order — expected role from data function in a business; alternative ways by which the information team could possibly be organized; role of information engineering & ML Ops; ideal ways of working with other functions.

This largely relies on the data-savviness of the organization from maturity & capability of the information function to the approach of decision making by the business leaders.

As per my experiences & learning, below is how the role of a knowledge team evolves in a company.

Basic is the plain first step, followed by ability to dive deeper for .

As the information ecosystem matures, stronger leverage of statistics & data science gives to the business. This can also be the time when often (logging, pipelines, database / warehouse etc)gets further streamlined & strengthened. Data function evolves further when it moves from just predicting to next steps because the accuracy of the models improve & their impact on KPIs turn into clearer.

Eventually, when the DS/ML solutions get ecosystem, data function can truly own an issue statement end to finish, owning the ‘execution’ leg as well.

Centralized vs decentralized are self explanatory terms, and hybrid is somewhere in the center! Loads has been written about pros & cons of centralized vs decentralized team structures, and step by step everyone appears to be settling with ‘’ as the fitting answer — or lets say ‘easy’ answer, till we start trying to seek out that high quality line that should be drawn for ideal ways of working / relative prioritization etc

Conventional wisdom is that any technical / area of interest expertise that doesn’t necessarily require deep domain understanding and will be cross leveraged must be evolved as a central horizontal capability (enter f xcellence) e.g. Data/ML Engg, Product facing DS solutions.

Within the case of hybrid structure, the decentralized modules must be aligned with business function or central team depending on where the leverage is higher, i.e. if the analytics / insights team get more leverage through synergies with central DS/ML team they must be aligned with central data team and vice versa.

Data engineering often sits with tech function but there are also examples of information engg sitting with wider data function, former ensures proximity to the source of information & tech / production system while later ensures superior alignment with the top consumer of information (i.e. business / product analysts, data scientists etc).

At CARS24, data engg & warehousing practice was formally began by the CTO back in early 2019. A few of those responsibilities sit with data function now.

• There are a few tech-aligned data engineers who’re handling data transformations and click-stream ingestion in production ecosystem, while there are a few data-aligned engineers accountable for managed / custom pipelines, warehouse optimization, ELT procedures, data access control and back-end infra of dashboards.

We leverage managed solutions extensively to take care of a lean team. Nevertheless, we also know there’s a LOT more we want to do on this space than we now have done up to now.

Many organizations either expect data scientists to learn production ready deployment skills OR expect DevOps to grasp the nuances of ML workflows, each of that are relatively unrealistic. That is the rationale why most ML projects get significantly delayed in going live or worse never even see the sunshine of day.

Unlike software development workflows, ML workflows are non-standard (and evolving rapidly), they’ve model objects, data files, model formats and their compatibility matrix with underlined infra. There’s also the necessity of monitoring model performance, resource utilization, model & data drift. Hence, has emerged as a separate & very critical skill-set cutting across tech & data science realms

At CARS24, we now have a ~3 member strong ML Ops practice inside core data ecosystem which operates as a horizontal COE helping all of the DS modules efficiently interact with the larger production ecosystem. This team thinks ‘engg first’ and has strong ties with DevOps and dotted line to the tech leadership.

As a company we now have chosen to operate in a hybrid structure where Data Engg / ML Engg, Marketing analytics & product centric modules of DS (e.g. Magneto (end buyer reco / sorting algos), Auctoris (dealer reco)) operate as global ; while Business analysts & business sensitive modules of DS e.g. Profecto (pricing engine) & Fortem (fraud engine) operate decentralized and really closely integrated with respective business functions.

Current data ecosystem at CARS24 is heavily influenced by our philosophy of establishing ‘ML for business’, with data science team having direct & measurable impact on business KPIs vs constructing in isolation.

Below is a high level overview of how CARS24 data ecosystem looks like and deeper of how they engage with business, marketing, product & tech for India business, similar engagement is replicated across other geographies.

If we dive deeper, the constructing blocks of this structure are ‘pods’ / natural working teams that are focused on a given problem statement e.g. buyer top funnel , seller conversion, dealer engagement, refurbishment ops efficiency etc

A typical ‘ideal’ pod has dedicated folks from business, product, data & tech who’re responsible to make sure alignment on KPIs / objectives of the pod, relative priorities & timelines of various projects and establishing ideal ways of working throughout the pod.

As is the standard practice across most organizations, Product Managers ensure pod dedicated techies and tech lead (often spread across multiple pods) are aligned on BRD / PRDs, timelines & deliverables.

• Not very different from how often ‘Product — Tech’ work together, we now have also arrange ‘Analytics Lead — Data Science’ relationship at CARS24, albeit a bit less formal. A lot of the senior analytics leads at CARS24 have some prior experience with data science / advanced stats before they selected to go deeper into business / business side. Having them as an interface between DS & Business helps us create a really productive win-win answer for everybody.

are enabled through full stack DS team as they move from only providing data viz / custom insights to also execute & drive changes being plugged into production system through DS APIs.

give attention to problem statements & KPIs which are truly relevant for business, where analysts are capable of play ‘checker’ to the ‘maker’ data scientists.

Now while all these pods are relatively self sustained units and will ‘potentially’ operate decentralized, there are obvious upsides of ensuring data professionals across modules are connected through a central ecosystem including the information platform (data warehouse / ML engg) — this ties back to the ‘hybrid structure plugged into central team’ approach discussed in previous section.

below captures how the information ecosystem is plugged into different pods and still tightly interconnected together with the information platform providing data engg & ML engg capabilities.

I trust the write up above provides an excellent high level overview of how we now have been excited about the information org at CARS24. We’re still learning, unlearning and relearning as we go along the journey!

It’s a fast evolving world. And with the sort of exponential tech advancement being seen across data platforms (advanced data structures, storage & data access mechanisms), AutoML / Explainable AI (XAI) becoming increasingly more real, LLMs kicking in and prone to dramatically change data querying interfaces, and the upcoming ‘Infra as Code’ tools on ML engineering front we are able to expect to see very different kind of information org structures in a future not up to now. Latest ways of doing old stuff — faster / higher / simpler way.

Nevertheless, till we get there, all of us need to seek out our own answers that work for our specific constraints & context.