Episode 193 | Distributed Team Collaboration for Startups

Startups For the Rest of Us

Episode 193 | Distributed Team Collaboration for Startups

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds

00:00 /

Apple Podcasts Google Podcasts Spotify Stitcher

RSS Feed

Share

Link

Embed

• Facebook
• LinkedIn
• Twitter
• Email

Show Notes

• SqlSmash by Latish Sehgal
• Remote: Office Not Required by Jason Fried & David Heinemeier Hansson
• Episode 64 – Hiring and Managing Remote Developers
• Episode 68 – How to Hire and Manage Virtual Assistants
• Episore 143 – How to Hire Like a Bootstrapper with Special Guest Laura Roeder

Transcript

[00:00] Mike: In this episode of Startups For The Rest of Us, Rob and I are going to be talking about distributed team collaboration for startups. This is Startups For The Rest of Us episode 193.

[00:07] Music

[00:15] Mike: Welcome to Startups for the Rest of Us, the podcast that helps developers, designers and entrepreneurs be awesome at launching software products, whether you’ve built your first product or you’re just thinking about it. I’m Mike.

[00:23] Rob: And I’m Rob.

[00:24] Mike: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s going on this week Rob?

[00:28] Rob: We, meaning you and I and this podcast appeared on the floor of Google IO last week.

[00:34] Mike: Wooo Hoooo!!!

[00:35] Rob: Yeah. We were contacted by Michael Mahemoff. He’s the creator of player.fm. Which is a podcast app. And he said that 13 companies were invited by Google to participate in the developer sandbox at IO. And he emailed us. He wanted to find out if he could basically use our logo or use us as one of the place holders in the big player.fm app on the floor.

[00:58] So, it was really cool. He sent me two pictures of what the display looked like. You can see our logo. And it’s huge on this big on this extra large monitor. That’s always exciting. It’s kind of a nice tip of the hat and I really appreciate it. You know, Michael doing that for us.

[01:11] I have not checked out player.fm. I have since downloaded it. And let me tell you it’s quite a bit better than the built in Apple podcast app. Which I have been looking to leave for…Well, since pretty much the day they launched it. I think I might be trying to start migrating to player.fm.

[01:28] Mike: Got it. I’ve been using Casts, which is an interesting app. I like the fact that you can just set it up to download everything in the background. And you can set up these filters so that you can filter in different criteria. And what I do is I set mine up so that it is unplayed and then I have it unplayed by date in reverse order. So that way if I’m behind at all I can just catch up in the order that the podcasts were received on my phone.

[01:50] Mike: So it’s kind of nice it doesn’t make you go episode 30 then 29, 28 ect. You go the other direction. So that’s kind of a nice feature. And then like I said, it just downloads stuff in the background while you’re connected to wifi. And you don’t necessarily have to worry about it. It pops up little notifications to let you know that new episode have been downloaded. It cleans up after itself after things have been played. And you just have to delete stuff afterwards.

[02:13] Rob: Yeah. None of those things happen in the Apple podcast app. It’s a mess.

[02:17] Mike: The biggest problem I had with it was it would start to download an episode and then wouldn’t download the whole thing and if you were not home or on Wi-Fi then it would say “Oh! I can’t play this would you like to stream it?”  I’m like; I don’t really want to be sucking up all my data.

[02:31] Rob: But even then if it got stuck in the middle and then you tried to stream it, it would choke.

[02:35] Mike: Yeah. Well, we got an email from Latish Sehgal. And he says “Hi, guys! I’ve been a regular listener for the last year or so. I’m a developer and love building tools and utilities. Over the last year I worked on one of my side projects and launched it last month. It’s called SQL smash. It’s productivity plug-in for people who work with SQL server. I have a few paying customers and I’m getting a lot of good feedback. I’ve made mistakes on this journey but have avoided a lot more because of everything you guys talk about. Just wanted to drop a note and say thanks.”

[03:00] Rob: Very cool. Congrats Latish.

