Those of us who work inside the black box that is software development make a lot of distinctions when it comes to our peers. To the world outside that box, we're "good with computers," which means that making a pivot table in Excel, unjamming the printer (for the umpteenth time), and hacking the Pentagon are all in a day's work.
Managing a team of programmers is a matter of depth management. You can't afford to be too shallow in any single area of expertise, or you will pay for it--in bugs, wasted resources, frustrated customers, a messy codebase, leaked data, and more. The most common defence against the dangers of shallowness, so far as I've seen, has been to focus on functionality--assigning people to broad roles like information security, database management, user interface, etc. Not surprisingly, technical certifications and years of experience with a given technology are the criteria for hiring.
I'm not knocking certifications or experience--oh, no. But I do believe that the approach over-emphasises a tactical approach to team-building that may be a strategic liability in the long run. Here's my take on what managers should also be looking for at interview time. It's about the unofficial roles that will eventually constitute the bulk of your new programmer's value to the team.
The Here-Go-Bash-Yourself-Against-This-Technology-And-See-If-It-Works Programmer: This is someone with a streak of McGyver in their make-up. But make sure that they're also someone who's had their heart broken a few times by The Next New Hotness (TM). Ideally, though, you should have multiple people who can cycle in and out of this role. Because all programmers need a vacation from chasing billable hours. Most especially those who have to maintain other people's code.
The Scalability Programmer: This is the one who already has A Plan, should your website go viral during the Stanley Cup or Superbowl. This is also the programmer who will talk you back to sobriety after Sales has convinced you to put that half-baked demo. on a live webserver for their customer to start using.
The Security Programmer: This is the one who flips out when they learn that you're only encrypting passwords with MD5 and not 1024-bit SHA-2 hashes. (No, you don't have to know what that means if you don't already.) But if they show more interest in how your website can be broken than in how to make it fast/pretty, that's actually a good thing, on balance. When the next round of celebrity nude photos or filched credit card numbers hits the news, you'll be thankful they're around. There but for the grace of those folks go you.
The Need-for-Speed Programmer: Performance jocks are good to have on staff, and they're likely to mesh nicely with the Scalability jocks. But. There needs to be a mutual respect between them and the Security Programmer, unless you enjoy breaking up spitting-matches. (Trust me, the rest of the team will not enjoy them.)
The Archivist Programmer: Programmers who actually write things down are a rarity. If you don't already have an internal wiki, set one up for them. If they're the only one ever using it, leave it alone. If their time-sheets run longer than "Anna Karenina," that's okay. There will come a time when having that information on hand will save your butt. If you ask nicely, they might even wiki their meeting notes for you.
The User-centric Programmer: Oddly, this person might not even know their way around Adobe InDesign or how to make CSS work in four dimensions (on all browsers, nat'cherly). Basically, what you're looking for is empathy--the ability to imagine themselves in the user's seat. It's a scarcer commodity than you'd think. Someone who points out that the order of the "OK" and "Cancel" buttons are flipped around on your mock-ups isn't being retentive. A user clicking one because it's in the same spot where they're used to seeing the other can cause a whole lot of damage.
The Process Enforcer Programmer: You have a process for a reason. If client data was a month late in arriving, you emphatically do not skimp on Quality Assurance to make up lost time. The Enforcer is there to remind you that bugs are much cheaper to fix before they go out the door, and that an account-level conversation with the client should be happening sooner rather than later. The Enforcer will likewise point out that server upgrades the weekend before a major release are a special snowflake of stupid.
The Hardware Geek Programmer: Someone who can rise above the Windows-Mac-*nix-Android-iOS spit-balling is invaluable. And not only when you need to have all the circuits holding hands in a circle singing "Kumbiya." To many average programmers, the hardware, and even the network is becoming increasingly invisible. Until it breaks. That's why you want this geek close on hand.
The Programmer You Can Show to Clients: There's no substitute for first-hand information when software is being designed, feedback is being given, or bugs/inconsistencies are being worked out. In fact, substitutes just add friction and increase the likelihood that the client will receive less value for the dollar. If the "communication skills" blurb on a programmer's resume turns out to be something besides filler, do not squander the chance to make use of them.
This is by no means an exhaustive list. And it probably goes without saying that a programmer with a few years of experience in a decently-run code shop or I/T department will probably take on more than one of the above. Just don't expect them to wear all those hats, even during the course of an entire career. That's the same kind of unicorn-hunting that leads to the myth of the full-stack developer.
- - - - -
* A special note of thanks to my husband Dennis for helping me round out this list.
