The freelancers talk to Matt Kern about managing remote teams.

 

Hey everybody and welcome to episode 129 of the Freelancers’ Show. This week on our panel we have Curtis McHale.

Good day.

Reuven Lerner.

Hi everyone.

Eric Davis.

Hi.

I’m Charles Max Wood. And this week we have a special guest, Matt Kern.

Hello.

Matt, you want to give us your origins story? I use that term now if our guests are like superheroes, right?

[Chuckles] Oh boy. Yeah, here we go. I think I’m coming on to talk about remote teams, so I’ll try to keep it somewhat related to that. I’ve been consulting for a long time now – I guess 12 years or something like that, and about five of those now have been remote. Well, actually remote with remote teams, and they’ve all been remote. I’ve fairly ever actually worked on-site. I guess I’ve gone the gamut from programming language to programming language from PHP, through – actually, I guess going way back from Perl to PHP to Ruby on Rails and now I'm dabbling on a whole bunch of other stuff and a lot of iOS these days. My company at the moment is called Bloomcrush. It’s going through iterations probably as much as our software does, I guess [chuckles]. That’s the current iteration of it, anyway. I guess we’re between 8 and 10 people typically; I think right now we’re 8. That’s decent enough summary, I think.

Awesome. But you didn’t use the terms mild-mannered.

No, I didn’t. I’m not wearing glasses right now either, so contacts [crosstalk].

So if you put on a cape, we’ll know who you are.

Oh the cape’s in the closet.

Got it. Awesome. Do you usually wind up leading the teams or working on the teams? Where are you at with remote teams?

That changes a lot, I guess. These days, mostly, I set teams up and then we bounce in and out of project management for most of the projects. We tend to only have a few projects at a time, so I try to stay pretty hands-on, but I also have a great team, so it helps a lot. And actually, that’s probably the thing that I’ve learned the most, is that the team matters more than anything else and all of the guys that I have working for me have all worked remotely for quite some time, too. So yeah, I do a little bit of both and often times I will work on the project, as well. But these days, there’s enough work to keep me busy outside of that. I haven’t done a lot of that of late.

I have to ask before we get into how you manage your team, I’m really curious how you make a transition from being the guy to being the boss, or to being the guy that built the team. I think that’s relevant to managing the team once you get it up together.

Yeah, definitely. From what I’ve heard on this show so far in past episodes, I think my story’s pretty similar with everyone else’s where I started off as a solo freelancer and eventually just had too much work to take on, and then brought in one guy, and then that kind of turned to two guys, and then it continued to grow. I’ve always tried to keep a relatively small team. There’s not really any real good reason for that other than the fact that I can’t quite clone myself yet. It’s kind of been an organic transition I guess I'd say, and as far as it being remote, it was sort of out of necessity because I’ve always lived in kind of strange places these days. I'm in France, and typically I live in Bend, Oregon, which is kind of close enough to some of the tech centers of the West Coast, but it’s just far enough away that there’s not a lot of development out there – although that is changing, I suppose. I’ve always had to be remote because of the places that I’ve chosen to live. I’ve had as many as, I think, one or two guys at a time working in the same city. But even when we worked in the same city, it’s never in the same office. I’ve always kind of looked at an office as overhead that isn’t really necessary and I like my margins the way they are.

Cool. So, once you get to enough people to where you’re – it sounds like you’re spending more time managing the team than actually working in the project itself?

Yeah, these days.

So what do you do? What does your day look like?

[Chuckles] It’s a lot of sales these days. Actually, most of it I'd say is managing the client, not managing the team. I think client expectations are probably the hardest thing in managing a remote team. Especially in some of these cases, we started off as sort of less remote I would say, and maybe the same state, and then I’ve decided to go off to Europe for a while, so we became very remote. And then we had tons of issues and so on and so forth. I spend at least 50%, maybe 70% of everyday working with the clients – multiple clients for the multiple projects. And then outside of that, trying to keep the pipeline full, which is always a fair amount of work for all of us, I think. I would say that I spend much less time and energy on my team than my clients. But at the same time, there is a need even with strong leads. I end up spending a fair amount of time with making sure that everyone’s still on track. I think the key to the remote team so far has been overcommunication. Everybody is always in Campfire and available on chats, and without that bit – including the client, by the way; we also have our clients in our Campfires. There’s always a backchannel, of course, but they don’t always know that, so hopefully not all of them are listening [chuckling]. That’s probably most of my time – just managing the client. It doesn’t mean necessarily like the client is gathering; a lot of it is just status updates. I despise meetings, so I try to keep them to a minimum and that’s probably most of the reason that we use Campfire so much. We can keep the client pretty abreast of the things that are happening through Campfire without having to have meetings. But I do have at least a weekly meeting with every one of my clients. And some of them, a couple of them, so.

When you say weekly meeting, obviously that’s going to be remote, right?

Yeah, of course. We bounce back and forth between technologies on this, from Skype to Hangouts, but Hangouts” really been, probably the most enabling technology that we’ve used for the remote team thing, because without it face-time is pretty much impossible. I’ve got a team that’s as farflung as most of my teams typically are. So a typical team for us is, well these days, like I said, I’m in Europe, and then one of the bigger projects we have going right now – we’ve got a great dev in Germany, another one in Vancouver, Washington, another one in the UK, and then of course me bouncing in and out of it [inaudible] a guy in Ecuador. I’ve kind of always just taken the attack of hiring the best talent I could find wherever it is and figuring out how to make it work later. That’s worked out pretty well so far. It also helps if you like your team [chuckles]. When you’re dealing with time zones like we are, there’s a lot of time that you may not actually be building or working, but you’re still in channel, responding to things when you need to. It makes a big difference to like hanging out with the people, at least hanging out in terms of IRC or Campfire.

How do you find your people? Especially since they're near-shore or offshore?