[03:02] So, we have some new iTunes reviews, several actually. One is from Santa Monica Boone and he says “Best podcast for how to do anything in business. Podcast gets right to real advice on how to implement tactics. There’s no fluff, filter or lame teasers. Content is not just for software startups any business can benefit from Rob and Mike’s advice.

[03:22] I have another one from Lucas. And he says, “Amazing show-always learn something. Love the show and listen to it all the time. Rob and Mike always have interesting items to talk about and they don’t “talk down” to the audience at all- they move at a fast pace that is perfect for any developer looking to start a business.”

[03:36] We really appreciate 5 star reviews in iTunes. It helps us out tremendously.

[03:41] Mike: So we are slightly behind on this announcement but June was back up awareness month. And in the spirit of that I recently had a hard drive in my network attached storage device die on me earlier this week. It’s a 1.5 TB drive and fortunately I didn’t lose any data because I have everything at rate six already but I ordered 4 new 2 TB drives for measly $330.

[04:04] Rob: Oh Jeez.

[04:04] Mike: [Laughter] I think I paid more than that back when I bought one of my first computers for a 1.6 GB drive

[04:11] Rob: Incredible, yeah I paid more than that for my hard drive on my Apple IIe. That’s for sure. It had…but it wasn’t hard dive, I’m sorry. It was a floppy disk drive. It had no storage. [Laughter] Ahhh. That’s crazy.

[04:22] Mike: Crazy how much things have advanced. And how cheap, just computer parts in general have gotten.

[04:27] Music

[04:31] Mike: Today we’re going to be talking about distributed team collaboration for startups. And some of the topic sections are kind of pulled from the 37 signals book called, Remote: Office Not Required. So what we’re going to do is we’re going to talk through some of the different general topics of the book and kind of give it our own unique spin for much smaller teams.

[04:49] Rob: So, it looks like you’ve put together 5 points and each of those points has several specific items that we will be talking about. This first point is why you should think about hiring a remote team.

[04:59] Mike: Yeah. And I think the first one is for somebody who is starting a small business or running a small business, the first one is probably the most important one, which is it’s a lot more cost effective both for hiring the people themselves and for avoiding the office costs. Office costs tend more to be more of a sunk cost. I mean, you put the money in. You don’t necessarily get anything out of it. And then in terms of hiring people you are somewhat limited to the people that you have in your geographic vicinity. One problem that I had, for example, I put out an advertisement to hire people, several years ago, because my office was located near the monster.com office my advertisements for employees were getting overrun by their advertisements on their own website. Which totally sucked. I complained to them and everything.

[05:42] But the issue of course is that if I want somebody to come into my office they have to be located near me. And within a reasonable commuting distance. I know that there’s people out there who have 2 and 3 hour commutes each way. And that absolutely sucks. I mean, that’s probably part of why a lot of people gravitate towards building their own businesses. But when you kind of extend your reach and you say “Hey! I don’t care about you coming into an office. I don’t need you to do that.” Then you can extend your reach across the globe. And then you can use things like Odesk and outsourcing facilities and lots of other ways to get quality people in the door to help you build a unique business.

[06:19] Rob: Yeah. And I think you touched on two things there. One is that it tends to be more cost effective. And the second is that you’re not limited to geography. And so you can find the best talent in the world, at basically the budget that you can afford. I think another reason to think about hiring a remote team is that generally people like working remotely. Right. They like either working at a co-working facility working at their house and to be able to save time and avoid a commute and avoid sitting in traffic with everyone else. That flexible telecommuting type situation. But a lot of developers that I talk to that work for big companies, they’re still grinding it out on the 405 in L.A. an hour each way, you know. What is that 10 hours a week of wasted time? And not only is that exhausting mentally but it’s a huge time suck. And it’s time you can’t spend with your kids or you can’t spend working, frankly, developing the product.

[07:06] So, I think that the benefit, the perk of allowing people to work remotely not only benefits the employee but the employer as well.

