Colleague: Oh, hey. Do you have time to do an interview? We’ve got someone in for the open Java role.You: Sure. I can make some time. Do you have a resume?Colleague: Yup. Here you go. She’s in Conference Room C. Joe’s just wrapping up with her now.

Does anything seem wrong here?

I hazard that every IT development manager would agree that the greatest single factor in the success of a software development project is the quality of the programmers. Is grabbing whom you can at the last minute to go into the interview room largely unprepared consistent with the importance of the decision you’ll be making?

From the exchange above, we know that the hiring team has no interview plan. There’s no list of skills to be assessed, no design for assessing it, no process for organizing the feedback, no strategy for reaching a decision, and, in all likelihood, no thought at all given to making sure good candidates actually want to join at the end of the process.

Hiring is expensive. Hiring the wrong person is even more expensive. You need to be rigorous and rigor takes effort, but there’s good news. First, it will pay off. If you can figure out how to eliminate unqualified candidates within 1 or 2 rounds, then you save a few hours per interview. Even in a buyer’s market, you’re doing well if you only meet with 5-10 candidates per role. A good plan can save a week’s work per candidate.

And second, you can get a lot of impact from just a little rigor. Here are a few simple steps:

Make a list of the skills and qualities you need to assess. You probably already did this when you wrote your role spec.

Order the list of skills by importance. There’s no reason to waste any time assessing nice-to-haves if even one must-have is missing. (BTW, the ability to write code had better be number one on this list for any programming role.)

Decide how you are going to assess each skill and roughly how long it takes to do the assessment. This is the hardest part, because you need an actual strategy, not just “Tahmina is really good at OLAP, we’ll have her ask the candidate some questions.

For each area of assessment, create a central list of questions and require interviewers to work from them.

Create a simple standardized template for collecting feedback.

Keep anything the candidate writes during the interview.

Create and distribute a schedule before the candidate arrives. Make sure that every interviewer knows what he or she is supposed to assess. Make sure the decision points are clear. E.g. decide in advance that the second interviewer has the authority to send the candidate home if the feedback from both of the first two rounds is negative.

Make sure the senior manager in step 6 receives the feedback packet before the candidate arrives. Always review that packet thoroughly before you pass it on and, if possible, meet with the senior manager beforehand to summarize the candidate’s strengths, weaknesses, and concerns.

In order to execute this plan, you’ll need to spend some time writing those question lists and assessment forms for each interview, but you can probably collate much of your first draft from existing material or what’s in people’s heads.

With the input of 1-2 other people, you should be able to implement these steps in 2 days. As long as you stay disciplined, the impact will be significant and your investment will pay off within a week or two.

Daniel Chait at Greenhouse thinks that the potential to improve talent acquisition in most IT organizations is huge. The steps I outline above amount to establishing a basic workflow for interviewing a single candidate. Greenhouse aims to organize and automate that workflow, but that’s just the tip of an iceberg. They’ve developed software that helps organizations answer questions like these:

How should we find candidates?

How should we manage and process resumes?

How should we manage our relationship with vendors?

How do we estimate the time it will take to complete our hiring?

How do we estimate and optimize direct costs in money spent and the indirect costs in employees taking time out to hire?

How do we ensure that time spent in the interview room is effective at both assessing the candidate and selling him or her on the role?

How can we leverage the data we create in the hiring process to make future improvements?

I know Daniel from my time at UBS, when he was a partner at the consulting firm Lab 49 and I was a client. When we caught up recently, I immediately saw the value in what he’s proposing.

Most IT organizations, especially on Wall Street, are haphazard in their hiring practices. At past jobs, candidates for programming jobs were presented to me for final approval who had not been asked to write a single line of code in a full day of interviews. I’ve been interviewed, myself, by people who wasted the entire time reciting their own resumes. And, in 20 years, I have never seen a hiring plan with a cost estimate or with a timeline backed up by anything better than a finger in the air.

