Here, youíll discover various aspects of the high-tech culture, the six phases of a typical software development project and five kinds of skills high-tech employers are looking for when they hire technical communicators.

Having worked for IBM, Intel, Tektronix, Mentor Graphics, OrCAD, MedicaLogic and other high-tech companies myself, I can tell you there are cultural dimensions all these companies have in common. High-tech is also high-stakes. For every "dot.com" leader offering a new product, there is a line of wannabe's agitating to move into position and take over the leader's market share with a better product. Stability and predictability are anathema to companies striving for profitability and growth in markets where you either innovate or perish. High-tech companies are on the "bleeding edge" of economic development.

High-tech cultures reflect typical American values of winning and success ó being the first, smartest, fastest and the best. High-tech companies are dominated by the egos of those that spawn them and then drive them to success. Parking lots of high-tech companies are full of Porsches, BMWs and Lexuses. Those in the higher echelons of corporate management are known for their conspicuous "toys," lavish houses, extravagant vacations and obscene disposable incomes.

Some of this wealth trickles down to rank-and-file employees in the form of bonuses, stock options and other perks. High-tech workers earn the highest average pay working for companies with some of the most progressive human resource policies. On-site child development centers, company-sponsored education and degree programs, flextime, paid sabbaticals and telecommuting are well-established practices in many high-tech companiesónot so in more traditional industries.

Although extreme competition, mergers, and reorganizations are the norm, so is creativity and a talent pool of bright, imaginative and technically sophisticated people. Compared to working in more traditional, established industries, working in high-tech is like driving a sports car instead of taking the bus. If you like roller coasters, you'll love high-tech.

If you sign on to work for a high-tech company, you can't help but absorb some aspects of the pervasive corporate culture. Corporate values permeate the entire workplace, from subtleties of the messages delivered at company meetings and social functions, to the e-mail that emanates from computers in every cubicle.

All the software projects I've worked on, in half a dozen high-tech companies, have a lot in common. There is a consistent style and a pattern associated with software development.

Most software is developed by multiple contributions of members of a project team. The early 1980s model of the programmer entrepreneur creating a killer application and marketing it through a renegade distribution network, like Egghead, is just a memory. Good software coding is no longer sufficient to create and sell a product. Today, if software is going to sell, it has to be customer-oriented, bug free and well documented. To make sure software meets these requirements companies form integrated development teams comprising members from software engineering, marketing, customer support, quality assurance and documentation.

These five functions are the cornerstone of software development. Usually, marketing takes center stage and directs the product development; engineering, having the critical technical role, carries it out; and the rest of the team form supporting characters. Your job status is commensurate with your perceived role, somewhere between royalty (marketing and engineering) and serfs (admins and clerks). Some teams are more egalitarian than others.

Teams are configured formally or informally, with lines of communications and decision-making varying from nonexistent or obscure to highly structured, almost to the point of brittle rigidity.

Software development projects follow a similar development cycle that goes through six distinct phases. The following diagram is a generalized profile, depicting the level of intensity or effort on product development over time. In my experience, all software development projects exhibit some kind of saw tooth behavior; it's only the actual shape of the teeth that varies.

At the beginning of the software development cycle there is usually some kind of formal kick-off or internal announcement that development is about to begin. Most often, marketing takes the helm and throws a party with a lot of fanfare, almost like a pep rally.

These occasions are a little like exhorting troops before going into battle. Companies have been known to rent out restaurants or Elks Lodges and gather everyone together for an injection of enthusiasm to boost morale and convey expectations. T-shirts and mugs get handed out, managers are introduced and past successes are recounted. An unstated objective is to get employees to "sign-up" for the forthcoming project.

You'd think that such celebratory affairs would be postponed until after the product ships, but many times this is not the case. One company sent half of its employees to Disneyworld for a week's vacation celebration, more than a year before the product release!

After the launch, project teams are formed, objectives set, milestones charted and work plans put into placeóbut not necessarily in this order. Most projects go through a period of chaos and confusion where it's unclear who's in charge, who's working on the project or what the priorities are. Some projects never seem to settle these arrangements to the point where everyone is coordinated and working on the same objectives. I worked on one chaotic project where it was never clear who was in charge (no one I think), and the schedule was so mutable and indeterminate that everyone I talked to had different set of dates. Figuring out who was in charge reminded me of a battle scene in a Civil War movie where whoever is carrying the flag is the one everyone follows, until he gets shot. The next guy to pick up the flag then becomes the leader.

Once the project teams are established and milestones have been defined, a kind of complacency sets in. There is an initial attempt at team integration and project management through regular meetings and status reporting. People respond to such overtures willingly but half-heartedly. People work regular hours without a lot of intensity. There's a lot of yawning in the afternoon and idle chit-chat in the halls. Deadlines seem remote and people tend to work independently on their respective aspects of the project.

At some point, usually after the marketing team rep returns from a trade show, anxious about competitors, a bolt of electricity shoots through the project team. This is known as a "galvanizing" or triggering event. All of a sudden, deadlines, which were indefinite, become frozen. Priorities are finally decided, the project scope gets scaled back and work elements get cut. Team members start looking for short cuts as people come to realize there's too much to do in too little time. A clear focus and dead-serious urgency absorbs the project and everyone starts working "heads down." Idle talk in the halls disappears, and people get terse and testy. A real sense of urgency and intensity sets in.

