Ian McAllister, GM at Amazon. I lead the AmazonSmile program.

First, let’s break “getting things done” into two components: “excellent functional skills” and “drive”. Someone with great functional skills but poor drive will not get (enough) things done. Someone with great drive but poor functional skills will not get things done, or they’ll do the wrong things, or they’ll do the right things shittily.

  • Excellent functional skills

You can probe for domain knowledge and functional skills effectively in an interview or on a phone call. You come up with a list of role-specific responsibilities, probe deeply (several levels below the surface) into past examples where they’ve done similar work, and give them example challenges and see how they perform. You can make allowances for language or tool by letting them pick the language or tool of their choice, but don’t give them a pass on accomplishing the task set forth.

  • Drive

Drive is tougher to gauge effectively. You’ll have to form a picture of drive based on a number of different signals, and use your judgment on how heavily to weight each one.

Projects they’ve initiated - Are they spawning new projects, based on their own ideas or prototypes? If so, that’s evidence they’re pushing the boundaries of their role in good ways. If they haven’t, then they might make a good soldier, but you’ll know going in that they’ll always need someone to tell them what to do next.

Variation in projects or roles - Have they worked on the same types of projects for 5+ years? If so, they might have deep knowledge and be able to get things done in that domain, but it is evidence that they have a comfort zone. They clearly don’t have a drive to leave or expand their comfort zone, and may not be effective if your role places them outside of it. Look for evidence that a candidate has initiated some type of change in the type of work they do.

Progression in complexity of projects or roles - Someone good at getting things done gets more done over time. Often the results of this are not more projects, but projects of larger scope and complexity. A good résumé will show this, but you can also probe for it explicitly.

Side projects - I have a hard time hiring engineers, web developers, or designers (maker roles) who don’t have a history of side projects. These days, if you’re hiring a young engineer you’re looking for one who has been coding since she was twelve (or younger).

I intend to add more signals as I think of them, but hopefully these are a start.


comments powered by Disqus