October 10, 2017

Apply Filters
Apply Filters
Episode 83: Finale
Loading
/

This is the last episode before we retire the podcast. Many people have enjoyed the podcast and we’ve had a lot of great feedback and a lot of fun, so we’ve been asked why we’re retiring. Ultimately, we just needed to make a change and it’s time to move on. Be sure to listen to hear about how things have changed over the past couple of years and why those changes have led to us retiring the show.

For our last episode, we’ve decided to answer some of our listeners’ questions. Some of the highlights of the show include:

  • Regrets that Brad and Pippin have had regarding not building a plugin they’ve had an idea for.
  • Why it’s important for companies to start new projects frequently.
  • Advice Brad and Pippin wish they could give their younger selves when it comes to development, projects, and processes.
  • Some thoughts on pricing: How data, psychology, and strategy play into it.
  • Takeaways Brad and Pippin have learned that have come about by sharing business ideas with others.
  • Thoughts on hiring developers and setting salaries.

Links and Resources:

Pippin’s Blog Post: Get Better at Saying No

Derek Sivers: Hell Yeah or No

Brad’s Blog

Pippin’s Blog

Apply Filters on Twitter

ApplyFilters.fm

Amazon SES service

Blog Post on Why It Took So Long to Release WP Migrate DB Pro 1.8

 

Transcript
INTRO: Welcome to Apply Filters, the podcast all about WordPress development. Now here’s your hosts, Pippin Williamson and Brad Touesnard.

PIPPIN: Welcome back to Episode 83 of Apply Filters. This is going to be our last episode before we retire the podcast. We announced about two weeks ago that we were going to retire the podcast and stop recording episodes, and so this is the last one. When we announced that, the predominant question we got was, “Why? Why are we retiring?”

There have been a lot of people that have enjoyed the podcast. We’ve received a lot of great feedback over the last two years or so that we’ve been doing it, and it’s been a lot of fun, so let’s start by answering that question. Brad, why are we retiring?

BRAD: Yeah. I think there’s probably a few reasons. It’s funny. I think we should maybe let people know that we knew something had to change, for sure. We’ve been discussing that for quite a while that something had to change.

We discussed getting our teams involved in the podcast and having them run the show, maybe. Then ultimately we came to a point where we were just like, maybe we should just let it go. Maybe we should just retire it, and we could do something else later if it made sense.

That’s kind of where we ended up. We felt that it was time to move on. We’ve been doing this for a couple years now. When we started, it was a lot of fun. It was very exciting and new.

I know I personally was in a very different place than I am now. When we started this, I had just launched Migrate DB Pro, like a few months earlier, and I had one developer. Now we’re up to nine developers, or nine people: one marketer and eight developers. My days are mostly managing that team, whereas back then I was writing code, and I had my hands dirty every day. And so it was really easy to talk about development challenges and things that we were struggling with. It was just easy to jump on a call with you, Pippin, just hit record, and just talk about what’s been going on for the last couple weeks.

PIPPIN: Yeah. We could very easily just chatter on, “What did you work on this last two weeks? What was the code that you were working on?” because you were the developer, and I was the developer. I think we have very similar changes that have happened over time, like my day is not made up of code any more. My day is managing and overseeing the overall projects. Then most of my team members write most of the code now.

When I get to write code, it’s a pleasure, for sure, but it’s not very often. That made it a little more challenging to talk about code every day because we’re not in it any more. It’s funny to me because I actually got some criticism from somebody online the other day about how, in this podcast, we’ve talked about code, best practices, and lots of different things over the last couple years, and how we espouse these great development practices. Then he went back and looked at some of my old and new code and was like, “This is not great.”

I’m like, well, yeah, because, number one, it’s like four to five years old. But, two, that right there is a perfect illustration of part of the problem that we’re running into with recording these episodes now is that I’m not in the code any more, but we’re still trying to talk about development. I think that right there is probably one of the biggest reasons.

