Export (0) Print
Expand All
Separating DSL Semantics from Implementation
Expand Minimize
Bb508954.skyscrapr_banner(en-us,MSDN.10).gif

Mentoring: A Natural Element of Architectural Leadership

 

Sandra Y. Jeffcoat and Miriam Grace

May 2007

Summary: As an experienced architect, I would encourage you to make the choice to perfect our profession by mentoring a hopeful new architect. It's worth the journey. With mentoring, everybody wins. (5 printed pages)

Contents

Introduction
Introduction Phase
Planning Phase
Execution Phase
Separation Phase

Introduction

"I know I have very limited technical experience, but I decided that I want to be a systems architect. Can you help me?"

I was faced with this question from an individual who worked in my area and I had known for several years. At first, I was not sure now serious she was. I knew she had a successful career in technical writing, and we had worked well together on a project a year earlier. Her question took me by surprise, and it surfaced old memories.

I took a deep breath and let it out slowly, remembering when I had limited technical knowledge and needed guidance. I remember asking people at work for help. No one answered my call. I asked myself, "What now?" I began to feel my way. I searched for classes both in-house and at the local colleges. I took as many courses as I could, but I did not know if they were the right ones. Some turned out to be a waste of time, because I was taking them in the wrong order or they were not relevant. I eventually learned that this approach was not going to work; I needed some serious help. I decided to approach a few individuals privately. Some helped a little, and some put me off. I stumbled my way through and, after two degrees, uncounted courses, and years of experience in information technology, I finally became a successful systems architect.

Remembering my personal story, I could not say no to the individual now facing me and asking for the same help that I once needed. I told her I would think about it and get back to her. Before I said yes, I wanted to review my mentoring research and develop a presentation for my potential protégé. The presentation was to serve as an introduction to mentoring and to help my protégé understand what was expected of her in this relationship. In addition to the roles and responsibilities of both the mentor and protégé, the presentation would provide definition and information about the four phases of mentoring:

  1. Introduction
  2. Planning
  3. Execution
  4. Separation

Introduction Phase

I thought through the commitment I was making, explored my feelings, and was honest with myself about what it would take to truly make a contribution. When I came to a decision to proceed, I called my protégé, Betty, and told her that I was considering mentoring her. I further explained that I needed to discuss what mentoring her would mean to me, and that she and I would need to develop an agreement. I explained that a written agreement between us would be a great tool that we could use to remind us of our goals and why our relationship was formed. It would also help remind us of our obligation to one another and the importance of that obligation. She was so grateful and hopeful for the future. "How can I ever thank you?" she asked. "There's a lot of hard work between you and your goal, Betty," I said. "My thanks will come from your commitment to learn."

Mentoring is about a relationship between the mentor and protégé. I knew Betty, but not well. Without a relationship, how could I mentor her? How could I help her with what she needed to know? Could she take constructive criticism? How would I deliver it? Would I need to praise or encourage her constantly, to keep her engaged? These were just a few of the questions that I needed to answer to mentor Betty; and I was sure she had just as many questions for me. For instance, she would want to know how to ask me for help. She might wonder if I would get angry if she had trouble understanding what I was teaching her. She might have a fear that I would stop mentoring her if she did not perform to my expectations. She would wonder how I would react if she disagreed with me.

To get answers to our questions, I began the process of getting to know Betty. We scheduled a few lunches where we could talk freely. We began the get-to-know process by telling each other about ourselves, our education, our families, our work experiences, our likes, and our dislikes.

Planning Phase

After Betty and I broke the ice and got to know each other a little, we began putting together our mentoring plan. This plan included our goals and objectives, how we planned to accomplish those goals, a timeline for our accomplishments, and various ways we planned to measure our progress. If you recall, when Betty came to me for help, she mentioned she had very little technical experience. During our introduction phase, I learned just how limited her experience was. She had taken a few Web development courses and worked as a technical writer, so she had some knowledge of the technical language. But she had no practical IT experience. My mentoring her would have to begin at square one.

We started with defining her goals and objectives, which Betty referred to as simple. She told me her goal was to be worthy of consideration as an entry-level systems architect. This was a reasonable and achievable goal; it was a good start. I reminded her that mentoring does not mean that I tell her what to do or how to achieve her goal. I stated firmly, "This is a relationship. We make decisions together and I serve as your guide, but only you will determine your fate." She acknowledged my caution and accepted the responsibility.

Betty and I then moved to defining objectives that could be measured and that would lead to her goal. Her objectives became to:

  • Receive formal training that will increase my knowledge about software engineering.
  • Receive formal training that will help enhance my leadership skills.
  • Gain an understanding of all the roles and responsibilities of each member of a software life-cycle development team.
  • Gain an understanding of business-process management (BPM).
  • Gain an understanding of processes, procedures, and tools that would be helpful to an architect.

Now that Betty had her goals and objectives, it was time to complete the plan by defining how these could be met. We started with laying out her formal education plan. Fortunately, we found in-house courses she could take, and many were going be available over the next six to eight months. We found courses on topics such as software analysis and design, database design and construction, data modeling, software-design methodologies, software testing, and many others that addressed the software-engineering and software-development life cycles. We even found a course that covered roles and responsibilities of members of a software-development team.

