Continuous Deployment and Continuous People Growth | Greg Skerman, DoT at iseekplant

Matt Stauffer Co-Founder & Chief Executive Officer

Aug 6

In this episode of the Business of Laravel podcast, Matt Stauffer interviews Greg Skerman, Director of Technology at iseekplant, Australia’s leading online construction marketplace. They discuss Greg’s role, the benefits and challenges of a service-oriented architecture, and working with non-technical stakeholders. Greg emphasizes the importance of scaling people alongside technology, the value of experimentation, and the ability to swiftly revert changes. He highlights the advantages of frequent deployments, such as risk mitigation and quicker rollbacks, and their positive impact on staff retention. Greg also offers advice for aspiring leaders, stressing the importance of soft skills, openness to different approaches, and engaging with the community and mentors for career growth.

Transcript

Matt Stauffer: Hey, and welcome back to the Business of Laravel podcast where I talk with leaders in the Laravel industry and also folks who are working together with Laravel folks. So if it's people who are using Laravel in their company or their company is targeting the Laravel world.

Today, I've got Greg joining me. Greg, could you introduce yourself and talk a little bit about who you are, what your background is, and then kind of what company you're working at right now and what Laravel looks like at your company right now?

Greg Skerman: Hi, I'm Greg Skerman. I'm the Director of Technology at iseekplant, which is Australia's largest online construction marketplace. I have been working with Laravel now for probably going on 10 years.

We're a small team based in Brisbane, Australia, and doing some really, really cool things in and around the construction industry, which I know doesn't sound super sexy from the outside, but it's a really deeply challenging space to operate in. So yeah, excited to have a chat. Thanks for having me on.

Matt Stauffer: Yeah, of course. And Brisbane, for those who don't know, is where Laracon Australia is going to be. So we're going to be in your stomping grounds. Are you from Brisbane originally or are you just living there now?

Greg Skerman: It sure is. Yeah, no, I was born and raised. I did a brief stint. Well, I wouldn't say brief. I spent my teenage years in a country town about 100 kilometers away from here. My parents had a small retail business that they moved out there for. But yeah, born in Brisbane, returned to Brisbane after I graduated high school, and have lived here ever since.

Matt Stauffer: Okay, so I am in a Telegram chat right now with all the Laracon Australia speakers and the majority of them are Australian and every time I spend some time in the culture of another country I realize both the things that are extremely similar and the things that people just say casually that mean absolutely nothing to me. Then I know as Americans one thing we're always casually referencing a city or a culture or an area of the country that means something to us it's like shorthand and everyone else is like I don't know what you just made that reference to Baltimore. I don't know what that means. And for us, it's like, well, you know, Baltimore.

So what I know this is not the focus of the podcast, but I've got to ask you, as everyone's talking about, you know, Brizzy and all kind of stuff and like, where does Brisbane fit within the world of Australia relative to Sydney and other kind of like larger cities and relative to other smaller cities? Like, you know, if someone said I'm from Sydney and I'm moving to Brisbane or I'm from a country town, I'm moving to Brisbane or where should I move? You know, how does Brisbane slot in there?

Greg Skerman: Yeah, I think from memory I think Brisbane is the third largest. I'd have to check on Wikipedia to be 100 % sure. But I think it's the third largest by population in Australia. It's one of the fastest-growing cities in Australia. It's like a lot of cities in Brisbane, in Australia rather, it's sort of on the water. So there's a big river that runs through the middle of it, which has featured prominently in Michael's marketing for...

Matt Stauffer: Okay.

Greg Skerman: For Laracon. It's I think geographically a pretty large city so it's very sprawled out so there's the central business district and then there's sort of suburbs and it more or less bleeds into a couple of other smaller satellite cities so sort of Ipswich to the west and the Gold Coast to the south and the Sunshine Coast to the north of us.

Matt Stauffer: Okay.

Greg Skerman: I really like it, I mean I think it's a pretty chilled-out sort of city, it's not super busy, people aren't always in a hurry and...

I don't want to say rude, but I do find that the sort of larger country capitals where a lot of commerce goes on, tend to be very hustle and bustle, and Brisbane's pretty laid back and chilled. Really great climate. I mean, we have some very hot summers, but the climate's relatively mild.

We have wicked summer storms actually, so I hope when you're over here you get to experience one of those. They sort of turn up at about four...

Matt Stauffer: Yeah. Is it thunderstorms or what kind of...

Greg Skerman: Yeah, they turn up at about four o'clock in the afternoon. They look like the world's going to end and they go away by about five o'clock in the afternoon. If you see one, they're pretty thrilling. Wind, rain, hail, lightning, the whole lot. Which is the cost of living in a sort of subtropical temperate sort of latitude I guess. Yeah, it's really easy to get around to, like it's well transport connected. I was working with Michael and he was looking at bringing Laracon up here from Sydney and I think we had a conversation just, he was surprised at just how well connected the city is by public transport. So the location for Laracon AU is right in the middle of the city and there are river ferries that you can use to get across, it's well connected by trains. We're getting an Olympics in a few years so there's a lot of investment going into upgrading the infrastructure in the city which...

