Memorial Day 2016: A war story that predicted the future of IT

I like traditional paper books and resisted going to ebooks. I like to think it wasn't because I was stupid, I certainly understood the value of their portability but I thought ebooks were soulless. I grew up in a time where a quality bound book was a piece of education and also a work of art. It was collectible and you could get an author to sign it. It had value. But eventually I succumbed to the lure of being able to have thousands of books on my phone.

I was slow to adopt audio books too, but recently started up after flooding in Houston caused my commute to become longer. And I've wiped out three books in six weeks or so, improving my rate of attacking my backlog.

One of those books was Day of Infamy, by Walter Lord. It was written a long time ago but is a detailed overview of the Dec 7, 1941 Japanese attack on Pearl Harbor. It's a great book. The Pearl Harbor attack was a surprise and a shock to many on the islands. Some people even mistook the inbound Japanese airplanes for Americans on training maneuvers.

When the servicemen understood what was going on, many moved to respond, trying to help others or pass the word. Many others tried to put up whatever resistance they could, even firing at passing planes with small arms. Getting those small arms was sometimes difficult. Lord's book mentions a couple situations relevant to this blog.

There were some instances where even amid the attack the supply clerks refused to issue arms or ammunition to the men without the proper authorization. This represents several of the themes I've noticed in our IT industry.

• Revering Process at the cost of Effectiveness. The intransigent supply clerks had a narrow focus on their role, which was essentially to control inventory. They lacked an appreciation for the larger picture and worshiped the traditions of their gods rather than the reality surrounding them. The impetus for this thinking may have been grounded in reasonable motives (cost control, safety, accountability) but such adherence to dogma rather than the primary goal of the institution (in the case of the US military, to defend the nation) may have cost lives. This anti-pattern is often the fallout of large organizations that have naturally segregated duties for specialization and formed silos of knowledge. These silos have their own management chains and can take a counterproductive focus as they work to justify their existence. This behavior doesn't require a large organization though; there are plenty of inexperienced managers out there that can do the same thing even in small companies.
• The Road to Hell is Paved with Good Intentions. I probably don't need to explain this one. In a world increasingly driven by people and groups that have mastered the ability to push personal interests over what's really important, you can find plenty of real world examples.
• The Tactical Reality will Override the Theoretical Ideal. Lord mentions that in some desperate cases, servicemen took axes to the locks on ammunition cages and did what they had to do. Yes, an accountant somewhere will be very hurt by the loss of the lock, but although Harlan Ellison astutely noted that "the world is becoming a cesspool of imbeciles," people are not completely stupid and sometimes humans can be surprisingly functional. Even though I can't stand the ludicrous edicts of the Sarbanes Oxley act, SOX procedures do allow for the people who can get the job done to have provisional authority in emergencies. But I'll bet money it wasn't Sarbanes or Oxley that allowed for that, but the grunts in the trenches that fought back against the original rules.

In honor of the servicemen that lost lives at Pearl Harbor that fateful day, I wish you a happy Memorial Day. 

Book Review: A Technologist's Guide to Career Advancement by John Schneider

I saw someone mention this book in an article comment and bought it as it looked interesting. I also posted a review at Amazon but wanted to write a more detailed review here.

Advice from an IT Success

John Schneider has had an eventful and successful career in technology, working his way up to executive levels. This book couches itself as a career guide specifically for technology workers. I didn't find a whole lot that was specific to technology; there is a lot of great advice in this book for pretty much anyone. Schneider writes with an easy style and uses a lot of humor and the book is a fairly quick read. I think it's probably a good book for most people who want to know how to stand out in any industry, although it's likely a bit better value for younger people who have time to put into play the things Schneider recommends.

IT People Have an Edge?

The one conceit Schneider carries that's specific to tech workers is that you can do most of the other jobs in the company but the other people couldn't do yours.

This is often true but I would prefer that it not be presented as an absolute, because I've met my share of IT people that probably couldn't do other people's jobs, much less their own. And I've met smart folks outside IT that could be great in it.

But I do like the gist of what he's getting at because it matches an observation I've made about experienced IT teams: they represent an interesting foci of business and data. That is, they are people that understand the technology, but have also probably picked up knowledge of the company's business and its clients. They also are positioned to recognize the gaps between departments that need to use the same data. That puts them in a unique position to solve problems and improve the company.