Scheduling Betty into these courses was easy, but finding courses that would address some of the soft skills required for leadership was not so easy. We were unable to find anything in-house, so we began exploring other sources such as leadership organizations and conferences, as well as local colleges and universities. We managed to find a few in which to enroll her, such as "Conflict Resolution," "Leading Up and Down the Chain of Command," "How to Motivate your Team," and a few others. Finding very little learning opportunities in this area of "soft skills" led us to adding to Betty's plan some time for research and reading in leadership and team building.

We were almost done with the plan, when Betty asked, "This education stuff is great, but what does it have to do with being an architect, and when will I learn to be an architect?"

I smiled and answered, "In the software-engineering process, the architect is responsible for the technical solution. If you do not fully understand the process and what is required to build a solution, how can you become an architect?"

She nodded her head and asked, "Okay, I now understand the need for the formal education, but how will I know how to use what I learn?" I told her that her question brought us to the second portion of our mentoring plan. I continued by telling her that we needed to add some time into the plan for her shadowing me and/or other architects. I recommended that she shadow more than one architect, because that would serve two proposes: She would be exposed to different situations and a different architect's approaches and ways of working; and it would help her develop her own style of architecting by taking the best from each of the architects she shadowed. We needed to choose individuals who were experienced and not only willing to allow her to shadow them, but who were willing to discuss their role and responsibilities. This led us to put two additional tasks in the plan: identification and contact of senior architects for shadowing, and job shadowing.

The next component of the plan was to identify how Betty and I would measure her progress. She and I decided that during the formal training phase, she and I would schedule a two-hour discussion after each course. The purpose of this discussion was to answer any questions Betty might have and for me to determine if she fully understood what she had learned. I would also use that time to show her why an architect needed that knowledge. Betty chose me as one of the architects she wanted to shadow, and we decided I would be the last of the architects she shadowed. Being last gave me the opportunity to determine what Betty got out of her shadowing experiences. We added three hours a week to the plan, during which she and I would discuss and assess her job-shadowing experiences.

The last component of Betty's mentoring plan was to help her get some architecting experience. Betty's year of formal training and shadowing was to be completed about the same time I was scheduled to complete my current assignment and begin my new assignment as the senior architect for a major program development. The management for my new assignment and I were identifying individuals for my new team. So, I asked Betty if she wanted to consider working as one of my junior architects for this effort. She became very excited. I told her that it was contingent on her completing her plan on schedule and satisfactorily. She agreed, and we shook hands on it.

Execution Phase

Betty and I completed her plan and agreed on a start date. As soon as she began, we both followed the plan, unless one of us found a flaw in it. If one of us found something not working or missing, she called a meeting with the other. In that meeting, we discussed the issue or problem, agreed on adjustments, and continued with the revised plan. The purpose of the plan was to help Betty become an architect. If any part of the plan was not working or was missing and we did not make adjustments, we would have been jeopardizing Betty's goal. To ensure the plan was working, we had regular process checks.

Separation Phase

Betty completed her formal education, and she shadowed four architects over a year. Her progress has been outstanding. Now, it is time to let her go solo. She has become my junior architect, working closely with me as an "apprentice." We are into a new phase of our relationship, one in which I must allow her to make architectural decisions, develop plans, perform assessments, and manage technical issues resolutions. I will be there to offer guidance, if needed, but I have to remember not to step in. This will be hard, because I have ultimate responsibility for the program. Just as anyone else in my position, I will be worried about mistakes she will make, but I have to remember what my mentor once told me: "Mistakes are okay, as long as you learn from them and do not continue to make the same ones."

Mentoring is a key component of architectural leadership; without it, the road to becoming an architect can be a long and difficult one. Many architects might say, "I know we need more architects, but I do not have time, and it is not my job. Besides, what's in it for me?"

Let me share what I got out of mentoring others. I have been mentoring others for more than six years now, and each mentoring experience seems to be more gratifying than the previous. In two instances, it was like being a proud mother or father. This past year, I mentored two individuals: One I had been mentoring for more than two years, and the other for about a year. One became a junior architect within eight months, and the other after about a year and half. Both recently received promotions to systems architect. When their promotions were announced and they were asked by upper management for an acceptance speech, they both acknowledged me as being a part of their success. Boy, was I proud! Also, mentoring for me was not just about my protégé's learning; my knowledge has increased, too. Often, if I did not have the answer to a problem, my research with the help of the protégé helped us both learn, and sometimes my protégés had more knowledge on a particular technical subject than I did. In that case, I became the protégé.

As you can see, there are benefits to mentoring. As an experienced architect, I would encourage you to make the choice to perfect our profession by mentoring a hopeful new architect. It's worth the journey.

 

About the authors

Sandra Y. Jeffcoat is a member of Boeing's Technical Excellence Program, a 2005 National Women of Color in Technology and 2007 National Society of Black Engineers (NSBE) Golden Torch awards winner, and a Ph.D. candidate for the Antioch University Leadership and Change Program. Sandra has more than 28 years of technical experience with such companies as the Boeing Company, Eastman Kodak, NCR, Mead Paper Corporation, AT&T, and various government agencies.

Miriam Grace is an Enterprise Systems Architect and a member of the Boeing Technical Excellence Fellowship. She has over 20 years' experience as a computing systems architect, with a specialty in business-process management systems. Miriam is a published author, holds a Master's degree in Systems Design, and is a Ph.D. Candidate in Leadership. She designed a learning system that has provided a curriculum of foundational skills for software architects at Boeing.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.

Show:
© 2014 Microsoft