Up or Out - the attitude for contractors

I've just read the article Up or Out on The Daily WTF. This is related to/based on Bruce Webster's article Wetware crisis: Dead Sea effect. They provide a fascinating look into the culture of the skilled IT workforce as it pertains to over-zealous attempts at retaining skilled workers.

So I got to thinking about how that applied to myself, and my past experience in IT. I've worked both as an employee and, recently, as a contractor - and I've certainly noticed the difference in attitude between the two.

I believe that contractors automatically have this "up or out" mentality. They know that their required skills are wide and varied, and that to keep ahead of the game, they need to keep their skill-level up. Staying in one job for a long term leads (eventually) to skill-stagnation. Not because the company no longer has anything to teach a contractor, but because of a case of diminishing returns.

As the article states, any skilled worker can learn a lot more by exposing themselves to new opportunities, than by sticking with a single firm. However, contractors seem to be far more aware of this fact than long-term employees (even the skilled ones). Contractors seem to have learned the lesson that current and diverse skills are marketable, and that in-house knowledge of a specific system, while beneficial to keeping a specific job, doesn't lead to expansion of a skill-set. This leads contractors to constantly push themselves to try new and different things to stay ahead of the game - to keep themselves a marketable commodity.

Employers don't seem to have kept up with this understanding. The majority of employers look poorly on hiring contractors (except for specific skills lacking in-house), compared with potential long-term employees. Contractors fall foul of the attitude mentioned in the article - the feeling that contractors are just "dating around" and aren't serious about their committment. This despite the fact that employers are no longer loyal towards employees (a job is no longer a career-for-life).

So are contracters flighty or are they simply being honest? We know that our skills improve by varied experience. Stagnating in a single shop isn't good for us *or* for the company - yet we constantly get the look-down-the-nose treatment as though we are far more unreliable than their indentured employees.

Workers and companies both benefit from fresh-blood. There is definitely a balance involved here - continual turnover can make it impossible to keep hold of institutional knowledge (which is why documenting procedures is so important!), but a company without fresh-blood will stagnate and lose market-share due to a lack of new and innovative insights coming into the company. Any firm can benefit from a good mix of the two. The fact that contractors have accepted and embraced this fact should be a sign of maturity, rather than flightiness.

I especially dislike that skeptical tone that comes with with the phrase "oh, so you're *not* interested in long-term employement". I feel I'm simply being realistic. But employers (and recruitment agencies) that employ the tone seem to imply I'm being disloyal... or committment-phobic. Neither of which is the case.

A few rare cases even seem to imply that I'm simply being greedy - shopping around for a better cash-deal, which is far from the case. While I'll take a higher salary over a lower one, I'm far more motivated by an interesting project and an opportunity to learn. That's why I'm in Rails rather than many other technologies that pay well. I would never take a higher salary just to do something that was mind-numbingly boring and, in my mind, dead-end. I'm just stoked that I get to work in a field that is cutting edge *and* well paid at the same time ;)

I have no problem with sticking around with a group that values me and that contributes to my own experience. My current contract (with SIRCA) has lasted more than a year. I fully believe that I have added value to this project. I also have learned a great deal. I have also had smaller contracts where I have provided some chunk of functionality or code-review - each of which added visible benefit to the site I worked upon, and also provided an opportunity for me to learn some new aspect of the technology I work with. This is an equal-footing relationship - where both parties receive value.

My previous employment has included roles in which I felt my input was not valued, and in which I had no mentor from which to learn. Effectively I was gaining no value from them, and they were not gaining full value from me either. I stuck around for a long time trying to help out with the project - and eventually left due to burn-out. In hindsight I should have left far earlier and moved on somewhere that I had an opportunity to grow, and that valued the insights I was able to bring. It would have been a better opportunity for me - and the company I was with could have employed somebody that they would have felt comfortable with - increasing their return-on-investment as well.

In a free market - there's no point in sticking with a relationship that is not valuable, or which provides value only to one party or the other. I won't leave for reasons of greed or lack of committment - I'll only leave if you and I are no longer gaining enough value for the professional relationship to be worthwhile.

If an employer doesn't feel that this is reasonable - then we need a good talk on the concept of "fairness".