As companies grow, they naturally tend to fragment and become a collection of silos, each narrowly focused on its specific function. This is a dangerous structure that compromises efficiency, ironically the very thing that specialization is supposed to provide. It becomes inefficient because people begin working in a vacuum and lose insight into why a task is done and how it affects others downstream in the process ecosystem. Communication tends to suffer too as people get busy doing their own things and this gradually reinforces both the distance between groups and the calcification of process quirks that might have been workarounds for something that was a problem once but might have since changed. And without an oversight to recognize this condition and an agent to promote improvement, companies (even if still solvent) eventually suffer atrophy. Teams become political and defensive, trying to justify their existence and role, even if they'd be better somewhere else.

The agents of change would ideally be managers and business analysts. But we know this isn't the case; higher management typically does not listen to the things their subordinates are telling them. They've evolved into selfish entities that cater to self preservation and shield themselves behind barriers of elitist cliques and faulty assumptions that they, and not the customer, are the profit center.

Killing Sacred Cows

Schneider isn't shy about challenging conventional career wisdom.

He disagrees with some things that are considered industry best practices, notably the advice on accepting a counter offer when resigning. The general rule is that you don't accept them. If there were fundamental problems at the job that caused you to want to resign, are they really going to change if you accept the counter offer? Schneider does acknowledge that if a workplace is really dreadful you should just leave, but then goes on to say the things you've heard about taking a counter offer are "BS" and taking one is just fine. I too will concede that if the parties involved are mature consenting adults and not children that can hold grudges, it might be ok.

But people are human beings and both the company, the managers, and your peers will remember what's transpired (you might try to keep it a secret, but things have a way of getting out). Ultimately, if you had to threaten to leave in order to get what you want, is that really the kind of place you want to stay? These are legitimate caveats to accepting a counter offer and Schneider is perhaps a bit to flippant about them; in addition when he calls them "BS" he doesn't really provide an argument about the specifics of why they are.

He also seems to value the effort one could put into acquiring certifications. I think a lot of experienced IT staffers will tell you different things here. In my career I've managed to do well without certifications. Schneider feels they will be useful in helping you advance in the organization and discounts the value of seniority; that may be true in some companies. But my personal experience is that certs are best as differentiators in getting hired, not promoted. Once you're in an organization, promotions are likely to be based on a combination of things such as performance, politics, and yes, seniority. Often, very much about politics and seniority.

Higher Education

He recommends getting an MBA; not bad advice, but there's more to this than meets the eye. He casually shoots down several excuses people might use to not get one when some of them are actually really good reasons. Cost, for example. If you want to go to a prestigious program, it might cost you the amount of a nice house; I would not so flippantly disregard this barrier. And, in my experience, the value of an MBA is like that of a cert. It's probably a great way to get your foot in the door, but advancing beyond that point will depend on performance, politics, and well, seniority, though I do see a distressing trend today to put young and inexperienced people into positions of power where they can destroy companies largely because they have an MBA and are experts at cost cutting, Mark Hurd-style. So maybe Schneider is right about that after all.

Are Things Different Now?

I don't doubt that Schneider is a successful and brilliant guy and probably a good boss too, if he practices what he preaches. However, I couldn't shake the feeling at times that he's led a bit of a charmed life. His thoughts about certs, seniority, and MBAs make me feel that he's been fortunate to traverse most of his career through meritocracies. But I'm certain I'm not alone as an IT staffer that's recognized technology workers have become the contemporary blue collar workers of the world. IT shops are seen as costs, not strategic components, by most companies. As a result IT people are constrained by a very thick ceiling barring them from the highest leadership positions (roles open to operations, sales, engineering, marketing, and even accounting) where they could bring their blend and breadth of business and systems knowledge together to truly help a company forge strategic initiatives in intelligent cost cutting rather than mere layoffs and the practice of being cheap at the expense of efficiency.

All this to say that while Schneider's advice is still overall very good, it may have had more effectiveness before IT departments evolved into the bastard stepchildren of a companies today, a time before PMP's started telling us to forego innovation for smaller and more easily measured changes. A time when workers were allowed to think.

Second Thoughts on Having a Personal NAS

A year ago I finally took the plunge and joined Amazon Prime. What a happy prison it is. Good discounts, fast shipping, and lots of incentives to buy an Amazon Kindle tablet. But that's not really what I wanted to write about. It's fallout from being in the happy prison that has caused me to question whether my approach to having a personal NAS is a good idea.