Yet, many organizations have solved these problems and their practices are not secret or, for the most part, bespoke. But, it takes a dedicated team of talented people to build the requisite infrastructure. So, it makes sense to outsource by buying software and/or consulting services to organize the process and introduce discipline.

Every once in while, a manager gets a loose cannon, the employee who must be kept on a short leash, hawk-like watched, accompanied to meetings, cleaned up after, and cringed over. But, far more common is the overcautious employee, who checks everything with the boss and let’s management call all of the shots.

When I first started running a team, I shied from making even small financial decisions on my own. An employee would ask, “Can we order a copy of that new book on CDOs?” or “Can we take the new joiner to lunch?”

“Let me get back to you,” I would say, buying time to run it by my boss.

Partly, I was at a complete loss for how such decisions were made in the company. But also, I was far too timid. What, I should have thought, was the downside of committing to buy a $50 book? If I were wrong, my boss would tell me not to do it again. In the worst case, I’d have to tell the employee that I made a mistake or just pay for the book myself. But, I’m reasonably sharp and the company demonstrated enough faith to put me in the position. I wasn’t going to go terribly wrong.

Managers of only a handful of people may find the time and breadth to weigh in on detailed decisions, but those with large responsibilities quickly learn that the path to success lies in trusting the right people and staying out of their way. Truly mature managers realize that they have to trust people whom they know for certain will make some mistakes. The importance of trusting one’s staff is so frequently missed that we have a label for those who never learn it: micromanager.

Employees create value every time they accomplish something without input from their managers. The trouble with micromanaging bosses is that they reach in and give employees input they don’t need, “helping” to accomplish what the employee already can.

No matter where you sit in the organization, you can do your part to limit this bad behavior by never being a micromanagee, i.e. someone who asks for non-value adding contributions. Before soliciting senior input, ask yourself whether you really need it. If you think you know the right answer but want to confirm, consider skipping the validation and just acting.

The worst case is that you make a mistake. If that’s what you fear, you’ll have to wait for my post on taking risks. Check this out in the meantime.

Let me tell you a story about something I’m not proud of, followed by something I am proud of.

Five years ago, the bank I was working for shuttered an independent hedge fund and combined its assets and much of its staff into our ongoing business. Like many people, I suddenly found my previously crisp role overlapping with other people’s previously crisp roles. Boundaries and divisions of responsibility were unclear. Pressures increased as the financial crisis unfolded and, almost inevitably, conflict ensued. In one particular case, the tensions got so bad that one of my counterparts yelled at me and walked out of a meeting in anger.

I was sosure that I was in the right. 100%. I thought that he had been sneaky and that he had tried to undermine me and that, when it didn’t work out, he had been unprofessional, to boot. The interaction cost me plenty, too. I ended up having to defend myself to the CIO.

It took me a long time to admit that I had handled things poorly. I inflamed the situation when I could have been a true leader and built consensus. But, I’m happy to say that what I did realize very quickly was that I needed to get along with this guy. Our interests were sharply aligned. We supported the same business and together we needed to deliver a platform that would make that business successful.

So, I made it my mission to get along. I showed up for our regular catch-ups. I kept him informed of anything in my domain that might affect him. When he was less than responsive, I kept going. When word of the dispute inevitably hit the rumor mill, I refused to blame him (no matter how I felt). I even complimented him behind his back, when I got the chance. For four years afterwards, which was how long it took, I made it an official documented objective to build a strong partnership with his team.

Of course, I’ve come to see a lot of this in a different light. Now, I can see that he was trying to do his best for the business, that we were both under pressure, and that his actions made sense to him as surely as mine made sense to me.

As one of my managers once told me, “Assume positive intent. You might find out that you were wrong, but assume it anyway.” In that light, my more up to date and thoughtful take on the situation is that it wasn’t personal. Like me, he could have approached the situation differently. He could have been more open and collaborative. But, he expected me to be defensive and difficult. So, he built up defenses to protect his interests. Those defenses played into my concerns and I ended up confirming his negative expectations.

We take offence when we perceive that others disrespect us or are causing us trouble. But, as a general rule, what actual or perceived inconsiderateness really reflects is the fact that people are focusing on themselves, not us.

In this particular situation, I lost the opportunity to collaborate with someone bright and effective. But, often enough, the target of one’s disrespect isn’t so talented. One of the most frustrating aspects of corporate life is fixing problems caused by people who can’t or won’t do their own jobs correctly. Consider, though, that even if your colleague is only 30% effective, 30% is a contribution you can use. If you fight with the person, you may end up with 0% or even a negative contribution. Also, that ineffective person may grow more effective over time or may connect you with other people who are more effective, both benefits you lose if you allow the situation to sour.

Definitely be firm when it comes to defending your standards and pushing for the right solution. Avoiding conflict on substantive issues can really hurt you and those who depend on you.

But, when it comes to personal conflict in the workplace, grace and self-interest are perfectly aligned. The constructive path is to get what you can from relationships, work to improve where possible, and let the rest go. There is no percentage in holding grudges.

According to Jared Diamond, in his New York Times essay earlier this week, forest dwelling New Guineans refuse to sleep under dead trees.

Initial reaction? It sounds overly cautious, superstitious even. How likely can it be that a particular tree will fall on a particular night? But, long odds accrete into short odds when you play them repeatedly. Diamond’s New Guinean friends sleep in the forest every night. He does the math and concludes that if the odds of a dead tree falling on a specific night are 1 in a 1000, then the average forest dweller sleeping under dead trees would be crushed within about three years. The point, Diamond says, is that it’s important to be “attentive to hazards that carry a low risk each time but are encountered frequently.”

I see a broader principle here. Many actions confer little expected benefit when performed a single time, but being in the habit of performing them regularly confers great benefit. Skip one tooth brushing and your woes will begin and end with bad breath. But, allow your habit of brushing regularly to slide for long enough and you could be punished with severe dental and medical travails.

At work, we can usually get away with cutting a corner or two. But, habitually following best practices and proper procedures, taking notes, keeping good records, proofreading, double checking, and following up result in much higher quality work over the long run.

Of course, people with weak discipline rarely understand why so many things go wrong for them. They feel burned by “bad luck” saying, “Give me a break; it was a typo. It could have happened to anyone!” That’s partly true. It probably was a typo, a mistake that anyone could have made. But, careful people catch typos in important work, because they make a habit of checking every time.

If you think about it, what could be more “unlucky” than a tree falling on you in the night? Through good habits, the New Guinean forest dwellers manage to change their “luck”.

Second-guessing your own work can be valuable, even when it’s not your fault

A new colleague promised to meet you for coffee at noon. It’s now 12:15, you’re sitting alone at Starbucks, and you haven’t heard from her. Which is your first instinct?

a) Send her a note asking how long she’s going to be

b) Check your email to make sure you’ve got the right time and place

You may later find out that she’s disorganized or even just plain blew you off. But, you still want to be the kind of person who answers b, because being darn sure you’re right before you point to someone else makes you organized, efficient, and a good team player.

In software development, we have a special case of this principle. Software projects build on the work of other developers: stockpiles of legacy code, open source, standard libraries, vendor packages, work currently being done in parallel, etc. When a programmer makes a mistake (e.g. passes along bad data), it’s likely to make some of this other code in the project misbehave or even fail. So, when something goes wrong, the rule is always to look for the bug in our own code first.

I once had the misfortune to work with a software developer who held near perfect faith in his own genius. When he ran into difficulties, he would look anywhere for a smoking gun instead of in the code that he had just written. I would walk by his desk and find him debugging Microsoft’s libraries or ages old company code in order to find “the problem”.

Of course he was arrogant to assume that somebody else made the mistake. He was also terribly inefficient, wasting his time and that of others on wild goose chases. First, all of that other code in the project (the code he didn’t write) gets used by lots of other people all the time. So, it is highly likely that other developers have already found the really glaring bugs. And second, it’s very hard to debug code that you don’t know very well. So, it’s much easier to rule out your own work, first.

