The time has come to hire a new major incident manager. How do you go about that? How do you choose the right candidate? Major incident managers must have several typically conflicting traits, so how do you pick the right person? Let's dive into that.
Before you listen to my words, who am I? I have been in IT operations for over 27 years, specializing in fixing what's broken. My clients typically call me in for a specific part of IT Operations, e.g., disaster recovery, or service management, or IT operations management. Sooner rather than later also, I see that incident management has some issues. Within a few months of working together, my clients automatically call me in with any potential priority 1 or major incident. And then, we follow that up with problem and change management. I've been involved in and ran Incident management for major systemic banks in Europe, investment banks in the US, and Japan, including during major upheavals like 9/11. That is me.
Did the person leave the position prematurely? Was the person asked to leave by other members of the team? Did you ever "make do" with the hire because that is simply "your culture?" Or perhaps you kept the person because letting them go was not conducive to productivity.
We've all done that. We kept working with the person, essentially against better judgment, until something broke or an incident got handled so badly that the business started asking awkward questions.
Or, incidents get handled okay-ish, as in, they are picked up within SLA, people get together to solve it, the incident manager documents the proceedings, and the necessary steps are followed to put actions into a problem context, etc... Nice, and you may even meet your KPI's. Still, there is no pride here, excitement, or ownership feeling. Even though it seems like IM is under control, some ingredient is missing.
Why is that? We had a good feeling during the interview. The candidate had good answers, showed enthusiasm, and even had relevant experience in this area with several companies. Unfortunately, that is not any indicator of if the person will perform in our major incident manager role. Why not?
On Septern 27th, the HBR published a very interesting article that confirmed my long-held belief that an exchange of equals is a much better start to the hiring process than an interview. Of course, I have to define what I mean by "exchange between equals."
The current, accepted method of doing interviews has its roots in world war I. It was used to psychologically screen soldiers for duty. Even when you ask relevant questions, we all know that the interview is a poor predictor of future performance in our organization. The traditional interview only demonstrates someone's ability to answer questions in a way that it sounds plausible within the framing of the proposed position.
The person can demonstrate the theory and perform other "monkey" tricks. But that typically does not have any bearing on the real job circumstances or how the person needs to react and perform when confronted with real-world situations.
Most HR departments and hiring managers understand that the standard interview process is less than optimal, yet they have few ideas to solve this puzzle. If not the interview, then what? Personality tests? Do you fully understand the results? Bot screening? AI is not yet advanced enough. It will select the resume jockeys and leave out the real gems. (I would not even pass the initial screening, just look at my LinkedIn)
When I look to hire a major incident manager, I want to establish that I talk with a person who has actually done the job through a series of experiences. While past experience by itself is no predictor, it is a starting point; Note that I did not say past "performance." During a talk (not an interview), a person will always initially present themselves in the best possible light.
To poke through that, I interrupt the narrative. Yes, I know that is rude, but it is the nature of the job. As a major incident manager, you'll get interrupted many times on several levels. I then observe the reaction of the person. I look for excitement! A true major incident manager will immediately show indicators of heightened alertness, like a leopard spotting prey. You can sense it. It puts you, as the hiring manager, on the alert: "Don't mess up now, or you'll lose the candidate." It is at this point that the real talk starts. I take the candidate into situations and see how the person reacts, asks questions, and interprets and analyses the situations.
HBR nicely defines "minimally viable" as tests that are as clear and short as possible while allowing the candidate to demonstrate their prowess for the proposed role. Let m explain what I mean: if I'm hiring a major incident manager, I'm looking for certain aspects in terms of personality, action-driven reflexes, business-environment-awareness-ness (that's not a word, but you get it), people-awareness, and leadership. I'm not looking for a mathematician who may very well know the path to shortest resolution architectures. (I may still want to hire that person, but not in this role.)
I hope my meaning is clear. Again HBR makes it plain: using this technique will "reveal" the person, akin to the "reveal" in poker. After all the bluffing, you have to show your cards. The "real" major incident manager will reveal itself. But only to a peer major incident manager.
And that is the pitfall many companies fall into. The old saying, "it takes one to know one," holds true. If you're not a real major incident manager, you cannot hire one. Sorry to state it so bluntly, but that is my honest opinion. You must have experienced actual incidents where you went through the motions, solved them, and did the follow-up before you can hire for the position.
Within IT operations, "minimally viable demonstrations of competence" are much harder to get to than with positions that "produce artifacts."
Tangent: Development position selections may, e.g., require that the candidate produces a piece of code. You could then further check how the person would go about getting into the actual build. (hint: the candidate would go beyond the technical steps and include personal interactions with the team to validate the code and suitability and congruence with other code.) Prima-donna's or people with limited social skills are an issue.
The reality of the major incident manager job is that, when you start in the company, you do not know enough to be "the" expert. The key is to have sufficient background to know how architecturally things "ought to work" and then adjust that mental picture to the company, to know how to obtain sufficient company-specific knowledge and how to get to know the people in the company. A candidate who has learned the lessons of the "Servant Leader" is invaluable.
Some years back, I had to hire an additional major incident manager. That posed exactly these problems for me. You cannot become a "major" anything in IT operations unless you understand the business, the IT environment, and the logical and physical architecture of the company. And yet...
I met late in the day this person in the main lobby of a financial institution in Belgium. My favorite receptionist pointed her out to me. (This is an important detail! if you do not understand, ping me by email) We sat down on one of the open benches, and I started to talk with her. We exchanged a few experiences, and in even those first few minutes, we seemed to finish each other's sentences. That is when I quickly moved on to scenario-based questions (MVP). She did not miss a beat. In my recollection, the talk lasted about 30 minutes, and I offered her the job on the spot. She is still there after ten years of service. And while I'm in a completely different function now at a related company, I will ask for her by name when needed.
Interviewing in the traditional way is not a predictor of future performance. Allowing the person to demonstrate their capabilities is. For major incident managers, this means: