Remote Work Tools

06/07/18 • 56 min

In this episode we are talking about our remote work tools that enable our distributed team across the world to collaborate, design, and build software. Throughout the episode, Todd, Ken, and Jamon touch on their favorite tools—from Slack, Zoom, and Google Sheets—why they chose them, and the ways they have added custom features to really make the remote experience special.

Show Links & Resources

Episode Transcript

CHRIS MARTIN: The topic at hand today is remote tools, and all of the different ways that you have built a remote company. Where do you even start when you're thinking about what tools to pick when you're going remote?

KEN MILLER: This is Ken Miller, by the way.

It happened very organically for us. To be honest, I don't know that we could've done this company this way before Slack. Because the tools that came before, Hipchat and IRC and Yammer, even though I worked there. Sorry, Yam-fam. They just didn't quite do it. Right? They didn't quite create the online atmosphere that we need to work the way that we do.

Does that sound accurate to you, Todd? I feel like once we found Slack, we were like, "Holy crap, this is epic!"

TODD WERTH: I think there's a few alternatives. Hipchat, at the time, wasn't good enough. There were a few alternatives we investigated. I would like to mention at the beginning of this ...

This is Todd Werth, by the way.

I would like to mention at the beginning, I imagine that a lot of companies in this podcast will need to be paying us an advertising fee. Like Slack.

JAMON HOLMGREN: We actually adopted Slack before we were remote. We had ... I think we were using Google Hangouts or something. Or whatever of the myriad Google chats there are out there. They have like 12 apps. We were using something else in person, and then we started using Slack organically right when it first came out.

TODD: Sorry about that noise you all heard. That was me throwing up a little bit in my mouth when you said "Google Hangouts". (laughter)

KEN: We'll talk about video-chat in a minute.

JAMON: By the way, this is Jamon Holmgren.

It was ... Initially, we jumped onboard. They did a really good job marketing themselves. We had used Hipchat a little bit, but it just wasn't what we expected. We started using Slack. That was in early 2014, I think it was? I don't think it's a coincidence that within a year and a half we ended up going remote. I think that was one of the enabling tools.

We got used to it in the office, but it enabled remote work.

TODD: To talk about chat apps or chat services is important, but on a more general standpoint, I would say how you approach it is actually try 'em and do it. A lot of companies seem to just use whatever is available and not look for optimum solutions. If trying three or four different chat systems is too onerous for you, that's probably the wrong attitude, in my opinion.

KEN: You think, "don't settle". Don't assume that the first thing that you try is the only thing, and then conclude that remote isn't gonna work because the tool that you tried sucks.

JAMON: We tried a lot of tools at ClearSight, before the merger. We tried ... I can't even name them all, to be honest. Part of it is because I like ... I'm a gadget guy, I like to try new things and see how it goes. There was actually a lot of skepticism around Slack because they're just yet another tool that they had to log into and pay attention to. "We already had the email, so do we really need this." It was kinda funny, when I went back and looked at our inner-company email, just tracked ... I think I used the "[email protected]" or something email address to track how often we were using it for company communications. It just dropped off a cliff after Slack.

The amount of email, the volume of email that was flying around went way, way, way down. In fact, I remem...

Show Links & Resources

Episode Transcript

CHRIS MARTIN: The topic at hand today is remote tools, and all of the different ways that you have built a remote company. Where do you even start when you're thinking about what tools to pick when you're going remote?

KEN MILLER: This is Ken Miller, by the way.

Does that sound accurate to you, Todd? I feel like once we found Slack, we were like, "Holy crap, this is epic!"

TODD WERTH: I think there's a few alternatives. Hipchat, at the time, wasn't good enough. There were a few alternatives we investigated. I would like to mention at the beginning of this ...

This is Todd Werth, by the way.

I would like to mention at the beginning, I imagine that a lot of companies in this podcast will need to be paying us an advertising fee. Like Slack.

TODD: Sorry about that noise you all heard. That was me throwing up a little bit in my mouth when you said "Google Hangouts". (laughter)

KEN: We'll talk about video-chat in a minute.

JAMON: By the way, this is Jamon Holmgren.

We got used to it in the office, but it enabled remote work.

KEN: You think, "don't settle". Don't assume that the first thing that you try is the only thing, and then conclude that remote isn't gonna work because the tool that you tried sucks.

The amount of email, the volume of email that was flying around went way, way, way down. In fact, I remem...

Previous Episode

Clients and the Value of Ideas

In this episode of Building Infinite Red, we are talking about clients and some of the assumptions that often need to be challenged when creating software. Throughout the episode, Todd, Ken, and Jamon touch on the importance of knowing who your audience is, what they value, and how your ideas will meet their needs.

Show Links

Episode Transcript

CHRIS MARTIN: Today we are talking about clients. It's an important topic and one that pretty much every business owner inevitably gets asked a variety of questions. The question that we could start with is: what's your favorite moment in working with clients?

JAMON HOLMGREN: You would think it would be when you launch their app or their site, or something like that, but I often find that actually to be a little bit anti-climactic 'cause there's so much going on. There's usually already plans in place for a version 1.1. It's not usually like everybody gather around the big green button and then the founder pushes the button, and it goes live. Although a little side note, Mark Rickert, who is one of our developers has released an app to the app store while in free fall during a skydive.

That is true. We can link to it and there's a YouTube video of it. But that's not usually how it works.

KEN MILLER: It wasn't a client app I don't think. I think it was one of his apps, but still.

JAMON: That was a pretty cool way to do it. But no, you would think that would be the most exciting time. The exciting time is usually during design, for me, because I feel like you start getting a lot of enthusiasm, the energy. A lot of those things start coming out during the design process. And when we get a chance to use our design process—some clients will come to us with something already designed, others will come to us who need design. When they're going through the design process, it's really exciting, you can see a lot of the possibilities. The development side of things is also fun, but a little slower moving.

TODD: I agree with Jamon on the design side. Once we get through the product development and start getting into design, probably past the wireframing and into some more concrete examples, it's pretty fun to see the client get really excited. Especially if it's a situation where they show people who are interested in their product, or their stakeholders and investors, or whomever, and they had a good reaction to it.

I would add the second most fun time with clients is once there is a beta or an alpha available for their beta testers. And again, they send it to them and they use words like "blown away," or something like, that's awesome. I'm not gonna lie and say, that's always what happens, but those two times I think are the most fun to me.

CHRIS: One of the things that Jamon wrote in Slack that was interesting is: what are some common assumptions that clients bring to the process that have to be corrected?

TODD: I don't know if there's anything that's common or consistent across clients. There are some things that come up. I would say, depending on the experience level of the client with software product development, we may have a little to a lot of teaching to do. And that's one of the things we like to do is teach.

I find it particularly fun when our start-up clients are newer, they're not on their series B or something. Because there is a lot of moments that you can help them and give them kind of golden information. Both from our personal experience running start-ups, but also we work with a lot of start-ups. So we've been through this before.

There are some misconceptions about software. Not necessarily from our clients, but from people who weren't a good fit for us. For example, it's very common in the world at large, to believe software is orders of magnitude cheaper than it really is. People also get very used to the quality that they see in apps like Facebook or Gmail, or these kind of things. And they think they can spend less than a car to get those things.

When you're in our industry of course, that doesn't seem super logical, but from their perspective it makes sense. An app costs nothing, or $1.99.

JAMON: Right.

TODD: Or $4.99, so of course something like that seems cheap. What they don't know, of course, is Facebook has tens of thousands of employees.

JAMON: Y...

Next Episode

How Should I Charge For Software Development?

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.

Episode Transcript

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 ...