Entirely word of mouth. Boy, I don’t think I’d ever looked at resume or anything like that; it’s always word of mouth. Usually I’ll find one person and that person will lead to another, and that person will lead to another, and that’s pretty much the way that that works. I don’t know, I think as long as you’re relatively well-connected in the community, I think it’s pretty easy to find people. The challenge is finding people that are willing to take on contracting full-time. And I hire – when I say “hire”, I run kind of a strange model, but at least I think it’s strange anyway and from what I’ve seen, it’s relatively strange – I don’t hire any employees, actually. All of my people are subcontractors. I’ve toyed with the idea of taking that to the opposite extreme and having everybody being employees or asking them if they want to. In almost every case, my guys have all said they’d rather remain contractors. I don’t know if that’s a reflection on me or not; it could be. But I think for the most part, they enjoy their freedom and I pay them better, because [chuckles] they're contractors and pretty much everybody that I’ve ever worked with has stuck around unless the client work itself has just burned them out. But I generally find a contractor or ten and just keep working with them until someone comes up, I guess.

I assume that keeping everyone as contractors also makes it simpler, because you’ve got people in different states and different countries. And this way, you pay them a certain amount of money, you don’t have to worry about they’re on your payroll, they’re living here, they’re living there, whatever.

Yeah, most definitely. I think, especially with the international connections, I can’t imagine the headaches that would come out of trying to deal with the task burdens and the paperwork and all that stuff that comes out of trying to have foreign employees in a US company.

I can [chuckles].

It just makes things so simple. [Chuckles]

You’re a wise man. Don’t do it. [Laughter]

Yeah. It’s worked out pretty well. Honestly, the only tough thing about the international thing that I think I’ve ran into, really, is banking. Some of the countries out there, namely Ecuador, can be a little bit of a challenge to get wires through. Most of my guys, at least two have a US connection where they can have US bank accounts, so I just transfer their money there. Otherwise the international wire can be a bit of a pain but tolerable, anyway. It’s all up in the paperwork that comes along with the other options.

Yeah, I have a subcontractor in Argentina. We’ve jumped through several hoops before we found a way that routinely works for me to pay him.

I’m just going to say that I think that’s the biggest – getting it initially setup, and then it’s pretty simple. And it actually depends on your bank a fair amount too. I use a pretty small local bank in small town Bend, Oregon. It’s been a little bit challenging but it seems to work out ok.

Just treading on this subject, I have this guy who’s working for me from Ukraine doing some subcontracting. It’s this whole complicated situation with a client, and he’s in the US, and he’s paying me to do the development, and I’m managing. Anyway, after a whole period where I thought, “Ok, everything’s going to be really settled.” I went to the bank two days ago, three days ago. I said, “I want to make a wire to Ukraine.” They said, “You can’t do that. They’re in a state of war. We don’t transfer to Ukraine now.” I was like, “First of all, I don’t know if this is really a situation where we’ll be pointing fingers. But second of all, really?” So we had to do – they were yelling at me, I was yelling at them; there was a lot of scrambling to figure out who’s doing what, where, when. Finally they got back to me and said, “Yes, it is possible, because it’s not in Crimea; it’s elsewhere.”

I haven’t have had that problem yet, but that’s pretty [inaudible].

You mentioned that you’ve kind of overdo it on the communication. I’m wondering – are there specific things that you make sure that you communicate about? Or are there certain processes that you follow when you communicate certain things?

Yeah. I think actually a lot of it is less –. When I say over-communicate, I think I’m more specifically saying that we use tools that allow us to keep the client in very close touch with what’s going on. We use Basecamp; we use the standard things that – maybe you don’t use Basecamp and Campfire, maybe you use HipChat and another product, but whatever. Most consultant companies these days are using something to manage their product or something like that, right? But most of our communication doesn’t happen in those channels. At least in Basecamp – I try to avoid Basecamp like the plague because it’s so slow back and forth – everybody knows the problems with Basecamp. But between Campfire and sending notifications – not too many, but enough – so that the client will be aware of what’s being committed. In most of the cases, my clients are not sophisticated enough to parse and read a commit log, so it’s just to show that there is work happening and that it is in this general area. My team is very disciplined when it comes to things like git commit logs. We use GitHub Issues for most of our communication around features and stories and story breakdowns, and we really try to keep the tooling as simple as possible, but just enough that people are able to keep up without having to ping each other. I think we sort of follow a similar approach to what I’ve heard GitHub does where they try to make it so that everyone can work as asynchronously as possible, but the information is out there if you need it. I think there is a tendency to over-communicate on a remote team, which is just as deadly as under-communicating. I think a lot of it just takes time and experience and gelling with the team and the client to figure out what appropriate level of communication is. But really, most of this is –.

Let me ask you about that. We’ve been having a little conversation, some joking on the backchannel here about over-communication. First of all, do you mean over-communication within the team or over-communication with the client? And second of all, what does that mean? Does it just mean too much information, too many messages, instead of just giving a daily summary? Give us some examples of what over-communication would be like.

I was thinking signal-to-noise, but I’m not sure which mean, neither.

Yeah. Well, it is somewhat a function of signal-to-noise. I think we have a – at least in my experience, we have less of a tendency to over-communicate because we’re, generally, pretty busy with things. But the client can [inaudible] and try to parse out huge brain dumps of 15 different stories in one email. And also, when things get dumped into several different channels, it’s also a waste of time. So I think when I’m saying over-communicate, I’m generally talking about the client over-communicating with us, which is not a bad problem to have except for the fact that it can be a pretty large sap on the project if you have to spend too much time trying to figure out what needs to get done because it’s coming in email, and it’s coming in Basecamp, and it’s coming in –. I guess resolving those multiple channels can be difficult. I think that’s probably more of what I’m talking about when I say it’s possible to over-communicate. In general, I personally think it is possible to over-communicate. By that, I mean spending too much time hashing out an issue that may not actually even be to the forefront. One of the things that we try to do pretty rigorously is we don’t really keep super close track of things as far as wish-list type things that clients may want, like “Oh, we should do this one thing”, and they’ll mention it once. We don’t go around and write that down somewhere, generally. I don’t write everything down until I’ve heard it at least a couple of times, because if it’s only said once, it’s not a pinpoint, it’s not something that needs to be solved. If I hear it several times, then I will write it down and it will bubble up again. I think a lot of it depends on how much your clients communicate with you to sort of find that balance. Does that answer your question at all?

