Latest / The Laravel Podcast / A Day in the Life of Taylor Otwell, Managing a Remote Team, Productivity, Regrets, & Marriage

Transcript

A Day in the Life of Taylor Otwell, Managing a Remote Team, Productivity, Regrets, & Marriage · The Laravel Podcast

• Matt Stauffer: You're now listening to the Laravel Podcast. All right. Hey everybody. Welcome back to the Laravel podcast season... God, what season is it? Six? Season six. I'm like season I don't know, something. I'm one of your co-hosts, Matt Stauffer. Then we also got Taylor. Taylor, you want to say, "Hey"? Taylor Otwell: Hey, everybody. Is season six when they start thinking about canceling a TV show? Matt Stauffer: You know what? Now I want to figure out- Taylor Otwell: I hope not. Matt Stauffer: ... what season did the jump the shark incident happen? Jump the shark. Was that Good Times that that happened in? Taylor Otwell: I can't remember. Matt Stauffer: All right. It was, oh, Happy Days. For anybody not familiar, there was the American sitcom called Happy Days and it, over time, got more and more just kind of crazy trying to get people watching it. At one point there's an episode where he actually jumps over a shark and so they say, "Jump the shark" when something is just like they went too far, they're trying too hard, just let the thing die. Now I want to see, what season was it in? It doesn't actually say what season it was in. Taylor Otwell: We'll be more like The Simpsons, like Season 57 or whatever. Matt Stauffer: Yes, exactly. That's what I'm talking about. Yep. Oh, it was season five for them. We are already past it. We're good. Taylor Otwell: Nice. Matt Stauffer: I like it, like The Simpsons. Oh, go ahead. Taylor Otwell: Me? Matt Stauffer: Yeah. Taylor Otwell: I wasn't saying anything. Matt Stauffer: Okay, cool. When I got into comics as an adult, I was like, I've always wanted to do comics and my parents wouldn't let me or didn't have money or whatever. And so, I never did. Then I realized as an adult that, oh my God, I can just buy comics now. I bought this Marvel unlimited subscription where for 80 bucks a year you can access the whole back catalog on the internet. I was like, great, I'm going to get started with Spider-Man. It was like volume 192 or something. I was like, how the hell do I catch up with this? But I was able to find, they did this thing called, it was the alternate universe. I don't know if you follow any of that stuff. The ultimate. Taylor Otwell: Not super deep. Not super deep. I know it's a vast amount of material. Matt Stauffer: One of the things they did, I think in the nineties, was they did a alternate universe that I think is where Miles Morales is from, and I think it's called the Ultimate Universe. They rebooted everybody in that universe and told the stories a little bit differently. And so, I was like, cool, this is a more manageable kind of subset. I still haven't read almost any of the comics from the normal people, except for Black Panther, but I read through all of the, I think it's ultimate, but whatever that was. That was kind of fun. They did things a little different, like miles Morales is a little different. Tony Stark, his dad experimented him in a certain way that ended up in basically intelligence slash AI being in every cell of his entire body. I don't know, it's kind of like they're like, "Let's tell a new story versus just retelling the same Ironman, Captain America or whatever stories we've told a million times." Taylor Otwell: That's cool. Matt Stauffer: I guess we're supposed to be talking about code here, huh? Okay. We have a queue of questions that people have asked for us, and every single time we get to talking, I say, "Hey, what's new and what's in the queue?" And one of the things I found was there's a whole bunch of items on the queue that all are related to how you and I run our businesses and how we're productive and any regrets we have. I figured, let's pick those up for this one. One of the things that I think that is the biggest deal that everyone was asking is, what is the day in the life of Taylor at Laravel? And so I think let's just start with that one. Today, and I've asked this over the years, but I feel like your role at Laravel has changed over the years, too. What do you actually do on a daily basis? And obviously you're the BDFL, the Benevolent Dictator For Life, but you're also running a company. What do you think of your role as the company as being and what kind of stuff do you do? Taylor Otwell: Walking through my day, I always start the day on customer support. Any customer support tickets that have been assigned to me, which is usually I would say 8 to 10 tickets, something like that, I will handle those. Usually refunds, customers that are getting sort of upset or sensitive tickets or whatever. Those are the kinds of things that I handle. After that, I head straight to GitHub where I review all of the poor requests across the whole organization. I'm still pretty much the only one that merges poor requests across all the Laravel repositories, including the framework all the way down to Socialite, Telescope, Horizon, Octane, everything. I sometimes ask for a review on those if it's a package that I'm not super expert in, which would maybe be something like Laravel Pennant, which Tim McDonald wrote. Most of the packages in the Laravel ecosystem currently, I actually originally wrote, so I'm somewhat familiar with how they work, so I manage all of that. We get probably, I don't know, it can range anywhere from 10 to 25 pull requests a day across the ecosystem that I kind of need to manage. Matt Stauffer: Wow. Taylor Otwell: Of course a lot of them are super quick, but a few of them end up being multi-day endeavors or even multi-week explorations of whether this feature is needed or not. After that, I sort of review whatever's in my queue from the Laravel team. If James needs me to review something on Forge or Joe needs me to review something on Vapor, I'll do that either on GitHub, or if it's a post on Basecamp where they're sort of pitching a feature or a problem we're having, I'll review that, respond to all of those. Once all of that is done, which is probably going to be almost 11 o'clock, I would say, I'm sort of free to work on whatever I want to work on. Sometimes that's busier than others. Sometimes, like right now, I need to review a new package we have coming up at Laracon Australia called Laravel Pulse. Not going to dig too much into the details of what that is because I don't want to spoil it, but just reviewing that code base is what I have on my plate right now. But that just varies. I do think my role at Laravel has changed a lot over the years. Used to be more hardcore coder all day to more curator, editor, refiner, sort of like the chef that does the final inspection on the way out the door, I guess you would say. But of course still write a fair amount of code too, like Folio and Volt were sort of prototyped out by me, and then Nuno and I collaborated on Volt. That's kind of honestly a day in the life of Taylor at Laravel. That's pretty much what goes on. Matt Stauffer: It's interesting to me, the thing that you mentioned about you still merge all the poor requests, because I think one of the things that people often say when they're talking about running a company is, I just went to a conference for people who own digital agencies, whether it's doing programming or whatever, and they're like, "You need to get out of the day to day. You want your hands out of the pie or whatever." In some ways, you've said that you are. You're not the one originating everything. There was one of the speakers there who's like, "I know that people who run this conference are going to say I'm terrible," but he's like, "One of the things that I want as an owner of business is to keep the business being the things that I still want to do and the ways I still want to be involved in it. And he's like, "So what I've done is I hired a CEO to run the thing so that I can still come up with fun little experiments." He's like, "It's her job," and I know this is not what you do, but "it's like it's her job to take all my experience, then decide how to make money with them." He's like, "But I want to make experiments. That's what I like. I don't want to be like, now I can't do what I like because that's not what business owners do." Obviously that's not exactly what you're saying here, but you have obviously built space for yourself to innovate and to create and to continue to be involved in a way that I think that it would be hard for you, for the Taylor ecosystem or for the Laravel ecosystem to be Taylor and for there to be stuff out there where you're like, "I don't know if I actually agree with that." I have this very small microcosm of that with Valet because we got to the point where I'm like, "I need somebody who knows this particular subsection of Valet better than me to be the one who decides." I'll ask Chris, Dr. Byte or somebody else, "Hey, you know WordPress better than I do. Is this particular request to the WordPress thing better?" But in the end, that still kind of runs through me, so I can still feel like I own the decisions that are made there. That's an interesting balance. It's like you're delegating responsibility for reviewing a particular thing, but the buck still stops with you. Is that how you look at it? Taylor Otwell: I think so. I do the same thing. I'll reach out to, there's a person in the Laravel community, Tobias, that's really knowledgeable about databases. Recently we had a database PR, this was only maybe two or three weeks ago, had a database PR, wasn't super sure about it, so reached out to him on Twitter DMs and asked him to take a look at it. He kind of looked at it and said, "Yeah. It looks okay to me." I still reach out to people like that, but the reason I still merge every poor request is just to, one, make sure we're only maintaining the things I want to maintain and that the framework is staying sort of focused and not too bloated, but then also to make sure that Laravel is internally consistent stylistically, so that all the code is basically how I would've written it, more or less. Because if it's not, I'll pull down the poor request and tweak it to be how I would've written it so that the entire code base and most of the packages feel like they were written by the same person and has this consistency when you're reading through it, which I think is helpful if you're trying to work on the code base; It all sort of has the same style, things are named similarly, the variables are named in the same way. Everything just works together. I think if I was letting a team of people manage poor requests, the framework would start to feel really disjointed pretty quickly, actually. Matt Stauffer: That's a great point. You've talked often about the things that drive you, like how to make an API. Laravel has a lot of incredible benefits, but one of them that we don't always talk about but always benefit from is, it just works. You try a new thing and you're like, well, I understand the ethos of how the database driver works, and so if I have to hit the cash driver for the first time, it's probably going to be very similar. And so, you can kind of intuit things. If you learned one, you can intuit that another one's probably going to work relatively similarly. Taylor Otwell: This is semi-related, but one of the benefits of Laravel, I think, is just how cohesive it is, which creates that it just works together feeling. I think that, for example, comparing to the JavaScript's ecosystem, I think it's very different and hard to replicate in JavaScript where, for example, in Laravel, let's say you have an event listener that listens to an event and you don't want it to execute until the end of the current database transaction and you want it to be queued. You put the should queue interface on it, you put after commit on the event listener so that this thing is queued and it's only executed after the current database transaction finished. That takes an interaction of three big libraries: the database library, the event library, the queue library all working together. That sort of cohesiveness just doesn't happen in the JavaScript ecosystem because your database library and your event library and your queue library are all going to be separate; They're all going to be written by different people; They're not going to have that same cohesive feel. I think that's part of what makes Laravel so nice to work with, honestly. Matt Stauffer: One of the nice things that I like about how Laravel does that is, granted that Laravel relies on Symphony classes, it's got its own internal classes and it relies on third party packages as well, but when it does that, the majority of time it's putting them all in front of a Laravel flavored thing. You may not be writing... If someone heard what you just said and didn't know, they might be like, "Oh, but aren't you duplicating code that other packages have written?" It's like, "No, because it's also relying on these other packages from people outside Laravel ecosystem, but all of them have a face in front of them, an API in front of them that is consistent across all of them, so we're getting those things normalized." And no shade to Symphony, but often when I'm having to reach down into the Symphony component, I'm like, uh, get this set, that or whatever, and I'm like, I'm very grateful for the fact that my day-to-day work with the console commands or whatever else is not actually the direct Symphony thing, but it's these really nice APIs on top of it. Taylor Otwell: Right, and pretty much everything in Laravel except for the HTTP request and artists, the console, is sort of custom. HTTP and console are really the only big Symphony things that we leverage. Everything else, like all database cues, events, all of that is custom written. Matt Stauffer: And it's not as if you couldn't write those too, in Laravel. It's just sort of like, why do it when there's already a good one out there? Taylor Otwell: Yeah. Matt Stauffer: Okay. Continuing to talk a little bit about running the business of Laravel. One of the questions we got was about managing a remote team effectively. I know that you and I both manage remote teams, but kind of different style. We've got questions like, how do you handle standups? How do you handle assigning people's works and shaping the features they're going to do and keeping people accountable and communication? Could you walk us through a little bit what your remote team setup looks like? Taylor Otwell: We primarily use two tools, Slack and Basecamp. Slack, of course, for everyday quick communication and stuff, and Basecamp for what we call check-ins and work cycle announcements. I'll explain both of those things. But basically every month in Basecamp I write up a document of what we're going to work on that month. Some people do it in six week sprints, five week sprints, whatever. I just do it by month. Actually, this week pretty much I'm going to be writing up what we're going to work on in November and I'll assign it to people. Really, that's usually not too hard because James Brooks works on Forge, Joe works on Vapor, Nuno also kind of works on Vapor, Dreese works on quite a bit of open source stuff. We've sort of slotted into these roles and they're not totally static. Joe could definitely work on Forge and other people could work on Vapor, but that's just kind of how the cards have fell. I'll write up what we're going to work on, and leading up to the next month, I'll be keeping an internal list of things I think I- Matt Stauffer: Got it. Taylor Otwell: ... want to put on that document as people suggest things or as problems come up or just as ideas hit me during the month. I definitely have some idea before this week of what I'm going to put on the next work cycle. I'll write all that up. I'll also ask for feedback from the team on anything they think we need to address next month. Then I'll post that out on Basecamp and everyone is free to work on their assigned task in pretty much whatever order they want to work on them in. As far as standups and accountability on that stuff, we also use a feature of Basecamp called Check-Ins where, I've done this two different ways, in the past I had to check a prompt that comes into your Basecamp every day at four o'clock in the afternoon that just says, "What did you do today?" And you don't have to write a ton, but just like a paragraph about what you did that day, just so I have a sense of what's going on. It's not really to be big brothers, it's just so I can feel like I have some sense of what's going on at the company just because up to like 10 people now. So that's how I used to do it, but I've transitioned to a new system and I'm not totally sold on if I like it or not. But on Monday we ask, "What do you plan to work on this week in the morning?" On Wednesday afternoon we ask, "How are your projects going this week?" And on Friday we ask something like, "Did you finish what you wanted to get done this week?" I can't decide if I like that better than just asking what you did this day every day. I may honestly switch back to that, but that's sort of how we do so-called standups or whatever. We don't have any Zoom calls or any synchronous meetings as far as that goes. That's kind of how things go. I don't know if there's much else to say as far as how we schedule and do work. Once things are done, they'll put them in my Basecamp to-do list for me to review them, and then we ship them, and that's how it goes. Matt Stauffer: Nice. Do you have any expectations of synchronicity, like people working at the same time, or is it purely asynchronous? Taylor Otwell: Sometimes I will put two people on a project, especially Tim and Jess, since they're both in Australia, I've put them on the same project a couple times. One, just so they don't feel totally isolated because the rest of the team is asleep while they're working, and the Slack is much, much, much quieter while they're there. I think that probably feels a little weird, but to alleviate that, I've put them on some projects together. I've put James and Joe on projects together. It definitely happens. I wouldn't say it's the norm or what we do most of the time, but it does happen. Matt Stauffer: Well, this question asked for both of us, I'm trying to figure out how to give the short answer for ours, but we don't do standups. Taylor Otwell: Tighten, I feel like, is a much bigger, more complicated operation, perhaps with more projects going on, so I'd be curious to know. Matt Stauffer: We don't do standups. We have a weekly meeting for every... The majority of our teams are two programmers and a project manager, sometimes a little bit of design. The most standard thing is you've got often a lead programmer and then a mid-level programmer or staff programmer, and then the project manager is 20% of the number of development hours. If you've got two people on it, then they're working half week, basically. They meet together once a week and they say, "Hey, here's what we're working on this next week, here's what we worked on last week." Then they usually have that exact same meeting with the client the next day. They said, "Hey everybody, here's what we did last week. Here's what we're planning to do next week. Here's a demo. Do you have any notes on this?" And so, there's usually basically those two big meetings, like a one-hour meeting internal, one hour meeting with the client, max. Then everything else is just internal work. But we do a lot of pair programming. Not full-time pair programming, but there is a lot of synchronicity. We try and make sure that there's a pretty decent overlap between the project manager and each of the developers and the client, so that when they do need those kind of communications, it's not like, well, we'll wait until tomorrow. Because we've worked with folks who are so far outside of our time zone or the client's time zone that it's sort of like every single time anybody has something to say, you wait and then you wake up and then they're shutting down, and now you've got 20 questions for them and you can't kind of get that synchronous communication. We've always said Basecamp has this very asynchronous way of thinking about their work, and that's not how we do remote. We do have a ton of respect for their conversations around remote, but ours is not fully synchronous, but we require people to be pretty modestly overlapped with each other because of the amount of communications with the PM or communications with a client or pair programming, whatever that you have. We do Slack for everything. All our communications are in Slack. The majority of our notes also live in Slack and also Slab, which is a tool that's sort of like a business-y version of Notion, but I don't think the programmers use Slab all that much. I really think it's more like project managers and the admin folks use Slab. 99% of the work we do is going to be either in code, it's going to be in Trello as well. Our tool of choice for task management is Trello. We had tried Basecamp for a while, but I think that we didn't commit fully enough into the Basecamp ecosystem to really get the benefits of it. Taylor Otwell: I don't think Basecamp to-dos is very good. Matt Stauffer: I agree. Taylor Otwell: I think Trello is much better at that. Matt Stauffer: We use Trello for to-dos. We do have a tool that we built called EOD, and basically at the end of every day people say in Slack at EOD, there's an EOD bot, EOD meaning End Of Day, and you just kind of give a couple of bullet points about what you were working on. It's similar to the Basecamp check-ins that you have. With some clients, they put those EODs directly in a client-facing channel. Some clients we put them in, the project manager will scoop them all up and then share them, just depending on the communication style. The majority of the time everybody's in Slack. We try to keep everything in Slack as much as possible only because if that's where we're asking you to live, it's better to integrate things into there, than be there and you also have to have three other tools open. We've even built internal tools and then sort of sunsetted them in favor of just trying to have a custom Slack integration of some sort instead. So, most everything lives in Slack, Trello, GitHub. With clients, sometimes we have to be on GitLab, sometimes we have to be on Jira and Confluence. We'll join that stuff for them, but our ideal setup is weekly internal meetings, weekly client meetings, lots of overlap between the two programmers, the project manager. Programmers do as much coding as possible and as little management as possible. That's what the PM is there for. We're very, we call it lowercase A agile, or I call it that and then make other people call it that. But we don't have Scrum masters, we don't have all that kind of stuff, but we just try to say every week we're going to do the best work that can possibly be done on this project for this week based on what we know, and then the next week we're going to do the same thing and the same thing and same thing. I think that's basically how we do it. Taylor Otwell: As you were talking about all these tools, when you're running a business, it's so easy to accumulate so many tools- Matt Stauffer: Yes. So true. Taylor Otwell: ... that you're using to do things. I just always find myself wanting to consolidate back to a few tools. We've explored a lot of different tools over the years at Laravel, trying. We've used Notion, we've used GitHub projects, we've used Trello, and it's just like, gosh, it's so nice to try to consolidate. It's like a never ending journey trying to figure out the best workflow. Matt Stauffer: I don't know about you, but every single time somebody joins, they bring some opinions. Sometimes they'll join and be like, "I love Linear. Linear's the best thing ever." They'll kind of dive into Linear for a while. But so far, no matter what other things we've tried for information management, we end up back in Slack. It does all the things we need well enough for task management. We always end up back in Trello. We've been chat-based since the very beginning. It was Rocket or Campfire or whatever it was originally, then there was one other one in the interim, but when Slack came up, it was like, oh yeah, this is life. When the new Slack update came out, I was so nervous. I was like, our whole company is founded around Slack. Interactions in Slack, groups in Slack, connections to Slack. It didn't break it too much for me. Taylor Otwell: I don't mind the new Slack update, but I have seen a lot of drama about that. Just talking about Trello makes me want to go back to Trello, honestly, because- Matt Stauffer: That's fantastic. Taylor Otwell: ... I personally use Trello for Laravel 11 and Laravel 11 planning. I keep track of all breaking changes that have been made in Laravel 11 in Trello. I keep track of all new features. Matt Stauffer: Nice. Taylor Otwell: And this is something that just I can see for my own personal benefit. When I go write the Laravel 11 docs, I have a good list of everything that's happened. I love Trello for task management, but I feel like, okay, so if I start using Trello for task management and stop using Basecamp to-dos, now I'm only using Basecamp for check-ins, which is like, why am I using all of Basecamp just for check-ins? Which is why I started building Beep, which was just check-ins- Matt Stauffer: Check-ins. Taylor Otwell: ... as a product only. I don't know what to do because I'm with you, I love Trello for task management and what people are working on and what we need to review, all of that. I think it's awesome at that. Matt Stauffer: One of the things when you were building Beep that I thought of is, remember what I said was when we build internal tools that require people to go log into them, they're just much less likely to be used. I was like, Beep with a Slack integration once a day- Taylor Otwell: It would have to have Slack. Matt Stauffer: ... Beep the app DMs you and says, "Hey, what's your answer?" And you type it and then it just stays in a database. Then of course you, as the admin, can go look somewhere outside of Slack, but now people don't have to log into Basecamp at all. They can just have Trello for their tasks and Slack for everything else. Taylor Otwell: It would have to have Slack integration. Totally agree with that. Put that on the Beep backlog. Matt Stauffer: Yep. I'm compelled. Speaking of which, one of the questions that people brought up was, how is Taylor so productive? And you have talked a little bit about- Taylor Otwell: I don't even feel like I'm that productive, honestly. I feel like I could be much more productive. Matt Stauffer: I agree with the questioner, that you get an incredible amount done running a company, employing people, responding to GitHub issues, stuff like that, then also creating stuff. It does feel like your thing earlier, when you were talking about how your day works, gave the answer a little bit, is because you have this very structured thing that leaves space for creativity. Whereas I think a lot of us just spend the whole day being beholden to our email. I'm guessing once you're done with your morning, you don't go back and check GitHub issues again? You don't go back and check your to-do list again. You're mainly like, "Cool, I'll do that again tomorrow morning, but now it's my me time." Is that true? Taylor Otwell: Pretty much. That's pretty much true, I think. As far as productivity goes, I think I'm productive in a different way than I used to be, which sometimes makes me uncomfortable. To me, back in, let's say 2014, well, really 2015, 2016, back when I first started working full-time on Laravel, to me, a productive day was typing on the keyboard, code eight hours a day working on Forge or, back then, Envoyer maybe, or Spark. That felt like a really productive day. I was the only employee at the company. We hadn't even hired Mohamed yet, who was our first employee. Of course I was the one coding everything. But now with like 10 people in the company, it's just rare that I'm coding all day. I'm doing a lot of different stuff, like I said, curating, reviewing, writing, emailing, which I guess is productive. I'm not sure. I'm totally happy with that, feeling productive, because it's not the same. But at the same time, these people work here, they have to work on something. It would be smart of me to delegate these tasks to them so that we can get even more done rather than it just being me. I don't know, I'm still not totally used to that. I may be feeling that more because I personally don't have some big secret project that I'm working on every day because Laravel Pulse was, originally, the idea for it was formulated by me, but Jess and Tim have been working on it pretty much the whole time. Matt Stauffer: Got it. Taylor Otwell: I've been giving feedback here and there, but honestly not that much feedback. We are kind of doing the traditional Laravel secret project, have something in the pipeline, but I'm not the one coding everything. I don't know. It's a weird feeling that I'm still trying to get used to. I'm not totally sure I like it, to be honest. Matt Stauffer: I don't know, maybe we're going to get you a CEO one of these days, so you can just sit and come up with fun projects then. Taylor Otwell: Maybe so. Maybe that would be fun to just take all of that off my plate and go back to being just a coder the whole time. Matt Stauffer: We should probably start wrapping soon, but there was two questions here that I feel like I couldn't not bring up because I feel like they're spicy. The first one is, do you have any regrets in Laravel and do I have any regrets in Tighten? Taylor Otwell: On the business side, I think I didn't hire soon enough. I can't remember exactly when we hired Mohamed. It was like 2016, 2017, but I'd been working, I think, full-time at Laravel for almost a year before I hired someone. I put off hiring a little bit too long, mainly because I was scared that I had been the main one to work on Laravel this whole time. If I bring on someone else, what if the framework gets messed up? What if they mess something else up? But that really didn't happen. Bringing on Mohamed was a big productivity boost and help for the company, so I would've done that sooner, looking back. I generally still feel like we're kind of understaffed, honestly, for the amount of stuff we're working on. The framework side, the open source side, I think being distracted by the opinions of people who don't even use the framework over the years, which doesn't happen much anymore over the past few years. But again, back in 2014 through 2016, it felt like there was this whole crew of PHP developers in the community that were very vocal about why they didn't like Laravel and what they think Laravel would do differently. There was a part of me that thought, well, maybe if I make these changes in Laravel or add these things to Laravel, these people will also love Laravel and become Laravel evangelists, and they'll finally like it. The hoop always moved. We put one thing in Laravel, well, I don't like this. Maybe if this changes, I'll use it then. Then we add that and then it just moves a little bit further. The carrot on a stick moves a little bit further away, and it was all just kind of a waste of time instead of just focusing on what made Laravel unique and productive and fun to use, and just focusing on that, which we've done, I think, the last several years. We focus on our core audience, and Adam at Tailwind calls it playing for your fans. Like, Slayer doesn't play Taylor Swift tunes. If you like Taylor Swift, that's great, but you should go to her concert, not come to the Slayer concert because this is where they play heavy metal. Sticking to what your fans like and playing your hits for the people that what you're doing, I think, is generally good. Matt Stauffer: That's good. I was just talking with some folks yesterday who are trying to learn more about the Laravel community, and they were asking, "What is the future of Laravel's growth?" And one of the things I said was, "I think that we've done a really effective job of getting the people who are actually looking for what Laravel offers, getting them to be aware of it within our world." I was like, "The answer is not now to get more market share in the PHP community and try to convince more PHP people to like us. The people who were sitting here shitting on Laravel are going to keep doing that, ongoing." Taylor Otwell: I think that job is honestly kind of done. I think Laravel has been successful in PHP and has sort of become the main- Matt Stauffer: Yes. Taylor Otwell: ... framework thing for most new projects, which is great. I totally agree. I don't feel compelled to win over non Laravel PHP people at this point. We're what, 12 years in? If it's not your thing by now, it's not going to be your thing. Matt Stauffer: And that's what I said. I was like, "What's to be done is what we've seen a little bit of happening lately, which is people outside of the Laravel in PHP ecosystem getting rid of some of their anti PHP hatred and just saying, 'Oh, regardless of what I think about PHP, this Laravel thing is really kind of amazing and productive.'" I was like, "More of that. More the JavaScript famous people or CSS famous people or Ruby famous people going, 'Wow, Laravel, okay.' That kind of thing." Taylor Otwell: Do you see? There's a lot of PHP in the world that has been written years ago, and maybe their teams already know PHP and they want to modernize their code base and it makes sense to stay on PHP because this is what all our programmers know- Matt Stauffer: Yes. Taylor Otwell: ... and we're going to move to Laravel, I think, is just the natural choice for a lot of companies. I think a lot of people come into the Laravel ecosystem that way these days, and will continue to do so, honestly, as their applications continue to age and they need to upgrade and stuff like that. Matt Stauffer: We have that all the time. I would say the number of clients that we have that are on a hand rolled vanilla PHP system and either come to us and saying, "Hey, can you write this Laravel?" Or more often, "Hey, we knew Laravel was the thing, we started rewriting it in Laravel and we need you help your help doing it right." They already made the decision. They already taught themselves Laravel, they already came in, but they're like, "We got stuck here," or, "we weren't sure what to do." Not even, "We don't know how to do this in Laravel," but, "we're not sure the idiomatic Laravel way that we were supposed to do it." And so, we come in and we basically help them get set up in the Laravel world, but they already made the decision. They already knew about Laravel. They already decided Laravel. That's already been set. My biggest regret in Tighten was not being involved in the nitty gritty of running the company earlier. One of the things that when Dan and I started the company together was he was a little bit tired of keeping up on tech and I was a little bit tired of selling to people. I'd been a freelancer. I was like, I don't want to do this anymore. I went head down on tech and he went head down and running the company, which is the right decision. I think that once we got bigger, probably 10 plus people, I think the appropriate thing for me to do, because I'm very good delegator, was to delegate some of the leadership in the technical space earlier than I did. I've done a great job of delegating it. Now, Keith Damiani is effectively acting as a CTO, he's Director of Engineering. But I did that later than I should have. What I should have done was delegate that earlier and get involved in contracts and finances and business development, all that stuff, earlier than I did. I only really dug into that stuff over the last year and a half. I feel so much better with my role in the company and my relationship with Dan and everything like that now that I feel like I know everything that's going on. I know how bookkeeping works, I know how our contracting processes work. I'm involved in every aspect of business development. Dan took a sabbatical and I just ran the company when Dan took a sabbatical, and I felt fine. That's something where for the first 10 years of the company, I was just sort of like, all I do is tech, la, la, la, right? And so if I didn't like how something was going, I wouldn't be like, "I know what's happening and this is the issue," I'd be like, "Eh, Dan, can you handle this?" He was the same way for me for a technical perspective, so it's not like I was unevenly burdening him, but I think it's from me knowing what I want from the company, I think my relationship with the company would've been much better had I gotten involved at that really nitty gritty level a lot earlier. I thought that wasn't my type of thing. I thought, oh, well, I'm not a sales guy. Turns out I love sales. I love talking to people who have a problem and figuring out how we can solve it for them or figuring out if they should go somewhere else. I'm like, oh, I actually really like this. I just needed to give myself that space, so that's my biggest regret. Taylor Otwell: That's interesting. What do you think would've been better if you would've been involved? Just you would've had a better sense of what's going on at the company? What would've actually been better? Matt Stauffer: I think I would've had a better sense, but also there had been times where I smelled something was off, and I just kind of said, "Well, Dan's not saying anything about this, so it's fine." Then later I'd be like, "Oh, I knew something was off and I didn't say anything about it because I was just sticking my head in the sand, being the CTO." There was a time where our accountants were completely screwing anything over and needed to be fired. I had a sense something was off, but I was just like, "Well, they're the accountants and the accountants know things, so they're totally fine." Then once I actually dug into it, I was like, "No, the accountants are shitting the bed." I'm sorry I'm cussing so much this episode, everybody, sorry. The accountants are doing a terrible job. I was right, and my gut sense was right, but because I hadn't spent the time really digging in and knowing how the finances of a large company works, I was just like, well, I don't know. Maybe my gut sense is wrong. Then I dug in and learned how it works, and I was like, oh, this was a lot easier for me to understand than I thought, and I would've trusted my gut to say, "This is a problem and I need to handle it," quite a bit earlier, had I just been involved there. I would've been more connected, involved. I also think that Dan and I have been shifting our responsibilities a lot over the last year as I took over as CEO and stuff like that. I think the dynamics that led us to do that would've been apparent to me a lot more lot earlier. And so, it would've been a lot easier for us to figure out when it was time to make that shift. We just felt some pain and some friction as a result of it taking a while for me to figure that all out. In the end, we're good, but I do think that had I realized that that was what was needed earlier, I think a lot of friction, a lot of pain points, a lot of miscommunications, a lot of someone's doing one thing and should be doing something else, would've been better served. I do think that it's just one of those, I just drew a hard line in the sand where I don't do the business stuff, and I don't think that that served me well. Taylor Otwell: That's interesting. Matt Stauffer: Which is very interesting to me because the last topic, the spicy one, is Laravel and marriage, and I put LOL next to this one in the card because I'm divorced. So I don't know if y'all want to be listening to me, but one of the funniest things about my marriage story was that my ex and I both knew it wasn't working long, long, long, long, long before we got divorced. But because I was coming out of the church, I had been taught that the most important thing you do to protect your marriage is say, "Divorce is never an option, period. Divorce is never an option." No matter what went wrong, no matter how early it went wrong, I would go, fingers in the ears, "La, la, la, la, la. Divorce is not an option, so this problem is not a problem or this problem is fixable, right? No matter what, because we can't get divorced, so obviously we're going to be able to fix the thing." I feel like I'm seeing I have a trend there of, just in the past I would just say, "This can't be true, so I'm not even going to deal with it," or, "this can't be on my plate, so I'm not even going to interact with it." Now I'm just kind of like, there's no such thing. There's no hard lines like that in life. Sometimes you're going to have to take responsibility for something or an experience, a situation that you didn't want to have happen, and you just got to deal with that. Taylor Otwell: It's basically confronting fear. If you can maintain these sort of boundaries of things that are impossible or not options, it's easy to not be as scared by scarier options. Matt Stauffer: Ooh, yeah. Taylor Otwell: But sometimes scary options are the most freeing at the end, even though they're hard to go down. They're hard roads to go down, but they end up being the most beneficial. I'm not telling our listeners necessarily to do whatever, but sometimes I think we just put walls up to certain options and hide them in our mind as not being available options because they're scary and we don't know what's on the other side of that door, basically. Anyways. Matt Stauffer: No, that's a great point. You prefer the comfortable, even if it's uncomfortable, it's comfortable because you know what it is, versus- Taylor Otwell: At least I know. At least I have some sense of what my world will be like in that scenario. Matt Stauffer: That's a great point, especially as you get a little bit older, you get more and more settled in, things were turbulent before, but now I know where I am. And I might not like everything about where I am, but at least I know what it is. And are you saying in my thirties or my forties or my fifties I'm going to have to completely throw everything upside down? That's scary, like making big changes to your job or your career or your company or your relationship or whatever. I love that. That's a really good point. But this particular point, they didn't say anything other than Laravel and marriage, but I think one of the reasons they're bringing it up is because your marriage and your relationship is public and beautiful, and a lot of people are like, "You guys are so happy. You do these wonderful things together and you support each other and everything like that." Obviously it's not a PHP framework that got you there, but there is some element of how you handle your relationship and also what your position and role as a open source founder of things has enabled you to do in terms of having a relationship that maybe not everybody who has a traditional nine to five has been able to do. I don't know if this prompts anything for you, but as you hear someone saying, "Taylor, I see your relationship. I see it and I think there's something beautiful about it, and I want some of that." Is there any part of you that says, "Oh, there's a story I want to tell, there's any advice I want to give," or something you want to share about how Laravel has allowed you to be more present a dad and as a husband or anything like that that you could share with folks? Taylor Otwell: As far as marriage goes, I feel like I just got very lucky, in some sense. Abigail and I got married really young. I was 23 and she was 19. Matt Stauffer: Vegas. Taylor Otwell: It's just in a very true sense, we just did not know each other at all. Just because how can you at that age? You're just very young. You change a lot over the years. I think we just got lucky in the sense that we kind of changed in the same ways and headed the same direction the other person was heading, together. And in some sense, sort of grew up together. Transitioned from basically teenage and young adulthood to being an adult with kids. We grew up together and we made similar transitions personality wise, spirituality wise, what we'd like to do, just sort of went in the same direction. I consider that somewhat lucky because it definitely didn't have to go that way. I could have gone one direction as I got into my thirties and she could have grown a whole different direction into her thirties, and then we would actually have a legitimate issue, I think, where we're just not compatible people anymore. Matt Stauffer: Interesting. Taylor Otwell: I think we just were fortunate in that sense that we sort of grew in the same direction. I don't think that it was necessarily anything specific that either of us did. It just happened to work out that way. As far as kids, I think running Laravel has obviously afforded me some freedom to work at home and be present with the kids, especially during the summers when they're not in school and see them during the day, which is great. It's been like a family business, so it's given them something to like, "Oh yeah, Laravel is sort of our thing as a family and dad made it," but we all talk about it. I explained to them Laracon and what I'm going to talk about and what we're working on. It's been kind of a fun family business over the years, which has been really, really nice. Matt Stauffer: I really appreciate you sharing that about the ways you guys change over time. I'm engaged now, and one of the things that I've discovered that I didn't give space for in my first marriage was for the idea of compatibility. Very early on when we're having issues in the marriage, it was sort of like my ex would be like, "We're not compatible." Again, I was like, "La, la, la," fingers in ears, "we must be compatible because we're married and divorce is not an option." But this time around I'm just sort of like, yeah, no, she was right. You need to find people who you're compatible with. I do agree with that very strongly. However, I've heard so much from people who study relationships that no matter how compatible you are on day one, everybody's going to change throughout the span of a relationship and your willingness to not just say, "You're not who I married on day one," but instead say, "as you change, we are going to change. Maybe not in all the same ways, but we're at least going to be refalling in love and getting to know the person you're changing into." Hopefully you're also both changing in similar directions, to your point. But regardless if you're just saying, "I married this one person, this one person's who I wanted, you're not that person anymore, now we have a problem," even if you change in the same direction, you're being so stubborn and obstinate that you don't allow them to grow. I forget who it is that did these studies, but there's a lot of studies that said that really is a determining factor of longevity. One of the determining factors of longevity relationship is how much you're willing to allow that person to grow and shift, and how much the two of you are actually in a trusting connection with each other, shifting together. I've talked to several people I know who got divorced and reflected and said, "I changed in certain directions together with my partner in a way that I would not have if I were not in that partnership." They're not saying that was a bad thing, but they're just reflecting on the fact that you can see it, that in order to try and make a good and healthy partnership, you follow together so that you guys can kind of move in that direction. While you say lucky, and I'm sure there was luck there as well, I want to name that a lot of studies have shown that the work that you all did to grow together in those directions was a big factor of where you are today. To other folks, it doesn't seem to just be about finding the perfect person or getting lucky. A lot of it has to do with how you handle those shifts that naturally happen over the span of a relationship and a lifetime, right? Taylor Otwell: Yeah, being able to communicate, being able to compromise on differences were also hugely key, I think. Matt Stauffer: Well, I know we're over time, but to whoever asked that question, thank you for giving us that moment to jump into it. Taylor, we're at 43 minutes, so I think I should cut us off, but is there anything else you wanted to chat about today before we cut? Taylor Otwell: Well, on the Laracon front, we have Laracon Australia coming up next month. We have Laracon Europe in February. We are still selecting speakers for Laracon Europe, so if you haven't submitted your talk proposal, go ahead and submit that on laracon.eu. We've already chosen six or seven speakers, I think, that are up on the website, but we still have quite a few to select, so go ahead and do that. I think we're about 50% sold out on Laracon EU, also. Matt Stauffer: Nice. Taylor Otwell: If you are interested in getting a ticket, I would probably start thinking about that in the next few weeks. Matt Stauffer: And I'm very sad to say that Laracon AU is happening when I got my kids, and Laracon EU is happening when I'm getting married, so I'm not able to make either this year, but I've been to both in the past. Y'all, if you have not had a chance to go to one of those conferences and those are in your regional area, the benefit that comes from these in-person conferences, it's very, very, very difficult to communicate really effectively. People are like, "Oh, it's this many dollars or whatever, and all I'm going to do is listen to talks I can listen to elsewhere." Yes, the talks are great, but the value that comes as a programmer, as a member of a business, as a member of community, from being in the same physical space as these folks, is absolutely incredible. To put things in comparison, I just spent two or three times what Laracon EU charges to go to a business owner conference, because that's just what those conferences cost, and was really grateful in that moment for the work that Taylor and Laravel folks have put in to try and make these things affordable. So on the one hand, I know it feels very expensive. I remember the first conference I ever went to was LesCon run by the Les accounting folks. Taylor Otwell: Allen Branch. Matt Stauffer: Yeah, and I had just gotten to know those guys, and I was like, "Guys, it's a thousand dollars. I don't know if I can afford this." They're like, "Matt," gently, they're like, "this is three times cheaper than anything else in the industry. Trust me, it's going to be worth it." The relationships I made at that conference are still following me today, are still impactful in who I know. I met Josh, the guy behind that accounting tool. I met Robbie Russell behind, Oh My Zsh. I met all these people who I'm still in really great relationship with and people who've been really influential in my life. That happens with every Laracon, too. Every time I go to Laracon, I make new connections. That happened this time. I've been to, I don't even know how many at this point, and I still am like, wow, the people I talked to, the connections I made here, business relationships, friend relationships. I just really want to hype it up to you all. If you are on the fence and you are considering going to one of these conferences, not only are they all great, but I can specifically name that EU and AU are just a fantastic time. If they're near you, you should go. Make it happen. If you need any more motivation, hit me up on Twitter and I will tell you why it's so great. But seriously, all these things are amazing and I'm jealous that I'm not going to be there. Taylor Otwell: Yeah, we'll miss you, but congrats. Matt Stauffer: Thank you. Right, it's for good reasons. I can understand this, so. All right, well, thank you all so much for hanging out with us on this episode four of season six where we did not jump the shark, but we did have some great conversations and we will see you all next time. Taylor Otwell: See you.