There are a couple of other reasons that we talked about, though. One was time. Time is challenging. There’s the cliché, there’s never enough hours in the day, but at least for me that is more true now than it’s ever been. I think it used to be pretty easy, especially when we were living in the code all day, to jump on every two weeks, a scheduled call, a scheduled two hours of the day every other week, and record an episode.

We started to find that it was challenging to do that. We would delay a day. We’d delay a day. We’d delay a day. All of a sudden we’ve delayed two weeks, and we’re not able to record episodes every two weeks. Now we’re recording once every month and a half.

BRAD: Mm-hmm.

PIPPIN: That definitely continued to get worse.

BRAD: Yeah. For me, I definitely came to the point where it felt forced to record an episode, right? I mean I’m sure there’s a lot of things that go into that feeling, like time, but also having to plan the episode and the extra effort that it takes to plan an episode because I’m not in the code every day. There’s all these things that go into it. But, ultimately, it stopped being as fun as it used to be, and it felt more forced.

Then you take a step back, and you’re like, well, why am I doing this? Right? Then the answer is, maybe I shouldn’t be. Right?

PIPPIN: I think one of the pieces of advice that I always see people, like as they grow further in their personal lives or in their companies, whatever they choose to do, it’s to get better at saying no. I wrote a blog post about this. I should be doing better at this and, at some point, realized, you know what? We don’t need to do this any more. We need to say no because it’s not as fun as it was; so let’s say no. Let’s take a break.

BRAD: Right. That’s a great point. I think I’ve talked about that on this podcast before because there’s a great blog post by Derek Sivers. The title is Hell Yeah or No. If you can’t say, “Hell yeah I want to do that!” then just say no. Don’t say, “Yeah, I guess so.” There’s no half way.

If you have that problem where you find yourself saying yes a lot and then not enjoying yourself or whatever, then it’s an interesting exercise to try that. I tried it for a whole year, and I found that I ended up probably saying no too often. [Laughter] I was a little bit too disciplined in the practice, and so I had to scale that back since. I think it is a worthwhile practice if you have that problem, for sure.

PIPPIN: I think it is. I think it’s something to be very mindful of.

BRAD: Yeah.

PIPPIN: There’s your answer. That’s why Apply Filters is retiring. We may come back in the future. We may not. There is no decision being made other than we’re going to stop recording for now.

We did have a concern about will the episodes stay up. There are some people that like to go back and re-listen. There are people still discovering the podcast. And so, yes, the episodes are going to stay on the air. They’re going to stay on the website. We have no intention of taking the website down. If you ever notice that it’s broken, let us know, and we’ll fix it.

BRAD: Right. You can follow us. Pippin still writes on his blog, and I still write on the Delicious Brains blog. You guys can still follow us on Twitter. I pretty much post–

PIPPIN: And come chat with us in Post Status Slack.

BRAD: Yeah, Post Status Slack. I don’t really participate much in there. But if I get a ping from somebody, I’ll answer it. Do you participate in Post Status Slack a lot, like in the conversation?

PIPPIN: More now than I used to.

BRAD: Okay.

PIPPIN: I tend to focus mostly in the business channel and every now and again the e-commerce channel and the heavy dev channels.

BRAD: Gotcha.

PIPPIN: Not all of them, though. I typically look in. I’ll open it a couple times a day; see what kind of conversation is going on. If it piques my interest, I’ll pop in.

BRAD: Right. See, that’s that hell yeah or no thing. That was one of my nos. I have to reevaluate that.

[Laughter]

PIPPIN: All right. When we decided that we were going to do this last episode, we had to come up with some content. We knew that we were already struggling with producing development oriented content, so we decided to go back to our listeners. All of you have been awesome in sending us questions over time, and so we still have a series of questions to go through. We had some that were submitted after we facilitated this last batch of questions. We’ve got some that have been sitting around for a little bit, so we’re going to run through those, and we’re going to jump through one last mailbag episode and say, adios.

BRAD: Yeah, for sure.