Yeah, I think so.

Yeah.

One other question I have is what types of things do you communicate in your task-tracking system, for a lack of a better term? And what kinds of things do you communicate in your other systems like your chat, or maybe a wiki for documentation or things like that?

We pretty much just use – we want to get as simple as possible, like I said. Most of our communication happens in Campfire and GitHub and sometimes in code. We don’t keep wikis; we keep that stuff in a ReadMe, or otherwise in the code basis themselves. Our issue management is all in GitHub Issues and we just use – we make very heavy use of pull requests and the ability to do the checkmark stuff as tasks in GFM; I think GitHub Flavored Markdown is really useful. Our issues tend to be really detailed, but then it’s nice because we can track the comments pretty easily and the code with those comments in that issue itself, and that’s worked out really well for us. We usually use a whole lot of other tools and we’ve really streamlined over the last, I’d say, two years and watched a lot of the tools that we used to use sort of fall away because they’re just not necessary anymore. I should also mention, you were asking what types of things go in what types of communication channels. In general, this is probably the hardest thing to train your clients on because most clients have never worked this way before. I think kind of holding their hands and being patient with them at the beginning as they spew across multiple tools is pretty tough but it pays off dividends in the end. And the way that we generally approach is when we first open a Basecamp project, we set out that this is for things that we want to archive for later or that don’t require a whole lot of discussion, just a place to keep things that don’t need responses right away, and please never send me an email. [Laughter] Campfire is generally for things that if you need an answer now, you may not get the answer right away, but you’ll get a faster answer there than you will on Basecamp, and just in general, things that need a little bit more synchronous communication. But like I said, we still keep it relatively synced because I don’t expect people to pull off with what they’re doing to answer a question in Campfire. I really wish these two tools were named something a little bit more disparate so I didn’t always confuse them. And then the stuff that’s actually issue-related pretty much like design – that all ends up in GitHub Issues. It takes a little bit of time to get to the point that the types of communication are well demarcated, but it does eventually fall out. And again, I think this depends on, more than anything else, on your team being rigorous about their own communication and not letting those lines blur; because once the lines blur, the client – all bets are off and you have to retrain. It’s a little bit like housebreaking a pet.

I was curious to know if your clients were technical, non-technical companies, a mix, if you found differences in the way you want to communicate and how to communicate with those different kinds of clients.

Yes, totally different. We do have a mix. We’re kind of all over the board with these types of gigs we take on and I definitely have my preferences. I would say from an ease of contract perspective that I definitely prefer the more technical clients. If you’re taking on a startup where one of the founding members is an engineer, that tends to make things a little bit easier, but it can also make things more difficult, of course. If they are set in their ways about the way they do things and they want you to follow their procedures instead of yours, usually we’ll walk from a contract like that. But for the non-technical – for those guys, you really have to hold their hands the entire time, at least for the first few weeks of the contract. And often times, like gentle nudging reminders over and over and over and over. You’ll get an email, and you’ll be like “Hey, this is a great email. Thanks so much. But this would’ve really been backshooted for Basecamp so we can keep track of it.” So it really does depend on the type of client. The non-technical needs way more hand-holding because they’re not just used to the tools, like even getting something like Google Hangouts working, which is really simple most of the time; sometimes, it doesn’t work, can be a real challenge for a nontechnical user even just finding it.

Is it counter-productive to copy it over there for them for the first little while, say, “I’m putting this in the system and I will reply to you there?”

No, absolutely not. We do that all the time, in fact. Or actually, more common than that, I will ask them to do it, and if they don’t do it within a day or two, then I will go back into it. Again, this all requires a fair amount of – it almost feels like baby-sitting but it’s really worth it. I don’t know how many of you are parents, but it’s like having younger children and spending time with them and working with them to do the things that you know are the right way to do things that will pay off in the end, and then reaping the benefits as they become well up until teenager maybe.

Yes. My children are very appreciative for all the lessons I give them for how to live a better life. [Chuckling]

That’s why I left out the teenager part. [Laughter]

Oh, oh. They were grateful and thankful and non-sarcastic long before they were teenagers. [Laughter]

I kind of want to change tactics a little bit and talk a little bit more about how do you – because I’m in the mode where I have been selling myself and my services for so long, that now that I’ve kind of got a guy and I’m looking to hire another guy or another programmer. How do you make that transition marketing-wise?

Oh boy. That is a good question. Like I said, when we started it was a pretty organic transition at first, although I will say that my company as it currently exists, I am now – actually, I'm the only employee. But before this, I had worked with a business partner and he was sort of crucial in making these transitions for me, actually. In other words, kind of prodding me along to like, “Look, there’s more work. Don’t turn it down. Let’s take it and we know plenty of people and we all like to work together, so let’s make it happen.” To be honest, I have a hard time answering this question because the marketing piece – I don’t market almost at all. In fact, in my twelve years of consulting, I have never had more than a placeholder page for my website [chuckles], and still is the case. There's not even contact information, because I can’t keep up with it. So for the marketing perspective, I really can’t answer the question; I wish I could. But from the sales perspective, I don’t think it’s a big difference because my team’s – I hire, again, subcontractors. But I hire better than myself; that’s what I’ve always done. I’ve always believed in surrounding myself with smarter people than me, and I’ve been successful with that with this company. So for me, to sell my team is like selling myself but way better, so it’s easy. I think it’s a little harder when you start – when the numbers start to creep up pretty high, and our rates are pretty high, and so you can deal pretty quickly with numbers that make clients uncomfortable, but at the end of the day you still have to just ask for it. That’s the only way you get those rates. I’ve heard of many times, on this podcast even, that you have to sell what you think you’re worth, and I know that my team is that good, so it’s not really that hard.