So here's what's happening: I'm now buying a lot of ebooks from Amazon. I've got a Nook HD+ tablet so I also buy them from Barnes and Noble. I also have found my way on to some nice free ebook mailings. And I have digital magazines on Zinio. And comics on Comixology. And more ebooks on Steam, and some on Humble Bundle, and some more from Groupees and still more on BundleHunt. I also have a few loose ebooks on my local drive, managed by Calibre.

Do you begin to see the problem? In a world where technology is supposed to make life easier, I now have several more accounts and passwords to remember, and the sad truth is I'm probably not going to read but half of those ebooks, and that's being optimistic.

"So wait," you ask, "isn't this exactly why you got the NAS? To put all that content in one place and be able to access it from any device?" Well, sort of. The effort involved in transformation of that data from the commercial cloud to my personal cloud is sort of a pain in the ass. It's more effort than memorizing ten passwords.

When I use Amazon's cloud service for storing my MP3's or Microsoft's SkyDrive or DropBox for a commercially provided network storage, it's really convenient. Security, infrastructure, capacity and maintenance are all someone else's problem. I do get the point of the personal NAS: I have full control of my content and if Amazon goes out of business (unlikely) or Microsoft decides to pull the plug on SkyDrive or change it into something else (less unlikely) then my content is still safe on my own hardware. Not to mention that if any of the data is sensitive such as client information, it's better on my own device than on someone else's.

But for non-sensitive materials, I'm not sure having a personal NAS is really that big a deal. I love the Synology Diskstation I have, but it wasn't free. And it's not free to maintain, although as you've learned from my last several entries, harnessing additional functionality was really cool.

I think what I need is for someone to write a consolidation app that pulls all of this together. In the meantime, I've got a Frankenstein of a storage approach. And you know what? Even with all their problems, the happy prisons that Amazon and Steam give me for all those books, music, and games are awfully comfortable and I'm glad to have them.

The Best Bonus I Ever Got

I know I complain a lot on the blog about IT management. Well, in my opinion, IT management asks for it. Just like lawyers do when they send our society on a downward spiral to hell on riptides of lies and blame deflection.

But this post will be different. I promise. Today, I'll talk about the extra bits of cash compensation employees get outside of their base salaries. These have been far and few between in my career, so maybe this will also get to be a blessedly short post. Apologies again in advance, for some salty language that might follow.

The first bonus I got didn't come until about five years into my career. A lot of that had to do with the crappy company I worked for, but a lot also had to do with me being an inexperienced and poorly managed resource. Anyway, it was a day cruise given to my team for working hard. I appreciate the gesture, but it was on the lame side as rewards go. And I didn't like how only half the team got to go and in retrospect consider this a managerial mistake. Some of the newer team members weren't included (in what I would bet was a cost-cutting move). I felt that was not a smart way to handle team morale in an effort about raising team morale. But it's the thought that counts, so I count it as a bonus even though it sucked in more ways than one. Shit, sorry, I was supposed to be positive in this post. I'll try harder on the next paragraph.

The next bonus was much better. It came in my sixth year with my first company. I had moved to a new, smaller, team and I was doing a much better job of being useful as I'd become more experienced. I also had a more laid-back supervisor and a pretty reasonable manager. My team received an end-of-year bonus of about three thousand dollars. Not enough to buy and island and retire, but nothing to sneeze at either. What is so damn goofy is that I worked less hard for that bonus than I did for the day cruise.

I switched to contracting for a while and bonuses are typically not part of the compensation structure for hourly employees, so there's nothing to report until I switched back to full-time work about 1999. Then I got a variety of bonuses. An annual performance bonus could be between two thousand to five thousand dollars. A spot performance bonus I got was three hundred dollars.

I bounced back and forth between full-time and contracting for a while after that but didn't get another bonus until I was again full time and had a manager that appreciated my work. I killed myself for more than a year straight of overtime and got a spot bonus of a thousand dollars.

I think it's fair at this point to note some lessons I've learned about bonuses. Your experience may be different. In fact, I hope it is. I hope you've done significantly better.

