Philosophy #1: Build The Best Team You Can

It takes even the best employees at least 9 months to get up to speed.  A good hire is worth every penny you pay them (and then some).  A bad hire costs you double whatever a good hire costs.  That doesn’t mean you should overpay for talent, or that a candidate’s salary requirement necessarily translates to their skill level.  However making a bad hire because you won’t pay market rate will almost certainly cost you in low productivity, poor decision-making leading to increased mistakes and future remediation costs, low team morale, and potentially even severance costs.

Once you start hiring, interview for the role.  If you’re hiring for a Senior, don’t keep a mid-level or Junior hire on the back burner as a possibility, even if you’re having trouble finding qualified candidates.  First, it’s unfair to the candidate.  More importantly, if you’re willing to hire a mid-level candidate you should rewrite the job description and then attempt to hire the best mid-level candidate you can find.  After all, there may be tons of mid-level candidates that just aren’t applying to your Senior role.  I’ll have more to say about writing a good job description in a future post.

Interviewing should start with a phone screen to ensure you’re not wasting your time or theirs on an in-person interview.  Phone screens should be used to rule candidates out, never to decide to hire a candidate.  They should ask a broad series of standardized questions across different domains, and should be designed to confirm the candidate is in fact at the skill level required for the role.  If they are, bring them in.  If you’re not sure, then pass.

Especially for phone screens, pick a side.  Thumbs up or thumbs down – make a decision and move on.  Being unsure or wanting to wait is the equivalent of thumbs down.

All interviewers should have an interview plan with questions ready ahead of the interview.  For the phone screen these questions should be standardized and used for every candidate as a baseline for comparison.  After all, it doesn’t matter that a candidate built a fusion reactor in their basement if the job you’re hiring a sales associate at a car dealership (unless perhaps if you own a Delorean dealership).  If you want to save a few minutes at the end of the interview to ask about their amazing experience because you like to hire employees who show initiative that’s fine, but remember to focus the interview on the primary skills for the job.  I’ll have more to say about how to write good interview questions in a future post.

Don’t hire the first few candidates.  I’ll discuss the mathematics behind optimal stopping theory in another post, but trust me when I say that you won’t be picky enough early on and will almost surely end up settling.  And when you finally do find the right candidate remember that a good hire is worth every penny you pay them (and then some).

The Phoenix Project

A co-worker recently loaned me The Phoenix Project, which I’ve subsequently been reading the train for the last few weeks.  If you’re an IT Operations manager who feels like IT bears the brunt of your firm’s problems (and let’s face it, what IT manager doesn’t feel that way?) it’s a great read.  More than once I caught myself thinking “Wow, this is just like my company.”

The book dispels a number of myths like “IT is knowledge work and is nothing like manufacturing operations” through close comparisons to managing work-in-progress (WIP) and the Toyota “Kata” (continuous improvement).  While the term DevOps gets thrown around a lot, the essence of the book is that IT is ingrained in almost every firm and thus is far more critical to the success or failure of the business than most executives suspect.  I wish the authors had spent a chapter on how best to prioritize the four types of work (business projects, internal projects, planned changes, and unplanned incidents), but overall I highly recommend it to anyone – not just IT managers.