Matt Stauffer: That's exciting.

Greg Skerman: In some cases, it's all we needed. As a local, I'm very very pleased that that's happening. I saw that happen with some friends in Sydney for the 2000 Olympics and it's a great way to level the city up I think.

Matt Stauffer: Yeah, well, I love that. And I live in Atlanta, which, you know, like we had that same thing happen in the 1990s and everyone still talks about how you should have seen that area before the Olympics. So it's familiar.

Okay, so thank you for, you know, working with me here, even though I know that's not the primary focus. I do want to talk a little bit about your actual responsibilities. So you said Director of Technology at iseekplant.

Greg Skerman: Mmm hmmm.

Matt Stauffer: So what does your day-to-day job look like? How much are you in code, reviewing code, supervising folks? How much are you more like kind of doing C-suite conversations, like high, big thinking? Like, what do you actually do day-to-day?

Greg Skerman: Yeah, so there's a lot of all of that, I guess. As I mentioned before, we started recording. I'm not on the tools as much as I used to be. I came to management via an individual contributor path. I sort of...

Matt Stauffer: Mm-hmm.

Greg Skerman: Landed ever-increasing responsibilities just by being fractionally better than the people around me. So I mean I'm not by any stretch of the imagination a super skilled engineer and I sort of lucked my way in a lot of ways into my career path. So you know these days I think some of my colleagues would tell me that I know enough to be very dangerous when I open up PHP Storm.

Matt Stauffer: Yep, there's that level of leadership where they're like, do we want him to open PHP Storm?

Greg Skerman: So, you know, from a sort of day-to-day management point of view, I sort of have a relatively hands-off management philosophy and the sort of small leadership approach. I mean, I think I have a team of very, very skilled people.

And I have found through bitter lessons of experience over the past seven or eight years that it's often better to provide guidance and then just get out of people's ways and trust that they'll achieve what you want to achieve.

I don't think that you get, you know, the result might not look quite like what I would have done, but that doesn't matter as long as we have the outcome that we want. So there's high-level conversations, lots of white-boarding, lots of architectural discussions. We have our sort of architecture is a series of monolithic applications. So we sort of say it's service-oriented, it's definitely not micro-services, but we isolate business functions within full-stack applications that deal with a particular domain concern.

So we might have like an inventory service, which will have an administrative backend. It'll have an API that things can talk to it. It'll have its own database. And a lot of that is around being able to scale the team when we need to so that people aren't treading on each other's toes.

It also allows us to do some really cool things with experimentation. So when we introduced Inertia a few years ago, we sort of introduced it in one service. Have a look at what that's doing and then decide whether or not we spread it across all of the services or whether or not it becomes an artifact of the thing that we once played around with.

So that's really helpful. There are a lot of conversations with non-technical stakeholders in the business. The business, interestingly, doesn't have a technical co-founder. So I wouldn't say that I fill that role, but I definitely sort of guide the founders of the business around the technical strategies that we have in place, looking at things like feasibility, viability, cost.

I do a lot of vendor relationship management as well. So I'm not really selling the management life for people, but there is a lot of talking. So we have some key vendors. We work a lot with AWS. Work a lot with Twilio, those are probably our two very key vendor relationships so there are a lot of conversations with them about what's coming down the pipeline for them and you know how we can better leverage their services.

There's thankfully in my team not a lot of people management and that's more or less by design. So I think I often tell people that if you make me manage you, I'm going to be unhappy. I don't like telling people what to do. I don't like disciplining people. And we have a very good engineering culture. And I think the culture within the engineering team takes care of a lot of that for us. So we have no leaners. Everyone's a lifter. I mean, people have bad days or bad weeks. I think it tends to happen. You can't be 100% on all the time.

But generally speaking, everybody makes a really solid contribution, which is wonderful from a leadership point of view because that sort of yucky part of people management doesn't come up terribly often for me. There is a lot of code review as well. We, I guess, somewhat famously deploy very, very frequently upwards of 20 times per day being deployed directly into production.

There's a fairly sophisticated continuous deployment pipeline. So review is still a major part of what we do and part of being able to maintain that kind of deployment velocity involves being able to review quickly.

Anyone who can understand code and has an opinion on it will get in and have a look at what's going on and make sure that we're not doing silly things. So, yeah.

Matt Stauffer: Yeah. Okay, there are so many different directions we can go from there, but I think the first one I want to start with is you said there's not a technical co-founder, but you end up advising leadership on kind of the direction that things are going. One of the things I'm always curious to talk about is when I talk with folks in this podcast, they are either in leadership because they started leadership or they're in leadership because somebody else started a thing and they moved up into leadership or they were hired in leadership. And I found the dynamics of their relationship with Laravel and other tooling is different depending on which one they are.

So if someone said, well, I started this thing and I used Laravel to start this thing and now it's built up, that's one story, but that's not the story that you have, you know, because you weren't a co-founder.

Were you the one who brought Laravel to the company? And if so, could you talk a little bit about like, what was the process like of selling it to a company that had a different tech stack beforehand? Or if it was already there, did you have to kind of like, do you have to defend it at any time or anything?

