The Analytical Engine:
operational leadership
entrepreneurial execution
ambiguity navigation
“You took initiative on problems I didn’t even know we had. I appreciate how you push back and guide me towards better ways to think about the business.”
I was brought in to answer basic business questions for a four-person health tech startup that had no formal analytics function and relied entirely on their single engineer to pull metrics through ad hoc queries.
My role was to build a scalable, self-serve analytics infrastructure that freed leadership and operational teams to make data-informed decisions in real time.
The Problem
When I started working with the startup in 2021, the CEO depended entirely on the company's single engineer to pull metrics for weekly standups, monthly all-hands, and strategic decision-making. These requests were technically accurate but often misaligned with business definitions or applied inconsistent filtering criteria, making comparisons unreliable over time. There were no documented standard definitions for key metrics and no transparency into how numbers were calculated. The process was slow, non-repeatable, and created a bottleneck: the engineer couldn't focus on product development, and leadership couldn't move quickly on decisions. The Community team had no visibility into user behavior without going through this same request process. As the company grew from four employees to a seed-stage team of six employees, four contractors, and three interns, this ad hoc approach became completely unsustainable.
The Solution
I requested read-only access to the transactional database and began answering business questions directly using SQL. Since no documentation existed, I created a data dictionary by reverse-engineering table relationships and documenting business logic as I encountered it. After about a year of manual query work, I identified Metabase as a tool that could enable self-serve reporting and secured a $1,000 annual budget by demonstrating to the Chief Product Officer how it would free up both my time and engineering resources. I built interactive dashboards starting in late 2023, beginning with the Community team's most frequent requests: user search, activity summaries, and behavioral tracking. By January 2024, these dashboards were in active use for weekly standups and monthly reporting. Throughout 2024, I developed reusable analytical layers — transformed tables with business rules pre-applied — so that future queries no longer required redundant filtering logic. This created consistency in how metrics were measured, dramatically sped up the process of updating business definitions, and ensured robustness: when business rules changed, I could update them once in the analytical layer rather than hunting down and modifying dozens of individual queries. Before implementing Metabase, I held an analytics summit with the CEO and Chief Product Officer where we mapped out all the parts of the product we cared to measure and jointly defined metrics, aligning on what was included, how calculations should be done, and surfacing gaps in our data capture. The system enabled the CEO to make pricing decisions based on my analyses, supported partner reporting that strengthened external relationships, and allowed operational teams to access the data they needed without depending on engineering.
Core Skills Leveraged
-
I approached this work with constant awareness that whatever solution I built needed to both adapt to changes and scale as the startup grew. The Community team had been downloading "server reports" with all activity history and manually formatting them repeatedly in Excel to get answers—clearly inefficient and unsustainable. Having me manually run queries to answer everyone's questions was also unsustainable.
Metabase offered a scalable solution that would streamline everyone's data needs by cutting down on unnecessary manual work. I drove adoption by focusing on the highest-frequency pain points first, so users immediately saw the value and switched to using the tool because it made their lives easier.
I built analytical layers because I saw that this approach would ensure metric consistency as the business evolved, product features changed, and new team members joined. I had already experienced many business rule changes and business model shifts firsthand: subscription models tested, user definitions refined, product launches altering the data structure. I wanted to build a system that could absorb those changes without breaking downstream queries or requiring wholesale rewrites. I was struggling to keep track of which queries included which business rules and would be affected by changes. I knew we needed better data infrastructure sooner rather than later, and I wanted to lay the foundation with a solution that would continue to adapt as the business grew.
-
With no formal authority in this organization, my influence came from credibility, strategic framing, and relationship-building. By studying the data schema independently and producing defensible metrics, I established myself as someone leadership could trust when they needed answers. I showed that I was a thought partner in measurement strategy by engaging in conversations with the CEO about her questions. When the CEO requested metrics that weren't feasible or wouldn't actually answer her underlying question, I pushed back and reframed the conversation around what decision she was trying to make. This often led me to propose alternative metrics that better served her actual needs. To secure budget for Metabase, I knew having an internal champion who understood both the technical value and the operational cost of the status quo would strengthen my case. I invested time demonstrating the tool's potential to the CPO, who then advocated on my behalf. Throughout this project, I was constantly translating technical concepts into business value, building coalitions, and creating visibility into my work so stakeholders could see the impact and trust the system I was building.
-
This entire endeavor was born from my identifying a problem, designing the solution, learning how to improve it, and building infrastructure that democratized data access. I was never asked to play a role in analytics — I simply saw how frustrating it was to ask the sole engineer for metrics and how much time was wasted in each discussion clarifying filters and exceptions. I requested database access because I wanted to support the CEO's decision-making with more transparent metrics. Once I had database access, I systematically reverse-engineered the schema, occasionally asking the engineer clarifying questions but largely working independently to understand what data we had and what we could measure. This deep understanding allowed me to participate more confidently in conversations about metrics, set realistic expectations, and guide leadership toward better measurement approaches. After we adopted Metabase, I continued checking in with the Community team to improve their experience and eliminate more manual work as the business evolved. When I noticed I was repeatedly writing very complex queries and having to hunt down broken queries after each product change, I reached out to my network to learn how mature companies handled this problem. I decided to undertake the painful process of rebuilding all existing queries based on new analytical layers because it was the right thing to do to ensure the scalability and sustainability of the business's analytics capabilities.