The theme of this episode is centered around the lessons learned in charging for software development. Starting with a question from the Infinite Red Community, Todd, Ken, and Jamon touch on hourly vs. project pricing, the tension between time and value, how software estimating is a lot like weather forecasting, and the many experiments conducted over the years to find the right pricing model for Infinite Red.
The theme of this episode is centered around the lessons learned in charging for software development. Starting with a question from the Infinite Red Community, Todd, Ken, and Jamon touch on hourly vs. project pricing, the tension between time and value, how software estimating is a lot like weather forecasting, and the many experiments conducted over the years to find the right pricing model for Infinite Red.
JAMON HOLMGREN: We received a question from the community, community.infinite.red, it's a Slack community that we have. Trent asks, "Hey Jamon, I'm enjoying the podcast. Will you guys be covering hourly pricing versus project pricing? It's a question we're dealing with right now. Which do you guys prefer, and what are some lessons learned to bring you to that choice?"
I think this is a really great question. Todd, do you wanna talk about what we're doing right now? And then we can go into maybe what we've done in the past, and what brought us to that choice?
TODD WERTH: Sounds good. Yeah that's a great question, and it's actually a really tough one to deal with. So, what we do now, is we do weekly pricing. We charge per person-week, and we call it "person-week" as opposed to "a week of work" because it could actually be two people working maybe half a week each and that would be one "person-week." Because we're doing person-weeks, we have a point system. So, 100 points equals a person-week. We don't track time. We used to, and we can talk about that—we used to bill hourly. We don't track time, we don't actually know how long things take, it's just, we estimate our tasks in points, and if we've reached a hundred or more per person-week and we charge per person-week, then we're accomplishing our goal.
JAMON: There's a bit of a tension between time and value, and this has been something that we've dealt with, I mean, I've dealt with, since I started my first consultancy. Of course, value-based pricing is kind of a holy grail of pricing for consultancies, and we've heard this for a long time, that you should charge for the value, not just the time that it takes. So an example, this would be fixed-bid pricing, where you're essentially betting on delivering the software in a reasonable amount of time, but you're getting paid on the value to the client.
The problem is that our costs are not based on value. So, we're not necessarily paying our people based on the fixed-bid, a percentage of the fixed-bid, or something like that. There are industries that do that, but ours is not one of them. So we're paying people salaries, and our costs are over time, and so if something takes a very long time, then our profitability and the ability of the company to remain financially solvent is threatened.
Conversely, you have, of course, hourly. We've done that in the past, and the nice thing about hourly is that it corresponds, obviously, very tightly with the amount of time that it takes to do. But the problem is that every hour is not equal. You have hours that are maybe really valuable, you've automated something and in a lot of cases you're actually delivering more value than the client is paying for, quite a bit more. And then there are others where the person's getting spun up, or they're hung up on a particular problem, whether it's their fault or not, and that turns into a bit of an issue, because then you're billing hundreds of dollars an hour for something where the client isn't really getting a lot of value. So I think that's why we ended up where we are, in a way.
TODD: Yeah, both have issues. When you're doing hourly, it might seem to a client that's more fair, but it's not. It means every time there's a bug, or any time there's an issue, we basically are nickel-and-dimeing them, and they don't necessarily like that. We have to spin up someone, like Jamon said, where in our value system that we use now, they don't see any of that. We fix the bugs because it's part of the value of that particular feature. It does mean, though, sometimes, that we can produce a feature faster than the hourly would've been, and so they get charged, I guess, more for that.
KEN MILLER: There's a couple of different ways that hourly works out sometimes, though. There's certainly the very literal, like, you sit there and you run a clock, like the way a lawyer would, you actually have a little timer that shows exactly what you're doing. When I worked for a large sort of corporate consulting company, Big Five-style, back in the '90s, I remember my first week I was filling out my time card, and I filled in the insane hours that I worked, because that's the kind of work that you do. And my project manager comes over to me and he's like, "No no no no no no no no, this is not what you do." And he took my time card and he filled in "eight, eight, eight, eight, eight." (laughter)
TODD: That's ridiculous. But...
KEN: Right. So that's how the Big Five work, often.
TODD: So it's completely fake in that situation.
KEN: It's completely fake. It's basically pretty close to what we do now, which is that weekly billing. Where an hour is just a way of measuring a week.
To answer the question directly, you know, do we prefer hourly or project-based, we prefer hourly.
JAMON: Yeah.
KEN: Hourly leads to less problems in the long term because the trouble with fixed bid, although it seems like it's appealing—It's appealing from your point of view, if you think you can be really efficient, and it's appealing from their point of view if they think you can't. But that's exactly it right there, it creates this adversarial relationship. Todd?
TODD: Yeah, clients all– not all, but many clients think they would love a fixed bid. And in truth, they will hate a fixed bid. Ken's right. Fixed bids create an adversarial situation. Even if both sides are extremely... They're at the table in good faith, and they're trying to do the right thing and do their part and stuff, it still means that the client is trying to get as many hours as possible out of you for the same price, and us would be trying to do as few hours as possible. Like I said, even if you're both being very nice and very ethical in the way you're billing, that always creeps in.
It also means that you have to lawyer every change. You'll have companies that have change order systems that are pretty complex. Clients hate that. When I talked to especially start-ups, one of the things I say is if the project we're working on at the end ends up exactly as you envisioned at the beginning, that's a huge red flag. That means you didn't listen to your beta testers, that means you didn't think at all during the process even after you got in your hands what could be better, it means a bunch of different things.
So, we have a pretty strong process, but it's designed to be flexible. We wanted it to be flexible. So when we get to the point when we do estimation after a research phase, it's fairly accurate. The likelihood that it will actually produce your project for this estimate is extremely low. Not because we're incompetent– I'm sometimes incompetent– not because we're incompetent, but because you're gonna make a bunch of changes, and we welcome that. We don't lawyer that.
But that's a little bit difficult, there's a little bit of education involved in getting people to understand that fully.
JAMON: One of the objections is that, well, there are other companies that do fixed-bid, and they seem to do just fine. They're able to sustain that and their customers are generally happy, and things like that. But I think there's a hidden cost in there that people don't take into account. Which we've sort of driven a stake into the ground, we've said, "Hey, we're not willing to go down this route." And that is that those companies put the burden of hitting those estimates onto their employees. They essentially say, "Okay, well, we estimated this amount, you're not done yet, so you're gonna stay late until it's done." And they push, and push, and push, and they really, really just drive the screws in on their employees. Maybe not overtly, maybe not directly, but there's a culture and an expectation of being able to hit those estimates that puts a lot of stress on the employees.
KEN: Yeah, that doesn't necessarily look like a slave driver. It can look like a "Rah-rah, sleep when you're dead," "work hard, play hard." "Rah!" But like, that kind of corporate culture. There are firms out there that I respect that do fixed-bids, and they seem to make it work, and that's fine. But in our experience, someone is paying for that somewhere.
JAMON: Exactly.
TODD: There's another type of fixed-bid which isn't just slave-driving your employees into the dirt. It is, you think it's gonna cost $100,000 on this project, you bid $800,000. So no matter what, unless you're ridiculously off, you're fine. The problem comes in when clients want both the lowest possible price and a fixed-bid. That just... It's not really possible.
JAMON: So, our system is different. And Todd, I'd like you to talk a little bit about why our... Because, we are giving an estimate with points, and we're trying to hit those points, so it may feel like a fixed-bid, but do you want to explain what we're doing differently, where it really does change over time as you do a project?
TODD: Yeah, so we do spend a decent amount of time doing research, architecture, that kind of stuff, before we estimate the points. So we're not just doing a ballpark estimate. We do a ballpark estimate at the beginning, but that's a few hours of our time. But we spend a few weeks or whatever doing research, architecture, that kind of stuff. And at the end of that, we produce an estimate in points.
So those are fairly accurate. Obviously, anyone out there who does software development... By the way, everything we're talking about here is for development. On the design side, we do fixed-bids, and that's a different discussion. The gentleman who asked us the question was more towards the development side, so that's what we're talking about.
JAMON: Right.
TODD: So, our estimates are based on a whole lot more information than a lot of people do. And we do have clients who want an accurate estimate earlier, and we just have to push back, because in that situation we have only two options: We either push back against them and try to educate them in the process and help them do a successful project, or we lie to them. (laughter) And unfortunately a lot of companies just lie. They just come up with a number, they act like they put some thought into it– they didn't. I worked for a consulting company in the late '90s where the way we estimated was we asked the sales person how much they could afford. That was our miracle estimate. Which to me, I hated as an engineer. I just loathed it. I'm digressing a little bit here, but I don't want to make it out that our estimates are super accurate or that estimating software at all is an accurate thing at all. We know it's not.
KEN: One of our sort of colleague companies out there calls them "forecasts," which I really like. People understand, like, a weather forecast is not necessarily going to be accurate. It's like, "Based on what we can see right now, this is what we think is gonna happen." And everyone understands that. So I really like that as a bit of language.
TODD: Yeah, we should call it "forecasts."
KEN: I'm tempted to steal that, but... (laughter)
TODD: The other cool thing about a forecast is it's known: the further out you are from the date, the less accurate the forecast is, and the closer you get, the more accurate, and that's very true in our situation as well.
JAMON: That's a great point, Todd, because we will definitely adjust those estimates as we get into things, and as we learn more. And I try to, I do a lot of the sales calls now, and one of the things I try to do is set the expectation that over time, the estimates will get more and more accurate, as we know more. The same thing with the weather forecast. You look at the ten-day, and you look at day number ten, and as you get closer and closer, you're gonna see a better and better forecast. And it's not uncommon for that to change even quite drastically, because weather systems can get delayed a little bit or something, and that can impact which day they land.
KEN: Unless you live in California, in which case our weather never changes.
JAMON: Yeah. No, I live in the Pacific Northwest near the Columbia River Gorge, and nobody understands the weather here.
TODD: Our weather's hot and sunny. Tomorrow? Hot and sunny. The next day? Hot and sunny.
JAMON: What if it's-
KEN: And then a terrifying thunderstorm. And then hot and sunny.
TODD: Once a year, we have terrifying water from the sky. I live in Las Vegas, Nevada, which is in this very small patch– I'm totally digressing here– but it's a very small patch in the US with the most sunshine out of the whole US, and it's just basically Las Vegas and around the desert area here. I think it's something ridiculous like 300 and some days of pure sunshine. Which is nice, as I lived in San Francisco for 20 years, and it is the opposite of that. And I enjoyed that for a long time, but I enjoy this. Anyways.
So one of the things I wanted to bring up is, and we should talk about estimates. Because estimates are a big part of how you charge. And it is a difficult problem, and we have all sorts of issues that, I think, would be very interesting for listeners to hear that they're not alone in, and that we're still struggling with.
KEN: Nobody has a magic bullet. Nobody has a magic bullet on that.
TODD: It's a soft problem, it's definitely a people problem, and it's something that I'm actually actively working on all the time. But to finish up what we were saying before, we do find that weekly billing has worked out very well. It does require education. Your clients may instinctively go, "Okay, well they're just doing this to make more money because they're gonna get it done way faster, and they're actually gonna charge me this extra money, and they're not gonna do anything."
And that's a perfectly normal human reaction. But one of the ways that we added some sugar to that tea is we say, "A bug comes up, sometimes bugs take five minutes, sometimes bugs take a half a week to fix. That's all included in that estimate. You don't have to worry about that. No nickel-and-dimeing." When the estimate goes up, say we add person-weeks to the overall estimate, and then maybe we add some calendar-weeks...
By the way, we have typically a minimum team of two, and most times people work on one project full-time, so if you have a two person team on a project, we're producing two person-weeks per week. From that, and the number of points we estimate, we can calculate the calendar time, as opposed to the person-week time. And the calendar time does get extended, and the person-weeks do get extended. But it's always– not always, but it's usually from changes, and we try to be very good about being very transparent in explaining, and the client should know what all those changes were. They hopefully have approved them, and that's what adds the person-weeks and that sort of thing.
JAMON: There are some times where we will feel like maybe we made a mistake, in such a way that it was maybe, we're not comfortable charging the client more for a particular thing. And in that case we will adjust what we're billing for a particular chunk of a project. And we'll take on that risk. There's a shared expectation of being reasonable in this. If a client's asking for something, then we're gonna bill more. If we make a mistake, then we'll try to rectify that as much as possible. But it does have flexibility built in, and that's important. But then also, like you said, Todd, the bug-fixing is built in and things like that. That really helps mitigate the amount of risk that the client is taking on.
TODD: And truthfully, it's much easier for people doing the actual work, because they don't have to constantly, "Oh, this three-hour task is now a five-hour task, I have to ask permission for those extra two-hours, and it's just a lot of paperwork and a lot of thought about stuff that has nothing to do with making a great project."
But yeah, and I also want to add on to what Jamon just said, the way we deal with issues... Let's say the value wasn't there, we had some problems, we typically deal with it on the invoicing side. We tell our people, "Okay, for whatever reason we're not gonna be charging for these person-weeks." But from their perspective, it doesn't matter. They're estimating points, they're working during the week, they're getting at least a hundred points per person-week, and they just keep on going forward.
We'll adjust it on the back side, on the invoicing side so that our process keeps going and we have accurate data, even if we're in a situation where we made a big mistake or something like that, and we're not charging them for, say, a few weeks or whatever.
JAMON: Yeah, totally. And Ken, would you wanna talk about the chronic problem of under-estimating? 'Cause I know this is something that's near and dear to your heart.
KEN: Yeah, I don't know why engineers... I don't know if they want to feel like they, you know, they're really fast, or they feel guilty, or if it's imposter syndrome, or whatever it is, but it is a chronic problem. Engineers will estimate too optimistically. So we have sort of structures and practices, and this is not an easy problem to solve, right? But we have sort of structures and practices in place to sort of counter-act that, hopefully, whether it's sort of checklists like, "Have you considered these sort of failure cases? Have you included the bug-fixing and the testing time? Is the testing time including every platform that you could possibly use this on?" Et cetera, et cetera. Todd?
TODD: Yeah, this is a problem we have not solved. We really try to hire, and I think we have hired, really decent, ethical people. Which is fantastic, and that's the intention, and I very much enjoy working with almost everyone here (maybe not Ken, but that's okay). (laughter)
KEN: You can't fire me. (laughter)
TODD: I cannot. I've tried many times.
KEN: It's a perk of the job.
TODD: Actually, it's funny, because I've been working on this a lot lately. We hire good, ethical people, which I very much enjoy. But they tend to feel more guilt, and they tend to be a little... They contemplate it and worry about it a little too much, to be honest. And so we do have chronic under-billing.
One of the things we do is, we ask them for estimates, and we never ever– up to this point I've ever said, "This estimate's too high. You need to reduce this estimate." Because this is the estimate they're giving us, and they're gonna do the work, and it's not fair for us to come and say, you know, "You said it's gonna take a hundred points, I think it'd take 50 points." And of course when they do it and it takes a hundred points, they've failed, but only because in my opinion it should've been 50. We never do that. We never push back on that.
So you would think that just human nature, in order to alleviate stress, they would say, "Okay, that's gonna take 50 points, but I'm gonna make it a hundred and 50 points just to give me an allowance." No one does that, surprisingly. That is not the problem we deal with. It could be just our team. Probably not just our team, I'm sure there's a lot of people out there who do that.
KEN: I mean, I've seen this everywhere I've ever worked, right? People wanna feel like a hero, people don't... It's not as much fun to think about all the ways that things go wrong, well, depending on your personality I guess. But yeah, the ideal way that we're always striving toward is basically, the engineer gives us as accurate and conservative of an estimate as possible. And then in terms of how we present it to the client, if we feel we need to make an economic adjustment in order to get a sale, for example, then we will do that on our end. We don't want it baked into the estimate.
JAMON: And Todd actually ran an experiment with our own engineers at one point. He took a screen, I think it was a login screen of a project we'd actually already done-
TODD: Yes.
JAMON: -and sent it to several engineers and asked what their estimate was. Do you wanna talk about that, Todd?
TODD: Yeah, I've done a few of these to try to kind of understand this problem. In that case, it wasn't clear what kind of project it was, whether it was a mobile app, an iPad app, a website. I did that on purpose. I also didn't give them any requirements other than I gave them a screenshot. Which is not untypical to get from a client if we didn't do the design, to just get the screenshots. So I wanted to see A) how they approached the estimation process, and B) what their estimates were.
I'll skip to the spoiler part. The lowest one was like three hours? This is back when we did hours, we weren't doing points. The highest one was like 46 hours. So the range is three hours to 46 hours. Some people, their estimate wasn't accurate for obvious reasons, they got back to me within five minutes and didn't ask any questions. And that was more on the junior side, and that's perfectly fine. Estimating is probably one of the most difficult things that we do, and so it's understandable when people with less experience do it less well.
But the interesting part is that a lot of people didn't even ask what platform it was on. The person who did 46 hours, the highest one, had a huge write-up of all the reasons why it was 46. And when you look at it, you're like, "Yeah." Because it seemed very simple. Like, it's a login screen. It's two text inputs and a button that says "Login." But there's actually a huge amount of stuff. A lot of people assumed they were just doing the screen as opposed to actually making it work, like, making you log in to the backend, and Facebook integration and all this stuff. But the fascinating part is how different it was and their different approaches.
KEN: It should be mentioned, though, just for the record, that the way this exercise was set up was intentionally, on Todd's part, very vague. Right? It wasn't like, "Hey, I need you to do this for a client so that we can get a good estimate." It was a very off-hand... But the range of responses to that very vague setup was illuminating. Because some people are constitutionally incapable of not treating that seriously. (laughter) And some people are like, "Whatever Todd, I've got work to do." Right? So there's gonna be a very broad range there, and the range of real estimates is probably not gonna be quite as wide. But still.
TODD: Ken has a particular personality, and so does a few other people on our team, where he really didn't like the "gotcha" part of that question, the vagueness of it. And he felt like I was looking for a real answer and he was set up to fail on the real answer because I didn't give him any information. That wasn't the point of it. I actually didn't care what their answer was as much as the process by which they went around the answer. And I didn't say that, on purpose, too. And so he was a little bit like, "You're setting me up to fail, I don't like this, go to hell." Which was kind of funny. But it's funny from my perspective, but it's also illuminating. For people with that type of personality, that's the reaction they have to that, and that's a very real thing.
KEN: Well, it's also, like, if you just ask me a very vague off-hand question, I'm gonna devote a vague off-hand amount of attention to it. Right? And I think a lot of other people are gonna be that way too. It's kind of like, "Oh, okay, without any further information, why am I gonna spend an hour breaking down this problem for you?" Or however long it takes.
JAMON: I will point out that mine was both quick and accurate.
TODD: Yeah, I hate giving Jamon a compliment, but I thought Jamon's was one of the more accurate, and he did it very fast, and it was very thorough.
KEN: We brought Jamon on because he's lucky.
TODD: That's right. I have a rule: Every quarter, I randomly fire one of our team. And the reason I do this is very simple. I don't want anyone unlucky working at our company. That's a joke, in case anyone thought it wasn't. We don't horribly fire people because they're unlucky.
But yeah, so that's a very interesting thing on that. There's other interesting things too. Another experiment I did was, I had people estimate something simple again. Then they gave me the estimate, whatever it was– the numbers don't matter, but let's say they said 10 hours, and this is once again, back when we did hours. If they said 10 hours, then I would say, "Okay, what's the likelihood– are you 100 percent confident that you can do it in 10 hours or under? Are you 90 percent confident? 80 percent confident?" And then I would ask them, "Okay, how about eleven hours? How about twelve hours, how about thirteen hours?" And what I found is that the first estimate they gave me, almost no one was confident they could do it in that time. Which was fascinating-
JAMON: Yeah, it'd be something like 60 percent or something, and then you'd have to go quite a ways up before they were 90, 95 percent confident.
TODD: Correct. So I'm not sure exactly what to make of that, except for, that's a phenomenon.
JAMON: I did ask some of our employees that were doing an estimate to include a confidence factor. And that estimation is not done yet. It should be in the next week or two, and it'll be interesting to go through that and see where they landed.
KEN: Yeah, that would be interesting.
JAMON: There are some other reasons why you might not be confident. Maybe there are a bunch of unknowns that we will have to dig into before we'll know for sure, and there's no amount of hours that would satisfy that necessarily. But I think that that's something... You should give a number... Again, we're not doing hours, but doing the point system you should have your estimate units, of course, for each task, but then also include a confidence factor. And that might be a percentage or something that you're confident. I think that's an aspect that maybe will be helpful going forward.
TODD: To be clear, that's a hypothesis. Jamon has at this point, we haven't tested that. So take that as an idea.
JAMON: That's exactly right, yeah.
TODD: Another thing I asked them was, it's very fascinating, the same kind of line of questioning on giving them a very simple thing to estimate. And then I asked them, "Does that include tests? Does that include QA? Does that include bug fixes? Does that include any production issues when it goes out to the real world?" All over the map, whether or not they included, very few people said it included all of that. So when you asked them, "How long will this take?" They didn't take that question as, "How much time will you spend to have this completely done and you never touch it again?" Very few people took it that way. They more took it as, "I could get it done and in the app and then later we would debug it or test it or make changes or whatever, but that's not included in my estimate." So that was a fascinating result, also.
Now, I don't have any recommendations for any of this, other than it's very interesting to see how people's minds work, and how different people's minds work differently when they're given a task to estimate how long something will take.
JAMON: There's a couple of ways that we can mitigate that. Ken mentioned earlier, checklists. I think those are probably under-utilized. That's something that we should use more. So when you're looking at a screen, you'd have a checklist of things. And maybe some of them don't apply and you just mark them off. But some of them are definitely...
KEN: Yeah, there's something else that we're trying, which I've never really heard of anyone else doing, I've never encountered it before. We're trying to keep a database of past features so that instead of sitting and de novo every time, sort of like thinking through step-by-step every feature, you say, "Does this feature feel more like this one or that one?" Right? And then you just take the number that we actually empirically determined previously.
JAMON: So it gives you kind of an anchor point, and then you can determine if it's maybe more or less than that.
KEN: The jury's out on whether this could work as a system or not, but.
JAMON: Exactly.
TODD: What does "de novo" mean, Ken?
KEN: From the beginning, from new.
TODD: So, you replaced "from new," which is two syllables, with a three syllable word, "de novo." Okay, just making sure I understand. (laughter)
KEN: It has further implications, but whatever, Todd. Feel free to make fun of my vocabulary as much as you like.
TODD: I would make fun of your vocabulary, but the word "vocabulary" isn't in my vocabulary, so...
KEN: Obviously.
TODD: It's a vicious circle.
JAMON: So I think it's good maybe for us to go back a couple years, maybe. When we merged, we had... We try to be a little bit unconventional in our thinking. We try not to bring a lot of preconceived notions into what we're doing here, and think things through de novo, you know, start from the beginning, start from– you like how I did that?– start from first principles and kind of look at it in a way that... "Okay, can we innovate on this? Can we look at it and come up with something new?"
And we did, actually. And I don't actually remember whose idea this was, maybe one of you does, but we had the idea, "We're gonna bill hourly," was what our initial thought was. "We're gonna bill hourly, and then let's have a base salary for all of our developers and designers, but then pay them per hour billed that they personally billed." And it was an interesting experiment. I think we ran it for probably a year, maybe it was two years? Something like that, with varying success. And we learned a ton of things that you wouldn't when you just start out as salary employees. I will point out that we are now on salary. But we should talk a little bit about that experiment and what we learned there.
TODD: Yeah, that was... We had specific goals, and we had tons of good intentions for those goals. And like all good intentions, we fell on our face. But that would be a very interesting podcast in itself, the lessons... What we did, what we went through, what we changed to, and the lessons we learned during the process.
JAMON: I think to just kind of give it a really quick little thing, since we've teased it here, one of the things that we found is that people are generally not that motivated by money. Because they can certainly bill more hours and make more money, that was one of the benefits of the system, if you were very productive–
KEN: A couple people did.
JAMON: Yeah, some people did.
KEN: Some people took advantage of that.
JAMON: Yeah, for sure, but it was not anywhere near even a quarter of those people. So that was good to know. Other people, they were just motivated by different things. They were motivated, it's not that they're not motivated, but it just wasn't purely by money.
Another thing was that there were some situations that ended up not really being very fair. So, some people would be in projects where bill hours were very easy to come by. And others where we really either had to supplement their bill hours or something along those lines. It also didn't really encourage collaboration between people, so there's some silos.
The benefit to the company, obviously, is that if we're having sort of a down month because, you know, it's cyclical, then your costs go down. And the benefit to the employee is if you're having a really busy month, then you're getting paid more. But ultimately, that whole system, we went away from, and went to the system that we're using today.
TODD: Yeah, I can, in my opinion, it was a complete failure. That being said, it was, I'm pretty sure, originally my idea. And like I said, great intentions, but I think that was one of our biggest failures, to be honest.
JAMON: We learned a lot. I think that was the big thing. And those lessons will stick with us.
TODD: We learned a lot, and we changed, and, you know... But I think it was more painful than it should've been.
KEN: I forget where I sort of read/heard this advice, but basically, when you're starting a new company, you're trying to do something innovative, you should limit what you try to do that's innovative. Focus your innovation where it really counts, and then don't try to innovate too much in the rest of your business practices. I think that that's part of what we learned there.
Even setting aside all these sort of incentive things, there's a bunch of things that just work better when people are on salary. Right? Their benefits work better, insurance works better–
TODD: Vacation time.
KEN: -vacation time works better, there's a bunch of things where there's a whole ecosystem of support for how to run a business. And if you try to innovate in how you do that, you cut yourself out of all those things, and make yourself less competitive on the labor market. You make yourself... You know, you spend more time on things you shouldn't be spending time on. And so, you know, I think we've become in some ways a more conventional company in certain aspects, so that we can stretch out into places that we still want to stretch out.
TODD: It's so interesting you said that, Ken, because I literally give people that advice when they're starting out producing an app or a website or whatever it is. For the things that don't matter to your particular customers, or don't matter to your particular business, stick with tried and true. That's well-known, you don't have to worry about that stuff. Put all your innovation and your avant-garde ideas into the things that really differentiate your company from other companies. So it's so funny that you said that in respect to our company, because although we didn't apply it ourselves, it's advice we give.
KEN: Well, I had heard that advice before we did all of this. And the truth is, when you're there, you don't always know which one is the most important, right? So that's gonna happen. But it's worth bearing that in mind, to always be asking yourself the question, like, "What really makes us different as a company?" And if it's not this thing that we're doing and spending a lot of time on, maybe rethink that.
TODD: I'll personally admit to hubris.
KEN: What?! Never.
TODD: "We can do anything, and we'll just apply our big brains to it, and we'll figure it out."
KEN: Big brains are not the commodity that's in short supply. It's time, right? It's time and attention.
JAMON: I think I'll actually disagree a little bit, here. We've actually gotten the feedback that we all agree a little too much here. So I'll play the part of the devil's advocate here. I think it was well worth trying, and I think it was actually based on some things that we...
I think in certain cases, actually, it could work, I think it could be actually be something that a particular company could actually make work. It's just that we didn't like some of the side effects of it. Sort of like, taking a certain experimental medication. Maybe it works, but the side effects are not worth it. And I think that that's actually where we ended up with that. I wouldn't, like Todd said, I wouldn't necessarily classify it all as a complete failure. I think there were parts of it that were a failure. And I'm happy with the system we have now, but I'm also very much happy that we tried that.
TODD: It was 90 percent a failure.
KEN: It got us to the point we are now.
TODD: Well, sure.
JAMON: What's your confidence level on that, Todd?
TODD: I am 90 percent confident that it was a 90 percent failure.
KEN: Oh, man.
JAMON: Yeah, actually, I do have some thoughts on that. So, one of the questions that comes up is, "When you are selling fixed-bid or hourly, what do clients think? Is it hard to do?" And I've found that neither fixed-bid nor hourly are particularly hard to sell. Both are well-understood.
Our current system takes a little more explanation, and so I think that's something we need to continue to work on, our messaging on. But most people understand them. Some people have a problem with it. They'll say, "You know what, we're not willing to do hourly. That puts too much risk on us." And that's totally cool. It's not something that... maybe they're not a good fit for us.
KEN: Well, yeah, the thing is, whenever you're asking a vendor to assume risk for you... You're paying for it somewhere, right? You know, if they want you to be the insurance, then you're paying them to provide insurance. Either that, or they're mismanaged and they're gonna go out of business and then you don't have support.
You know, when we switched to weekly, I was concerned that we'd have trouble selling it. It doesn't seem like it's been too big of a deal. For the most part, people still mostly care about the total number, correct? And how you get there?
TODD: Correct.
KEN: They're not as, they're not usually as concerned with... We've had a few cases where... We had something recently where the upstream source of funds was a grant that had rules about how it's charged, so there's things that come up around that. So sometimes we'll make exceptions. And we have at least one enterprise client that we still use hourly. But for the most part, this has been pretty popular. We feel like it has the best of both worlds in some respects, that it has more predictability than hourly, but it still has built-in flexibility that a fixed-bid doesn't.
TODD: Our team definitely thinks the weekly is a success. It wasn't that difficult to convert clients from hourly to weekly, and for new clients, they don't seem to mind whatsoever. It's interesting from our team's perspective. Sometimes they could be working more than they used to, because they have to fix these bugs or whatever, but because they don't have the stress or the guilt, a lot of times of the hourly, they still like it better. It's kind of counter-intuitive, in that way.
JAMON: Yeah, I think there's three vectors, or three metrics that you would go off of, you know. "How satisfied is the client?" "How stress-free is it for the employees?" And then, "How much do we as owners like it as a business model?" And from those metrics, I feel like all three have been a success.
TODD: Yeah, it's definitely been a success. I think we could definitely do with hourly, but I think the weekly billing has been a huge success. I'm 90 percent sure that it was 90 percent a success. (laughter)
As far as the psychology from the client standpoint? We understand... One of the things we do, we hire a people who have a lot of experience, either they ran their own small businesses, they ran teams, that kind of stuff. We have a lot of people who have real-world kind of business experience. We're definitely not business consultants, per se, but we do work with a lot of start-ups who need some basic, not basic, but need some of our business consulting.
And one of the things that we do is we understand the risk involved. And there's a lot of companies like us don't talk about this at all. For example, from a client's perspective, it's a big purchase. If you're spending 100,000, 200,000, 500,000 dollars? That's a large purchase. If you're a start-up, that's a risky thing. So we try to really think about their risk.
Now, we have our own risks, too. We could put five people on a project for a few weeks, incur a huge amount of money, and they could just never pay us, go out of business, whatever reason. So we have risk as well. So we're not here just to alleviate all their risk and put it on our shoulders, being the insurance risk, insurance Ken just mentioned. But we do try to figure out a way to have a nice balance between us helping them with their risk, and them helping us with our risk, and just being up-front. Like, "This is risky, you don't know us. You've had a recommendation, maybe you liked us during a sales call so you're choosing us, but you really don't know us."
And we're a huge believer in gaining trust over time. So at the beginning, or whatever that word is Ken had, I forgot now, already, at the beginning, the risks are much higher. So we do put a lot of thought into that. Some clients, to be honest, aren't a good fit for our system. We're very happy to help them find someone who would better fit the system than us. So we do lose some clients, for sure.
JAMON: One way that some clients have asked us to share an undue amount of risk is when they ask us for hourly with a cap. That is sort of the worst of both worlds for us. If we finish early, we make less money, but we also take all of the risk of when it goes over. So we really do refuse, essentially, to do that.
Now, there have been some situations where we've put such a cap on ourselves because of particular circumstances, but we don't work for clients that demand that sort of thing.
TODD: Yeah, we have a general rule where we strive not to work for free. Which sounds funny, especially if you're in a different kind of business than ours, but it's actually super common for businesses like ours to work a lot for free, for nothing. And it's actually, in my opinion, a rampant problem in our industry. So we really strive not to do that.
I think that would probably come to a shock for a lot of people. If you're selling hamburgers, the concept, "Well, you know, 30 percent of the people walk through today, you're just gonna give them the hamburger for free." That would be shocking to them. But that's kind of like what people like us do, too much so, in my opinion.
Anything else on the psychology from the client standpoint that we could talk to, or talk about?
KEN: I mean, pricing is a huge topic.
TODD: Could you talk about pricing per week or per hour, the psychology? Because I know you've discussed this in the past, Ken, and I'd love for you to tell people.
KEN: Yeah, so one of the things we... We've tried a bunch of different ways of pricing. So one of the things we did before, we would only bill for extreme, like the instant we step away from the keyboard, the timer goes off. When we first started, we tried to do this. So we would charge like a pretty high hourly rate. But then, the actual number of hours burnt would be low. Nobody liked that. Nobody understood that, it was much better to bill in the way that people kind of understood about that.
When we would bill hourly, like an hourly rate, we're much more likely to get really kind of angry responses sometimes. To people who didn't really have a sense for what software costs. Because what people will do is, they'll look at the hourly rate, and they'll compare it to how much they make. Right? They'll go, "Wait a minute, that's what a lawyer makes!" Or something. It's not actually what a lawyer makes. But we would get this very visceral reaction to that.
But by doing it weekly, where we've kind of smoothed all that out, then they can kind of approach it more like a product that they're buying. Kind of like, "Well, it comes in this many chunks, and okay, that makes sense." So that, I think, was always one of the benefits of fixed-bid for people. Fixed-bid in sales has always been nice, because you can just say, "Here it is, and that's your price." Although, it's 100,000 dollars, they were like, "Well, my budget's 150, so I could do that." Right?
And with doing this weekly, although it's not quite there, it is a little bit like... The way we're doing it now is a little bit like fixed bid plus an extremely well-oiled change request process, basically.
JAMON: Yeah, exactly.
KEN: And that seems to solve both of those problems. Where it's like, they can look at that and instead of being some unknown number of hours, weeks seem like they're easier to kind of grapple with. And that's exactly what we want, right? I don't think we end up charging more, particularly. But it does come in these chunks that are easier to grapple with. They know what size the check are gonna be that they're writing next week because it's gonna be a certain cadence. It's not the surprise every time. It just seems to work better. Go ahead, Todd.
TODD: People will pay extra money to remove the surprises happily.
KEN: Yes, absolutely.
TODD: I don't think our weekly is more money, but even if it were, they would be happier. It's so funny, what Ken said is they associate their salary with their hourly, or even if they take their salary and divide it by 40 and divide it by 52 or whatever, and they compare it to ours, and they think, "Wow, these people are getting paid a massive amount." Of course, they don't see all the other business stuff. There's actually no–
KEN: They're not counting the overhead, they're not counting the things that they're not having to pay for.
TODD: I'm not complaining at all, but it's just a fact of our business: we actually have fairly low margins for a business type. Our team is extremely expensive compared to other businesses, extremely. Not saying we overpay them, I'm not claiming that, it's just the nature of their jobs.
JAMON: Yeah, and another aspect of this, and I realize we're going a little long here, but another aspect of this that we could talk about is that with the point system, it's not 100 points for each person, it's if we have three people working on it, the whole team needs to deliver 300 points. So they work together to divide up the work in such a way that maybe someone's doing 150, the other person's doing 50 but they're doing a lot of client communication. And allow them to divvy up the work in a way that makes the most sense to them.
Where with the hourly bonus structure that we had before, that would actually hurt the person doing most of the communication with the client. And that was a problem.
TODD: That's huge. And that was a decision we made. And because we chose that, meaning that we don't track individual contributions. I mean, technically we could probably figure it out based on Trello cards and that kind of stuff. But we don't track individual... It's team-oriented. So if it's three people, like Jamon said, it's 300 points. And we give them the flexibility to figure it out, how to be the best, most efficient to do those 300 points that they can. And I think that's worked out really well.
It has some downsides. It is harder to keep metrics on individuals that way.
JAMON: Yeah, a lot of what we do for that is to simply ask their teammates how it was to work with them, try to encourage them to be honest about their contributions and things. It's not a perfect system, but we are able to track individual contributions a little bit better, just through the perceptions of their teammates.
TODD: I do it more efficiently, I get 'em all in one room and I say, "Out of all of you, who's the worst?" (laughter) And then I let 'em... It's kind of like that inspirational movie, Hunger Games?
JAMON: The inspirational movie?
TODD: Yeah, so, and it's quite efficient, and you get right to the meat of it, literally, sometimes, to the meat of it.
JAMON: Literally.
KEN: And what they say is, "You are, Dad, you are!"
TODD: And I remind them once again, I'm not their father, that's Darth Vader. Fact.
JAMON: There's a lot more we could talk about here on this topic, this is probably something we could revisit at a future...
KEN: You may have noticed that we like to talk? Especially Todd. But, yeah...
TODD: My words are all very small, so I need lots of them.
KEN: We get very passionate about very dry things, sometimes.
TODD: There's some things to be said, too, on the subject of billing... It's a touchy subject, because although you can say that clients can be difficult in certain ways in regarding to this, it's all... Assuming that the client isn't a jerk and they're just trying to squeeze a rock for as much blood as they can, and let's assume that's the case, and most times that is the case. From their perspective–
KEN: Wait, you should be clear on what you're saying is the case. 'Cause otherwise, you mean... Most of the time, they are not trying to be jerks. That's what you're saying.
TODD: Most of our clients–
KEN: Okay, good.
TODD: Most of our clients are really great, and they're showing up, and they're partnering with us, and we're both working towards the goal of making something awesome. So if they are being difficult in a certain way that we may complain about in the background, they always usually have a reason why. It's usually a miscommunication, it's just something that they're misunderstanding on their end.
KEN: And like you said, presumably they're getting the software because they need it for some reason. Right? And it's a lot of money–
TODD: It's scary!
KEN: Yeah, it is scary!
TODD: And the last thing they wanna hear is, I mean, if you're doing a bathroom, you don't want a contract to come over and say it's gonna be from 50 dollars to 50,000 dollars. Which may be a true statement, but you don't wanna hear that, that's horrible.
JAMON: Well, one of the ways that we can mitigate that is if someone does have a fixed, like, hard-cap budget, which does happen and we understand when that is, then something else has to be flexible. And usually it's scope. We're not gonna compromise on quality. We wanna deliver really quality experience. But scope can be adjusted, and if a client is willing to work with us on scope, we can accommodate a tighter budget and still deliver a quality, but narrower scope, piece of software.
TODD: That brings up something very interesting, Jamon. It is a trade-off between low-price and low-risk. So, if we crank up the risk, we can give a quote at a very, the lowest price possible, because it may change. "We think we could possibly do it at this price." The easier thing to do is have a much larger price that reduces risk, but they're almost guaranteed to pay a lot more. Some companies hate the first one. They'd much rather have a much bigger price that's reliable and low-risk. Other companies, especially if they're really lean, they would prefer the first one. And the problem from our perspective is, we don't know who's who. And it's hard to get them to tell us, or they may not even know. So when you choose to go down one of those paths, do we give them as lean as possible estimate but we know it's much more likely to change? Or do we give them a much larger estimate that reduced the risk? When you're doing that, you're kind of choosing your customer at that point, too. It's all very complicated.