Greg Skerman: Yeah, so luckily for me it was already there. When I took this role, I was in between jobs for a long time and I'm sort of at the point in my career where I can afford to be relatively picky about where I go when I do decide to move. I was looking for a Laravel job. At that time I was not interested in any other sort of tech stack.

The business was originally built by an agency, so the business hired an agency to build a typical index.php, search.php, pages.php kind of thing. And my predecessor introduced Laravel 4, I believe. It was fairly long in the tooth when I got there, so we were quite a way behind. And this was pre-Laravel shift, so upgrades were a shockingly bad thing.

Matt Stauffer: Yep, yep.

Greg Skerman: The biggest and most interesting challenge there was that when Laravel was installed, it was overlaid over a legacy database. So, you know, sort of Hungarian notation table names and column names and, you know, relationships were very, very difficult because it was not, it was very non-standard. And we dealt with that for quite a long time. It's a very large database.

Matt Stauffer: Mm-hmm.

Greg Skerman: It sort of spiders into all sorts of things. And I think largely because of the nature of porting the application from a legacy application to a Laravel application, there were a lot of sub-optimal decisions around how that was done. I think that's just inevitable when you run into a problem like that. So the biggest challenge was getting the business to buy-in to do what eventually amounted to a rewrite. It was a progressive rewrite, we did it sort of as a Strangler Vine sort of thing, it was hacked off one part of the domain at a time and re-implemented that functionality. That has been an ongoing process for at least the last four years.

We're still in the weeds on that and it may never get ultimately finished. It's probably 90 % of the way there and that's probably extracting enough value for us. I've been very lucky with the co-founders that I work with. They sort of recognize that this isn't their wheelhouse. So I have been very lucky in that there hasn't been a great deal of resistance or a great deal of need to defend the technical decisions. I think, you know, if Laravel wasn't as good at enabling us to do what we do, then there may have been, but as it stands, the sort of tech stack we have is so efficient at delivering value for us that that has never really come up. So yeah, I'm not sure if that maps to experiences that others have had. Yeah.

Matt Stauffer: Yeah, no, that's very helpful. Yeah. One of the things I talk about with people a lot is the need to build the architecture for your application. And just as a refresher, this podcast is not supposed to be about tech, it's supposed to be about business. But the thing is the people who are making business decisions about how to architect their team often have to think about tech a little bit. So the questions I'm asking you, technical, are trying to kind of touch into what decisions are higher level C -suite people having to make.

And one of them that comes up often is somebody's trying to make the sale to watch that we need to move to microservices, PHP is out of date, we need to do a Go microservice and there's this, that, and the other. And more likely than not, people have a pretty small number of people in their team and don't even understand why they need microservices in the first place.

Before we got on the call before we were recording, we started to have a little bit of conversation around, you know, like what Laravel does for you there and your service-oriented non-micro service thing.

Can you talk a little bit about that, you know, multiple monolith, you know, service-oriented space that you were talking about at the beginning of the episode?

Normally when people split stuff up in those different domains is because they have a whole team of people working on each of them. But I think that your team is smaller than that.

Can you talk a little bit about like what motivates the decision to extract a piece of, you know, code into an entirely separate code base? And what are the benefits and costs that come from an organizational perspective, not even necessarily a code perspective, organizationally, interpersonally, what are the benefits and costs that you get from moving one of those domains over to its own kind of standalone model?

Greg Skerman: Yeah, so I mean I think one of the things that a lot of people miss when they go to any kind of service-oriented approach is that it is not an architecture that is in service of a technical scaling goal. It's usually in service of a people scaling goal. I've heard...

Matt Stauffer: Say it again, man, I couldn't agree more. Keep going, but there.

Greg Skerman: I mean, I've heard it said before that really microservices are more or less a deployment strategy, more than an architectural strategy. And you have all of the problems that you have with an object-oriented application. You just then also introduce a network complexity to the mix. So there are definitely trade-offs in doing it. And for us, there were a few reasons for doing it.

One, we were going through some fairly aggressive scaling in terms of the size of the team and I find when you rapidly increase the size of the team and you don't necessarily allow the dynamics of that team to settle out it becomes very easy for people to tread on each other's toes.

So being able to have a degree of isolation allowed us to accelerate the team growth because we could sort of isolate, sort of say, for the next six weeks, you're over here. And as long as you agree to communicate with this team over here via this API contract that we've created, I don't care what you do. You just stay over in your little space. There are other advantages that we find, it's a very, very large code base. So it's, I think at the last count, it was something around 1.3 million lines of code.

Not including Vendor, not including test. So we're talking about the business code.

Matt Stauffer: A lot of code. Yeah.

Greg Skerman: Yeah. Which you wouldn't, if you went to our website, you wouldn't think that, but there are a lot of things that happen in the background, administrative tooling, and report generation. We have a data lake where we extract information from all of our databases and consolidate them all for business analysis and so on.