PIPPIN: Brad, do you want to start us off?

BRAD: Yeah. Just before that, I want to make a note that all the episodes will be staying up on ApplyFilters.fm. We don’t have any plans to take it down. Yeah, we’ll be keeping everything up there indefinitely. If you ever need to refer back to an episode or something, it should stay up there as long as we’re still building websites, I think. Right, Pippin?

PIPPIN: Yeah, as long as my hosting….

[Laughter]

BRAD: Yeah, exactly. Maybe not forever – forever, but–

[Laughter]

PIPPIN: I’m still waiting on that free….

BRAD: Yeah, there you go. Right, so should we start off with the questions?

PIPPIN: Yeah, let’s do it.

BRAD: The first question is from Luis Rock. He asks, “Is there any idea of a new plugin you had but not followed and now, after several years after, you regret that you didn’t?” I think what he’s asking is, is there some plugin that we didn’t build that we regret not building.

PIPPIN: I think I’ve got a couple of little ones.

BRAD: Yeah?

PIPPIN: Actually, I’ve got two that I’ll mention. One of them I did build and the other one me and my team ended up not building, but I kind of wish that we had, and maybe we still will.

The first one is actually my event calendar plugin, my Sugar Event Calendar. That was a little plugin that I built with the intension of being this little tiny plugin that is very simple and does a very basic event calendar. There’s a part of me that wishes I had built that out bigger and made it a lot bigger. Now I say that, and I’m going to give you full disclosure that that is on the agenda is building that plugin out to be a full-fledged event calendar plugin.

But I can look at it now and say, like, this plugin has sat here as this very minimal thing for five years. What if I had built it much bigger? Today, would it have an ecosystem? Would it be comparable to our other products?

I wonder about that because also then I’m thinking about this, like I’m getting ready to dive in and work on rebuilding it, and I have worries. Am I wasting effort? Is this a bunch of time and money and resources that we’re just going to throw away?

If I had built it up a lot longer ago, say five years ago, that wouldn’t be a question. We would know; and so that’s one.

The other one, one of our biggest challenges with all of our plugins, our main three–Easy Digital Downloads, Restrict Content Pro, and Affiliate WP–is emails. Emails are terrible. Email delivery is terrible just in terms of, like, overall reliability on Web hosting accounts, especially when you get into lower end accounts.

One of the projects that we talked about building one time was a dedicated email delivery service that our platforms could tie into automatically. There are a lot of services out there–Mandril, Mailgun, SendGrid, SES, et cetera–that help solve this problem, but none of them are user friendly – not one. Every single one of them is developer oriented, and you’re expected to understand API keys, and you’re expected to understand what the actual problem is to begin with. Let’s be honest. Most people’s understanding of the problem is, my email didn’t show up. I don’t understand how the tubes work or how the channels work for the email to get there. I just know my email didn’t show up.

We were looking at building a system to solve that. To try to solve it, anyway. I think one of the reasons we didn’t build it is because it turned into a much bigger challenge than we had anticipated. But I still kind of wish that we’d gotten a little further with it. I think it’d be an interesting project, and I think it is very doable.

How about you, Brad?

BRAD: Hmm. What about just building on top of one of those platforms and just making it easier?

PIPPIN: I think that’s what we would have done.

BRAD: Right.

PIPPIN: But there were still a number of hurdles. We were looking at using SES, Amazon Service, Simple Email Service, for that. There ended up being just a number of hurdles that didn’t prohibit us from doing it, but took away some of the advantages of building it in the first place.

Some of the biggest challenges come in with things like domain verification for verifying domains, spam control, and things like that. When you put those into the equation, you lose some of the ease of use that you’re trying to create, and so maybe you don’t have that benefit any more. I think there’s still a chance that we’ll build it, and we’ll find out.

BRAD: Right. Cool. I like it.

PIPPIN: Do you have anything?

