Kyle Smith

Had an interview recently with a manager about a development position.  When I asked for his organization’s view on spending company time to work on patents, publications, and Redbooks his answer was that they certainly valued patents, and depending on my family situation I should be able to find some time to work on those types of things.

When I later asked about working on an M.S. or participating in a BizTech project he started talking about turning down my workload to 80% and the management team understanding that I’d be working on other things.  Elsewhere in the conversation he mentioned “turning it to 100 or 120.”

Am I the only one out there that doesn’t want a job where I’ll be expected to sacrifice time with my family in order to work on intellectual property for the company or am treated as a machine with a knob that can tune how much and how hard I work?

I’ve been taking a small break from reading Isaac Asimov’s Foundation series to read some other books I picked up from the newly-discovered IBM Poughkeepsie site library. One of them I finished was Cem Kaner’s book Lessons Learned in Software Testing, which had one lesson in particular on evaluating tester performance that caught my eye.

How should a tester (or other employees) be evaluated? Rather than look at arbitrary metrics like bug counts, familiarize yourself with their work (the actual bug reports, documentation they’ve written), collect comments from coworkers or project stakeholders that have interacted with them, and consider the following items:

• What fights does he get into and why?
• How well does he meet deadlines?
• How well does he keep his own promises?
• What kinds of problems does he miss?
• What types of assistance has he provided to other testers and
  programmers to make them more effective or more productive?
• Is he gaining new skills? How well is he transferring his skills to
  other testers?
• What issues has he taken stands on in your company? How do these reflect on his business judgment and personal ethics?
  (Source: Lessons Learned in Software Testing, Kaner et al)

For those of us that have worked at IBM, being evaluated on the above items would be a pleasure compared to Personal Business Commitments (PBC) ratings and results, which never seem all that concrete to me.

A second article that caught my attention earlier was from Seth Godin and talked about sheepwalking.

I agree with Seth that the employee can’t be faulted initially, but after the typical probation period I think it’s entirely the employee’s fault if they aren’t able to break from the flock of average performers and demonstrate some initiative. As much as I’d like all companies to have creative cultures like Google’s or that of a startup, it’s not going to happen. Once the company is established the happiness of the shareholders or funders inevitably becomes the primary concern.

Thankfully, I think as long as a company is willing to allow people to innovate for a few hours a week that’s enough. If you’ve hired the right people they’ll take the initiative and locate or create opportunities to be innovative and make the most of that time.

When I first started full-time at IBM I quickly got bummed that my manager wouldn’t let me go off and work on any project I wanted to. After several months I’d had enough and started working on small projects on my own in my spare time. Once I’d demonstrated to him that I was able to accomplish my regular work as well as my side projects, he started suggesting other opportunities to me and giving me more freedom.

Since then I’ve worked on two redbooks (and am scheduled for a third), started writing an article series for developerWorks, signed up to teach a weeklong workshop in Ontario, and participated in two “patent farms”.

The point? As long as you’re willing to take the initiative being creative shouldn’t be a problem. An easy place to start is to determine where the boundaries are between your job role and your coworkers job roles and then fill the gaps (don’t try to take over their roles).

If you’re not willing to step outside your comfort zone, be prepared for a very boring 9 to 5 job and an equally mindnumbing career.  If you’re looking to change that behavior you might check out Robert E. Kelley’s How to be a Star at Work (thanks to Bryan and his “How to Kick-Ass at Work” discussion group). I highly recommend reading it.

I doubt many (if any) of you are involved in hiring employees but I came across a post on TrueTalk by way of Jason Yip which had an awesome quote:

Friend of mine used to say, if you need to hire something that climbs a tree, hire a squirrel. You could train a turkey to do it, but it’s a heck of a lot simpler to go with the squirrel. Or, “hire for temperament; train for skills.”

Unfortunately I’ve encountered a number of employers that do the exact opposite. They hire the people that have a particular skill they need right now and neglect to look at the rest of the candidate. As soon as they see “Linux” or “Java” on a resume tunnel vision develops and everything else is forgotten.

When the next project starts and the manager (or a coworker) realizes the employee doesn’t have the skills or adaptability to do it properly, it’s too late.

When I interviewed at Microsoft in 2005 I got the sense that even though they had an immediate need for a particular skill, they refused to give in to their desire to hire someone that had it without looking at them as a whole and considering how they would perform on project N+1 or N+2. The writings of Joel Spolsky and William Poundstone seem support my view. I also get the sense that Google looks for more talented people (like my friend Dave from elementary school).

Sadly I’m pretty sure companies won’t improve their hiring process even though they’re already being bit by this problem.