I think there does come a point where an application is too big to keep in your head. The whole thing is just so overwhelming. So the isolation kind of allows us to have applications that are small enough to reason about, which means that when we do need to make a change, we can sort of say, you know, and we do a relatively good job of mapping these applications to domain concerns. So we can sort of shortcut the conversation a little bit and go, well, that's a company's concern. So that's going to be the company's service. And you can kind of load that entire context into your head rather than trying to load what is a very, very large and complicated system into your head.

It does have some trade-offs, particularly when you find that a feature or a change has cross-domain, cross-cutting concerns, where it's not just companies, it's communications, or it's not just companies, it's also our rate request system that needs to get involved. And that does introduce some complexities. We find that when that happens a lot between sort of like a couplet of services. It probably is an indicator that there's a missing business concept in the middle that could wrap that up.

Yeah, I definitely would caution people against it, I think when people do go down the microservices, we sort of jokingly refer to our services as serverless microliths. They're kind of, they're not really microservices. They're not like a single function deployed to a Lambda.

And I think people do reach for that too often. They split too quickly. So we try and resist the urge to split. And we only split when there's like a very obvious need to do that because you do introduce this complexity around understanding how the whole thing sort of hangs together.

There are other advantages around things like, you know, deployments and isolating databases. It does give you the ability to scale your infrastructure. If you found that sort of one of these services, and we found this from time to time, one of these services is starting to overload the system.

Putting too much contention on a cache server or a database server, we can kind of independently scale that, which gives us like a fine grain cost control that we might not otherwise have because, you know, it usually is one service that's being sort of over utilized and it needs a bit of attention from an infrastructure point of view.

So there are definitely advantages there, but it is definitely a thing that you should do to proceed, but you should proceed with that with caution, I think. And I think when people think microservices, they go you know this is what Netflix does and you are not Netflix and if you are working for Netflix then great they've already solved all these problems and it's very very easy to say you know just deploy a single function to Lambda and everything will be great but they never tell you the risks and costs of

Matt Stauffer: Yep. Yep.

Greg Skerman: Of doing that.

The other advantage is, I think I touched on it, was the sort of ability to experiment. So we like experimenting, we like coming up with new ideas, and often we find that if an individual has an idea and that idea by its very nature needs to be propagated across the entire system, there can be a lot of resistance to doing that because you don't know whether the idea is going to be successful, you're doing a very very large technical lift. Having lots of isolated systems allows us to experiment with new concepts, new patterns, new tooling, you know, maybe you want to play around with DynamoDB for whatever reason, to scratch an intellectual itch or to see whether or not it would help with a particular scaling problem.

We can do that in isolation in one service and we get better buy-in that way because people aren't, you know, filled with the fear that they're going to trample across everything. We get to see how it's going to work in a very, very real application that's running in production with real users hitting it and then use the information we gather from that to decide do we just leave it there as an artifact or perhaps bad decision that we once made or do we go all in?

And that's what happened with Inertia for us. We looked at Inertia, we thought this is great. I mean, we're a sort of a Laravel React Inertia Tailwind business. We were using React in a very awful, awful way initially. It was a bootstrapping React inside of jQuery.

Matt Stauffer: Oh jeez.

Greg Skerman: That's a whole thing. This is what you do when you don't know what you're doing. So we thought Inertia might be a really nice solution for us on that, but we didn't just go all in with dozens of user interfaces moving across to Inertia, because we just weren't sure.

So we implemented it in one service, really, really liked the way that it helped our workflow, and then collectively decided, yeah, this is the way forward. A counter-example of that in one of our services, we thought, let's try the sort of domain-driven Laravel, everything in its own folder kind of thing in one service, maybe that will help us in some way. And we decided that for us it didn't. So there's one of our services that's kind of built that way. And in some ways, we leave it there so that we can remind ourselves why we don't want to do it everywhere else.

Matt Stauffer: What I was gonna ask you, have you ever, and can you share if so, have you ever tried something that was so bad that not only did you not leave it there, you're actually like, we're gonna undo everything we just did because it's so bad?

Greg Skerman: Yeah, yeah, I mean, I'm a big fan of always making two-way decisions. I don't like walking through a decision that is irreversible. I'm a big proponent of working in small reversible steps. So when I mentioned that we sort of deploy upwards of 20 times per day, I mean, the deltas on those changes are usually, you know, 15, 20 lines of code. That's the sort of the size of the increment that the system is almost imperceptible how the changes are happening. They're definitely happening.

That sort of happens imperceptibly sort of commit to commit. And because of that, yeah, if we do run into a problem that we have an idea, we try something out, we go, this is not such a great idea, we're a handful of Git reverts away from removing that.

I can't think of a specific example. I think that tends to happen more when we're making architectural and design decisions around, you know, what sort of, what's the shape of this code or are we building something that's ergonomic and maintainable?

And I think in a small team, ergonomics are like critically important, which is why something like Laravel is just so good because there's been so much care and attention given to how it feels to use. Like things, it's kind of a bit naff to say, but things just tend to make sense. They just tend to work the way you think they should work. And we try very hard.

We're not as good as Taylor, but we try very, very hard to adopt that philosophy with what we're doing. And if we find that we're getting into a rabbit hole where things aren't feeling right, we'll often jettison that and try again.

