I wrote the cover story in Wired magazine this month. It’s called “Why I (Still) Love Tech: In Defense of a Difficult Industry.” It’s a little weird to be trundling along as a leader at a software company and then to have my name on the cover of Wired, but there you have it. Thought leader, think thyself.

The piece is a long essay about how the tech industry has changed in the last few decades, especially around the web and Internet. It’s partly about how, in terms of ethics, we in tech didn’t adapt enough as we gained power. We’re still fighting the battles of 1997 but 2019 is a different place; namely, we’re in charge. And too many people want to lead and not enough want to listen.

In the interest of putting my money where my words are, I’m splitting my fee between four charities: Black Girls CODE, Vets Who Code, Vermont Drop-in and Human Utility. These are inclusive charities, run by women and/or people of color. Several teach people who are marginalized by tech-at-large how to wield some of the power of this industry in their own interests, and one uses a technology platform to directly reduce suffering.

I work in an industry that is full of “solutions providers.” Except I know, from the clients who come to Postlight needing help, how rarely any one off-the-shelf solution truly solves a problem. Very often the problem is redefined to fit the solution. That’s how a big part of the tech industry survives: It invents new problems and solves them. This isn’t a bad thing! At some level the entire World Wide Web is exactly that. It created the need for websites. That’s why I have a career.

But it does lead to solutionism. Whereas an experienced software person, whether product manager, designer, or engineer, is not someone with quick answers. They don’t have solutions. At most they have preferences. The best people are the ones who can say, “it depends.”

Because there’s no such thing as “right” with technology. There never will be. There’s no one single operating system, design system, front-end framework, word processor, web browser, programming language, spreadsheet application, audio format, video player, text editor, IDE, windowing interface, network protocol, package manager, diagramming tool, or calendar program. Culture changes, and code changes with it. Seeing that big picture is work.

After the article came out, someone I greatly respect, who’s been around the tech industry for decades, wrote an email with kind things to say. But, he asked, where’s the vision? Where’s the big picture? We’re just starting!

He’s right. Right now it feels like we’re all just swimming in a stream of risk and despair. Today I read that society will break down by 2050, which seems premature, but what do I know? It’s almost sensible to choose a negative worldview because cynicism always seems more “correct” than pessimism. And okay, we need to plan for the worst. But it’s not a sin to hope for the best. As my friend Maria Bustillos says, Sometimes there are good surprises!

But ultimately, if I’m going to stick around and create a world in which I want to live, or have my kids live, I have to say: “It depends.” Maybe we need to all move to Mars, or have more nuclear energy to balance the fossil fuels. Maybe there’s no easy solution to the challenges of the world and we’re actually all going to have to get by with less.

All I’m saying is that we do have the tools, in the world of technology, to change things. But the tools are not the latest, coolest things at hand. You won’t solve global warming on the blockchain. You won’t create a more just society with a better chat client.

What does seem to work, at least from my experience, is listening, saying “it depends,” and then building the best possible solution as quickly as possible, and watching what happens next.

That’s the part of tech I love. The part that’s a conversation, not a solution.

Paul Ford is the CEO of Postlight. Send him an email: paul.ford@postlight.com.

When we started Postlight, we quickly found ourselves in a pickle, with 25 full-time employees and our major client announcing chapter 11 bankruptcy, one of the very worst kinds of bankruptcy. In desperation we started a newsletter and, as if we weren’t attention-hungry enough, a podcast.

We did what you’re supposed to do as a startup, which is: Build nothing and own less. We used Medium for the blog and SoundCloud for the podcast, Mailchimp for the mailing list, Meetup for the events. Our website was kept on GitHub and hosted out of Netlify. We threw parties, tweeted, did experiments—whatever could stir interest in our firm.

It worked out fine, don’t worry. But as the company grew we started to feel the strain of using many platforms instead of one platform we controlled. I’ve written about this, in a piece called “I Miss Staging.” The point of that piece was that as wonderful as it is to have cheap or free platforms for making things available online, it’s hard to understand how those things all fit together. You end up with a fragmented experience with a lot of seams. We were fragmented, and we didn’t have control.

This is the same situation that many of our clients find themselves in. They’ve given up control to third-parties and now they want it back for themselves. They want their own platform. They want to innovate. And they want to know exactly how people are finding them.

We realized that we needed that same freedom. No more issuing pull requests in GitHub or hacked-together case study pages. We need a single framework that matches our own growth today. One that we own, host, and manage ourselves. With that comes more risk, but more opportunity to tell our own story on our own terms.

And now we’ve got our own archive, too—Postlight has grown a culture and a history, and it’s here in one place, from the podcasts, to the announcements of new leadership roles, and the events we’ve hosted. After three years, we’re in charge of our own destiny. And ready to grow.

Paul Ford is the C.E.O. of Postlight. 

There’s a Netflix show called The Toys That Made Us with an episode about He-Man and the Masters of the Universe toys. He-Man toys were basically ridiculous. Tom Wolfe in Bonfire of the Vanities describes them as “unusually vulgar, even for plastic toys.”

But it starts to make sense when you learn the backstory. The Masters of the Universe franchise was forged out of the crucible of necessity; Mattel had passed on Star Wars licensing and needed to compete. The episode is great because it’s clear that (1) He-Man was produced under pure competitive pressure, by throwing stuff at the wall to see what sticks, resulting in zillions of dollars and a global media franchise that’s still ongoing; (2) everyone is still pissed off at everyone else, 40 years later. All starting with a 5.5-inch barbarian doll with a bowl haircut.

He-Man has a lot of vehicles but the most famous is his giant tiger, Battle Cat. The best part of the episode (which got clipped and shared all over Twitter) is when a marketing director named Paul Cleveland describes how Battle Cat made it into the world:

I had managed the Big Jim line, which was an international-only product by then. I knew there were tools [i.e. toy molds] that already existed that we didn’t have to pay for, and this tiger from the Big Jim line Big Jim was a 9.5-inch doll, so the tiger was scaled to a nine-to ten-inch character.

Tony Guerrero was the guy that sculpted He-Man, and Tony looks at me and says, “Paul, you can’t do it. It’s not to scale. It doesn’t look real.”

I said, “Tony, just do it,” and I walked out.

I come back the next day and he says, “I need to show you this,” and here’s this green tiger with orange stripes.

And he said, “See, look.”

I said, “Wow, that looks great.”

And he goes, “Oh, shit.” He said, “Paul, it still doesn’t matter. It’s as big as a horse.”

And I said, “I don’t give a fuck. If it’s as big as a horse, put a fucking saddle on it.” And I walked out again.

So, two days later I come back, and there’s a saddle on it and He-Man sitting on it, and I go, “Damn.”

And that became Battle Cat.

If your cat’s too big, put a saddle on it and call it a horse. That might be the single best pivot to find product-market fit in history.

the explanation for why he-man has a tiger is one of the funniest things i’ve ever seen in my life and i have to share the whole clip pic.twitter.com/1pgtQglG0M

— Bobby Schroeder (@ponettplus) May 21, 2019

It’s soothing to imagine that critical moments in product history are made by reasonable people in temperature-controlled rooms, as the result of a lot of process and discussion. We all try to live up to that every time we prepare a PowerPoint. But the truth is that an awful lot of progress comes in the form of people throwing a saddle on a cat in order to stop the yelling.

We don’t talk about that process very much. The process of winging it–using what’s available and cheap, and having no idea if it’ll work out. In truth that’s how a lot of software gets built, and art gets made, and novels get written. We just dress it up with discussions around planning, scrums, user journeys, agile, and process. We try to forget the ugly parts, but maybe we should spend more time celebrating our Battle Cats.

Paul Ford is the CEO of Postlight. Say hi: paul.ford@postlight.com.

One of the joys of my job is I get to talk to hundreds of people about their technology problems. Some hire us; many don’t. But it’s extremely interesting to see how people from around the world see software and what problems they want to solve.

Not long ago, one of our more enlightened clients, part of a big organization, said to us, “Look—let people ask for workflow after you launch this.”

Then the other day, a potential client in a global organization explained their goals this way: “We could build something to automate this, or we could just talk about it on Slack when we need to. The second option is going to work better for us.”

A lot of people come to us with a list of systems that all do roughly the same thing. Postlight, they ask, can’t we just have one system instead of 15? Can’t we just monitor all our data and analytics with one dashboard and enter data using one API? Can you make it easier to upload a video? It takes a half hour. (One client once actually made a video of someone uploading a video, and sped it up 10x, to prove to management how much time was being wasted.)

Of course you can, we say. There’s no technical reason why not. And lots of cost savings if you do! And we’ve talked about this subject on our podcast. It comes up a lot.

Okay, all are agreed, we’re going to centralize and consolidate, and we start discussing a plan. And over time, people start to express their deepest hopes and thoughts. Can we, they hesitantly ask, you know, make it so that the right people can approve everything before it goes live? We have a complicated organization, so we’re going to need a complicated workflow…

It sounds very sensible. It sounds like the right thing to do. Let the software system cut risk and promote good behavior. Good for the organization, good for employees, good for everyone. We can put some rules in place and cut all kinds of risk.

Except! Now someone wants to add a new employee to the HR system. Except now, they need 12 pieces of documentation and all of them need to be added at once, and some of those documents have to be approved. Once they’re in the approval process they’re locked, so when updates arrive to fix corrections, an admin needs to remove them from the approval queue. Some of them need to be stored securely. Finally, there’s administrative and legal approval, and integration with the payroll system.

The problem is, employees don’t submit bug reports. They ask a question, their problem is added to a queue, and then it fades away. Responses are rare. No one believes their software will be improved. They learn to be helpless. When the system tells them they’re locked out, they believe it, and they wander off to get coffee. And frankly, that’s on us, the software people, but I guess it’s good for the coffee people. The software industry is bad for people but it’s been great for the coffee industry.

This all starts when you start factoring humans out, trying to cut out places where they can make mistakes. Again, it feels right. But that’s because the people who make decisions about software platforms are professional managers with budgetary control. And that means they are risk managers. So they don’t ask you to build a great toolkit for people to be more productive. They ask you to cut risk. It’s their job. They have meetings and tell everyone that the software COULD, SHOULD, and MUST behave in such a way that no one can ever make a mistake, ever.

What you need to do, and we’ve found this over and over, is sit down with the people who are using the systems today and get them to show you how they work. It’s not always the best experience (which is fine, because it’s our job). A lot of times they need to just get angry and vent for a few hours about how no one has listened to them in the past. A lot of times they believe you won’t be able to help them and it’s pointless.

That’s okay. There’s no way to prove otherwise. Just listen. They’ll show you that it takes an hour to upload a file, that 90% of their work gets paused at one phase, that if someone is on vacation all approvals stop, that the analytics don’t make sense, and you’ll see the parts of the system they don’t touch, too.

Then act on what they tell you. Build something really little that helps them. Just one little tool that lets them do things more quickly. One red button to unlock the block. People might wonder what the hell you’re doing. Managers have heard this person complain so often that they’ve tuned them out. They blame the messenger.

Go back and show it to them. You’ve never seen a faster turnaround than when that person gets just a little love. They’ll start testing more things. You can train them to submit bugs. They’ll get invested. And critically, they’ll start showing other people. They go out for drinks with their peers and they’ll say, “Actually, I swear to God, I think they might finally try to fix it.”

Here’s the hard part: That doesn’t mean you can stop managing up. You can’t just walk the floor and be the shop steward of technical needs. The managers have the budgets, the goals, and the magic pen that signs the checks. You need to build their system, too. You have to build a system that works for the people who use it daily, and for the people who like dashboards, too.

It’s tricky because we’re an industry of disciplines. Should you do more research and understand your user? Or build a live prototype that works on mobile? Should you launch something on day one? Or day 30? Mobile-first or build the API first? The answer is: It depends! There’s no one answer, no magic solution, and anyone who tells you there is has something to sell you.

But it’s really worthwhile, as you’re deciding what to build and how to build it, to ask yourself: Is this going to be a carrot or a stick? Are we centralizing and consolidating so we can control things, or are we centralizing so that we can make things easier and more efficient?

A big organization is going to hand down technology policy. But technology change always comes from the bottom up.

You know how Linux showed up? Someone would set up a spare server in the closet to chew through some log files. Easier than getting it provisioned and getting another Oracle license.

Slack? Free tier. Suddenly started to work better at work.

GitHub? Started with a decentralized version control system and added some services around it. With a free tier, too.

The thing is, carrots work. Sticks don’t. Computers can’t make people do things. They have to want to do things. As a product studio, we try to play it down the middle: To listen to the people doing the work as well as the folks at higher altitudes, and fit it into the larger goals of the organization.

That’s what I love hearing from potential clients, people who realize that some of the best long-term value they’ll get out of our firm is by paying us to not build things. Let them ask for workflow, but in the meantime, people might find that they can get a lot more done without it. Maybe instead of trying to automate every process so that it all works and looks the same, assume that people just want good tools to do a good job, and help them do it faster so they can go out and have a beer with their friends. You might think our job is to build software but just as often it’s to help you avoid building the wrong software. And when you build, build carrots.

Paul Ford is the CEO of Postlight. Send him an email: paul.ford@postlight.com.

I used to hate people managing up to me. I’d feel like I was being shepherded, but over time I started noticing that a lot of the time it wasn’t people trying to control me as much as people trying to figure out how to communicate with me. Me! I’m a really good communicator! What’s the problem?

Turns out it was me (it always is). A lot of things that make me a good writer make me a weird, discursive, introspective manager. It’s not like I’m going to become a different person. But as I’ve written before, you have to admit, and accept, that you’re in charge, and help people meet you halfway. And part of that is acknowledging, and accepting, that other people are going to manage up to you.

We’ve had Kellan Elliott-McCrea on our podcast before. He’s a technology leader in New York City. He recently gave a talk on managing up. What I especially like about the talk is that he’s the manager: “Cards on the table,” he says, “I am the person you are managing up to.”

There’s a part in here about making your boss look good that I want to call out:

This is probably the most important skill of the whole section of making your boss look good and managing up, help them see around blind spots. Management breeds blind spots; it is the nature of the work that we don’t know what we don’t know. We are divided, we are scattered, we’re the boss, we make snap decisions all the time, we are often the least-informed people in the room, and we don’t know it. Our job requires us to go on making those decisions.

This is one of the frames that I really like to use when I think about managing up. The best managers need to be managed up….The best managers are the ones that are inviting you to manage up to them. They’re the ones who know they have blind spots, who need help. One of the phrases that someone said to me at one point that I really liked, it has been echoing in my head now for 20 years, “It’s my job to be pushing. I need you to tell me if I’m pushing us off a cliff.”

A little over a year ago I took over the front-line growth in Postlight. My co-founder Rich is really good at shaping larger engagements, so I focus on bringing attention to our firm and driving in more opportunity. I don’t design or build software; I simply work with a management team to create an environment in which software can be designed and built. But I’m also responsible to our clients, and they can ping me at any time. They have the expectation that I’ll know roughly as much about how things are going as anyone working on their project.

That’s tricky. There are 10–20 projects running at different paces at any time in our firm. So that requires me to know a lot of things, such as what stack we’re using for a given piece of software, when things are expected to be completed, and any flare-ups or concerns that should be expected. I read Slack and run growth meetings where we review every live engagement twice a week. On top of that, I get a staffing report.

A lot of time I’m operating on instinct, a pit-of-the-stomach feeling about how the client feels. A big part of client service is a sort of proactive empathy. So sometimes people are pretty sure things are good and I start asking them about what’s up and where the risks are, which feels invasive.

Sometimes The client is going through an upheaval mid-project and can’t tell us what they need or even return our phone calls. Sometimes the right thing to do is keep going and figure it out later and sometimes the right thing to do is just chill out and wait for the next steps to come into focus, because anything you do will be wasted work.

And it’s a coin flip, really. Pure instinct. Meanwhile, we’re in a project-based environment, where leadership means delivering work on time. As a result, my instincts, liberally shared, are basically guaranteed to drive everyone who works with me bananacakes. But my instincts are also pretty good.

When I look at my last year, building out the Growth and Partnerships functionality inside of a mid-sized digital product studio—well first, I never in the world expected to do such a thing. But second, I can see pretty clearly that I’ve been teaching the people I work with to manage up to me, and that across the organization I’ve been trying to share the reasoning behind my instincts with people.

I’m still confusing, I think, but hopefully less so. One day I hope I’m not confusing at all. The whole thing makes me squirm, but a big part of management is getting used to everything making you squirm.

Paul Ford is the CEO of Postlight. Send him an email: paul.ford@postlight.com.

We’re pleased to announce that Jeremy Mack is now a Managing Partner at Postlight, and that Aaron Ortbals is a Partner at Postlight.

Jeremy Mack, Managing Partner, Postlight