[07:13] Mike: I mean, with something you just mentioned there, is if you’re spending two hours a day commuting, that’s 10 hours a week. That’s an extra full day of work that you’re not actually getting anything done, which totally sucks. You know both for the employer and for the employee.

[07:26] The other thing I think that people tend to forget a little bit about when you’re putting together a distributed team is that when you have a distributed team it means that any sort of office disaster is not nearly as destructive to the productivity of the team. And by office disaster I mean the electricity goes out or there’s a storm. I live in New England. So snowstorms are fairly common. And that will just kill productivity because you don’t necessarily want people to come into work at that point anyway but then you also have to deal with the aftermath because of the weather. And sometimes there are power outages that go along with it. If people are working in a distributed fashion that might happen to one or two people but that doesn’t necessarily happen to everybody all at the same time.

[08:03] Rob: Yeah, this is one that I haven’t really counted on or thought of as a big benefit in the past. But I do suppose that if you do have customers around the world it’s nice to have folks in time zones around the world, both to handle support as well as get around local disasters like you’re saying.

[08:18] Mike: When you’re talking about putting together a distributed team there’s a lot of common objections that come about. And many of these come from what I’ll call the big company line of thinking. One of which is how do I know that people are working? How do I keep my data secure? How do I keep things moving along because they’re not working in the same time zone as I am, so I send them a message and it takes 4 hours or 8 or sometimes 12 hours to get a response back. Which means you’re kind of pushing answers into the next day.

[08:45] Those are some fairly common objections. All of which have some fairly straight forward answers. In terms of knowing how people are working, you just look at what they’re doing. Whether it’s…If they’re developers you can look at code commits, whether they are closing out bugs anything like that. I can almost guarantee that in large companies there are so many different ways that data can be lost or compromised that it almost doesn’t matter. You’re almost on par with the large companies as you are with a small company in terms of data security. And obviously you have to do at least the bare minimums, like making sure that you don’t have open firewalls and you’re running antivirus and basic things like that.

[09:21] But at the same time you don’t necessarily have to worry too much about losing IP because really the marketing behind your products is the core of it. It’s not necessarily about the code or compiling everything. It’s about all the different business processes that you are putting in place. That’s where the value of your business is. Not necessarily just the source code.

[09:40] Rob: I understand both of these objections, I think. How do I know people are working is reasonable. Right, it’s a reasonable concern to have especially when I’ve worked with contractors internationally, some of whom took advantage of the fact that we were remote. And they basically just billed me for hours that, in retrospect as I looked through stuff that they were not working. And that’s one of the reasons that I really liked when Odesk came out with their thing that actually gave you screen shots every 5-7 minutes.

[10:07] Because it was a really effective tool for managing people. And now anyone I work with who I don’t know already I will ask them to use Odesk. Working locally here now that I have a couple of developers that I work with. I know these guys well enough that if one of them moved away; I know they are working because I trust them. This trust has been built up through a relationship and through working close with people. So, to me that those are the two sides of it. If you know and trust them then you know they’re working. If you don’t know them well enough to trust them then I think you need to fall back on some software whether it’s Odesk or there are actual third party apps that you can buy that will monitor what people are doing, with their permission of course. You tell them this is a condition of getting hired or whatever. And they have to install it and it will send you screen shots. Or of you don’t trust your employees. And that’s just a problem, right? Then I think you’ve hired the wrong people. If you do know them well enough and you still don’t trust them. That’s kind of a whole other issue that I think is unrelated to whether or not they are working remotely or not.

[11:03] Mike: One of the things that the book Remote brings up is that if you can’t see somebody. If they’re not in your line of sight then you have a much harder time feeling like you’re in control of the situation. And what they’re working on and what they’re doing. And I feel like that’s more of a mental hurdle than anything else. There’s lots of people who just because they’re sitting in a chair does not necessarily mean they’re working. If you can see them that doesn’t necessarily indicate progress is being made. It’s really what you need to focus on is the work itself as opposed to seeing them as a person.

[11:33] Rob: Yeah, I totally agree. I do agree with the objection of “How do we keep things moving along because of latency issues”. Because that is probably my one biggest hang-up that still gets me to this day having worked with dozens and dozens of remote workers for the past, what?, 7 years maybe, is the latency issues. And I’ve figured out some work arounds and ways where I will stay up late. And make sure to work on that stuff late or early so that if I do have questions they’re at least online and they can back to me and stuff. But overall I think, this is the…Perhaps the biggest drawback for me, is that if people are not in your same time zone there’s just latency and in my opinion the other positives outweigh it. But I don’t know anyone who is getting around this that effectively.

[12:16] Mike: And that’s something I have a little bit of trouble with as well. What I’ve found is that, you suggested one mechanism for handling it which is kind of arrange your hours to overlap with the people who are working in different zones. Another one that is helpful, but obviously not something you can do all the time, is if you’re able to plan far enough in advance to be able to have them working on something that isn’t necessarily time critical. Then you can ask them questions about it and kind of have a couple of different things going on at the same time. I do find it when a project sprint is coming down to the wire and you really need things done on a specific time schedule. That’s when it becomes much more of a problem. At that point you really have to just start adjusting your schedule to be able to get the answers you need. But otherwise you can sort of slip stream things in as you’re working.

[13:04] Rob: Another common objection to having remote workers is that you won’t have a company culture. And if you listen back to episode 143 of this podcast where we had Laura Roeder on the show. One thing that she said that we discussed at length was that she says that every company even companies with remote workers have a culture. And that you need to be deliberate about it. And the companies that I’ve seen make the remote thing work. They definitely have a culture. And they have a culture whether it’s be it through their email system, whether they’re all in kind of a chat window at the same time, whether they meet up once or twice a year as a group but there’s definitely a culture and a vibe to the company. And I think it’s …It’s possible to have it. It may not be as easy to have as when everyone is in the same office. In fact I know it’s not. But it’s still possible to have a specific culture and a specific, kind of, mentality that everyone at the company embodies

[13:58] Mike: Yeah, one of the things that I’ve found that’s pretty helpful for keeping everybody on the same page in terms of company culture is getting HipChat up and running. HipChat basic is free right now. They recently changed it over. Previously it was up to five users it was free. And now it’s unlimited users and it’s free forever. So, you can just install HipChat on your Windows machine or your Mac machine. And it will just be sitting there running in the background and it’s basically just a nice private instant messaging utility that everybody can be on. They also have HipChat Plus which is only $2 per user, which gives you video chat and screen sharing and several other features. But again that’s still very very cheap for what it is.

[14:39] Rob: Right. And the other tool, that Ruben actually just mentioned to me today, is Slack. Slack.com. And supposedly it has a better UI than HipChat. Definitely has mobile versions and all types of stuff. So, I think those are two pretty good options if you want everyone to be basically chatting all day or available to chat during the day. I think those are pretty good ways to do it. I think the last objection that we’ll look at is “Who will answer the phone?” And this one’s laughable. I’m pretty much going to skip it. Because in this day in age with IP phones. It’s like, you can have a phone number and you can actually have more people answering it at more hours of the day if you have them on multiple time zones, right? You don’t need a physical phone in a physical location in order to do this.

[15:19] Mike: Yeah. I think that even, I’d say probably 3 years ago this was a much bigger problem because I think it’s only been in the past 2 or 3 years that it’s been a lot easier to have essentially a virtual PDX that you can, kind of, manage from your phone or manage from the web and be able to redirect people to from a centralized number to be calling different people in your organization. So, like I said, even 3 years ago I think that it was a lot harder than it is today. I mean, today you can just sign up for a Grasshopper account and you’re up and running.

[15:51] Rob: So, we’ve talk about why you should think about hiring a remote team, talk about common objections. The next step, the third point we have here is how to hire a remote team.

