My first job in data was as a ‘Professional Services Technician’. It was for a business intelligence product company. They would sell a tool with a bunch of reports and dashboards that covered 90% of what customers would usually ask for. Then, inevitably, they would come back and ask ‘what about that other 10%?"

That was when my job would start. We would take the call from the customer, figure what they needed, update their system, log our hours to the ticket and call it a day. And if you got a saavy customer, they’d explain it quickly and easily so you could get it done.

But…. sometimes the customer wasn’t so saavy.

After I got some experience, they started assigning me to some of the more difficult cases. It was then that I started getting calls where the customer would tell me a story instead of telling me what they needed. “Well ya see, Darryl drives the truck on Tuesdays, and he usually comes in late cause he has to drop off his kids. Now when he stops in Norfrisbreejamboot there’s a stop with an extra pickup on account of the snow……..” I’d listen intently, take notes, and at the end of the call have no idea what to do.

So I asked one of the more senior guys on the team about it. I told him my story. I asked him what I’m supposed to do when the customer doesn’t actually know what they want.

He gave me the ‘you must be new here’ look. Then he gave me the best advice a data analyst can get:

“Look, they don’t know how the data works. If they did they wouldn’t hire us. Your job is simple. We have two tools, rows and columns. That’s it. So when they tell you a story, listen for whether it’s a row problem or a column problem. For the really tricky ones you might even need a tables, but that just means you need both rows AND columns. For example, customer wants totals for a special order type? Add a column. Customer wants returns excluded? Filter out rows. Customer wants to tell you a story? Listen carefully, but translate everything into rows and columns.”

So I went back to my notes about the trucker. Turns out the driver table in the database has a special route code they needed to filter on. It was a column. Only billed them for an hour.

As I got more senior, I kept this little analogy in mind. It seemed so simple, so easy. Was that really all there was to it? Then one of the new guys was having trouble making something work and came to me to see if I could assist. Then I saw it.

He was working on special order types, and unioned to a table to add more rows. It didn’t balance, it required a few hundred lines of sql and zeroing out a bunch of fields. It was a mess.

I gave him the ‘you must be new here’ look. And I passed it along with one addition:

And be careful never to mix up columns and rows. When you make rows when it should be columns or columns when it should be rows you are gonna have a long day.

And ever since then when an analyst asks me how to do something, I ask “Well, do you think you need rows, or columns?” And they usually think I’m being snarky, but I’m not. It’s all we have. Fix your row problems with rows, and column problems with columns, and you too will be a senior analyst.