Since Postlight’s inception in 2015, Jeremy Mack has led our engineering group. Postlight is practitioner-led, and Jeremy is a fantastically disciplined and engaged engineer, who is utterly dedicated to his craft. He’s an architect and a builder, and working with Postlight he’s guided the development of platforms that can efficiently manage billions of transactions.

Where Jeremy is truly unique is that he applies the same focus to building his team. As he describes in his post about Postlight’s engineering culture, he’s an empathetic leader who has built a world-class team of respectful, collaborative individuals.

Jeremy has had a full-stack career, working in both low-level engineering and binary disassembly, up to building abstract front-end component frameworks. His growth as a leader has been a critical part of Postlight’s growth, which is why we’ve named him a Managing Partner—a role in which he can both lead his team, remain a practitioner, and directly guide the growth of the business.

Aaron Ortbals, Partner, Postlight

Aaron Ortbals is a veteran engineering leader on Postlight’s largest engagements, and one of the founding team members of Postlight. He’s an empathetic leader, a committed and proven technologist, and has earned the respect of Postlight’s largest clients by leading their engagements to production release over and over again.

Aaron has been critical to the success and growth of Postlight, capable of taking extraordinarily complex requirements, boiling them to their essence, and then empowering the engineers around him to dig in and build great software. He also remains a practitioner, with a deep interest in front-end performance and optimization.

Before joining Postlight, Aaron was in senior engineering roles at Beatport, ChaiOne, and National Instruments. He is being named Partner due to his skill as a practitioner, his clear commitment to his team and to our overall engineering culture, his focus on turning his team members into leaders, and his steady commitment to helping our clients overcome challenges and meet their goals. As Partner, he will help position Postlight to meet the largest possible engineering challenges—and for growth.

Postlight

Postlight’s engineering team is located in New York City, around the United States, and in Beirut, Lebanon. Our dedication to building a remote culture is proven by the fact that much of our engineering leadership works remotely: In Jeremy’s case, Tennessee, and Aaron’s case, Texas.

Postlight is a team of creative people working together to design and build great digital products—and we’re always looking for talented people to join the team. Get in touch at hello@postlight.com.

You saw that Apple Arcade will allow you to have access to lots of games for a monthly subscription, correct? No more in-app purchases. Just a bunch of games you can play.

Soon after that, Google announced Google Play Pass–which is not just games but apps too. As a Pixel owner I jumped on it and now I have Stardew Valley, Cut the Rope with unlimited magnets, and Weather Kitty, which shows me the weather, but with a picture of a cat.

The app stores are sometimes fun, but unusable. Apple has hired every editor and artist they can find to make things look fancy, but it’s still a lot of angry Viking faces and checklist apps when you hit the App Store. Google, well. They should be ashamed of what they allow on the platform. Did we really need a game where you help Elsa from Frozen…give birth?

Anyway. The App Store clearly made billions of dollars spread all around, but in the end, the app stores are kind of unusable, and the Internet is filled with the complaints of independent creators who can’t compete. The web doesn’t help. When you search for “top paid Android games,” you get hit from the other side: All the content is advertised-up to the gills. You can ask your friends, but that’s exhausting. And thus one of the things I loved the most in the world, shopping for software, is ruined.

So now: Subscriptions. Curated bundles of apps! Everyone loves curated bundles. But as Apple Arcade and Play Pass grow in significance (and at their scale they’ll get tens of millions of users), the pressure will now be on for app makers to get inside the subscription bundle. Which will of course give more market power to the people who created the subscription services. This is why it’s so great to be a giant tech platform: You get to charge everyone for making a big mess, and then to charge everyone to clean it up.

The Internet is going to want to throw more subscriptions at me, which is fine. I get my games and my shirts via subscription. But what I want is…reviews. By which I mean good, objective reviews, written in paragraphs, with conclusions, by people with adult sensibilities. Yes, you see a lot of good reviews on places like The Verge. There’s a lot of reviews of hardware and benchmarks. But lord do I miss old-fashioned, comparative, cranky reviews and software criticism. Magazines like PCWorld or MacWorld or Computer Shopper. I want to read about SaaS products and apps, reviewed by slightly surly people. I would read this every day. Given how much software matters in my daily life, I’d pay, and I’d read the ads, too. Don’t tell me about 100 note-taking apps. Tell me about one, in depth, that matters, and where it works and doesn’t. Say good things and bad things.

I think from the point of view of Apple, it’s smarter to just keep hiring great editors, writers, and artists, and have them create content that guides people to apps inside the App Store. It’s much more effective than having to buy ads in the places where reviews are published, and no one can say anything bad about you, too.

If there were more good, independent reviews, I’d buy more software. 

Paul Ford is the CEO of Postlight. Send him an email: paul.ford@postlight.com.

I see a lot of companies up close, and I probably talk to 100 or 200 organizations a year. As the last month has unfolded, I’ve started dividing places up in my head:

• Whatever;
• Basically Fine;
• Outlook Unclear;
• Oof.

The “Whatevers” are the massive orgs, especially the digital ones. They can pull up the drawbridge. They’re nation-states, and they’re fine. They’ll have bad quarters but will be fine. Maybe they’ll get in trouble a year from now, as newcomers nip at their heels, and they’ll acquire the newcomers.

Postlight is a “Basically Fine.” Anxious, but with a product (digital product strategy and development services) that continues to be in demand, and a good mix of clients from different industries. Companies like ours are basically taking it a day at our time, getting our work done, paying our folks, and keeping our mouths shut (i.e. dialing down marketing spend). No one wants to hear much from us right now.

The “Oof”s are big and small enterprises that had a finely tuned business model that they optimized relentlessly — the magazine publishers who were holding on to newsstand sales to drive revenue and juice up their subscription numbers, spending money on promotions and direct mail instead of building good digital. Or the events company that was thinking about a building a big unified platform then decided just to focus on installing new trackers on its many websites so that it could market more fiercely. Anyone whose business involved people doing things in space, who was purely focused on optimization over growth — well… oof. Because there’s not much left to optimize.

Rich and I spend most of our time talking about the “outcome unclear” organizations — the places that have been forced to respond quickly in order to keep going, but that are finding new ways of working and operating. The wholesalers who have started delivering direct-to-consumer. The farmers’ markets that have banded together into one common online shopping experience — and are now, suddenly, shipping boxes of food to your house if you pay them.

A few weeks ago I helped notarize a will over Zoom. Last night my spouse jumped on a Jitsi call doing mutual aid for food distribution in the neighborhood — there’s a lot of food insecurity in this part of Brooklyn — and she was immediately welcomed for her Airtable skills (she also said she was probably the only person over 30). She described a system where people can call in to a Twilio and leave a message describing their food asks, and the audio is auto-transcribed and both audio and transcription are added to an Airtable database, at which point it enters a queue for transcription review and editing by any available volunteer. It reminds me a lot of how we all reacted after Hurricane Sandy — but things have come a long way in the last eight years.

Every commercial today is the same, and I don’t really care how Toyota cares about me. Toyota doesn’t care about me. But I love, love, love to see people hack things together. The local Vietnamese restaurant has organized a curbside pickup with a two hour order window, along with Venmo for furloughed staff — global systems, applied locally. Knowledge is starting to get out there, about doing things very quickly with Shopify, Stripe, WordPress, Google Docs, Mediawiki, Notion, Salesforce, Airtable, Netlify, Discourse, Glitch, plus millions of other open source tools and open APIs.

Silicon Valley VCs want us to “build” right now, but build what? It’s like telling someone sitting in a field of wheat that you’re ready for your pizza. We probably don’t need more blockchains or skyscrapers. We probably do need more bike lanes and nurse practitioners. But who the hell knows?

Don’t build! Because you’ll build the same damn thing you built before. Make lists of broken things. Hospitals shouldn’t have to cut salaries in a crisis; schools shouldn’t be food banks, telemedicine shouldn’t have waiting rooms. The future is right in front of us. It’s ugly as hell, and it’s being hacked together on mobile phones. Learn new tools and think how the tools could fix the broken things.

Looking at big systems and press conferences is staring firmly into a bad old past that is absolutely collapsing. Watching everyone learn, do new things, glue together new tools, introduce themselves to each other, create new products or services, sell, and cajole — it’s like looking right into the future. I wish we weren’t all here, but we are, with a lot of systems failing around us. But the people keeping it together by trying whatever comes to mind, to make it better, in public, backwards in house slippers — they have my eternal respect and gratitude, because even if someone else is going to take the credit, they’re the ones leading the way.

Paul Ford is the co-founder and CEO of Postlight. Want to talk about your business and where you want to go? Reach out at hello@postlight.com.

The CEO is not supposed to code, but nonetheless I’ve been having fun shipping out a three-weekend project, which I call “Account.” It’s a storytelling tool with some simple calculations built in that you access via sliders. It’s not particularly novel, but it was interesting to make for Postlight Labs, and I would like to tell you about it.

You can visit it, or see the code.

What is it?

Account reads a text file like:

At your store {1-100:people} people each buy {12:apples} apples each week. That means that you need to buy {=people * apples:total_apples} apples a week, except {10:spoiled}% go bad…

And it gives you this:

There are a lot of interactive notebook tools but almost all of them are pretty complex. I wanted something that did basic algebra with very few options with plain text.

Why now?

I mean, why not? Writing low-stakes software is fun.

Also, my basic stack of communications tools has changed a lot in the last couple of months. I pitch a lot of new business for our company, and the most valuable sales tool I have is being in a room with a notebook, nodding and writing down what people say, making eye contact, and then asking them questions.

I can’t do that right now so I need to show my active listening in other ways. Most software for business is for making things, sometimes collaboratively (Google Docs, Figma, InVision), or it’s for telling people about what you made (PowerPoint, Google Slides, Keynote).

But there’s a space in the middle: Software for sharing mental models and thought processes that people can explore and play with. Like wireframes, but for business models and other ideas.

I really need tools in that space. Virtual sticky note boards are amazing, and we’re using them at work. But interactive shareable models that take a few minutes to glue together and mess with went out of fashion in the tech world of the 1970s and we could sure use them back right now.

I don’t take Account very seriously. I wanted to build and launch something and I wanted to update my React skills. That said, I just used it to build a model in five minutes that I presented to a client to show them why we have to keep a close eye on their content production goals. “And now,” I said, “because when you have a hammer everything looks like a nail…”

I moved the sliders around on a video call and said, “So you see, if we’re more efficient in our planning and keep our goals, we can save 2,500 hours of work.” Were they indulging me a little? Sure! But also it was a real exercise. They reacted to what I had to show them. They got what I was trying to convey and appreciated the effort. This is how we learn.

What’s next?

I built this app using JavaScript and React. There’s just a lot of JavaScript to tap into. So on weekend three I was able to add simple charting in about half an hour. So now my apples look like this:

I’ve also been exploring adding more more complex functions. There are libraries of statistical functions, astronomical functions, units (degrees, hogsheads, pound-forces, and farads). It’s pretty easy to rope those libraries and components into this framework. There are pie charts, agent simulations, and so forth.

As with all Postlight Labs projects, try it out, remix it, or tear it apart. It’s under an open-source MIT license, and we want to know your thoughts. Pull requests welcome.

Paul Ford is the CEO and co-founder of Postlight. Have an idea for software we can build together? Reach out to us at hello@postlight.com.

Postlight is a company of 60 people in New York City and around the world. We build software for clients. We are unified in our belief in progress. From our earliest days we have spent time, money, and energy making an inclusive firm, a place we are proud of, and a place where people feel safe and valued.

Like all people of conscience, the murder of George Floyd left us in grief. The ensuing global protests against police brutality have left us in awe. Structures that once seemed eternal are collapsing and, more than before, a better world seems possible.

We are builders, and will join in building that world. Today, we are committing $300,000 through the rest of 2020 towards driving change that benefits Black people. We will use some of that money to build on our existing Diversity, Equity, and Inclusion efforts, and the bulk of it to support not-for-profit efforts dedicated to building an anti-racist society. How we spend that money will be determined by a volunteer committee within Postlight.

We will go further than money. We will bring our talent to this movement. Postlight commits to ongoing funding to support our employees in efforts that help Black organizations thrive, including advisory, mentorship, and especially in building software. We will also continue to make our physical office in New York City available to anti-racist organizations for events and meetings.

In the coming days and weeks we will be sharing some of these initiatives, along with information about the organizations we plan to support. We encourage anyone interested to reach out and call on us, now or at any time in the future. blm@postlight.com.

Black Lives Matter.

I’ve been watching the TV series W1A on Netflix. It’s a three-short-season comedy that aired between 2014 and 2017, produced by the BBC. It’s also about the BBC—particularly the middle management, and it’s filmed at BBC headquarters in London. As a result it’s not the most biting satire, and it’s extremely inside baseball, but it also one of the most realistic portrayals of middle management in large organizations that’s ever been filmed.

The show is centered around a middle-aged man named Ian Fletcher, played by Hugh Bonneville, who is the “Director of Values” of the BBC, which is about as bad as it sounds. In addition to a lot of incredibly nebulous non-tasks, he’s in charge of making sure the Royal Charter for the BBC is renewed.

The actors treat BBC middle management the same way they might treat Jane Austen characters, and they each have little verbal tics; one says “Brilliant!” over and over; one says “I’m not being funny or anything”; another says “Exactly.” Basically these are people in such a constrained environment that they can’t say anything and so they say the same things over and over, and sometimes “Brilliant!” means “I hate you.” But you can never say, “I hate you.”

There’s a lot of stuff that just makes me squirm in recognition, such as when the external advertising/PR firm comes up with the idea of “BBC Me,” which is basically YouTube, but BBCish. I feel I’ve been to that meeting 20 or 30 times in my life. In particular, in one episode the new automated speech-to-text subtitling software (“93 percent accurate!”) turns “Dame Maggie Smith” into “Dame Baggy Smith” (among other terrible things), leading to public outrage on Twitter, and they can’t turn it off because it’s so deeply integrated with the existing all-company IT services platform, which is called Syncapatico. Syncapatico is basically a character in the show. It never works, and constantly screws up conference room bookings. This episode alone is probably the best portrayal of large organizational information technology release ever filmed, which, admittedly, we’re not looking at too much competition, unless you count Jurassic Park.

One of the points in the show is that for the most part no one really does anything, and no one wants to take responsibility; when Ian Fletcher takes any responsibility at all it feels like he’s scored the winning goal in the World Cup. Everyone has titles like “Director of Better” and they’re all very territorial. Meanwhile they are deciding the fate of thousands of people who actually do things, like the people making the nightly news program, or directing new TV shows. The central conceit of the show is that these are the people deciding the fate of the BBC’s programming, and some of them have never read a script in their lives. A lot of dreams get ruined as a result.

Meanwhile the Royal Charter, which is a very real thing and 41 pages in PDF, must be renewed, and there’s an enormous amount of busy work and meetings to hold, because it’s only renewed once a decade. You can’t have the BBC without the Royal Charter. It seems ridiculous as an American that you need a Queen to approve of your giant media organization in order for it to keep functioning, but then again we have Rupert Murdoch and Condé Nast.

There’s a lot of different theories of what defines workplace culture so I’ll put out the one that works best for me: The culture and practices of an organization are determined by the timeframes they use to measure their success. An organization like the BBC has people who must renew the charter every ten years and people who must update the website every ten minutes. And what W1A really, actually represents is the point of view that the faster-moving people—the makers, the directors—have of the slower-moving people, i.e. the middle managers.

I think that’s why it’s so valuable to watch, especially if you are a corporate leader or middle manager. (Or just watch the video in that tweet.) When you have different groups operating along different timeframes inside your organization, they are going to be unintelligible to each other. The people who move fast and ship every day believe that the strategists, who appear to be updating the same PowerPoints over and over, are basically doing nothing. Whereas the strategists often see the people who must ship their product daily or weekly as recipe-followers who “get to go home at the end of the day.”

In technology this is even more pronounced. Some technology teams are utterly future-facing and move very nimbly, others are supporting systems that are 50 years old. So some people are chasing 18 month deadlines, some are thinking five years out, and others want to ship every two weeks. If you’ve ever been told it will take two weeks to change something simple on the website you’ve run into this; you’ve also run into this if you’ve read a tweet where someone insists they could build a new (insert complex web platform here) in a week with two people.

No one is wrong. They’re just experiencing time differently. And ultimately, and this is the hard part, it’s management’s job to get everyone on the same clock. Resolving that tension between timeframes is really hard. You’ll find that a lot of solutions are really about providing reliable schedules—agile methodologies, for example, which are organized around sprints. Strategic and management timelines are different from delivery timeframes. Strategy is about moving humans around to meet goals, and defining processes, and that means that sometimes you just need to have twenty or thirty meetings before you can make something happen. Ideally you do things once, and very carefully, because of all the money involved and all the lives affected.

Delivery is about getting the thing over the line, publishing the newspaper, uploading the videos to the server, often so that you can immediately do it again, but faster and better the next time.