At this point, everyone makes a final push to complete the project. People who had nothing to do with the project get drafted to pinch-hit in testing, documentation and bug fixing. Managers spend all their time tracking bugs and trying to determine the trade-off of postponing product release to fix critical problems versus shipping on time with some level of broken functionality. Marketing finally chimes in at the 11th hour and makes its concerns known ó something they've been unable to communicate until now.

When all the other participants are done with their parts of the project, invariably, it is documentation and testing who spend the late nights and weekends trying to get everything done on time. In the end the product gets released, propelled by forces beyond the control of the project team, and the entire company breathes a collective sigh of relief.

After product release, the workload drops off precipitously. Vacant-eyed people who haven't changed clothes or showered in days, who have subsisted on junk food and nights of four-hours sleep, go home to their spouses and families to eat real food and crash in nice warm beds. Companies schedule pizza parties, BBQs, golf outings or trips to the movies to help employees unwind. Finger pointing and recriminations are postponed until later, during the ritualistic "post-mortem" (more accurately, post-partem.)

After decompression, marketing arrives at the scene to launch development of the next version of the product and the software cycle starts all over again.

As with most technology jobs in the current economy, the demand for technical communicators in high-tech companies greatly exceeds the supply. You'd think this would lower the barriers for getting into a company, but this is not true. In many instances, tech pubs managers will leave a job unfilled for months rather than hire someone without a suitable background. In recent years, in fact, the bar has been raised for entry into the specialized membership of technical communicators. As little as five years ago, you could get a job as a technical writer with little more than an English degree, solid communication skills and a convincing interest in technology.

Nowadays, tech pubs managers want applicants to have more than just the ability to write and use a word processor. They look for experience with software tools and communications skills, but they also want to assure themselves you have the ingredients for success. Here are five important skill sets you need to possess if youíre going to get a favorable nod from a hiring manager.

Although product development is left to engineers and scientists, you are expected to be knowledgeable about the technology your company deals with. What you don't know, you need to learn quickly if you are to write knowledgeably about the fine points of such subjects as medical records management, circuit simulation, or routers and servers. You have to be able to interview engineers who speak in a peculiar jargon and then make sense out of what you've heard. You have to be comfortable in their arcane world and sift through their detailed explanations so you can convey their ideas to an audience who might not be nearly as technically sophisticated as they are. You might not need to think and talk like an engineer, but you do need to be able to translate what they write and say into something clear and accessible.

In high-tech you can't afford to be cyberphobic. You have to embrace new technologies enthusiastically. Learning to use and master the new features of a product while it is still being developed is an everyday experience. Technical communicators are some of the first non-technical users of a product, and you have to constantly adapt to changing specifications and work around features that are not yet plugged in to the product. You don't need to know how to engineer a product, but you certainly need to know enough to understand how to use it and be comfortable doing so.

Talking about teamwork may conjure up all kinds of sports analogies and clichés, but working effectively in teams is essential to product development and a big part of your career. Your job is, fundamentally, about communications. This is not a job where you go into your cubicle, shut an invisible door, and write all day. High-tech is a world of continuous meetings, discussions and collaborations. You must have the ability to listen well, synthesize what you've heard and reciprocate by contributing your own ideas. None of these interactions can be done successfully or exclusively by e-mail or telephone. One of the telltale indicators of an ineffective technical communicator is someone who has a reputation as a loner. You have to participate to be successful.

Being able to write and communicate ideas and information effectively may be a necessary requirement for the job of a technical communicator, but it is not enough. You also have to be able to use common software tools to manage your ideas and information. Most tech pubs groups require basic experience with desktop publishing software, Help authoring systems, HTML editors, Internet search engines, e-mail and other tools of the trade before they will even consider your resume.

Although you won't have the depth of knowledge of a systems administrator on staff, you do have to have enough knowledge and skill to install software and debug problems on your own computer if want to get your job done. Your teammates won't mind guiding you once or twice through a software installation or product configuration, but if you ask them repeatedly, their patience will wear thin.

Finally, you are expected, above all things, to know how to communicate effectively. Certainly, writing words on paper or putting information up on a Web page are everyday kinds of tasks. But your colleagues will see you and value you in a larger capacity. Technical communicators bring focus and coherence to the technology development process.

As part of your master communicator, jack-of-all-trades role you will be drafted to test for product defects, become a customer advocate or project advisor. You might, for example, be asked to write meeting notes, plan agendas, polish a technical specification, architect information for a Web site, evaluate product usability or write progress reports for your team. Other times you might informally become the project manager's right-hand advisor, taking the pulse of the team's morale and deciphering a myriad of people problems that afflict the team. You get to work in all these capacities because you are a communicator and not just a tool jockey.

In the 21st century, the job of a technical communicator will be less about writing and more about processing and managing knowledge and information. The demand for technical communicators in software development and knowledge management companies continues unabated.

There is no limit to what you can do or what you may become in a high-tech company. Job titles are fluid and technology development is not the exclusive domain of degreed engineers. Regardless of your job title, there is tremendous mobility in high-tech companies. You can start out as a junior tech writer and work your way into training, marketing, technical support or quality assurance. In a few years, you just might find yourself a recognized technology expert or a manager influencing your company's future.

So, if great pay, the opportunity to use your communications skills, a dynamic work environment, the challenge of mastering tools and contributing to the advancement of technology appeal to you, then by all means jump in and join a high-tech company. It might just be the adventure of your life.

Copyright ©2000 by Metamorphix Consulting, Inc. Used with permission of the author.