Skip to main content
SearchLoginLogin or Signup

Building The Stack Webinar - Paul Ford from Postlight

Published onAug 27, 2020
Building The Stack Webinar - Paul Ford from Postlight

Paul Ford, Co-founder of Postlight

What are the biggest decisions people working in public media tech have to make? If there was a decision they could change, what would it be? 

In this new fortnightly webinar series from the Public Media Stack, we explore the art (and science) of making tech decisions with some of public media’s prominent voices. We’ll ask them five simple questions and unpack the issues that universally affect our industry – problems with workflow, the relationship between newsrooms and tech teams, reader engagement innovation, funding diversification – as well as the presence of and reliance on Big Tech and the efforts to create alternative ecosystems. 

For our second Building The Stack podcast, we were joined by Paul Ford, the CEO and co-founder of Postlight, an award-winning design and development agency in New York. He’s a writer, product strategist, educator, programmer and software consultant and has managed digital and editorial strategies for Bloomberg, Condé Nast, Credit Suisse and VICE Media.  He’s written for the New York Times and Wired and in 2016, won the National Magazine Award. He’s advised startups and Medium, and was an advisor to the White House Office of Digital Strategy during the Obama Administration.

This is an interactive document, so please add your own comments and questions either as annotations to the texts, or in the comments below. We’d love to know your questions or suggestions for future webinar guests.

The crux of the workflow issue and why it’s nothing to do with software:  

‘Workflow is a relentless theme. It’s not by choice, that is the reality. You see this at different scales. As you go up and up into larger organizations, they want platforms. They want big complicated systems that they can buy. Then there are infinite ranges of how do we put things in the box and who gets to say what goes in the box and who gets to hit publish? As simple as this sounds, an organization at scale can turn this into years of complexity.’ 

‘The problem is no longer putting things in the box and getting them out. The problem now is who gets to put things in the box, change them once they’re in there and who gets to hit publish. It’s just hard. The way people try to solve it is by throwing software at it, but the only way to solve it is to sit down in a meeting and watch how organizations all talk to each other and how they move those boxes along.’ 

On ripping out the middle so the database can talk directly to the front end:  

‘CMS is increasingly solved - we know the shape of it. There are three to five big players and a bunch of other options that are relevant to different patterns of building. But there’s a point at which things need to go truly custom. Everybody who’s done this work for years has gone ‘hey, what if I didn’t have to have all the code in the middle, I could just have the database and talk to it about the data?’ All of your programming is now in the database. You’re writing all this stuff with user management and authentication - this is very abstract but boy does it scale. It means that when you make a change to your data, it gets you to the next level of headless. Ripping out that middle and just letting the database talk to the front end.’ 

Stripping out complexity for minimalism: 

‘If you can get rid of a huge pile of complexity, even if it’s complexity that people love, it’s hard to beat that. There’s lots of people advocating for different kinds of minimalism, and every minimalism is radically different. [For example] the browser is becoming a truly first class platform for delivering software that has to run really fast.’

Turning back the clock to semantic web technologies: 

‘I got a little too into semantic web technologies in the mid 2000s. The idea was instead of a web of documents there was a web of knowledge and everything would be published in a special schema and everything would become a giant database. Instead of Facebook we’d all publish our own social data and that would allow us to find each other or automatically find itself. In retrospect it was library technology and it gets used inside of libraries still. Learning WikiData is hard but it’s fascinating.’

When people are nostalgic for the early web they’re nostalgic for a scene. It’s like going to a little club and seeing your favourite band but there’s only 50 people there. Then billions of dollars show up. There is great work like Google’s Open Schemas, but the idea of things being decentralized relies on human behaviour being a certain way. You have to really understand motives to make software that people want to use.’ 

Why communication is important not always tech and tools: 

‘I’d like to get off Google not even for all the regular reasons but for a different cognitive context. I bought a one-volume Columbian encyclopaedia and I had a fantasy that I’d read a page a day. That didn’t go anywhere. But it’s really fun to browse in the same way wikipedia is, except it’s a book and no one can yell at you. We’re good on tech. I don’t need any more tech.’ 

‘Half of [tech projects] is tech and delivery. The other half is communication, style, design work and so on. As things are evolving, that stack is getting really solid. You know you have fast computers, you know you’re going to pick one of three or four cloud services, you’ve got a couple of CMS’s to pick. More choice is always better. And then it’s all communications. We have the tools. It’s how do we use them, why are we using them, how do we make things better.’ 


On process and understanding the psychology of how people work to help your tech decision: 

‘Someone at a client of ours was making videos about how long it took to upload a video so that their management could see how painful it was. That has to be a spur to action for tech strategy - when your users are spending all day making a video to show how bad the problem is! So the first question you need to as is - where are the blockers? Sit down and figure out where the most brutal technical blockers are. Then you need an advocate. Top down systems are just recipes for disaster. It doesn’t matter if they’re good. People will reject them because they weren’t consulted, they don’t feel invited, they don’t know what they’re supposed to do and you took away all their old systems. The critical thing is to have a fast enough loop. You can’t go away for six months you have to back a couple of weeks later and say hey, I fixed that box for you. That will spread like wildfire.’

‘Don’t over index on stack. Pick a couple of technologies that people understand. Go talk to the people on the floor. Then when you go into your design phase, do the dashboard first. You’re going to lead with design as you’re working things up the chain. Draw the dashboard for your executives. What are the metrics? What needs to be seen every week? Then start to get the buy in that way. You’re going to have an analytics platform built in, and it’s going to tell a certain story. This usually gets instrumented after the product gets defined. I’d go ahead and make it part of the two week sprint when you’re figuring out what the thing really is. No one ever does that. But if you go ahead and say here are the three bar charts that everyday we can go in and see how this thing is doing, then the senior exec is going to go, alright.’



Comments
0
comment
No comments here
Why not start the discussion?