The people who made W1A are…TV-making people. They’re on the delivery side. Obviously they had been in so many confusing, ridiculous “strategic” meetings at the BBC that they needed to make a TV show about it. And it’s a very useful reminder for any manager, because no matter how well-intentioned you are, you’re living in a different timeframe from the people you manage, and you’re speaking a different language. They’re nodding at you but they don’t make a lot of sense. Bridging that gap is a lot of work, but you’re the only person who can do it, so you might as well start now. Brilliant.

Paul Ford is the CEO and co-founder of Postlight. Talk to him about strategy versus execution timelines at hello@postlight.com.

Postlight is a digital strategy firm that builds software for clients. As go our clients, so go we. We’ve been surprised to find ourselves growing in the Covid-19 pandemic. We didn’t expect it. In fact, we made plans to weather a long, slow period of flat or even negative growth. Instead, our clients are coming to us, often for strategic advice, and often with the desire to change strategic direction or try new things.

Fast Strategy on a Shoestring

It took us a while to understand, but increasingly it’s clear what’s happening. There are two forces at work.

First, because the future is unclear, and because it’s been unclear for a while now, people are deciding that it’s time to get moving. The “new normal” is now just “normal.” It’s put a lot of pressure on existing systems to deliver new experiences. It’s forced telemedicine to grow up in a hurry, for example. Companies that were mulling over collaboration platforms for years suddenly picked Zoom and accepted the consequences. The pandemic triggered radical change that forced people to sidestep all kinds of bureaucracy in order to just keep moving forward.

Second, and as a result of the first, every meal is dogfood now. Everyone has to use the tools at hand, and those tools weren’t designed for these situations. Since the new office “is” software, instead of getting an update in a meeting or asking someone down the hall for a report, leaders are using the systems they manage. Suddenly everyone, from senior leadership to regulars users, has to use the same tools at the same time.

Put this together and suddenly you have lots of new ways of working and tons of shared awareness that things need to get better. Software and strategies that seemed sufficient…aren’t. Which means there’s an immense pressure to move fast, define a real plan, and build something that does work.

Our Advice

Here’s what we’re advising our clients and our prospects as they find their way forward.

You know what works. The pandemic has stress-tested your infrastructure. It isn’t hard to see what’s broken in result. You have (1) too many systems; that are (2) hard to access and difficult to learn and use; and (3) they don’t talk to each other. It’s not just you. Everyone is dealing with this. So you need to have (1) fewer systems that are (2) easy to access, learn, and use, ideally with one login, and (3) that share data in the background. Fixing this isn’t simply housekeeping. It’s basic infrastructure.

Break up big ideas. Don’t look for one big system that solves everything. They don’t exist. You’ll spend four months searching, and then you’ll be back on the path towards 24-month builds with eight-figure contracts and overlapping vendors. What does Earth even look like in 24 months?

Build small platforms, they scale fine. We’re seeing a ton of progress using very cheap, boring technologies (this is high praise) and working them incredibly hard. For example, we’ve been using old-fashioned SQL databases with API layers on top, then using that stack (or anti-stack) to stand up really complex platforms. This seems way, way too simple to work, but it scales easily to tens of millions of transactions, and it means we can launch incredibly complex experiences in months. It’s looks new and scary, but it’s based on…enterprise-quality SQL database technology. You might as well use it.

Everything is an API now. Need a CMS? WordPress is an API. Need a CRM? Salesforce is an API. Most have adapters that let them speak GraphQL, which will speed up your developers. Authentication is an API, too, so people only need to log into a system once. So you can: Glue together a bunch of systems into a custom experience, with one sign-on, held together with one “classic” database system that provides an API. And still have control over everything and run it in a trusted environment.

Trust the front-end ecosystem. Start with a popular design system like Material, Carbon, or Ant Design. Use React Admin for quick admin tools. You can have working front-ends that look better than anything you have now, in weeks.

Collaboration-first. People on teams need to be able to work on things together, with live updates and notifications when things change. They need to be able to paste links into Slack, and then everyone needs to be able to click that link to see and edit the artifact. This used to be really hard, and it’s very hard to retrofit, but there are a lot of great tools in the world that make real-time collaboration possible. It’s the new standard.

If you use approaches like the above, and you have a very serious commitment to iterative improvement, you can have four or five platform-based projects running at once. You can fix a lot of broken stuff quickly.

Of course all of this starts with actually listening to your users, finding out what they want, and constantly testing results with them.

I’m Sorry, We’re Growing

Larger, strategic digital projects are moving forward far more quickly because there is immense internal awareness that things should be better, and that things will not return to status quo soon, or ever. For the first time everyone is sharing the friction. The old ways, which bring with them a lot of process, aren’t going to survive. No one wants to fill out 50 different forms and spreadsheets again when this is over.

It’s an awkward time to grow. But it’s also the right time to try new things, even with smaller budgets. The whole point of good digital strategy is that you get more impact with smaller budgets over time, as your platforms grow and your users use them to do better work. Everything that’s happening in the world supports this approach. You might as well get started!

Paul Ford is the CEO and co-founder of Postlight. Talk to him about digital transformation at hello@postlight.com.

Sometimes you should just stop everything and look at some new big digital artifact to see what it tells you about the world. That’s how I feel about Microsoft Flight Simulator 2020. It has things to tell us. I’m not talking about the gameplay — I’m barely a gamer, and I keep crashing my Cessna into the tarmac at JFK. Instead, I’m talking about the world into which Flight Simulator was born.

Flight Simulator is one of the most venerable brands in software development, and this is its thirteenth major release in 38 years. Flight simulators are an interesting class of software because they’re created by nerdy people for other nerdy people, and they lack plot or theme. They tend to be “about” the computer — how well can it simulate flight? What can it do? What power does your desktop PC have these days?

Let’s look at how we got here.

Key events

1982. Microsoft releases Flight Simulator in the era of DOS. It consists of a few lines on a screen. Microsoft is an important tech company in a big industry, but nothing like today.

1984, 1988, 1989. Flight Simulators 2, 3, and 4, respectively. Planes have shadows, stripes on the runway, still pretty ridiculous-looking.

1995. Windows 95, obviously. A truly big deal at the time. 

1996. Flight Simulator for Windows 95 brings satellite imagery, storms, and so forth, and we’ve moved into 3D (we skipped a few releases). Starting to look kind of cool. Three years later, Flight Simulator 2000 comes out with lots of airports — just what everyone wanted.

2001. Xbox appears. Great network play features. It’s Xbox! It’s huge!

2003. Steam from Valve shows up and lets gamers buy games and find one another for network play. Absolutely 100% Microsoft should have owned this.

2005. Bing Maps appears as MSN Virtual Earth, and keeps going. It is roundly and regularly trounced in quality and capability by Google Maps, but never, ever gives up.

2006. Flight Simulator X. Last major release for 14 years. Comes on a DVD-ROM. The real flight simulator nerds start getting into X-Plane (which was first released in 1995).

(Between 2003 and 2015, you’ve got Vista, Windows Phone, lots of things that didn’t work out very well.)

2015. Windows 10, the version of Windows we’ll likely all retire from.

2017. Xbox Game Pass — video game subscription service.

2019. Google Stadia, which lets you play games on someone else’s hardware, with glitches.

2020. Xbox Game Pass for Windows. An entry-level PC-only marketplace for big-ticket (mostly older) games, with a highly tenous link to Xbox, that costs $1 a month and $4.99 a month afterward.

2020. Flight Simulator 2020 released for Windows 10, incorporating Bing Maps.

Thinking like Microsoft

In order to compete, organizations that deliver software need to provide a lock-in: something for their users that no one else can provide. Sometimes that’s easy and obvious, as in the case of a university with a great reputation providing an email address to alumni. Sometimes, though, it’s a lot harder to see where you’re going to make a dent.

The conventional wisdom is that the market only has room for one leader in each category, and if you’re not the leader, you should go into a corner and hide in shame. This is a very pervasive thought pattern in technology. 

But consider this: Microsoft has one of everything, and sometimes they’re a leader (Xbox) and often they’re not (Bing). They have their own operating system, office suite, social network, game console, database server, web browser, search engine, IDE, programming language(s), and so forth. And you might think that’s a kind of stubbornness on their part, a refusal to move on. But they don’t actually seem that nostalgic. They recently decided to close Mixer, their Twitch competitor, for example.

So Bing isn’t as valuable as Google Maps, but as a platform component that Microsoft can fully control and integrate, it’s worth much, much more to Microsoft than Google Maps could ever be worth. Xbox Game Pass for PC has no breadth at all compared with Steam, but it sure is a cheap way to get Flight Simulator.

So given the timeline above, and given what we know, let’s pretend to be Microsoft. How does an organization like that see the world? What do they think? In my imagination, it goes something like this:

We’ve got this brand Flight Simulator. We also own Minecraft, and wow, do people spend a lot of time there. We spent $2 billion on that and got every nerdy child under age 15 in return. I wonder if we could turn Flight Simulator into the next Minecraft. We know exactly how flight simulator programs do in the market going back 38 years. And we know how to market.

Also, it’s 2020. If we’re going to simulate, let’s simulate the whole world. We can do anything we want with Bing, for obvious reasons. Let’s…just grab the entire world and put it on a big filesystem using our own cloud services. A couple of petabytes is cheap these days. We can use machine learning to fill in any gaps. People will make fun of us for making the Leaning Tower of Pisa look like a grain silo, and the fact that trees all start growing two feet above the ground, but we’re Microsoft. People have made fun of us for decades. We’ll make a nice API that lets gamers download gigs of geo data as they fly their jets.

Let’s also make it multiplayer, but not push that too hard. But people can definitely fly with their friends, as a team. Also we’ll make it easy to add plugins and add-ons for scenery, new planes, and other modifications that let you use your iPad as a separate screen, or to fill in the spots that Bing Maps renders incorrectly (like Stonehenge).

You know what grinds my gears? Steam. It’s a big sprawling mess, and Valve ships one new rehashed Half Life game per decade, but everyone just assumes that’s the way it has to be.

Oh, Google’s Stadia, that grinds my gears too. Between Stadia and Steam, there’s a whole market that should absolutely belong to us, here, at Microsoft. If anyone is going to stream games, it’s us. Mixer didn’t work out, but dammit, people are going to play games the way we want them to be played.

I think we should wrap up a couple hundred PC games and call it, I don’t know, Xbox Game Pass for PC. Let’s start blurring those lines and get people into our gaming ecosystem.

So let’s make Flight Simulator available on that and make it cheaper to buy a full year of Xbox Game Pass for PC than one license for Flight Simulator. Now we’re getting thousands, hundreds of thousands, millions of new users to set up Xbox gaming accounts and lock them into our store experience. So we’re lifting customers away from Valve.

So that’s launch! My lord, the gaming press loves us. They love being able to simulate the whole world. You know why? Because it’s amazing. We did it!

We also launched a little early. It’s a giant, slow, 90 gigabyte download and there are lots of bugs. It takes forever to actually get on the runway. But now we can see how people use this thing. We can see where they fly their planes, receive their reports in order to QA Bing Maps, study all kinds of usage patterns. We can see what people do with multiplayer mode.

What’s beautiful here is we just brought so many people close to Xbox, we locked them into a game they could play for years, we’ve got them using Bing Maps all the time, and we know exactly what they’re doing at all times. And it’s time that they don’t spend using Netflix or Apple products. And by time, I mean hundreds of millions, eventually billions, of hours where they’re leaning in our direction.

And now what? Well, we let people play. We plan for the Xbox launch, and figure out what to do, really, with the multiplayer mode, and how to start marketing Xbox as a platform to the people who are paying us $5 a month, and once we get this thing on Xbox we’ve got 90 million users. So now, for the next decade at least, maybe 20 years, we’ve got this airplane simulator game that will be a place where people live their lives, share experiences, talk to one another, and it’s utterly dependent upon and connected to a variety of platforms we control, and it knits our PC gaming and Xbox platforms together, and we can use the data a million different ways, create special sponsorships and plane liveries — I mean, seriously, don’t you think American Airlines is going to want their livery to be the default at some point or another? Or for Boeing to pay for special treatment for their airfield? Travel and tourism is $1.6 trillion in the US alone, and this is a global platform.

All we have to do is let people play, keep them playing, and encourage them to explore more and more of the game, and we’ll generate unbelievable growth and opportunity for ourselves.

This is a good plan!

What can we learn?

I think for a lot of us in the tech industry our mental model of Microsoft is this incredibly angry, enormous dragon that savagely burns every town it passes while sitting atop a huge hoard of gold. There were years (2006–2015) where it was simply giant. In 2020, the dragon still exists, but it mostly works in Excel. In addition, Microsoft used to be famous for having every single part of the organization engaged in total war with every other part. Somehow the divisions are capable of collaboration now — their CEO, Satya Nadella, usually receives the credit for this change.

It’s interesting to contrast this with Apple. Apple seems utterly uninterested in any category they can’t completely dominate and extract 30% from. Microsoft doesn’t seem anywhere near as organized, and yet…they’re turning little imaginary planes and a legacy brand into a giant integrated platform that will turn into its own miniature economy. There are billions of dollars they’re unlocking here.

That’s one hell of a way to think, and a good reminder for anyone who laments that they’re behind, that their platform isn’t modern enough, that they can’t compete. That used to be Microsoft. But now they seem focused on building new things with all the big pieces they own. 

Case in point: You already can’t find a flight yoke. They cost hundreds of dollars on eBay. They’re sold out at the big electronics stores. Lord knows, during a pandemic, when you’ll actually be able to buy one again. The dragon is still there — it’s just learned to be invisible.

Paul Ford is the CEO and co-founder of Postlight. Talk to him about digital transformation at hello@postlight.com.

Thank you all for gathering. First thing — obviously there’s a lot of change. So we’re going to meet more often. We’re going to do all-hands meetings once a week.

Second of all, we’re in a healthy, stable place. There’s a reason we run lean and stay busy. This is that reason. The future is very, very murky right now. But we are truly okay.

Related to that, being busy is good. We want to deal with this transition proactively and then get everyone back to focusing on work, because there’s still a lot to do and it needs to get done. And we think in times like this, having lots to do is actually a really good thing.

Reach out to our clients. Tell them we are here to help, and that we have lots of advice about the transition to working from home. They’re going through transitions of their own and facing challenges. Some of the decisions they make will be in their best interests and maybe not our best interests. Regardless, listen to them, and help them. Lives and relationships are long. Help them succeed.

Take care of each other. We really value the way the team supports each other and boosts each other up. Virtual kitchen beers are great. It’s also great to see the NYC culture mixing in with our remote culture. Keep it going, and get involved. Socially distanced Zoom houseplant sharing is a lot better than panicking on Twitter.

Be mindful that it’s not just NYC doing something different. We’re global. The Lebanon team has also gone home and is dealing with a lot of other challenges, too.

Communicate what’s going on with others. Overcommunicate to the people around you and to your manager. Keep the HR system updated. You’re essential, and we need to keep this network tight and connected.

If you’re wondering how someone is doing because you haven’t seen them in a day, say hello.

Take a minute and think about how you’re feeling and realize that everyone around you feels roughly the same. You, your reports, your manager, our clients. We’re all feeling this stress. People might snap at each other, or read too much into a Slack or video call, or make a bad joke, or get angry about someone’s bad joke. You will, we will, everyone will.

So please be quick to apologize and quick to forgive.

Let me say that again: Be quick to apologize and quick to forgive.

And overcommunicate. Say important things more than once and say “I’m overcommunicating here.”

Overcommunicate.

Use the free counseling sessions from our health care provider. Take time off if you’re overwhelmed.

If you’re a caregiver, coordinate and talk to your peers and manager. We’re here to support your situation and cover for one another.

If you can find help at home (sitter, etc.), we’ll pay for it.

We’re pausing PTO tracking for any caregivers that need that flexibility. Don’t worry about time off.

From day one Postlight has never been about the time we put in but rather the work we do. When you’re home and you find a quiet pocket, take it. Go for a walk (even if that means a walk around your place). Play with your kids. Take breaks in the middle of your day. If you’re feeling pressure, talk to your manager or any of the partners.

Our clients are in this with us. If we need to ask them to bend a bit — that’s okay. Leadership will provide that cover if need be and have those conversations.

Make your work environment at home as comfortable as possible. We’ll cover the costs. We have a lot of ideas here. Some of us have been remote for many years.

Wednesday lunch is still on. Expense it. There will be a Zoom every week. We can watch each other eat. It will be terrible and awkward.

We’ll totally get through this, intact, as a company and a community. That’s the plan. Even if things get tough, we’re going to stick together. We were designed to adapt to the circumstances around us. That’s part of client services. These are weird circumstances. But we’ll adapt to them. Humans are very adaptable.

Take deep breaths, look away from the news — it will still be there, we swear — and help the people around you get their work done. Keep each other busy.

Open a window.

Overcommunicate.

Be quick to apologize and quick to forgive.

We won’t get through this alone and grinding.

We will get through it together.

