Talent vs Tenure

First, I suppose definitions are in order.  Here are the definitions of talent and tenure from the Merriam Webster dictionary (http://www.merriam-webster.com/):


  • The amount of time that a person holds a job, office, or title
  • The right to keep a job (especially the job of being a professor at a college or university) for as long as you want to have it


  • A special ability that allows someone to do something well
  • A person or group of people with a special ability to do something well : a talented person or group

Now that definitions are out of the way, let me first start with my own experience.

In the late 90’s, I decided to go back to college for computer science. I was 30 and knew nothing about computers. My wife actually had to teach me how to use a mouse. Ahhh, I can still hear her dear, sweet words … “Double Click!!  NO!! NOT THAT FAST!!!!!”.

So there I was, in the computer science graduate program (I had an undergraduate psychology degree and did not own a computer) with a bunch of fresh-out-of-high-school super smart kids…and I just learned how to double click. I remember my first C++ computer lab. The instructor told us to “open this file on the desktop, select all, copy, and paste in the IDE”. Yeah, I had no idea what the hell he was talking about…copy? paste? IDE? huh? Someone took pity on me and helped me out. Whew.

Fast forward two years. During those two years, I rarely slept, read everything I could get my hands on, took on web programming side jobs that I was in no way qualified to handle, and ultimately caught up to (and surpassed some of) the fresh-out-of-high-school college students. I loved this stuff. I actually ended up administering those same computer labs where I originally had to have help copying and pasting and participated in a QoS research project. I loved what I was learning and doing.

There we were, at the height of the dot-com boom. I saw so many people graduate that I felt had average (at best) software engineering skills getting high paying jobs. I, on the other hand, was still attending classes, living in a two bedroom apartment with my three small kids, and riding my bicycle 5 miles (one way) to campus. I was really, really tired of living on student loans and not being able to afford ANYTHING. So, I decided to see what I could find, even though I didn’t have my Master’s degree yet. I believed I had gained skills that had surpassed many that had already graduated…this should be easy, right?!

My resume contained about one and a half years of “real” non-college work…which was actually quite a bit exaggerated…but dangit…I KNEW I could take on any programming job!

To my surprise, I couldn’t even get my foot in the door. If I did get an interview, it always ended up with “yeah, you just don’t have enough experience”. ARGHH. I didn’t have the tenure, but I knew I had the talent!!

Months went by, and I finally landed a Cold Fusion programming gig…my first introduction to corporate America. It was a great and scary experience.

Now, fast forward another year. The dot-com bust. I was laid off with about 50 others.

Back to the job hunt. Well, evidently that one additional year of “experience”, i.e. “tenure” didn’t mean anything. Again, I got the “yeah, you just don’t have enough experience”.

Finally, I interviewed with a great guy, who ended up being the best boss I ever had, that for some reason believed in me. He was looking for talent…what I could deliver, and didn’t care so much about tenure.

That was an amazing experience. He gave me a chance. It proved to be mutually beneficial for me personally and professionally, and for the company. We were eventually acquired by a large company where I eventually became a software development manager, which was another great experience. The funny thing is that the large company who acquired us would have NEVER hired me directly since I didn’t have the tenure!

Fast forward to present day.  One thing that I’ve learned while being in the hiring seat is that hiring for talent is HARD. Hiring for tenure is EASY. I find myself looking over resumes thinking “wow, they have a bagillion years of experience, they must have talent!”.

So, I understand now why those hiring appear to prefer tenure over talent. It’s because it’s so hard to determine if someone has talent before you hire them.

I’m not saying that tenure means “nothing”. It is something that should be considered.  However, focus on talent first and foremost.  The two best programmers I’ve ever hired had absolutely no tenure at any company. They were fresh out of college.

Hiring for talent is hard. Take your time, be creative. Why not have the candidate join your team and pair program for a day?  There are a lot of companies that actually do this.  It’s well worth the investment.  Don’t assume that just because someone has years and years of “experience” that they are automatically talented and can deliver…you will regret it if you do.


The Cross Functional Team vs. the Functional Community

An agile team consists of everyone it takes to deliver value to the customer.  The typical team consists of analysts, developers,  and testers. Of course the team is not limited to these roles.  The team could also include technical documenters, DBAs, or whoever else has a hand in creating value.

In traditional organizations, “team” is defined as a functional group.  The development “team”, the “testing” team, the “analyst” team, etc.  This makes sense in a traditional, waterfall-ish environment.

In an agile, cross-functional environment, it is not helpful to define “teams” around functions.  Okay, “maybe” its okay in a production support capacity, but that’s still pushing it as there will still need to be cross-functional work with production support.

Teams have a common, unified goal. Functional “teams” do not.  For example, a functional “team” that consists of a dozen Java programmers, with each programmer on a different project, can hardly be called a “team”.  They have no common goal, other than to adhere to the (hopefully) high development standards that have been put in place.

I propose that instead of calling these functional groups “teams”, we call them communities.  Here’s a simple definition of community that I found on dictionary.com: “A group of people having common interests“.  The Java “community” will work together to make sure that they have common standards of excellence, share knowledge and experiences, and provide each other guidance as needed.  However, these people will have different goals, depending on the project on which they have been assigned.