Yeah, I totally agree on the count of “sell for what you’re worth” and ask for your value from the client. The thing is that, when I try and do some of the selling, a lot of times they’ll talk to me, “Well, where is your team located?” and I’m kind of like, “Well, we’re all over the place”, and then they start asking “What countries?”, so then I tell them, “There’s me, and there’s my guy in Argentina, and I’ve got a few other folks that I work with here state-side, and blah blah blah”, and they get worried about the guy offshore or they get worried about this or that. They trust me, but they’ve heard nightmare stories, or they’ve actually hired offshore and had trouble and so they’re really leery. I mean, even if they were in a first-world country instead of whatever South America is – second or third world, I guess, though I don’t think they’re set back that far. But anyway, there are merging markets and things.

I think you hit on two things there. One is there’s a lot of clients that are really, really, really edgy about the offshore thing in particular. I think we think less of it now because it’s become more and more commonplace and it doesn’t necessarily have the connotations that it did, say, ten years ago. The sad thing is that it really does – like when that question of “where are your guys located” comes up, it’s always a tough one to handle because there are certain countries, unfortunately, that no matter what you say – and they tend to be countries like India and the Eastern bloc that just have this reputation of not being up to par, which is unfortunate because it’s ridiculous. The way that I generally handle that – well one, I actually don’t have any people in either of those places right now, so it hasn’t been a problem, but I have had in the past. Generally, the way that I handle it is that I don’t talk it as an offshoring ever. And as soon as they to talk about offshoring, I’d reposition it. The other thing that I do is tell them that, “Look, I hire the best people that I can find no matter where they live. I also pay my people the same no matter where they live.” So it’s not like I’m looking to save a buck and find somebody in the country that has a less privileged position economically, but that seems to generally stir them away from that concern. And there is some level of – if you’re talking to a client that’s really, really putting up a lot of objections around the remote thing, they’re not going to want to work with me either, because I’m remote. I never promise to stay in one place, generally. Then again, this comes out of being in places that tend to be either newly-entrepreneurial places or places that there just isn’t much market for the work that I do, but I like to travel and I like to be in places that I want to live. So I would say that at some level you have to cut your loss if a client’s put enough too much of a front on it, but in general, I think it’s pretty easy. If they’re talking to you and they know that you’re remote already, it should be relatively easy to transfer that into a remote team. Now, the other thing that I think you touched on is that – and this is the problem that I’ve always had and am now just starting to take it out of – is this notion of clients coming along and wanting to hire you. And this goes back to our earlier conversation around how do you make the transition from selling yourself to selling the team. I think that most of that for me has come out of forcing the issue, like, “Yes, I’m more than happy to work with you and yes I have oversight over all of my teams. And yes, I promise you – you trust me, because you’re wanting to hire me based on my name – but I promise you that I have hired better than me. Like hands down.” And at that point, the argument pretty much goes away. And again, if there’s too much of a pushback or anything, and that’s just the right client and you move on. But in general, those are the two things that I think come up the most often with the set up that I’m running right now. And that you're about to, it sounds like.

Let me just respond, as well. I’ve heard these objections; it sounds like you actually handle them, or seem to handle them better than I do in many ways, because a lot of times people – with people I speak to, they’re not considerate of where people are offshoring from as a matter of quality. They’re just worried about, “Oh, you’re not in my time zone. You’re not local.” So I definitely found – and I mean like you’re in France now; I live in Israel. I’ve definitely found that just telling, “Listen, I grew up in the US. I have degrees – high school, college degrees from the US. My English is fine. I work crazy hours. You will hear from me. I’m available during a business day. Communication is not going to be an issue.” And some people buy it and some people don’t. And the ones who buy it turn out to be, generally, good clients because there’s already the element of trust to some degree. But I’ve definitely been, shall we say, less successful than it sounds like you’ve been at sort of selling people who work for me to work with these people. Because they come to me and they're like, “Oh, wow. We want to work with you. We’ve heard about you.” I’ll say, “Well, I can give you a few hours a week, but the day-to-day coding’s going to be done by someone else.” And I think that’s actually good for them, because it means there’s someone dedicated working on the project, but they don’t always see it that way. It definitely takes some convincing. And again, some people take it more than others. And those who take it, again, turn out to be good clients, generally, and pretty satisfied.

Yeah, but that’s a great way to handle it by saying, “You can have some of my time, but here’s the two thing that are going to happen. One is you can’t have all of it because I don’t have it. Two, if you want some of it, it’s going to cost even more.” I mean, if you – well, this isn’t a word, I think – disincentivized having you in the team, like you said, they either go away or stick around. And if they decide that they want you five hours a week and you tell them that your rate is 500 bucks an hour, okay, that’s not a bad thing. And I think it is really key to the clients that will stick around for that, the clients that will reason with you on this – those are the clients that you want anyway. The clients that just can’t get it out of their heads, that this isn’t the best thing for them, they could not be great clients because they’re already not trusting you and you’re starting off on the wrong foot.

So I think you really have to build that trust up front and if they’re not there, then you move on.

One of the things that I’ve had come up with working with remote teams is that a lot of times, somebody will go off for several days working on some branch of or some feature, and then they come back and they’re done, and things have moved on since then. They haven’t kept up, or if they have kept up, there was so much going on otherwise that they couldn’t quite keep up. Is there a way to manage things so that you don’t run into that problem?