Last week Google released a new product called Tables, which takes square aim at (i.e., looks exactly like) “codeless” development and workflow-management tools like Airtable, Notion, Monday, and others. These are tools that let you set up workflows and work on big data sets. People use them to do all kinds of things, from running their interview process to building mutual aid societies.

I wrote about low-code in Wired last month:

There are a host of tools like this now, “low-code” or “no-code” software with names like Zapier or Coda or Appy Pie. At first glance, these tools look like flowcharts married to spreadsheets, but they’re powerful ways to build little data-management apps. Airtable in particular keeps showing up everywhere for managing office supplies or scheduling appointments or tracking who at Wired has their fingers on this column. The more features you use, the more they charge for it, and it can add up quickly. I know because I see the invoices at my company; we use it to track projects. (Though Airtable has made its Airtable Pro plan free for certain Covid-related efforts like the mutual aid society.)

No one is sure what to make of Tables yet. It’s not fully integrated with Google’s regular office suite, and it has an enterprise pricing model, more complex than “free” or “comes with your paid Gmail.” It looks a lot like a spreadsheet, and then there are mini-programs (called “bots”) that run as you enter the data.

But it’s no surprise they launched it — consumer codeless is a big, growing space. Amazon has a new product called Honeycode that lets you write business logic right there in the cloud. Airtable is valued at $2.5 billion. The core idea is that anyone can sit down and take what’s in their brain and turn it into a software experience that other people can use, without writing a bunch of SQL statements.

Postlight is a product development services company. People pay us to design and code things. Codeless products are designed to pick our pockets. And you might think we’d be worried about codeless products. But we utterly love them. They solve a huge range of problems people have. We also think that a lot of the most interesting “codeless” work happening isn’t in the consumer products space, but on the backend.

Consumer codeless vs. enterprise codeless

“Codeless” is a good marketing term. More accurate might be:

• Spreadsheets with rules
• Databases with comment fields
• Smarter pivot table builders

You get the idea.

But the key to codeless products is that they cut out whole layers that used to be necessary. You used to need a database and a programming language that talked to that database in order to build a web app. What tools like these do is just bring everything together into one unified whole: You have all the “state” that’s in your database connected to all the “interfaces” used to access that state. So you can see a view that looks like a spreadsheet, a view that looks like a Kanban board, a view that puts everything on a map, and so forth. You give up a lot of customization, and everything tends to look the same, but you get a lot of power in return, and a lot of simplicity.

The same pattern is starting to emerge in the server/API world, too. The way it works is pretty simple: You run a program on the server and that connects to a database and provides a REST or GraphQL API to the data in that database. Let’s call this “Enterprise Codeless.”

For example, whereas before your LAMP stack — Linux, Apache, MySQL, and PHP — might look like this:

Now your stack looks like this:

Which seems almost ridiculously reductive, but is also…true. Let’s add some details about this new anti-stack stack:

• Your database is the source of all truth and everything is stored there.
• You run an application on the server that inspects the database and automatically produces a web API.
• You add more functionality to the API by writing functions inside the database, mostly in SQL, and when changes happen, these are also written in SQL.
• User management is done inside the database with tokens for security.
• You write the front-end using a component framework like React.
• Extra work (say, producing image thumbnails) is done by serverless cloud functions like AWS Lambdas.
• You put static assets into bucket-based hosting systems like AWS S3.
• You write a set of scripts to deploy and manage things.

So maybe a slightly more accurate layercake diagram would look like this:

But the key thing is that a huge layer of complexity, code where users are managed, accounts are created, data is massaged, API requests are transformed, etc., etc., etc., is just sort of…stripped away.

Here are some examples:

• Datasette, which gives you a REST API (GraphQL is under development) on top of any SQLite database. This is one of the fastest, lightest ways to create simple web services and explore ideas, and it has a nice built-in interface too.
• Hasura, which gives you GraphQL on top of the Postgres database, and is written in Haskell. VC-funded, and starting to support MySQL too.
• Postgraphile, which is like Hasura but all in JavaScript. Postlight sponsors Postgraphile, and we’re big fans.

And many others — there’s a growing list of products like these.

I’m a huge fan of the first one because it’s a great tool for hacking and exploring data sets. And we’ve used the last two in production and found them utterly manageable and effective applications for organizations like the New York City Metropolitan Transit Authority (MTA).

Challenges of enterprise codeless

It’s a great way to work but it does represent a different approach. This approach requires engineers and designers to think differently about how they’re building things. There’s more time spent thinking and much less spent building. You have to unlearn a lot. You have to think about your database as a true platform. (But it works beautifully — more on that later.)

And in general, since this approach to building things is both really old-fashioned (using the database and database-native functions to define an entire application server feels very main-frame-ey), and ridiculously modern (goodbye forever, LAMP), the tooling isn’t quite there yet. 

Postlight engineers faced challenges, in particular, with managing the large set of in-database functions they were writing. Because the functions exist “inside” the database and are not organized into libraries, or structured readily into folders, all the niceties of a modern IDE don’t apply. At some level, doing this much work in the database means working with a single many-thousand-line file filled with table definitions, functions, and index declarations, and there’s no clear set of best practices for managing those. Plus, when code changes, that might mean the entire database is changing. Modern ORMs and migration tools, combined with modern tooling for code management, provide a lot of niceties. 

Ultimately, Postlight folks noted, SQL is a language for data analysts. So there’s friction between how SQL sees the world and how modern API-driven web services work, and you need to learn about that and think it through.

Advantages of enterprise codeless

So, okay, there’s still plenty of complexity!

But here’s the advantage: When you have a rough sense of business requirements, and you understand this stack, you can sit down and write an SQL schema, and have a fully functioning modern GraphQL API in an afternoon. Then you can glue some React components to that on the frontend — using something like React Admin means that you’re just building with predefined widgets and writing very little code. That’s it. That’s the whole thing. You built an app. Now you can start to focus on design, experience, scalability, and enhancing the feature set of the API.

Here’s the other huge advantage: This ridiculously modern way of writing code is totally enterprise compliant.

PostgreSQL is deeply established and can be purchased by the hour on most cloud platforms; Node.js and React are standard now, too. GraphQL is still fancy but not exactly bleeding-edge. Hasura is written in Haskell, but you run it as a binary, and it has a venture-backed company behind it; Postgraphile is fully open and all in JavaScript.

What this means is that you can use these tools in your giant organization. They’re simply libraries on top of existing, approved, well-understood technologies. PL/SQL, which is the language for writing PostgreSQL functions, was created by…Oracle.

Let’s imagine everyone said, “No, forget it, we want to go back to the old ways. Rip out the JavaScript and put Java in, instead. Let’s use SOAP.” All that would happen is you’d have a well-defined database schema with a set of database-native functions. That’s it. 

There’s no risk. You’re looking at a set of tools that are endorsed and supported by Microsoft, Amazon, Google Cloud, IBM — places like that. It might feel new and different, but it’s just…simpler.

Watch this space over the next few years. This is a powerful, less expensive way to work and I’d expect more and more developer tooling and simplifying frameworks to emerge.

Data models over code

In that same Wired article, I also wrote:

Programmer culture tends to devalue data. The database is boring, old, staid technology. Managing it is an acronym job (DBA, for database administrator). You set up your tables and columns, and add rows of data. Sure, 80 percent of your code in Swift, Java, C#, or JavaScript is about pulling data out of a database and putting data back in. But that other 20 percent is where the action is!

What Enterprise Codeless lets you do is own up to that 80% — stop trying to abstract it away, go inside the database, and get the schema just right. The paradox is that by doing this, taking this time, really thinking it through, we make everything go much, much faster — and we can ship working products inside of giant organizations with legacy IT systems and do it in six months.

So that’s the key. You might wonder how a services firm would feel if suddenly a new stack came along that made a lot of their work redundant. And the answer is, we feel great. There’s enormous opportunity and growth here, and the chance to move ever faster. In software, no matter what, speed is always a virtue. Which means that sometimes old, slower ways fade away and accelerants appear. That’s not a risk to our business. That’s literally the best thing that can happen.

Paul Ford is the CEO and co-founder of Postlight. Talk to him about digital transformation at hello@postlight.com and find him on Twitter @ftrain.

Once you’ve seen a beautiful project torpedoed before launch by a corporate decision — all that money and time down the drain, all that code left to rot on an internal server somewhere and never to be seen again — well, you’d like to avoid that. Forever.

When we started Postlight, we decided we’d push the opposite approach — we wanted to earn a reputation as the company that ships no matter what.

To deliver on that mission, we built a lot of management consulting right into our practice, under the guise of product management. We talk about it all the time on the Postlight Podcast (even more than we talk about tech itself), and we wrote Catalyst — our guide to shipping digital products that focuses less on the software part and more on the organizational politics and managing up required to get something shipped.

Software doesn’t ship to market without a lot of people championing it and pushing it forward. And you need all the help you can get.

“Managing up” gets a bad rap. Builders find it annoying to present their decision points to people who don’t know their craft; leaders are annoyed by people who are driven by software questions and less by business drivers. Everyone ends up patronizing everyone else and still the projects get cut.

But let me throw out an alternative that’s good for everyone: We refer to it as dashboard-driven development. The idea is pretty simple to execute and it can create buy-in all around.

Scenario

Let’s say you’re building a new product for real estate appraisals. Someone is going to take a tablet computer and walk around a house or apartment, entering data, taking pictures, and writing notes, and from there they can decide what the property is worth, so that the bank can decide whether to give that person a mortgage.

Your product is being built internally. It’s going to be faster! Better! The appraisers have complained for 10 years about the number of forms they have to fill out, and you’re going to cut that by 90%. Videos will replace images. These are great features! Everyone is overjoyed.

It’s also going to take 18 months to fully roll out to the whole company and it will cost a couple million dollars to develop. And during that time your boss, or your boss’s boss, will experience: a lengthy, difficult budgeting phase, quarterly review board meetings, bad days, good days, growth prioritization off-sites, a dip in business, and at least one serious corporate emergency. They’ll also be pitched on off-the-shelf software by salespeople on a constant basis.

You may not realize it, but they’re defending you. Even if it doesn’t feel that way, even if they’re not doing the greatest job at it — they think they’re doing the best they can. And add to this that you can usually keep a boss’s attention up until design is locked. But the next 15 months, presenting Jira tickets and burndown charts — it’s a struggle.

So what does matter to them? The dashboards. The analytics. The reports that will let them know how this line of business is doing, what returns it is generating, how much time it is saving, and how many growth opportunities it is delivering. Typically this is lumped in with a bunch of KPIs and promises.

Try this: “We want to do an exercise where we talk through all the metrics we can gather, and then design a dashboard together that will actually help you. Because when this thing is done, it will generate a ton of data, and I see it as my job to give you good tools to know what’s going on and to make good decisions based on data. It’s critical for our long-term success.”

Now work together. Whiteboard out what an “ideal dashboard” would look like for your boss — something they can use to make decisions and build the business.

Choosing Your Metrics

Come with a list of the kinds of data you’ll be able to gain from this new product. For the appraisal app, here are a few:

• Conversion rates for inbound business
• Overall financials
• Digital invoicing compliance
• Number of messages sent in-app
• Client engagement
• Time spent in app
• Number of jobs done per week
• Top performers
• Low performers
• Performance by region
• Time spent in transit
• Time to deliver final report

Not sure which analytics to propose? Look at the web pages for companies that offer more general versions of what you’re selling. Look at all their differentiators and back those into metrics (all I did above was search for appraisals). Start the conversation that way.

Now that you have the dashboards, you can return to this conversation every time you present progress. You’re not just building something for users, you’re building something that informs leaders and helps them make better decisions. The good news is also that dashboards, at this stage in the game, are pretty easy to build. There are tons of open-source platforms that make it easy. So you can actually show them real dashboards. That they can use. And ask them what they think. Ask them how they’d like to be notified of changes. What cadence is right? Do they want to log in every morning? Get an email? Get a text?

Now look, there’s a way to read this cynically. You’re distracting the boss with shiny things! But trust me, a boss really appreciates a good summary. And there’s no better summary than a good dashboard with well-considered metrics.

And in addition, you’re doing many things right for your product by following this approach:

• You’re defining the real business drivers that will sustain this platform long-term.
• You’re giving leaders opportunities to commit to and engage with digital transformation.
• You’re defining more parts of the value chain around your platform.
• You’re building a more coherent relationship between executive leadership and end-users.

That last part is key. You have to build for your users first — that’s an undeniable truth. But after launch, have you ever seen a bold product vision slowly get shattered by the addition of more layers of analytics, new frameworks, integrations with other systems? Look at what happened to news websites with online advertising — that’s just a highly visual example. It will happen to your great design, too. So one of the best things you can do is to think about how to protect your users, and their experience, when the future comes knocking with yet another third-party tracker, pixel, CRM integration, set of pop-ups, or data capture workflow.

Of course, while you’re building these sweet dashboards, you also have to build your whole new platform and software — the real work! —and the thing that people will use and that will feed data into the dashboards. But that part of the work won’t be so abstract to your stakeholders because you’ve invested time in their needs. You’ll have made it easier for them to protect you. And they want to get promoted, too, just like you do.

Paul Ford is the CEO and Co-Founder of Postlight. Talk to him about digital transformation at hello@postlight.com and find him on Twitter @ftrain.

Tech After Trump

Eventually, the current chaos will subside. What will the tech industry look like over the next four years? What should we expect?

These aren’t predictions as much as possibilities. The point here is not to magically assert the future, but rather to think about places where pressure is building up, and where things might change as a result. Also, after a year of mounting bad news, it’s very therapeutic to imagine some good news. Here are some things I’ll be watching.

The Big Changes

Regulation: There’ll be more

This one is obvious: There are going to be many more congressional hearings about social media, app store guidelines, platform lock-in, and the like. Policymakers will draft new regulations around transparency and labeling media sources. Maybe protecting consumer privacy sounds good, but much of this policy will simultaneously peck away at user privacy in the interests of law enforcement.

As this unfolds, copyright holders (news and other media) will line up asking for kickbacks from the social networks, and also will ask in many ways for the government to break (especially) Apple’s 30% lock on in-app purchases. European efforts like the GDPR or even the Right to Be Forgotten will be mined for inspiration.

All of this will come as a relief at first, and then cause a massive internet freakout as we see just how many things are being horse-traded in tech regulation’s name. Eventually, sure, the industry will just code the legislation into terms of service, make everything opt-in, and keep printing money. But there’ll be a lot to work out first.

Silicon Valley: It’ll be weird

It’s going to be an odd stretch for Silicon Valley. Lots of tech leaders abhor regulation, so there’ll be a lot of stomping around on Twitter and Clubhouse and Parler and wherever else tech libertarians go to farm their rage. Simultaneously, half of the USA sees “tech” as a democracy-destroying monster, which is bad for the brand. And, meanwhile, the pandemic has shown people how to work at home — and the FAANG companies will only become more physically decentralized, even as the services they provide (and acquire) will become more digitally centralized.

If I were being cynical I’d say that it’s a shame Halt and Catch Fire is already a TV show, because it’s a great way to describe Silicon Valley’s geopolitical future. And yet…I’m bullish, as usual. City-states are an ancient technology that work really well. A lot of people will work from home, and a lot of Twitter-account VCs will complain about the fascism of any form of regulation. But then they’ll invest in new startups that create marketplaces to trade around the new regulations, and everyone will go to The French Laundry to celebrate their C round, or whatever it is that VCs do. In the long run, tech is everywhere — when you pick up your phone, you don’t care that AT&T was a New York City company — but it’s still a long run, and Silicon Valley has a lot of money and ideas to go. It’ll keep breeding unicorns.

Civic tech: Lots to build on

The good people of the US Digital Service, 18F, and other civic tech ventures have all been working steadily over the past four years, like ambulance drivers in a bad hurricane. Many thanks to them!

Now it looks like a lot of energy is going to go into making a better, more responsive digital government, and instead of starting from scratch, this time there’s a ton of work done around accessible design systems, basic tech infrastructure, authentication and identity, and so forth. Which means that people working in civic tech with broad mandates should be able to ship meaningful services to civilians or servicemembers with months, not years, of work.

And you can increasingly expect government orgs to ship good stuff: open source code, scalable APIs optimized for reuse, and so on, rather than monolithic software. As a result, the U.S. government “platform” is going to keep growing and getting more valuable, month over month, and lots of people who wouldn’t have wanted to serve under Trump are going to want to help. Which is great, as long as they listen and learn before starting to code. (Check out Cyd Harrell’s book, A Civic Technologist’s Practice Guide.)

There’s one huge caveat here: Contracting. It’s still ridiculously difficult for smaller, more nimble organizations to work with the government. (For example, a few years ago I started talking with a government agency about some work it wanted Postlight to do, and it dragged on so long that my contact…retired.) So even if the tools are good, and the desire for progress is real, execution will be hard. Giant orgs will still take government money, burn it, and ship a month’s work in a year. And of course, we’ll still only be talking about a few systems out of thousands. Still! Fun to watch, with big impact.

