[ Pobierz całość w formacie PDF ]
.Nevertheless,consider the potential dismissal s impact on the company.Seek help in evaluating the decision from your boss.What security issues will the firing create for the company? Does the programmer have expertise and knowledgethat must be extracted prior to the firing? These questions, and others bearing on the dismissal, need to be askedand answered as part of your considerations.You must also give careful thought to the effect of firing a programmer upon the rest of your staff.They may wantto know why one of their friends was given the axe.Be careful in sharing the specifics simply state that the programmer s performance wasn t satisfactory and his or her retention was not in the best interest of thedepartment.A positive effect can also result from firing: Problem people are no longer around to make trouble, andeveryone is warned that such individuals will not be tolerated in your administration.This is a good signal and oftenis one you need to send to your staff.Promotions and RaisesI touched on money and other such rewards in Chapter 1.It will prove to be your most difficult area to administerproperly.Job titles are prized by some and money by all, so what do you do? Well, in the 1960s Bell Labs had onesolution: Each scientist had the title Member of the Technical Staff, and there was no higher honor than beingamong this group.This can work when you have a highly competitive workforce, but it s often impractical todayeither due to corporate titles established beyond your control or the desire of individuals to have an impressive title.The younger the employee, the more he or she will seek the status of title.The older ones want interesting workand serious money.If an employee wants all three of these things, maybe he or she is worth it or just a bitunrealistic.No, interesting work will be a common denominator among programmers, so you ll have to sort outtitles and money matters as a function of merit and experience.Use care in promoting people before they are ready for more responsibility.Many programmers, and technicalfolks in general, can be happy most of their work life just doing interesting and creative work without ever gettinginvolved in management.Learn to know when a worker has reached his or her maximum level of responsibility.That programmer may be able to handle more in the future, but most of us need to settle in for a while at a certainlevel of responsibility that feels comfortable.Once you see growth and comfort, it could be time to ratchet up theresponsibility again.Promoting staff is often an iterative process, much like defining business requirements andprototyping: Once you prove the new level of responsibility is working, maybe an employee can handle somemore.Some people think more responsibility means more money and, to a certain extent, this is true.Be aware, however,that more money should really be offered for more productivity and effectiveness on the job, and not just for awider scope of project activity and responsibilities for others.If you re lucky enough to be part of a corporation that has created a technical track so programmers can reachupper management salaries, great! This eliminates the glass ceiling that often results in a technical personaccepting a management position just to gain extra income.It also brings up another point: Can you manageindividuals who are making more money than you are? This can happen in some organizations and isn tuncommon for those staff members who have saved the day for the company during their tenure.Is such a heroin your company worth more financially than you are? He or she could be, and you must learn to value thestrategic employee and be glad you have that person on board.In a book extolling the value of craftsmanship,Pete McBreen addresses the issue of what a great developer is really worth:Probably a lot more than they are currently being paid as employees.They are worth at least fivetimes, and perhaps ten times, what the average developer receives
[ Pobierz całość w formacie PDF ]