killthemeeting

There's an interesting group advocating for telecommuting these days -- rural town governments.

Apparently, rural towns have had a population problem of late -- as young people these days don't tend to want to work on the farm, and all the information-worker jobs are found in large cities, people tend to leave small towns for the city or the suburbs.  Many of them want to live in a small town (or to return to one when they have children), but there's not a lot of demand for, say, an Enterprise Architect in a town whose largest employer employs maybe a dozen people.

Telecommuting to jobs in large cities is an obvious benefit to the workers, who get to live where they want -- at substantially lower living cost, plus without the costs of commuting -- while getting a job that's not available in that area.  The benefit to the town is less obvious but no less real: "People who telecommute, live and work here, are the best of both worlds.  They're big earners and they spend the money in town," says Dave Wilson, quoted in the article above.  He recruits for Kansas City and Wichita companies in tiny Sterling, Kansas.  It's a way for companies to bring high-income residents (with the local economic input and tax revenue that that provides) to town without having to lure employers (a task that often requires giving them huge government handouts, in the form of discounted leases, long-term tax breaks, etc.)

Right now, a lot of these employes are probably virtual call center employees, which while not the highest-earning thing out there is at least a "real" job you can do from home (as opposed to the mountains of envelope-stuffing "work from home" scams.)  However, there are definitely some other things out there that are employing virtual workers.

There are, however, some roadblocks.  While towns may be eager to lure telecommuters to reap tax benefits, state governments are fond of reaping tax benefits, too, and the law doesn't always favor telecommuting.  The Telework Coalition is trying to get a law passed to change the situation, but as it stands now, people telecommuting across state lines may end up paying state income tax twice.  The issue is that some states (e.g. New York) require state income tax to be collected on all wage income paid out by employers in the state, even if the worker resides in the other state.  But some states require state income tax to be collected on all income earned in the state -- even if it was from an out-of-state employer!  While this isn't a problem if you live or work in a state with no state income tax (e.g. Washington), or for an employer in the same state, it does discourage companies from organized telework programs.

This said, I'd find an extra 1-2% state income tax a pretty small price to pay to give up commuting -- especially since commuting costs me more than that now.

Posted by Grant at 10:44 AM | Permalink | Comments (0) | TrackBacks (0)

I observed in a previous entry that I found myself somewhat baffled by the software engineering process taken by some offshoring/outsourcing firms, and realized that one issue is that while these people were programmers, they weren't "geeks."  I realized then that there are actually a lot of things that are done differently by the "computer geek" set -- a group which tends to include all of the best developers I know.  Mainly, I've observed this in the differences between developers at my current employer (a large, traditional retailer) and my previous one (Microsoft.)

Geeks have different priorities than most people when it comes to software engineering jobs, and attracting and retaining them at a company can require some different strategies.  And they're worth attracting and maintaining, for two reasons: first, most of the really good developers fall into that category, and while you don't need all your developers to be superstars, it sure helps if some of them are; and two, because they don't care all that much about the money.

What does matter to them?  Several things:

• Autonomy.  Micromanagement drives them crazy.  This is a case where you must follow management-by-results, not management-by-tasks.  Figuring out how to do things is precisely what geeks enjoy about work -- tell them what you want, not how you want them to achieve it.  They'll figure something out, and be willing to go above and beyond what's required, because it's theirs.  Whereas if you give them a checklist, they'll do it haphazardly, because they're not invested in it.
  