Climate work: Here it comes

As climate guidelines get baked into law, and thus into business requirements, and money frees up to implement new climate guidelines, climate sensitivity will need to be baked into technology platforms. For example, if you’re a giant company deciding where to buy your aluminum, you’ll need to factor in the carbon involved in mining, refining, and shipping, and weigh that against a bunch of other factors. If you gain any kind of credit for that, how do you exchange it? (In Kim Stanley Robinson’s new book he posits a sort of blockchain for carbon credits, and I mean, whatever works.)

A lot of this has started already. But much more will need to happen in the big sleeping whales of software: inside enterprise resource planning systems, mapping tools, and the like, built into SDKs. It’ll be dry stuff, but there’s a lot to do. Judging from Postlight’s inbound queue of work, I expect this to be a major growth area for client services over the next…well, probably forever.

Social fragmentation: We can hope

The monolithic hold of social media over the internet’s attention is starting to fragment. First, self-regulation by orgs will change some dynamics — like Facebook’s promise to stop running political ads (eventually), or Twitter’s labeling of “disputed claims” on Trump’s tweets. Government regulation will change it further.

It seems inevitable that “third places” will show up — the “first place” is email and chat, the second is established social platforms with all their rules, and the third are places that are somewhat public but not open to all, new platforms where people can yell and stomp around and be themselves, like the far-right Twitter clone Parler, which will probably implode due to infighting but will lead to a lot of Mother Jones articles in the meantime. Or Mastodon instances, or small Slack communities. Ultimately it’s a pretty small percentage of people who want to fight all the time; most humans want to trade recipes, say stupid stuff about sports, and engage in mild piracy without anyone yelling at them. In addition to severely damaging democracy, the big social platforms are doing a bad job of filling that market need, so I’d expect other solutions to arise.

Be mindful, though: The social giants aren’t going away. Trump will still be tweeting in 2024, and hundreds of millions of people will be engaged/enraged. But the platforms can’t remain this monolithic and centralized; humans are just too inconsistent to keep this mess going.

So, what to do?

So how will this trickle down to we the people, who make the platforms and apps with our keyboard-typing and mouse-moving? This is obviously even more of a set of guesses than the above, but consider some new probabilities.

Expect a lot of opting in

The idea that you can track someone around the internet — because…well, because you want to — could fade away, partially because of moves by Apple, and probably because of some influence from the government. You’re going to have to ask people for data, not just help yourself, and you may need to give people the right to manage and erase their own data. I could even imagine that being automated — imagine a really big DO NOT EMAIL list controlled by the government, but with teeth. The right time to have started collecting opt-in email addresses that can be used as unique account IDs was 20 years ago; the second best time is today.

Start looking for ways to “climate enable”

Climate science is hard, and if you’re a tech-oriented person, it’s a little…well, boring. There’s no IDE or YouTube tutorials, just a lot of science. But it’s pretty likely that the next four years will involve a lot of global warming mitigation efforts, and that means lots of sensors out there, lots of data to analyze, lots of machine learning models to evaluate, lots of supply chains to optimize in new ways. It won’t all be carbon calculators.

It’ll trickle down. You might build accelerated insurance claims software for people whose homes are damaged by increased flooding. Or tools for notifying people about weather events. Or build tools for hardware chains to help people pick more sustainable, resistant home repair materials. Better fire notification systems. Platforms for emergency preparedness. Tools to help farmers manage and predict drought.

I know this sounds kind of dystopian. That’s because it is. But it’ll happen bit by bit, and as it happens, people will still be buying things through their phones and filling out forms. When you see that McKinsey is coming down hard on the need for organizations to adapt to climate change, you know that the rest of capitalism will eventually follow.

Light a candle in hopes of app store changes

This is a stretch, and wishful thinking, but just imagine for a moment if Apple suddenly was forced to charge 5% for in-app purchases instead of 30%. You’d see a vast, thriving ecosystem bloom in hours. It’s just a huge tax we all pay. Fun to think of what you’d do if you could get a quarter of your revenue back! You could do so many more interesting things with that money, whereas Apple will just use it to hold more events announcing updates to Apple Watch.

Fun fact: Just before we hit “publish” on this post, Apple announced that small businesses will have their app tariffs lowered to 15%. I wonder why they made that decision right now, after 12 years? Hmm!

Experiment with new distribution strategies

Social media plus Google ads have taken all the air out of every room and it’s essentially impossible to make something new and share it with an audience, without paying tons of money to billionaires, or turning everything you make into memes. Plus, no one visits home pages.

That’s why newsletters are big now: Because they provide reliable, predictable, cheap means of distribution since social won’t and can’t. Another means of distribution is phone notifications; the New York Times, for example, is hiring a full-time mobile notifications editor.

So even though one-off apps are weak sauce, people will keep making them because they let you regularly ask for attention and engagement without paying Facebook or Twitter for the privilege. You could even see a renaissance in RSS feed readers (Substack is apparently building its own!).

Creating audience without paying a huge tax to some utterly disinterested gatekeeper is the great challenge of our age.

Somehow podcasts will ignore all of this but keep doing fine.

Going big

Maybe over the next four years little changes: The social networks and Google agree to behave a little better. Fake news flare-ups are a normal part of life, but everyone follows a more transparent rulebook. The newsletter fad crashes because no one wants to pay for that much media, and big players like The New York Times and The Washington Post keep growing. There are more privacy rules to follow, but in general, if you use well-known user tracking and analytics platforms, you don’t get into too much trouble.

Or perhaps it will come down to a change in tone: The Biden administration focuses on “de-polarization” (a little different than bipartisanship) and makes social media a big target of action while encouraging the Republicans to reject Trumpism, in the hope that America can just chill out. The FCC starts to keep closer tabs on a lot of FAANG companies, including bigger telecoms. As a result, the giant platforms go on a charm offensive and start working together around pandemic preparedness, climate, and so forth — i.e., helping the administration with its policy goals in their own self-interest. The changes start to trickle down at the API and SDK levels, with things like Apple’s CarbonKit.

For fun, let’s turn the dial all the way. Maybe we’re headed to a huge climate-driven economic reboot: VCs funding climate mitigation marketplaces, the option for every Amazon purchase to be offset, huge amounts of government spending, vast changes in finance, insurance, and real estate. Partnerships with China on climate start to change the trade relationships as well, and more Chinese software platforms get relaunched in the U.S., à la TikTok. TPP gets resurrected. Huawei is forgiven and buys the state of New Mexico!

Or maybe there will be pressure from all corners, leading to increased regulation and pressure to break up major components into multiple companies: Amazon to split off cloud, Apple to manage in-app purchase rates, rules about lock-in, everyone managing their own data. That’s a lot of change for four years, though.

And of course I’ve mostly neglected the gaggle of black swans out there flapping around. I’m assuming vaccines, stability, a relatively stable market — I left out a lot of the bad stuff, because I think we’ve been playing those scenarios out for years now. We already know what it looks like when tech treats humans like a cheap natural resource.

What’s obvious to me is that the next four years will be an opportunity for tech to de-center itself from every single conversation about politics and culture. It can do that by accepting that it’s…infrastructure. (I love infrastructure.) I know we’re supposed to be the most disruptive industry, but the world doesn’t seem to be craving any more disruption. Maybe we could focus on stabilizing institutions instead of destroying them. Just for a minute. Even half a minute. One can always hope.

Paul Ford is the CEO and Co-Founder of Postlight. This piece was originally published on Postlight’s Insights Blog. Talk to him about digital transformation at hello@postlight.com and find him on Twitter @ftrain.

Twice a year we bring everyone who works for Postlight to New York City — from around the U.S., and from Beirut, with their families if they choose — and we all work together for a week. We call it Remotes Week. Teams visit clients, clients come to the office, vendors stop by to say hello. We do a hack day. Not a lot of work gets done. The office is like a mosh pit. Toward the end, we do a big all-hands meeting and go to the holiday party. It’s ridiculously expensive to bring dozens of people to New York City, but it’s always worth it. But of course, not this year.

Yet in the spirit of things, we decided to have “Remotes Week” anyway, and called it “We Are All Remotes Week.” Like everything this year, it was a pale imitation of normal life. But it also illuminated what’s changed.

One side effect of the pandemic is that we rehearse a lot more. Communication with 70 people over internet video is hard. For the all-hands presentation, my Co-Founder Rich drafted the deck with input from all over, and then we practiced the pass-off from leader to leader. We also cut out a ton of detail. Tell people what happened, focus on what’s next, and keep it moving.

Rich put in stock video of cheering fans behind all the promotion announcements. We walked through the work that our Action Committee did toward social and racial justice. We listed all the perks we’ve had during the year: mailing coffee and ice cream (with a vegan option); money for office equipment, obviously; the time we gave everyone 1% of their salary as a random bonus. We didn’t mention the time we hosted a live donkey on Zoom, but we did once host a live donkey on Zoom.

And then we had Minecraft! Thanks to hard work by Jeremy Mack, a Managing Partner who leads Engineering, and Operations Coordinator Paula Chew, who created dozens and dozens of Minecraft accounts and Discord accounts — we were all invited into a big open area called the hub. We all logged onto Discord as well to chat. Jeremy then guided us to an all-hands auditorium.

We chatted for a bit, and then Rich and I were asked to fight to the death as Co-Founders. Rich was confused and dropped his sword, then picked up a cactus, so I was able to kill him quickly. A melee broke out, and the company started in a frenzy of murder. I was killed soon after.

Then we went through another portal. And this part was just magical. It was New York City, inside Madison Square Park, right where you’d come off the R train to walk down to the office. The model covers from around 19th St. to 36th St. It doesn’t include our office at 17th St. and 5th Ave., but that’s okay. We just ran around like feral children, lighting fires, laughing on Discord, damaging the Empire State Building.

And finally, through another portal, where there are plots to build — the “hack day” for 2020. Some teams haven’t had a lot of time to do much, other teams have absolutely gone wild. There’s a roller coaster and Mario. However, senior management’s plot is just pitiful. We don’t deserve to work at this company.

It was a moment of pure folly and joy for anyone who logged in, and just a source of true joy. It wasn’t a holiday party, but it was close.

If there was a holiday party, I’d make a toast. But of course, not this year. So this was my toast at the all-hands meeting:

We pride ourselves on work-life balance. But work-life balance in the past eight months? What is it? It’s been obliterated. Work is in life, life is in work. Everyone is on camera. Families are in and out of the frame. I know some of us have had the worst days of our lives in the past eight months. I know I don’t know all of it, or most of it. But I know that it’s been hard.

The work you did forming relationships and building trust, and supporting one another over the past eight months, many of these relationships are going to last for the rest of your life. Those relationships are much bigger than Postlight. You’ll be amazed. Some of you will still be checking in with one another 30, 40 years from now.

So celebrate that. Celebrate that you did a great job. In the midst of absolute chaos, you all did a great job. We did a great job. Lebanon has been through hell, New York City has been through hell, the world is in the middle of a disaster, but the part that we could control, the only part that we could truly control, we did a great job. I am lucky to work with you.

Imagine that delivered in a serious tone, but with occasional awkward sound effects that we used to keep things light. Then we closed out the all-hands with a video montage of the work people had done all year, made up of their demo videos. I wish I could share it, but client confidentiality comes first. People are proud of their work, and they should be.

This has been a very trying time. We’re not done with it yet. People are still utterly cooked. But ultimately we figured it out. We’ve got some scars, but we’re stronger. Tell people what happened, focus on what’s next, and keep it moving.

Paul Ford is the CEO and Co-Founder of Postlight. Get in touch at hello@postlight.com, and find him on Twitter @ftrain.

Postlight has short contracts, and we’ve discussed contracting on our podcast many times. As a result, many people have emailed us, asking if they could see our contract and use it themselves. Enough people have asked, so we’ve decided to go ahead and share it widely, for anyone who finds it useful.

Before co-founding Postlight in 2015, I lived in fear of the law. Not because of my crimes, but because I had mostly worked in and around the media industry, and the number one job of anyone in media is to avoid litigation. You might think it’s “write and publish great articles” or “make compelling podcasts.” But it’s not. You just never hear about it because no one wins awards for not getting sued.

So I was glad that my co-founder, Rich Ziade, was a New York lawyer turned technologist. If someone threatened to sue us, he’d know what to do. Contracts would be his department. He could deal with those thousands of pages of mess. Thus, I was a little underwhelmed when he showed me our standard contract and proudly said, “Here we go.” It was just two pages. I’ve signed longer contracts when adopting a cat.

What about all the indemnity clauses, intellectual property clauses, exit clauses, and so forth? I didn’t know much about the law, but I knew you need clauses. “It’s all covered,” he said. Okay.

So I read the contract. It was…well, it was readable. Not fun and sprightly, still a contract, but clear — and indeed it did cover all of that stuff, albeit briefly. And Rich had run a software business for a decade before we started Postlight. Still, it made me nervous. “What happens,” I asked, “if someone sues us?”

“Anyone can threaten to sue anyone at any time,” Rich explained. “I could threaten to sue the guy at the bodega for making bad coffee. You can’t live your life in fear of lawyers. If someone sends us an angry legal letter, I’ll just call them on the phone and talk about how to resolve it.”

The Three Rules of Contracts

Then Rich said three things that have been lodged in my brain ever since — the Three Rules of Contracts.

1. “The relationship is all that matters.”
2. “A contract is just an instruction manual for what to do when things go wrong with a relationship.”
3. “Our goal is to build the relationship so that the client never feels the need to go back to the contract.”

This might sound obvious, but it’s a subtle reframing that robs the contract of its magical powers and puts the focus back where it should be, on keeping an open line between parties. “The law” is just another gigantic human construct that everyone has agreed makes sense, like democracy, the World Wide Web, or Bitcoin.

Software development is ambiguous work. You agree on one result, but three months in, it’s clear that a different result will be needed. Even with the best, most efficiently run projects, direction can change many times. It might feel like the smartest, most cautious path is to attempt to document everything in a contract and a statement of work, but it’s frankly a fool’s errand. You can’t. Everyone tries, even though it’s pointless and it all changes. We just decided to stop pretending. 

As a result, our statements of work are short too. When we send over our short contract, usually four pages max, we often hear, “Wow, that’s a short contract.” Most vendors love to give you 100 pages. But when the legal team on the client side get involved, they typically go, “Oh, this is great.” They add a few comments and ask for a few small changes around cancellation clauses, or they want to tweak various obligations. Most of the time we go, “Makes sense,” and that’s it. Usually it takes a few emails.

When things go wrong

And all of that works very well. When there’s a dispute, and the client sends an email asking for a call, it typically goes like this:

The client says, “I went back to the contract, and I think we are still owed Feature X.”

And sometimes we say, “Yeah, that’s right, it’s in the Statement of Work, and we will do that for you.” And we do it.

Or sometimes we say: “When we changed the product road map four months ago, we talked about how Feature X isn’t relevant, but Feature Y would be more relevant and lead to a better product. So we built Feature Y instead.” And the client says, “Oh, that’s right. Hmm. Okay.”

Remember rule two: When clients go back to the contract, it’s not time to panic or get defensive. It’s a moment to understand what’s happening with the client. Sometimes they’re a bootstrapped entrepreneur who’s naturally worried that they’re not getting everything they paid for. Sometimes their boss has said, “You go get me all the software in that contract! I don’t care if they shipped Feature Y, make sure they ship Feature X too.” Sometimes people are having a bad day.

Here are the things I’ve said in response to those calls:

“I’d love to work with you to find the best path forward.”

“I can understand why you’re concerned, so let’s take it point by point and find solutions.”

“We fully stand by our work and our obligations. Let’s figure it out.”

Because that’s rule one: The relationship is all that matters. You can’t fix a relationship with a contract. You can’t make a great software product by editing a contract, either. You have to have a relationship that works.

As a result, even though we have dozens of live relationships in the firm — and we keep all of our contracts nicely organized in a knowledge base for instant reference — I almost never look at those contracts, except to refresh my memory. That’s how it’s supposed to go. I probably dig in on one contract a year.

There’s a thing I find myself saying more and more about Postlight: After five years, it’s not an accident. Whatever is good (or bad) about our organization, it’s the result of our actions, often actions that were taken years ago. Our contracts are part of what makes us who we are.

One of the first things we did when starting Postlight was write up a charter. It’s an open document that we review every year as a whole firm. When new employees come on board, it’s shared with them and they’re asked to read it. And the first two statements about client work are:

And that’s why we keep our contracts short and clear — because that’s in the best interest of those relationships. After five years, we feel confident that our approach is solid. Rich’s “little” contract is a big part of our success. We can say with confidence: It’s not an accident.

The contract

And here’s that contract. Read and enjoy. Obviously we are just sharing a document, not offering you legal advice — go ahead and review it with your own lawyer before using it. And as always, we’re glad to hear what you think.

