- Rob’s site is lifeofthefreelancer.com, @lifeofthefree on Twitter.
- Since this podcast was recorded, he also launched The Itinerant Entrepreneur.
Avdi: Hey, this is Avdi Grimm with WideTeams.com. And I’m talking today with Rob Dempsey of the LifeOfTheFreelancer. Rob?
Rob: Hey, Avdi. How’s it going, man?
Avdi: It’s going great. How are you?
Rob: Good. We overcame the technical difficulties, so we are all about it this morning. Yay Monday! (laughs and woots)
So well, let’s just start this conversation off because this will be – at least for the folks at LifeOfTheFreelancer- this will be a bit of a different kind of thing. Not our traditional interview where…we have some definite commonalities in terms of we’ve both been doing software, we’re both working with distributed teams or another way of putting that is working with other folks self-employed, or otherwise that are all over the damn place. Alright?
Rob: And for me at LifeOfTheFreelancer, it’s very important to team up with other freelancers. Huge! Especially nowadays. So you’ve been doing that, I’ve been doing that. So we can totally have a conversation around that. So let’s start off too…I think by you giving some more of your background.
Avdi: Alright well, so like you said, I’m a software developer. I’ve been doing that for I guess, over ten years. And I started out sort of in the best military industrial complex and I eventually moved into…more into web development. And in the process, I’ve done a lot of working with distributed teams scattered usually across North America.
And at some point, I realized that I really wanted to spend more time at home…as much of my time as I could at home with my family. And so I decided that I wanted to really get good at working with dispersed teams and so sort of enabling that to happen for myself and for more people to be able to choose where they work from independently of who they work for.
And so since –I guess- June, I’ve been interviewing a lot of people who are working on dispersed teams about how they make that work, how they do typically software development. Although I’m going to be talking to some other people that are in different types of organizations about how they manage a dispersed team, what are the challenges and how they overcome those, and the tools they use, and all that kind of thing.
And of course anybody who is listening to this on WideTeams.com knows all these already. But yeah, that’s definitely…I am a freelancer now so Rob’s thing is all about freelancing. I’ve learned a lot of stuff from his site. And, from your site I should say……and, I have been a freelancer for a while now.
Rob: Yeah, and I was reading your bio. And so again, like you said, you were working in that vast military industrial complex. It sounds like, basically, ‘The Man’, right?
Rob: I saw the Ratheon cup.
Avdi: Yeah, my military industrial complex mug here.
Rob: You can say I’ve been there and got the mug, right?
Rob: So now, when did you go freelance?
Avdi: Let’s see, that would be, I think spring of this year? Yeah.
Rob: Right on. So not an enormous amount of time.
Rob: But you made that league though.
Rob: And you have four kids, you said, right?
Avdi: Yep. Mm-hm.
Rob: Right, now did your wife freak out or went out when you were talking about going off on your own?
Avdi: Not really. I mean, she keeps track of the kids in the home and I pretty much figure out how to bring money in and so we keep things pretty well divided that way.
Rob: That’s good. And did you create a financial safety net having been working full-time for quite a while before you made the jump?
Avdi: I wish I could say yes. The truth is I had been planning on making the jump to freelance at some point, but I had it kind of come to me faster than I had planned.
So basically what happened was I was working for a company called Devver, which the Ruby on Rails programmers that are listening may remember, which was the start-up which was really cool but unfortunately didn’t succeed.
So when that went away, that sort of launched me earlier than I had intended into my freelance career rather abruptly. So no, I didn’t really have a safety net.
Avdi: I mean, I had the best safety net you can get which is just having good friends and knowing people that were able to find…you know, to refer me to work.
Rob: Right on. And that’s a huge point, having that network there. So a few listeners who give a bit of background on me I mean, my background too is software development, even before that IT.
So before I got into Ruby on Rails, blank. I think it was maybe six years ago, now I don’t know, I mean I remember messing with Rails before I was 1.0 but I didn’t actually start building a business doing Rails development until a little after 1.0 was out.
So my background was IT, I did Microsoft stuff. So I have like that MCSE and I was A+…. So basically,….. And the first time I had my business, I just up and quit my job and I’m like, “I can do it better than this guy” and…he was doing some stuff that I didn’t…well he said something that I didn’t fully agree with.
And so, I up and quit my job and that didn’t turn out so well. So luckily though, the second generation of my business which was doing software development, the way that I set it up was completely to be able to do it literally from anywhere that I was working. And so that I could work with people that were anywhere because I had…well I didn’t have a physical location when I was doing IT, I was running around – I was up in DC all the time – so literally driving all over DC, Maryland, and Virginia which will take a minimum of forty five minutes to get literally anywhere.
So yeah, you go to one place, you’re up there for an hour or two, you drive forty five minutes to an hour to get to the next place blah, blah, blah basically, half your time is spent just driving around from place to place. So that really reduces the amount of billable time, so I’m like, alright, I need to do something that’s tech that I don’t have to drive anywhere. And so that’s really how I got—well, I ended up doing a computer science degree.
And that actually let me do getting into Ruby on Rails and software development, and agile development which is a…well you know about it, I’m sure your listeners know about it, but it’s basically a method well it’s principles that manifest themselves as a set of methodologies for developing software that really, it talks about being very customer focused, a lot of communication.
And so when you talk about agile distributed software development or really working with people all over the place regardless, it really comes down to this. It’s really important to focus on the communication aspects of the project.
And so you’re talking about, using tools like Skype like we’re using, you can have face to face conversations or talk in project management tools, you’re talking, even at the development environment itself, really giving you you’re feedback and telling you what’s going on….OK does your software suck, are your test breaking? Do you even have test in the first place?
It’s like all this kind of thing and so, when…a lot of the same practices though, whether you’re doing software development, whether you’re doing really anything where you have people and multiple locations working on the same project, the same principles, the same practices I think, absolutely come into play.
And so I’ve been able to use agile practices on non-software development projects and it’s been really wicked cool.
Avdi: Right. That’s interesting. So agile on things beyond software.
Rob: Yeah, absolutely. And so because again, agile itself is a set of principles that then manifest themselves as different practices whether it’s scrum certification and there’s been a whole shitstorm over there and that and that community. I’m glad to kind be away from that. You have scrum or extreme programming, you have all these things but basically we work together for the benefit of the customer.
And so, I remember going to these conferences where people go like, ‘Oh, they’re not sitting side by side, they’re not doing agile and blah blah blah’ and I’d like to punch these people in the face. I mean, that’s like, ‘Who are you to tell me I’m not doing agile because I’m not sitting beside the person I’m working with?’
And I think the future of work further is that we will be…we will have these distributed teams because you’re working at your house and I’m working at mine, and the overhead of that is a hell of a lot lower than if we have to come into some office. And what’s the point? I mean, you and I can work together. Where you’re up in…where, like Maryland you say?
Rob: Yeah, ok. That’s off completely. So, my fault.
Avdi: Well, not really because I’m really just across the line from Maryland, it’s forty five minutes to for me to ride to Baltimore.
Rob: Right on, right? So you can be on in Pennsylvania, and I can be…I’m currently in Minnesota, I’m gonna be at Highland probably in a month. But, you know the point. And I’ve worked with folks in the Philippines, I’ve worked with some of my previous employees in Florida, right? My customers are all over the place, I’m sure yours are too. I remember when I was building Atlantic Dominion Solutions which is my web development business. And I had never met any…a majority of my customers? I’ve never even met them in real life for years.
And so my wife and daughter and I took a road trip and sort of driving around and meeting these folks. So I think this is just an ever increasing trend and especially when you’re talking self-employed people like you and I, teaming up working together, all of this becomes even more important for…okay, well how do we work well?
Rob: With you in Pennsylvania, me in Minnesota or Thailand or wherever, totally for the benefit, again, of the customer. And how do we bring them into the picture? And so we’re all over the place scattered about, how do we really make this work well?
Rob: So my question to you is what are you doing that’s really helping you to do to make that happen?
Avdi: My biggest project right now is just the process of sort of trying to bring together the people that are doing this and get the conversation going more because what I found is that…I mean, you’re absolutely right, I think this is sort of the trend. You’re seeing more and more of it, especially in web development.
There are some things that you can do that you really require at least part of the team to be on one site. But when it comes to web development, you’re absolutely right, you can be anywhere. And there all these groups that are doing it, and they’re using different techniques, they’re using different tools, and I’m trying to sort of assemble that into one place and get people…sort of collect some of that wisdom that’s out there…
Rob: Okay, so for instance, what are you hearing then? When you’re out there interviewing people about stuff, what are you hearing that are some of the things that are working pretty well for folks so far?
Avdi: Well, I think the general experience seems to me that it’s not as big a change and it’s not as big a problem as a lot of people imagine it‘s going to be. And I think it’s interesting you talked about sort of a debate. There is that debate over ‘ can you be doing agile work distributed?’
But the truth is it’s kind of a moot question because it’s being done…just like you said. People are doing it everywhere and I hear a lot of things, I hear things like…I mean, obviously communication is key but it’s all about sort of the pace of the communication and how you keep it going. I mean, the big thing that I hear a lot is the importance –even if you’re gonna be distributed- of meeting up in person from time to time.
I pretty much hear that from everyone. If you’re going to work with somebody as a dispersed team, that’s fine. But try to make it happen that If possible, at the beginning of the project, you all get together and just sort of get to know each other a little bit in person. It completely changes the character of every interaction that you’ll have after that because you’ll have that sense of them in person and so, when they email you or when you talk to them on Campfire or something like that, you’re gonna see them as a person seeing it rather than just that jerk in the other end of the internet. And so, that’s something I hear over and over again. Pretty much everyone’s doing some kind of daily meeting usually on Skype or something like that.
I hear a lot about having well-defined expectations. So it doesn’t work as well when it’s kind of up in the air what to do next on the project…It works better when there is some clear and well defined goals for the iteration or whatever. And I think the thing that the biggest thing that I’ve taken away from everyone I’ve talked to and from my own experience is that working as a dispersed team really requires you to be intentional about it.
I mean, you can’t just…I think the people that have the biggest problems or the worst experiences are the ones who just sort of expected it to work, just sort of to happen. And the truth is that as good as the technology gets, everything is still going to be a little bit more of an effort. You and I even had some technical difficulties getting Skype connected this morning. And if you’re going to say, ‘Oh, screw it, I’m just not going to do the Skype call this morning.’ and you’re working as a team, that doesn’t work out.
And so, you have to accept the fact that everything’s going to be a little bit more effort than it would be if the other people on your team are sitting across the table from you. And as long as everybody realizes that and is intentional about making it work, it will work.
Rob: Right on, so really what you’re talking about then is relationship building between the people within the team. And so less about the project, and more about how do you and I work together to make this thing happen? So you’re talking people skills, and not necessarily technology skills at that point.
Avdi: Yeah, yeah it’s really just about making an effort, and making sure that the connections happen even if there is a technological barrier, or a time barrier, or whatever it is. Just making sure….it’s easier to remember to maintain that communication when you see someone around. But as long as you just make the effort, then it’ll happen.
Rob: Right on. Yeah, I mean ‘cause to me, I think as you said, people doing in the software space, agile development distributed is a moot point because it is happening. I’ve seen companies where they have all their business analysts and all the “businessey” people inside, like internal. But then they completely outsource all the developments.
Where that really falls down is just as you said, no expectations had been discussed. No one even talks about that. Okay, who’s going to do what, what do we expect of you, what do we want to see on both sides? It’s kind of the…not the plan of action per se, but the… what are the rules of engagement, if you will, right? So you don’t have that, you’re not even laying down the foundation for this whole thing to work.
Avdi: I have a friend, Chris Strum, who talks about working agreements and the importance of working agreements when you have a dispersed team. And that’s basically just having an actual short written list of things like ‘we will report status in a daily meeting every day’, or there are tools that are sort of like internal Twitter for reporting your status to each other and keeping up to date with each other, and working agreement could be, ‘I will update our yammer tool or our presently tool, or whatever you’re using at least once an hour’ or something like that. Just these working agreements that these groups come up with that help them remember to keep those lines of communication open.
Rob: Yeah, right on. So that forms the kind of foundation, everyone has their expectations. The thing when you’re working inside of a company, you have that company culture. Hopefully there’s company culture that kind of dictates how people will be working together. You get maybe that training when you first come into the business. But when we’re forming these ad hoc teams out there, … whereas we weren’t before….then we have to make sure that we have a basis in place for how we are going to work together.
Rob: Then it’s a… I think then the tools and everything else are pretty straightforward. I mean so to me this stuff seems…maybe because I have been doing it for a number of years.
Rob: Seems pretty straight forward. It’s like, ‘Okay, we got to talk, we got to know what we’re doing, and we got to know when we’re gonna talk with the customer, who’s gonna say what so we don’t step on each other’s toes’ and all that kind of thing.
So yeah, that idea of a working agreement is fantastic, just having that right off the bat. You could probably come up with some boiler plate and say look if we’re gonna work together, this is how it’s gonna be then that is that, because this is what I found to be successful.
Avdi: Yeah, but you got to be flexible too. One of the big insights of agile is that you constantly improve by evaluation pretty frequently, evaluating the things, the tools, and the techniques that you’re using. And then you suggest improvements, and then you test, you see if the improvements have helped. And I think that’s another thing that’s really important especially for dispersed teams. Because dispersed teams really are more reliant on tools and practices to keep those lines of communication open.
You really have to have retrospectives or something like retrospectives every couple of weeks, or at the most, every month in your project and just talk about what’s working and what the annoyances are and then possibly come up with…so you may add a new working agreement, or you might modify one or you might decide, ‘we’re gonna try a different tool for our meetings’ or something like that. You really have to keep stay flexible on that and stay on top of that stuff. If something’s not working right, you can’t just let it fester.
Rob: Yeah, absolutely. So for anyone in the non-software listening to this, a retrospective is where…like Avdi and I will sit down and say like, ‘okay, how are things going? What’s been working well? What’s not working well?’ So taking those “what’s not working so well” and then figuring out how do you make that better. And then implementing that like say, over the next two weeks or a month but personally, I think one month is too long for anything. I’m on internet time here buddy. So every two weeks you say ok well let’s try this out for about a week or two, see how it goes on the project, and then if we need to change yet again, then we change yet again. So yes, always trying to optimize your process whether that’s how you’re developing software, how you’re designing something, how you’re communicating internally. You got to look if what the hell you’re doing isn’t working. And if it’s not, then freaking change that stuff right away. Because I’ve seen project get derailed extremely quickly because basically no one does address the issues. So you got to address the issues.