Russel Goldenberg & Caitlyn Ralph from The Pudding join Amelia & Nick to talk about how they create data-driven, interactive articles, how the team works on both The Pudding’s data journalism articles and Polygraph’s client work. We also dive into how the team works with contractors and how the company manages itself using a Holocratic method.
Featuring
Sponsors
Raygun – With Raygun Error and Performance Monitoring you have all the information you need at your fingertips to quickly find and fix errors and performance issues across your tech stack down to the line of code. Get started with a free 14-day trial, head to raygun.com and join thousands of customer-centric software teams who use Raygun every day.
Sentry – Working code means happy customers. That’s exactly why teams choose Sentry. From error tracking to performance monitoring, Sentry helps teams see what actually matters, resolve problems quicker, and learn continuously about their applications - from the frontend to the backend. Use the code SHIPIT
and get the team plan free for three months.
Micro – Micro is reimagining the cloud for the next generation of developers. It’s a developer friendly platform to explore, search, and use simpler APIs for everyday consumption all in one place. They’re in early development building out the first set of APIs, and they’re looking for feedback from developers. Signup and get $5 in free credits.
Notes & Links
Transcript
Play the audio to listen along while you enjoy the transcript. 🎧
Hello, hello, friends. This is Amelia Wattenberger. I’m here joined by Nick Nisi…
Hoy-hoy.
…and today we wanted to talk to some fine folks from The Pudding. The Pudding is a company that creates these wonderful, data-driven, interactive articles on the web. If you haven’t checked it out, go to pudding.cool. There’s some really interesting deep dives there. Here today we have with us Russell Goldenberg.
Hi, everybody. Thanks for having me.
And Caitlyn Ralph.
Hi, Amelia. Hi, Nick.
Hello.
I’d love for one of you, maybe Caitlyn, to give a deeper dive into The Pudding the company, a little bit of context around all it is that The Pudding does.
Yeah, definitely. So The Pudding is like our umbrella company, but we’re actually splitting to do different companies, that have two different complete brandings and logos… So when you’re going to each of their websites, you think there’s two separate entities, but we’re actually connected in the background. We’re all the same team.
So The Pudding, as you’ve been talking about, Amelia, is our editorial publication. If you go to The Pudding, which I suggest you do, like Amelia said, there’s no subscriptions, there’s no subscriptions, there’s no ads, we don’t track page clicks. Everything is free, open to read… But to keep the lights on at The Pudding, we also have another company called Polygraph, which is our brand studio. This is where we do the same exact work at The Pudding, which is the visual and data-driven storytelling, which I’m sure we’ll get into a little bit… It’s a purposefully vague definition of what we do, because if you dive into our archives, it’s definitely been changing more and more over the years… But we specialize in data and visual storytelling, we consider ourselves data journalists, and at Polygraph, at our studio, we do that same kind of work for different brands, organizations etc.
[04:18] Okay, so that’s like the company layout, where a team of eight - so we’re very small - we’ve been around since about 2015. It started with just Polygraph. Matt Daniel has founded Polygraph. He got in touch with Ilia Blinderman and Russell Goldenberg, and in 2017 it split off between The Pudding and Polygraph. So that’s kind of like a brief history of how we got to where we are. How is that, Amelia? More prodding questions, or is that good?
That was wonderful. I also heard a story about how The Pudding got their name…
Oh, okay…
…if you wanna go into that…
The funny sub-anecdote is that I actually started with the team all the way back in 2017 as an intern, and I spent an entire summer as an intern and didn’t know how we got our name. I always thought it was Polygraph, like a lie detector, and The Pudding I had no clue… The Pudding is “The proof is in the pudding”
Nice.
And Polygraph is poly, like multiple graph, instead of just a lie detector. So that’s the background between Polygraph and The Pudding. Is there anything else, Russell? I know you guys debated for a while what to call The Pudding.
I wanna say we actually wanted to call us The Proof, and in our research I think we found that that was taken. I feel like someone suggested to us “The proof is in the pudding”, and we were like “Ha-ha! The Pudding.” And then it stuck. That’s my memory of it.
I also just love the TLD that you’re on, pudding.cool. And polygraph.cool. Just so cool! [laughter]
We try hard.
Yeah, I don’t think I know any other sites that are on a .cool TLD… Which makes it extra-cool. I’d love to get into the process of actually making one of these stories. I know they’re quite intensive, and each one kind of like has its own data, and you need to research behind it, and technically they’re very impressive… I’d love to talk through maybe your process, Russell or Caitlyn, and then also how that is different across the team, because I know people use different stacks.
Yeah. I’ll start here, and then I know Caitlyn you haven’t made a story for a little bit but you definitely have in the past, so I wanna hear your thoughts, too… I think the most interesting thing to me is that every story has a different process, and that’s a great thing, in the sense that we kind of get to tell the story in the best possible way, that’s right for that story. The downside though is that you sometimes have to start from scratch every time. So we don’t have a ton in the ways of like a streamlined process; it kind of comes with both sides of the coin.
So I’d say in terms of like a story’s lifecycle, most of the time it starts with us – well, definitely starting with the question; we usually have a bunch of brainstorming phases where we just kick around ideas, and some things stick, and then someone starts looking into it… and so, we haven’t really come up with this very, I guess, rigid structure to keep things evolving. I’d say more often than not we end up having to do a lot of work in actually figuring out and compiling our own data sources. I think it’s exceedingly rare where the data is just sitting there, ready for us to pull down and start visualizing. I don’t even remember the last time that was the case for myself. Even in seemingly obvious ones, like sports stories; those ones are usually pretty straightforward, because there’s tons of data out there already… But even then – I mean, this kind of goes with anyone in the data science field… Most of the work is actually doing cleaning of the data, and like “Oh, this data isn’t as robust as I thought it was.”
[08:00] So that’s a big part of what we do. And then a lot of what we lean into is spending time creating data sets that don’t exist. I feel like our tried and true example is the story about women’s pockets. Jan and Amber created this story around pocket sizes, comparing them in men and women’s jeans… And that’s not like a readily available dataset, so they literally went into a bunch of department stores and grabbed jeans, and measured them in the back, creating their own data stores.
So we do a lot of that type of stuff, where, when I worked with Mat a few years ago creating this dataset around Ali Wong’s stand-up comedy routine. We literally watched it, had a big spreadsheet going, annotated all this stuff… Caitlyn, I think you helped out with that one, too. And yeah, we definitely do a lot more of those type of stories, where we try to come up with these interesting datasets that don’t exist. And I think people – you don’t see a lot of those out there, because it just takes so much time, and it’s like, big risk, big reward. You don’t know what you’re gonna get. And we luckily have the luxury of being able to test that out.
So that’s just the data portion. When we actually get into development, the same rule kind of applies. The only piece – actually, nothing on our site, aside from our homepage, is actually scaffolded out. Every story - there’s no CMS. Everything is made from scratch, on a per-project basis. We have some starter templates in place, which you can definitely get into… But we really heavily leaned into trying to make the development experience for whoever’s working on it something new. They have no constraints, and they can just do whatever they want.
Everything is statically hosted, so that’s really our only concern at the moment but we have had exceptions where if something needs to be bigger and have a dynamic backend, then we’ll figure out a way. So I think that’s our biggest philosophy, is “Let’s not give anyone constraints off the bat, and see where it goes.” I’ll pause there in case Caitlyn wants to jump in before we talk more tech stuff.
Well, I think the only thing I can add to that is just how we package what Russell just said for a client… Because I think it’s very difficult for them to wrap their head around the black box of creating an article like this. A lot of clients have never done a visual storytelling project like this, so it’s brand new to them… So a lot of what Russell just said I tried to distill down into four separate stages. I always think about the story, creating kind of like a storyboard and narrative.
There’s some data work, there’s data analysis that sometimes happens in parallel as we’re creating a storyboard for the article… And then there’s design… I know we can get a little deeper into how we do design. People use different tools, people like different fidelity of design, but usually we’re doing pretty hi-fi mockups for clients, and then we bring it into the last stage, the fourth stage, which is common development.
So that’s just the distilled, simple way to pull open the curtain and let clients actually see how we create something like this. But I also think it’s kind of a good breakdown of our process, very simply…
Yeah. Also, you can just see that Caitlyn and I, we think two little different ways. Caitlyn is very good at turning my organic “Let’s just do stuff” into a very systematic approach, which is really helpful for the Polygraph side. Also, something we should talk about a little bit later, which is we actually do approach projects very differently, because of the nature of them.
But, getting back to the tools and the tech stuff - I didn’t mention, on the data side, again, we let everyone wield whatever they want. Some people like R, some people like Python… I use exclusively Node, and I’ve been really into VisiData lately, which is like the command line tool for data exploration. Some people use MySQL… It’s really all over the map, and again, we really don’t have any formal tooling, headshaking from my MYSQL
[11:57] Yeah, so that spirit is again embodied on other processes, whether it’s a design – a lot of us use Figma, just because we can reuse assets, and stuff… But again, really whatever works for you. I usually skip from pencil on paper sketching right into code. I know Jan does, to Caitlyn’s point, super high-fidelity mockups, so she’s like “This is what I’m envisioning.” And yeah, we try to make it a space for people to do what works best for them.
And then the place that I care about the most is the frontend code. I spend a lot of time creating scaffolding and starter templates for us to utilize. Again, we’re not totally reinventing the wheel each time. I suppose our most recent one that I’m quite fond of - no surprise to Amelia - is in Svelte.
I’d say we’re not like a traditional journalism outlet, but I think a lot of our workflow are similar to what you might see more in newsrooms, mostly because a few of us have backgrounds in newsroom journalism… But also just like the tooling that’s used there just kind of fits with how we work. We really lean into Svelte, obviously (maybe not obviously), made by Rich Harris, who’s at the New York Times. We use a lot of different tools. I mentioned we don’t use the CMS, but we have our micro CMS, so for like injecting copy into our projects we use Google Docs, and we have a thing that – we use RGML, which then converts the JSON so it can get piped into the build… And right now our starter template that I use mostly is made in Svelte, and specifically SvelteKit, which has been a great and challenging experience, using something that is still kind of in development and changes a lot. I’m currently live coding, doing a recording of our website in SvelteKit, so you can follow along to see how it challenges me on a day-to-day level.
But yeah, we’re really into – I mean, I think I’ve converted a few people on the team to be into Svelte. It just makes so much sense for the type of work we do. I’ve been finding it really great for dealing with data visualization specifically… And it’s really nice when we have a lot of different levels of engineering on our team. It’s the only framework that I’ve found that actually works across all levels, because it’s a really easy learning curve to just get started… So yeah, we have a go.
I really haven’t used Svelte before, but it’s something that’s definitely on my radar, and it does really seem – from my understanding of all of this, it really does seem like a perfect fit for this… Because the way that I imagine using Svelte is when I really want granular control of a page, or specific pieces of a page… And it just seems like it really gets out of your way and lets you focus on that.
Absolutely. Amelia, I know you have a lot of experience with Svelte as well.
Yeah, one of my favorite things – I was at Pudding/Polygraph last year, I worked very closely with Caitlyn on the agency side… And one of my favorite things about the whole - there’s about eight people at The Pudding - is that everyone has their own workflow, which Russell was talking about a little bit, where you really do wanna get the right balance of starting from scratch, so that you can be creative, and think through different article formats, and not just have this template that you go through… And also being able to work quickly, so you’re not doing every single thing from scratch every time.
I know when I joined, Russell was still kind of evangelizing Svelte to the rest of the team. I know this whole starter kit, with kind of more like a vanilla JS and Gulp, I think, workflow… And Russell and I really got into using Svelte for these articles, because it really feels like the lightest-weight JavaScript framework, at least that I’ve used, where you’re really just writing HTML in CSS, and then you have like a script tag where you’re writing JavaScript.
[16:07] And there’s a few framework-specific syntaxes, like - to do a for loop, you have the curly braces, and you say hash each, and then you loop over some array… But other than that, it’s really basic HTML and CSS and JavaScript… And you can get a little bit fancier if you want to, but you don’t have to… Which is just a really good fit for this kind of article.
Yeah, it’s definitely opt-in. You can choose how much you want to Svelte it up, or if you wanna really just mostly vanilla, you can, too. It’s one of those things where the more you see – I think there’s lots of (I’m still having them) little light bulbs that go off, like “I don’t really understand why I would use it”, and then you see it being done in a way that makes sense, and you’re like “Oh, this just changed how I can approach this.”
And then, again, on the starter template front, we have a lot – this is something that Amelia started doing when she was with us, which was… We had a lot of (specifically in Svelte) preset components, or stores, or things that we’re like “Okay, we’ve used it more than once. Let’s turn this into something that we can just take and use out of the box.” And this is something I’ve been wrestling with a lot now, is I feel like I don’t wanna use libraries anymore, because I’d rather just have a component that’s right there, that I can just go in and customize… Because I feel like it’s more often than not that I wanna change something core to how it functions.
A good example was we have an accessible button set component, and I was like “This could easily be a library”, but then I’m like, “If I wanna change this one little thing about it”, it could be easy, depending how it’s written, but it also could just be something that you have to write this hack, for like “Oh, I wanna override the styling for this specific thing”, and that seems annoying, rather than just jumping into the component and mocking with it that way.
So that’s something I’ve just been embracing more, is like creating these more reusable bits that are kind of part of the Svelte starter template that we can wield, and I know there’s a few different places that are doing these things, like with recipes and whatnot… But that’s something I’ve really enjoyed with Svelte… And also because it’s obviously gonna build it at runtime, you don’t have to worry about it being included by default, unless you use it… So that’s just like another observation.
Yeah, that’s another one of the really nice things about Svelte… I think at first they called it the magic disappearing framework, and then – there’s some reason they went away from that, but… Essentially, there’s no runtime. It just compiles, and it kicks out anything that you haven’t used. They have built-in transitions, but if you don’t use them, then they’re not gonna increase your bundle size afterwards, which is really nice, because as a framework, they can add in all of these goodies, like adding animations really easily, adding transitions really easily, without having the impact of like “Oh no, we’re adding megabytes to the runtime.”
Yeah. We can just convert this to a Svelte Party, if we want… [laughter] No more Pudding. We can talk about Svelte.
I’m curious, with these pages - I think it’s really cool how you’ve set it up, and you kind of start from this template, and then bringing the data and use it… But one thing that’s always driven into me with the use of JavaScript anywhere is how does accessibility play into that? And when you’re telling a story with data, and oftentimes I’m presuming a lot of them might have animated or interactive elements to it, how does accessibility play into visual storytelling with data?
Yeah. It’s a great question. I think it’s a question that is probably becoming more mainstream in the past year in the data viz community. I feel like I didn’t see a lot of it being discussed previously… And something that is admittedly lacking and lagging compared to other places. I mean, I’ll be the first to admit that we’re not the best stewards of all time of this. It’s something that we’re working on currently. This year - I think it was just this year, beginning of this year - we’ve put into place… We’ve never actually had any kind of checklist for what we should even check before publishing a story, and that’s something that my former co-worker Amber and I worked on together at the start of this year… And we’ve put together the first step of many of like what is the baseline for what we need to do. And luckily, there have been a lot of great people working on this.
Frank Elvasky - sorry if I mispronounced that; I probably did… Who’s been working on this thing called Chartability - they have a bunch of documentation specifically thinking through how to think through data storytelling and accessibility, and it offers a really kind of comprehensive look at all the things that you should be considering… So that’s really been the framework we’ve been basing things off.
We’ve got kind of like our foundational thing, which is just like your general accessibility, like “Can you go through the whole page just using your keyboard” and all those other things that are kind of standard without data viz… And then there’s kind of like different rungs of approaching it from a data viz perspective. I think the first is – I wanna say the easiest low-hanging fruit is having good copying language and proper semantic markup around things. So if you have a chart, you should be able to understand what the chart is about, and the main takeaways, from reading the title and the description… Or if there’s accompanying text, a lot of it is in having good summaries about what’s in it, especially if it’s like a complicated chart that you can’t put actual interactive accessibility stuff with… Having really good copy that helps also explain what is going on with this crazy chart. I think that’s a good starting point.
Having alternative ways of viewing the data… My last real article that I did - there was a way to just look at it in tabular format, or have the data available as like a CSV download… So those are kind of – there’s basically all these different things. Some are really easy, and they get incrementally harder to implement and think of, especially as visualization gets more complicated. But I think we’re really following other people that are thinking more thoroughly in this space, following what they’re doing, and trying our best to integrate these into our day-to-day workflow when we publish a story.
But I do know - and this is, again, stemming from the journalism world - there’s so much fast and furious publishing that it’s super-obvious that this is something that falls by the wayside. I’ve noticed that every single big news outlet, especially the New York Times - I don’t wanna throw anyone under the bus, even though I just did… Because they produce some of the best visual interactive eye candy from a data visualization standpoint. There’s oftentimes where they’re on deadline and something has to give… There’s probably different pressures being put on, like “We need to get this out by tonight.” Some of this stuff takes a lot more time to think through properly.
Yeah. So I think part of it is having a good framework for what you actually have to check, but then there’s the tooling argument, like “Is there things that we can do?”, so when you make this, you don’t actually have to think about it, but it’ll automatically create these things for you… So I think it’s a little – a blend of both, and I feel like we’re lucky that there’s some people thinking through this, so we’re not pioneering this space, nor do I think we’re the ones that are most versed in it… So it’s nice that this exists.
And I think the checklist is really helpful. I think it’d be awesome also if you all could share that publicly… But I also think it’s hard to keep track of – there’s different types of accessibility. Data viz is visualizing information, so it’s inherently really hard to make it non-visual, because you’ve already taken the data and made it visual, and now you have to make it not visual, again, with summaries, like you mentioned, Russell… But there’s also different types of colorblindness, so making sure you’re not using certain greens and reds, because (what is it) like 5% of the male population can’t distinguish…?
Let’s go with that.
It’s not five… [laughter] There’s motion sickness, so a lot of the work that you all do at The Pudding is scrollitelling, so you’ll have one thing fixed, and then the text is scrolling… I know Ember did an alternative where the two things are kind of interleaved optionally, so you can toggle them on and off.
I’ve never heard that term, scrollitelling. I like it.
Oh, yes.
Russell is the king of scrollitelling.
I have written one library for it, but I think that’s maybe – it surprises me that you’ve not heard of it. I feel like that must be a very journalism-centric term of those stories that Amelia was just describing.
Yeah, yeah. I’d also love to hear – I know, Caitlyn, you’re involved in all of the client work, and I know there’s differences between writing these stories, or developing these stories for journalism, and writing these stories for clients. I’d love if you could talk a little bit about what are those differences, and how does that look on the client side.
Yeah, definitely. So I started, like Russell said earlier, by making articles at The Pudding, but the reason I was the first person on our very small team to have a specialized role focused at Polygraph… And the reason I kind of gravitated in that direction - I had my personal career goals, that I liked management and things like that, and I wanted to go in that direction… But what I’ve found exciting about the visual and data storytelling work we do at Polygraph is that – I know you said at the beginning we’re not gonna pit The Pudding and Polygraph against each other, and now it sounds like I’m doing that… But what I find exciting about Polygraph is that right now it’s set up that we can actually go outside of the page and do this kind of work… So all of The Pudding articles right now live on The Pudding’s website.
What we do at Polygraph lives on all of the different brands’ and organizations’ we worked with sites, but we actually do installation work, we’ve done work with the Smithsonian National Portrait Gallery, and stuff like that… So I think the first part of the answer to that question, what I find really exciting is that there’s a lot more variety in what we’re doing… And Amelia, you remember a lot of these conversations; because there’s a lot more variety, we find ourselves straddling very interesting lines in between being more editorial with our client work, or being more agency, flashy, pulling in some crazy JavaScript work to create very immersive experiences with data, things that we’ve done with some of the installation work, and stuff like that… Or to really replicate our editorial nature for clients.
[27:59] What I’ve decided to do strategy-wise this year is dabble in both, and show that in our portfolio we’ve done both. Again, we do see ourselves as data journalists, so that is our expertise, that storytelling… But we can’t do a 40-foot installation for Universal Music Group’s lobby offices of their artists and musician data, if that’s something someone wants us to do.
And I think it also ends up serving as a creative outlet for people at the pudding to do different things as well, but that’s a whole other conversation thread as well, with how we set up our company. So go ahead, Russell; I see your face.
I know, I’m opening my mouth…
I know, I’m used to it. By now I know. [laughter]
I just wanted to add that it’s very much like this symbiotic relationship, both financially, but then also technically, because the great example is the UMG case study. We created this - again, a big lobby visualization, and it wielded a bunch of WebGL stuff that we hadn’t done before, because we weren’t forced to use it, so no one on our team had a background in it… But it was like, “Oh, we need to use this, because this is the only thing that’s fit for this environment.” So we got to do it, find some stuff, and we were able to integrate that back on to the other side.
So sometimes it’s nice when you have constraints, and definitely with client projects you have a lot of constraints, so it kind of forces you to push up against those constraints and get comfortable. So I think it’s like forced learning in a lot of ways for us, which is nice.
Yeah.
That’s really cool. That’s such a unique thing about this too, and the storytelling, and being able to kind of break out of the constraints of the browser almost, with all of that. And definitely breaking out of the constraints of making this CRUD app that has some basic state management and navigation, and doing something just much more fun.
Actually, the National Portrait Gallery, now that you mentioned - that was maybe the best example of this. We actually had to render a video…
Oh, yeah?
…and none of us – I mean, some of us have to use some video software, but I was like, “Why make a video when I can create a JavaScript library that basically creates a 60 fps animation with D3, and exports each frame, and then stitches the video together?” So that’s what we did. I’m not sure if I would do it again, but it was a really interesting challenge, because we were like “We have to make a video”, which is not something we normally think about doing, from a data web perspective. So that was really fun.
That was my favorite thing about the client work… I know y’all are super-picky about what stories you do, both on the journalism side and on the client side, and I felt like working on the journalism side, it was too open-ended. I’d have to really believe in what I was writing about, whereas on the client side it was kind of like “Okay, we have some pretty severe constraints, and they’ll force us in a certain direction”, which I thought was really nice.
I think it’s interesting too, because – this kind of goes more into our company structure, and stuff like that, so I don’t wanna say too much about it… But also the differences of how people like to work too, in these types of things, and I think you’ve just really hit on that, Amelia, because I think everyone’s like “Oh, you wanna work at The Pudding because you can do anything you literally want”, which is pretty much true, to an extent… Again though, the reason why I gravitated more working with clients and stuff like that is there was constraints, even on your mental state… I think Pudding articles - you can be thinking about it on a Saturday afternoon, but if I’m done picking a client on Friday, I can kind of put it away… And I personally just prefer some of that boxing a little bit.
When it comes to workflow, the work itself, and just like the experience on the projects, and stuff like that. There’s just a little bit more separation. But because we do both often, people get a little bit of each, so…
[31:50] Yeah. It must be real timelines. If you’re like “We need to tell the client in two weeks what this is gonna be, and what it’s gonna look like”, that really puts your feet to the fire in a great way. You have to make decisions… So that is nice.
Yeah, and it’s also nice to have a reliable thread throughout the entire team, of like data. We’re visualizing data, we’re finding data, we’re making it understandable for humans… So there are people who go back and forth between the journalism articles and the client articles, and you can kind of like pick and choose, like “Do I want those constraints, or do I have something that I really believe in and I wanna pursue to completion, and I wanna get a little bit whacky?”, but it’s always gonna be in the browser… Whereas you could do a museum installation on the client-side. It’s just really cool to have those options. You can switch monthly, potentially.
How do those constraints get formed? Is it “This is the data that we have” and then do you storyboard it somehow? Or how do you determine “Here’s this mass of data, and here’s this beautiful story I wanna tell with that”?
Russell, do you wanna go into that on The Pudding side?
I think The Pudding side - it’s rare that we just have a bunch of data that we weren’t already knowing what we wanted to look for… So I feel like this is much more common, actually, on the client side. I feel like this is an exercise that we do often, which is “Here’s the data. Can you tell us what we should make?” I think that’s where we really lean into – everyone approaches this differently.
I might sit down and be like, “Okay, I’m actually just gonna scan through this data sheet you sent me, and actually just really think about this topic more”, but someone else might be like “I need to know the summary of this – I need to know the mean of the data, I need to know what it looks like, the shape of it…” So I think everyone has a little bit of a different approach. We often will do some very preliminary stuff, and then I think early on we try to just – we call it storytiming; we just try to talk about it. I think we’ve found that just bouncing things off of each other really gets us thinking about it in creative ways more quickly. Caitlyn, do you have any specific examples on the client end?
Yeah. Well, actually, I’ll talk for a second on The Pudding end, too; I’m about to do a talk at a university later, so I feel like I’m prepped for this question… We always do start with a question; it’s very rare where we find – and I think Russell somewhat mentioned this… It’s very rare that we find just like a giant dataset unmined, and then we go in and mine the data and get insights, and then we think of the question. We’re always going in with the type of story that we wanna tell, and I think the way I think about that still feels a little bit amorphous.
The way I think about it is that if I’m at a bar in New York with my friends on a Saturday night and I brought up this topic, could we actually have some kind of debate and conversation about it and talk about it for a little while? And I think with that lens, that kind of like bar talk lens going into The Pudding articles, I think often – think about the women’s pockets article… I could sit and talk with my friends for ages about how dresses don’t have pockets, and things like that. So that is usually kind of idea selection part zero, and then it manifests itself in something called storytime. Literally, I say this, and my mom’s like “You have a meeting called Storytime?” I’m like, “Yes, it’s a long story”, but literally, that’s what it is. We sit and we bring – a lot of us will be like “I have the worst idea in the world, but let’s just talk about it.” And we talk about it, and stuff like that, and see if we can spark that kind of conversation. So it’s just a little bit more color on The Pudding end.
On the Polygraph end we have clients coming to us with every step of the process. Russell and I are kicking off a project this week where the clients have data - they’re actually data scientists themselves, so they have the data done, the insights done, it’s in a Google Doc, a narrative outline is already done, linked to the different datasets that match that part of the narrative outlined… They even have some low-level sketches and visual inspiration ready to go. So they’re really giving us a headstart here. Now we just sprinkle in our data storytelling prowess and make it come to life on the page.
[35:58] Or we have clients come to us, literally just being like “We saw your work, we love your work, we have zero clue what we wanna do with you, but we wanna do something with you.” And with that, usually I end up doing a consulting contract hourly with them, where we actually kind of like embed in their team, meet with people and figure out the idea that we wanna do using our expertise, and then we actually create a scope of work to go with it.
So I’m not afraid if no one knows what they wanna do; we’ll figure it out. But we just have people come to us in various stages. So to Russell’s point, it actually is messier often on the client side.
And I think practically speaking, a lot of what we do is getting a sense of the shape of the data - okay, is it temporal stuff? …like, how many different keys and stuff are we talking about? How many different data points? And then once we have seen that, I think we have collectively just observed and consumed so much data visualization out there… I think it’s a lot about just being like “Oh, what if we did something like this?” and then “Let’s use that as a jumping off” point.
So I don’t think we’re thinking about this stuff in a vacuum. It’s really just kind of amassing, and just really consuming, living and breathing everything that’s out there, and then kind of remixing pieces and just knowing what might fit with what. So I feel like a lot of that is where our ideas and visions come from. It’s not just tunnel vision on the dataset. I think that’s a real key to it.
I love those two points, because I think most people when they see those articles, they think a lot of the work or all of the work is in what they see, and they’re like “Oh, how did they even make that chart?” And it’s like, oftentimes you need even a separate contract for finding the data, parsing the data, exploring the data, understanding the data… And even getting to that “What is our main question for this piece?” And then that’s like a totally separate job. That’s often just the tip of the iceberg.
Alright, so I heard that you all, at least on the editorial side, are leaning a little bit more into a contractor network, instead of doing everything with the people who are on the team. I don’t know if, Caitlyn, you wanna talk a little bit more about how that transition is going and what that looks like.
Yeah, definitely. Something that Russell and I love to do is talk about strategy. In fact, in the December holidays, Russell, we have maybe three-hour meetings of just talking about strategy… Which I feel sounds so vague, but it really – it’s one of my favorite things about being at such a small company, in that we can really shape the strategy of an entire company very easily, because we’re so small… So because we have these two entities, we could kind of decide “Oh, we want Polygraph to grow in parallel with The Pudding” or “We want The Pudding to grow much more than Polygraph, but then Polygraph financially supports The Pudding”, so there’s a lot of interesting nuggets there.
[40:23] But what we decided to do at Polygraph is instead of increasing our personnel, we’ve decided to lean into a very small - so I’m not talking about like a 50-person contracting network, I’m talking like 5-8 people… Freelancers, contractors, people who are full-time freelancers at Moonlyte to work on our client projects with us, along with the seven other makers at the company who are full-time, who also do some of the client work as well.
Oftentimes we’ll have one of the full-time employees working on the project, and then we’ll bring in maybe a contractor support for any of those stages I talked about earlier - dev, design, data, story… And - Russell has finally pushed me in this direction - bringing in a PM contractor as well for some projects, because I would default PM all the projects… Which has been really exciting from a development standpoint and just a capability standpoint. People are experts in different things, so we can bring in some really cool contractors who are – we’ve just worked with a data art creative coder, which Russell has done a lot of work with in the past, but no one is an expert on the team, and has produced just some amazing work. Now we know this person and we’ve worked with him, and now we can wield him in different ways.
A lot of people can admit being a full-time contractor and freelancer is pretty common now, so… We had a lot of people who wanted to work with us. Yeah, so that’s kind of how we’ve been doing it.
And then we’ve hired a – again, I was the first person who took this type of role. In the past three months we hired an equivalent of me at The Pudding, our managing director, so our second really specialized role (who actually just pinged me). And basically, he is doing the same thing that I’ve done with Russell at Polygraph, which is building out our freelancers for The Pudding, for the exact same reason. I think Russell can talk more about the freelancers at The Pudding, because he was doing a lot of that management work at The Pudding before Rob came into the role… But that’s how we’ve been thinking about it at Polygraph.
Yeah. I’ll just add on that, first of all, I think we still have a form open somewhere, but if you are out there and are curious about contracting with us at Polygraph, we’re always entertaining collaborations; so reach out. And then I’d also say that on The Pudding side, this is something that we’ve actually just – we’re trying to pour some gasoline on the fire, so to speak. I don’t know what the number is, but we’ve always had freelancer contributions. Some of our best and most popular stories have been from freelancers, and we’ve just decided this year that it’s something we wanna lean into more. We like to learn about different topics, and even like different ways of telling stories, by working with other people.
Most people have stories that they wanna tell, and so it just gives us an opportunity to both work with those people, and also just be a bit of a platform for people who wanna do their own data-driven storytelling, and maybe wanna partner up with us.
So we’re just very much embracing the spirit of collaboration, so to speak, on both sides of the business. I think it’s something we wanna keep just leaning into more in the future. It’s good for everybody. It’s good for us, because it keeps us energized, and I think it’s good for the freelancers and contractors, because they get work and another outlet for telling stories or working on projects.
And in the same way that, Russell, you said we have an outside form, we actually don’t accept pitches at certain points at The Pudding. We literally 24/7 accept pitches, so anyone can email us at any time. And you don’t need to be an expert in every step of the process. You don’t have to be a developer, and a designer, and a data person. You could literally just have a really great idea, and you wanna bring it to us and you wanna collaborate with us on it, and we’ll kind of fill in those gaps from there.
[44:14] I think another really important thing - obviously, another really important conversation going on is that the more freelancers we bring, the more diverse forces, the more experiences we can have on The Pudding, and the more we can give them a platform… It’s not just contained to the eight people working here. I think that also has been really important for The Pudding, and obviously, it does manifest itself in a way at Polygraph as well. So. Amelia you go.
I just really like how the data viz community is made up of people from all different backgrounds. Basically, no one has the same back-story of how they got into visualizing data… So I think it’s really great for people who want to try out, like “I wanna make this data viz story, but I don’t necessarily have all of the skills” or “I just wanna see what it’s like, what goes into making one of these stories.” I think that’s also a really great opportunity for people who are curious or adjacent to this space.
That probably lends itself really well to just bringing in or injecting a lot of creativity, just having so many diverse skillsets and viewpoints and everything; it really probably contributes to that, I’d imagine.
I’ve also heard that, Russell, your role is changing a little bit in tandem with these changes.
You hear a lot of things… [laughter] This is true. This gets into how we structure our company a little bit, but I do a lot of just frontend development and story creation, and that’s kind of like my bread and butter. But in the last year I’ve had a lot more interest in, like we’ve been talking about, networking with other people and collaborating with them. And to Caitlyn’s point, we need to matchmake on the client end sometimes, if we have a specific project, for the skill; we’re like “Oh, yeah, they don’t have that” or maybe they don’t have the bandwidth for that at the moment. We can reach out to people.
And that’s something that I’ve been turned into my actual day-to-day role recently. And the reason we were able to do that is because we run on a very loosely-inspired form of holacracy, which is a way of self-governance. Something that Matt kind of pitched a while ago… Because he started the company, but didn’t want to be a boss. He wanted everyone to have a voice and be an active participant in the company.
So we’ve been leaning into this holacratic method, and so the way that I started taking on this role, which Caitlyn has called CTO, is we have a proposal system where anyone on our team - there’s a very clear decision-making structure on stuff. So there’s certain things that certain people own exclusively, but then most everything else at our company, anyone can create a proposal on. This was a good example - I was like “I wanna shift part of my role”, so I wrote up a proposal, brought it to the team, and there’s this very specific process called… What’s it called? I know the acronym is IDM. I think it’s –
Integrated decision-making?
That sounds right.
I think that’s it.
Yes. And we’ve actually been trialing out a tool called Murmur which I think is in private beta, which helps streamline that process. So yeah, it just goes through this round of “Here’s the proposal. Does anyone have questions? Does anyone have reactions?” People can object to it, or they can consent to it. But through that process I now have part of my role as CTO, where I get to help figure out who’s working on – it’s kind of staffing; who’s working on what, from an outsider perspective, and then just a lot of consulting from a technical standpoint, on how we even develop every project, and what we need to think about. Caitlyn, you can probably talk more about those things though.
[47:59] Yeah. I said this earlier, Russell and I would have these long strategy conversations last year. Russell and I have been working together for like four or five years now, and even though we are just polar opposites people - I don’t know, it’s like opposites attract, or something like that… So I think we just work really well together on the daily. I love having him as my co-worker and friend. So I was really excited that we could actually formalize this. Because when you’re at such a small company, I feel like a lot of these things kind of like fall through the cracks and they’re just kind of happening, and no one has written them down or documented that they’re actually happening…
But when we brought in Rob – I said this earlier, but when we brought in Rob, the managing director, who was absolutely fantastic. Russell is the editor at The Pudding; a lot of his editorial management kind of got freed up there, and he’s been able to – again, because he has this lens, he can look at people’s portfolios and see things that I don’t see… And I think from my perspective, I was doing all of this alone, and I think I got like a hero complex, that was like “I can do all of this, it’s fine. I’m good. I don’t need any help.” And I think admitting that I needed help and bringing in another person, which is also very difficult I think to do at a small company, has just made such a huge difference. We’ve been able to expand the amount of projects we bring on, work with more people, and stuff like that. But it really is all embedded in that; you know, it could be your role. It could be you don’t like the family leave policy, so you wanna come and make a change… Amelia, I think you brought a proposal about our health insurance policy pretty early on, and things like that…
But to kind of like bring it back - I think it fits with The Pudding, because we’re so self-driven… So we’re not only self-driven, we’re not even – we’re exercising those muscles when it comes to the work we’re doing, but we’re also exercising those muscles in how the company operates. A lot of people bringing contractors to do this HR work, but we have literally written all of our company documentation, from the code of conduct, to our health insurance policy. And anyone can make changes on it when they want to.
It’s really great to have that control over the place that you work, but there’s definitely a bit of a learning curve where I think it was like the first week I was there. I was like, “Can I have this external health insurance to the ones that are offered?” and everyone’s just like “Sure. You just have to write the policy.” I’m like, “Oh, man, I don’t know how to do this… I guess I’ll figure it out.” [laughs] And literally, anytime I’d ask a question, it’s just like “Yeah, whatever you want it to be, as long as you don’t taint the company.” I think it’s really great once you get used to it, but getting used to that coming from larger companies is definitely a little bit of a mindshift.
Yeah. It also is just interesting, because I feel like you sometimes get a vibe of like “This person really doesn’t want this to happen, but they can’t think of a reason why it’s not safe to try.” So you kind of end up like, “Oh God, I know they’re not happy with this, but we’re gonna do it.” But the point of it is to push people out of their comfort zone and to promote experimentation. The reason why we started to do it was that any small – We got to the point, like three years ago or so - we’ve been doing it for about 2-3 years - where to make one tiny decision on an external health insurance policy everyone had to be in the room, and it got very slow… And this forces experimentation to be happening quickly.
[51:24] We did four-day workweeks last years - Amelia, I don’t know if we told you, we’re on 4,5-day workweeks right now… So we tried out those policies, we tried out a commission model for a while… And this is literally all in like the past six months, just because we were able to do these policies. But there is a learning curve; it could be very paralyzing, coming in and being like “Oh, so just do it. Yeah, just do it. Trust yourself. Believe in yourself.”
Experimentation is just written into the DNA of the company. It’s cool.
Yeah. And it’s great for a lot of things, especially, again, if you care about the company. But it’s one of those things where you also have to be comfortable with change, because – Caitlyn just brought up one, we did this experiment on the commission model, which was if we were over our yearly budget, we could take on more projects and then people would get paid a commission on them, so over the top of your salary… And we tried that out, and we collected a bunch of data on it, we ran it for 6-7 months, and there were some great things about it… But then there were some things that we learned after doing it; we were like “Well, we’re actually gonna shift this policy.” And I know it’s not something that everyone unanimously wanted to change again… So there’s those tensions that you just have to accept as part of the process. Kind of like everything, there’s good and bad to it, but it just comes with the territory.
But even from there, even in that specific situation, we just had a conversation with our co-worker. It was like an hour, and we just were transparent with each other and just talked about where we were coming from. We literally called them “tensions”. Like, what the tensions were, and stuff like that, and worked through it. So I think although you can kind of get those vibes, I think it just adds a level of candor to how you work, and stuff like that, because you can just be very clear with everyone about what you like.
Well, I could talk about holacracy all day… I think it’s a super-interesting topic, and I don’t think there are many other companies that are operating this way… But I think we’re up on time. So it’s been so much fun having both of you, Russell and Caitlyn on, for our chat today… And also thanks for joining us, Nick, as well.
Thank you.
Thank you, guys.
Our transcripts are open source on GitHub. Improvements are welcome. 💚