BRAD: I think if I go back in time far enough, probably the thing that I regret not doing is when I was running a Web hosting company kind of part time. My business partner was running it full time, and I was just kind of chipping away at the sides kind of thing. One thing we had discussed is focusing on WordPress and hosting WordPress sides, like a managed WordPress host, essentially. That was back in, like, 2005, probably, 2006, maybe. It was really early on and, honestly, it probably would have been a little too early. Actually, it might not have been that early on that we were talking about it. It might have been closer to 2008, actually, which the timing would have been better at that time, I guess.

Yeah, anyway, I remember when we were talking about it, the timing did seem very right. We just didn’t. It would have been a lot of — we had a lot of other, higher priority things, and we just never did it, which is usually the reason you don’t execute on a new idea. Right? You’ve got so much other things on your plate that it’s really hard to kind of make that leap, take that leap of faith, and start something new.

PIPPIN: Yeah, especially if you take those. You have 24 hours in a day. Let’s be honest. A lot of that is spent sleeping, eating, and hopefully having a little bit of fun. Then some of those hours are spent working in taking care of those tasks. You have all of these little things that you say, like, this is my immediate to-do list because I know that if I don’t do this today, I have to do it tomorrow. And so you tend to focus on those, whereas if you look at this bigger project, you say, well, this could benefit me in the future, but I’m going to have to push aside all of these little things that I need to work on now in order to do it.

It’s just like an investment. You have to look at the long-term future versus the right now gratification. Right now that gratification is marking off that to-do list, or you can take a gamble and say, I hope this works for the future. But it might be a bunch of wasted time, and that’s challenging to do.

BRAD: Yeah, it is. I think I need to take those leaps more often because the thing is, if you’re just continuously working on the same products all the time and not working on anything new, you’re not innovating. Right? As a company, I think it’s important that we do build new things all the time. You shouldn’t be starting new projects every week, right? You should focus.

But there has to be a balance. You can’t go for years working on the same thing without any innovation. At least that’s my view of it because things change. The markets change. Everything changes. It’s always nice to have a kind of diversified product line. You guys have three products, right? If the Affiliate one starts to go down, the other ones are probably going to be okay, right?

PIPPIN: Mm-hmm.

BRAD: Yeah. It’s nice to have that. Should we get to the next question?

PIPPIN: Speaking of that, Jonathan Bossenger asked, “What is one piece of advice you wish you could send back in time to yourself when you started developing products for WordPress?”

BRAD: Hmm.

PIPPIN: is there anything that you wish you had done differently in the early days of your products?

BRAD: Oh, yeah. [Laughter]

PIPPIN: All right. Let’s hear a couple.

BRAD: Like a million things, probably. I wish that I had hired someone in a time zone that was closer to mine so that I didn’t have to stay up until midnight working with them. My first hire was someone in Australia, which is almost the exact opposite clock as mine, so they were coming on as I was supposed to be going to bed. Just to have a little bit of overlap, I would have to stay up late at night. That was a huge mistake. I think that’s probably the biggest mistake I made early on.

Yeah. What about you, Pippin?

PIPPIN: I’ve answered this question before, and one of the answers I’ve come up with was, I wish I hired sooner. I spent the first several years working solo, and I go back and forth on that now, actually. Sometimes I wish I had hired sooner. Sometimes I’m glad I didn’t. I still feel like, going back, the way that I started to hire was right and successful.

One thing I do wish that I had done, I think, is I wish I had hired a dedicated marketing person or content creator or somebody like that early on because one thing that we’ve always struggled with in our teams is marketing, content production, and related efforts because we’ve never had anybody that’s focused on that. We’ve had full-time support. We’ve had full-time development. We’ve had a full-time bookkeeper. We’ve had all those kinds of roles, but we’ve never had a marketer or content producer.

I don’t know exactly why. I think a lot of it comes down to I’m generally pretty slow to hire, and I’m generally a little bit reluctant to hire because I like a small team. I think another aspect, another reason is I know very well for myself now that I am not good at those roles and that I don’t really know exactly how to hire for those roles. And so maybe it’s a fear thing in that I have a hard time understanding or knowing how to gauge if somebody is going to do a really good job at that.

