George Bernard Shaw was wrong when he said �Those who can, do. Those who cannot, teach�. With a well structured program, �Those who can, not only do, but can also teach�
One of the challenges the IT departments in many Insurance Companies have is ensuring their software expertise is not concentrated in just two or three �experts�. One way to do this is through a Mentorship Program.
The term �Mentor� originates from the Greek Odyssey. Mentor (who was the Goddess Athena in mortal form) was entrusted with the care and upbringing of Odyesseus the son of Telemachus when Telemachus left to fight the Trojan Wars. Thus the word Mentor came to mean someone who is a combination of teacher, trainer, positive role model, protector, an opener of doors and a developer of talent (but, to be clear, within the IT world a Mentor should not be thought of as a God or Goddess in mortal form!!!).
A Mentorship program is a formal agreement between two people (the Mentor and the Mentee) through which the Mentor will pass knowledge and skills onto the Mentee.
The role of a Mentor is not a fixed role in the sense that they follow a curriculum, rather it is a role that uses, in a flexible and open fashion, the skills and experience of the Mentor to match the Mentee�s need for skills and experience development.
The relationship between the Mentor and Mentee, however often works best if it is fixed and in some areas formal. It is a documented partnership between an expert (the Mentor) and someone who wishes to become an expert (the Mentee). The document becomes an agreement between the Mentor and the Mentee and provides rules of behavior that will allow the transfer of knowledge.
The Stages of a Mentorship Program
There are three stages in a Mentorship. It is very important to set expectations at the beginning of the mentorship so that both parties work towards the same goals.
The Mentor and the Mentee have to discover what each person wants from or is willing to give to the relationship, what expectations each person has for the other and what commitments each is willing to give and take. It is from these discussions that the Mentorship agreement is crafted and signed.
This is the actual process of Mentorship. Both parties have to uphold the responsibilities they laid out and agreed to in the Mentorship agreement.
The Mentorship agreement will have a predefined end date (e.g. a 6 month) or it can end (hopefully mutually) when either party�s professional or personal interests or positions change.
What do you actually do
Generally speaking, a mentorship program does not specifically detail what needs to be taught or learned in the same way that a training program would. This is because what needs to be taught or learned varies from one Mentor / Mentee relationship to another. It is because of this lack of specificity that the creation of a Mentorship Agreement is so important.
The first step in a successful Mentorship program, called the Negotiation stage, much like the first step in a project, is used to document what is the desired outcome of the program, what resources are available to the program, what techniques will be used during the program and what the schedule is for the program.
The Mentorship Agreement outlines the desired outcome of the program, the things the Mentor and Mentee hope to achieve, such as:
�A full and complete understanding of the architecture and code structure of the Billing application�.
The next step is to document what resources are available to the program. Given that a Mentorship program is usually between two people, resources in this case usually means what time is available from the Mentor to the Mentee. Being a Mentor can be hugely disruptive if the program is not structured correctly, so it is very important to set the �rules� around time usage before the program starts.
It is entirely the Mentee�s responsibility to use the time to ensure that the learning goal is achieved. If a Mentee is expecting the Mentor to set a curriculum or to lead them in the task of learning, the program will not work. The Mentee must �pull� the information out of the Mentor; they should not expect the Mentor to �push� the information onto the Mentee.
The process between the Mentor and the Mentee will include both structured and unstructured meetings. The structured meetings are to be used to review very specific issues. They would be used, for example, for a demonstration of the system, a code or design review, or a white board session on how one area of a system works. It is the Mentee�s responsibility to arrange, structure and drive these meetings. They must set the meetings at least 48 hours in advance and provide the Mentor with information on the purpose of the meeting and, if required, a copy of the documentation that is to be discussed and / or reviewed. (e.g. code or a design document etc.)
The unstructured meetings, on the other hand, are to be used for rapid answers or advice on specific questions or areas of the application. For these meetings, the Mentee can approach the Mentor, without an appointment, for a short period of time (i.e. 5 or 10 minutes) to get advice on an issue or area that the Mentee is working on. It is envisioned that these are the sort of questions / problems that the Mentee could, in all likelihood, discover the answer themselves but they would have to take a few hours of research to do so. It is far more efficient if the Mentor can quickly and efficiently point the Mentee in the right direction.
The mentorship agreement documents the approximate number of structured meetings that the Mentor and Mentee will hold and the approximate amount of time that can be used in unstructured meetings. As mentioned above, it is important that both parties respect this time commitment; the Mentee cannot arrive at the Mentor�s desk every 10 minutes with yet another question.
One further point, there is an issue of confidentiality that needs to be considered, although it is important that the Mentor be able to report progress to the Mentee�s manager, the Mentor also has to be sensitive to the fact that for the relationship to work, the Mentee has to be able to trust that he or she can be open with the Mentor without fear of every mistake, repeated question etc. being reported back to the manager. A process of being able to speak �off the record� can sometimes be of assistance in this area.
We are voluntarily entering into a mentoring relationship; we want this to be a rich and rewarding experience with most of our time together spent in learning activities. To this end, we mutually agree upon the terms and conditions of our relationship as outlined in this agreement.
The following are the objectives we have jointly agreed to:
|We hope to achieve:||To accomplish this we will do:|
|A full understanding of the business use of the system||A series of demonstrations of the business uses of the system, each showing different functions within the system and each building on the knowledge gained in the previous demonstration.|
|A full understanding of the business use of the system||A series of demonstrations of the business uses of the system, each showing different functions within the system and each building on the knowledge gained in the previous demonstration.
This will take approximately 3 Meetings
|An understanding of the architecture of the system||A �white board� review of the underlying architecture and a discussion on why that architecture was selected / used.
This will take approximately 2 meetings
|An understanding of the code structure||A �white board� session outlining the basic code structure used within the application.
A series of simulated �code review� walkthroughs where the Mentor will select the key modules within the system and present them to the Mentee as if in a code review session
This will take approximately 5 meetings
|A review of the areas of the application that tend to create challenges||A general discussion about the system focusing on areas within the application that tends to create the most challenges for staff who are new to the application.
This will take approximately 4 meetings
|Items not covered||There will be no formal attempt to increase the Mentees understanding of the underlying technology|
It is understood by both parties that the Mentor may provide feedback on the progress of the Mentee to the Department Manager. However it is also understood that any sensitive issues that we discuss �off the record� will be held in confidence.
We will attempt to meet formally at least twice per month. Such meetings will be set and structured by the Mentee. If we cannot attend a scheduled meeting, we agree to be responsible and notify our partner and reschedule.
We will also agree to meet informally on an as needed basis. Such informal meetings will not consume more than approximately five hours per month.
We have determined that our mentoring relationship will continue as long as we both feel comfortable or until December 31.
Although it may look overly formal, the agreement lays out what the Mentee hopes to achieve, the amount of time commitment each is willing to give to the program and the methods that will be used in transferring the knowledge. It is suggested that the importance of the Mentoring Agreement not be understated, as it sets expectation, rules and creates an environment where a Mentoring program can be a win-win arrangement.
And George Bernard Shaw thought only those who cannot do should teach�
OARBIC Inc. is a specialized IT consulting firm helping the property and casualty insurance industry make older systems behave like new ones – and new ones behave the way they should.
We offer an array of consulting services, plus our OSEA software solution is specifically designed to extend the life of legacy applications to allow them to keep pace with change.
Our in-depth knowledge of the property and casualty insurance industry and our access to a global network of talented, specialized IT professionals, sets us apart from other consulting companies. More information at www.oarbic.com