• Bonuses are usually but not necessarily tied to company profitability
• Bonuses are highly dependent on your immediate superiors and their superiors
• Bonuses are a very subjective thing.
• At one company I got almost no bonuses until the end, and I was working less hard than I did in the earlier years. Some employees told me of bonuses they got for putting in a mere hour of overtime. Now that's the kind of consistency that earns employee trust!
• At another company, bonuses sometimes came with formal recognition in the form of "President's Awards" or "Outstanding Performance Awards". These were REALLY ridiculous. It's not that some of the people getting them didn't deserve them. The problem was that the significance of the achievements earning these awards were all over the map. Some people got them for working hard on a specific important project, even though the teams on that project might have had several deserving people. Or two people might get awards for working on different projects, even though one was a multiple month or multiple year effort and the other was a one week commitment. It all came down to who had the manager that liked them, and in the end, I think this hurts morale more than it helps. Getting no recognition really hurts when you give your heart and soul for a long time and when you really make a difference. I'm not sure what the answer is for this bullshit though because for the people that deserve it, it is nice to see them get something.
• Don't depend on bonuses. They're not guaranteed. Hold their feet to the fire in salary negotiations. If you get a bonus, great, but either way you will get the salary.
• IT shops are pretty barren when it comes to bonuses especially when the company treats IT like a cost center. For sales and a few other divisions, bonuses may be a more legitimate part of the compensation structure.
• If you want to work in IT and get bonuses, find IT shops in companies where an annual bonus is universal to the pay structure. For example, one of my clients was a trading firm, and everyone, even IT, got significant bonuses (like 20-40% of the salary, a concept that is completely alien to me!).

So which of the bonuses above was the best one? I am thankful for them all, but the answer is, "none". The best one didn't come from management, it came from my users. One of my clients had a legacy system that had (and still has) a terrible user interface. They were suffering greatly on having to enter data one row at a time, spending multiple man-days of effort each month. I added a simple import capability so they could massage their data in Excel and then import it through cutting and pasting. Did it work? A few weeks after the feature went live, I got this from them:

That's right: a modest $25 gift card, for a place that makes food that's mostly not on my diet. It's the best bonus I ever got. Why? Because as Jeff Atwood would say, it showed that people were using my software. It showed that my work improved lives. What makes this bonus great is not even the $25, but the kind comments from my users on the card it came with. 

Now I'm sure there are managers looking at this and saying, "Gee what an asshole that Bernard is. How could that meaningless shit be worth more to him than a thousand dollars?" Man, if you're a manager saying that right now, I pity you. You have completely missed the boat on how to do your job and how to be a leader. And I pity even more your subordinates.

Oh shit, I'm supposed to be positive! Ah, ok, well, I took the card and had a nice date with my wife, eating wings before a movie.

And for any overly literal pinheads reading this, no, this doesn't mean I don't appreciate monetary bonuses. But really, this kind of recognition is truly special and particular to software developers in the same way that a compliment to a chef or an artist means as much emotionally as the money. The chef gets a paycheck either way, but if he knows his clients were enriched by his cooking, he has a sense of purpose fulfilled. And this really is where IT management really needs to get a better understanding of how technical people respond to feedback.

We really don't give a shit if you praise us for good attendance or being on time to meetings. We do like pizza, but throwing a pizza party isn't really doing much for morale. When you use metrics like how many SOX audits we passed or how little we were penalized for dress code violations, you're just drawing attention to the parts of the job that suck. 

The Empowerment Ratio

It's really hard to be a grunt in IT. It's even hard to be a manager or leader in IT. At least, it is if you care and really want to do more for your users and clients and your teams. As this industry advances you'd think we'd collectively improve based on lessons learned applied institutionally. It doesn't really happen like that though.

Yes, we do see some improvements. Since I started working in IT, several things are better than they've ever been: user interfaces, databases, source control, languages, tools, and some processes. And of course the hardware is amazing now and just getting faster and smaller and sometimes practically invisible: virtualization is a very useful tool. But even with all those trappings of the software development space getting better, the people parts of the industry continue to exhibit tremendous and appalling flaws contrary to the ideals of such intellectual pursuits.

One of the things that has most frustrated me, and I'm betting it also dogs many of my industry brethren, is a concept I call the power-responsibility ratio, or the empowerment ratio. I mention it in this post because it's a concept that will be used in a future post. It's a problem not just in IT, but in all industries. The power-responsibility ratio is the rating of power a person has to effect change relative to the amount of responsibility they have over a particular process or domain.

Example: the typical IT support team has responsibility for an application's operation. This includes being the first point of contact for anything that can go wrong: network infrastructure, hardware, software defects, user error, process error, data error, interfaces, cross-system discrepancies and reconciliation, bug fixes, new features, project management, data fixes, source control, documentation, and probably a dozen other things I've forgotten to mention.