[16:01]Mike: Yeah, so I don’t know as we should dig too much into how to hire people because I think that we’ve talked about this quite a bit before in three different episodes that I can think of; episode 64, where we talked about hiring and managing remote developers. And then in episode 68 we talked specifically about how to hire and manage virtual assistants. And then again in 143 we talked about how to hire like a bootstrapper. And that was the one with Laura Roeder.

[16:25] So I think we’ll go on to the next one which is how to collaborate effectively. And the primary thing here I think to keep in mind is you really need to be using web based tools, especially ones that you are not actively managing. You know, there’s any number of services out there for all kinds of different tools that you can sign up for. That most of them are subscriptions based but you just pay that monthly fee. And you can add in the users that you need to be able to access the system. Whether its wikis or bug tracking, source control. I use a combination of things like Basecamp, HipChat, Skype and then there are all these CRM systems out there like PipeDrive and Act CRM. You can also use Grasshopper if you need phone systems. You can also use WebEx. I use a WebEx account. There’s  … You can also use GoToMeeting. GoToMeeting and WebEx are pretty comparable I think in terms of features. But those are all the different tools you can use and just sign up for an account for them. And it’s like I said some of them are free. And you can use them until you get to a certain point. Once you get to that point chances are really good that your business is in a position to be able to pay for those services.

[17:24]Rob: Another tool someone told me about just today is called I done this. Idonethis.com. And it’s basically email as UI. So everybody on your team gets an email and they reply to it and I done this parses though it and gives everyone a status report the next morning with what everyone accomplished. And if you’re running into things you can comment on their stuff. But it just tracks your progress every day. This is obviously not a real time thing but it can be super helpful for distributed teams. And knowing what’s going on on your team. Because even whether you are the manager of the team or you’re just a member of the team it’s a good tool to know what everyone else is up to.

[17:58] Mike: Another key piece of collaborating effectively with your team is to try to operate on a non interruptive schedule. And by that I really mean make sure that you’re reserving voice and instant messaging communication for critical items. Not the everyday stuff. For all of the everyday stuff use email. Use something like I Done This. There’s also a service you can sign up for called 15 Five. It’s the numbers 15 and then f i v e. com. And essentially what that does is that … You’re essentially getting these weekly reports from people to help the management stay informed about what’s going on. And does I Done This go to everybody or just the managers?

[18:37] Rob: Everyone.

[18:38] Mike: I think that 15five only goes to the managers, but I could be wrong on that. But I came across that a few weeks ago as well. But the idea there is that you’re really trying to get information from people and surface it in a way that does not interrupt your daily flow. And leave it up to the people who are working to not only get their jobs done but at some point communicate information back. And that kind of goes back to the latency thing that we talked about a little bit before. And if you can kind of plan around that you’re impacting people’s productivity a lot less which allows them to get more done.

[19:09] Rob: Yeah, I have heard of some remote teams who are in a chat window all day. So they’re in CampFire or HipChat all day. I did that about 10 or 15 years ago when I worked at a dot com startup in the first wave of the dot com boom. And it was great fun but it was not very productive. And these days I have no chat windows open ever. And if my team needs to get a hold of me then they email me. If they need to get a hold of me urgently they text me. Those are the ways that I want to be contacted because I’ve found that being in a chat window, for me personally, it leads me to either get interrupted more than I want or to interrupt other people more than I want. Because if something pops into my head I’ll just ask them and often times it’s better to just have to wait. Right? It’s better for the whole teams productivity if it’s not as easy for me to just interrupt somebody and if I kind of get the discipline where I can just send someone an email and then wait for it. And then if there is something urgent then we do communicate on the spot but other than that. Personally I am not a fan of this. Not to say that this is right or wrong to all be in the same chat window, everyone has their own working style, but that’s the direction I tend to lean.

