Jonas Downey is the design lead at Basecamp. In this interview we discuss the ethics of designing and building constraints into your product that change human behavior.
Jonas Downey is the design lead at Basecamp. In this interview we discuss the ethics of designing and building constraints into your product that change human behavior.
Build a custom point of sale that connects to Square Terminal, an all-in-one credit card device built by Square for contactless and card payments.
Start building with Square Terminal API by visiting https://developertea.com/square today!
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com/contact.
If you would like to join the new experimental DIscord group, reach out at developertea.com/contact, developertea@gmail.com, or @developertea on Twitter.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
What happens when you have the audacity to redesign, rethink something as big and as commonly used as email? In today's episode, we talk with Jonas Downey. Jonas is the design lead at Basecamp. He's also the co-creator of the Hello Weather app. He's currently working on Hay. And I'm very excited to talk to Jonas, not only because of the kind of scale of the projects that he works on, but also because Basecamp has a unique approach to almost everything that they do. And in many ways, the approach that Basecamp takes is probably not one that you would find in a classical kind of business. Most of what they do, they have run through a lens of philosophy and opinion. And I find that incredibly inspiring and challenging. So I'm really excited to get into this interview. We've been doing a series on what it's going to be like post-pandemic. And we're going to pick that series up after this interview with Jonas next week. We will pick that back up and we'll continue. We'll continue talking about life as an engineer after the pandemic is relieving. And I'm excited to pick that series back up. But today, let's get into this interview with Jonas Downey. How do you build a product that's good for both the business that you're running and the user? Do we always have to trade off value from one to the other? That's one of the things that I talk about. But today's guest, Jonas Downey, Jonas is a design lead at Basecamp. And spoiler alert, no, no, you don't have to trade off and give away value to add value to the user. So it's exciting to talk with Jonas in this episode. And hopefully you will get a little bit of inspiration and hopefully some conviction out of this interview. It is a two-part interview. So make sure you subscribe if you want to miss out on the second part. Let's get straight into the interview with Jonas Downey. Jonas, welcome to the show. Thank you. Thanks for having me. People who are listening to this know about Basecamp. And I'm sure that they have probably seen some of your work. But I'd love for you, assume that somebody who's listening to this has no idea who Basecamp is, what they do, what you do. Can you kind of give like a two-minute introduction? Sure. Yeah. Basecamp is a software. It's a product company. We've been around, I think about 20 years now. And over the years, we've made lots of different products. Our most famous product is the one called Basecamp. So our company is named after the product. And it's generally known as a project management tool, but it's kind of not a fair description of it. It's really a communications tool for small businesses and teams to get work done and to keep in touch with each other, keep track of everything, stay on the same page. Within that, there's chat. There's chat and to-dos and things like that. So that's Basecamp. And then we recently launched a brand new product called Hey, which is an email service. So it competes with things like Gmail or Yahoo. You can sign up for a hey.com email address. And it's a sort of reinvention of email. We took a look at email and basically blew it up and came up with a bunch of new ideas and distilled all that into this new product. So I think that's the summary. Yeah. So Basecamp seems to take on all of the projects. There's a lot of projects that when you first start being, you know, a lot of people listening right now, they become a software engineer and they're like, oh, I'm going to build a productivity app. And there's kind of this kind of meme culture around the idea that, oh, yeah, of course, your first app is going to be a to-do app, right? Right. But then Basecamp actually takes it the next step and they're like, no, we're going to actually build this thing and do the whole, you know, start in these really, really hairy, difficult problems like email and productivity and project management, all of the things that, you know. Are hard to tackle because there's so, first of all, so many competitors in space. But secondly, there's so much kind of religiosity around how to do these things. And I've always seen Basecamp as someone or someone. There's a big personality that Basecamp has of taking on these hard problems, having opinions about them and sometimes having, I won't say countercultural because it's really a buzzy term, but having opinions that other people are quick. Right. Quick to criticize. So I'm curious if you have that same perception of Basecamp in kind of the super culture. Yeah, I think that's right. Definitely our products swim in heavily populated spaces. There's lots of competing products and lots of ways to get work done. There's lots of ways to send email. Those things aren't novel. But what is novel is our approach to how we run our business and how we think of this software and how it fits into people's lives. That's really the way that I think Basecamp. Yeah. Contrast against most of the other companies building tools in these spaces. So we are very opinionated about running a company that's profitable and small and respectful of our employees time. And we build the products that we use to run our company. So the products have those same principles and that ethos built into them as just the fundamental of how we approach work and communication and time. We thought a lot about those. Things over two decades. And so when you use any of our products, you're going to get the kind of distilled version of how we translate those opinions into tools. Yeah. It seems that I've always kind of thought this way about Basecamp. It's a philosophy company that happens to have products that they work on. That's a good way to think of it. Yes. So I have one more question for you because I always, you know, a lot of these tools, they have a way, you know, capital W way. And I think that's a good way to think about it. What seems to be, you know, a good, and we'll get into ethics a little bit later in our conversation, but what seems to be like a good way to do things, right? You think about the products that try to do, be all things to all people and they end up kind of failing because there's no prescribed kind of, what would you call it? Happy path or well-trodden pathway. A way of doing things is not enough of opinion. So do you think that's a good way to think about it? I think that, where do you think, you know, the average Basecamp product falls on that spectrum of trying to be so flexible that you can bring any process, you know, any of your opinions are all welcome here versus having an extreme, you know, very strict working pathways for, you know, for example, for project management, are there these best practices that are built in, baked into the products all the way? Right. I think it's a, it's a nuanced answer. Basically the way I think of it is we, there are some things that we are against fundamentally that we just won't do in our products. So certain things like a very common thing that people ask for, for years and years in Basecamp is like a Gantt chart. It's like a common way that people do project management. But we sort of have opinions about the way that projects get created and the way they get communicated about. We didn't find a Gantt chart to be the way that we wanted to approach this problem. So it's a thing like we're not going to put in. Whereas another company that's less opinionated might get customer requests for Gantt charts and say, sure, yeah, we'll, we'll add Gantt charts. That's great. So we really go into it from a holistic perspective and think about the totality of the problems we're trying to solve. And then we make decisions based on what we think is best for our customers and for us. And that may not fit everyone. We do make the tools to be generalized enough that like you can show up to Basecamp with any number of different processes and it probably will work for you. But if you do have certain specific requirements, like you have a rigid project management process and you need X, Y, and Z features to accomplish that, Basecamp might not work for that because we don't, you know, we don't try to run the gamut of every possible thing. The idea is really we give you the right tools, just enough tools while keeping the product overall simple enough that you can invite 200 people to it. And like, you know, we don't have to do that. People pretty much know what to do. They don't have to learn the ins and outs of detailed project management, become certified and learn all this stuff. So we try to kind of be in that middle space where it's friendly and simple and respectful, but not so, you know, bloated or full of specific features that we've gone over the top with it. Yeah. Yeah. So it's interesting you mentioned Gantt charts because, you know, I have my reasons why I never want to see another one again in my life. I'm sure other people do too. But. There may be somebody who's listening right now. You know, what's wrong with Gantt chart? Why did you decide that Gantt charts are, you know, against the user's best interest? And I'm curious, you know, those kinds of decisions. And we can use that one as the working example. But how do you arrive at that? You know, how do you how have you developed those kind of blacklisted items or block listed items that you're unwilling to maybe not unwilling, but. That won't make it into a product because you think it's not good for the user. Some of it. Gantt charts are kind of a weird example. But one issue with like a Gantt chart is it sort of communicates a degree of certainty about a project schedule. So if someone fills out a Gantt chart and they have a bunch of dependencies of like time blocks that are going to happen, you know, one after another within, let's say, like a six week block of time that you have to complete a project, you're sort of blocking out the time. You think something is going to take and then you can refer to this chart as a way to say, like, where are we? None of that is necessarily bad. Like those are OK things to do. But we don't want to promote that way of working in Basecamp because we don't believe that projects have that kind of certainty and we don't want to really put information in that format. It's not that we don't want to provide tooling that accomplishes some of the same goals, but we want to do it in our own way and we want to not fall back on like a preexisting solution that people are just used to rather than thinking through that problem from scratch and saying, like, how else can we do this in a way that's better suited to what we believe in? Yeah, it's interesting. You know, when I hear you talking about this, I'm reminded of for a very short period in my college career, I actually was pursuing a degree in journalism. I realized pretty quickly that I didn't want to do that. But this feels a lot like the ethics that a journalist might approach their work with. Because, you know, for example, data visualization. Data visualization is not a totally transparent picture of the data. It's always going to present a picture that is somewhat skewed. There's no way to remove all of the bias out of it. Even the choice of different colors can certainly communicate a lot to the viewer. But of course, we've all seen those, you know, different types of data. There's data that are presented, you know, two charts that look like totally different things, but actually it's the same exact data that it's representing because you can skew them. And this reminds me quite a bit of that because this idea of saying, okay, you know, we're not going to do that because we don't believe that presenting information in that particular way is effective. It's actually, it could harm your team. It could harm you as our customer. It might give you a false sense of security. You know, are those the kind of conversations that you're having? When you're considering different feature sets or requests from the end users? Yeah, absolutely. We actively avoid using lots of common design patterns and things that we just fundamentally disagree with. Another example of that is in our new email app. We don't show counts of emails anywhere, which is like a thing that if you use email apps, you may have subliminally just absorbed and not even really realize what's going on. But if you use Gmail, and you look at the boxes in Gmail, all of them tell you how many emails are in each box. And the numbers tend to be ridiculous. Like you might have, my wife has like 13,000 unread emails. And most people are used to that because that's how most email apps are designed. And it's sort of taken for granted that like, if you have email, you know how many unread messages you have. We took a look from the beginning and said, okay, what is it about email that we want to solve and what don't we want to solve? And we think something like that, an unread count. Is actually an anti-pattern that's bad for people because it gives you a feeling of remorse and guilt and obligation to have to deal with this like pile of stuff. When in fact, the pile of stuff actually in terms of your life probably isn't that important really. So we, we question everything. We don't just like automatically assume that like these questions have been asked before and that the existing answers are the right answers. We go into it cold and say, well, what really do we want? And. How do we build an app that respects our time and treats us as humans and doesn't try to use little, even small details like that to get people to take actions that we don't think are necessary. Yeah. Yeah. So it is interesting because I can understand, you know, I'm imagining if I were to go into Gmail and remove all the numbers and that wouldn't be a sufficient change, right? Because I still need to understand my inbox. To some degree, but I can imagine the immediate craving for those numbers. Again, this feeling of, well, I don't know where all this information is. It reminds me of this, of another thing, actually, for my, for my college years, the different types of information. So sometimes you have encyclopedic information, which is what Gmail typically could be considered where you have this massive amount of information and it's navigable, but really the whole point is that you can see the entire information. You can see the entire thing, right? There's no selection process, no filtering, really. It's encyclopedic and it's your responsibility to dig through it in some way that is meaningful to you. But Gmail is kind of going to, you know, shovel that responsibility onto you and they'll tell you that you have a million unread emails, you know, good luck, right? Right. So there's this interesting feeling that not having those numbers would evoke, which is, ah. I have to be mindful about what I choose to read now. And I have to, it's not just a simple interface. It's not just, we don't like numbers because they stress us out. It's a totally different approach to that particular task, right? Right. Yeah. And you have to think of the problem holistically. So you could imagine you could take Gmail and delete the counts and say like, that's Gmail without counts. But it doesn't, that doesn't actually do anything. Really. You still, you basically have the same software. So what we like to do is think about, okay, this is a design pattern that people have used to indicate that there's like new things or a quantity of things. If you take that away, how do you design the rest of the system to like make up for that deficiency? Because now that is like a little bit of an information center. Like if you remember, oh, I used to have 12,000, now I have 12,010, you know, you have something new or whatever. If you don't have that anymore, now what do you do instead? How do you still make it clear when there are? Things happening in the system and which things do you choose to prioritize? Like how do you encourage people to look at the important information that they probably do need to see right away and shove everything else off to another place? So it's like, you can't look in a vacuum at any one detail, but some details kind of give you a leg into the idea that like, you know, I'm tired of being shamed by my email app telling me I have so many unread messages. How else could we do that? And then that opens up a whole new. Line of thinking. It's not just about that count then it's about like the holistic idea of the workflow of the system. We'll get back to our discussion with Jonas right after we talk about today's sponsor square. With square, you can build a custom point of sale that connects to square terminal. This is an all in one credit card device built by square for contactless and card payments. Square terminal. Square terminal. Square terminal. Square terminal. Square terminal. Square terminal. Square terminal. Square terminal. and a built-in thermal printer for safe and distanced payments. It's easy to disinfect. It's built to make payments easy and safe. Square Terminal syncs seamlessly with your app via the Square Terminal API to accept Apple Pay, Google Pay, and other NFC payment methods, plus mag stripe and chip cards for smooth checkout experience. Terminal API is compatible with basically every web and mobile platform, so it's easy to integrate your iOS, Android, Flutter, React Native, or your Windows applications. And Square has your back. You can build with the Terminal API and take advantage of Square's end-to-end encryption, dispute management, and fraud detection. Connect your app to the all-in-one payments device merchants love with the SimpleRest API. You can get started by heading over to developertea.com slash square. That's developertea.com slash square. Start building with Square. Share Terminal API today. Thanks again to Square for sponsoring today's episode of Developer Tea. Well, if I'm thinking about your job as a designer and my job as an engineer, it seems that the approach from the average engineer is to kind of zoom out and say, okay. I'm going to do this. Well, the designer is going to worry about the holistic approach, and I'm going to worry about the implementation approach and getting all the details in place. But there is some kind of inversion of that principle when the designer starts talking about the details, right? And when there's some collaboration. So I'm interested in what you think about kind of the realms of responsibility between these two roles. And also, you know, how are these two roles best going to work together as these lines blur? Assuming that the lines are blurring, what do you think about that? Yeah. Well, I think in general, I think designers specifically have a great deal of influence over human behavior. If you think about our daily lives and how often we are interacting with apps and websites and phones and cars and appliances, almost all of those experiences, well, at some point, are decided on by a designer and a team with engineers. So, we have a very, those go along with it. So design is really powerful because people will kind of just do what is directed most of the time without questioning it. And I personally don't think that design and engineering are separate disciplines. I think that they overlap in a great deal of ways. I think that engineers are almost as much designers as designers are designers. I think like if you're working on a system and you are deciding how it operates, what the function is, what something, what happens when someone does something and what the effects of that are, you are making decisions about the system's design. So at Basecamp, we are much more overlapped in terms of our job responsibilities than other companies. Our designers are all also programmers. We mostly do a lot of the front end development of the products we make. And then we work with a programmer to do more of the back end and more of the hard stuff. But our process is very collaborative. It's the designer and the programmer working together through the whole time throughout a project. The programmer can push back against a design idea. Designer will change the design. The designer can tell the programmer, no, we're not going to do it this way because that's not what we believe in. Programmer will change it. So we think that it's a two-way street. We don't think that like design stops and then you hand a design to a developer and then develop it. We don't think that it's a two-way street. We don't think that like design stops and then you hand a design to a developer and then develop it. We don't think that it's a two-way street. We don't think that it's a two-way street. We don't think that it's a two-way street. And then you have a product. That process is actually part of the reason you will find breakdowns in some of these issues, like breakdowns in thinking through the totality of the system, thinking through the ethics of the system, spotting ways in which it might be harmful before it ships. All those things. I think the more collaborative and together the designer and the developers are, the better you can do. Yeah, this is definitely endlessly interesting. Because it is the process of product development. Product development is a design exercise. It's kind of like the, oh, I don't know what the cultural reference is, but you are practicing a design exercise, whether you're choosing to do it or not. If you're developing a product, you're placing something in the pathway of human behavior. And despite all of the many different definitions of design, and that is certainly one of the most salient ones, which is we choose to make something in the world a little bit different. We're adjusting pixels. We're adjusting people's time when we adjust those pixels in some way. We're changing the course of their behavior. So it's definitely something worth thinking about. And I think one step further and something that we've already kind of discussed in advance of this episode is that because you have a lot of this opportunity to change behaviors, it's not just an opportunity. There is some level of responsibility. And you can choose to kind of view it as a responsibility or not. But there is some level of responsibility that you have to other people if you're going to be an ethical designer. And I want to get into that. Before we go down that path, I do want to ask you a question that I typically save for the end of the episode, which is what do you wish more people would ask you about? Hmm. That's an interesting question. I think one thing that doesn't get talked about very often that could be, especially around this topic of ethics and respect and product design, is how caring about those issues can actually also be positive for your business. I think that one of the reasons that everyone feels very defeated about these problems is that they're not going to be able to do what they want to do. And I think that's one of the reasons that a lot of the tech companies now are focused so much around performance that like, OK, yeah, we'd like to do things that are that are better for our customers or whatever, but we also have to show profit and growth and all these things. And that always wins. Basically, the capitalism beats ethics. And what we've been trying to prove with, hey, I mean, not directly, but I think what we did kind of prove was that you can make these decisions, make ethical decisions and build a respectful product that is also a financial success and also becomes popular in its own right. And that's the thing that I think people still don't necessarily believe. They're like, oh, well, if I don't do, if I don't juice my conversion and all of this stuff to the absolute most degree, we can't make a business out of it. And I don't think that has to be the case. So I think that's an aspect that people should dig into more. There is some sense of a zero, you know, what if people are listening, you haven't ever had this term zero sum. The idea is that, you know, there are certain things in the world in the universe that are zero sum, right? The conservation of energy is an example of this where we can't add new energy to a system. There's only so much available. Right. We learned this in kind of like seventh grade physical science or something. That's not always true, but we often apply that same model to all systems. So as a simple example of this, you know, one version of this might be, well, if you're not going to give that person money, then another person is going to get the money. Right. That's not necessarily true. And also if you spend, you have a hundred dollars to spend, you can either spend 50 in one place and 50 in another or a hundred in one place and zero in the other. Well, actually there's a lot more you could do with that money, right? You could invest that money and turn it into $200. This is where the idea of zero sum comes from because the concept is just to equalize those two amounts, right? Or to not be able to change whatever that fundamental building block is in the system. And I think what you're pointing out here is exactly that. It's the false dichotomy between designing mindful systems and designing, you know, economically profitable systems. Those can be coexistent. Right. Yeah. And some, some of it depends on where you start. So if you think about, if you compare like Gmail to pay, let's say as two examples, um, they, they start from different angles. Gmail has a business model that's built around advertising. Um, so the business incentive for Google with Gmail is to have people using a Google product and looking at it. As much as possible so that they can see ads so that they get revenue from ads and they can do any number of things around that to make that experience more mindful and more respectful, respectful, but fundamentally that's the case. Like that's the root of where they started versus with, Hey, our route was to build an email app that preserved your time and respected your attention and took care of you. And that hopefully became a business. Like that was our. Um, and so that's, that's the, that's the, that's the, that's the way of thinking about it, which are just two totally different ways of coming at that problem. Right. So in, Hey, we got to do a lot of things that Google would probably be disincentivized, uh, in doing, because it wouldn't benefit them, um, in the way that it might benefit us. Um, so there is a little bit of a trick there where depending on which way you come at a problem, the amount of movement you can make in one direction or another can be constrained. Um, but with that said though, you're right. You can make a lot of things and we all get to make choices. So as designers and developers, we have a lot of authority. We might not think we have a lot of authority, but we do, and we can choose if we want to build something that's sticky and attention grabbing, or if we want to not do that, but we don't think it's right. Um, even within any of those contracts, or even if you work at like a company that's built on advertising money, that's fine. Um, there are ways that you can do that. That are better or worse. So you always have to kind of weigh this. Yeah. Try to promote the things that you believe in and come at it from a principled perspective. Yeah. That's so that's a very interesting, uh, it brings up an interesting question, which is okay, you know, is it okay for me? And I don't know that you can be the answer, the person that answers this for everybody. I think everybody has to kind of answer this for themselves. Um, but the thought experiment is, is it okay for me to do something solely for the money? Uh, and, and is that a. An ethical pursuit or not. And I don't think that the answer is as simple as we hope it is. Um, but, but it is an interesting question. Is it okay to do something that is purely for financial gain? And I, you know, I think the logical, um, uh, walkthrough of this would lead us to say, well, if you didn't make money at your job, you probably wouldn't be there. Right. So there is, there is some point at which everybody says, okay, I will not do that. Unless there is money involved. So how do we parse through that? I, I'm not sure that there's an answer, but I think it's worth talking about, you know, how do you parse through, uh, those competing incentives? We say, okay, well, I've, I've got this stressor to do something that, uh, I otherwise wouldn't do where it not for the money. Right. Part of the problem is that right now, the way our industry is set up, we are essentially deflecting. Right. Right. That decision onto the employees at the end of the chain who are doing implementation work and saying, you know, uh, you came out of college and you needed to get a job and, um, your family doesn't have a lot of money and you need to be self-sufficient and you managed to land a job at Facebook and now you're being well taken care of and you have a well-paying salary and you crawled out of a difficult place in order to be successful. And we should be able to celebrate that. Like that's wonderful. Um, at the same time though, you are now, you're now working for a company that does a lot of manipulative and harmful things globally to a very large audience. And so squaring that is a really difficult thing to do. Um, and I think the answer can't be that, um, the individuals at a company are the, the way to do the protesting. So if, if, you know, Facebook employs 30,000 people or whatever, you can't realistically expect that those people are all going to just walk out because they have children. They're feeding. And they have concerns that are beyond, um, maybe their ethical preferences. Certainly some of them who have the capability and can leave in protest or whatever, fine. Um, but that's not really fair, I think. So the, the thing we need more in the industry is one, some regulation around what's okay and what's not okay at a high level. Um, and I think two, something more like, um, the code of ethics that like the medical profession has, which is like, if you're a practicing doctor, and you do something really horrific to your patients, they don't allow you to continue to be a practicing doctor, but you're out. Like that's not a thing that's allowed anymore. Um, and we, we have almost as much influence on people as doctors, um, as the people who make these systems. So I think that to me is what's missing is we don't, we don't have some sort of overarching understanding of like where the boundaries are. And we're leaving it up to every individual to be able to like grapple with those decisions alone. Right. Right. More or less individually. And it's tough. The individual people working is what you're saying. Yes. Right. Yeah. Like individual employees at companies. Yes. Yeah. Yeah. It's kind of the, it's kind of an interesting thing because, you know, you could probably poll the individual workers about how they feel about these various things. And some of them would, uh, you'd have a full spectrum of answers. It wouldn't be, you know, I think it's, it's kind of like the, uh, the wrong mindset of thinking, oh, you know, um, as an example. Right. Right.. Right. war not all of those soldiers equally believe uh the same things that that they're fighting for right for some of them it's just this is they're they're they were 18 when they joined the military as a job and now they're fighting in a war that they don't even maybe they don't even understand uh why they're fighting that particular war and i think that's there there's some kind of economic um megaforce you know nobody is actually uh radicalizing all of facebook's employees right i don't think that that's even economically important to facebook to make everybody at facebook believe that what they're doing is good uh i think instead it's it's about money and right it is an interesting problem and i don't know that like you say i i'm pretty sure that it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's that the individuals can't really hold all of the responsibility here because well what are they going to do not have a job right like i have to feed my children even if it makes the world burn down to some degree and you know there are there's a lot of balancing to do yeah there's an easy answer right the the tough part of it too is that um that argument can also be used as a cop-out by the people who are doing that work right so it's a very common excuse if you talk to developers or designers they say well we don't have any power um we just you know the people at the top of the company make decisions about what we're doing and we execute those decisions and like that's our job so like what do you expect us to do right and that to me is a hollow defense because it's basically admitting you're complicit and refusing to take any degree of responsibility for what you're doing um and so i i think there has to be a balance there you know someone who is working at facebook right now and cares deeply about a lot of the stuff that they're doing a lot of these issues and is trying to do their best to to make the company move in the direction they believe is right i think like you know you're doing what you can and what works for you right now um but but that defense that designers and programmers aren't you know authoritative is wrong i think they are because none of this stuff can get built without us right we we are a line of defense we may not be the top line of defense but we absolutely are critical to the operation and um if enough people speak out and stand up against things like that then we're going to be like it will stop so i think uh there's a balance there you know i don't think it's fair to put all the ethical concerns on the individuals who work these companies but there's also some amount of it that you do own yeah it's like a collective action problem very similar to you know taking care of our planet right we can't say oh well me recycling this bottle is going to do nothing uh in the in the grand scheme of things so i'm just going to throw it away because it's easier for me right it's convenient it's convenient it's convenient it's convenient it's convenient it's convenient to not have to deal with recycling and pay for it and all that but there is a collective action problem there right when we all do that same thing it's the tragedy of the commons when we all choose to go the easy path and we all suffer um from that collective inaction right well i'm interested so i want to stick on this for a little bit longer because it's something that we rarely talk about on this show but it's incredibly important and relevant to our lives right now i i you know i i wonder if so there's this this kind of um maybe a narrative or different narratives about how we got here um i i it's hard for me to imagine that there was a person um who started a company uh and called it facebook and their grand plan was to start meddling in democracies at some point you know i don't think that that's uh that that was the initial intent um of this of this venture and somewhere along the way despite that not being the initial intent something like that has happened right or at the very least some very serious manipulation as a result of advertising that certainly has occurred so how did it happen right that that's um you know how did it happen and the reason i asked the question is as we build these new products there will be another one right there will be another product that comes along that has the same level of or more uh certainly as we as our products gain more complexity and fidelity we're gonna have even more uh leverage over people's behaviors so you know where do we uh insert ourselves as designers and developers uh and product managers and and developers and and and and and and and and and and and and and and and and and and people managers how do we figure out how to not cross that line yeah well i think if you if you walk back the histories of companies like facebook or twitter um the problem is not that they set out to take over the world and meddle in democracy it was that they didn't set out to do that and then ended up there anyway i think the naivete of how those platforms started versus where they grew and what they became is the problem that like you know if you go back and look at what twitter was like 15 years ago when it started um it was a joke i mean like it really was like people were on there just goofing around posting you know stuff about their dog or whatever it wasn't serious like it was meant to be kind of just a a place to play around and then obviously within the last four years it became like the bully pulpit for the u.s president and they've grappled with any number of ways they had to censor him and all these things so it turned into a platform that was not what they originally designed the original designers who thought of twitter did not think of that they did not imagine 15 years in the future that it could be used in this way and if you are a person who is building a new product or a new platform and you're thinking about doing you know a communication system that's kind of the reality you're facing now you need to think of those effects on day one they're like okay hopefully this thing will grow we don't know if it will if it did what would happen like do we have a way to content do we know what we'll do like how will we grow this and is it okay and have we designed it up front to protect people who are vulnerable who are going to be using this to communicate because if you don't think about that in the beginning it's very hard to graft on protections after you've already built something so that's the problem that twitter and facebook find themselves in they have an existing system it has all these rules it already has all these constraints and decisions in it and you can't walk those back because that's that's what they have so all they can do is sort of like bump it a little bit in one direction or another but it's not enough like it's not enough to really fix the the root problems that came out of it thankfully now we've learned that and like if someone sets out to make facebook 2 or whatever maybe they would take all that into account and build something that's healthier but they're very difficult problems and they're new problems that we only arrived at in retrospect thanks so much for listening to today's episode of developer t the first part of my interview with jonas downey if you enjoyed this episode i encourage you to subscribe so you don't miss out on the second part thanks again to square for sponsoring today's episode head over to developer t.com slash square to get started with the square terminal api today another reminder that we have a discord we have a community discord that is invite based but anybody can join all you have to do is reach out to me on twitter or via email on twitter at developer t and via email developer t at gmail.com thanks so much for listening to this episode of developer t and until next time enjoy your tea