Yeah, definitely. We used to do daily standups and we still do quite a few standups, but during the summer it’s a little bit harder. In general, I think it’s just important that you’ve got somebody on point that’s watching. And I don’t mean like watching like Big Brother over your shoulder, but I mean you do have to pay attention. And this is one of the reasons that I think I spend a fair amount of my time running it between projects. And it’s something that, if I was fully honest, I would like to not spend so much time doing. But I think that the way that the business is setup now kind of requires it until, like I said, I can clone myself. So the way that I handle it is just by being pretty deeply involved in each of the project. It doesn’t necessarily mean that I know everything that’s going on in every project that’s running, but I do keep pretty in touch with those projects. So there isn’t really a chance for a few days of off on a branch that nobody really knows what you’re doing or if it’s still relevant to the thing that you’re supposed to be working on. We tend to work on pretty short iterations anyway, so that kind of solves the problem as it is. And then it’s just that being in constant contact again. It also helps to have – we’re a pretty flat organization, but I do tend to put somebody in – if it’s a larger team, a team of maybe three of four people or a team that I know that I’m going to need a little bit more bandwidth for management than I can give, I definitely like to have one of my guys be more active in the management role just kind of making sure that things are prioritized and that people have tasks and some of those tasks are being worked on appropriately. I think a lot of that – the success of that depends on the person being involved in the project. I don’t have teams big enough that I really need a project manager separate; and if I do, I tend to fill that role because I don’t think it’s enough of a role on the projects that we happen to work on. I’m sure there are projects that require that, but that’s – those just haven’t been the ones that we’ve been tackling.

I've actually found in talking to some clients that that’s a huge advantage in getting business. I spoke to some people where they say, “Ok, you’re a developer and the people who work for you are developers. Are we going to have to work with a project manager to communicate with you?” I

say, “No, no. You’ll be talking to me and to the developers and we’re not only good at software, but we’re good at talking to people.” There’s a huge sigh of relief of, “Oh my god. Less bureaucracy to deal with. Thank goodness.”

Absolutely. I found the exact same thing, yeah.

Yeah, I think my experience is along those same lines.

It’s funny once people get past the, “Oh my god, you’re a developer and you can talk to people?” [Chuckles] Once that’s gone, it’s the best thing they’ve ever heard [chuckles].

Well, it’s not just that, but it’s like, “Ok, well we’ve been talking about this. You understand where I’m coming from and you want to hand me off to someone else?” I mean, it just doesn’t work.

It’s one less layer of interaction of abstraction too, right? And it’s just more efficient. Again, I’m sure there are times where it’s probably not a bad idea; I just haven’t seen them yet. The one thing I will say about that real quick is time zones have to come up at some point. Reuven, you talked about it briefly, but the time zone thing is difficult; I won’t lie about that. That’s definitely the hardest thing to deal with this distributed team thing, especially when you’re distributed. It’s one thing to be distributed across the US, like you got a worker in California; you got a worker in New York – that’s a decent time zone change. It’s a whole another story when you’re dealing with the rest of the world. One of the ways that we handle that is that I don’t like making people work –. First of all, I can’t make people do anything; they’re all subcontractors. That’s one benefit. But I don’t like asking my people to work late at night, but I do need some overlap, and generally, I kind of let people make their own hours and say, “Look, let’s see how this project goes. If this project needs more overlap then let’s float towards that idea, I guess. And if it needs less, then it can float towards the other idea of have a normal working day.” And it seems to work pretty well. I think, again, it’s probably is a function of working with a great team that these guys have done this for a long time. So generally, if there’s work to be done that needs to get done in this certain time, and there needs to be communication, then people show up. Probably the biggest downside to this is that I think, especially for those of us that are in Europe, we end up working longer days but maybe not always working. In other words, you’re kind of available. Like you get up, do your thing, and then you start working at 12 or 1, and you’re not really working yet, but you’re kind of working. Then, really, it starts in earnest much later. So your days end up much longer, but you may not be getting as much done in a compressed amount of time. So that’s probably the biggest downside to this. If you can handle it, it’s great. But if it drives you insane to sometimes you have to wait until 2 o’clock in the morning to have a call, then it’s probably not for you. Or don’t move to Europe is the other option, I suppose. [Inaudible] I’m also pretty rigorous and strict about, we don’t do calls after this time. So much of it is about discipline, really.

One other thing that I ran into when I was a part of a remote team is that our project manager – they actually had a project manager, this particular client, and he liked to have this super long meetings for like estimations and things. And I’m just not a fan of sitting and talking for 5 hours about what we’re going to do; I’d rather just do it. But some of that needs to happen. I mean, a lot of times a client wants to know when stuff’s going to be done or how much or how long and all that stuff. Do you just do that? Or do you have your team kind of collaborate on estimates somehow?

How do you handle that?

This may sound somewhat ludicrous but we don’t do estimates. We’ll do some pointing and some basic estimations but –.

Yeah. That’s all I’m looking for.

The client, they don’t get estimates on anything. We just work by the hour or by the week. Actually, most of us work by the week these days; I actually can’t say anymore – by the week or by the month these days. But yeah, internally, we have to have those discussions but it really does fall more out of the GitHub Issues I think, and we don’t so much formalize the pointing anymore and a lot of that has just been pretty straight off the bat saying, “No, we don’t have – I’ll give you like kind of loose ballpark, off-the-cuff ideas to when will it be delivered,” but we don’t do it. And again the clients that don’t trust us don’t stick around, and the clients that do, do.

Wow. I’m very impressed [chuckles].

It doesn’t always work. It’s not perfect, but I think part of that is that we also run super low obligation contracts. So if you want to work with us for 15 minutes and it doesn’t work out, then you pay for 15 minutes and go away. But I think that that also puts a fair amount of trust; I think it offers a fair amount of trust anyway that the client can choose to take or not. So like I said, it doesn’t always work. There are always some clients that just insist on “we have to have estimates”, and generally we’ll just say, “Look, that’s not how we work so if you want to find somebody who does that, and there are lots of firms that are more than happy to do that, and you’ll find out why we don’t do it.” [Laughter]