But, the worst consequence of jumping to the conclusion that “someone else messed up” is that it belies sloppiness. Careful people take pride in their work. Any hint of a flaw scares them into doubling back to verify. Someone who hurries to blame others isn’t too fussed about the quality of his or her own output.

Looking for the bug in your own code isn’t just a good rule for programmers. When anything goes wrong, startby figuring out whether youdid everything right. If someone didn’t follow your instructions, were your instructions clear enough? Did you effectively communicate the importance of following instructions? Did you give the assignment to the right person?

If it turns out that it wasn’t your fault, you’ll still likely learn something about how to shield yourself from other people’s foibles. E.g. next time, maybe you should reconfirm the same morning that coffee with your possibly flaky colleague is still on for noon.

By the way: The right way to go after an actual bug in someone else’s code isn’t to open up the hood and look for the error directly, but to construct a simple example of your own that pinpoints the issue and proves the bug is there, eliminating all risk of confusion and false accusation.

Share this:

Like this:

I started this blog with an admonishment, “Acknowledge important email right away”. Today I ran across Sarah Green’s sharp rant in the HBR blog about struggling with the email avalanche. Nobody reasonable, she writes, can respond thoughtfully to everything. So, we tend to fall into a trap of reacting instead of responding, a critical distinction. Reaction acknowledges receipt. Response requires actual content.

Because I sympathize with her dilemma and because I don’t sleep with my smartphone, Sarah’s solution resonates, even though it’s unsatisfying: accept that her replies will be slow and senders frustrated, but respond quickly only when she can or must and flag the remainder for follow up, knowing full well that many will go unanswered.

Email toes a subtle line between real-time and asynchronous communication. Usually, we choose email over phone calls because we don’t require immediate responses. But, sometimes we choose it because we need to involve multiple people and keep a log of the communication.

By all means, do acknowledge important email right away, but make sure it’s important. Don’t let the balance overwhelm you.

Have you ever heard that old saying about job interviews that, the handshake is everything? Well, experimental psychologists have demonstrated that it’s even truer than you might have believed. They asked a group of untrained strangers to rate 98 candidates based on videotaped interviews and those untrained reviewers came to substantially the same conclusions as experts trained to conduct thorough interviews and come to bias-free decisions.

Not that surprising? What if I tell you that the untrained strangers were shown only the first 15 seconds of each interview without sound? That’s right. People who take the time to ask thoughtful questions and carefully weigh evidence do about as well as people who watch silent handshakes.

As a candidate, this is pretty troubling. I want interviewers to judge me based on my skills and experience, not my handshake. As an interviewer, it’s perhaps even scarier. I might be letting great candidates get away, or hiring bozos upon whose work I might depend for years, because of arbitrary intuitions generated by first impressions. While intuition is great when it works, it has absolutely no defense against the entry of bias. That’s why we introduce formal rational checks to important decisions in the first place.

But, be concerned even if you don’t regularly conduct job interviews. You probably make decisions all the time based on your perceptions of the competence and reliability of partners and colleagues. Here is solid evidence that at least sometimes what we believe to be reasoned judgments actually reflect intuition and are susceptible to bias. Those trained interviewers in the experiment believed that they were following an objective rational process. But, in all likelihood, opinions formed in the first 15 seconds influenced everything that followed.

The only way you can reduce hidden prejudice is to recognize that it’s probably present, rout it out, and quash it. Assume that some of the “rational” decisions you make have been colored by subconscious intuitions and invalidating biases. Double check. Bounce things off trusted colleagues. Listen even to silly feedback. And, analyze again.

Bias, by the way, can be the traditionally insidious isms (racism, sexism, etc.), but it can also be plain old judgment clouding nonsense of no particular moral vice: a bad experience with a particular vendor, something in the tone of someone’s voice that reminds you of a sleazy ex, who knows? Whatever it is, don’t let it mislead you.

P.S. You can read more about the study here. Or, check out this more accessible summary.