[20:15] Mike: Yeah, I think that just comes down to just how you’re comfortable working and how your team’s comfortable working. We use HipChat. And it’s kind of nice. But if I need to get work done I’ll put myself on do not disturb. So that even if stuff goes in there I don’t end up seeing it. But you can also just use email to schedule time to say, “Hey, can you get on chat. We’ll chat at such and such time.” One thing that I like doing is using a common set of sprints or scheduled milestones to get people working towards the same things at the same time. Remember before I talked about how if you have a couple of different things going on at the same time if one of them is sort of a blocking issue and you need an answer to move forward on it, you can kind of switch to the next one. It’s nice to be able to kind of aggregate some of those into a specific sprint or a scheduled milestone so that everyone is working toward the same goal. And they know when those deadlines are coming up.

[21:02] They know when that stuff’s got to be done. So they’re rearranging whatever their personal lives schedule is in order to be able to meet those. And it’s nice because then everybody is on the same page. I find that just having those, I’ll call them snapshots or of points of where people’s work crosses one another, you know, converge. That can be very very helpful for keeping people on track. And not only meeting that particular milestone but meeting further milestones moving forward.

[21:28] Rob: Yeah, I think this makes sense if you’re working on big features in separate subsystems. Right. And this allows people to sync up and not just do integration testing but see how the whole app works and get an idea of how everything is working together. I think with our stuff with HitTail and Drip since we are building and deploying new features constantly. I mean, we may do, there are days we do multiple deployments in a day. And launching tiny little features as they’re done. We have less of a need for this. We don’t really have, aside from like the rules engine, that was a milestone. Aside from that we don’t tend to have many grouped launches of features. They just tend to go out when they’re tested and when they are ready. There doesn’t tend to be so much overlap between work people are doing. Now I also don’t have 5 developers working on one product either. People are kind of spread out among multiple products.

[22:19] Mike: If you’re deploying a lot of things very very quickly then having those sprints or milestones doesn’t make nearly as much sense. But it’s obviously the things that are a little more complicated. And your situation also with those developers is a little bit different because they’re working in the same office. So, it’s a little bit easier to coordinate some of those things because you can just stop by and talk to somebody. And hash things out over half an hour and that’s not to say that you can’t do that over Skype or through a chat message or something like that. But obviously some of those things play into it a little bit.

[22:49] Rob: Yeah. That’s true.

[22:51] Mike: So I think the next section we’re going to talk about is some of the common pitfalls that people run into. And I think the first major one that I’ve seen is that people are not on the same page. If you set yourself up as the manager for a bunch of different people who are working for you and you don’t keep everybody informed about everything that’s going on. Then everybody feel like they’re in a closet and in the dark. And they don’t necessarily know all the other stuff that’s going on and they don’t know the interdependencies between the stuff that they’re working on and the things that other people are working on. And I find that that is not helpful for the team morale but it’s also not helpful for making sure that people are kind of working on their timelines and deadlines. So, if somebody doesn’t know that there’s 4 or 5 different things coming together and they just know what they’re working on and they say “Oh! It’s got to be done by Friday.” But if they know that there’s 3 or 4 other things that are also coming together on Friday and there’s a press release or something like that going out. Or some new marketing campaign and if they don’t get it done everything is going to be held up because of them. I’ve seen that this has kind of a motivational factor to it. People tend to make sure that they buckle down and rearrange their schedule to be sure those deadlines are being met.

