The Human Interfaces of Data - Taylor

Taylor Brownlow of Count

This week’s guest is Taylor “Dashboards are Dead” Brownlow - yes, this term was coined long before someone paid X $million to put it up on the 101…

Taylor spoke at the first London Analytics Meetup I hosted at Lyst, last year (Meetup #5 is happening at Funding Circle later this month, on the 27th). This was the first time I met Taylor, but have been frequently bumping into her in the data scene since.

Taylor has been speaking more frequently and was one of my co-conspirators for MDS Fest. I’m always eager to hear what she has to say, and feel like we have many similarities of viewpoint and background.

---

Intro

I love this question, because it gives me the chance to reflect on how a Florida kid who hated math wound up moving to London and devoting her entire career to data.

Growing up, I was never a numbers person (and am still shockingly slow at calculating tips), but I fell in love with math when I took Calculus my senior year of high school. That class inspired me to study Industrial Engineering at Georgia Tech the following year. Industrial Engineering is a hodgepodge degree - you cover data, analytics, supply chain, logistics, systems engineering, and queueing theory. But, essentially, it's all about modelling and optimizing systems.

After university, I got a job at Intel in Portland, Oregon in their Supply Chain department. I was a Buyer of spare parts for the fab, which basically meant I had to convince grown men two to three times my age to deliver their dwindling inventory to me, not the other company. I found myself avoiding those tough phone calls and, instead, dug into our inventory data. It was here I became ‘the Excel Guru’, a title I’m sure nearly all data people have held at some point. I spent a lot of time building reports for our team, helping my boss make strategic decisions on new suppliers, and yes, being an IT help desk for whoever needed it.

Wanting to do more of what I studied in school, I got another job at Intel as an Industrial Engineer. I was hired to help optimize Facilities’ performance, but really what they needed was… you guessed it: a data person. I spent another few years building reports and helping people wrestle with the numbers.

I was being pushed into this field of data whether I liked it or not, so I joined the newly formed Data and Analytics team. This was my first time on a centralized data team, actually working with other data people. It was here I found a lot of the frustrations that fuelled many of my later ranting articles, but also where I learned loads about how to be a better data person.

After a few years on that team, I was ready for another change, so decided I would go back to school. I moved to London in 2017 to get my Master's Degree in Business Analytics at UCL. At the end of the degree, we were asked to complete a dissertation project in partnership with a local company. I was paired with Count Open - a small, 4-person start-up working out of a shabby shared office in Central London. I loved it.

[David Jayatillake - what made you ready for this change? Why did you want to move on from Intel? Why did you choose this particular Masters? What were your hopes upon applying for it? What were the highlights of what you learnt? Would you recommend this to people interested in entering analytics?

Taylor Brownlow - Professionally, I had been feeling a bit stuck at Intel. I wanted to try something new - in particular a smaller company where there were fewer politics to navigate and where I could explore different parts of the business. Without a Master’s degree, I found it difficult to get those jobs at that time.

As for why I chose that particular program, it basically came down to money and location. I was accepted into more well-known programs in the US, but they were twice as long and cost up to 4x as much as the program in London. I really didn’t want to take on that debt if I didn’t need to.

Probably my biggest motivator, however, was that I had always wanted to live abroad and this seemed like the best way to make that happen. Maybe it’s selfish, but I’d be lying if I said it didn’t play a large role in selecting London, of all places.

A final reason, which has only become clear to me upon recent reflection, is that this was the least technical data degree I could find. At the time, and still to an extent today, I felt like an imposter in technical spaces. Even though I had a technical degree and job, I still never saw myself as technical ‘enough’ for a pure data science or machine learning degree. I’m not one for regrets, but I do wonder what I might have chosen without that self-imposed limitation.

The degree itself is a bit of a blur. A year is such a short time to cover so much material, but, I do remember it covered a wide breadth of topics: from pure mathematical concepts behind Machine Learning (my favorite), to Marketing Analytics and a Python crash course. Our course director was very involved in the London start-up scene and had started a few companies of his own. This gave the whole program an air of pragmatism, which I enjoyed after a mostly theoretical academic experience up to that point. And it was this course director who helped us think through the types of places we might want to work, and how we could help ourselves stand out in those types of companies.

As for whether or not I recommend this kind of program, I think it depends on whether you want to be a generalist or a specialist. I am a generalist through and through, so this degree was perfect for me in that it exposed me to so many different parts of data and how it relates to different industries. For a specialist though, it would have been very frustrating. Do your best to know yourself and trust your gut.]

5 years and 1 company name change later, I’m still here. Today, my main responsibility is working with users to build and maintain a data product people love and value, and writing about it when I find the time. We now have an amazing analyst who keeps us in line and does the truly hard work with our data, but, for better or worse, I don’t think I’ll ever fully shed my data identity. [David Jayatillake - I feel the same and, for people like us, I think it’s just how we see the world. We’re still doing the analysis, it’s just somewhere else.]

Human interfaces that worked

Being an Excel Guru

Surprisingly, the first thing that came to mind when I saw this prompt was from my early days as a Buyer at Intel. We had a primitive set-up: I could get raw data by downloading reports from SAP or, when really desperate, use a janky internally-built interface for a data cube, that would let me filter and download a wide table of data. From there, I used spreadsheets to do analysis and create re-usable reports for people. Technically, it was a nightmare. But, on a human level, it was perfection.

Since I was on the team I was ‘serving’, none of the inter-departmental issues that data teams normally face were there. I didn’t have to win their trust, I didn’t have to extract requirements from them (their requirements were my requirements), and if they asked a vague question, I would just walk down the row of cubicles and talk to them about it.

[David Jayatillake - This is a big argument for embedded analysts. Taylor, where do you stand on embedded vs centralised vs hub and spoke?

Taylor Brownlow - That’s a surprisingly complicated question (or at least I’ve made it one). In my experience, embedded analysts and specialized data teams (e.g. Product analytics) are the happiest and most effective. Blending data and business knowledge is gold and any structure that lets you do that well is going to win in my book.

Of course, you can enable that using all 3 of those structures. For example, a small start-up of 100 people can still have a very personal and intimate relationship with their 4-person centralized data team, so it’s not a one-size-fits-all approach.

In the end, it comes down to which battles you want to fight. Separating the data team means you may have more data integrity issues, less efficient use of resources and code, and poorer communication up and down the stack. But to sever data from the business? That’s a much harder battle to fight, if you ask me.]

My favorite part about this time, though, was that in that role, I added more business value than any of my other data roles combined. I remember when my boss called me into a conference room with him and a few senior buyers to help them solve a big shortage they were navigating. They needed help running some numbers, and, just because I could use Excel, I got to be in the room with them. I got to help them think through different options. I never got to do that when I was actually in a data role. I chased that feeling for a long time, without much success.

[David Jayatillake - I think “being in the room” is key to adding more business value, as you described above. I have expressed my own opinions in this substack - why do you think it’s so important, in your own words?

Taylor Brownlow - Being in the room, to me, means your work has added value - it has contributed to something. The absence of this experience is soul-crushing. Who can stand building charts and dashboards without knowing why or how they’re being used? On a data person’s hierarchy of needs, this feel like a fundamental base need.

It’s not just for us, either. The rest of the room is better off when a data person is present. Our skills are undeniably valuable, and the outcome will be better for us having played a part. Why doesn’t this happen more often, David?

David Jayatillake - I feel like there are many possible reasons, some accidental and some purposeful, some well-meaning and some nefarious. Katie, Benn and I had a bit of a substack post thread going for a bit: Katie > Me > Benn > Me, which I think covers this really well. Especially, take a look at Benn’s points in the comments of the last post of the four and my responses, as I think we really get to the crux of it.]

In reality, there are many spurious reasons this setup could’ve worked so well:

1. The rose-tinted glasses of the past

2. Nothing I did was that complex and had to scale beyond more than a handful of people

But there are also some very valid reasons this interface worked, including:

1. I was a trusted insider

2. I had all the context that makes doing valuable analytics possible (I knew what they really wanted, because it was the same thing I wanted)

3. The team understood the value of having a data person on their team. They knew how I could help them better than I did

Going rogue

Later on, once I joined the centralized data team, my old teammates still messaged me for help sometimes. They knew they weren’t supposed to - all data requests were funneled through a lengthy (and useless) request form - which made the instances when they did all the more valuable. I knew they would only ask me if they really needed to.

“Hey Taylor, I need help. All my engineers are going on holiday this summer and I know we have loads of maintenance due in the next few months on our tools sets. Can you help me work out how many part-time contractors I should hire to cover their time off?”

I did these requests in secret. I knew that if I told my manager, she would go to their manager and they would be reprimanded like children (remind me to talk about the importance of good culture). But I enjoyed it for a few reasons:

• I didn’t care about making these outputs look pretty or pass the visual standards our data team had on outputs. This was quick and dirty analysis and it got straight to the point

• I got to work with the business. Most of the time, I only spoke to my requestor at the start and end of a request, but with these rogue questions, I could message them when I found something new - “Hey look at this!” and they would be just as excited as I was

• and yes, maybe the thrill of doing something I shouldn’t be doing

Interfaces that didn’t work

Data request forms

Oh man, request forms. I despise data request forms. Don’t get me wrong, I understand why they exist - how else are we supposed to prioritize the never-ending backlog of things people want from the data team? But I can’t help it, I hate them. I hate the way we take the form as gospel, using it as a way to punish stakeholders who ask for more. I hate how useless they are in actually telling you what someone really wants. And more than anything, I hate how, in the end, the truly important people don’t have to fill out request forms at all, and we magically find a way to do whatever they want, no matter what.

I’m firmly convinced data request forms only exist in order to maintain a culture of resentment and mistrust between data and business teams.

In fact, last year at Coalesce, I heard a speaker advise people to ‘make the request process as difficult as possible’ in order to give your team more space to do more data modeling. Couldn’t say it much clearer than that.

Dashboards

Are dashboards a human interface? We certainly use them as a replacement for human interaction, so I think it works.

I’ve said all I can possibly say on this subject here and here, so I will leave it at this:

Dashboards are good for operational reporting. That is about 10% of what a data team needs to communicate to the business. So, how are you doing the rest?

Compare and Contrast

Good human interfaces:

• were personal

• contextualized

• built trust

• focused on the problem, not the request

• made room for complexity and context

• took place when I had the same goal as the business

Interfaces that should have existed

I have two pet ideas of interfaces that I hope to one day exist - even if they are more science fiction than reality at the moment:

Data request meetings

I know, what’s worse than a data request form? A meeting about a data request form. But hear me out. One of the challenges with data request forms, and really between data and business teams, is that no one outside the data team really knows what the data team is doing. If we’re spending a week building a new table for marketing, no one, maybe not even marketing, knows what’s happening.

One of my friends, who runs a data team in utopic Sweden, runs a meeting every quarter with all the heads of business in the company. She runs through:

• what has been requested of the data team

• what she’s going to commit to in the next quarter

• she gets their approval on what she will decide to do (and not do)

The benefits of this are:

• transparency: everyone knows what the data team is up to

• respect: the business understands just how much the data team is doing and ends up respecting their time more

• natural prioritization: the most critical items to the business will be flagged in this meeting

We all need to do this, in my opinion.

[David Jayatillake - Do you think embedded analysts need to do this when they live and breathe what their team needs? I feel like, if they could just be proactive without needing their team to ask, it would be even better. I know this is idealistic.

Taylor Brownlow - Perhaps for embedded analysts it would go the other way - having a regular checkpoint with the data team. The main function of this type of meeting is to bridge the gap between functions. For a more centralized data team, that means communicating with the rest of the business (as is described), but for an embedded approach, where an analysts’ priorities are clearer, it could be more valuable to speak instead to the central data team in order to maintain that relationship.]

Let me solve problems

Being on a centralized data team basically spelled the end of my career of using data to solve problems. Many of us got into data because of our ability and desire to set data loose on real-world problems. So, can we get it back?

Maybe embedded analysts are the answer, or maybe there’s another way to formalize the process of my boss calling me into a conference room to help solve a problem quickly. Maybe by defining a space for problem-solving, we can give it room to flourish again. I loathe to formalize this too much (and thus kill the creativity required in problem-solving), but there ought to be time at the start of every data project where you are not working to complete a task, but looking to understand, generate ideas, and find the best solution possible.

What I’m doing to help

Count’s been trying to improve the interface between data and business teams for the last few years. Last September, we launched the first canvas for modern data teams. It brings together the power of a data notebook in the context of an infinite whiteboard, which gives data teams the flexibility to work through problems, rather than churning out dashboards.

Our goal is to help data teams be problem solvers again, by creating a space to think freely and work with others - data and stakeholders alike. We’re confident that data teams are going to need to find better ways to work better both together and with the business very soon, and believe the canvas is the best way to facilitate that collaboration. You can learn more about what we’re building here.