Pioneers vs. Planners
20 Feb 2007Ryan Carson has a post about why you should ditch your freelancer. Having recently joined the ranks of full-time freelancers, I read his thoughts with some interest. Courtenay had something to say about it as well. There’s a little something missing from the discussion, though, and that’s the concept of Pioneers vs. Planners.
When you are creating a new product, or a significant revision of a product, you need developers who are Pioneers. These are developers who enjoy tackling new problems, are good at translating ideas (often more nebulous than detailed requirements) and business processes into code, deal with ambiguity fairly well, and basically can be given a rough direction and be expected to find a way to the correct destination. Pioneers are the ones you want to have on board to help you build your next big thing.
When your development efforts are spent more on bug fixes, small feature additions, and maintaining your product, you need City Planners. These developers are good at following and extending what’s been done before, enjoy the puzzle of figuring out what an application actually does vs. what it’s supposed to do, and thrive on having a specific set of instructions to delineate exactly what is to be done. City Planners are the developers you need to help keep things going smoothly.
Some developers are good at (and/or enjoy being) both Pioneers and Planners. Most aren’t. Most prefer one of the two roles, and have to move out of their preferred work environment to take on the other role. As an aside, this is often what you see at startups when the original developers start leaving the company—from their point of view, all the fun, new projects get replaced with boring maintenance work.
It’s entirely possible that the freelancers with whom Ryan worked had other clients competing for their time or they simply weren’t reliable for long-term work. It’s also possible (and I’d say, likely) that he hired Pioneers to build his apps and then expected those Pioneers to become Planners when it suited his needs. When that didn’t work out, he went and found Planners (maintenance developers) in the form of an offshore team. I’d wager that the next time he has an idea for a brand new application, he’ll find he again wants some of those expensive and talented developers to build it for him.
As a Pioneer myself, this suits me just fine. Feel free to keep sending me fun, new projects that need that talent to be successful. When your project gets to maintenance mode, I’ll be happy to help advise you when you are ready to start looking for some Planners.
That’s a fascinating idea. I hate to generalize, but it seems that many freelancers are Pioneers, otherwise they would have chosen a more stable, predictable way to make a career out of computer programming.
@topfunky: the unpredictability is what makes it fun! you say that like it’s a bad thing…
Sure cashflow can be lumpy and I crap myself when the mortgage payment is due, but I try and book work weeks ahead, so I’m no worse off than any average Joe Wage-slave whose job gets offshored with two weeks’ notice.
I agree with Ben, I’ll take fun, new projects over making sense of old, crusty, bordering-on-unmaintainable code written by someone’s nephew.
Having said that, I am more than happy to support and resolve issues for my clients where the software delivered deviates from the agreed specification (be it a bug or otherwise). I’d consider a freelancer who refused to rectify defects like this as a priority issue totally unprofessional.
What I won’t do though is be at a past client’s beck and call 24/7 to add or tweak new features, unless they are willing to pay a retainer to ensure my availability.
I’m not their employee, I’m an independent supplier of services. If they have jealousy issues because I’m “seeing” other clients, then we need to re-examine our relationship.
Zed Shaw sums it up best:
“I don’t want to code for someone because they treat me like their bitch” (http://zedshaw.com/blog/announcing_my_retirement.html)
[...] (For the background that inspired this post, see here, here and here.) [...]
Hey Ben,
Interesting point. However, the decision I made was largely based on cash flow. If DropSend was bringing in a significant amount of cash, we would’ve stayed local.
Have fun at RailsConf – looks like it’s going to be a blast.
Kind regards,
Ryan
This really struck a chord with me. A while back my wife had me take the Keirsey temperament sorter (aka the Myers-Brigg’s test) and I registered as an INTP. It turns out there’s a lot of us freelance developers who fall into that category.
One of the most striking things about folks with this personality type (as found in the book “Please Understand Me II”) is that they love to start new projects but should not be asked to maintain them once there’s nothing left to build.
While I think anyone in their right mind prefers new over maintenance (seriously – have you ever met someone who was psyched to do maintenance code?) I think Ryan ran into big-project-101. Anyone who’s done any development knows that 95% of the project takes 50% of the time and the last 5% take the remaining 50%. This isn’t because his freelancers suck, or because you need to have a PhD in psychobabble to hire people. It’s because the initial development work was one item and adding features that weren’t thought of during that initial push take a lot longer because there’s an above average chance the code wasn’t written to support these new features which leads to lots of refactoring. There are a ton of headaches that come with adding a new feature to a mature project. It’s going to take longer.
Ryan didn’t solve his freelancer problem – he just found a cheaper labor market. His urgency required beckon-and-call and his budget didn’t support that. Of course – I have tons of respect for people who aren’t willing to partner with developers… that’s going to get him great results (not). A hired gun is a hired gun – don’t expect them to give a shit about your project if you treat them that way. Anyone running a software company that doesn’t think a developer should be part of the core team is ridiculous and overly greedy in my book.