In this episode of the Business of Laravel Podcast, Matt Stauffer sits down with Jon Behr, VP of Engineering at FM, to discuss his journey into the company and FM's use of Laravel. FM operates three major brands—Musicbed, Film Supply, and Stills—which license music, provide film clips, and sell premium stock photography. John shares insights into the ground-up rewrite of the Musicbed app using Laravel, highlighting the importance of choosing "boring technology" to ensure stability. They also explore topics like scalability, clear communication within engineering teams, and the intricacies of hiring and firing developers.
- Matt Stauffer Twitter
- Tighten Website
- Jon Behr Twitter
- Jon Behr LinkedIn
- FM Website
- Musicbed
- Filmsupply
- Choose Boring Technology Blog Post
- Becoming an Effective Software Engineering Manager Book
- Radical Candor Book
- FM Careers Page
-----
Editing and transcription sponsored by Tighten.
Editing and transcription sponsored by Tighten.
Creators & Guests
What is The Business of Laravel?
Short, powerful interviews with business leaders working with and within the Laravel ecosystem--about business, tech, and more! Hosted by Matt Stauffer.
Matt Stauffer:
Well, hey everybody, welcome back to the Business of Laravel podcast where I talk to business leaders who are working in and with Laravel. My guest today is Jon Behr, the VP of Engineering at FM. Jon, would you kind of say hi to the people, tell everybody, tell us a little bit about yourself and talk about FM. What does the relationship between FM and Laravel look like, and what's the story of the company and your relationship with it?
Jon Behr:
Sure, thanks for having me on the podcast Matt. So this is a little bit of a convoluted and lengthy story.
Matt Stauffer:
Love it.
Jon Behr:
I got back about 10 years or so and I had just started a Laravel consultancy agency in the UK and FM at that time was just one company called Musicbed and Musicbed had a legacy app which was... If you can imagine the worst spaghetti PHP code, no framework, SQL injection all over the place, this was like a textbook case of that. Laravel I think was on version 4 at the time and I basically was brought in to rewrite the app from scratch. Complete, rewrite the entire database structure, everything.
And this was one of our, I think it was maybe our second or third big project at the agency at the time. And so that took about six months and Musicbed at the time kind of grew over time and we then had, brought more contractors into metal. They started subcontracting to Musicbed and this relationship continued for a few years.
And then about three years ago, so I was chatting with the CEO and he said to me, "Hey Jon, are you interested in coming in full time?" and it took a bit of back and forth and I'd kind of had enough of agency life at that point in time and it just made sense. So I joined as the VP of Engineering. It was a good time to join, I think in a lot of respects, the engineering team was a little bit deflated at the time. They'd kind of gone through some big changes internally. So I had to kind of rebuild the team, not completely from scratch, but we had lost a few engineers just before I joined and just after. Bring some stability to the team and kind of go from there.
So I guess your question is, well, what does FM and Musicbed do? So there's three main brands at the moment. The first one is Musicbed, which essentially licenses music to the creative industry. So if you think about an advert that needs a backing track or your podcast may need some intro music or maybe somebody's making a film and they need some atmospheric music or wedding video, anything along those lines. And so we have a roster of really excellent musicians that provide music and we then sell that music for them. So it's kind of like a two-sided marketplace kind of deal. We work very much at the premium end of the marketplace. So a lot of our content goes to Nike adverts or movies that are on Prime Video, NFL, Apple. We've been placed with some really big clients.
The second brand is kind of in the same industry. It's called Film Supply and basically it's film clips that are five to 15 seconds long. Most of them don't have audio.
And again, it's somebody who wants to create an advert and needs a clip of a car racing through the desert. A lion stalking its prey, something along those lines.
Matt Stauffer:
Right.
Jon Behr:
And so they could go out and shoot this themselves, but of course then they have to hire a film crew, costs a lot of production money, or they can just license it from film supply. And then the third brand, which is probably something people are more familiar with, is called Stills and stills is I'm going to use the word stock photography like Shutter Stock. It's the same kind of thing. We have photographers upload the images or photos and we sell it for them But it's not your typical stock photography. So again, it's very much at the premium end high end of the marketplace and you wouldn't find a stock photo in our catalog.
So there's about 100 people working at FM. The engineering team is completely remote. So North America, South America, EU, UK, and we work across multiple time zones.
Matt Stauffer:
That's a lot, man. That's a big deal. So first of all, thank you. And congratulations on kind of the progression. I've known you since before you worked with FM at all. And so it's just kind of been fun to watch you step into this role. How many people are in the engineering team at this point?
Jon Behr:
So it varies a little bit because we sometimes bring in contractors for lengthy periods of time depending on what's going on. So it's anywhere between let's say 16 and 20 engineers.
Matt Stauffer:
Okay, got it. And so, one of the first questions I'd like to ask people is in what way is Laravel involved in your business? And so what you mentioned was kind of Musicbed was a old school app and you were brought on to do a ground up rewrite. And I can say, you know, you, you know, this is someone who's been a consultancy guy at some point, ground up rewrites are almost never successful. And yet you were able to do one into a new tech stack. And the thing is super, super successful. obviously this is not a deeply technical podcast, right? This is more about business.
But one of the targets, and I told you this and I told all my guests this, one of the targets to this is high level CTOs who are CTOs of a larger organization or VPs of engineering where they're not on the ground making the decisions, but they do have to think about like the higher level technical direction. And one of the questions very commonly is what tech stack should we use? Should we do a ground up rewrite? They're not asking the question of what package should we use that little stuff, but these big things are for them.
Can you kind of share a little bit about your thinking having done it before of, you know, what helps you decide when to do a ground up rewrite or not? And if you're going to do it, are there any, again, not little nitty technical, but any kind of big directions like do this, don't do this if you're doing a ground up rewrite.
Jon Behr:
Yep. So I think at that point in time, there was no choice but to do a rewrite just because of the state of the application and the state of the database. It was not scalable, but, you know, at all based on where it was. And that's totally fine. It was, you know, kind of proving the concept that the business works. It did what it was meant to do.
But in order for the business to really get to the next level, it needed a platform that could get there. I think at that point in time, I don't think Laravel would have been kind of a natural choice. It didn't have the market respect that it has now. This was really, really early days. 2013, somewhere around there. So it really didn't have the buy -in that it has now. And that wasn't my choice.
Matt Stauffer:
Very early. Yeah.
Jon Behr:
It was kind of, I think at that time there were maybe four or five people in the company that brought on someone to kind of run product and he had made the decision, you know Laravel looks like it's an up and coming thing. There's a lot of momentum behind it. It kind of makes sense to try it. And I think to a large extent, a lot of credit needs to be given to him at that point because it was a prescient decision to make.
Having said that, we really haven't written or rewritten a lot during our time, especially on the back end. I think it's fair to say the front end changes a lot more than the back end does. So we've done a few rewrites on our front end. The front end react wasn't even out at that time. So it was an angular front end. And my sympathies for the guys that had to work on that. But then we converted that to React.
For example and then our newer our apps we are using next.js The funny thing is is the same code base that we used in Laravel 4 is the same code base that we're using now It has not been rewritten. Yes. It's been modernized. Yes. We've added static type hinting and of course we've evolved from PHP 5 I think maybe at that time and it's on PHP 11, or Laravel 11 now and so PHP 8.3. So we've kind of upgraded it but some of the original code which I wrote whatever 10 years ago is still in the code base and I think that's kind of testament to some extent to PHP but a lot to Laravel because you know if you stick to the conventions if you follow kind of a pre-standardized way of writing code, it's going to stand the test of time.
You'll naturally find edge cases that need optimization or being split off maybe to a microservice or add a caching layer or whatever. But really, our philosophy, one of our guiding philosophies as an engineering team is choose boring technology. Like there's this, what's the guy's name? Dan McKinley
I think, and he I think was one of the first tech guys, I think it was at Reddit at the time. And there's a blog post out there, Choose Boring Technology. And it really changed the way I think about things and the way we approach things as an engineering team, because every new piece of technology or everything you rewrite is just going to occupy more mental space, more context switching,
and it's like you choose something boring, you've got the domain knowledge, you understand how it works, what the drawbacks are and unless you are... there's a really really good business reason. My philosophy is just keep it boring, keep it simple.
Matt Stauffer:
I love that. And I mean, I've talked to with previous episodes of the podcast about, also in the talk I gave at Laravel Live UK, your conference about, you know, there's a lot of things we have to control for when it comes to people's influence. There's sometimes the people is the product team, or sometimes the people are the owners. But some of the people we have to control for are us as developers because we get shiny object syndrome and we always want to bring in the latest greatest. Obviously you've spoken to don't always just use what's new and sexy.
One of the things I was going to ask you about is that a lot of times we get folks saying, oh well, the way you all talk about building Laravel apps is fine for small stuff. And it's always this kind of like pat on the head, like, yeah, whatever. But if you're going to build anything big that's going to last, you need to do all of this premature optimization and structures and stuff like that. Do you have any thoughts about that? Is there things where you're like, you know what, there's certain aspects of how to write big scalable apps that you really have to do this architecture upfront?
Or is more of it stuff you're able to respond to as the problems pop up?
Jon Behr:
So I think just in general, think it's complete nonsense that Laravel can't handle big scale kind of stuff. We're, like, I don't know where this stands in the scale of things, but we're handling 220 million requests per month on our tech stack. And that's just Laravel, hitting Laravel endpoints. So, and just people to understand, Laravel basically runs our API and then we have front end apps.
So that's not counting all the other requests, front-end requests and going straight to Cloudflare or CloudFront or anything along those lines. I think knowing when to optimize is possibly like if you had to ask me like what are the top three developer traits I'd say that's in one of my top three. Because it's something you can only learn through experience.
The domain knowledge and understanding the business that you're building a code base for. You start to learn over time where you need to build something that can handle scale or where it's fine to just put something into practice, see how it works and if it works fine you can optimize it as and when the time comes.
And this kind of happens all the time, this kind of iterative feedback thing. Like I can give an example, we built a reporting dashboard for our internal team and it ran off MySQL. And it's like, yes, it worked fine when we implemented it, but now that we've got hundreds of millions of records in our MySQL database, someone in the admin team runs a report and it takes three minutes for the report to run and the front end deadlocks completely because MySQL just grinds to a complete halt. And so you learn, okay, for that kind of stuff, let's put it in a replica database, and admin can then go completely separate. And then there's steps you can do beyond that. You can send it to BigQuery and run it off that instead. And these are the kind of things you learn over time with practice.
It's hard to know upfront sometimes what path you're meant to take. And my viewpoint to the guys is, to the people on my team is just, let's put it in, let's see what happens, and the reality will actually show us what we're meant to do going forward.
Matt Stauffer:
Yeah.
Jonny Behr:
I've fallen into this trap so many times, and I think it's such an easy trap to fall into as a developer, in that you want to build the perfect solution for all scenarios. And it's the wrong approach to take when you're thinking of things from a business perspective, because a business perspective is not that perspective. Business perspective is making sure the work that you do is the most efficient and effective thing in order for the business to thrive in the short term, medium term, and long term.
Matt Stauffer:
That's great. I mean, short-term, medium-term, long-term really kind of points out the fact that if you spend three years building a thing and not making money and whatever and then you know, the thing that you're building has changed three times along the way. You know like versus if you get something out there that works and accepts money and then it gets bigger and then you make the adaptation, adaptations and then it gets bigger and then you make it you know it shifts and it pivots. And I'm sure you know Musicbed was originally just Musicbed. It didn't used to be FM and at some point I don't know when, you know they made the switch out to add these other mediums.
Jon Behr:
Yep.
Matt Stauffer:
Do you, when they made the first pivot, when they said, okay, we're gonna add whether it was, you know, Filmsupply, assumed it was Filmsupply, it was second. Was that a big moment for you of, need to go head down for a couple of months and figure out what the, now the dual architecture is gonna look like? You know, do I refactor it to be the same app powering two or do I split it out and do we start a new one fresh, whatever? What was that kind of experience like for you?
Jon Behr:
So I think we were kind of fortunate in that it was decided really early on that Filmsupply was a completely separate brand. There was no parent company as such. The only thing in common was it was being run by the same people. But from a branding point of view, it was completely separate. I think that's the first thing. The second thing we were really fortunate about is that we understood the domain really well and we understood what pieces of technology we had to put in place in order to make Filmsupply work because we had already done it for Musicbed. Yes, the content is different. know, videos are huge, huge, huge files. Music is, you know, kind of just a couple of megs. So I think from a from a scaling the asset pipeline point of view that was a whole new challenge for us on Filmsupply, but other than that you know the way that users purchase a subscription or purchase content on the website was a solved issue for us and I'm not saying we could copy and paste it from one to the other but there was no like gotchas or things that we hadn't already solved for and I think you know there've been a couple of periods during the last 10 years that I've been involved, but for most of that we've had really really stable engineering teams. And I cannot kind of overstate the importance of having domain knowledge and stability in an engineering team. And for me that kind of environment pays dividends multiple times over.
Matt Stauffer:
So let's talk about engineering teams a little bit more, because obviously you've built this super productive development team that has been consistent over a decade here. I want to talk hiring in a second, but let's first talk about structure.
When thinking about an engineering team, there's so many different ways that people handle it. And the most common one that I see, and I don't think this is what you've done, is you've got one senior person, and in order to try and save money, the company has them hire 20 junior developers and just try to throw them in the fire or whatever. What is your kind of, if somebody were to try and build a 15 to 20 person, or even maybe five to 10 person engineering team, what are your kind of like, maybe not mantras, but what are your guides to here's the first and most important steps to structure it so that it's gonna last.
Jon Behr:
Yeah. So I think there's a couple of points to pick on here. First, I'll give a little bit of an overview as to how we structure our engineering department. In essence, at the moment, we're split into two separate teams and the teams are split according to brand. So there's one team that deals with MusicBed and another team that deals with Filmsupply and Stills. Each team has a product manager and an engineering manager. I think this is fairly typical. I don't think there's anything too atypical here. And then there'll be two to three backend engineers, two to three frontend engineers, QA and designer on each team. So somewhere between seven and 10 people on a team. I think anything bigger than that kind of gets too much.
So there's a separate product team, which is the product director and product owners. And there's kind of a separate engineering team, which is myself, the engineering managers and all the individual engineers. I think the part which is possibly a little bit unique for us is that our engineers are for the most part, mid-level, a few, but most of them are senior and have been around for a long time.
And we don't have many junior engineers at the moment. I think if I had to grow beyond this point, then my route would definitely be to hire more junior engineers. I think it's good for the team. I think it's good for senior engineers to mentor junior engineers. I think it's good for certain tasks to be done by junior engineers and not senior engineers. So there a lot of benefits to having juniors around. The benefits of having senior engineers is that they understand the domain well and one of, I think our key mantras is taking ownership of things and so we like I will not micromanage and my engineering managers will not micromanage at all. The kind of person that thrives at our in our engineering team is the kind of person that is proactive, takes ownership. If there's something on the backlist doesn't wait for on the backlog doesn't wait for somebody to say hey can you take that item? If a bug comes through through the arrow tracking whatever, doesn't wait for somebody to say can you go have a look at that? He's in first thing in the morning because of the time zones by the time you get in he's already said, "hey I picked up this and I think this is the solution to it." and to some extent I think this kind of mindset can be taught or can be demonstrated, I think to some extent it needs the right kind of person to thrive in that environment because not everybody's like that. And I'm not making any judgment calls here at all, but I think that's the kind of person that we're looking for that is willing to take ownership of their own career path and also how they work with us as a team.
Matt Stauffer:
So one of the things I really like about what you said there is that with respect to people having this problem, there's an incredible amount of technical leadership that make the decisions they make because they don't know what to do. And so they either look at what other people have done or they just kind of flail and say, well, maybe this is the right thing. And when someone says, you know, almost apologetically in order for us to do things the way we do it, we have to have people who work like this. We have to do this.
I'm not saying nobody's ever said that and been a jerk in doing it, but even if so, which I don't think is very often the case, you have to have an understanding and a vision for what your team operations are going to look like, what each person's interaction with the rest of the team, with their responsibilities that shows, hey, this is how I think it should happen in order to even say that in the first place. So I want to dive. I know I said we go to hiring. We'll go there in a second. I'm going to talk a little bit about what got you where you are today.
How did you develop? What is your background? What are your experiences? What are the books or videos, whatever? What has gotten you to the place where you are today where you know how to build this team and you know how to bring in people and say, this is the type of person I want working here and here's how I want them to interact with each other.
Jon Behr:
I think I have come from a very unusual path into tech as a whole, to be honest. My background isn't in tech. I was in investment banking, structured finance. That's what I had studied. That's what I'd done in my career for 10 years and only made a switch to tech possibly about 15 years ago.
I think the part that I've been really fortunate with is having amazing mentors throughout my career. Right from the first full-time job that I ever had through to when I emigrated over to London and even now the CEO of FM, Daniel. I think, you know, amongst all of them, I've been really fortunate and maybe it's not purely by luck because I place a huge premium on the people that I work with.
For me, as I've said, and I remember saying this right from my first job, the people that I work with is far more important than anything else that I do in the job. Yes, the pay needs to be acceptable and yes, you know, the work that the kind of work that you're doing needs to be important or work that you enjoy. So maybe there's a bit of being fortunate in it or maybe it's you know, possibly also choosing that, but finding people who have the same ideals as you, respect the same things, find the same things, you know, important that you find. And I think once you create that kind of circle around you, then the kind of environment that you want to create, I think, kind of naturally follows on from that. And yeah, I just for me, one of the key principles is making sure that your expectations are communicated and understood. And I think both of those are really important because I think a mistake that a lot of some people make is they know in their own minds what kind of environment they want or want or what kind of engineering team they want or how they want the tech stack to work. But they haven't necessarily communicated it well in the first instance. But in the second instance, it's one thing to communicate it. The second part, which is possibly something I've only learned more recently in my career, is making sure that the person you've communicated to has accepted it and understands it and that they can communicate it back to you. Once those expectations and that groundwork has been put in place, then there's transparency and clarity from everybody as to how we want things to be done and what we expect from you as a junior engineer, mid-level engineer, senior engineer, staff level engineer.
I think, you know, I think I probably to some extent naturally kind of had an intuition behind this. But then you read a book like Radical Candor by Kim Scott, which...
Matt Stauffer:
Third podcast episode of this in a row with somebody mentioning that. I was like, is he gonna say it? I think he's gonna say it.
Jon Behr:
Right, it doesn't surprise me at all because it just puts a framework in place and explains it in a language that makes complete sense. And it's like with that clarity and that candor, everything is just above board and everybody understands what needs to be done.
Matt Stauffer:
Yep. And I love that you brought it up just to be clear because as you were talking and I was like, yeah, it's, there's a difference between broadcasting an idea and communication, right? Communication, you know, so, so, well I communicated it and it's interesting. Cause one of the things that, the author of Radical Candor said was I actually wanted to call it. And, but she had another name that she wanted to call it, but she's like, I feel like people.
Jon Behr:
compassionate candor.
Matt Stauffer:
Yeah. And she's like, but I just felt like people would think it's too soft or whatever. So wanted to change it and one of the things that she said in the intro to like the later editions was I regret that because I've heard instances where tech bros would say, well, I'm being radically candid. And she's like, yeah, but you missed the part where you're actually caring about the other person and thinking about their response and everything. And so hearing you say that, I'm like, yeah, like...
You have to know people, have to understand people, you have to be able to read people, you have to pay attention to them, you have to consider that it's not just you, the leader on top, telling everybody, making decrees from on top of a mountain, right? But you actually kind of, it has to be a discourse, a communication. So I love hearing you say that.
Jon Behr:
Absolutely. Yep, yep. I totally agree with you. I think it's really easy to fall into that trap of, you say, you know, making announcements from the top of the mountain and expecting that people have actually heard and understood what you're talking about. So, yeah.
Matt Stauffer:
Got it. Okay, so I keep saying I want to go to hiring, so we're gonna go to hiring for a little bit. So there's kind of two sides of the hiring story. One of them is a lot of folks say, well, I don't know what it looks like for me to look for Laravel developers. And then a lot of folks say, well, I don't know what it's like for me to look for Laravel jobs. And I'm trying to get a narrative out to people saying like, hey, I have story after story after story of company finding incredible Laravel developers. And every time they look, they've got hundreds of applicants, all these wonderful people.
And yet also, I have all these Laravel developers being like, there's so many cool things I can do with Laravel. There's so many companies using Laravel. And so I kind of want to ask kind of for you, what has the process of hiring Laravel developers been like? Have you found it easy? Have you found it difficult to get really good Laravel developers? Are you hiring non-Laravel developers and training them to know Laravel? Like, what's it been like?
Jon Behr:
Yep. It's been at some points easy and at most points painful, to be honest.
Matt Stauffer:
Tell me more.
Jonny Behr:
And I don't think this is specifically a Laravel thing. I think it's, you know, if we're looking for a React engineer or Next.js or whatever it is, we kind of go through the same pain points.
Matt Stauffer:
Hiring stuff.
Jon Behr:
Yeah, it's really hard. to be honest, I'm not sure what the answer is. To give some color to that, would say, you if we put a job post on LaraJobs or on one of the other remote job working sites, we get somewhere between, say, let's just round it off and say 300 applications coming in, of which I would say 250 will get discarded without looking further than the cover letter because of whatever reasons.
So we left with 50 so that means I need to or the engineering manager or whoever else needs to read through 50 cvs and cover letters which takes time of which let's say 10 go through interview. Takes more time of which two or three make it to the next round it takes more time and yeah it is it just is a really painful process and like I've heard hire fast, people hire fast and fire fast or whatever. And I don't subscribe to that at all. I think hiring needs to be a really careful thought out process. I think if you've built a strong engineering culture, you need to do everything in your power to strengthen that culture every time you bring somebody on board. And kind of my hiring bar is every time I hire somebody, I want the average of the engineering team to go higher, not to go lower.
Yes, you need to take into account that somebody may be a junior engineer, so you may need to benchmark it amongst juniors. But for me, I need like, I do have high standards because I've worked so hard in building this amazing team.
And I don't take any credit for them being amazing because they really are all amazing individuals. And I owe it to them. I have a responsibility to them to bring other people on board that are going to work well with them.
Matt Stauffer:
Yeah, no, that makes sense. As you think about that kind of structure around like the quality of the people that you want to bring on, I don't know if you've had to, but for me, I've had to fire before.
And I can tell you right now it sucks. This idea of like hire fast, I'm like hiring fast means you have to be very comfortable to have made a mistake, which means first of all, from a legal perspective, many places, it's very difficult to fire people.
But from an interpersonal perspective, hiring somebody and training and onboarding them takes a lot of time and energy. So throwing that away sucks. But also there's a human being on the other side of this and that human being let go of some other job, let go of some other opportunities. And now all of a sudden we did a bad job of picking them to be the right fit for this. And now we're going to dump them, like the worst, the only one thing that's worse than firing someone is firing somebody soon after they started. You know, like that's like the worst thing to do. And so this idea of like hiring, and I'm like, no, no, that's not the solution. You know I mean?
Jon Behr:
Yeah, yeah, yeah. I do kind of think like if you firing somebody really soon after you hired them, then the onus is completely on you. And I'm not meaning you as in Matt, I'm just saying the person who hired them, because it means something is wrong in your process, in your hiring process. And so you need to go back and refactor that process to find out what went wrong. I'm not saying you're going to get it right every time because that's completely impossible. And I think
Matt Stauffer:
Yeah, yeah.
Jon Behr:
If you try to get it right every time, you'll probably never end up hiring anybody. But for me, that would, I think, be an opportunity for learning and saying, well, what did I do wrong?
Matt Stauffer:
What could I have done better? Yeah.
Jon Behr:
There's obviously something I missed in the process somewhere along the lines. I will say, though, in terms of firing somebody, it's like it's possibly the worst part of the job. But I would say that if it's reached the point of firing somebody, it shouldn't come to a surprise to either of you that it's reached that.
Matt Stauffer:
Yeah.
Jonny Behr:
And I think that's, you know, there's lots and lots of things you can do before it reaches that stage.
Matt Stauffer:
Yeah.
And I mean, it's interesting because the, you know, for me, we're not legally obligated to, but if somebody is going to get fired, unless it's like, we discovered they're stealing money or something like that, there's always going to be a performance improvement plan either by name or by, by token of like, we want you to stick around. We hired you because we see value in you. This particular aspect of your job is not working out. Can we give you a direction? And it's interesting because I see people on Twitter, almost always people who've been fired before and who have like a grudge against their previous company be like if you get a PIP it just means you're know you're just fired but not yet right or something like that PIP meaning performance improvement plan and as somebody who's given them before I'm like for me, a performance improvement plan is a plan to improve your performance, right? Like if I did all this work to find the right person, interview 500 people, you know, go through all those interviews, train you for all this time and things aren't working out. My desired solution is for things to work out. If that wasn't the case, I would just fire you right now. Right. And so I think I want to spread like the news to people that like your boss can come to you and say, I need to officially register that you need to do better. And here's what doing better looks like and can do it with love and grace and empathy and the desire for you to do those things and stick around, right? Like it's it's not that you know, yeah.
Jon Behr:
Yeah, I completely agree. And again, you know, it just comes back to setting clear expectations and being compassionate and not radical in terms of your candor around that. You know, just from personal experience, you know, we have put, you know, a handful of people through PIPs before and it's worked out, you know, completely fine. And they've stuck around and...
Matt Stauffer:
Love that.
Jon Behr:
We've said, you know, as you said, this is somewhere, this is an area that you need to work on. Here's how I can help you. You know, if you just throw it to somebody and say, go fix it, that's not an answer for anybody. Yes, they need to have the right mentality. Absolutely. They need to be, you know, open to it and willing to work with you. If you've done your hiring process right, then hopefully, you know, you've got the right person with the right mentality.
Matt Stauffer:
Yeah. We've had a couple different responses to PIPs and we can go up PIPs. We've had one person discovered through the PIP that the problem was not them. The problem was they wanted to be in a different industry and they had tried to get into tech and they really just wanted to to the other thing. They went and did that. We had one where it worked and it's great. They stuck around. We had one where somebody had internalized this idea that a PIP means you're fired. And so during the PIP, they went and found another job because they were like, well, I'm obviously, and I'm like, no man, you know, so again, I think that's maybe why I have like a personal desire for people to hear like, and that doesn't mean that people don't misuse PIPs, right? I think people's dislike of this idea is because there are large organizations and really unhealthy startups and stuff like that, that are doing PIPs in a bad way that are that's the source of their bad reputation. You know what I mean?
But my former employee and still friend, Dave Hicking, talks a lot about the idea of organizational scar tissue, where if one person does something wrong, you make a policy so nobody, and you just get more and more policies. But I also think we have cultural scar tissue from like the number of bad employers having done what is on its head, on its face, actually a good thing. But the bad employer kind of like taints it for us a little, you know?
Jon Behr:
Yep. Yep. I feel like, you know, looking back maybe five or 10 years ago, a lot of the culture, tech culture that was published and you know, were in blog posts all came from big tech. And the way in which you run a big tech team cannot be the same in which you run a smaller or mid-sized, you know, tech team. It just doesn't work.
Matt Stauffer:
Yeah.
Jon Behr:
You know, there's I know like Microsoft used to do stack ranking for example, which is just I mean...
Matt Stauffer:
Garbage.
Jonny Behr:
it's just disgusting on all levels and like for some reason, you know I spoke to a few you know, a few people who running small tech teams and they say oh yeah we do stack ranking and it's like they've got ten engineers and you do stack ranking It's like it just doesn't make any sense. And the same thing with PIPs. It's like yeah, I don't you know this guy isn't working out I've put him on a PIP and he'll be gone by the end of the month and it's like that is completely nonsensical.
Matt Stauffer:
Yeah. Yeah, for sure.
All right, so back to the actual topic. Thanks for letting me kind of go down that route for us a little bit. So we're kind of nearing wrapping up. I have a few wrap up questions. And one of them is if somebody wanted to have a role like yours in the Laravel world, they desire to eventually become a VP of engineering of a larger company. They wanted to do the type of work that you're doing in hiring or in terms of the teams you have or the architectures that you built. Is there one piece of advice or experience you'd recommend them to do or step you think they should take to help them get to where you are today?
Jon Behr:
Yeah. I think it's probably important at this point to lay out. And this is something I had to put some time and energy into understanding as well. There's actually two routes to go down. There's an individual contributor route and there is a management route. And a lot of engineers have a mistaken impression that thinking in order to progress their career, they have to go down the management route because that's the only way they get more recognition. They can manage people, their salary will increase and all the rest. And that is actually not, that's actually a specious argument. It is totally fine to, if you're more comfortable on the tech side of things and you don't want to be managing people and deciding on who gets a raise and who doesn't get a raise and liasing with the product team all the time.
that you can stay on the IC route, individual contributor route and still progress your career. That's totally feasible. And if you join a company, you should ask them for their career progression framework.
Matt Stauffer:
Yeah.
Jon Behr:
And I would strongly recommend putting companies that have separate tracks for management and for IC to be a favorite solution. If you feel like you like working with people more than you like the tech side, not to say that the tech isn't there to some extent, then you can consider looking at the management side of things. I don't think it's for everybody, to be honest.
Matt Stauffer:
Couldn't agree more, yeah.
Jon Behr:
I think a lot of people, especially, I'd say probably most engineers got into engineering because they like writing code. And I totally understand that because I've been there as well. I think you need to really want to be a manager of people to go down that route. And it brings a whole different bunch of problems and ways of thinking compared to being an individual contributor. There's some fantastic books on it. There's a book by James Stanier called Becoming an Effective Software Engineering Manager, which to me is probably the best book I've ever written on engineering, ever read on engineering management.
Matt Stauffer:
Wow, never even heard of it.
Jon Behr:
Yeah, fantastic book. It's really practical, goes through all the all everything from day one to doing reviews to one on ones, remuneration. And I would say have a read through that book and see that book would probably help you determine if you want to become an engineering manager or not.
Matt Stauffer:
Fantastic. And I really like that delineation because the most common time I'm having this conversation with folks, I'm saying, are you sure you want to start a company? Because there's all these things involved in starting a company that are not doing the thing you want to do. But this is the same thing at a smaller scale. Are you really sure you want to write less code and deal with people more? And that doesn't deal with people suggests that we're a whole bunch of, corner closet dorks, know, just kind of just want to code but like the actual domain of your day-to-day job as a manager as a VP, as a CTO, becomes less and less about code and more and more about interpersonal things not only interpersonal with your team of programmers but also interpersonal with product and with business and with customers and stuff like that. And if that sounds exciting for you great but if you're like but I want to get back to code the number of people who've moved into a senior leadership position who are kind of like in my you know my cohort of programmers from 10-15 years ago
who said, how do you find time to code? And I have to talk to them. like, do open source projects. I do blah, blah, blah. But like, it is the most common question I get before, how do you hire well? How do you do this, that, the other? The first thing is how do you find time to code? And so I think that's really great advice.
Jon Behr:
Yeah. Yeah. I would say that if somebody shows interest in wanting to become a manager, it's totally fine to give them the opportunity to try for six months or a year.
Matt Stauffer:
Yeah.
Jon Behr:
And if they don't like it and they want to go back to coding, they will be a better coder and a better team member for having tried to become a manager. Far better, because they'll have that experience. They'll have that understanding of the different responsibilities that you have as an engineering manager, how you interface with the rest of the company, how you interface with other people on your team as a manager. And if you don't like it, that's totally fine. You gave it a try and there's absolutely no downside to doing that.
Matt Stauffer:
That's really brilliant because like you said, if you don't like it, then you know, you know, you're kind of more settled and also you're probably you have a better working relationship with the managers in the future because you've been there and you understand what they're going through.
Jon Behr:
Exactly.
Matt Stauffer:
So I love that. Wish we had more time to talk about all of these as always. Okay, so three last questions. Number one, are you hiring or will you be in the near future? Okay.
Jon Behr:
We're not at the moment. Yeah, unfortunately not at the moment. I will say that may change in the not too distant future, but at the moment we're not hiring on the front end or the back end.
Matt Stauffer:
Okay, if somebody wants to keep up, if one day they want to work for Jon and they want to work for FM, where do they go? They follow you on Twitter, do you guys have a careers page?
Jon Behr:
Yep, we do have a careers page and they're more than welcome to connect with me on LinkedIn or Twitter. There's a number of engineers who I've met over the years, opportunity didn't work out at the time. I stayed in touch with them and they ended up either come joining us full time or doing contract role with us for a couple of months. So it does happen.
Matt Stauffer:
Love it.
Jon Behr:
My advice to people looking for jobs, I think more than anything is just network as much as you can and not in an obnoxious, over-the top kind of way. Just keep in touch with people, drop them a line every now and again. Totally fine.
Matt Stauffer:
Yeah, just build relationships. Yeah. Love that. Second to last question. Is there anything you either want to plug like promote or is there anything that you wish we had talked about that we didn't get a chance to talk about today?
Jon Behr:
Gosh, I've been in the Laravel community for a long, long time and I'm not really the kind of person that plugs a lot of things all the time or that often. I'd say most people probably don't even know who I am in the Laravel community other than the fact that I do Laravel Live UK.
So I'd say if you are in the UK or Europe and you want to come to an awesome conference, we'll be having it again in June of next year.
Matt Stauffer:
Definitely would recommend it. Okay, and the last thing is, if FM came through and I don't know whether you have any equity in FM, but let's just imagine a world in which because of the work you've done for FM, somebody handed you $100 million. What do you do tomorrow?
Jon Behr:
So.
Matt Stauffer:
Deep sigh.
Jonny Behr:
Yeah, think the reality of situations is very different to how people imagine it in their mind. And you'll often see like people saying, oh if I had to see somebody getting mugged in the street, I would definitely jump in and help them out or whatever. And the reality is, well, actually you did. Funny story, that.
Matt Stauffer:
Yep, and I have a bone spur in my jaw to prove it for the rest of my life.
Jon Behr:
I think probably 99 % of people wouldn't, you know, they'd freeze on the spot. I think, you people think, they have all these imaginations of what would happen if they won the lottery or a hundred million dollars or whatever. I think if that had to happen to me, I would take out a sum, let's say a million dollars, and I'd put the rest away for a year and say, I don't want to decide this now.
I'll take a year and think about what I want to do with it. I mean, I think, you know, the probably the typical, the typical answer would be, you know, I want to help people in some way. And I think I would, but I think there, there are lots of ways to deploy money and time that empower people and really can really make a change to people's lives.
And I, to be honest, I can't think of a better legacy than making a difference in people's lives in a positive way. Not necessarily just amongst your family and close people, but people that you've never met that because of circumstances, because of where they've been born, because of whatever unfortunate circumstances in their life, they haven't had the opportunity could really kind of have a multiplier effect on themselves, their families, their communities. And I think that's the kind of opportunities which I would look to make a difference in.
Matt Stauffer:
I really appreciate the diversity of answers from people because some folks they're like, it's all about what they're going to do personally, which is fine. And some people it's all about what they're going to do professionally, which is also fine. So you gave me a little bit more of a professional direction. Let's talk personally, just real quick. Where's the first trip you take? Where's what's the first chateau you stay at? Or what is the first experience you do? Or what is this first thing you start, you know, like from a personal perspective?
Jon Behr:
Hahaha
Matt Stauffer:
You don't have any work responsibilities. Let's say you take a year before you figure out your next thing. Where are you? What's the first thing you're just like, I can't wait to do that.
Jon Behr:
Yep. I would get a camper van and travel around the US.
Matt Stauffer:
Okay.
Jon Behr:
I've done a fair amount of traveling around the US and I've done various overlanding trips before but I think America is just made for that kind of traveling. I think my wife and kids would absolutely love it. So go see the wild areas of America.
Matt Stauffer:
Love that.
Jon Behr:
Canada I think would be amazing.
Matt Stauffer:
That sounds awesome. I love that. Yeah. I've been talking with my wife about one day, maybe renting an RV or getting an overlanding truck set or something like that and just disappearing for a month or something. That's awesome.
Jon Behr:
Yep. Yep. That's the dream.
Matt Stauffer:
well, Jon, obviously every person who listened to this podcast fell in love with you and is so excited to learn more about you in the future and everything like that. If they want to keep up with you, what is the best place you mentioned LinkedIn, you mentioned Twitter. Is that the kind of the best way for people to keep up with what you're up to? Okay.
Jon Behr:
Yep, those two are the best, So add @jontybehr on Twitter and LinkedIn, just search for my name and hopefully it comes up.
Matt Stauffer:
Okay. Yeah, and we'll have links in the show notes as always. Well, Jon, I mean, we've been friends for a long time right now. It's really nice this year to have been able to kind of see you in person at Laravel Live UK and to be able to have you on the podcast right now. And I just want to say thank you so much for your time and your energy and your excitement and sharing your wisdom with us. It's really great having you on. Once again, this is one of these where I'm like, we could talk for three more hours, but even in 45 minutes, I feel like we got a lot of good stuff here. So thank you for hanging out today.
Jon Behr:
Yeah. Thank you for having me on and I don't know if this gets said enough, but thank you for everything you do for the Laravel community.
Matt Stauffer:
Thanks man.
Jonny Behr:
Yeah. I hope you know how much everybody appreciates it.
Matt Stauffer:
Really appreciate that a lot. I just feel all good about myself. All right. Well, thank you, Jon. And to the rest of you, thank you so much for hanging out with us today and we'll see you next time.
Jon Behr:
You bet.