Now that's a lot of responsibility. But if any one of those factors in the system ecology isn't efficient, it can affect the total productivity of the team. So if there's a problem, the team just changes it right? Not exactly. IT grunts are increasingly beholden to productivity sapping cruft and dense processes invented by people that don't have to suffer the consequences of these process deficiencies:

• Want to change to faster hardware? Get permission from someone else.
• Want to move to a more efficient document system? Get permission from someone else.
• Is there a particular user that's proving intransigent about using the system correctly and doesn't want to learn, but continues to create problems? Good luck replacing him.
• Someone on your own team proving unwilling to follow the best practices everyone else is? Didn't you hear corporations don't fire people that are incompetent anymore, they only fire people that are politically incorrect.
• Want to upgrade the software to the latest version of a framework? No can do, the project manager thinks that effort is wasted because it's not part of the business needs.
• Think you found a way to reduce the overhead in those data fixes that are killing the team's capacity for more strategic work? After filling out forms in triplicate, you find out it was denied because the powers that be just don't feel it's that important; powers of course who don't have to suffer with processing the repeated data fixes.

I'm being a little facetious here because not all management says "no" to everything, just most. But the point I'm making here is not about the having to ask, though that's part of the inefficiency of it all. It's more that IT workers may be the least empowered people in modern organizations. Accounting has a lot of power because it manages finances and in the case of some controllers, accounting actually has to take managerial responsibility for some regions and therefore must understand the business. IT is similar in that it learns about the business and the data that flows through a company, but do IT people have the power of accountants? Not really. R&D, they're usually getting to do things that help the company and as they're seen as a part of the company's core business and its future, so they are deservedly respected and have some influence. HR certainly seems to have garnered a big part in organizations now. Sales and marketing? Please. But IT is expected to be on-call 24x7 and can't get approval for even simple changes.

That's an incredibly frustrating position to be in: You hold significant responsibility over a domain but have very little power to improve it.

What's really sad about this is that the solution has long been documented. In the military, effective leaders know they have to trust the boots on the ground to be able to manage their unique situations, and those boots need to be able to make changes efficiently, or at least as efficiently as possible in the behemoth military. [Note that I'm not saying the military is all good here, it's certainly had its share of gaffes, key leaders are often clueless, and it is hardly a universal exemplar of a properly applied empowerment ratio. But selected groups, like the Special Forces, have figured it out.] And in many management books the concept of empowerment has been a popular one. It's not like this is some secret that can only be implemented with excruciating pain or arcane spell casting. The solution is a simple thing, a single word: trust.

A lot of organizations have a long way to go before they will be able to take advantage of truly superior IT.

Contract vs. Full-time

I've made another job change and this time I've returned to a mercenary's trade. I'm a contractor now (sometimes called consultant in IT circles). There's a long story behind why I decided to do this (some clues to which were in the last couple blog posts) but in the end I looked carefully at where I was and made a list of "reasons to stay" and "reasons to leave" and though there were some good reasons to stay, there were a lot more reasons to leave. Maybe more on that in a future post, but speaking of contracting, IT consultant Paul Glen has penned another very good one for Computerworld's April 19, 2010 issue.

In the essay, Glen cautions against not taking a closer look at factors involved in the contract-to-hire issue. His advice is usually sound and is so here, but a few omissions reveal his proximity to the ivory tower. Glen notes that contract-to-hire can be a good idea for both parties, but that some contractors may not be good matches for full-time employment if they are really happy with the consultant lifestyle (superior monetary compensation, travel, constant variety in projects and people) and may grow disenchanted with a full-time role.

Let's stop and think about that for a moment. In a previous post, I said I didn't like the way most IT shops used contractors, largely because I felt these shops were giving the most intellectually engaging work and pay to contractors and treating their full-timers like second-class citizens. Well, I still think that's true, and sadly, I've thrown in the towel on my hopes that this would change.

Glen's dancing with a contradiction here that contractors are somehow less valuable to an organization than a full-timer, even as he admits the contractor's duties are "fun and lucrative". What? Are full-timers not supposed to like work that is fun and lucrative? Are they supposed to ignore that mentally engaging and challenging work is often given to contractors while they are asked to sit and guard a light switch? Should they be only the types that "will gladly go to work on your help desk" for the rest of their lives with no upward mobility or appreciation?