I’m impressed, not only because – as a general strategy, this is really impressive and it’s nice that you were able to get such trust with your clients, but I’m dealing now with a client where we’ll see if I decide to continue with them, or they decide to continue with me, I mean basically, we just worked on stuff for about 3 months now and they have been griping nonstop about “Well, you're going over your estimates, going over your estimates, going over your estimates.” So a friend of mine who pulled me into this project and was like the acting CTO finally got fed up with this and yesterday put together a whole PowerPoint for the CEO of the company and showed that “Yes, in the first phase we delivered two days late and we’re 13% over-budget. And the second phase we delivered on time and we’re 3% over-budget.” But in each case, we also delivered three times as much functionality as they originally asked for. But no one’s been talking about that. They’ve just been talking about, “But your original estimates said x and y and z.” It’s such a torturous relationship to deal with because they’re always looking at the dark side of things and they weren't looking at, “But wait, you have a working application. You can actually launch. You can make money now.’

Yeah, I think that’s the problem with estimates. Like I said, it doesn’t work for all clients and it sure as hell doesn’t work with all teams. But if you have the right team, it can work – and again it doesn’t work for every project we’ve ever worked on and yes of course, we get people that get upset and say, “You haven’t done this,” or “You haven’t done that”, but [inaudible], but we never told we were going to. [Chuckles]

For me, the estimate’s like the pointing – if you’re non-technical, basically, you just assign a complexity or a similar value to it. The thing that’s nice is that then you can do points which don’t really mean anything, but you can actually then kind of track and say, “Okay we slowed way down this week. What’s going on?” or things like that, which is nice. But with the estimates with the clients, I start to sound like a broken record while I’m doing the estimate. “This is just an estimate, it’s just a guess, it’s just a guess, it’s just a guess, it’s just a guess, it’s just a guess,” and then turn around and when you’re off the estimate over, under, whatever, then they're like, “But that was nowhere close to the estimate”, and I’m sitting there going, “I didn’t drill into you, this is just a guess, this is just a guess, this is just a guess.’

Yeah, right, right. I think just by putting the estimate out there, I think it gives them something to fixate on, right? So it doesn’t matter that you delivered all those things; what you didn’t do is what they’re going to fixate on. The other way that I will often explain why we don’t do estimates – I don’t explain it very often because if I have to explain it too often then it’s obviously not working anyway – but if I give it a few shots, then generally what I’ll say is that, “Look, we can come up with an estimate, it’s just going to be an estimate at the end anyway, so you’re not any closer to what we wanted anyway. And the reality is it’s going to take us probably – depending on the task that you want us to do or the story that we’re going to implement – it may take me five minutes to estimate or may take me a week to break a story down into other things. And we just tend to like to do things a little bit organic than that. In fact, the current name of my company is based much around this notion of software’s gardening, software’s nurturing and tending instead of this really sciencedriven technical, sterile variety of company names that are out there, I suppose. This comes somewhat from that that we’d like to more organic about the way this stuff works. And I like efficiency, and honestly, what I think ends up happening pretty quickly in most of our projects is that the clients see the result and see that it actually does work this why and stop asking for estimates. Sometimes they still ask but that’s usually one somebody that’s not involved in the project that’s coming up and saying, “Why is this costing so much?’

Now, when people need to collaborate on a feature, do you just let them figure out the timing, so if there is a time zone issue you just let them figure out who’s going to get up early or who’s going to stay up late to make it work?

I do try to be somewhat strategic about the teams that I put together so I try to keep time zones as close as I can. If there’s a client in New York – the East Coast are nice because they can work pretty much in any time zone. I guess there’s a few places in the world that it doesn’t work. Japan maybe, it’s a little bit difficult, but in general they’re fine with Europe, they’re fine with the West Coast time zone.

Right. Because you're within three or four hours, right?

Yeah, those are easy to deal with. What becomes hard is when you’re like dealing with the client that’s on the West Coast and you’re, say, the person you want to put on the project is in Poland or something. I generally try to keep the teams as close in time zone as possible, but I will never ever compromise the team for time zones. It will always be the right team for this particular job. One of the teams that I have right now has somebody in Canada, in B.C., and I think the furthest East time zone would be Central European. Like I said, I don’t worry about that too much. As far as how they handle their workloads, I leave it up to them for the most part. I wish I had the magic bullet for this stuff, and if I do it is really just hiring well. It’s finding the right people for these tasks, for these teams, because they do a good job of breaking themselves up into time blocks that need to happen. It also helps sometimes I think if you can keep things somewhat – like break the time zones on a functional basis. In other words [inaudible] design a farther away time zone than the engineering staff is that it doesn’t matter so much. Again, speaking of time zones, one of the other nice sells on the time zone thing especially for projects that have tight deadlines which is sort of a misnomer – we really don’t [inaudible] [chuckles]. Anyway, it’s nice to picture that as a benefit that people are in multiple time zones because you have developers working practically around the clock. And it’s a dangerous one because it was one that was thrown around a lot back in the days of offshoring for cost benefit. But some clients like to hear it, and you’re just going to have to gauge your client on it.

I’d like to hear a little bit more about your hiring process. You said that mostly people know who you are, you’ve worked with somebody who knows them, and so that’s how you find people. But how do you make sure that they are a good fit for this kind of thing?

Well for the most part, I need to know at least a few of the people that have either worked for them. It’s all really a word of mouth and reference-based. You can actually ask [inaudible] more about it [chuckles]. I just don’t really have a process around it. There’s a fair amount, at least I think in the way that I’ve run my business of needing to find – my ex-business partner used to have this analogy of a “One Hand Clapping” and that you need to find the second hand. So I often have a case where I’ll have a client that I would really like to take on but I don’t have the people because I don’t run a bench, which is unfortunate. But the flip side of that is that I’ll also often run into a case where I know somebody that I really would like to work with who has just come available, and I can’t snap them up because I don’t have the client. So it’s been a bit of serendipity that I’ve been able to find people that I’ve respected and that have other contacts and other references that respect them that have been willing to come on board. And then in most cases, the person that I

