Here’s a simple example: think of two very different managers that you’ve had in your life, ideally two who were both effective, but had very different management styles. One might have been a fairly authoritarian, micro-managing type. The other one might have been a hands-off, “let’s steer the boat with a few light touches in the exact right spots” type (which is the direction I tend to lean towards). Those two managers, even though both “good”, would have a vastly different idea of what a “good manager” is, looks like, and how he or she behaves. They might eventually arrive at an agreement about a single hire, but there is no way you could come up with a list of bullet points to describe how they would both recognise a good manager, because their ideas of what makes a good manager are very different.

So how do you solve this? I don’t really like any of the solutions presented in the article on Business-Of-Software. They all smack of damage limitation rather than damage avoidance. “Accept the problem”? “Hire from within”? The last two seem more helpful but don’t really present much of a practical, repeatable approach.

In order to do this, I think first it’s important to establish who’s going to be hiring that manager. If you’re doing that hiring, I’m going to guess that you’re yourself a manager, and that you’re not hiring your boss - you’re hiring someone who’s going to be working for you - or perhaps you’re hiring a colleague on the same hierarchical level, someone who’ll be working alongside you. If you’re the manager hiring another manager, you might be a good manager yourself, or you might not. The thing is, there’s not really any way for you to tell whether you’re a good manager. Going back to the earlier point, “good manager” according to whom? And irrespective of what kind of manager you are, you want to hire a manager with whom you can work.

So the thing to realise here is that you’re not trying to hire “a good manager” according to some arbitrary definition. You’re trying to hire a manager who:

• has a management style that will fit well with yours
• will be able to deliver what you need them to deliver

Assuming that you fit these criteria, this means that essentially, you’re trying to hire someone more or less like yourself. It doesn’t really matter if they fit some set of criteria that someone else came up with. It’s a pragmatic decision that has to be based on your current circumstances, on the specific managerial role that you need to fill.

Any experienced manager should be able to elicit enough information out of someone to determine this. Unlike the juggling interview quoted in the Business Of Software article, you should never be asking closed questions like “do you know how to do PERT analysis? What about performance reviews?” Instead, ask open-ended questions which give the candidate no framework to structure their answer, e.g. “what would you do if you discovered that all the estimates for your project are fifty percent off? How would you deal with a poor performer on your team?”. Let them meander about and include stories of what they’ve done before and what they believe would be the right way in these circumstances.

One of the characteristics of management is that it’s very much a situational performance art. Motivating your team is a key management skill - yet every person requires something subtly different to be motivated, and a good manager will be able to adapt to each of these people to motivate them. This is unlike, say, a programming question, where there is typically a limited set of valid answers to a question. However, the answer that the candidate gives you will be what he believes to be the best answer - and that’s precisely what you’re looking for: what does he think is the right way to deal with situation X? Does he think like me? If he behaved like this in the real situation, would I be happy with his performance?

Based on those answers, you should fairly quickly gain a pretty good idea of whether this person’s management style works with yours. If you see that yes, his or her approaches are acceptable to you, then the only question you have left to answer is: is his experience real and sufficient? Unlike programming, there’s very little “hidden icebergs” in management experience. Nobody hides years of managing a team on their CV, because it’s clearly relevant experience (unlike “I designed a raytracing engine after school”) - and if they do when applying for a management job, you’d have to question their common sense.

I hope this helps. If you have any other suggestions for how you deal with management hires, do leave a comment below. Thank you for reading.