Matt Stauffer: When you say ergonomics, I think I'm understanding you to mean developer experience.

Greg Skerman: Yeah, yeah, yeah.

Matt Stauffer: Okay, got it. I like that phrase. Ergonomics is a nice way to talk about it. Okay, so I'm trying to, again, like I said, there's just so many things you talk about that I wanna kinda go down those routes. I think that the continuous deployment is one where, again, while it's an extremely technical concept, it requires really significant business buy-in.

We have so many clients who go two, three, five, 10 weeks between deploys. And we come to them, we say, you know, like when you do that, there are just myriad problems you're introducing into your development process. You're slowing things down. You're introducing conflicts, stuff like that. Like, yeah, but how do we, you know, how do we make it shorter? And we're able to usually help them come down to a couple of days or maybe at most like a couple of weeks in terms of their timelines.

But very few people who don't have the initial intention of their own to deploy that frequently or ever get down to more than one time a day. And I'm always pushing them in that direction.

How are you able to make the balance between the technical value of shipping all the time and the business reality of, well, now we got to do feature flags or, you know, now we have to, you know, change the scope of our things. Like, how do you talk the business language around the value of and overcoming the costs of doing these more frequent deploys?

Greg Skerman: Yes, I mean this is a real challenge I find for technical people, speaking for myself here, but I have spoken to a lot of other people who are in the same boat, but technical people who move into management, is that a lot of what we do is just deeply, deeply counterintuitive.

Like it just doesn't, I mean, on the deployment side of things, it's like deployment is risky. Why would we want to do it more frequently? Because it's less risky to do it more frequently than it is to do it less frequently. But intuitively, that does not make sense. Like I can understand, I can empathize with people going, that's crazy. Like, you know, when we deploy every six months, we have to,

Matt Stauffer: Yep. Yep.

Greg Skerman: the team out for three days and deal with break fixes for a week on end, you know, why would you want to do that 20 times a day? It's like, well, because doing it 20 times per day actually mitigates that exact problem.

We didn't get to where we were in one step and this is an interesting conversation I have with people that I speak to off the back of my Laracon AU talk last year.

Obviously in a 30 minute talk, you don't have a lot of time, it's fairly reductive, so you just go for the headline items. We deploy this frequently. And people are like, that's crazy. It's like, well, we didn't get there all at once. So we were lucky enough to be on Laravel Forge early on, which gives you at least click to deploy, which is, I think is at least essential. If you can't just click a button and deploy your code, get to that point first. That I think is crucial. We sort of, I guess, boiled the frog on this. We sort of very, very slowly made it easier and easier and easier and easier to do.

And then we got to a point where I think once you can get to a point where you can continuously deploy daily, continuously deploying hourly, it sort of just collapses into that because you've solved all of the problems. I think that the key sort of pitch to the business on this risk of deployment aside, ease of rollback is definitely one of them because once you've got continuous deployment you also have the ability to roll back at will. So as soon as you notice there's a problem a rollback is instantaneous because you just Git revert, Git commit, pipeline runs and it's back to the state that it was in before you had a whoopsie.

Matt Stauffer: Yeah.

Greg Skerman: And having that then allows the team to be less risk-averse to change. So the team can take, you know, we very rarely have conversations around a change that we feel could be risky, because what's the worst thing that could possibly happen? We have a very small outage in one of our services for a couple of minutes while we wait for it to go back to where it was. So that's one thing. And then the business really likes the velocity of change that we can have.

There's a bit of a throwaway phrase that I used to use in meetings that we can have an idea in the morning and have it in production in the afternoon.

Matt Stauffer: Yeah. That's sexy.

Greg Skerman: And that is for a small team and a small business, that's a competitive advantage, right? If you have a competitor who has maybe toiled on a feature for weeks on end to get it out there and you can have it, they launch it and you can have a competitive like answer to that sort of in 24 hours. That's like, that gives you a capability that few have.

So yeah, when you're sort of having these conversations with people, yes, it's technical and it's, you know, these things aren't easy. I'm not sitting here saying that, you know, it's very, very easy to get continuous delivery or continuous deployment.

But really the conversation has to be around what is the competitive advantage for the business, you know, for being able to do this. Staff retention is another really big one too. Like people who, I think Charity Majors has said this a few times in her talk, I definitely mentioned it in my talk last year, is that once people have worked in this kind of way, once people have worked for a team that really performs well,

Matt Stauffer: Mm-hmm.

Greg Skerman: they will be very reluctant to work for a team that doesn't do these things. So, and because there are so few businesses, particularly in my corner of the world, that are working this way, it's attractive for talent and it's also a great way of retaining talent because, you know, who's going to want to go back to FTPing a folder to, you know, a shared server somewhere after they've experienced the fact that they can commit the code and then have their work running in production within a few minutes.

It is a journey. You do have to look at things like feature flagging. You do have to balance the sort of engineering decision, which is you kind of want to make deployment an engineering decision, but release still needs to be, in a lot of cases, a business decision because there's usually a marketing movement that like a marketing motion that exists when you're, particularly when you're doing large feature sets. And you need to align that. So you do need things like feature flags. There's definitely a trade-off there between deployment velocity and the sort of complexity of managing the release of a feature.