Paul Ford is the CEO and Co-Founder of Postlight. Get in touch at hello@postlight.com, and find him on Twitter @ftrain.

If there is one lesson I wish the tech industry could learn about itself, it’s that most people wish we would talk less and listen more. Because the state of tech diagramming is bad. It has lost sight of the listener, and the story it delivers is TMI: too much information. The result of TMI for the listener is usually a sense of awkward discomfort, and ultimately, boredom.

Here is a typical chart of a cloud architecture:

Another systems overview chart from the United States Military:

When things are busy at Postlight, I probably end up drawing one layercake a day. If you work with me, you’ve seen my layercakes. At its simplest, a layercake is just a diagram made of a stack of boxes, and the basic idea is that the boxes on top are “powered by” or “built atop” the boxes below. Here’s a classic layercake — the “Semantic Web” layercake from 2002 — where each technology builds atop the other or connects to the others:

At its peak, a layercake is a storytelling aid that could fit on a playing card. It communicates the technological solution to the audience, and it becomes a tool they can use to tell a story of digital change to their peers, or maybe to their boss. Stories precede solutions. When we present the layercake, and someone asks, “Can you send me that diagram?” — that means it did its job.

Overbuild, then carve away

When communicating about technology via a layercake, you should remember that all software is basically the same. You might exclaim, turning away from your standing desk and throwing your Nintendo Powerglove to the ground:

“The hell it is, Sirrah! I use functional reactive programming to create user interfaces that are dynamically coupled to graph-based schemas! And that’s hardly anything like creating user experiences that are loosely coupled to relational data stores!”

Okay, and I love you. But listen: Don’t start there. Start here:

• Some software manages data
• Some software manages user experience
• Some software helps the data software talk to the user software

If that just seems embarassingly, awfully basic to you, well, that’s right. That’s where most people are. Would you rather be right or would you rather build software? (Think before answering.)

Since we’re in agreement, let’s draw all software ever as a diagram.

Pretty good, right?

Let’s say someone scheduled a call because they’re working for a government health agency. They tell me:

• They want to make it easier to book appointments for medical screening using smartphones
• They need to message people reminding them to comply with their medications and schedule follow-ups
• They expect hundreds of thousands of appointments and interactions per month
• They want to use off-the-shelf software, but their constituents use old smartphones, are SMS-first, speak many languages, and in some cases have cognitive or physical disabilities

First, I listen to them for an hour. I love this part. You learn about whole industries, ways of seeing the world, and you hear unbelievable horror stories about bureaucracy and exploitative consulting firms. What people get out of watching all the Marvel movies, I get out of listening to stories about global consulting firms. Big consulting is my Thanos.

After the call, I draw the three boxes above. Then I start to expand and move things around until I have a rough sense of the platform. It usually looks like this after an hour or so:

That’s for you to see the process. I would never, ever present this. Sometimes I keep going until I can’t think any more thoughts. Then I schedule a follow-up call. And a few hours before the follow-up call, I sit down and take away absolutely everything I can.

Share the plan, not your work

As a writer, it’s hard not to show all my work and notes and list out every sub-system. As a technologist, that’s even harder. But people are not buying documents. They are buying relationships. When you try to prove you heard someone by showing your work, you often stop listening. It’s more important to keep listening. 

“So I took what we discussed last week,” I say, “and sketched out how I think it could work. I’d like to work through where I am and understand your requirements a little bit more.”

Now I bring up this plan on a shared screen in the video call (or hand it out on paper when we’re in the same room, inshallah) and talk through each layer and each box, asking questions as I go and noting the responses.

Yes, as an occasional systems architect with taxonomist tendencies, I know the diagram above is kind of infuriating. It doesn’t actually tell you what’s inside the systems. It doesn’t mention CRM. Where is HIPAA? Different things are much more work than other things. No arrows connect anything. What is read-only and what is read-write? What cloud will it be hosted on? You can’t just say “third-party integrations” and leave it at that.

I am here to tell you that you can, and should.

If that conversation goes well — and often it does — we will be asked to prepare a proposal. Now our layercake gets eaten. It is turned into a table of contents and becomes the outline of our scope of work. All of the questions above should be addressed and turned into a plan, a budget, and a schedule. It is time to drill in, list all the integrations, and show off just how much you can do.

Making good layercakes

For most of my layercakes, I use a tool called Whimsical. Other tools that work fine include any presentation software, plain HTML with tables, or a piece of paper. I like Whimsical because it gives me almost no control over anything. For example, if I want to use color, I choose colors in the order presented in the palette dialogue. I avoid letting boxes have multiple sizes. When it comes time to make things nice, a designer should help me. Pride is the enemy of a layercake.

A good layercake:

• Invites scribbling
• Lets you see a whole system in a few blinks
• Leaves room for interpretation
• Works like the table of contents of a book
• Shows data/back-office at the bottom and user experience on the top

Frankly, I am embarrassed to find myself writing at such length about something so unbelievably simple. But then again, I am embarrassed to be in an industry that thinks spackling 500 clip-art illustrations into a document until it looks like the wall of an Egyptian tomb is good communication.

So, make it simpler. Then make it simpler yet. Make it so simple you’re ashamed to say it out loud. 

Now say it. Believe me, people will be happy to hear it.

Paul Ford is the CEO and Co-Founder of Postlight. Get in touch at hello@postlight.com, and find him on Twitter @ftrain.

Not long ago I wrote about the secret geographies of the office for Wired. I was a little surprised by the reaction. I expected people to yell at me, like usual, but instead people wrote in to say that they missed the office, too. They sent me pictures of their offices and maps of their offices. One “office” was a homeless outreach service in the West, which was a good reminder of how lucky we are in the tech industry to have the work and flexibility that we do.

A return to anything like “normal” is still probably six months away, but I like thinking about it. Like many companies, Postlight has gone fully remote. We’ve hired non-NYC employees across the organization, not just in engineering but in design and product management as well. We’re talking about how it will work to return to our offices and looking for both CDC guidance and best practices. The pandemic has taught us all patience.

So, we’re waiting. But in the meantime, I am really looking forward to a few things. 

Buying candy

One of the true pleasures of my job is when my co-founder Rich and I are walking back to the office from lunch and we stop at a store. We buy a ton of candy and treats, then scatter them around the big kitchen table. Soon, people gather and start chatting about treats, candy, and packaging. Some people love JavaScript, some love Figma, but everyone loves candy. It’s interdisciplinary.

Really long meetings with breaks

I know it’s ridiculous to say “I miss meetings.” Especially because I’m in meetings on video for six hours a day. But sometimes you just need to hash things out for six hours with a whiteboard and those sandwiches that seem to only exist in corporate lunch settings. Structured time with long agendas during which you can be playful, take breaks, go for a walk around the block, watch some dumb videos, go out for lunch — it feels like it’s been a year since anyone has been able to change the topic of conversation.

Less hierarchy

Video meetings really enforce existing hierarchies. Casual interaction and chatter is difficult. So you end up talking to peers or people one level up or down, and it’s much harder to pipe up in meetings. And Slack channels are nice, but they aren’t serendipitous in the same way as when you overhear someone talking about Marvel movies while they eat random candy.

And increasingly, after a year of Postlight going remote, I keep finding that things I am sure everyone knows — our hiring policies, or why we’re called Postlight — hardly anyone knows. (Post is for HTTP POST! Light because we’re on screens! And also because voice interfaces were big when we started the firm, and so if people stopped caring about screens, we could be “post-light.” But thankfully that didn’t happen.)

Fighting with Rich

It’s important to be respectful to all, but I simply enjoy arguing with my co-founder Rich, calling him names, and making fun of every aspect of his personality and being. He enjoys doing the same to me. And it’s no fun to fight over video. It’s too much like a real fight.

After a year of being pandemic co-founders, leading an absolutely amazing team that does the real work of running the shop, and driving through the most dramatic period of growth we’ve ever experienced, we have defaulted to being very polite, caring, and tender toward each other. It’s absolutely exhausting, and it needs to stop. I didn’t move to New York City in 1995 to be tender.

My commute

Drop the kids off at school, get onto the bus or train, and watch the world go by with a book in hand. An NYC commute is an excuse to read and think for about an hour every morning. That feels like an absurd indulgence at home. 

It’s been a long year. And it’ll be a long stretch until we’re back, safe, and CDC-approved. But things are looking up, and I’m looking forward. Drop me a line with what you miss, too!

Paul Ford is the CEO and Co-Founder of Postlight. Get in touch at hello@postlight.com, and find him on Twitter @ftrain.

I like to watch software company videos, the more enterprise the better. At worst they’re hilarious, and at best I might learn something — usually a little of both. This hourlong one from SAP is representative: It starts with a gentle voiceover and slow-motion shots and people in wheat fields, and it’s basically incomprehensible.

If you’ve ever watched an Apple launch event, with lots of bright screens and cool products, enterprise software videos are the opposite. They bludgeon you with brand identity, stock photography, and corporate-speak until you’re reduced to a crouched, paranoid state, ordering Seeing Like a State off bookshop.org and planning your move to Taos. Why do they do this? Well, they had the budget. And it’s impossible to watch these without remembering the Veridian Dynamics commercials from the TV show Better Off Ted.

Enterprise software companies produce thousands of videos a year, almost all bad. So why subject myself? It’s good to know what the big players are doing, because as Postlight grows, we’re being pulled in on more proposals and competing with much, much larger companies. 

In those proposals, someone will basically list all the features of Salesforce, then cross out the word “Salesforce” and ask us what solution we’d recommend.

“We’d suggest…Salesforce?” we say. “Exactly!” says the buyer, right before they throw our very pretty and carefully produced proposal in the trash in order to go with a Salesforce Silver Certified Global Cloud Partner (or whatever) that has 80 or 800 times the number of employees we have, 10% of whom are Official Salesforce Cloud Ninjas. This way they can tell their boss: “We considered a custom solution, but ultimately it made more sense to go with Salesforce…again.” 

Enterprise software sales is a wonderful business. But also as we grow, we’re learning not to pitch where the odds are stacked against us. We implement using Salesforce at Postlight when our clients want us to.

My personal, nerd take on Salesforce is that it’s the object-relational revolution of the 1990s taken to its most implausible conclusion. Essentially, they start with CRM, add some fields, and call it a cloud. Have a lot of cows? Salesforce Cow Cloud. Cars? Car Cloud. Tracking weather conditions? Salesforce Cloud Cloud. A combination of seat licenses, enterprise inertia, platform lock-in, and being close to revenue means this thing absolutely prints money, so they can buy dozens of younger companies like Tableau and Slack. I respect it, and fear it, and find that the people who work there are basically as happy as anyone working inside a mega-corporation can be. 

The big problem is that whenever I meet anyone on the other side of a Salesforce implementation who isn’t focused on customer service — literally, neighbors and friends over to chat — they are often reduced to inchoate rage by the delta between what was promised and what was delivered. As we come out of the pandemic, I’ll be mindful to invite my enterprise software friends and my NGO/case-management friends to different parties. I don’t want violence.

Values, success, product

So this particular video. Even given what I just said above — given that it’s 80 minutes long, even though Salesforce is a colossal pain for smaller firms like ours, even though it gets misapplied in a lot of contexts — this is a very good video. They know exactly what they’re doing. I watched the whole thing and took notes. I walked around for a long time and thought about it. And ultimately I boiled it down to three words: values, success, product, in that order.

Values

First of all, it’s raining really hard and they’re on the roof of a hotel (COVID-19), and it’s always inspiring to watch people barrel through in spite of the elements. We learn that people in the audience are Salesforce Trailblazers — a sort of generic term for “people who do things with Salesforce” — especially admins, business analysts, and people who have entered the software industry via Salesforce.

You’d expect them to show you some software, right? That’s what I’d expect. The emcee, a director of marketing named Jon Moore, is warm and on top of his material. What he’s doing — emceeing an enterprise software marketing event and making it seem positive and natural, not cheesy — is incredibly difficult. Turtleneck/blazer is a great combo too; business and casual.

What the emcee does is drive home values, over and over. How does he do that? With lots of statements like, “We believe in doing well and doing good…because businesses are very powerful platforms for social change.” You can roll your eyes, but he doesn’t. 

Salesforce acknowledges Equal Pay Day, makes a public commitment to equality, and talks about a lot of large donations — a million dollars for COVID vaccines, for example. There’s a video montage of Texas employees helping people hit by the recent power outages. And I think, in general, Salesforce acknowledges that it operates within a society. This is sadly unusual. Most companies at this scale, such as Facebook, simply assume that society should run like they do.

At around minute six — this is a long time to wait — you get to see…a video! It’s a montage about working remotely and “customer delight.” It’s a genial, positive, and progressive messaging video. Then, Marc Benioff, one of the richest men in the world, comes out holding an umbrella, and look, I have a lot of love for tall beefy dudes in software wearing comfortable clothes. If you’ve ever seen me you’ll know why.

Benioff simply cheers for everyone. Gives thanks to everyone. Thanks first responders. Keeps going and going, talking about all the good each group is doing. It’s not about him, not a bit. At minute 11 we’re still on values, and they put up a plaque with their four core values:

• Trust
• Customer Success
• Innovation
• Equality

Why do I keep watching? Well, I want to see the product. I want to see what happens next. I want to understand this thing.

Success

Benioff is incredibly excited about Salesforce’s values. He’s excited about everything. But they aren’t just Salesforce values; they’re “our” values. Over and over: “It comes from you, our customers.” (They also say the word “amazing” roughly 500,000 times.)

He talks about growth, revenue, and definitely success, and then he brings up a “Trailblazer” — a charmingly nervous, well-prepared woman who became a business analyst in order to be a better provider for her family. She tells a story of growing her career with Salesforce. They give her a “golden hoodie” and a Salesforce doll. Benioff obviously loves this part. The guy likes making jobs with software. He says: “Help other people.” He says: “Marshall McLuhan once said ‘the medium is the message.’ That’s the message right here at this event! We have to change!” 

Look, a CEO has to be able to say incredibly simple things with enthusiasm over and over again, without any irony, and this person is good at it. There’s just a lot of earnest strategy here. And underneath all of this, there’s a specific rhythm: Lead with values, move to success, then back to values. Over and over. 

The event is entitled “Success From Anywhere World Tour.” We’re at 22 minutes, hearing about how it’s been an amazing year, and the presentation flips between a slide of Salesforce philanthropy to a slide about cloud products. Describe your values and demonstrate the success that you can achieve with the platform. 

At minute 25: You can hear the rain coming down, and now, finally, we are talking about software. Benioff hands it off to Bret Taylor, the COO. And I have to admit: I’m kind of enjoying this? These people appear to have met each other before. They speak like people. They’re incredibly wealthy but keep going to work every day. That’s pretty good in enterprise.

Product

So now we see the product, right? Nope. Instead, Taylor starts talking about Salesforce as a suite of products, and how it’s enabling remote work during the pandemic. We see charts of the ecosystem, how all these enormous pieces fit together.

At 30 minutes we see a mocked-up screenshot of the “Sales Hub” — 30 minutes until screenshot! My god! Finally! 

But no — Benioff returns! And we meet Jessica Tisch, commissioner of the Department of Information Technology and Telecommunications for New York City. For her, Salesforce has put together a vaccination scheduling platform for NYC (I used it, it had issues; nonetheless, I got vaccinated and went back to the office). She talks about their partnerships. We still don’t see screens. Friends, I am losing it. 

In fact, it takes until the 45-minute mark, three quarters of an hour, when we finally see Lynne Zaledonis, an EVP, who warmly walks us through the full user journey of a person who is going to be vaccinated and all the touch points that connect them to Salesforce. We actually see the technology: how it feels, how it’s built, and how all the different pieces (like Tableau, Mulesoft, Einstein) work together. It’s called…Salesforce Vaccine Cloud. “Amazing,” says Benioff. My brain basically starts leaking out of my ears at this point. I keep watching.

And fine, from there on it’s more of the same. We see more videos, more demos, and the inspiring story of how Honeywell uses Salesforce, which is sort of like hearing about how Germany sells a lot of optical equipment to France. Interesting, but what does it have to do with me?

More and more in this ilk. Eventually it wraps up, and they bring out Sara Bareilles on a baby grand piano. She sings “Love Song,” and says some nice words about Salesforce. Later she does “Brave.” She has a great voice.

The anti-demo demo

For two weeks I cannot stop thinking about this goofy video. I’ve never done anything half as compelling. I’ve got to give it to them. I ended up watching an 80-minute ad, and then ended up writing about it. What I finally figured out is that the algorithm here is very simple:

• Describe your values and how you give back to different communities.
• Talk about the success of the people who work with your tools, connecting the values to the success.
• Repeat until you’ve described everything that is not a product.
• Demo the product.

Or rather: values, success, product. In that order. And take your time.