If I see your results, I can look at those results and say those were great. But when it comes time to say, like, to interview somebody or try to find that person, it’s not a role that I’m familiar with, and so it’s not a role that I know how to hire for. I think, looking back, I wish I had taken some gambles earlier on and just done it; just said, hey, I need somebody to do this for me because it’s not my role.

BRAD: Yeah. I can relate. We just hired Liz this year to handle our marketing stuff. Yeah, I spent so much time doing that hiring, setting up that hiring process and just going through it. It was all based on fear.

Honestly, I don’t regret it at all. I think it was time well spent because Liz has been working out really great, and it’s just been excellent. I feel like I nailed it with getting the right person for our team.

PIPPIN: That is just a satisfying thing.

BRAD: Yeah, exactly. Maybe fear is good in this case. That’s something you don’t want to rush into, right?

PIPPIN: No, for sure.

BRAD: Actually, I can say that we’ve stumbled with hiring by going a little bit too fast, by cutting corners. I’ve been very cautious, and then I’ve gone right, like, all the way the other way and been super careless. I think those mistakes that I made, I need to find that middle ground where it’s like the sweet spot where I’m not spending tons of time, but I’m not spending no time on it.

Next question?

PIPPIN: Let’s do it.

BRAD: It’s from Ross Johnson. He asks, “I noticed that Affiliate WP has a lifetime license option at $499. Since pricing is an interesting psychological topic and Pippin seems to make good use of data, I’m curious if this option is because you figured out the average lifetime value of a customer is less than $499, or if it is an anchor to make the other price point seem cheaper?”

PIPPIN: It’s based on data.

BRAD: Yeah.

PIPPIN: Well, okay, I’m going to give you a caveat. It was based on expected data, originally, because you have to keep in mind when we first launched Affiliate WP, we included a lifetime option. When we did that, it was a new product, so we didn’t know what the lifetime value was.

However, we did know what the lifetime value was at that time for EDD and for Restrict Content Pro. We did have some data to back it up. What we did is, I thought about if I’m going to get one payment out of somebody, how much do we need to get, basically, to account for the fact that they may be there forever or for the life of the product asking us support questions, getting updates, et cetera? How do we make sure that I’m not going to lose money on this in the long run?

What we ended up going with was we looked for 3.5 years worth of revenue from a customer. We took our pricing and said, “If this person purchases and then comes back and renews for 3.5 years–really we went 4 years, and we cut it back just a little bit–what does that price point need to be?” That was pretty much how we came up with $499. Originally it was $449, and now it’s $499.

There was that piece of data we used just to say, look; if we get 3.5 years, I think we’re safe. Are we going to have some customers that maybe get more value out of it over five years? Certainly. But the majority of customers will not have an issue with that, and our support team won’t be burdened with that. But we will have secured 3.5 years. Looking at that then, keep in mind that Affiliate WP is not yet 3.5 years old, and so we haven’t even reached those points yet.

BRAD: Right, so you don’t know yet if it’s a good idea.

PIPPIN: We don’t know yet. It’s still a little bit of a gamble.

BRAD: Yeah.

PIPPIN: But we do have the data. We have other data to back it up. I mentioned that we had the lifetime value of EDD and RCP. The lifetime value of EDD is $150; the average lifetime value of customers over all time. And so, yeah, I’ll take $499 because if my average is only going to be $199. I believe the average for Affiliate WP currently is higher than that, but it’s not that much higher. It’s mostly a data based decision, but it does also work to incur the other prices to make the other ones seem lower.

BRAD: Right. A lot of people that have these lifetime plans, they just do lifetime plugin updates and still do one year of email support, but you guys do lifetime email support. What was the thought process behind that?

PIPPIN: I think, honestly, we had just not thought to even separate them.

BRAD: Right.