• Isolation.  Geeks, all told, are not very social.  They do their best work when left alone.  The cubicle is a horrible environment, giving you all the obstacles to collaboration of offices but without any of the privacy.  Offices are ideal for most development work, the only exception being the early stages wherein there's a lot more collaboration and brainstorming than actual coding.  Actual coding needs extended, uninterrupted quiet time (well, sometimes it's not quiet at all if you count music, but the sounds are chosen.)  Geeks coding get into the "zone" -- a 5-minute interruption can and will cost you an hour of productivity.
• Technology.  Geeks want to be on the cutting edge.  You're not going to retain one for a project writing Yet Another Database Front-End unless you've got a truly amazing work environment (or seriously overpay them for work that frankly doesn't require superstar developers.)  More interesting projects often mean more than higher-paying projects.  In addition, it's worth investing in the technology they'll use every day.  Sure, they may not really "need" a $4,000 dev workstation with two LCD monitors... but they'll be more productive with one, be happier working on it, and it'll do more to retain them than you would from a comparably-sized raise.  Ever having to wait on substandard technology to keep up with them is irritating.
  

Most importantly of all, though, geeks despise "politics," where by politics I mean any situation in which interpersonal considerations outweigh technical considerations.  They have no patience at all for things like:

• Using an older, inferior, or simply less appropriate tool (e.g. programming language, web framework) because "the boss likes it," "we've always done it that way," or "we're a [insert product here] shop."  They need technical reasons for using a technology, not somebody's feelings.
• Anything perceived as unfair.  While I said they don't care much about money, there is one situation in which they do care -- if they feel they're paid less than market value, or that someone else who's not as good as they are is paid more.  Trying to keep salaries secret helps not at all -- they for the most part don't understand why they should be kept secret, and thus will totally disregard any order to do so.   Of course, the problem is that they're often unwilling or unable to see any non-technical factors in an employee's value, which sometimes do play a part in compensation.
  
• Fiefdoms and silos.  Geeks want to get things done.  And they don't care overmuch who does them -- when engineering solutions, they'll totally ignore interdepartmental boundaries.  This isn't a bad thing; however, managers often think it's a bad thing, since they want their team to get the credit for it.  What these managers fail to take into account is that trying to get the credit for it results in not just an inferior product but also unhappy developers.

Though I'm talking primarily about work here, these characteristics do extend outside of work, too, particularly the intolerance for personal considerations outweighing technical (or whatever they perceive as "rational" or "logical" considerations.)  Geeks don't see the point of playing a game if they can't play to win -- it's not that they care overmuch about winning, it's that the game has a framework of rules, and that framework should be complete.  I think this is one thing that makes geeks thought of as antisocial -- they don't take people's feelings into account when doing things, because those don't fit into the rational, logical, predictable framework they like.  I think that how "normal-seeming" a geek is depends largely on how willing they are to sublimate this impulse in order to relate to other people.

Finally, when it comes to performance management, geeks need to be told, directly and clearly, how they're doing and what needs improvement, if anything.  Not being people-oriented, they probably can't read you.  They don't know if you're happy with them or not unless you tell them.  And they're certainly not going to ask.  While they deal extremely well with technical ambiguity -- they love to solve problems, so an incoherent mess from a technical perspective is just a challenge to overcome -- they don't deal well at all with ambiguity in other contexts.  Clear expectations and consistent feedback turn the job itself into a problem to be solved, which makes it much more satisfying to them.

I can't help but think there's probably some correlation between what I've observed as the "software engineering geek" personality and some MBTI or enneagram types.  It's probably not an exact mapping, but it sure is something that comes up a lot -- I can pretty easily classify most of the developers I've worked with into "geek" and "non-geek" if I try. 

Posted by Grant at 09:10 PM | Permalink | Comments (0) | TrackBacks (0)

The last five years have seen two trends take off: independent (or semi-independent) contracting for IT, and offshoring development work.  Both of these bode well for telecommuters in the workplace... eventually.

Here in the Seattle area, independent IT and development contractors are everywhere... and so are jobs for them.  If I post a resume on Monster, Dice, or any other job board, I am pretty much immediately inundated with offers for 3- to 12- month development contracts on small- to medium-sized projects.  I don't usually want them, due to the inflexibility (no vacation time, and they're just long enough that I don't usually want to commit to 6+ months without any time off), but they're there.  I must confess their presence doesn't do much for the idea of corporate loyalty -- their fixed length implies they're not interested in any commitment themselves, and their ubiquity means that anyone with the skills to get one isn't really trapped in their current job.  Rather than weeks or months of interviewing to get real employment, a developer can often snag a few months of contract work within a week or two just due to the sheer number of these positions.

Offshoring development work, as much as people complain about it, does get managers used to the idea of employees that they can't see and which don't even work the same hours as they do.  Of course, they have the comfort of knowing that wherever these employees are in the world, they do have some other manager breathing down their neck.  And they're also undoubtedly comforted by the mounds of process these firms tend to use.

I think its the combination of these trends that is starting to produce automated, telecommuting job boards for development and IT workers.  The two major ones right now are Rent-a-Coder and oDesk.

Rent-a-Coder's main flaw to the U.S. telecommuter is that it works too well.  The jobs people tend to post on Rent-a-Coder are straightforward, self-contained dev jobs for one person.  They're usually no more than a week's work.  Rent-a-Coder works as a reverse auction -- people put in proposals for how long the work will take, advertise themselves a bit, and state what hourly rate they're willing to work for.  Rent-a-Coder is a pretty reliable way for a skilled developer to find quick, straightforward, and usually easy work.

However, it's just as easy for developers in India or China.  Rent-a-Coder, being a virtual job market for people who will never meet their employers in person, is truly a global market.  If you're a teenager or college student, the $15-20 an hour that development work usually goes for might sound pretty good, but skilled professionals usually find themselves priced well out of the market.  Overseas developers with 10 years of enterprise Java experience put in bids of $13.50/hr... anyone in the U.S. or U.K. who can compete with their qualifications usually doesn't want to compete with their prices.

oDesk aims to be a different sort of market -- they target companies looking for "homeshoring."  It works more like a traditional job market, in that people post themselves with a rate requirement rather than just bidding on projects.  It's less one-way than Rent-a-Coder.  In addition, being targeted at more serious projects (there are a lot of long-term things on oDesk; it's not so biased at Rent-a-Coder's usually-tiny projects), the providers often command more reasonable (from a U.S. perspective) rates.  Their current home page quotes providers with rates up to $65/hr. for some skillsets... though it quotes some at $14/hr. as well, so obviously there's a lot of variability.

oDesk, however, goes far beyond Rent-a-Coder's simple matching.  Essentially, they aim to be a virtual temp agency, a Volt or ExcellData for the nation.  They provide all their contractors with standard software (SVN and BugZilla for tracking and version control, but also presence and videoconferencing software, timecard software, etc.) and have relatively standardized contracts.

On the bright side, oDesk recognizes that the biggest hurdle companies have to hiring telecommuters is one of trust -- managers, unable to track what people are doing since they're not in the office, need proof that they're actually doing work.  My preferred solution to this problem would be to track work -- that is, integrate with the version-control tools, bug tracking software, etc. to demonstrate tasks actually completed, and use status report deliverables to have employees state their progress and bring up issues so that if someone is falling behind managemnet is informed beforehand (or can fire an employee when he fails to meet a deadline not for failing to meet the deadline, but for failing to track toward it and lying about it in the status reports until that time.)

oDesk, however, does not take my enlightened, employee-friendly approach.  No, they have a different way -- spying!  oDesk's software screenshots the telecommuter's machine every 10 minutes to give remote managers a gallery of activity to browse.  They also generously provide their contractors with a videocamera, so managers can watch you wherever you are.  And the logs show not lines of code, or checkins, or bugs, but rather the number of keystrokes and mouse clicks per minute you've made.  The result is that you can get all the stress, lack of privacy, and constant monitoring of an "open-plan" cube farm right in the comfort of your own home!  Also, oDesk keeps 30% of whatever you're paid.

Obviously, I think oDesk is, to some extent, missing the point.  On the other hand, they're a business, and their customers are not just the employees but also the employers.  That trust gap is one of the most important things for them to bridge in order to get employers comfortable with telecommuting employees.  In the long run, I think it's a good thing for telecommuters -- having hired a few people through oDesk, a manager is likely to be more comfortable with employees he can't see, and less inclined to protest the idea when someone comes along wanting to be a truly independent remote employee (this time without keystrokes-per-minute clocking.)  This said, in the short run, well, I wouldn't work for them.

Posted by Grant at 12:52 PM | Permalink | Comments (0) | TrackBacks (0)