Pair Mentoring

  1. Posted on February 10, 2008 3:57:PM by Earl Beede to Practicing Earl
  2. Technique, humor, requirements, mentoring, Management

What does it mean to be a mentor? While I can fancy myself as pretty knowledgeable in a couple of areas (mostly the proper way to eat an Oreo© cookie and how to make my wife angry), mentoring somebody else in that knowledge is another matter.

As a Certified Software Development Professional (nice big IEEE title) one of my professional duties (nice IEEE ethical stance) is to mentor others. I think this is reasonable and, actually, I am in favor of establishing a more formal apprenticeship program for junior developers. Software engineering, like most engineering, is both an art and a science. We can teach the science in school but you have to have experience to really gain the art. And that experience should be guided experience. So, while not trying to promoting the art side too much  (there are known reasonable practices), we should all occasionally sit at the feet of a master.

Much as I may support it, software engineering doesn't have a craft guild to enforce an apprenticeship program. So what we have left is mentoring.

A lot has been written over the years on what a great thing mentoring is and that everybody should have one. Most of what I have heard is more about how you should get a mentor. Of what I have heard (which may be surprisingly little), most of that consists only of the advice to meet.

So, what do you do when you meet with them? Ah, that is where the advice starts to wear thin. It seems even thinner for the Mentor than the Mentee(?). I know there is a pair here in the relationship so, what is the Mentor side to do?

So, I have come up with a list of ten things a Mentor and a Mentee can meet about.

  1. At the first meeting, exchange names, cell phone numbers, and favorite sports (just in case the talk about software begins to lag). The Mentor should set up the first few meetings at least as the Mentee is probably still trying to figure out how to use the corporate scheduling system.
  2. Work at establishing a growth plan. For a starter on this, look to the Professional Development Ladder from Construx. Any good ladder, like Construx's provides a balance of knowledge and experience. One does not want a lopsided Mentee.
  3. At the same meeting or another, tailor the ladder for the Mentee interests and the companies needs (keep a balance). For example, if they want to get into embedded, then you can select readings and activities that focus on embedded programming in the construction cells. Or, even better, have the Mentee focus a lot on how to test the heck out of it.
  4. Establish a realistic time-line to do the reading/training and activities. Many a Mentee has burned out due to trying to go too fast. In truth, many of the books one should read can put an insomniac to sleep, instantly. Many doctors use software engineering books as a last resort treatment for sleeping disorders.
  5. Keep a look out for projects/project roles that will help them complete required activities. As a more senior person in the organization, you probably have more insight in upcoming projects. For the roles you think they are ready to take on, recommend the Mentee or have the Mentee volunteer. If you are really good, you can recommend a few activities that the Mentee will fail miserably. You can then sit back and say what deep things we can learn from failure while you laugh behind their back.
  6. Set up a schedule of meetings (monthly or quarterly) where you get together and talk about what the Mentee has done/read/attended. It is your job to make sure the Mentee gets the main concepts and points of the reading/training. No, you don't give exams, you speak from your experience in going through the same material. (Uh, you did read some of this stuff yourself, didn't you?) You also confirm that the Mentee did "good enough" job in the activities.
  7. Don't make the Mentee do anything. You just recommend. If the Mentee doesn't do it or doesn't want to, it is their career. This is not a parent/child thing.
  8. I try not to let it get into any kind of grip session. It is easy for the Mentee to get frustrated if the reading is difficult/voluminous. Keep it positive. You can recall what a pain-in-the-#@!! it was for you to read all that stuff.
  9. Give feedback to the Mentee's line manager around performance review time (if you are saddled with that) about what a great person the Mentee is. Of course, it is due mostly to your fine talents as Mentor but, hey, the Mentee deserves a raise for all the hard work. (You probably do to but that is your's Mentor's job to mention.)
  10. Don't be afraid to tell a Mentee that they are not progressing in their development. We all get comfortable at certain stages and the demands of the day job can overwhelm. It is the Mentor's job to jab at the Mentee from time to time to keep the Mentee moving. It is kind of fun, too!

If that doesn't set the stage for many a fine Mentor/Mentee meeting, I don't know will. Perhaps I should ask my Mentor...

Post a Comment:

 
 

Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).

 

Contact Earl