Building a data function from zero in specialty insurance

Starting a data function from nothing sounds like freedom. In practice it is the opposite. There is no team to delegate to, no platform to extend, and every commercial leader already has a spreadsheet they trust more than anything you have not yet built. When I joined Volante Global as Head of Data Engineering and Analytics, that was the position: commercial reporting ran on spreadsheets, and sales and underwriting had little shared visibility of the book.

Decide the system of record before the platform

The first decision was not technical. It was which system would be the truth for commercial data. We made Salesforce the system of record. Once that was settled, the platform had a clear job: take what the business recorded in one place and make it usable everywhere else, rather than reconcile competing versions of the same deal.

Skip this step and you build a platform that faithfully reproduces your arguments. Every report becomes a debate about which source is right, and the data team ends up arbitrating instead of building.

Build one platform, and own it

The commercial data platform was built over Azure Databricks, Azure Synapse and Azure Data Factory, and I owned the Databricks platform. Owning it mattered more than the technology choice. A new function needs one accountable owner for the platform, its costs and its priorities, or it becomes a shared service that nobody can say no on behalf of.

The aim was to move commercial reporting off spreadsheets onto a single platform. That is a modest sentence and a large change. It means the people who built those spreadsheets have to believe the new numbers enough to stop maintaining their own, which only happens when the platform answers their questions faster than the spreadsheet did.

Ship something real early

We took the MVP live within 18 months. For a function starting from zero, with a platform to build and the trust of the commercial teams still to win, the MVP had to be narrow enough to finish and useful enough to matter. I led the architectural and dimensional modelling for underwriting, risk, actuarial and executive stakeholders, and worked hands on in Python, SQL and Airflow, including on custom predictive actuarial models.

An MVP in a regulated, relationship-driven business is not a prototype. It is the first time underwriters and sales see the same view of the book without a reconciliation meeting first. That shared view is what earns the function its next budget.

Add the reporting layer when the foundations hold

Microsoft Fabric and Power BI came afterwards, for reporting and analytics, and they sat alongside the platform rather than replacing it. The order was deliberate. A reporting tool on top of unreliable foundations just makes the arguments prettier. Adopting it once the system of record and the platform were in place meant the dashboards inherited trust instead of having to create it.

What I would tell a firm starting from nothing

If you are about to build a data function from zero, the order of work is the whole strategy:

1. Name the system of record for your most important commercial data before you design anything else.
2. Give the platform one accountable owner, with authority over priorities and cost.
3. Scope an MVP that the commercial teams will use in place of a spreadsheet, and put a date on it.
4. Add the reporting layer once the data underneath it can bear the weight.

If you are standing up a data function, or rescuing one that started in the wrong order, book a confidential introductory call.