The team talks with Expensify CEO David Barrett about how computer graphics and video games inspired his career, how Expensify built their stack, and why this CEO still takes his turn on PagerDuty.
Expensify is an expense management solution that integrates with your travel, ERP, and finance/accounting software. Check out their full list of integrations.
Expensify engineers rely on Stack Overflow for Teams to make knowledge accessible and shareable, rather than wading through swathes of documentation. Read the case study.
Flat organizations like Expensify have minimal or no middle management, meaning there’s no management layer between staff and executives. A similar model for decentralized management is Holacracy.
Find David Barrett on LinkedIn here.
David Barrett And in the process of trying to build essentially this private label food stamps card I learned a ton about payments, which I didn't know anything about in the past, and kind of invented this company that became Expensify. And so I'd say it definitely seems like a meandering path from the outside, but there was a strong technology similarity between everything we do. Even at Expensify the very first thing that I built, which sounds crazy, was this custom blockchain replicated database, which sounds wild, but it had a reason behind it. It solves an actual purpose. And the reason I could do that was because I happened to have spent a bunch of time doing distributed programming for this peer-to-peer content distribution startup. And the reason I did that was because I had to do firewall punching in P2P for my video conferencing thing. And the reason I did that was because I happened to be traveling. So there is a method to that madness, if you will. But like most things, the path is only clear in the rear view mirror.
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am Ben Popper, Director of Content here at Stack Overflow. And I'm joined today, as I often am, by my wonderful co-hosts Cassidy and Ceora. Hi, y'all.
Cassidy Williams Hello!
Ceora Ford Hello!
BP Today we have a great guest, David Barrett, who's the CEO over at Expensify. I get his emails. They are lengthy, they are passionate, and they engage with a lot of topics related to both business and technology. So after getting them for a while I responded to one, I think it was one when maybe the company went public, saying, "There's a lot of ideas in here that I feel like are things we discuss on the podcast, we'd love to have you on the show." And he agreed to come on which was very gracious of him. So we're going to chat a little bit today about how he got into software and technology, how Expensify is built, sort of the tech stack that it runs on and why they made those decisions, and then talk a little bit about where software and technology is headed and some of the things David is passionate about in terms of using those tools to change the world. Alright so David Barrett, welcome to the Stack Overflow Podcast.
DB Well thanks for having me!
BP I will kick things off and then I'll pass the hat. We often ask people not to date themselves necessarily, but tell us a little bit about how you got into programming. What was it that drew you to this field and got you started?
DB Sure. I mean it was interesting. So when I started, I lived in the countryside and didn't have any friends that knew anything [about programming]. I didn't know until college a single person who'd done any programming whatsoever. And so I just started programming when I was six, computer graphics and video games were my jam, but middle school and high school I wrote 3D graphics engines back when people did that kind of thing, at The University of Michigan and worked in the virtual reality lab. After that, I went to the game industry down in Texas and I wrote 3D graphics engines for a motorcycle racing simulation.
CF Ooh.
DB Yeah, it was pretty cool. But then I realized that even I didn't feel like I had the time to play my own game and it made me really reflect, like, "Who is this for? If I don't think my game is worth my own time, whose time am I wasting, and do I feel good about that?" And so I kind of got out of game development at that. I got into Push-To-Talk, video conferencing, Voice over IP, screen sharing, peer-to-peer content distribution. And now, it's an unlikely background for the expense report magnate that I've become, but obviously, expense managements, payments, chat functionality, and then the next thousand years of vision beyond that.
CF That's very interesting. I'm wondering about going from game development to eventually doing a business like Expensify seems like a pretty big jump. What was that process like for you?
DB Well actually, everything is easier than game development. Game development is harder than everything else, because it is the most advanced of everything. It has the most advanced AI in the market, the best graphics, the best sound engineering, it's the most reliable, everything about it is absolutely bleeding edge. And so if you can do game development, everything else is a step down from there.
BP And the most demanding consumers, obviously.
DB Absolutely. Yeah, absolutely. And so I would say I love games because it's super fun, it's visual, it's a lot of instant gratification, so forth. But fundamentally the product that you're selling is just wasted time. And I think that you can add more of a social component to it, maybe find some justification there, but it just didn't feel satisfying to do it. And so I took the same background, of high performance engineering, and then my dream was basically, I had one of the very first laptops that had a webcam. This is my favorite laptop I've ever owned, it's called the Sony PictureBook. It's basically just a keyboard with a small screen on it. This is like early-2000's sort of thing. And I was traveling around the world with this and it had this webcam on the top. I'm like, "Damn. I feel like every laptop is going to have a webcam soon. This is going to be cool. And wouldn't it be great if you could just, like Thailand or Croatia or things like this, and wouldn't it be cool if you could just work from anywhere?" This is before digital nomad, WiFi was still spotty, things like that. And so I'm like, "Oh, you know, I could just build a video conferencing tool that uses push-to-chat style conferencing." And then video conferencing is actually insane, it's like computer graphics, it's like video games. The latencies are very, very difficult. There's a lot of challenging sound engineering, things like this. And so that put me into more of a peer-to-peer programming background where I had to punch through firewalls and things like this. And then from there, I got recruited into a company called Red Swoosh, which did peer-to-peer content distribution. So it's like BitTorrent for legitimate content. So smaller user base, but at least you don't get sued into oblivion either. And so we had a very small exit, and I was living in San Francisco in the Tenderloin and I was basically seeing my same houseless neighbors in the street every day, thinking like, "Look, I mean, it's easy to get paralyzed when you think about global issues." It's like, "I can't solve hunger globally. I can't solve hunger in this city. It's beyond my means, but I have the resources to ensure the people on my street have a hot meal every day. That's within my power, but it's just super inconvenient to do." And so I'm like, "Well, what could I do to make this more convenient?" And so I came up with the idea of essentially like a private label food stamps card that I would just give out to people on the streets and say like, "Hey, if you look like you need a free lunch, use this, and this card will work up to $10 a day, only once a day, and only at restaurants that don't serve alcohol.” And so that was my initial idea while I was just kind of vesting up my golden handcuffs after selling this last startup. And that'd be fun, whatever. And in the process of trying to build essentially this private label food stamps card, I learned a ton about payments, which I didn't know anything about in the past. And we kind of invented this company that became Expensify. And so I'd say it definitely seems like a meandering path from the outside, but there is a strong sort of technology similarity between everything we do. Even at Expensify the very first thing that I built, which sounds crazy, was this custom blockchain replicated database, which sounds wild, but it had a reason behind it. It solved an actual purpose. And the reason I could do that was because I happened to have spent a bunch of time doing distributed programming for this peer-to-peer content distribution startup. And the reason I did that was because I had to do firewall punching in P2P for my video conferencing thing. And the reason I did that was because I have to be traveling. So there is a method to that madness, if you will. But like most things, the path is only clear in the rear view mirror. It seems pretty murky as you move forward.
CF I love the way everything tied together to get you where you are now. That's really cool.
CW Yeah, I also appreciate that you went through some of the most challenging programming problems and industries that you can to get to where you are today.
DB: I mean, I think that payments is interesting because it's high stakes stuff. We process billions of real dollars. And so the security is intense and the availability requirements are super high. And so I'd say I love technology, technology is super fun and interesting, but fundamentally I like solving problems more. And I think that people too often get distracted by the latest whizzbang technology as if the technology itself matters, but the technology only matters as much as the problem it's solving. And I think people choose boring problems and then solve them with fancy technologies and they accomplish nothing. Or rather, maybe they feel good. It's like a hobbyist. It's like, "I didn't solve anything, but I felt good doing it." That's cool. I'm not a hobbyist. I'm here to get shit done and solve real problems in the real world.
BP So David, we wanted to talk a little bit about the tech stack at Expensify. Are you involved in that part of it now, or do you have a CTO and you focus more on the executive side?
DB Well, actually we don't have a CTO. No one has any sort of hierarchy internally. The only titles we have are fictional titles for investors, basically, because if you're a public company and like, "Who is this person? Who's your Chief Product Officer?" I don't know, there's a whole bunch of people that do products. I'm like, "We'll just pick one of them." But internally, no, our titles have no meaning. There's no one in charge of engineering. There's no one that runs product. There's none of that. Everyone just shows up every day, does what they think is the best use of their time, no one asks permission of anyone else to do anything. They just do it. The consequence, however, is that we vote twice a year on everyone else's compensation, we're actually in the process of it right now. And so all of our compensation is determined by votes. Everyone in the company participates, there is no titles, there's no hierarchy, and so your compensation is entirely determined by your peers. And so yes, you can do anything you want, but if what you do sucks, you're just not gonna make very much money.
BP Gotcha. I would spend most of my time trying to please my peers, just sucking up to other people. No, I mean, contributing, poll requests constantly.
DB But actually those two things are the same thing. How do you suck up to 140 people? You just kick ass. I mean, you just have to perform fundamentally. And so your question is how involved am I on the technology side? I would say I'm pretty involved. Like I have root in all the servers. I take a turn on pager duty, and so if shit breaks in the middle of the night, I get woken up once in a while. And so I'm very involved in a lot of the technology strategy. The layers that I work on are pretty stable and so thankfully they don't require a lot of changing. I'm not super involved in the application programming layer but I was pretty involved in the selection of React native and the early prototyping and things like this. I'm super involved in the product side and the business side and the financial side. So I'm pretty involved across the organization.
CW That's really interesting that you take a pager duty round, that's really, really cool because it's rare to find people who run companies, CEOs or whatever you choose your title to be, to actually continue to contribute to code, especially where Expensify is.
DB I mean the way I like to see it is, like we say, we view ourselves like a flat structure. But what does 'flat' actually mean? I think flat means that there's no thick juicy center, meaning everyone has to touch the real world in some fashion. Everyone is either shipping code, talking to customers, working with auditors, doing something on the outside. No one's job is just to think real hard. Because I kind of think the worst people in this industry are product managers. It attracts the worst people because, and I can understand why, it's like pure honey. It is all authority with no accountability. It's like, "Yeah, I don't talk to customers. I talk to people who talk to customers.” And, “I don't write code, I talk to people who write code." All you do is talk all day long and if anything goes wrong, there are a million ways to shift the blame. It's like, "Oh, that feature sucked? Well it's not my fault. The people who talk to the customers informed me wrong." Or, "The dude who built it, they suck. They fucked it up." So I think that we try very hard to say, no, everyone has to engage with reality, engage with the customer, engage with the outside world. That's what keeps you fresh. That's what keeps your perspective relevant, because value is not made by talking internally. Value is made by shipping functionality to actual customers and anything before that is just overhead.
CF I want to rewind to something you said earlier about people building companies that solve simple problems, but do it in a really complex way. And I want to hear your take on how you have built Expensify to not do that, because Expensify tackles a pretty, I would say complex high stakes problem. But it seems like since that's your philosophy, you would probably solve that complex problem in a really simple way.
DB: Yeah. I mean, there's probably a million ways to take this question, but the thing that comes to mind initially, and probably the most important, and one of the most probably difficult skills for someone to really grapple with when they join Expensify, and it sounds so obvious, is that we don't solve anything if we don't know what problem we're trying to solve. Which again sounds obvious. But a very common thing that you'll hear in the halls of Expensify is you propose that you want to do something. It'll be like, okay, step back, what is the actual problem you're trying to solve? Give me a problem solution statement, let's define the problem, and the problem cannot reference the solution. For example, we'll say an inverse problem statement would be, problem is I don't have a car. Solution, got to get a car. That's not a real problem because that's actually not getting to the heart of what you're trying to solve. The problem might actually be that I can't carry this bag of groceries home and then thus, the solution is get a car. But if you define the problem this way, well actually there's a bunch of other solutions. You could just call Instacart, whatever it is, there's a million different ways to solve it, but you can only have that discussion once the problem itself is specifically called out. So we are ruthless internally about demanding clear problem descriptions, even for things that sound totally obvious, because I think when someone says that it's obvious, that's a sign that it's not. Because if it were obvious, you would just say why you want to do it. When you say it's obvious, that's actually a cop out of actually giving a real description. And so we're always basically ruthlessly figuring out what is the underlying problem that you're trying to solve. Second, we spend more time talking about the problem than the solution itself. We say, "Is that a real problem? How real is the problem? How many people experience the problem? How sure are you that's a real problem?" Things like this. And so it can actually be quite frustrating for many people who join the company. They're like, "What are you talking about? Everyone in the industry does it this way. Everyone agrees it's a problem. Why are we even talking about this? It's so obvious." I would say, "If it's so obvious then you should be able to answer these questions very simply. But the fact that you can't answer them means that actually we don't really understand what we're trying to solve here. We always try to take everything down to these base principles and solve it in the most elegant and simple and scalable way. But when you take away this obsession with basically elaborate solutions, actually most problems don't exist and don't need to do anything. Our most favorite thing at the end is like, "Oh, so once again, the answer is do nothing?" We're like, "Yeah, great. Okay, cool." That is the best thing ever. And so I think the key to simplicity is just focusing on technology as a solution to a problem. And it's only as valuable as the problem it's solving. Because the vast majority of technologies out there literally do nothing. And so we try to say no, it's all about focusing on delivering real value in the real world.
CW When you are thinking about some of these problems, do you lean towards building or buying? Is that something where you're just like, "Oh, these tools are so complex. We might as well build it internally?" Or do you say, "Well, they're so complex, but they solve the problem. Let's use this new tool that's third-party so we can just solve the problem and go forward?"
DB Sure. I would say we end up building a lot more but that's not because we're seeking to build, it's as in, when you get really crisp on what the problem is you're trying to solve, you realize that most problems are kind of bespoke. Or rather, they're very specific. And most problems aren't actually that hard to solve. Any product that's off the shelf probably isn't that complicated. And so I'd say, for example, we use our own database for replication because it's actually built for replicating over internet connections and not just sort of like high-speed LANs and things like this. So it's not like we decided from the get-go that we're not going to investigate alternatives, but when we made this choice, MySQL didn't even have distributed transactions. Postgres didn't have transactions that could do LAN replication. The technology simply didn't exist. And so I'd say we end up building a lot because our requirements and scale are kind of significant, or a lot of the stuff that's off the shelf just kind of breaks down, but it's not because we didn't understand the options that were available, it's just that we weren't biased one way or the other. We're only going towards what's the best solution, and we don't really care if we have to build it or buy it.
BP David, I want to tee you up on this, to both Cassidy and Ceora's question, she was saying, "How do you approach your own philosophy of keeping simplicity in problem solving?" And then Cassidy's question is like, build or buy? The quote that was sent over, and I'll have you maybe defend it, is that you're interested in simple solutions to complex problems and advances in technology since the 90's have all gone in the wrong direction. Okay, I can admit that the 90's were a high water point for human civilization. And then from there, it goes on to talk about some of what you do, Ubuntu on bare-metal, sequel life or database C++ and PHP, no internal DNS. So just talk us through a few of those details of the stack and how, as you lay that out, I think it's a good illustration of your overall thesis.
DB Well, I would say if we go back to what were the technologies available in the late 90's? Okay, there's bare-metal servers. There's some basic SQL databases, there's PHP, things like this. The basic trappings of making a SaaS service were available. And what's happened after that? We've gone through like a million different frameworks. It's like, "Fuck SQL, it's gotta be Ruby. No, not Ruby, it's gotta be this other thing, or this other thing. It's gotta be Ruby on Rails. No, Rails is stupid now it has to be Angular. Nope. Angular is dumb too, it's gotta be Actionscript." Like all this stuff, and I was like, "Oh, well, why all this?" "Oh, we like these languages because there's no compilation." What are you talking about? Every single modern development uses the most elaborate tool chain, and is much more compiled than C++ but just worse. And so I think that we've kept rediscovering the old styles and then C++, it's fucking great. It's like, you want closures? You want like any language contract? It's all there. It works wonderful. It compiles wonderful. It's super high performance. It works across all platforms. And so I think that again and again, a lot of these technologies became solutions in search of a problem. And people are like, "Oh, isn't SQL terrible? We need to go NoSQL. It's gotta go to MongoDB. Oh, it's actually super hard to do some big query thing. Well, now we're going to make an SQL layer on top of our non-SQL database. Now it's just a shitty SQL database. You could actually just have an SQL database that does all of that. I think the worst offender has got to be AWS. I cannot understand why people like AWS. It is objectively bad in every possible regard. It blows my mind how people don't see this. You could go to anyone, probably 99.9% of your viewers would agree with the statements like, "AWS is cheaper, it's faster, it's simpler, it's more reliable." Everyone would be like, "Oh yeah.", they just nod their head. "Yeah. Definitely." It is none of those, like from a cost perspective, so we operate these 384 CPUs, 6 or 7 terabyte RAM servers, these giant monster servers. And they cost literally 10% of what you would pay in AWS bills. Let's even think about that because AWS, they're not in the business of giving away things. The cheapest you can get an AWS server is if you prepay for three years, but the cost of prepaying for three years is slightly more than the actual hardware cost. And the hardware cost has a much longer lifespan than three years. You're actually paying like a 10x premium for AWS. I can go on and on about all of this, but again and again, when it comes down to what is the actual problem you're trying to solve, and what is the simplest solution to it? Almost always the solution is the oldest technology, because it was the very first thing that people figured out forever ago. Any new technology that is coming out right now, it can't be solving that hard of a problem because what new problems have come out for computers in the past five years? They've worked exactly the same. Bits are the same. Your screen size hasn't changed. Basically nothing has changed since 2000, but we just keep changing technologies just for the fuck of it.
BP I want to let Cassidy and Ceora in because this is a topic we've discussed before, but I think some of that is every generation, and let's say every new cohort or class of developers, wants their crack at writing the same language but improving it a little, personalizing it. And then there are trends and fads and fashion and a sense of social capital within that stuff. So Cassidy and Ceora I'll step back. But I think that's why you see that pendulum swing of, let's make it more complex, no less complex, SQL, no NoSQL, like back and forth. And often you find you end up in the same place at the end, but everybody wants to get their chance to run that race, I guess.
CF But a lot of things are hyped up because a company has good marketing. Whatever the language or the framework or the technology whatever it is, might have really, really dope marketing that tricks people into thinking like, "This is the best thing since computers have ever existed." And I know for myself as someone who was coming in, like fresh into the industry, there were certain things that everyone was talking about, certain technologies, frameworks, generators, things like that. And I would be like, "Okay, I'm going to try it out. This sounds amazing. Everyone's talking about it. The company seems like they know what they're doing." And I would try it out and I would be like, "This was a horrible experience for me." And I think a lot of times that is because people get trapped into the hype. Everyone is talking about it so you start to get hype about it too. And then when you really sit down and think about it, it's like, oh, this maybe isn't so great. And I've had moments like that myself with certain things where I've gotten really hype like, “This thing is so great. It's awesome. I love it. It's going to be my new personality." And then after I really start to spend some time with it and build with it or try to build with it I'll be like, "Oh wait, this really kind of makes what I'm trying to accomplish harder than it needs to be." So I do see where you're coming from with that. I do think probably as a society, honestly, we've gotten into the habit of not really identifying problems at their core and just chasing after shiny new solutions just because their ideas seem cool.
CW I think the pendulum is very real of people trying different things. And it's not necessarily just in one direction either, it's one of those circular pendulums.
All [laughter]
CW One of those things. They're in like museums with the clock.
BP Yeah. You end up in the same place. Yeah.
CW It's a very real thing. Like, just as an example, if you look at web development over the past decade or so it was, "Everything is static. No, everything should be rendered on servers. No, everything should be single page applications. Oh, actually, no servers are good. Oh, well, what if we did static again?" And it's all the same thing where yes, we're probably optimizing certain aspects of each of these things better, but we're all solving a lot of the exact same problems that we've been solving forever.
BP So let me take us a little bit in a forward-looking direction now. David, you just talked a bit about the things from the 90's you think are still good and the futility of solving the same problem over again. But are there things that are happening now in software technology that you're particularly excited or enthused about? I know you said you tried out blockchain before it was blockchain, so I guess first I should ask, are you Sotoshi? Because if that's true we'll use the rest of the time to discuss that.
All [laughter]
DB That would be amazing, but sadly, no.
BP So yeah, what gets you excited when you look out at the technology landscape? Are there things that are on the roadmap for Expensify, where you're hoping to adopt or move in that direction because of what you see?
DB Well, yeah. I think that I would say again, the technologies themselves don't super excite me, but I think the problems that can be solved with them do. And I think that one maybe challenging idea is that all of us grew up during a period where there was a steady drum beat of tech disruption, basically like every 10 years or something like that. And so we've just got into this habit of thinking, of course digital technology is disrupted every 10 years. It's always been, it always will be, is kind of the idea. But I think there's a radical possibility, what if there is no next big thing? Because most industries don't have a big thing. They just mature. Like oil exploration is just oil exploration. It's basically the same and it stays the same for a very long time. Maybe you go to fracking and things like this, but by and large, at some point you just kind of perfect it and then it just gets incrementally better. And I think that when it comes to disruption overall, people over-focus on the technology side and they ignore the business side. What makes the disruption cycle happen isn't that a new technology came out. It's that a new business model was enabled, and that business model was more efficient at acquiring customers than the one before it. Computers initially sold through governments. We're going to sell one to each nuclear power, like six in the world. And then it came out through large corporations. And then it was like mini computers, sourced through field sales. And it was like PCs through retail. Then mail order was a big thing. Then it became online. Now there's no software, it's SaaS and it's in a laptop, then it's in your phone and then it's still in your phone. Basically your phone is the same size. It's hilarious how Apple has used the exact same advertising campaign for a decade now? It's like, "Shot on iPhone." It's like, "It still is." It's not even saying it's the best camera. It just says, “iPhone exists and has a good camera.” And I think it's amazing that if you open up your phone right now, most of the apps on the home screen were probably made around 2008 and you probably haven't changed your home screen in the past five years. Maybe you added TikTok, maybe, but not much has changed. And I think that for the next 10 years, your phone is going to be the same size. It's the size of your hand. Nothing's really changing, so the business model isn't dramatically changing. And so we might not have a big tech disruption. And so when I think about the future, I think much less about what's the new fancy technology that comes out, and more about what is the next business model that's going to come out. And possibly, maybe there isn't one. And so therefore the future is less about radical new use cases and more about consolidation of existing use cases. Why is there 500 apps that do the exact same thing? I just want one app that can kind of do it all. And so I think the future is going to be more about a super app concept, a world of like, "Are you in the Google super app? Are you in the Facebook super app? Which one is kind of your home turf, if you will?" And they're just going to kind of expand out. I think it'd be a hard time to start a new startup right now because there's just not a lot of room and it's easier than ever to write technology. It's easier than ever to raise money. Everything is easy except for the one thing that matters. And that is acquiring customers. That is harder than ever.
CW It reminds me of an episode that we had on the podcast somewhat recently in the past few months. We had Alex Obenauer on the podcast and he was talking about what a future operating system looks like. And it addresses a lot of what you said because so many things have stayed the same for so long and we just accept this is how notifications work. This is how apps work. This is how this, this is how that works. And he's done a lot of research and questioning on what if we change notifications to be more driven by you, rather than someone trying to get your attention and kind of reversing those kinds of concepts. And there's nothing tangible out of it besides the research, but it's an interesting perspective.
BP Yeah. And I think there's the macro picture as well. For me, the biggest change has been the pandemic and moving away from the city, moving out into a rural space and the ways in which the technology I use now flexes in a different way. I can be on slack and email, move to a different part of where I'm at and jump on a podcast. It's all mediated over software, then run back and do some farm chores and then finish up a slide deck from my phone. So that is old technology, but it has a new application for me because the world is kind of changing on me.
DB Yeah. And I think the interesting thing going forward is going to be about this whole idea of the new work-life balance, and that the idea that you have to go to an office, that idea is gone. It's never going to come back. Any business that requires you going to the office must have died by now. So every business that has survived cannot claim that that's a necessity going forward. But we haven't really figured out, what does it mean if all my employees can work anywhere? Historically you could only work with people that were literally within spitting distance of you. But now, you can work with anyone, but the next constraint is really timezone. You can work with anyone so long as they're in a compatible timezone. The next barrier after that is how do you work with people effectively in different timezones, and moving away from a synchronous management style towards an asynchronous management style. And I think there's a huge opportunity that comes from that. But also it's like the difference between single threaded programming and multi-threaded programming. It's just an order of magnitude difference. The organization itself is a completely different company, if everything is designed to operate asynchronously without reliance upon any timezone.
CW That's literally what we're solving at Remote right now. We're saying, "Okay, what does the workplace of the future look like if we're everywhere?" Because I have coworkers who I work with and chat with who are in Korea, who are in Israel, who are in South America, all over the place, and it's completely async and it's very different from what I've experienced before and we have to figure out, “Okay, if we want to solve these problems for other companies, how do we define what the future of work looks like in terms of flexible hours, a universal timezone of some kind, async work in general, and what do meetings look like if people aren't able to come because they're on the other side of the world sleeping?”
BP I think the ones who are gonna lose out are that fat middle, the middle managers that David mentioned before, the ones who lose out when it's all async and project driven and about how do you deliver for your colleagues. There was a question– Workplace is my favorite Stack Exchange, it's where people go to ask awkward questions they're afraid to ask their colleagues. And it was, we hired this developer remotely to do a project for us, but I see them playing on Let's Code two or three hours a day during the work day. I can see them online playing games when they're clocked in to work. And the answer from the top three answers was just like, "Well, do they deliver the projects on time? And if not, then you should be setting different deliverables or talking about that. And if they're delivering the projects on time and wasting time coding, maybe they need bigger projects." It wasn't like, "Shame on them." It was like, "Shame on you as a manager. That's your thing to figure out. It's up to them to decide how to spend their time if they can deliver what you ask them to."
DB Yeah. I think that's definitely true. On the topic of meetings, one thing that we've started doing is we actually don't have any group meetings, really. I meet with one group of people a week and then we do a bunch of one-on-one meetings, but basically there's no team meetings of any kinds. But we do what we call 'slack meetings' where we'll schedule a time where everyone's going to go in this particular room, someone will moderate a discussion with a bunch of threads, and then we will intentionally leave the conversations unresolved for at least 24 hours to let everyone in the world participate in that. And I think that this idea of figuring how do you use the new tools, it's not like chat is new, it's not even like threads are new, but trying to specifically use these old tools in new ways to enable an asynchronous work style, I think that's the challenge and that's what drives a modern business today.
CF One thing I want to mention that I think ties all this together too, as you mentioned earlier, about how one of the problems now is that we have the tools, we have the problems, and the disconnect is knowing what customers need and want and being able to reach them to give them the solutions that they need. So I think that's probably a problem that in tech we'll start really thinking seriously about because in a big way, we do have most of the tools that we need to solve these problems. I think the disconnect is really knowing how people need those tools to be applied now because things are really changing, right? We just talked about how work-life balance, work-life culture is changing dramatically just over the past year and a half with the pandemic, actually two years by now. But it's just like, how do we use these tools that we've had for years, like slack or other things, tools like that, to fit our problems, solve our problems, now dealing with timezones and things like that. That's just one example out of a myriad and I'm interested in seeing how tech companies are going to figure that out, and if they will. It's interesting.
BP Right. So David, maybe we'll give you a chance at the end if there's something in particular that you're passionate about or you want to talk about, we can. Do you want me to throw it in that direction or we can just wrap it up here? I'll let you decide.
DB Well, I would say something I'm passionate about as I said, is always using technology to solve hard problems. And I think the hardest problems are not really in the workplace, honestly. Internally we have this concept, we say "A life well-lived is one where you're living rich, you're having fun, and you're saving the world." And I like the bombastic phrasings of these because they're all just sort of out there, and to kind of put some structure in what we mean by those, when we say living rich, it means that your boring average day is amazing. You wake up in a comfortable bed with someone you love. You go to work, you're inspired and energized, you're challenged. You come home and you have the time, resources and energy to spend it on your family and the time around you. But that should be every day. That's just like a baseline. Like having fun, is not like XBox fun. It should be, you're always thinking back to that last bucket list thing that you did like, "Oh my God, wasn't it an amazing thing we just did? That's a once in a lifetime thing." And you're always thinking to the next thing, always in that trough between two bucket list items. That's having fun in our mind, but both of those are sort of an incomplete experience. We'd like this idea of saving the world. I like this outlandish phrasing of it. It's not like, "Do your part." Or, "Don't make things worse." It's like, "No, no, no. Let's actually pick hard problems and then genuinely put in place scalable solutions that will ultimately solve these hard problems." And it's a more optimistic and engaging approach towards basically trying to be a good global citizen. I feel like there's so much apathy and skepticism and cynicism around what can be accomplished with technology and so forth. We've proven that social media can ruin the world. But can we prove it can save the world? That's a harder problem, and I think that rather than just criticizing the first generation of this stuff because we're still pretty early into a lot of these technologies, we're still figuring this stuff out. Let's not give up hope for the internet and for social communities and things like this. We just need to have a new version of them. And so I'd say everything we're doing as technologists shouldn't just be solving the problem right in front of us, just making money or whatever it is. I think we should be always using our positions of influence and creativity to think about the huge topics, whether they're equity inclusiveness, whether they're just ensuring that everyone has the ability to live rich and to have fun. That's what we think saving the world is, and that's everyone's job. And I think it doesn't matter what you're doing. I run a fricking expense reporting company and somehow we're involved in all of these social issues. If I can figure it out, I'm sure that you can too.
[music plays]
BP Alright, everybody. It is that time of the show. We like to shout out the winner of a lifeboat badge, somebody who came on Stack Overflow, found a question with a score of negative three or less and gave it an answer that got up to a score of 20 or more. You may have heard of this individual, John Skeet, awarded February 7th, "Is a ternary expression possible for this construct?" John Skeet, the guy does not stop. I am Ben Popper. I am the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper, email us podcast@stackoverflow.com with questions and suggestions. And if you like the show, leave us a rating and review.
CW I'm Cassidy Williams, Head of Developer Experience and Education at Remote. You can find me at @Cassidoo on most things.
CF And I'm Ceora Ford, I'm a Developer Advocate at ApolloGraphQL. You can find me on Twitter. My username there is @Ceeoreo_.
DB And I'm David Barrett, the Founder and CEO of Expensify. You can find me anywhere at @dbarrett and definitely check out our page, we.are.expensify.com if you're interested in a job.
BP Alright, everybody. Thanks for listening, and we'll talk to you soon.
[outro music plays]