PIPPIN: We may change that in the future. I’m not sure. At the moment, it’s not causing us any issues at all. It’s working very well for us at the moment. We’ll see if that changes.

The nice thing is that we’re able to be flexible if it changes. I mean if we suddenly realize that once we get to the 3.5-year mark that all of these customers that purchased lifetime 3.5 years ago, they’re now problems, we’re not going to kick them out, but it might mean that, okay, we need to adjust so that new customers, when they get to that 3.5-year mark, we don’t have the same issue being exacerbated.

Another thing that we looked at with lifetime options, this is something that I think people tend to forget. I’m actually a little bit of a rarity, I think, in that I really like the lifetime options from a business perspective. Most software products don’t live very long. Let’s be honest. We didn’t even know if Affiliate WP would live to be three years, five years old, or ten years old. We don’t know what it is.

To me, EDD feels like it’s been a lifetime, and it’s not even five years old. Is it five years old? I don’t know how old. It’s five or six. The point is, software products don’t live that long. And so when we’re talking about three to five years, I mean that is the lifespan of a lot of products.

I don’t need to be concerned; in most cases I do not need to be concerned about supporting somebody from eight years ago because that customer literally will not exist on that product in eight years. I don’t know if I can name a single WordPress product that’s been around for eight years, except for maybe something like — there’s a couple of them, but their business models have fundamentally changed throughout those eight years. They’re totally different systems. They’re totally different platforms now.

I think people get caught up in the idea that a lifetime option means I’m supporting you for 30 years.

BRAD: Yeah. Yeah. It could. It’s possible. [Laughter]

PIPPIN: Yeah, you’re right. It is possible, especially if you’ve written a poor terms and conditions.

BRAD: Very unlikely.

PIPPIN: That’s my take.

BRAD: Have you experimented with the prices for Affiliate WP, or did you just set it and forget it?

PIPPIN: We did. In the first year and a half, we did some price experiments. Then we did do a price change about nine months ago. Yeah, we’ve done some experiments. We’ve done some testing with renewal discounts, no renewal discounts, et cetera. We had manual renewals and automatic renewals. That’s all in the span of like 2.5 years. Again, we’re not even to the 3.5-year mark.

BRAD: Right. Yeah, yeah. Crazy.

PIPPIN: All right. Brian Krogsgard asked, “What’s one big takeaway or thing you’ve applied to your own business, which you only discovered by sharing about your business with others (in this medium or others)?”

BRAD: Right.

PIPPIN: Brian asks hardball questions.

BRAD: Yeah, good question, Mr. Krogsgard. I definitely get a lot from sharing. I just wrote a blog post that we published this week that’s about why it took so long to release Migrate DB Pro 1.8. In that process of writing that post, there was a bunch of assumptions that I was making that I actually went to the team. I was like, so I’m thinking that this happened, but is that what happened? There’s certain things, like, until you’re actually trying to distill things down and communicate it to share it, you don’t really recognize the assumptions that you’ve made.

For me, that was super valuable, the exercise of writing that blog post, because I was able to kind of dig into some of the issues that we had that I thought we had. It turns out some of the issues that I thought we had weren’t really much of an issue. Yeah, I find that sharing is super, super valuable.

What about you, Pippin? Is there anything that you’ve shared in particular?

PIPPIN: I think that that’s one of the big ones for me as well. I think back to the number of times when I’ve gone to somebody on the team, or not on the team, and said, “Guys, I’ve got a problem. Can I hash it out with you real quick?” Then purely by the act of talking about it, I answer my own question; I solve it with zero insight from anybody else.

It is simply the act of talking about it, laying it out, and trying to explain it in a way that somebody else can step into the situation that you’re in and try to understand the thought process and then hopefully provide their suggestion or their advice on what to do, whether it’s a bug or a decision you’re trying to make, whatever it is. Simply the act of talking about it makes a huge difference. I found that I’ve had that same experience any time that I have talked about a business decision that we made or a development decision that we made.