Healthy economic relationships come about when both parties benefit. Anything else doesn't make economic sense. When the benefit to one or the other fades over time, then it should be understood that this will lead to the eventual ending of the relationship. It's simply a matter of good business practice - and shouldn't be looked on as "lack of committment" any more than moving to a cheaper/more efficient supplier.

</whinge> :)

Update: Bruce Webster has written a follow-on article: some thoughts on up or out which gives a few ideas on how to avoid developer-churn or the Dead-sea effect (and even counteract the thermocline of truth) by providing a non-managerial track for techies to follow. I completely agree. If there was a way "up" that didn't involve "out" I'd go for it!

The Economics of IT salaries

I have been reading a book called "The undercover economist"[1], which mentioned the problems with "asymmetric information" in negotiations. It's discussed on pp112-115, if you want to look, but to summarise, the problem is thus: A 2nd-hand car salesman is trying to sell all their cars - whether they are peaches or lemons, and wants to get the best price for each. The buyer is not willing to pay as much for a peach as for a lemon. The salesman knows if any given car is a peach or a lemon, but the car buyer does not. This is the "asymmetric information".

The salesman will, of course, say "all my cars are peaches" (especially if they are not) and to try to charge accordingly. The buyer must then decide if it worth the risk of potentially paying peach-prices for a lemon. If there is no accurate way of telling one car from another, they will often choose not to buy at all.

The problem is that even if the car really *is* a peach - the customer will still not be able to believe the salesman... after all, he'd say that if it was a lemon too.

In this case, both the salesman and the customer lose out, because the salesman is in command of information that the customer is not (ie the "peachness" of the car in question).

The only way out of it is for the salesman to offer undeniable proof of a car's "peachness". The customer can then trust that the car is worth the price - and is more willing to buy.

In Australia, this is done with independant inspections, (eg done by the NRMA). A customer can be fairly certain that a car that has passed inspection meets a basic level of quality. Doing these tests takes more time that the average car-buyer has (especially when they have so many to look over), but it's worth the time for the salesman to get it done, as they then have undeniable proof of peachiness.

But it's relatively easy to verify the quality of car: does it, or does it not have working brakes? Well, test the brakes and see if they work!

What if it weren't so easy - with a set of skills that are subjective, and tests that are at best indirect, and at worst misleading. For example, how do we tell if one IT-worker is more skilled than another? How do you measure skill in IT? and who's doing the measuring? In fact, who is the buyer in this kind of transaction?

Measuring your l33t sk1llz

In the first place, we all know that it's pretty hard to tell how good one programmer is from another. Sure, it's sometimes pretty easy to assess ourselves relative to one another. Obviously David Hanmeier Hansson is easily more skilled than my kid sister. He's certainly better than I am... but am I better than my colleague in the next cubicle over?

I like to think so and I'm pretty sure that my paycheck says so too... but I'm only guessing that... and is a paycheck a reasonable guide anyway - or is that just a cue for a feedback loop?

A year ago I was working for considerably below the average salary[2]. Partly it was because I valued job-security (and thought I had it[3]) but I've been trying to figure out the other part. Why is it that companies with certain types of management don't offer more to their IT workers? Contrariwise - why is it that some companies hire idiots and pay them huge sums of money?

There was a Paul Graham article that explains that the average PHB can't tell if a technology is really good or not. They simply don't have the requisite experience to make an educated distinction.

By corollary, they also can't tell if the technology skill of their workers is really good (after all, if they don't know how to use it, how can they tell if *you're* using it to the best advantage?). The only clues they have to go on are the skills that they can see and judge from their own experience. These tend to be more socially oriented: is the worker well-dressed, articulate yet polite, well-behaved, do they show due deference to the PHB, do as they're told etc. The average PHB can measure these hirself, so they get put to the top of the list of required "professional" skills.

The skills mentioned above may well be a good indicator of whether or not they'll get along well with the manager, but they are clearly not a good indicator of skill in IT.

Now, I'm not saying these skills aren't important. Doubtless, most of these have their importance in a workplace, especially where one must get along with peers. Without any level of skill in the above list, friction will eventually ensue... and yet the original point here was not to tell how good an IT worker would be at making friends in the workplace, but how good they'd be at being an IT worker... and surely actual IT skill should rank up there as an important part of the job requirements.

