I’ve always been a curious fellow, wanting to know more details and always being intrigued by the hidden knowledge data provides. Other people like the knowledge, but not the data in tables & fields.  This is why I taught myself SQL: I wanted more information than canned reports could provide.

A list of skills & experience are at the bottom.


As I became adept at accessing data, I found just being able to extract it wasn’t enough because there’s garbage in it.  When I figured out how to get rid of bad data & organize the good data, it still didn’t tell me anything.  I had to organize it meaningfully into groups (segmentation) & start comparing it to itself (group A vs group B, MTM, YOY, etc.).  This whole evolution is summed up quite well using Legos.



When I started in the data analytics position at DealerTrack, it was 1 SQL contractor & myself. Over the years, I grew the department to 2 reporting analysts who handled 60 data requests/month and a reporting intranet site, which emailed thousands of reports to clients & employees each month. After seeing the benefits of providing data, I had my team learn how to pull data & perform reporting from Salesforce, Google Analytics, & Splunk.

We provided basic lists/tables, dashboards, scorecards, trending reports, executive summaries, pie charts, bar charts, & even ventured into maps.

We provided basic lists/tables, dashboards, scorecards, trending reports, executive summaries, pie charts, bar charts, & even ventured into maps.  I discovered this is incredibly complicated & our technology stack couldn’t handle our needs.  This was all provided using Microsoft’s SSRS add-in to Visual Studio.

In later years, I researched BI solutions to make better use of expanding amount of data.  My shortlist included Birst & Good Data.  My final pick was SiSense because it was a full stack solution (Tableau didn’t have a data integration component), you could upload new data sources on-demand, spatial reporting, linked/unlinked reporting, & a bunch of other features.  When I resigned, I was working on a project involving big data & Hadoop.


One of my favorite fancy visualizations is the alluvial diagram, here showing what & how much of each ingredient is used (left side), but also what & how many cocktails use each ingredient (right side).  It’s sorted by ingredient parts per cocktail.

At the 50k foot level, it’s easy to see gin & tonic has the most ingredient parts: 29 of tonic water & 12 of gin.  Also, tonic water is the most used ingredient (thickest line) & is also “monogamous” since it only goes to 1 cocktail.

More granularly, I see a little bit of gin is also in long island iced teas, along with lemon juice, gomme syrup, etc.  You eyes perform a bit of visual pong when looking at an alluvial diagram: left to right to left to right.

Digesting the above reminds me of the most valuable lesson I learned as a business intelligence professional: don’t lose the forest for the trees.  Always remember why you’re looking at the data in the first place, or you’ll get lost in it.  This is also important when communicating the results to your client.  It’s up to the analyst to walk the consumer through the story the visualization tells.


  • Medium, functional proficiency in SQL
  • Medium proficiency in data analysis
  • Expert in data visualizations
  • Expert in Excel