bring on board, the people that I bring on board have sort of another layer of, ‘these are the people that I would like to work with’ so I make it a priority to go, “fine, let’s get those guys on the team, get those girls on the team.’ That’s really been how I’ve hired, and it’s pretty much been since day one.

Have you ever lost anyone because you don’t have a bench?

I have, although – it was unfortunate. It’s the reason that my business partner is now my exbusiness partner, or at least one of them. We lost –basically the way that it works – you guys know this as well as I do that you never know what clients are going to roll off and when. You hope to have some notice, but sometimes you don’t. And in this particular case, somebody that I’ve very much would have liked to have kept on my team left because we rolled off a contract relatively suddenly because of an acquisition and the business partner told him that he should take something else if he was worried while I was trying to say just, “Hey, doors close, doors open. Don’t worry about it. We’ll have something really shortly”, and a week later we did, but I had already lost him. But I think that’s the only person that I’ve ever really lost.

Are there any tax implications or things to hiring people outside the US or whatever that you have to deal with having your company in the US?

No, not so much. I mean, again this is where you count in the contractors – the subcontractors – really as an advantage. As long as you’re very upfront with how the payment works and they’re responsible for all their taxes, I would say that there’s probably more likelihood of the subcontractor having to [inaudible] a little bit more than I do. For a US-based business, it’s basically just – there’s an expense going out. The money goes out and what they do with that money is up to them and then it just drops off of my balance sheet. So bottom line, no, not really; it’s pretty simple.

So there’s no paperwork that you have to have so that the government will recognize that those went to somebody to pay for contract labor?

Yes. I haven’t been into a situation – where there’s been concern that most people have with running subcontractors, which is that the IRS might consider them an employee not a sub. But with working with people from outside the country, that’s not really an issue because it doesn’t matter. The IRS has no authority over them anyway. For a couple of guys on my team, I do keep the paperwork that they give me because they’re more worried about their government wanting to track it. Their government wants to track down that I have invoices, that these invoices say this thing and it’s for this company; I keep that on file. That’s kind of the extensive paperwork.

Alright. Well, let’s go ahead and do the picks unless there was something else we should have asked that we didn’t.

I don’t think there was anything else. I did want to touch on one more thing, which is the one of the things that I think makes our internal teams work the best. I talked a bit about the client communication and then my communication with my team, but I think there’s probably an equally important, if not more important, piece to all of these, is the internal process between the teams – inside an individual team, I should say. And that is that we, I guess, I don’t know if it’s still heretical but we don’t pair generally.

No!

I know, it’s crazy.

And that’s the way we get software done [inaudible].

It’s amazing. It’s amazing.

All your code’s crap; we know it now.

[Chuckles] We will on some things, on things that aren’t particularly [inaudible]. But we actually don’t – I don’t even think we really think of it as pairing; it’s just what it is. But we have a really, really, really rigorous set of code metrics that we expect to always be increasing, and that goes for anybody on the team including if you’re working with somebody on [inaudible] staff augmentation type of projects, so we kind of train the client to do the same. So there’s that, and then on top of that, we’re sort of very, very strict about code review, as well, so I think, in a lot of ways, that our pairing is – and again, this is slightly heretical – our pairing is slightly replaced by the code review process, but everything goes through this code review process that’s very, very, very, very detailed. And honestly, I think that probably is one of my favorite things to watch, is watching everybody reviewing each other’s code because you can see people learning as they’re committing, and then watching the reviews come in. I think that’s a pretty important piece of our process that I’ve left out originally that I wanted to make sure was out there. And actually I think for reference on that, one of my guys, Dan Kubb, did a podcast with the Ruby Rogues some time ago around both metrics and code review, I think. That’s worth looking up and listening to.

Yeah, we talked to Dan on Ruby Rogues like two years ago.

Yeah, a lot of these processes came out from Dan’s rigor around this stuff. He’s been amazingly instrumental.

Cool. Yeah, he’s a classical guy.

Yeah, he’s good.

So you're just measuring performance that way?

There’s been a lot of I guess, back and forth in code metrics, especially of late. In fact – where was that – at wroc_love just last year, which I’m trying to butcher the name of the conf – Piotr Solnica. Piotr used to work for me and Markus does now. They did a little panel there on code metrics and taking opposing views on [inaudible] code metrics and what does it mean and all that kind of stuff. [Inaudible] to be a part of – I think I actually might have the recording [inaudible] worth looking at for people. But anyway, it’s interesting. We still stay very strict about it, and I think it’s done wonders for our code and for our clients. I don’t think that we’re quite to the point that there’s always discretion involved. I think these automated code tools, these automated metric tools are great and we have a pretty extensive suite that runs. But there are still times where the rules need to be bent, and I think as long as there’s discretion involved in that, that the process works fine and that it’s an overall trend, not like every day it has to be better. There are certain days that it’s okay to drop a little bit.

Awesome. Alright, well, let’s go ahead and do the picks. Eric, do you have some picks for us?

Yes. There’s a blog post I found few days ago called On OSS – Open Source Software – and the individual. That’s a pretty short one but it’s pretty interesting because it looked from the maintainer side of what you deal with [inaudible] when you get a popular project or you’re on a very active project. But I’ve had a lot of the same experiences, and that’s why I hold back from open-source stuff as much as I used to.

Awesome. Curtis, what are your picks?

I’m going to recommend sort of three books, sort of like nine books, because two of them are Omnibus Editions. It’s the Wool, Shift and Dust Omnibus books.

My wife love those.

I actually recommended the Wool one years ago, quite a while ago. But I read them all over a week, two weeks ago or so, and they were very, very good.

My wife really liked those books.

