Among the many challenges facing the insurance industry, none might be more critical—and problematic—than finding and keeping strong technical talent. And this is not a new problem. It has slowly but surely been creeping up on the industry for decades, as technology companies, the lure of startups and the industry’s reputation for living behind the technology curve have all created disincentives for young technical talent to take a look at the industry.
So what’s the answer? In part, it’s focusing on the assessment process as a way to find talent that others might overlook by measuring skill—real and potential—over experience. And much like the popular baseball book and movie Moneyball, the key to better assessing talent and outcomes is to know the right questions to ask.
This Moneyball approach promises several benefits:
First, it could provide the industry with an influx of strong IT talent that could help to move technology capabilities forward
Second, it could—over time—improve the quality of systems and processes in the industry, leading to better customer service overall and improved profitability.
Third, it could enhance the efficiency of IT departments as they become restocked with fewer but more capable people.
Fourth, it could start to break the perception of the industry as a backwater for technology innovation.
The key to accomplishing all of this is by improving the way in which technical talent is assessed. However, asking the right questions is something that seems easy, but actually isn’t. It can only be learned through the bitter experience of asking many of the wrong questions, which leads to bad hires.
One of the keys to asking the right questions is to ask the questions that would likely arise while somebody was working in that position. To get a holistic view of the experiences and potential of each candidate, the interview questions should be organized into three categories that align with the desired position.
In the following examples, the positions used are an IT developer, a technical lead, or a junior architect. Through the above-mentioned trial and error, the question categories that have been developed over time for the interview include technical skills, previous successes/failures and soft skills.
The assessment objective behind the Technical Skills category is to determine with some reasonableness of certainty that the candidate is or will be capable of developing quality software within a large project scope. Therefore, the specific questions will not focus on knowing this language or that configuration tool, but rather on a thoroughness of understanding of best practice coding patterns, testing, and integration techniques, and designing software for scalability and maintainability.
This approach generally leads to an insightful dialog and avoids simply checking yes and no boxes for specific skills. The focus is on the long-term probability of success for any given interviewee. The analogy to the Moneyball approach is that this qualitative approach is trying to get at how an interviewee will perform over a full season, given enough at-bats, pitching starts or other applicable metrics.
This approach is continued for the two other main categories of the interview. For the Previous Success/Failures category, the whole point here is that evaluating somebody based upon their experiences to date and extrapolating their development into some future point is usually a better success indicator than evaluating somebody on the specific skills listed on their resume.
So the questions in this category focus on asking the candidate to tell a particular project story from their experience, why they thought it turned out the way it did, what they might do differently next time, and what they learned from the experience. This is a good opportunity to have the candidate use a whiteboard or some other medium that allows them to illustrate and elaborate. There are great insights in this category for a candidate’s thinking and logic process, the technical and operational complexity of their experiences, and their organizational and communication skills.
For the final category, the previous discussion on the candidate’s experiences can be used as input to evaluate their Soft Skills. Asking questions that center on why something works the way it does, or why certain decisions were made, are much more valuable than questions about how something works.
For example, answering the question of how to maintain software over time is a very different answer than why it’s important to do so. Answering the why question leads to broader thinking about the value of software to a company, its relation to operational processes in the business, etc. There are no real right or wrong answers, and it again becomes an opportunity to have a conversation about a variety of things. The focus is mainly on communications, and the goal is to ascertain a candidate’s ability to:
· Understand technical conversations
· Meaningfully contribute to technical conversations
· Summarize the technical details for others
· Participate in overall team dynamics
The premise posited here is that the insurance industry has a technical talent issue and that the suggested approach herein is one way to begin to address that issue. This approach is of course only one way, and other approaches may be equally effective.
The larger point is that the industry’s overall approach to talent assessment needs to get better, and not just by a little bit. The consequences of not doing so are problematic and would leave the industry exposed to continuous innovation and technology deficit as compared to other sectors. That’s why the industry needs to be proactive rather than reactive about talent assessment, and judging someone on their current skills even if they haven’t had the experience to prove them out entirely is one way to do that. As the statistical analyst opined to his baseball general manager boss in Moneyball: “Your goal shouldn’t be to buy players. Your goal should be to buy wins. To buy wins, you need to buy runs.” We need to score more runs.
Originally published by
Read the original article here.