Honestly, I learn about why we did it more while writing about it than while making the actual decision. I think part of it is it gives you that time to sit there and reflect while you’re trying to compose it all in your head or you’re trying to compose it on paper, or however, through your keyboard, however you’re conveying the message. You’re trying to compose it together and make sense of it, not only in your own head, but trying to make sense to others. In doing so, it makes a lot more sense to you, or it becomes more clear, or something like that. That’s been infinitely valuable.

I’m not sure if there’s a single — if I could say that there’s one takeaway, like a particular decision that we made that I only realized by sharing. But I think, just in general, that sharing and talking about it here, in private channels, in conversations in person, at WordCamps, on my blog, et cetera, that has been valuable. Maybe it’s the, “Don’t live and work in silence.”

BRAD: Exactly. Yep, 100%. All right. We’ve got one more question from Scott Paterson. He says, “I think it would be great if you did an episode on hiring developers, managing developers and projects, and how to determine salaries.” I think, in a previous episode, a few episodes back, we did promise to have a discussion about developer salaries and countries.

I know it’s really tricky, that whole topic. Let me try to set it up. Let’s say you have a developer that’s working in the Philippines. The economy there, it doesn’t take much U.S. dollars to live very comfortably in the Philippines, right?

But let’s say the developer is producing code of the same caliber, the same quality as the developer you have hired that’s based in the U.S. Let’s say the developer based in the U.S. is making $90,000 a year. Should you pay the person in the Philippines $90,000 a year? They’re producing the same amount of work, but they can live like a king on $90,000 a year in the Philippines, right?

PIPPIN: That person living in San Francisco is not doing nearly as well.

BRAD: Right. Right, so I said $90,000. To live in San Francisco, you’d need six figures, at least. That’s the dilemma, right? I don’t have a good answer for it, to be honest.

I know Buffer does something like, when you move, then they recalculate your salary. Let’s say you move from a city to the country. Buffer has all their calculations and stuff is public, their salary calculations. If you live in a city like San Francisco, you get a bonus. You get extra money because you live in San Francisco. Then if you move out of San Francisco, then your salary needs to be adjusted for that event.

I don’t know if I agree with that or not. And I don’t know if there’s a perfect system. I’m pretty confident there’s not a perfect system. But I don’t know what’s right. It’s a tough one, man. I don’t know.

PIPPIN: It is a tough one. It also brings up issues that, as businesses, if you are a person or a team in charge of hiring people and you are also a team in charge of trying to make the company profitable and work well, all of a sudden you have an incentive to hire people in places that pay less. That’s not necessarily good or bad, but it is a very, very real thing.

I think the only constant in it is that it’s challenging. No matter how you look at it, no matter what you decide of what is philosophically/psychologically right or wrong, what is best for people, what is best for the company, it’s super challenging.

I’ve had a couple of times trying to figure out. I’ll be honest with you. It’s one of my least favorite parts of being the boss; trying to figure out what to pay people.

Hold on. We’ve got to step back for a second because there are also a lot of other things that you keep in mind, like sometimes, for example, you’re trying to hire a very specific person, and so maybe you decide I’m going to pay you extra because I’m trying to encourage you to come over. Sometimes you have somebody that already wants to work for you, and so it doesn’t take as much to convince them.

Or you have all of these different things that come into play. For example, as a U.S. company, we pay health insurance for all of our U.S. employees. But we have employees that don’t live in the U.S., and they have government provided healthcare.

BRAD: Right.

PIPPIN: Should they be paid less because some of their salary doesn’t go to healthcare?

BRAD: Right.

PIPPIN: It’s super tricky.

BRAD: You don’t even have to go international to get crazy because every state has a different healthcare situation.

PIPPIN: No. You’re right, absolutely right. Yeah. We’ve got employees that live in California. We have some in Arizona. We have some in South Carolina. I’m in Kansas. All of those states have fundamentally different levels of living expenses, and even from city-to-city.