I’ve started to think a lot about this segmentation in a lot of my own communication inside and outside of Postlight. I mean, we’re a values-led firm. We give away a lot of money on behalf of our employees, support employee resource groups as part of our DE&I effort, and try to advocate for careers. And we see it as our job to advocate for client success — at some level, when you engage an agency, you’re hiring us to move your own career forward. And we love to build products, for our clients and ourselves. We’re building a new SaaS product right now, in fact. Can’t wait to show it to you. It’s solid.

But I’m now convinced I’ve been coming at it from the wrong direction. What I like to do is show people a product, explain how it created success for the people involved, and then, if I have time, explain how it connects back to values. 

Think about how Apple events go, with a huge, shiny object gleaming on screen, so that everyone watching thinks, Now this is for me. This is demo culture. It’s a huge part of how the software industry talks about itself. Lead with product, describe success, sprinkle some values on top. 

But Salesforce here is anti-demo. And it works because it builds up the case for why their entire ecosystem works, why it’s good for you, and why you should invest your time and energy and build your career around these technologies. Frankly, if my daughter came home and said, “I want to be a business analyst specializing in Salesforce and learn to program in Apex (the official language of Salesforce),” I’d breathe an enormous sigh of relief, because right now she shows a lot of signs of wanting to write fiction. Of course, she’s nine. Still.

Community over individual empowerment

The classic software demo, the kind that Steve Jobs excelled at, was about individual empowerment. Use this thing and enjoy absolute superpowers. Isn’t that great? But this was less about individual empowerment and more about community. The product here is your success as a Trailblazer. Not some new cloud technology, not the software, not even ease or simplicity. Instead of Isn’t that great? it’s Aren’t you great? Aren’t we great?

Values, success, product. I came ready to mock and left impressed. I’m going to communicate in this sequence forevermore. Values, success, product. And I do wish my friends wouldn’t come over to my house and complain about Salesforce as a product. But then again, that company gives away a lot of money and it is worth $212 billion. You can’t have everything.

Paul Ford is the CEO and Co-Founder of Postlight. Get in touch at hello@postlight.com, and find him on Twitter @ftrain.

We’re pleased to announce that Gina Trapani has been named Postlight’s Chief Executive Officer, and Chris LoSacco has been named President. Gina has been with Postlight since 2016 and became partner in 2017. During her tenure at the firm, she’s overseen complex engagements for our varied client portfolio including the MTA, Mailchimp, VICE Media, and The Players’ Tribune. Chris joined Postlight as a founding partner in 2015. Since then, he has led major platform projects for the MTA, VICE Media, Goldman Sachs, Oculus, Cision, and Synacor. 

Over the past year, Gina and Chris partnered to build Postlight’s Digital Strategy arm — dramatically expanding the breadth of Postlight’s client portfolio, building out new service offerings in content strategy, and growing the firm’s headcount by 50 percent.

“These are two natural leaders who complement each other beautifully,” says former CEO and Co-Founder Paul Ford. “They’ve been running the shop for a year as true partners. They’re advocates for our employees, they’re advocates for our clients, and they’re uncompromising about quality.”

“As we gave more and more responsibility to Chris and Gina, it became clear that they were quickly maturing into the leadership of Postlight,” says former President and Co-Founder Rich Ziade. “We’re a bigger firm now and this is a critical step to ready Postlight to scale.” 

Rich and Paul will remain at Postlight as full-time executives and will both retain the title of Co-founder. Paul will work on standing up a new climate change-focused practice, building on Postlight’s existing portfolio of climate work. Rich will lead in-house development of a new software-as-a-service platform to be announced at a later date.

“Rich and Paul built a premium client services firm from the ground up, and I’m so excited to partner with Chris leading Postlight into its next phase of growth,” Gina says. “We will double down on Postlight’s mission to drive success to our clients, and create a great place to work that builds careers and has a positive impact on our communities and the world.”

“Helping to build Postlight over the past several years has been the most rewarding time of my career,” says Chris. “Gina and I work exceptionally well together and we’re thrilled to be defining the future of this company. We see tremendous opportunity ahead.”

“My partnership with Rich has been one of the greatest things to happen in my life,” says Paul. “This firm is built on mutual respect, deep partnerships, and an abiding fascination with what technology can do for culture. Gina and Chris are going to take that forward. It’s a fantastic moment for us and I’m proud and excited to see what comes next.”

Postlight continues to focus both on digital transformation and on rapid delivery of finished software platforms for some of the largest organizations in the world. We’re headquartered in New York City, where our team of software engineers, user experience designers, product managers, and digital strategists define, design, and ship digital platforms for clients across industries.

“We’re incubating an incredibly ambitious platform,” says Rich. The idea started small but the vision is big and Postlight is the perfect environment to turn it into reality.” 

Postlight has an extraordinary team of people who love to make great digital products — and we’re hiring. Come join us.

Gina Trapani is a technology leader who has been building software and companies for two decades. She is best known for founding Lifehacker, the blockbuster tech and productivity blog acquired by Univision in 2016.

Chris LoSacco is a digital product strategist, team leader, and thoughtful technologist. He has led major platform projects for the MTA, VICE Media, Goldman Sachs, Oculus, Cision, and Synacor. 

Paul Ford is a writer, product strategist, educator, programmer, and software consultant. He has consulted on and led digital and editorial strategies for organizations for over 18 years.

Rich Ziade is a noted leader in the New York City technology community and a globally recognized product leader. In 2004, Rich founded the successful digital technology firm Arc90.

I’d like to understand more about the world of statistics and data science, so I’ve been learning the programming language R. It has wide applications in the sciences (social and natural). There’s an IDE, freely available, called R Studio, which features a very large number of relatively sensible defaults and makes it easy to load up libraries. This meant that I didn’t have to learn much to get started, and had all the software I needed installed and ready to go in a few minutes. There’s also a set of connected libraries called the tidyverse that are obviously a huge improvement on whatever was there before. 

These tools help you turn messy data (i.e., most data) into a more normalized form, and then you can filter it, reorganize it, and finally, chart it. I’ve munged a lot of CSVs in my day via all kinds of pipelines, and the tidyverse is exceptionally well organized and thoughtful. It isn’t magical, it’s reasonable.

Like any language worth its salt, you can do anything in R, and people do. It has web servers and drum machines. But I’m suspicious of those. This is a language focused on transforming and visualizing data. The end result of an R program is something you feed into a report, a scientific paper, a work of analysis, a dashboard. R Studio makes it very easy to work with notebooks, which are a mix of prose, HTML, and code. It’s a special-purpose language but a very flexible one.

I’ve always been very interested in special-purpose programming languages, like Csound for writing songs, or TeX for composing documents, or NetLogo for running simulations. For some reason I always come back to them at the holidays. Nothing is more fun after I get the kids to bed than learning some programming language that draws 3D scenes, like POV-Ray. So I’m also enjoying R at that level. These languages have rarely been a major topic of study in the history of programming languages, although that is thankfully changing.

And they all raise a question that I think about a lot: Why is one language “general purpose” and another “domain-specific”? As I was starting my career, the big battle was between “compiled” languages like C++ or FORTRAN, which require you to convert source code to machine code before they ran, and “interpreted” languages like Python, PHP, or Perl, which didn’t. Which was better? 

It turned out that when you were programming web services, the ability to change a line of code, save it, and hit reload in the browser sped up everything dramatically. Eventually the lines always blur: People figure out ways to speed up the interpreted languages, and also create faster compiled languages. These battles can be surprisingly fierce, but over the years I’ve lost much interest in them. I like whatever 1) makes the computer go; 2) can be understood by mortals in a year or two; and (3) makes the current programmers happy.

I’ve also been talking to and interacting more with people doing data science from inside different disciplines — not data scientists per se, just people doing their jobs — and what keeps surprising me is that they’re programmers but don’t identify as programmers. The data they know about is the data relevant to their discipline; the programming they know about consists of operations upon that data. They don’t think too much about the state of their code as it runs, or where the variables go once they’re used up. And a lot of their code is imperative with big, messy variable names. They write code that needs to be run once a week, not a million times a minute. The end result is not a web API or front-end that needs to run all day but a CSV or an SVG with a graph.

I kept wondering: What’s the difference between what they do with, say, climate data, in R, and what we do with TypeScript, Elixir, Java, Swift, or Rust? What am I doing differently when I write R code to convert messy Excel files into charts that I can use to support a business plan, versus when I write some Flask code in Python for a small web project?

\n

\n \n

\n

\n

\n

\n

\n \n

\n\n

\n

I think it comes down to three things: 

1. First, we, the general-purpose software people, write functions that can be run millions or billions of times without breaking. (One hopes.) There’s a lot of subtlety in that work. 
2. Second, we create interfaces and experiences on top of our code that can be extremely specific to a specific job or role — commodities trading platforms, or systems for reporting train schedules to millions of riders. That takes a ton of design work and product thinking, work that would probably get in the way of someone who just wants their CSV to export. 
3. And finally, we instrument and analyze the performance of our code and systems because we want them to be as efficient as possible, and we get extremely worried when something takes half a second, because we typically need it to take about 20 milliseconds. And because we need to report analytics to our clients. They want to know how people are using the app.

Do R programmers do all of this too? Sure, lots of them do. Especially people writing libraries or building big systems for other R users. Are there lots of exceptions to the above? Absolutely. Nonetheless, I think there’s something in it:

Domain-specific languages are defined to create specific kinds of outputs; general-purpose languages are designed to keep running forever without any problems. 

Elixir is a great example: It is optimized for tons of parallel network connections, which is great for chatty client/server applications (like chat apps). You can do the same work in lots of languages, of course. We live in a world of riches. But compiled Elixir code is designed to stay up and run forever, catching errors, never failing.

When I asked people if I should use R, some said yes, and some said, “You already know Python, why bother?” R Studio is great, and R is great, and the tidyverse tooling is just a joy to use. Plus, the language itself wasn’t hard to learn. But it’s about what you can do with it.

Deep in its heart, R is a language for making charts, and it’s genuinely fun to go into its world: statistics, natural sciences, sociology — all right there. You will never pry me away from JavaScript or Python or the whole web stack of standards and protocols. They’re how I make things happen in the world, and they are very much my home base, but using more specific tools is always an education. It’s like suddenly discovering a new wing of a big museum, and realizing that there’s still a lot to learn.

Paul Ford is a Co-Founder of Postlight. Get in touch at hello@postlight.com, and find him on Twitter @ftrain.

Work for Postlight! Love making exceptional digital products? We’re hiring engineers, PMs, designers, and strategists. Let’s grow together. See openings.

Since stepping down as CEO of Postlight, I’ve been learning about climate change. This work is harder, in many ways, than my work as CEO. 

Climate change isn’t a single discipline. It’s a mix of climatology and paleoclimatology, statistics (especially statistics of probability), data science, parallel supercomputing, cartography, information visualization, international relations, macroeconomics, microeconomics, communications theory, technical writing, political science, risk analysis and management, systems thinking, materials science, construction project management, psychology, sociology, agriculture, energy systems analysis, physics, chemistry, fluid dynamics, supply chain management, and thousands of other subdisciplines, many of which involve huge legacy software platforms.

I cannot learn all of these things in a year, or in 50 years. But neither I nor the climate has 50 years (we have negative 50 years). Plus, I am alive right now, I have a column in Wired right now, I am the co-founder of Postlight right now. (Fun fact: Climate change work is already a big chunk of Postlight’s business.) So I should do this sooner rather than later.

I think there are two main ways I could help with climate change. (1) I am a technologist who can develop digital things that help people prepare for climate change or help them to release less carbon dioxide into the atmosphere. (2) I am a writer who can communicate about climate change. However, there are a billion ways I could screw up. I could advocate for innovations that don’t really work or push for solutions or approaches that seem promising but aren’t ready yet. I don’t know what I don’t know.

Thus my goal is: Learn just enough to be helpful, then do things with what I learned while I learn more ways to be helpful. An important part of being helpful is to never represent myself as something I’m not, e.g., to be absolutely unashamed of not knowing things, while pointing to people with more expertise. 

How hard can it be? You might be thinking, This guy is dumb as hell. I’m smart. I’m good at learning things. I’ll just read Wikipedia and become a climate person. But take a look at these two slides from the CarbonBrief.org trivia night. This is what truly deep domain knowledge about climate change looks like: 

They do this every year. It’s a disgusting quiz. These people are obviously very sick. But how did you do? I did very badly. That’s why I need to keep reading and using the resources I list below. None of these resources are without critics, but they’re all things that people acknowledge as credible, they are grounded in climate science first, and they all fit together into one body of knowledge. Nor do they offer simple solutions. They all start with physical risks before moving on to mitigation or adaptation strategies. 

While I am still finding my way, I feel secure recommending them to you. They’re sources of knowledge to make you think. They won’t harm you or the planet, and they are all very serious about the risks of climate change, even if they’re funny. I’d welcome hearing about other things I should see.

Starting point: Probable Futures

This is a not-for-profit organization that came to Postlight two years ago seeking to build a platform to communicate climate change and bring climate science into culture. The Probable Futures web platform is the result of a large team of people working together for a long time, with Postlight as one component of that team, and it’s one of the finest editorial/communications platforms I’ve ever seen, even if we did build it.

I have spent an extremely large number of hours looking at Probable Futures maps, and there is always something more to learn.

Also, I’ve worked with these people for years and have never seen them budge one iota from their mission of making a better future. It will take you an hour to read the entire thing. Every single word and image was chosen carefully by people who are building bridges between culture, finance, and science but always putting the science first. The site exists for the public good and is untouched by weird sponsors. 

If there’s one reason why I stepped down as CEO, it’s because I watched these nerds make cool maps and wanted to get in on it. Little did I know I’d end up programming a bunch of Python code to load geodata into a database while simultaneously ending up on a humbling, lifelong journey that leaves my computer’s desktop littered with PDFs and my brain feeling like it’s been microwaved nearly every night. They sure fooled me.

Science: The Woodwell Climate Research Center

There are many climate-focused scientific organizations, and I don’t have the skills to evaluate their differences. Woodwell is a well-known, incredibly respected organization that works closely with Probable Futures. I’ve worked with Woodwell’s data and have read papers by their team in the best-known academic journals. I subscribe to their email list and attend webinars they give. They are obviously the real deal in every way. I think you, too, should pick a climate center and adopt it and look at the events they throw, the things they talk about, and how they communicate with the world. I would even suggest it be Woodwell. Also, they’re nice, and their website is pretty.

Textbook: Introduction to Climate Science

I found this by googling “free climate textbook,” and I can’t recommend it enough. It’s written by a professor at Oregon State, and there is an epub version. It tells you about climate and paleoclimate, gives you an understanding of models, and has plenty of diagrams. It won’t be fast-going if you’re a liberal arts type like me, but if you plow through this book, all of the conversations happening about climate change in all of these other things will make much more sense very quickly.

General news: Bloomberg Green

There are many climate writers out there whom I really like, and some amazing newsletters, but the best one-stop-shop is Bloomberg Green. It covers the climate industry as an industry, and calls out green stuff that doesn’t live up to its own promises. It’s good, informed journalism. A lot of climate journalism focuses on how bad it’s going to get, and a lot of it is very serious and somber and evocative and prize-winning. But Bloomberg Green is just: Welp. Here we are. Its journalists did extremely well at the last CarbonBrief trivia event.

Unfortunately it’s expensive (you can only get it with a full Bloomberg sub), but I’m glad to pay for it. The print magazine is good too. I like it so much I worry about it. I need it to continue. (Disclosure: I’ve written for Bloomberg a lot in the past.)

Trade news: CarbonBrief

These are the people who write the questions for trivia night, operating at a level of extreme climate nerd. When you learn something about Earth System Models and find the Wikipedia page incomprehensible, or when everyone on Twitter who does energy systems is arguing with climate modelers about RCP8.5 in a huge and terrible thread, a good next stop is CarbonBrief. It’s a trade publication for the climate change world. It has good general explainers as well, but I find it most useful in helping me situate myself as I try to fathom the 8 billion concepts involved in this discipline, or to parse some argument I don’t understand. The next stop after CarbonBrief is actually reading scientific journals. Pace yourself.

Entertainment: A Rational Fear

This is a satirical podcast, created by Dan Ilic, about Australian politics, which is not one of my major interests. But it does something very specific and important. It makes climate part of the conversation in a natural way, as a fundamental aspect of any story. A climate activist might be in the room with a bunch of comedians, and they will have just as much voice as anyone else. People will joke about Rupert Murdoch electrocuting himself with a Tesla battery to atone for his destruction of the world. 

In general, Australia’s climate activists seem to be ahead of the US’s in how they work climate into things, perhaps because the country is, at its essence, an enormous flammable ovoid operated by coal goblins. The other climate podcasts I’ve heard are very…educational. But this one makes me want to hang out and see what else they come up with. I like getting notified about it. It makes me laugh out loud. I don’t despair when I listen to it. I need to donate to its Patreon.