[23:57]Rob: Yeah, I think there’s a lot of ways to get people on the same page. The daily check-ins that we talked about with 15five and I Done This is a really nice way to keep people communicating. I think another way is to have coding standards. And style guides for HTML/CSS and that kind of stuff. This sounds like big company stuff but its shocking how once you have two or three developers working on the same project. Things like how many spaces should a tab be in your editor? Should you always run the clear trailing spaces command when you’re done with a file? Are the variable names upper camel case, lower camel case or do we put under scores in the variable names? I mean there’s all this kind of stuff and if you want consistency in your code files then this is stuff that even a one page doc can do wonders. If someone is able to refer back to that. And there’s some pretty good examples of this, there’s a GitHub ruby style guide and I think there’s one for CSS as well. If you read through it, it’s like “Yeah. This stuff makes sense.” They’ve done a good job in a very short amount of time. This is not a 50 page style guide. Its one to two pages but they communicate a lot with it. And I think being able to document that in one place where everyone can go back to. And it’s living and breathing too, right. We can go in and edit it. And anyone should be able to keep it up to date as it goes. It’s not set in stone. But just to have a common understanding, keep your consistency across all the technical assets you have will keep that consistency high.

[25:21] Mike: Yeah. And some of those things you can do with technical controls as well. So like for C# there’s things like Style Cop and FX Cop that you can use to essentially do a static code analysis of the software that is being written. To make sure that it is conforming to whatever the style guides that you’ve set forth are. And then you can just integrate it directly into the build process. If somebody checks some code in that doesn’t meet the style guidelines you can kick it out and say “Hey! You’ve got to go fix this because it’s not passing. The build server’s crashing on it.” It says “No! I’m not going to allow you to build this and push it out because you’re not following the style guidelines.”

[25:54] Another thing you can do is incorporate some of those things into just standard operating documents or procedures, some of your general operating guidelines. As long as people generally know how the business is being run and this isn’t just necessarily about software development. But how the business processes are done. If they run into a situation where they’re going to be doing something and there may very well be a situation where somebody could come in after them and have to do it themselves. They should be empowered to go in there and modify those to be able to document that stuff and say “This is how it is done.” And if we need to change this process later on it’s not a big deal but here’s the documentation that explains how to do this.

[26:31] My bookkeeper’s actually been really good about documenting the things that she’s been doing and adding them into our Google Docs so that she just links to them from our standard operating documents. And just puts it in there so that if she ever moves on and goes to do something else then whoever comes in afterwards and picks up the books can go in and basically pick up where she left off. And know exactly how everything is supposed to be done. And if they don’t like it they can change the documents and change the process. But you need to be able to empower these people to actually do that stuff, so that everybody’s doing it consistently.

[27:02]Rob: Another common pitfall that we have listed here is employee burnout. I have to be honest I’ve never encountered this. And I don’t know if it’s the culture of the company here or it’s just the folks who I’ve hired specifically but I haven’t had anyone kind of work themselves into the ground. Do you think this is a common pitfall?

[27:19]Mike: I think it’s a common for the founder of the company.

[27:21]Rob: Ahhh. Got it.

[27:23]Mike: Yes, I don’t know that it’s so much for the people who are, you know the contractors, especially for contractors I’ll say. Because with contractors I think the issue is, like, they’re getting paid however much they’re getting paid for however many hours. So, you know generally speaking how many hours they’re working because you’re paying them for that. So, if they work 30 hours a week at $20 an hour you’re going to pay $600 for the week. And if you start paying $800 or $900 a week for that person then it’s pretty clear that they are working a lot. But I think that if you’re not tracking their hours for whatever reason. And they’re not tracking them. Then it becomes much easier to kind of to go into the… down the road of burnout without being aware of it. And I think that that’s a…that’s the biggest part of that is that if you’re not aware that burnout could become an issue.

[28:07] You could get to a point where it’s just too late. It’s become a problem and it’s too late to do anything about it. You need to basically need to send them on vacation for a while. It’s more of a problem for the business owner than it is for the people working in the business.

[28:21] The next pitfall is accounting and HR problems. When you are hiring people across state lines or in other countries there’s all these different problems that come to mind like, how do you pay them? for one. How do you account for any sort of benefits? You know, how do you give them time off? And I think the general consensus between at least you and me for these types of situations is go as long as you possibly can using people as contractors. Because then you are able to avoid those things. And you’re going to be paying them as a contractor you’re going to be paying them hourly. Such that they can go out and take care of that stuff themselves. There’s two different things that happen there. One is that you don’t have to worry about what sort of health plan you’re going to be using to cover everybody in all different states and different countries and things like that. And the other thing is that they get to choose whatever it is that they want.