I remember when I moved from one city in Kansas to another city in Kansas. My living expenses dropped, like overnight, just because the city was so much cheaper where I lived. The house that I could buy was a lot cheaper. All of our standard daily expenses were lower. That was only a 200-mile move. That all of a sudden meant that, as the owner of the company, I needed less to live, and I gave myself a pay cut because I just didn’t need it any more, and it was better for the company if I did.

Then you wonder; does that then go over to everybody else? If one of our employees decides to leave New York City and move to the middle of nowhere in the Midwest, and their living expenses get cut in half or more, do we cut their salary?

BRAD: Right.

PIPPIN: The quick answer says no; that would be a terrible thing to do.

BRAD: Right.

PIPPIN: How could you?

BRAD: Right, but you can look–

PIPPIN: But hold on.

BRAD: But you could look at it the other way around. If they moved–

PIPPIN: Right. What if you move from the Midwest?

BRAD: Exactly.

PIPPIN: Like somewhere in the Midwest where it’s super cheap, and you move to New York City? All of a sudden your salary isn’t even adequate to pay rent for a one bedroom apartment.

BRAD: Exactly. Exactly.

PIPPIN: Now all of a sudden getting a raise makes perfect sense.

BRAD: Right. Exactly.

PIPPIN: Yep. It’s super tricky.

BRAD: It’s super tricky. It seems like, from the employee’s perspective, it makes sense when they get a raise because they’ve moved somewhere more expensive, but it does not compute that they would get a pay cut for moving somewhere cheaper.

PIPPIN: You can give me more and more and more, but don’t ever take it away.

BRAD: Exactly. Exactly. I’m saying that because I think, if I put myself in that position, I would feel the same way. Right?

PIPPIN: Absolutely. I mean I think it’s just natural.

BRAD: Yeah. Yeah, but from a business perspective, it doesn’t make sense. If it goes one way, it should go the other. It should swing, you know. It’s tough, man. It’s a tough one. I don’t think there is any, you know, perfect solution there.

PIPPIN: No, I don’t either. I think maybe the best that I can come up with is just be mindful of it. I think if you are somebody that is in a position of hiring, I think you have to be mindful of it, and you can’t just ignore it. Whether your decision is that you have a flat pay scale, that’s great, or that you have an equation that you use. That’s fine.

BRAD: Right.

PIPPIN: But be mindful of it because it’s a very real challenge.

BRAD: Right. Yes. I agree 100%. I think the bottom line is that everyone on the team should not be struggling to take care of the bare necessities because that’s going to affect their work. Right?

PIPPIN: Absolutely.

BRAD: If they can’t afford to have dinner one night a week, obviously that’s going to be a huge problem for their performance at work, right? You have to definitely navigate. That’s an extreme example, but the idea is still there.

PIPPIN: Yeah. I think it sets a good baseline to basically say, look; I may not know where we cap you at, but I do know that we’re going to take care of your necessities. We are going to make sure that you can do your work and that you can live a comfortable life. Now, everybody’s definition of a comfortable life is going to be different.

BRAD: Yep.

PIPPIN: But that, I think, should be at your psychological core when you are deciding how you set the salaries.

BRAD: Yep. Exactly. It’s tough, man. Yeah, it’s probably one of my least favorite parts of managing a company, to be honest.

PIPPIN: Yeah.

BRAD: Well, I think maybe we should wrap it up.

PIPPIN: I think that’s going to do it.

BRAD: Yeah.

PIPPIN: Thank you, everybody, who submitted questions for this episode and all past episodes.

BRAD: Yeah.

PIPPIN: It’s been fun.

BRAD: Yeah. Thanks, everybody, for sticking with us through all 83 episodes. For those who have joined us just recently, maybe you can go back to some older episodes. There should be some good gems here and there that are still relevant.

I guess, here’s to the next chapter, whatever is next. Cheers, Pippin!

PIPPIN: Cheers!

BRAD: Thanks, everybody.

Apply Filters © 2024