I could not convince my wife to try them. She liked Ender’s Game, but that’s about as far as she’d go.

Nice. Reuven, what are your picks?

I got one and a half picks for this week. My first pick – I think I mentioned in the past that I really like these Slate Political Gabfest podcast. This past week, as we’re recording, now this past Friday, they have this guy named Dan Carlin come in and be a guest panelist as well. I’ve never heard of him before, but they just keep gushing about his – what they call the Hardcore History podcast. The series they did about World War I which started just about this week a hundred years ago. And

I was just in Berlin and I kept bothering my children with the fact that World War I led the World War II, and I actually realized that I didn’t know much about World War I. So I started listening to his podcast about World War I and I never would have imagined that I would be so entranced an hour and a half, I guess nearly 2 hours, into a monologue about World War I history – the first of five three-hour podcasts he did, but it’s still – it’s pretty amazing. It’s quite detailed, but it’s really helping me to understand the story. So if you’re a history buff and if you have time to listen, train, treadmill, walking, whatever, I definitely would recommend Dan Carlin’s Hardcore History and especially the ones that he did – the most recent five – on World War I. And the second recommendation is – I got hurt over the weekend; I’m doing okay now. But it occurred to me that if I did not have health insurance, I would really be in trouble. Granted everyone in Israel has health insurance and, shall we say, all other enlightened countries, ehem-ehem. But if you’re a freelancer and you don’t have some sort of health insurance, you should really seriously take a look in getting it. First of all, as people like to say, you're health is really the most important thing. And second of all, you just never know when something really unexpected and tragic can happen. And so you should deal with that in an intelligent way and get insurance. Anyway, those are my picks for this week.

Awesome.

I love the World War I one. That’s fantastic.

Yeah, I'm definitely going to have to check that out. I got a couple of picks here that I’m going to put out there. One is that I just switched my podcasting app. I was using the iPhone podcast app for a long time, and I signed up for Ruby Tapas by Avdi Grimm, and it has an RSS feed that you can get the videos from. However, you have to do HTTP basic authentication. In other words, you have to put in a username and password. The issue there is this that the podcast app doesn’t play well with that. It doesn’t actually download them. It will stream them, but it’s still kind of busted. So, I switched over to Downcast on the iPhone and I’m really liking it. The playlist capability is better; it actually works with Ruby Tapas, which is a major plus. So yes, now I just sit and listen to podcasts all day while I work and I’m really, really enjoying it. Another pick I have is Xiki. That’s x-i-k-i (dot) org and it’s a tool – it’s a command line tool. If you’re not a technical person that does a lot on the command line, you’re probably not as interested. I’ve actually integrated it with my text editor that I do my coding in, so I can actually then use the menu-ing and command stuff that comes with Xiki. So I’m going to pick that one as well. Finally, I have been playing a lot of this game – I probably picked it in the past – called Hearthstone. It’s by Blizzard; it’s a free game. I haven’t actually put any money into it, but I’ve been enjoying it and been doing alright on it, so go check out Hearthstone. Matt, what are your picks?

I've got – let’s see. I do love Hearthstone, by the way. I just started playing that; it’s pretty fun. So I’ll pick a game too. I just got done with a week’s vacation, which I also highly recommend. I think it’s the first one I’ve taken in 10 years. I ordered a game called Coup, a card game that I was lucky enough to play with a bunch of folks at a tournament conference in Sweden this year. I really enjoyed the game, so I picked it up so that the family could play, and it’s a really, really fun game. If you’ve ever played Resistance, it’s similar to that too. But it’s a simple game; you can play a lot of them in a row. It’s a pretty lightweight game; it’s really fun. It’s definitely worth playing. It also – since you are lying and bluffing and killing and plotting, it’s an interesting game to play with your family, so that’s one. One more pleasure-based one, I think I’ll also pick Born to Run, the book. I don’t know if that’s been picked before. I find that I didn’t use to be able to run until recently because of this book, largely. It has made an incredible difference in my productivity and I think my overall enjoyment of life, so I highly recommend it. It’s written really well. A book about running, I know, sounds terrible, but it actually is pretty awesome, so that’s another one. And then along the lines of the things that we’ve been talking about today, if anyone has ever tried the conference service, I think over the last – I don’t know, four or five years – I probably tried 10 different teleconference solutions out there and they’ve all just completely sucked. This one definitely sucks the least. There’s a couple of problems with it, but they’ve got a great staff that’s willing to listen and jump on the problems pretty quickly. This is called Uberconference, and the greatest thing for those of you that are possibly working outside the country or that need to call in from foreign countries, they have international lines as well. Plans are pretty reasonable, and it’s been a kind of a life saver for me. And there’s an iOS client for it, too. And then the final one that I’ll put out there is Earth Class Mail for again those of you who are kind of nomads like me, traveling around. It’s a nice way of having an address in your home country. In this case, I think it’s only for the US where you can send all your mail. I've heard a lot of problems with this sort of remailer companies, but this one has been just spectacular. They’ll even take checks, and I don’t mean like payments; they’ll actually take checks from your clients and then you can call them and they will send them to your bank for those of us who are not lucky enough to have the cool deposit via phone thing. So yeah, those are my picks.

Very cool. Alright. You were talking about the conference; one thing that I forgot to mention is I’m going to be speaking at AirConf in October. It’s the conference that Airpair’s putting on; it’s all online and it’s basically an introduction to freelancing. If you aren’t freelance, you want to learn how, you can get the details there. I think that’s all we got. Thanks for coming Matt.

Thanks for having me, it’s great.

If people want to get hold to you or ask you questions about how all this works, is there a good way to get a hold of you?

Twitter would be fine; that’d be great. I’m @lightcap on Twitter, L-I-G-H-T-C-A-P. Email’s fine, but it’s not on my website so it’s matt@bloomcrush.com.

Alright. Well, thanks for coming guys, and we’ll catch everybody next week.