What I’m doing

So how am I going to be acting once I’m done reading? I’m not a scientist or an activist, but I can discuss my own reactions to climate things. I can talk about climate reports as journalism, or climate models as software, and bring the journalism/software parts of my understanding to bear. For example, I could talk about a netCDF file filled with climate data and explain what’s inside, or review a novel about climate change, or discuss a document from the UN as a standard. I’ve been doing this in my Wired column, but perhaps I’ll start a newsletter to do just this; our world so desperately needs more newsletters. Perhaps in time I could become something like a climate critic. This is like being an architecture or music critic. You can’t actually do the thing, but you still get to complain.

As a technologist who co-founded a software company, I can do more work to bring the world of climate science closer to other parts of the technology world. The work with Probable Futures has shown me that you can look at climate data not as some immovable and impossible science thing, but as a kind of API to access the very nature of the Earth itself. It’s not as opaque as you might expect. It’s just…data.

A lot of people are talking about climate as a growth industry, and I’m sure that if I work hard on this, I’ll find opportunities for Postlight, but I think we have to be frank and accept that not everything worth doing is going to grow a company in the near term. That’s fine.

I’m sure I’ll get things wrong, because I’m operating from imperfect information. I hate that, but what can you do? And I’m sure I’ll need to ask for much more help than I’m used to. I think I’ll start going to protests. Now that I’m not CEO, I can get arrested without harming the company, plus my co-founder is a lawyer, which will be a real time-saver. I probably won’t chain myself to a tree, though. They don’t make chains in my size.

I’ve been humbled by this discipline, but I also recommend learning it. I’m not as scared of a future I can plan for. Over time I’ll share more about what I’m doing, what Postlight is doing, and what I’m learning. But mostly I’m going to point to what other people are doing, and this article is a start. If you’d like to reach out, my email is open. Go check out Probable Futures. See you soon.

Paul Ford (he/him) is a Co-Founder of Postlight. Get in touch at hello@postlight.com, and find him on Twitter @ftrain.

Work for Postlight! Love making exceptional digital products? We’re hiring engineers, PMs, designers, and strategists. Let’s grow together. See openings.

Working in technology, I’m always on the hunt for new ways to explain things. Not long ago, I asked Twitter if anyone could recommend exemplary explanatory videos. The replies were truly interesting. There were a bunch, but these five stood out for the way they use tone, visuals, and humor to convey complex things.

1. Erlang: The Movie

This video breaks down what’s interesting and novel about the programming language Erlang. It’s useful and dense but also a little silly. Erlang is showing its age as a language, but its core technologies carry on. And its descendant, Elixir, which looks and feels a lot like Ruby, is a popular platform for big platforms that involve lots of conversation (like chat).

2. Everything Is a Remix, Part II

This video is an updated Part II of a classic, and it’s notable for just how well it uses its medium. It would not work at all in a form other than a carefully edited video.

3. The collected works of Kurzzgesagt

These animated explainers are absolutely beautiful, bright, and shiny, with clear voiceover, which is great because they often present bad news. The recent video on climate change included below is exemplary because its thesis — that there are no simple solutions! — is the opposite of the typical reductionist solutions offered by most explainers. There’s something great about getting bad news via animated birds.

4. The collected works of 3Blue1Brown

This account publishes very careful explanations of complex mathematics using — and this is near to my heart — a totally custom math-animation tool written in Python, which a community has adapted to be more general.

5. Statistical Rethinking

Before I asked Twitter for advice on videos, I asked Twitter for advice on statistics, and the book the most people recommended was called Statistical Rethinking (once I was ready to go Bayesian). These are lectures by the author of that book, professor Richard McElreath. Okay, it’s statistics. But…they’re friendly, viewable lectures with good visuals, memes, and lots of wit. They’re paced for learning more than fun, which I appreciate. New lectures are published every week!

Bonus: Hexaflexagons

Of all of them, this one is the most fun. It’s just hands messing with paper. It’s nearly a decade old. But it’s charming, full of facts, and you truly do learn a good bit about hexaflexagons. They are cool.

Paul Ford (he/him) is a Co-Founder of Postlight. Get in touch at hello@postlight.com, and find him on Twitter @ftrain.

My son has been teaching me to play a Very Popular Video Game. As anyone with kids knows, screen time is premium — plus bedtime was coming — so I set a limit of 45 minutes.

That would have been plenty of time for a few battle royales, but this Very Popular Video Game needed to download a few gigs of updates, and our internet was spotty. So we had 30 minutes of downloads between our computers. My son is 10. He was bummed. “They have to do it,” he explained. “It’s how they keep people from cheating.” Frequent, game-pausing updates are just part of his life. Eventually we enjoyed the 15 remaining minutes, and he was rewarded by watching my character die.

Then, after he went to bed, I thought, You know, since I’ve got Windows booted up, I’ll play Flight Simulator. Except…guess what happened? Flight Simulator wanted me to download Spain. I could not play until I downloaded Spain. So I let that run for an hour. At which point, I was feeling pretty tired, and Windows wanted me to reboot, because it too had downloaded a bunch of updates. My computer’s 3D card had also downloaded some updates, and my computer’s fan. So I gave up and rebooted the machine into Linux, which wanted me to update to Ubuntu version 22. I started that, and then went to bed.

I’m not complaining. Or rather I am, but I’m accepting of this too. Frequent software updates are a big improvement over the days of gigantic service packs or new software versions with years between them. And since everything gets hacked all the time, they truly do matter — if you ignore updates, you’re inviting risk. And we who build software believe that software should be produced this way, with new features going out to users as soon as they’re ready. And for the most part, updates are invisible. We’re all using dozens of apps a week (if you could categorize websites as apps), and updates are being uploaded all the time.

For a while, it looked like everything would consolidate into your phone. Your phone would become your calendar, remote control, telecommunications platform, camera, mapping system, and so forth. And it did! But humans are funny — every time a platform emerges that seems to subsume all the other platforms, we end up making all kinds of new stuff to attach to it.

The era of personal networking

You may have a smartphone, and so do the other people in your house and your life. A Kindle. A laptop or desktop machine. A Wi-Fi printer. A smart tablet. Smart speakers or Bluetooth speakers. Your dishwasher and fridge might be online. Your car probably has multiple operating systems. Your air conditioner might be on Wi-Fi too. And then there are the devices specific to your life: the smart lock, the intelligent dog collar, the e-reader, the video game console, the router the cable modem people give you, and the router you connect to it. My TV runs an operating system. The $30 security camera you use to keep your son from eating all the ice cream.

I have 63 devices online in my house right now. This seems like madness, but when you tally up the phones, Chromebooks, watches, printers, laptop, speakers, and so forth — well, I still don’t know what many of them are. And all of these are…computers. They have operating systems, even if those OS’s are weird. A lot of them are secretly web servers; that’s how mobile apps connect to them and pull data. If these devices don’t talk to the internet, they talk to devices that are connected to the internet. Which means they really need to be updated, or your Sonos will be used to DDOS an embassy. And of course they need to be updated when the devices that control them are updated. That’s the worst part about updates: Every update necessitates further updates.

As software developers we should think hard about this. Obviously your updates are very important. But we should remember that they are only one of hundreds of things happening to any given device at a time, and they will inevitably slow things down for the user. They’re friction, no matter how great that security patch turns out to be.

I think all the updates are a symptom of the changes in our industry. We started out 30 years ago doing personal computing. Then everything went mobile. But now, given all the devices we share and the sensors we install, we live in an era of personal networking. This was going to be the “Internet of Things,” but it’s a little more like “the LAN of stuff.” Our experience of computing is a hybrid. For a long time it looked like the answer was, “Just use the cloud,” but…the cloud is expensive. My home security system doesn’t really need to log all video to Dropbox. Sometimes I forget to check code into GitHub and just want to log into my home machine and grab a file.

Managing our LANs of stuff

The world of software is evolving to help us deal with our LANs of stuff. One interesting company (which recently raised $100 million) is called Tailscale. Tailscale makes a VPN product. It lets you use your Google account to link lots of devices together, so, for example, you can connect to your home computer from your phone while on the train. VPNs have been around for a long time, but they’re always a bit of a chore. If you ran one at home, sometimes it would disappear for various reasons (cat stepping on surge protector).

Tailscale is easy in the same way that Dropbox was easy. And it has changed the way I work: All my little hobby projects are at home on my local machine; I don’t need a cloud server in the middle. Sure, I still check code into GitHub for safekeeping. I also got rid of Dropbox and use a tool called Syncthing instead, which keeps all my files linked up between my home and work laptops. Photos and email are still inside of Google.

Is that the way we’re headed? Your cheap, chatty devices will all talk to each other via a mesh. They’ll control each other. They’ll update each other. Peer-to-peer stuff. Or will we have more and more centralized software — so that Apple pushes out all the updates not just to your Mac or iPhone, but to all the devices in your phone? Centralized stuff.

A third alternative: your web browser. Perhaps because of the decades we spent waiting for legacy versions of Internet Explorer to finally be cast aside by IT administrators, modern browsers have been religious about self-updating and have ridiculously high version numbers. Occasionally a browser will need to restart, but it’ll only take a moment. Since browsers are now 3D-engine-having, virtual-machine-powered, pseudo operating systems, running things inside a browser means that updates are fast and cheap and don’t require restarts. What’s valuable is orchestration — the ability to access all this stuff wherever you are.

Get me to my TV

What does all this mean to people like us, the ones who make software? Well, ask yourself: What do users want? They don’t care about Netflix or Hulu or HBO Max. Those are just friction before they can get to “TV.” If you could log into your TV and use it anywhere (and why not? It’s just a computer! Why can’t I access my TV through Tailscale?) that would be…cool. It’s weird, because the idea of a TV seems old-fashioned in an age of streaming. But when I think about TV, I still think about the slab of pixels in the other room. Old habits die hard. Same with your Sonos. Why am I accessing music one way to play it on the Sonos and one way at work on my headphones?

All these different interfaces, modalities, and platforms, all the companies and approaches to accessing the same stuff (video, pictures, e-books, email, music), the idea that things work one way at home, one way on mobile, one way on the web, and one way on desktop — they are all a drag on the user. No one cares about your software, or your cool e-reader platform, or your brand. They care about their data, their access to that data, and their experience. And they’re starting to drop Netflix because they don’t care as much about its data or experience.

Fair. The fact that I have to remember that What We Do in the Shadows is on Hulu and Peacemaker is on HBO Max is ridiculous. All these updates are slowing down my fun as well as my son’s. We’ve organized everything wrong, again. All of our stuff revolves around operating systems, brands, and platforms. But those things should be organized around our stuff, at the protocol, OS, update, interface, UX, search, and data level — whether it’s on a home NAS drive, cloud service, or website.

What people want are fast devices that chat with each other just enough so that they can watch their movie or read their book. They want systems that update themselves quietly and don’t reboot. It’s all very blurry right now, which makes it fun to think through.

Paul Ford (he/him) is the Co-Founder of Postlight. Reach out at hello@postlight.com or follow him on Twitter.

When we think about software, what we imagine is based on our own user experience, consisting of the interface, buttons, and words that we can interact with. Meanwhile, we are all aware that the interface is merely the tip of the iceberg beneath which lives the magic between our devices, applications, and internet connections that make the interface function. Often, a key part of that experience is one or more application programming interfaces, more commonly called APIs.

An API, in short, is a bridge between different software systems to help them talk to each other and exchange information. Most of the software I’d product managed in the past was built with a focus on end users — human end users I could talk to in order to determine whether the software was working. Recently, however, I began managing the delivery of an API — a product that works between machines rather than people. I had to ask myself: What’s the best way to assess needs and functionality and judge success for something you cannot talk to? Here’s my advice on the particular set of challenges of API management.

What is an API?

I think of an API as a waiter at a restaurant. The person waiting on your table does the job of communicating between you, a person visiting the restaurant, and the people in the kitchen to make sure your order is prepared and delivered correctly. 

It goes without saying that when you visit a restaurant, you probably want only one entrée, not the entire menu. The kitchen, meanwhile, has the ingredients to prepare a much larger number of set dishes. Part of the server’s job is to broker that interaction. First of all, they prevent you from making errors. If you try to order something that’s not on the menu, then they will correct you and ask you to try again, reiterating what is available. Similarly, when the kitchen prepares your meal, the server makes sure that it is actually what you ordered. If you order the pasta and the kitchen makes you a burger, the server will send it back to them before it hits your table. The bridge and the gatekeeper between those worlds make those interactions possible.

And so it is with APIs between systems. One system needs to send a request over to the second system. The job of the API is to make sure that those systems play nicely together then and will continue to do so for years to come.

Define your characters

An important step in managing an API is collecting requirements from the key users and systems you are serving. Some APIs form a bridge between two systems, and others are built to open one particular system to many.

Consider building a table mapping out that system of user stories to include the full context of needs and capabilities. Think of them as separate characters with their stories. Collect the jobs to be done and the context for each system and user:

For each of these five characters, list out:

• Jobs to be done: What do they need to accomplish in this interaction? What are their goals?
• Capabilities: What can they actually do?
• Constraints: In what ways are they limited in serving other parts of the system?
• Upcoming changes: How will needs for these systems evolve over time?
• For the systems: What are the possible endpoints that the API can connect to? Should any new ones be created? Is one system writing information to another only, or are the changes bi-directional?

The results of this exercise will be different for every set of systems that you build for, and it is important to build a full picture including the intent and context of user interactions. This will set you up to understand where the API sits within the system and what it needs to accomplish. 

Prioritize the build

Just as with other products, once you have the needs and functionality mapped out for your API product, it is important to prioritize the order of your build. 

To do this, look at your systems map and find the endpoints and functionalities with the highest risk. This means finding the parts of the API product where, when not working as expected, cause all other parts of the experience to come to a stop. This could be the payment function (critical failure), an inability to sign in (oops), or another pivotal point which causes dysfunction on either side of the API.

You may also want to prioritize areas with the most uncertainty. When integrating multiple systems, engineers often discover attributes of solo systems they wouldn’t have noticed otherwise. Do your best to expose that uncertainty early. When asking your engineers for their level of familiarity with the systems that they’re building for, you can use the 80/20 certainty method: Ask them if they are 80% certain that the connection will work or if they are 20% certain. This leaves space to uncover areas that may require further learning, so you can prioritize those risks to delivery up front.

Get testing

It is important to have a way to check that endpoint connections are working as expected. Whether you are using a well-established tool like Postman or you have another in-house method to run test API calls and see their responses, be very clear about your methods for testing every endpoint and allow time in the project to do this work. This is essentially your replacement for human user interviews where you can ask, “Is this working for you?”

Document every decision

Documentation is critical to maintain a healthy API. Developers building into your API need to be able to clearly read how they can interact with it, and there are so many APIs out there with endpoints of mystery floating around. Document every single decision that was made and how it related to the health and capabilities of each system. Do yourself this favor both for other people and for yourself in the future.

\n

\n \n

\n

\n

\n

\n

\n \n

\n\n

\n

Write the story of the system

If you are a Product Manager who’s found yourself in charge of an API, remember that systems themselves are like characters with their own needs, capabilities, and constraints. Write the story of those specific “system personalities” and get to know them. Define what correct functionality looks like and work with your engineer to map out points of highest risk. Build system tests to ensure that each of those risks has been addressed, that functionality has been validated, and that minimum functionality is in place even under less than ideal circumstances.

It’s a lot of work, but once it’s completed, you will make the unseen appreciated by adding functionality to multiple applications that were never built to be friends, adding value to every system.

Sarah Cassidy (she/her) is a Senior Product Manager at Postlight. Interested in working on your product? Get in touch.

Work for Postlight! Love making exceptional digital products? We’re hiring engineers, PMs, designers, and strategists. Let’s grow together. See openings.

Our Mission and Values

The Postlight Charter

ON THIS PAGE:
Who We Are Our Mission Our Values

Who We Are

Postlight is a premium, full-service digital partner specializing in product strategy, design, and engineering. We build beautiful, enterprise-scale platforms that drive business outcomes for our clients.

Our Mission

To create great digital experiences with our clients that drive positive change for their businesses and the people they impact.

We aspire to:

Our Values

Part 1: For Ourselves

To create great digital experiences with our clients that drive positive change for their businesses and the people they impact.

We love our work for the challenges it brings and the change it creates.
Share your love of your discipline and the things you learn. Be mindful that what you build will impact people and the world around us.

We share the responsibility of creating a respectful and inclusive environment.

Part 2: For Our Clients

Part 3: For The World

Finally…

These values are aspirational. Use them as a framework for improving Postlight.

If you see our actions don’t match these values, speak up. Use these values as a framework for discussing how Postlight can improve, and how to implement changes.

This document was created through a many-month, collaborative process. The language about inclusivity is copied from VOX Media’s inclusion and diversity statement (adapted a little). We expect to return to it every year, to discuss and adapt it.

Updated April 13, 2022