Remembering how the journey can be the work

I did a thing I literally haven't done in over a year thanks to house chaos stuff. I took a day of vacation! So I'm a bit behind on the conference program, but expect announcements later this week.

Data science work typically comes from an Engineering perspective. While modern tooling has reduced the boilerplate work significantly, a decent amount of the work still requires writing code and managing systems. What this usually means is that we pay a lot of attention on getting things done. A project is done when the report is sent out, a broken pipeline gets fixed, or when a feature launches. There's a clear deliverable that signifies completeness.

And since we as a group are steeped in data and code, efficiency is often a consideration. Now that we delivered "the thing", can we make it so that it is less hassle? Faster? Easier? Cheaper? These are very natural questions to ask given what we do all the time for work. In the same vein, other engineering teams do very similar things – they're very goal focused because the deliverable is the goal. It's the reason we do the work in the first place and honestly the details of how the work is done aren't very important.

But there's a class of problems where "the end goal" isn't the point and the process of getting to the goal is actually the most valuable thing .

An everyday example of this is writing up a personal budget. The task is to write a derailed accounting of how much money you earn and spend on a typical month. But if you've ever sat down and written one, you quickly realize how writing an "accurate" budget is almost impossible. Most of us can't pinpoint every last penny we spend in a week or even day. We shop seasonally. Utilities and other bills can fluctuate for all sorts of reasons. All the financial professionals that tell people they need to write down their budget knows that it is an actual "impossible" task. The advice is then to make estimates and do the best you can.

Everyone who writes down their budget will, when finished, say that their budget is only a rough approximation but they're happy that they went through the exercise anyway. By being forced to collect and sum up all their income and expenses, they're forced to face the reality of what their cash flow looks up. It becomes obvious if cash flow is negative. It is also easier to find places to adjust the budget when a problem arises. The process is the whole point of the exercise.

The main difference is that for budget tasks the goal is to cause some kind of change in people, the deliverable is merely a guiding star that leads people towards a given journey. The problem is that it is not obvious at the start whether a given task is one or the other. Sometimes you don't want the participants to know that they should be paying attention to the process instead of the result.

So why am I harping about this in what is nominally a data newsletter? Because sometimes in a UX organization now, I learned that there's a bunch of things that I need to convince people of, which is very difficult to communicate without essentially direct experience. I can do as much analysis and make as many charts as I like to explain that the median wait time on hold is "15 minutes" but it is impossible to express how your brain wants to explode already after 90 seconds thanks to the horrific hold music. Such pain needs to be experienced to make an impact and change decisions. Otherwise, 15 minutes sounds like a short trip to the store and is thus "not a problem".

More recently, I was leading some workshops to get some Eng teams to use a product feature like our customers do (to bump into all the rough spots). We do this pretty often now because, again, there's no substitute for directly experiencing pain to fix. But then an engineer playing with some LLM tooling managed to get something of a workflow that let the LLM bot walk through a bunch of steps and write down the "pain" it experienced. While there's a bunch of limitations in the process, it does "work" in a very limited way. And predictably, some folks wanted to know if that process could be scaled out and then the whole workshop process becomes unnecessary. Then teams can go back to writing code and shipping new features even faster!

Obviously, the answer from all of the UX teams was 'no' because that final generated report wasn't the point of the exercise to begin with. If writing the same issues down on a piece of paper would've gotten them fixed, we wouldn't be resorting to inflicting the experience on people as a way of convincing them it is a problem to begin with. We want developers, product managers and engineers to have the visceral sense of horror if they even consider putting in a configuration page that is 50 checkboxes with cryptic names pulled from the API documentation. We want them to recoil in horror if we tell them that a web page takes 90 seconds to fully load.

So if anything, let this be a reminder that our work as analysts, researchers, and data scientists will often seem to center around a deliverable. But it's very important to separate the artifact from the result that we're trying to get. Does it actually matter if we don't write that final report in fully polished form, if we can convince the CEO to make a course correction to a flawed decision? Persuasion and advice doesn't just take one form.

Standing offer: If you created something and would like me to review or share it w/ the data community — just email me by replying to the newsletter emails.

Guest posts: If you’re interested in writing something, a data-related post to either show off work, share an experience, or want help coming up with a topic, please contact me. You don’t need any special credentials or credibility to do so.

"Data People Writing Stuff" webring: Welcomes anyone with a personal site/blog/newsletter/book/etc that is relevant to the data community.

About this newsletter

I’m Randy Au, Quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. Counting Stuff is a weekly newsletter about the less-than-sexy aspects of data science, UX research and tech. With some excursions into other fun topics.

All photos/drawings used are taken/created by Randy unless otherwise credited.

• randyau.com — homepage, contact info, etc.

Supporting the newsletter

All Tuesday posts to Counting Stuff are always free. The newsletter is self hosted. Support from subscribers is what makes everything possible. If you love the content, consider doing any of the following ways to support the newsletter:

• Consider a paid subscription – the self-hosted server/email infra is 100% funded via subscriptions, get access to the subscriber's area in the top nav of the site too
• Send a one time tip (feel free to change the amount)
• Share posts you like with other people!
• Join the Approaching Significance Discord — where data folk hang out and can talk a bit about data, and a bit about everything else. Randy moderates the discord. We keep a chill vibe.
• Get merch! If shirts and stickers are more your style — There’s a survivorship bias shirt!