I ultimately believe that Glen and I are on the same page about contractors. What I don't like is the article's failure to mention that if Corporate America wants to retain the best talent and bring it in-house, then Corporate America needs to give people a reason to want to be full-timers. There needs to be something to distinguish the full-time role and it doesn't start with looking at contractors and full-timers and trying to set them apart. What companies need to do is stand behind the lip service they pay to the hollow chant of "we love our employees" that they continue to print in their annual reports and recognize the value of the intellectual capital an employee brings through experience, expertise, and commitment to a company's clients, and to recognize the cost of turnover and mediocre quality. This means doing the things I've mentioned in the past: investing in employees, providing some education, and building an environment where they can take initiative to make changes in processes or tools that lead to efficiency and value. A company cannot crush employee morale and then expect miracles to happen. Even the most passionate employee can reach limits, right Mr. Glen?

There is a sad and disturbing analogy for this discussion: the US military. The military is outsourcing several duties (security details, civilian support) to companies like Blackwater and Halliburton. These contractors are paid handsomely for their services; significantly more than the US's own line troops. The US soldiers risk their lives for a client whose appreciation is suspect in a difficult war where the opponents have the honor of cockroaches. As the young privates and seasoned sergeants and even the priviledged officers look to their flanks on the battlefield, they see security consultants zipping by with better equipment, relaxed rules of engagement, and fat wallets. The army may be a volunteer force, but I think they can be forgiven for asking the understandable question, "Why?"

People will say, "Oh, but the full-time government troops have honor and job security the contractors don't have." Perhaps, but honor and 25 cents won't even buy a cup of coffee, much less pay the rent for the wife and children awaiting their father's return. And the job security is an illusion; if war should wind down, the army will be under the same pressures the consulting firms will be to cut costs.

People will say, "Oh, but soldiering is a calling, like teaching, so they don't need money." No way, you don't get to use an excuse that flimsy. Screw Jerry Brown and his "psychic income" cat crap. The bank won't accept psychic payments for the mortgage.

So here's where I get off the tangent and back to the point (as the readers, no doubt, say "thank God"). Yes, the reason some people like contracting is because it is fun and lucrative. But it doesn't have to be that way. Companies can, without having to break the bank (which they're already doing for contractors), make the full-timer proud to be a full-timer, and make the contractors want to be a full-timer. It's simple economics and capitalism: be competitive. Make full-time roles fun and lucrative.

It starts at the top with management.

• Have the philosophy that your employees do matter. Don't just say it; believe it.
• Be cognizant of what the compensation levels in the market are and competitively maintain your people's salary and benefits so the thought of leaving never occurs to them.
• Actively recognize them when they do something that helps the company.
• Find good projects for them that are engaging and not just about guarding light switches. You were able to do it for the contractors, I'm sure you can do it for the full-timers too.
• Let them keep their skills up to date. I'm not saying let them create a custom application inventory of a dozen disparate languages and platforms (no one should want that), but understand that technology is both your job and your responsibility. When a technology or technique comes along that can save time, reduce production support, make users and clients happy, and help the company in ways even the CEO doesn't know about, take the initiative to promote it and materialize it even when the PMO and the business may not have it on their radar because technology isn't their job and responsibility.
• When the PMO wants to make a project happen in an unreasonable time frame, don't throw your staff under the bus for personal gain. Yes, there are emergencies when unpaid overtime is a necessity, but if you're doing your job, they are the exception and not the rule.
• When your employees do work unpaid overtime, recognize and show appreciation for it. The contractors get that appreciation built into their rate and ability to bill per hour. Your full-timers don't, and when they look into the flanks and see contractors getting richer while they get poorer for the same work, or worse, for fixing the contractor's errors, believe me, they ask "why?".
• Appreciate what the mantle of management means. It means managing your employees. Don't wait for your full-timers to ask for a raise or a mentally engaging project. Some of them won't; they'll just vote with their feet, especially if you've been the kind that has enjoyed saying no to them several times in the past.

Contractors and full-timers aren't all that different, especially if you have been the type to use contractors in the same way you would use a full-time employee. They are both human beings and while yes, there are some differences in what each individual wants, at the end of the day it needs to be recognized that everyone's really there to make the mortgage and pay for college tuitions. If management could be less about cost cutting and more about building an environment that encourages the attitude of wanting to deliver world-class results and quality, then maybe production support wouldn't be so heavy, your full-timers could develop into the crack team that could do it all, and the need to ask who would be a good contract-to-hire candidate would go away.

Don't like what I have to say? Don't worry, it's just a rant. And I'm not holding my breath waiting for Corporate America to change.