Flylib.com

Books Software

 
 
 

You as a Mentor


You as a Mentor

Just as you ve had mentors who have significantly helped you, you have an obligation to be a mentor to others.

I like to believe that I was a mentor, at least briefly , to Garry Reinhard. I helped Garry get into IBM because I needed him to help me create the IBM Apparel Business System software product, then I watched him accelerate through many opportunities ”so much so that he has become a mentor of sorts to me.

Be prepared to give a significant amount of your time and energy to mentor others, as others have given time and energy to mentor you. However, you will have to guard against those who will utilize your time and talents without applying themselves enough to deserve your mentoring. To achieve a successful and lasting relationship, the mentor and the mentee must both give of themselves. And the mentee must be worthy of his or her mentor s time and trust.

start sidebar
$$ The Bottom Line $$

A talented and hardworking programmer who connects with an influential mentor has the greatest chance for success. Indeed, keen as I am on the virtues of talent and hard work (and some people think I m so high on them that I m over the top), if I had to choose between being talented and hardworking, but not having a mentor, or being average in skill and zeal but having a powerful mentor, I would choose the latter.

You have many opportunities to find valuable and powerful mentors who will project your career upward as you, in turn , help them with their careers. Placing yourself in high-visibility and high-potential situations, specifically projects that are very important to upper management, will put you in the spotlight for probable selection by a well-connected mentor as he or she moves up inside or outside your company.

end sidebar

 



Chapter Twenty Three: How Do You Deal with the End User ?

Having rapport with users, building their trust, means that the end users don t feel as if IT is shoving something down their throats, Dan Goldstein says. That matters, because if the users don t buy into something you re introducing, it is not going to work. They can make or break any system.

Dealing with an end user can be tricky. Even as an experienced programmer you will have end user encounters that will require all of your expertise and finesse to facilitate. To help you visualize some of the situations you might encounter, this chapter presents some tips from two IT veterans ”Jean Kopan and Dan Goldstein, both of whom have gained perspective on the problem not only as programmers but also as high-level IT managers.

Yes Is Not Always the Correct Answer

Jean Kopan, vice-president of technical development at a software development and consulting company in suburban Philadelphia, has the following advice:

When a user comes to you with a request, you should not just transcribe that request into programming. The request may be counterproductive.

For instance, let s say someone in the order entry department says, ˜I don t really see why I have to key in this order classification code. I don t want to key it in anymore. Take it off the screen.

But everyone in the sales department is using that classification code to decide how well certain classes of orders are selling. So if you take out that code, there ll be a ripple effect. You cannot always just do what the user wants. To respond intelligently to his request, you need to understand the business of the company, what the other users are doing, and how this request may affect other parts of the company.

You may notice that Jean has just affirmed my oft-stated axiom that you cannot be a good programmer without having a thorough knowledge of the flow of your company or client s business. In the situation she described, you wouldn t be savvy enough to say no unless you understood the business.