|
|
||
|
Managing Techies | |
|
Originally written 20051108 There is a must read for anybody is, employs, or manages techies. "How to Manage Geeks" was written by Eric Schmidt of Sun and Novell fame in June of 1999. The article is so good that the rest of this article will blatantly paraphrase his ideas. Well, no, but I am structuring my comments as a companion to his article. Every company needs the best techies available1. Good techies make business faster and life easier for everybody. One week of my work saved 6 hours per day for 6 people forever, and the quality of work increased because the employees relaxed knowing they would easily complete the day's tasks before going home at a reasonable time. The department was 50% overworked (everybody worked 12 hour days), so they could have added 3 human resources. A one-time cost of 1 week's cost for 1 human resource is incredible return on investment ("ROI"), even if I cost several multiples of a normal employee's rate 2. Good techies make new things possible. Several of my projects collect statistics and automatically alert management about extremes. The input is easier with a computer, and analysis would require at least 1 expensive employee to work with the numbers. With software, this work is automated and looks for any extremes, not just management's latest interest. Understand how techies thinkMost techies expect competence in everything. They do not understand that most non-techies expect conversational lubrication. Techies are focused on projects. The project is going to lunch. The phone call is: "Ready for lunch?" "10 minutes. Burger joint?" "Good. Tell Dave. John's with me." "OK." [Click] Yes, non-techies sometimes talk like this. Yes techies sometimes talk about things outside the current project. But most techies talk like this most of the time. Non-techies find it rude, and label it "poor social skills". Techies are communicating at high bandwidth; shouldn't that be "great social skills". It is the people who need 10 minutes for the above conversation who are communicating poorly. I communicate regularly with both types of people, and both types state I have "good social skills" because I talk to each in their own style. Companies often use me as a translator between management and techies. I am fantastic for gathering specifications because I understand what management wants despite their poor technical comprehension and my plans include what they meant rather than what they said. A recent example was users complaining "their login did not work" when a browser was not opening PDFs correctly. Login worked properly; it was 3 steps later they were having difficulty. The proper process is to immediately ask what they are attempting, what they did, and where it failed rather than focusing on what they said. Techies know they are doing everything as well as possible. They do not respect people who do not. That translates as arrogance to non-techies. Know what techies wantTechies know they are important. They know minutes of their work can save much resources. They expect to make business better, and they expect to receive a portion of the savings. During the end of my last lengthy "full-time" employment, I worked less than 20 hours each month for 6 months. My input won over $10 million dollars in new business, and saved failing projects worth even more. I added 5 lines to a "second opinion" about a new project; the customer quoted 4 of those lines as the reason why they decided to give the $4 million project to my company. Senior management was very upset that I did not work 40 hours every week. My annual pay was less than $100,000, and they saw an employee who did not fit the mold, rather than an incredibly profitable but inexpensive resource. My managers tried to protect me, but eventually senior management removed me (and the company committed suicide.) Compensate techies without forcing them into managementMy input is worth millions of dollars to most companies through planning architecture and new applications, designing fast and usable applications, and suggesting ideas about improving business. Those companies expect that advice for a steady paycheck about a quarter of my consulting rates. To be compensated reasonably, I had to become a "consultant". Companies hire me for very short periods for their own goals. They lose because I never have the impact of being a respected member of the strategic team. The skills of a good techie do not translate at all to the skills of a good manager. In a well-run company, techies would often be compensated several multiples of their "manager". For historic reasons, most companies feel the management hierarchy is an indication of value. Employees are often too valuable in their current job to be "promoted" to management; they need to be compensated based on their value, not their position in the management hierarchy. Programmers are artistsGreat programmers are artists. They need the perfect environment to create. They need quiet, or loud music; they will refuse to work in a cubicle farm. Many have weird sleep schedules. Many will work for forty hours straight, sleep for a few hours, then do it again. Once the major issues are solved, they will do minor work for a few days, then take a week off so they are rested for another marathon. No programmer can be productive going home at 5 PM five days each week. Most administrators must be available to work weekends and whenever the beeper is activated. Allow them a standard work week of 20-30 hours of afternoons, so they do not mind the hours outside the normal business week. Technical Support is an entry level position. Make them work whatever hours needed. Know most must be promoted or they will quit soon. Fire Bad TechiesI recently worked at a company where the lead programmer was unable to work with anybody. Fire him. Teamwork is a critical component for software development. I know several project managers who would rather have a team of mediocre programmers than one great programmer who upsets the others. Even if the great programmer can develop the software alone, they need to team with business people to develop the specifications, see how the software can be improved, and teach them how to use the software. If an administrator does not offer a plan so that the latest problem does not recur, fire him. If your company refuses the plan without explaining why and considering alternatives, fire the management. Every problem is an opportunity to improve something. Make certain your administrators know their job is to stop fires from happening. Then make certain you can use them in other capacities so they do not worry about losing their jobs. Let them train as a programmer, or involve them in planning new initiatives. If your company is not growing, your administration staff should be shrinking. If your non-techies do not like to talk with a support person, fire the support person. It does not matter if they are unknowledgeable, condescending, or just unpleasant. Their job is to solve problems. If they upset the business people, the business people will not call when there is a problem, and the company will suffer. Again, every call is an opportunity to improve something. It could be more redundancy is required so critical applications are always available. It could be making the applications easier to use by noticing where users get confused. It could be another sentence added to the instructions. Let the support personnel be involved with the development, documentation, and development groups. The other departments will get to know the support personnel, the support personnel will learn about possible career paths, and everybody wins. Techies Solve ProblemsThe article suggests that techies will solve problems if given the resources and authority. It is true that techies respond better when treated as adults rather than children, but that is true of most people over 7 years old. It also suggests that techies are the best judge of other techies. This is true, but you need to know the competence level and personality of the techie doing the judging. Most incompetent techies love other incompetent techies, and resent any who understand computers better, or have more knowledge without the skills to explain it. The few incompetent techies without this attitude quickly become competent. Competent techies dislike the incompetents because they must spend time fixing problems caused by the incompetents. Superstars find the rest annoying or funny, based on their own personality. I accept that there are few people like me, accept I will usually work with people without my experience or knowledge, enjoy when I meet someone who has experience or knowledge I lack, and find most of the solutions created by others to be humorous (and sometimes dangerous.) I have met thousands of techies. About half should not be allowed near a computer. Most of the rest do well. A few are superstars. Try to find and keep the competents and superstars. A natural leader will emerge on most projects. Often it is the superstar. If the superstar is a difficult teammate and poor leader, then another leader who can work with the superstar will emerge. If there is no superstar, the project is doomed, and a non-techie project manager should be assigned to make the motions until it is cancelled. If you do have a superstar with good teamwork ability, one business-driven project will not keep them occupied. They will accomplish most of the work during short bursts of frenzied activity. Let them associate with other projects. When I was at a consulting firm, I spent a few hours each week wandering and asking people what they were doing. Management was upset because I was interrupting the work. I never bothered someone when they were "in the zone". The others were often stuck on a problem, and it was solved by the end of my "interruption". It never mattered what technology they were using; a superstar will find a solution. Small Teams, Small ProjectsComputers are there to do the work. Proper choices of technology allow even programming to be done quickly. Each project team should be one to six people, including the business specialist, the designer/architect, the interface designer, and a programmer or three. If the project requires more, either the requirements need to be reduced for this phase, or it needs to be split into more projects. If a project is very large, add a central team responsible for integrating all the small projects, but keep the programming teams very small. I can build most business applications in a few months. Add 4 people, and the project will take 6 months. Managerial overhead can double the project time. Specifying the technology could triple the project time, and could doom the project. (And I might turn down the project. I have yet to miss a deadline, and never had a project fail. Too many technical decisions from business management is the easiest method to doom a project.)
|