But a lot of that's a solved problem. Again, Laravel solves a lot of this for you. Things like Laravel Pennant. And if that's not good enough, there are plenty of free and relatively affordable tools out there for managed feature flagging and experimentation. And that's the other thing too, experimentation. I mean, once you can isolate a change into sort of two variants and then send half your traffic to one variant and half traffic to another variant, you can make decisions a lot faster because it's nearly impossible to know whether a feature is going to be successful until you try it.

And being able to A-B test or multivariant test a version of a feature to decide where to go next is incredibly powerful. You're not making these very long-term bets around, you know, we're going to deploy in six months' time, therefore we've got to fill six months of the schedule up, therefore we've got to decide everything today guaranteed you're gonna be wrong in more ways than one when you do that. And then you've wasted six months of a very expensive team's time on something that is less successful than you expected it to be.

Whereas if you put little tiny micro changes out and then A-B test between the two, that allows you to sort of sense the direction that you should possibly go in.

So yeah, there are definitely business trade-offs or advantages to business in doing that. The challenge for technical people is to keep the technical side of it out. So the advantage for you is that we have lower risk, we have more competitive advantage, and we can make smarter decisions by investing in these pipelines.

Matt Stauffer: That's cool. So when it comes to, and I didn't expect us to go down this direction so far, so apologies, but when it comes to this A-B testing, do you, at iseekplant, do you have your own internal framework or are you doing, because a lot of people I know who use A-B testing tools, it's because they're in something like WordPress or something where they're not in control. They can't just throw in a line of code that says 50 % of people get this, 50% or do you have your own internal metrics? Let's say you're gonna change how a checkout button works. Do you write a little bit of code and then say, now track the people who get one and people get other and see what their, you know, the amount of money that we convert on one versus the other and then you track that in your data lake and do it there? Or are you sending that all out to third-party services?

Greg Skerman: Yeah, we've done it a few ways. I think the most naive way that you can do this is that you have like an environment variable that switches a flag on or off. And that's the kind of way that you would have done it before Laravel Pennant turned up.

Laravel Pennant gives you the sort of all the lottery functions that allow you to say, you know, this user is going into, you know, this group, this user is going into this group, which will get you a reasonable way there. We use a tool at the moment called PostHog.

Matt Stauffer: Okay.

Greg Skerman: Which is sort of built as a product operating system. So it's not just feature flagging and experimentation. It's also got like a customer data platform and it's got product analytics and a whole bunch of other things around that. And most of that is sort of handled in the front end. So there are React libraries that we use to arrange that, but it kind of all more or less boils down to if the name of the feature is on, display this, else display this. And then the intricacies of deciding, you know, whether that flag is switched on or off is offloaded to a third-party service, which then, you know, thankfully does all of the student T-testing, and all of the statistical analysis that's required to know whether or not a particular feature is a winner or not.

Matt Stauffer: Yeah, okay, that makes a ton of sense. Because we've got 10 minutes left, I'm gonna start into some of the more traditional questions that we ask, even though I could go down this direction forever.

Greg Skerman: Yeah, go for it.

Matt Stauffer: You mentioned that you have gone from being an individual contributor programmer to entering a management role. And one of the things I always want to talk about in this podcast is what does it look like if somebody sees your level of leadership, your level of success, and they are a programmer and they want to get there? So whether it's someone who's a solo founder or someone like you who joined a company at a leadership level from having been a programmer if somebody wanted to follow in your footsteps, are there books, are there experiences, are there trainings, are there talks, are there articles, are there things that you could share with them? You say, this is what you need to do to kind of get to where I am today.

Greg Skerman: Yeah, and this is the thing that I wish someone had told me when I was coming up because I think there's a lot of...

Matt Stauffer: That's great.

Greg Skerman: People forget that leading people is a skill. They often promote people and expect them because, by virtue of being promoted, they'll be good at it. And the first few years of my leadership experience were not great. I was not a very good... And still don't really consider myself to be a fantastic people person. I think... engineering-type people are sort of wired to solve problems in a certain way and people don't risk like those solutions don't work with people.

I think a lot of the focus for me if I was to give advice to people, and I certainly do give advice to people on this, is that you really need to look at the soft skill side of things.

And you need to let go, I think, of the... I think we all have our sort of code babies, the things, you know, the ways that we like building things, the ways that we want something to look like when it's done, and you really need to get comfortable with letting that go because you're not writing it. It's not you that's doing it.

There's a really, really great book called Turn the Ship Around. I can't remember the author of it off the top of my head. It's a very, very easy book to read. It's about a US submarine commander who took a very underperforming submarine and turned it into the best crew in the Navy. And I think the model that he applied to that has sort of now been rolled out across the entire submarine fleet. And there are some very, very good things in that book from a management standpoint that I think are worth looking at. So one of them is getting the team comfortable with telling you what they're going to do rather than you telling them what they're going to do.