[29:07] Using something like Odesk really helps out with that because they also handle things like 1099 forms. So what I’ve had to do every year is whenever I’m working with contractors if I pay them more than $600 a year. Then I have to issue them what is called a 1099 form. In the US that’s just a standard form that notifies them and the IRS that this is how much you paid them. And let’s the IRS know that they should be expecting tax money from that revenue. I don’t know what it’s like in other countries with that regard but if you’re using Odesk. Odesk takes care of all that stuff for you.

[29:39]Rob: Another common pitfall is people doing their own thing. Either not following instructions, not doing good work or doing other work during the time that they are billing you for. I mean, this is just a matter of keeping an eye out and like we said earlier, it’s like trusting your people. And watching what they’re up to, looking at their productivity and stuff. And if you do find out that stuff isn’t working out then it starts with a one on one conversation of you raising the issue. And if it doesn’t clean itself up really fast. This is where letting someone go that you don’t have a relationship with, right? If you’ve know and worked with them for a couple of years and you know and trust them and something is going awry. Then in my opinion, it’s up to you to dig deeper and figure that out. But if it’s someone that you just started working with, you are 2 or 3 weeks in and you know things are kind of going awry. I’ll give someone one chance and have a really good talk with them. Solid talk explaining exactly what’s going on and what my expectations are and if it doesn’t clean up after that I consider it a lost cause at that point. I don’t have the time to teach someone that they need to be productive or that they need to not be doing someone else’s work while they’re billing my company for it.

[30:41] Mike: I think sometimes it’s very hard for people who are starting a new business, I’ll say, come to grips with because a lot of times you feel like, “Awww. I went through all this effort and time to vet this developer or vet this new employee and I’ve done all this extra work to essentially integrate them into the processes that run the business. And you don’t want to spend all that time and essentially walk away with nothing out of it.” You really want to be able to get that person to be productive. But, as you’ve said, I mean, I really like your approach with it. To just say “Okay. I’ll have one talk with them.” But after that but if it doesn’t straighten itself out, you kind of have to pull the plug. Because otherwise you’re going to be back in that situation in six months or 9 months later or even maybe three weeks later. And you don’t want to have to keep going through that. You’re much better off finding somebody else who’s a good fit. Who is going to be able to provide you with what you need without the micromanagement oversight that you’re going to have to apparently provide in that situation.

[31:38]And along with that is that, as I said, there’s this sunk cost that you have in hiring these people. And you have to remember that there are always more people out there who are just as good. You can find somebody else, who’s just as good, if you are willing to put the effort in and look for them. Because you already found somebody like that once, what’s to say that you can’t find somebody else like that again.

[31:57] Rob: Yeah, I agree. It’s not easy to find good people but the times where I have hung onto people. Or given them too many chances. What in retrospect was too many chances. I’ve always regretted and as soon as I have let them go and found someone new who is what I needed, it’s like a smack to the forehead. And why didn’t I do this months ago. Every time it works out to that. So, yes there are still costs in hiring and training to bring someone else onboard but if you really work with them and things aren’t working out then there’s no other choice here. Right? Just the same if you’re working on site with someone. There’s some costs in that. You’ve gotta let them go, find someone new. It’s time to do it.

[32:34] So to recap the 5 main points we touched on with distributed team collaborations for startups was: 1) Why to consider hiring a remote team. 2) Common Objections. 3) How to Hire 4) How to collaborate effectively and 5) Common Pitfalls.

[32:50] If you have question for us, call our voice mail number at 888-801-9690 or email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from “We’re Outta Control” by MoOt used under Creative Commons. Subscribe to us in iTunes by searching for startups or by RSS at startupsfortherestofus.com where you’ll also find a full transcript of each episode. Thanks for listening. We’ll see you next time.