Jason Tucker 0:10
This is episode number nine of Dev Branch How to hire a WordPress developer
brought to you by ServerPress, makers of DesktopServer. They make local WordPress development easy. Check them out at ServerPress.com
And The Events Calendar. The events calendar is the best calendar for events on your website and your clients websites. Go check them out over events calendar.com and use the promo code wp WPwatercooler for 20% off your purchase of this great product. I do want to tell you one thing, if you’re going to be selling events and making selling tickets to events, go to theeventscalendar.com go take a look at it. Good stuff.
I’m Jason Tucker, I’m an IT director and WordPress web developer.
Steve Zehngut 1:16
I’m Steve Zehngut. I’m the founder of Zeek interactive and I run the OC WordPress meetup.
Jason Cosper 1:22
And y’all know who it is your boy Jason Cosper, AKA Fat Mullenwig.
Jason Tucker 1:30
We’re a podcast as well, if you’re listening to us or watching us, I mean, go and subscribe to us as a podcast, go to Apple podcasts, Google podcasts, Spotify, wherever it is that you listen to podcasts, there’s plenty of those places that you can listen to us over there. How’s it going, folks? good intro music. Thanks, man.
I didn’t have enough time to to fade it out. But hey, whatever. So today, we’re gonna be talking about how to hire a WordPress developer.
How to hire WordPress developer? You know, we’re WordPress developers. We are and most of us are hireable. And,
Unknown Speaker 2:10
yeah,
Jason Tucker 2:12
if you want to hire a WordPress developer, it’d probably be a good idea to know some stuff about WordPress developers about how to approach them, how to be a good client, any of those sorts of things. So let’s, uh, let’s get started. Steve, this was this was your topic? What do you how do you want to kind of start this off?
Steve Zehngut 2:29
Um, you know, I think I think you touched on a good point here is, is how do you be a good client? Right? Because that that’s often overlooked, and is probably not probably it is critical to the success of any, any, any project, right? Of any, any outsource resource that you’re hiring. Right. So that’s true of, you know, any, it’s true of any business, but, you know, especially in developers, and, you know, I’ll give you a kind of a, some of the context here, right. So if you, if you’re listening to this, and you have worked with a developer before, we and I include myself, in this category, we are a unique breed, developers are mostly kind of cut from the same cloth. There, there is a certain type of person that gets attracted to becoming a developer, you know, developers are notorious for being not great communicators, right. And so, so that, where it start with, you know, how to how to be a good client is really there should be a focus on on strong communication, right? And, and communication is, is going to be successful, it’s going to be critical to the success of any product project, but especially when dealing with a developer. And, you know, take what I said, you know, sort of for, you know, at face value, or for what it’s worth, but it is kind of true that, you know, if you’re working with somebody that is not great at at offering up communication, or offering up transparency, or any of those things that are sort of critical to the project, it’s sort of, it’s going to become up to you as the client to pull that information out of the out of out of the the person on the other side of the table. Makes sense. And this happens more often than not, right? I know, a lot of the projects that I inherit, I inherited because the the developer was, you know, not a bad developer that I inherited the project from and you know, they weren’t doing anything necessarily wrong. From a development standpoint, they just weren’t communicating the status of the project and then that that is that that’s important to my clients, and that I know I just insulted pretty much everybody that’s that’s watching our show. But does that make sense?
Jason Tucker 4:56
Because firs eyes got really big as you started going through a long list of things. You want to do it salt? Yes.
Jason Cosper 5:05
You know, honestly, if you want to find a developer in the time of wordcamps, I used to jokingly say, look for the white guy with a beard and about 30 extra pounds, pretty sure to find at least 30 extra pounds
Steve Zehngut 5:26
in the corner by himself that he forgot that part.
Jason Cosper 5:29
Right, right. Right there, there are a handful of developers who are fortunately, confident enough. And he can be around people easily enough to go out and give talks at word camps and stuff like that. So you know, it’s not an exclusive thing. I’m painting with a pretty broad brush there. But it’s not far off either.
Steve Zehngut 5:59
And, you know, and again, I realized that we’re stereotyping here, right. But the really good developers that I’ve worked with over my 26 year career, right have been quiet, right? They keep themselves they want to just kind of hang out in their cave and write code, right? Not there’s nothing wrong with that. Right? But that’s, that’s just the kind of person you’re going to, if you want a really strong developer, that’s the sort of personality you’re going to get. And I’m saying this stuff, because you need to know that going into the relationship, right? Because if you’re expecting a normal working relationship from a developer, nine times out of 10, that’s not what’s going to happen. Right? And so it’s important to expect that as a client that you’re not, you’re not going to get normal communication, right. A lot of people, when I hear their horror stories about past projects, they talked about the developer ghosting them, right? You know, the I gave the specs and the developer went away, and then they came back and nothing was what I expected it to be. Right. So and sometimes that span is months, right? Literally, there’s just months of quiet, and all of a sudden, here’s your project, and it’s nothing what I had envisioned, right. Yeah. But that’s actually very normal in our, in our space. It’s, it’s, it’s, again, I’m not saying there’s anything, I’m not passing judgment, there’s no good or bad here. But that’s what most developers are expecting to happen, right? You gave me the tasks, right? I’m gonna go off into my cave. And I’ll report back when I’m done. Right? That’s just the attitude, right. But that’s not what most clients want. And so to be a good client, you need to, you know, set up milestones set up, set up communication, set up a path for communication, right? set expectations around what you know what you want to happen with the project, right? Because most developers on left to their own devices are not going to do that for you. In my experience, right? Now, it’s different when you’re working with an agency, right? An agency set up typically with a project manager, or an account manager, or somebody that is managing the project, who is that buffer between, you know, the client and the developer, right? That’s really what that project managers job is, is to deal with the quiet developer, right? To get the current status of the project so that they can communicate it to the client,
Jason Tucker 8:31
right? And that’s just for, and that makes it really difficult if you’re a one person shop.
Steve Zehngut 8:39
And that’s really both. And that’s why I’m but we I suggested the title of this episode, specifically, how to hire a WordPress developer. This is not how to hire a WordPress agency. Right? It’s different and it is specific for a reason, right? So really, what I’m referring to is a one to one relationship between a client and a freelance developer. That’s, that’s what I had in mind when I titled this, this episode, so so number one communication, then I had that on my list here, right? That’s that that’s key, and expect that communication isn’t going to be typical. I was gonna say normal, that’s not the word. It’s not going to be typical, right? And again, normal normal. The reason I usually didn’t use the word normal is because that’s passing judgment, right? It’s just, it’s not typical, right? It’s just different, expect communication to be different. And again, if you go into it with that expectation, then there are no surprises. But that’s a good segue. Right? In, you know, in about surprises, right? I think you need to expect surprises, right? There are going to be surprises during your project. Right? And so I think the reason I bring that up is because when a surprise happens, and To find surprises a minute, but what a surprise happens, right? It’s up to you as the client as to how you’re going to react to that surprise, right. And so there’s there’s many ways to react to a surprise, right? One way is to get angry, right? I didn’t expect this this was wrong. This is this is different than what I explained. Right? So surprise happens, you get angry. That’s no good for the project. No good for the for the relationship between you and the developer. It is no good for the it’s no good for the outcome of the project, right? Because things like that getting angry about surprises is going to affect motivation. Right. And so I’ve found that it’s best if you can control those reactions, expect surprises, and and rather than reacting with anger, go into that go into those those situations with questions about why something is different than we expected. And that’s going to ultimately result in a better outcome. Right,
Jason Tucker 10:59
right. So how should How should the client? How should the client set those expectations that they want from the developer? Because they’re, you know, not all clients are developer friendly? Yeah,
Steve Zehngut 11:14
let me let me find surprises first, before I answer that, because I have I have a that what you just asked really is my next point, right? So So let’s talk about what surprises are right? To me a surprise is something is different than what I expected it to be, you know, the the functionality is different. The look and feel is different. It the something functions different than what I then what I explained to the developer, that’s, that’s a surprise, a surprise, maybe something’s gonna cost more. Right? It costs more than I expected, right? Because there was something that was, you know, not not expected at the, at the at the start of the project, right. So that that’s a surprise. Surprise is something came in late, it came in longer than than expected, right? All those things that kind of lump under surprises, right? Surprise, right? This happened, something’s different than what I expected that to me, I categorize all that as a surprise, right. And again, as the client, you can control how you react to surprises. And I like to I like to react to surprises with by taking a breath, and simply asking questions or just explaining, hey, this isn’t what I expected. Right? Explain to me why, you know why you did it this way. Right? And a surprise actually might have resulted from good intentions, right, that surprises and everything I’ve expressed so far isn’t necessarily done. with malice, there’s no, that doesn’t necessarily have to be malicious intent behind a surprise. The developer may have done something in the clients best interest, but not communicated it. So it resulted in a surprise.
Unknown Speaker 12:56
Right. And
Steve Zehngut 12:58
most of the time, most of the time, I find that that’s the case, right? So developer, you know, sees, you know, something that they need to develop, they see a problem, right? They decide to tackle the problem in a different way, maybe in a more time efficient way, maybe from a code efficiency way. Maybe there’s just a different whole different library that they they include in the in the project to tackle this particular problem, right. And they do it in a way where they feel really good about it. They’re proud of it. But they didn’t communicate it, right, because we got to go back to my first point, right? All that stuff happened in the cave, right? It happened in the background, without any communication. And they did it and they did it with good intent. Right. But when it’s met with anger, then then that all all of that results in in a bad outcome. Does that
Jason Tucker 13:48
make sense? Yeah, it makes perfect sense.
Jason Cosper 13:51
This, this all goes back to kind of what you were first talking about, which is having milestones and clear deadlines. And really, from the outset, making sure that they know what their milestones and their deadlines are, when deliverables are and when you set a deadline, don’t set it for the day, you’re gonna want something set up for like two weeks before you launch something. Because I have seen people flipping out because their developer, oh, we were set to launch on this day. And it’s like, you’re never going to hit that launch date. You always have to plan for for Murphy in his damn law. To rear its ugly head, like what can go wrong will and you need to have a buffer for that. You need to be ready to say, hey, I need this project in four weeks knowing that you actually need it in six weeks. And I’m not saying you know what, that it could happen where the person you’ve hired to develop something comes in, under time under budget, it all goes wonderfully. But you need to have that buffer there. You can’t put yourself on the hook for something like you can’t depend on people, if you’ve ever I know we talked about this on wp WPwatercooler. Last week, that the house analogy, you know, if you hire somebody to do something on your house, and they go, okay, like, it never takes, like, Oh, yeah, we’ll be, we’ll be in and out and done with us. And in a week,
Steve Zehngut 15:30
every time, every time I get an estimate for somebody to work on the house, I double it, and then I triple it.
Jason Tucker 15:38
Both the money and the time. Absolutely. Double it and triple it.
Jason Cosper 15:42
Right. So this isn’t unique with just hiring developers. This is hiring plumbers, hiring house painters, hiring mechanic to work on your car, it goes, it’s it’s everywhere, but you just have to know that you’re in for this before you actually decide to take that plunge. And so
Steve Zehngut 16:05
I i 100% agree with everything you just said, lump that all under my third point was is managing expectations. Right. So Jason Yeah. Your to answer your question earlier. Right. The The key is, manage expectations, and continue to manage expectations throughout the project, right. And expectations are on both sides. Right. So as the client, you’re not just managing expectations isn’t just saying, This is what I expect to happen. Right? It’s also saying, Hey, this is what I expect to happen. Right? How do you achieve that on your side? And what are your expectations of me to make this happen? Right, it’s an expectations are a two way street. Right. And so that’s another key here is, is managing those expectations. I think, I think Cosper gave a great takeaway there. Right? always had your schedule, and don’t tell your developer that the schedule is padded, because as soon as they know, it’s pattern, that becomes the new schedule. Right? And you’ll find, right if if you haven’t done the first two things that I talked about, whatever date you quote, is the is the date, you can expect to see something like the first version at the end of business on that day. Right? So if my, if my deadline is February 5, right? I’m gonna see the first version of the project at the end of the day today. That’s what’s gonna happen. So it’s a great nugget is Pat is pad your schedule, right? expected to take longer than than what you said. But you said something else that Cosper. And I want to, I want to kind of pull this out is, is you said, Hey, the developer may come in ahead of ahead of schedule and under budget, right? And I’m going to encourage you as a client, and the, our listeners are going to hate this. If a developer comes in under budget, right? And you had budgeted for something originally, pay them what pay them what you originally budgeted. Right, because that’s a value to you, because they came in under schedule or under budget doesn’t mean the project should be cheaper. Right?
Jason Cosper 18:13
Right.
Steve Zehngut 18:14
As a matter of fact, at that point, you should give them a bonus. Right? So I’m just gonna use some loose numbers here. Let’s say your budget was $10,000. Right? And it was four weeks, and they came in and three, that doesn’t mean your budget is now 7500. because they’d spent three quarters of the time, right? You pay them the 10 grand as a matter of fact, they got you in a week early. So give them another $2,000 bonus. And you know, what that does that motivates them to come in again, under budget, the next time around? If you cut their budget, because they came in early, right? You’ve shown them that they actually provided no value whatsoever.
Jason Tucker 18:53
Right. I think I think if you’ve been burned in the past, by a developer and this developer in particular, what do you mean, if but I think you should approach this, you should approach this in a in a way that you feel that that that the developer is going to this is going to be a longer relationship than this one project. You know, you’re because you don’t want to just go and be like, if you got screwed over on the previous person, it doesn’t necessarily mean you can be screwed over on this with this person as well.
Steve Zehngut 19:24
So many, so many good takeaways there. Right? So so so the first thing is a really, you’re you’re you working with a developer, once you hire a developer, it is much like a marriage, you’ve just entered into a long term relationship, whether you think it’s one project or not. This is a long term relationship. So you should expect that,
Jason Tucker 19:44
right? Just huge changes you have, you know, we want to do a full redesign. We just changed the name of our company. We’re now pivoting. It could be all the things when you want to have a good relationship with the developers, the developers
Steve Zehngut 20:00
The code they put their signature on it, right? they’ve they’ve put their style on it, right? And so if you like, assuming you like working with that developer, right, you’re, you’re there are going to be changes down the road, there’s going to be maintenance you, you’ve entered into a long term relationship. But the other thing I want to say, I think this is critical. Jason and I encountered this all the time, right? Your past relationships with other developers have no bearing on the current relationship with the current developer. Right? And that’s, it’s tough. It’s tough to separate because, you know, if you if you think about that in our love life, right, right. Everybody does this, right, they bring, they bring the skeletons from the past relationships into the current relationship. That’s how that’s how relationships work. So it’s natural to, to bring those skeletons into your working relationship with a developer. But you have to find a way to separate that, right? Because this new developer, isn’t the old developer, right? There may be some similar patterns. Right? But it’s, it’s not the same. Yeah. And it’s, it’s a tough thing to do. But, you know, I find myself dealing with that all the time, right? Being being I’m gonna use air quotes, but being, quote, unquote, punished, right? for something a developer did that, that was that predated me on the project happens all the time. Yeah,
Jason Cosper 21:31
despite despite the generalizations that we were making earlier, developers aren’t a monolith. And one, just to reiterate what Steve said, one, one developer isn’t going to be exactly like another one. I, when I mentioned, you know, they might come in under budget, or you know, ahead of time, that happens, almost as much as the delays or, you know, these weird twist surprises, these m Night Shyamalan esque surprises.
You know, the trees, the trees are trying to kill people.
Jason Tucker 22:19
And, and like, not all of his not all of his, his creations are created equal. But But here’s
Steve Zehngut 22:27
the thing to know, right? I again, I know, I know, we’ve overgeneralize a stereotype. But the truth of the matter is, developers have different skill sets, right? Not all languages are the same. Not all frameworks are the same. Not all servers are the same, right? Not all software is the same. And so developers have different histories, different things they’ve learned, and they bring different skill sets into the project. Right? So even the best developers are not going to approach every project the exact same way. And that’s okay. Right. So it’s not none of this again, none of this is done maliciously. It just is what it is. Right? And so, you know, even though they may be kind of cut from the same cloth from a personality standpoint, they they bring different skill sets the project?
Jason Cosper 23:15
Absolutely,
Jason Tucker 23:16
yeah. I mean, you as the client, come come with your own set of baggage and your own set of issues. But you also come with with a, you know, with an understanding of, you know, the company that you run the website that you want to have built, if you’ve done this before, at least you have some of that experience as well. And don’t assume that it’s just going to go exactly the same way, this time. And,
Steve Zehngut 23:40
and, and, and here’s what’s important about that, this is my last point. So what’s important is to articulate your business goals as best as possible to the developer, right? Because, because they, they need to understand the benefits of what they’re building as well, right? There’s a value to what they’re building. And if you can articulate that this is the result that will that will end up from this, that’s actually motivating for the developer, right? We, you know, we need this much traffic, or we need to scale this big, or we need this many sales or whatever your business goals are. articulate those, make them part of your scope, right? articulate them in the scope, put them on paper, bring the developer into the business conversation, because I guarantee you that that will motivate them, that by itself will motivate them to get the results that you’re looking for. We’ve talked about scope quite a bit during this call, right? It I’ve been doing this for a long, long time, right? And what I’ve discovered is there is no perfect scope. right at the beginning of the project, you can get as detailed as you want, right? But the scope is going to change. And you need to be okay with that. Right. And so, one thing I’d advise both sides of the table and I’ve talked about this in the past at wordcamp talks Is treat the scope as a living, breathing document, write the scope, you don’t write the scope at the beginning and then put it on the shelf. Right? The scope should be always ever changing and should reflect the current state of the project. Right. And all of the questions that you encounter along the way should be addressed in the scope.
Jason Tucker 25:20
Yeah, I don’t want to I don’t want to throw this in fight, you know, five minutes left into the show, but there’s going to be change orders.
Steve Zehngut 25:29
Yes, there are going to be change orders. Just like if you just like, if you were doing a project on the house and you hired a contractor, there are always going to be change orders.
Jason Cosper 25:38
Absolutely.
Jason Tucker 25:40
And you got to navigate them.
Steve Zehngut 25:42
And change orders are not a bad thing. They’re a good thing, right? It’s a way to it’s a way to document the understanding of what’s changing why it’s changing, right. And a change order may not necessarily result in a in an impact of the timeline and the budget, right? A change are can be, hey, this is a change of the scope. We’re pulling this thing out of the scope, because this change became a higher priority. So I’m simply swapping things out. But it is still important to document it as a change order. So that everybody understands what changed.
Jason Tucker 26:13
Yeah, that’s, that’s that living breathing document piece? Yeah. Yeah. Because you know, down the road, you can, you can find out that that developer is capable of doing these things that you weren’t necessarily, you know, aware of, or the the, the client themselves says, you know, we’d really love to be able to do this thing. And now you can, you know, go through and either set up a change order, or what have
Steve Zehngut 26:38
you. And, frankly, that’s where the change orders come into play when I do a project in the house, because I want the contractor to, you know, be cool. If we put that thing over there. I think I can absolutely do that for you.
Jason Tucker 26:54
Many $800 change orders during my process of getting into my house.
Steve Zehngut 27:01
I bought a 770 $500 beam in in a house when I when I did a small add on because I wanted I wanted something to just move slightly and he said okay, well, that’s a structural change. Right? So that just that just became a 70 $500 change or because we got to put a piece of wood in the ceiling.
Jason Tucker 27:18
Okay.
Jason Cosper 27:21
And if you aren’t, to the point where you you know, own a home and don’t have any idea about this. Sarah, my wife and I watch a lot of AMC or TCM another UCM. And there is a movie that constantly makes the rounds over there. It might still be in the TCM app is a Cary Grant movie, Mr. blandings builds his dream house. Are you familiar with the movie? Steve? It looks like you’re nodding and I. Yeah. Cary Grant. His wife convinces them like we need to quit living in an apartment in the city. Let’s go get a house in the country. And they find a house that it’s falling apart, they end up having to tear it down. And it was it’s all the costs involved with doing this. All of the little surprises, all of the things like that. It’s like an hour and a half long. It’s it’s very funny, despite the fact that it’s an older movie that you might not want to give a chance. But it is fantastic and really goes into like, why, when or how things can go wrong.
Steve Zehngut 28:35
But they they remade it. Yeah, years later, with Tom Hanks called the money pit. It’s basically the same movie.
Jason Tucker 28:43
The same movie,
Steve Zehngut 28:44
a movie? Yeah. Anyway,
Jason Cosper 28:46
oh my gosh. Well, hey, that’s
Jason Tucker 28:51
about wraps it up. I have no intro or outro for today. So I want to say thank you very much for hanging out with us. Really appreciate it. talk to y’all later. Have a good one. See you guys. Bye.
Leave a Reply