Put the team in charge. You act sort of like a backstop. So if someone's got a very silly idea or hasn't considered the risk, you can question them and sort of say, have you thought about what will happen if, as opposed to do this, don't do this, which it's very, very easy, I think, for programmers to think in terms of do this, don't do this, because that's like literally how we write code. If this is true, do it this way. It doesn't apply to people. And I think, you know, if there was one book, I would suggest that everybody, even if it's your contributors, I think should read it because you might be able to convince your boss if you're having a rough time of it...

Matt Stauffer: Need to give you a little bit of leadership opportunity.

Greg Skerman: that there is a way forward. But yeah, I also think too, one of the other things that I've learned over the last few years is that leadership is a choice. Leadership is not a role. The best leaders in businesses are the ones who are chosen by their teams. So if you have aspirations for being a leader, just start leading, just start going first. Start sort of wearing that hat. Because leadership takes all sorts of forms. It doesn't necessarily mean that you've got a fancy manager title and have positional power within an organization, which is not all it's cracked up to be and often not necessary.

So yeah, if people do aspire to lead or to have an impact in that space, I would just suggest people start doing it. And if you're in an organization that won't let you do that, you might be in the wrong organization.

Organizations should be breeding leaders. If they're keeping people down and keeping people in their place, then there are plenty of other places out there that will let you thrive.

Matt Stauffer: Yeah. I didn't intend to go about this, but I just remembered that when we were talking before you said something about, Laravel is the seventh, member of the team. And, it was just such a compelling thing that I realized that I wanted to talk about the role that that plays both for like a business decision of choosing to use Laravel, and also even just like the empowerment of the people working on the team. Can you talk cause you know, cause you were just talking right now about empowering, you know, the individual members and I'm realizing that you're like...

Greg Skerman: Yeah.

Matt Stauffer: Well, if my job is to build nitty gritty on-the-ground cues or build all these rote things or whatever, then I'm less empowered. That if my job is to give a feature definition and turn that feature the whole way to reality, you know, and I'm capable of doing it. So could you just talk a little bit about that idea about like what Laravel does specifically for you and your team to allow you to empower people and also to, what impact it has on team size and team makeup and everything using Laravel versus something else?

Greg Skerman: Yeah, I think Laravel very much is like The Fifth Beatle for us. There's so much work and care that has gone into not just Laravel but the entire Laravel ecosystem. So we're on Laravel vapor. So that takes care of so much of our infrastructure for us. And all the little details have already been considered for us. So we don't have to be in the weeds around how does Lambda work.

There are so many things that all applications have. And I think, you know, if you, if you really thought about it in most cases, 80% of all applications have the same concerns, the same, particularly in the web development space, right?

Matt Stauffer: Yeah.

Greg Skerman: So you're always gonna need to send email notifications. You're always gonna have to send Slack notifications. You're always gonna have to have something that you can, you know, just because of the nature of the way PHP works, that you can push onto a background queue and process in the background. You're always gonna need to be able to route a URL to some piece of functionality. And look, it's possible to go and build all of that stuff, which you can, but it's really not interesting.

It's not, you know, the business outcome is not we need a queue unless you're in the business of selling some queuing solution.

Matt Stauffer: Right.

Greg Skerman: Like queues and emailers and those kinds of things, those are not, those are not valuable business outcomes at all. A valuable business outcome is that we need a user to be able to log in and see their dashboard. Well, guess what? Laravel's got you covered on that. It's like literally three commands away from existence, which it's almost a meme at this point, just how quickly you can sort of set up auth and all that.

So Laravel really helps us because it just provides all of the groundwork for you. Like you start a new Laravel application and it's bare of business functionality, but it's rich and deep in like application functionality. Like all of the sort of, there's like this pick and mix of, pieces that every application tends to need you you won't use all of it we don't even use all of it but you know chances are it will be there if it's not there it'll be in the broader sort of official Laravel ecosystem and if it's not there there's going to be a spatie package for it. So you know it really helps us to get out of the implementation weeds of you know these very low-level problems that need to be solved and just solve business problems, just build features that actually put money in the bank.

Matt Stauffer: Yeah, that makes a ton of sense. And I mean, it makes sense from an interpersonal perspective about our experience with Laravel's programmers, and it makes sense from a business perspective in terms of who's working for you and how quickly you can get things pushed out.

So I have one final question, but before I get to my one final question, I just want to ask you is there anything that you would like to share with someone who would love to be in your position, who's still coming up, or somebody who's in your position but needs help getting the company kind of really operating at the same level yours is operating in? Is there one kind of piece of advice that you would want to share with anybody who's just kind of like, hey, you know what? Greg, I want what you have in some way, shape, or form. Is there, you know...something they should do, something they should read, somewhere they should go, some talk that's really, because you mentioned kind of that one book that kind of helped you coming up, but is there any other thing that we've missed that we haven't got a chance to get to, or do you feel like you're able to cover it all?

Greg Skerman: Yeah, look, I mean, I think I would, in a lot of ways, mirror some of Aaron Francis's advice and talk to people. I'm relatively old at this point and I came up in a time when, you know, you worked in quiet, didn't sort of talk about it, not of the Instagram generation, I guess, where brand building is a thing.

