One thing that surviving six rounds of layoffs in a little more than two years has taught me is that being a superstar developer isn't enough to save your job. Actually, it's often not even necessary. After all, how much of your daily work really requires your "best" programming skills? I've seen excellent developers let go during layoffs, while some of their lesser-qualified peers survived.
Is it because management is clueless and out of touch with the needs of the business? No, it's because the company would prefer to employ someone who has adequate development skills combined with the necessary soft skills to get expensive projects done.
After making it through the dot-com bust with my job intact, I have a good idea of what skills can make you a more valuable team member. Although most of these items are pretty basic, we are all guilty of letting some of these things slide—sometimes without realizing it.
Know your business inside and out
If you want to chart a career path within your organization, you must understand its short- and long-term goals. In addition, you should understand your company's products and services, who those products and services are targeted at, and how those products and services are used.
You can learn more about your business in several ways. One easy method is to review your company's marketing, public relations, and other external communications. After all, those materials are being produced to inform people about your company. Most of that information is probably on your company's Web site or intranet. It will give you a broad overview of your business and its products. It won't give you all the information you will need, but it will provide a foundation to build on.
The best way to get more specific information about your business is through your coworkers. I constantly have people stopping by my office to check on the status of projects. I often use those impromptu meetings to ask questions of my own. I've found that most people love to tell others about what they do and are more than willing to share information. Just be willing to do the same. There is nothing worse than when someone asks you for your ideas and you don't have anything meaningful to say.
When times get tight, everyone in the organization should be willing and able to contribute ideas or solutions that address specific business objectives. So the more you know about your business, the more you will be able to contribute. And even if you aren't immediately concerned about moving up in your company, knowing the "why's" behind a project can make figuring out the "how's" much easier.
Be a team player
Okay, I know the term "team player" is right up there with "thinking outside the box" and "synergy" when it comes to business cliches, but there is still a grain of truth to it. There is often a pretty big gap in communication and teamwork between a company's business units and its technical team. The business people are perceived as impatient and demanding by the technical people, and the technical people are seen as arrogant and lazy by the business people.
This division often prevents the groups from working together effectively. It also makes it easier to dwell on personnel issues rather than the project everyone is working on. How many times have you recognized that a business client's requirements were vague or incomplete but implemented it exactly as it was written? Next time, instead of taking the easy way out, find out what the client really meant. Sure, they may have written inadequate business requirements. However, as a member of the team, it is your job to do what is best for the project.
I recently had a coworker come to me and express frustration with one of our legacy applications. It turns out that the Perl script that the application used was written by an employee who had left the company long ago. Because there was no one to support the software, he'd been doing hacks and workarounds just to get by. Now, he had some new ideas he wanted to implement and didn't really know how to proceed.
Knowing that this issue wasn't a big deal technically but was a huge roadblock from a business standpoint, I offered to take a look at it in my spare time. In less than two hours, I was able to come up with a solution that saved his team several hours each week. He was thrilled that his team members could now use their time more efficiently.
Be a good communicator
Because of the split that often exists between the business and technical groups within an organization, you must have good communication skills. Many people don't, and they don't make any effort to develop them.
It's easy to get into the habit of depending solely on e-mail to communicate with other team members on a project. And because of deadlines, those e-mails can often be short and unintentionally vague, especially to a business client who doesn't have the same level of technical expertise. This type of communication often feeds some of the negative stereotypes I mentioned earlier.
So the next time an issue comes up or you are dealing with a "difficult" business client, get out of your chair, walk down the hall, and speak to the person face-to-face. It's amazing how much a little face time can accomplish. Not only will you be able to communicate more clearly and quickly than if you'd exchanged multiple e-mails, but you'll also demonstrate that the issue was worth your time.
Provide creative solutions
Let's be honest: Sometimes, the business teams in our organizations present us with project ideas that aren't fully baked. They may know what their business need is, but they don't know the best way to meet it. Worse still, sometimes they suggest a way to implement their idea that just isn't feasible.
Instead of simply pointing out the problems with their implementation ideas, use this opportunity to showcase both your business and technical skills by coming up with sound solution of your own. If you're careful to work with the business client (and not just steal their thunder), you'll gain respect from your business partners and demonstrate that you have more to offer than just code.
It can be tricky figuring out how and when to step in with your ideas. If I have concerns about how a client has asked to implement a particular project, I'll usually work up a mockup or demo of a solution I would like to propose. However, instead of leading off with the demo, I'll ask the client questions ("How did you envision this working in this situation?" or "What should happen after a user performs this task?") to help them expose some of the issues themselves. Once the issues are out in the open, I introduce my proposed solution and point out how it might address the issues raised. No matter how good your idea might be, some clients need to feel that they helped contribute to the solution or you won't get their support.
Have a good attitude
I saved the most important one for last. Your attitude is either your biggest strength or your biggest weakness.
Most of your coworkers don't know you for your code; they know you for your attitude. Even if you've never interacted with some of your coworkers professionally, if you've got a bad attitude (or even if people just perceive that you do), chances are that everyone knows it. After all, when people gossip with their coworkers, it is rarely about what a good job someone is doing.
Whether the decision is who to promote or who to let go, your attitude plays into it more than you might think. Fortunately, improving your attitude is relatively quick and easy. Often it just requires paying a little more attention to how you interact with your coworkers.
I once worked with a developer who was incredibly bright. If there was a problem that was stumping everyone else, he was the person who would figure it out first. Unfortunately for him, he had a tendency to belittle everyone else for not knowing how to solve the problem. He was a great developer but a horrible coworker. So when the time came to make a decision about whom to let go during a layoff, much to his surprise, he got cut—and a junior-level developer with lesser skills was kept instead. Our manager realized that having a team of solid developers who worked together was better than having a superstar who alienated everyone.
Make yourself valuable
Employees who don't have these basic soft skills to complement their core competencies ultimately cause more problems than they solve. And as budgets get smaller, a developer—regardless of technical proficiency—who can't work well with peers is a liability. If you have let some of these skills slip, now's the time to make improvements.