Now, a good, skilled techie may know reasonably well how they stack up compared to other techies (s)he's worked with - at least within a few degrees of freedom). They tend to know that if they hand a tough task to Jo she'll get the job done quickly and elegantly, but hand it to Sarah and she'll need a fair bit of hand-holding so you'd better give her the easier tasks while you get on with the "real work".

A less-skilled worker, by contrast, may not have a clue how good they are, and you can't compare at all if you've never worked with a person[4]

So maybe they can tell, roughly, by contrast, their own level of skill - maybe it's not accurate, but they've probably got some idea of where they think they stand. In any case they have information that the PHB doesn't have... and, come review time, every worker will say they are a peach - especially if they're a lemon.

And those that have better social skills will be more convincing to the PHB.

What does the PHB think?

Now, a manager that was actually skilled in IT (eg one that had "come up through the ranks") might have a chance to judge accurately. This neatly slams up against another perpetual problem of the IT trade: that if you promote your best IT workers into management - you are wasting the IT skills that made them good in the first place. Not to mention the fact that to be a good manager requires a completely orthogonal skillset to being a good IT worker.[5].

Of course, if promotion is based on IT skill - you're in a chicken-egg situation. How do you judge good skill to promote if you cannot trust the skill-judgements of those around you? Paul Graham calls this "the design problem".

What does this mean for an organisation?

In my experience, the problems from asymmetric information are amplified in monolithic IT organisations (eg the IT departments of banks), which nurture this kind of manager - and also seem to nurture a higher percentage of mediocre programmers.

If a manager cannot tell if their workers are skilled or not - they aren't prepared to pay as well - after all, the worker might really be a lemon, just saying they are a peach. But a real peach may know that they are - and thus won't be prepared to take the low pay... so they have no choice but to leave. Everyone loses.

This is a self-perpetuating cycle. I don't know how it all started, but you can see that it'd be nigh-on impossible to break out of. A mediocre manager would not be prepared to offer competitive pay to his employees - as he's simply not prepared to pay peach prices on the offchance of buying a lemon. This causes all the actual peach epmployees to leave - they know they can get better pay elsewhere... leaving only the mediocre programmers (and lemons) behind in the monolithic organisation.

Which leaves only mediocre pickings for employees to rise through the ranks to become mediocre managers themselves one day... or the hiring of managers, but without the benefit of a sanity check on IT skills from the employees. In any case leading to generally the same cycle - bad managers, bad employees - lemons all round.

Thus the monolithic organisations fail to get or keep good staff, and the only place to find them is in the small, agile development houses, or in contracting - where a peach can have a chance of negotiating more directly with clueful people.

Which matches what we see around us every day...

Is there any way out of this for large organisations?

Not really sure it's possible. I know some do - but my gut feel tells me this only occurs by chance. If they happen to stumble across a peach by accident, or if one decides to take pity on an organisation and work at making it a better place. But it certainly doesn't seem to be the norm.

The only cases I've really known are where peaches don't know their own worth and stay on, thinking they are worth less than they are. In a mediocre organisation this might last for a while - as their worth is determined by people who don't know how to accurately judge worth. But eventually a true peach will learn about themselves and leave - usually by going outside of their colleague-group and seeing what other people are acheiving in their field - ie by getting a better frame of reference.

Any opinions?

Notes

• [1]By Tim Harford - pretty good read, actually.
• [2]for a programmer with my experience - as measured by two different salary surveys. Note: for australia many IT managers use the Hays salary survey which is great... except that it leaves job titles somewhat vague - and several of them don't specifically have a "years experience" associated with them (especially the oft-misunderstood term "junior developer"). When going for your pay review, I recommend searching for a variety of surveys - and make sure they have years on them.
• [3]...an entirely different story that I won't go into here.
• [4] Paul Graham wrote an article about Great Hackers which also discusses how it's hard for hackers to judge the abilities of other hackers without having actually worked with them.
• [5]It is not impossible for a worker to have both sets. It is more rare, however, as a skillset takes time and effort to develop... and your IT workers are generally spending more time developing their IT skills than their social ones.