But there is a community out there, it's a massive community of people, and there is, you know, there's the very public community, there's a very Aaron Francis community, the very sort of Ian Landsman community, Matt Stauffer community out there. But there are people in the community who have specific pockets of knowledge that are sort of a little bit off to the side of what Laravel is. And I think engaging with the community and asking people who have what you think you want, you know, questioning.

Most of us are fairly open to having these conversations.

Matt Stauffer: Yeah.

Greg Skerman: I think, you know, it's, the answers are out there. I don't necessarily, there's no, I can't give you like an answer that says, you know, this is how you get to where I got to because I think everyone's journey is gonna be very, very different. But I think, you know, finding yourself a mentor or finding yourself somebody who will give you half an hour of their time and, you know, tell you what it actually is like. Because it often is quite different from what it looks like from the outside, I think.

Matt Stauffer: Yeah, no, I think that's absolutely true. And also just the people who you are idolizing are always just people, you know.

Greg Skerman: Yeah, 100%.

Matt Stauffer: Across the board, you know, you'll meet them and you go, really? You know.

Greg Skerman: Yeah, yeah, and some of the nicest people in the world too. Like, I mean, we have our community is... we're very lucky. It's a community of very wonderful, supportive people. You know, I speak to Jess Archer a lot. I speak to Aaron Francis, not quite so much as I used to because he's very, very busy with his new thing. But everyone just seems to have so much time for everybody.

If you have questions, if you're just starting out, or if you're at that inflection point in your career where you want to make a change, there are literally hundreds of people out there that you can reach out to and who will happily give you a moment of their time.

Matt Stauffer: Yeah, I love it. All right, last question of the day. No, hold on, there are two last ones. First of all, is there anything you wanna plug?

Greg Skerman: Yeah, so I've spoken a lot about team performance and building a high-performing engineering culture over the last six months. I do offer a very small number of coaching slots in that space. So if anybody is interested in getting some of my time to talk about that or just wants to pay me so that they can tell me how crazy I am. I'm fine with that too. Yeah, feel free to reach out to me. I would be remiss if I didn't plug Laracon AU for Michael. I think at the time of recording he's sold half the tickets already.

Matt Stauffer: I know, it's amazing.

Greg Skerman: So it's... yeah, look I'm very biased because it's my home country and hometown but I do think it's the best of the Laracons just because it's just such a chilled out and...in relaxed time. So yeah, get along, come and see Brisbane. And if you're in town, hit me up, I'm always keen for a cheeky drink or something, if you've got the time.

Matt Stauffer: So Australian of you, a cheeky drink. Love it.

All right, my actual last question. If somebody came along today, and I understand as a not owner, this is a little bit less legitimate of a scenario, but I don't care. If somebody came along and because of your participation, the company offered you $10 million to just walk away and you didn't have to do your job anymore, what would you do tomorrow?

Greg Skerman: Well, that's a tough one. $10 million is a lot of, particularly if it's US dollars at the moment.

Matt Stauffer: Yeah, 10 million US.

Greg Skerman: Yeah, it's really, it would be really hard for me personally. I still get very attached to the things that I build. I still think that you know, we call it engineering, we call it development, we call it all these things. It is fundamentally a creative pursuit. And I find that, and I don't write as much code as I used to, and I've had to get comfortable with this idea of writing code through other people, but there's still an active creation there. And I don't know that if it was my own thing, I mean, this is a decision that I couldn't possibly make because, you know, I don't own the business but if it was a business that I did own and I don't know that I could because I don't think that I necessarily build to get an exit. I don't think that's kind of in my DNA. I think I am built to solve problems that I have or that people who are important to me have. So yeah I take an investment but I don't necessarily think I'd take an exit.

Matt Stauffer: Okay. Somebody offered you, 10 million dollars, you'd say, all right, you own X percent and let's keep going. All right. I like it. Yeah. Right.

Greg Sherman: Yeah, yeah, yeah. Do a lot with $10 million.

Matt Stauffer: Well, Greg, I had a great time getting to know you. Thank you for sharing all this. And I will make sure that all the references, your book or the book you're talking about and booking stuff like that is all in the show notes. So if people want, and also your Laracon AU talk from last year, they'll all be in the show notes. So if anybody's interested in this stuff, but if anybody does want to get in touch with you, they want to follow up with you, how do they find you?

Greg Skerman: Yeah, I'm on the website formerly known as Twitter. I'm at Greg Skerman and you can also find me on LinkedIn. I think it's Greg-Skerman on LinkedIn. I'll get it into the...

Matt Stauffer: We'll put you in the show notes too.

Greg Sherman: Yeah, those are probably the best ways to get in touch with me.

Matt Stauffer: Fantastic. Well, thank you so much for your time. Thanks for sharing your learning with us and everybody else thanks for hanging out with us.

Greg Skerman: Thanks for having me on, Matt. It's been a pleasure.

Matt Stauffer: All right, cheers.

From MySQL to Typesense: Blazing-Fast Full-Text Search in Laravel

Getting Started with Twill, an Open Source Laravel-Based CMS

Get our latest insights
in your inbox: