Navigation:  Articles > Feb-2000 >

Getting Better

Previous pageReturn to chapter overviewNext page

Peter Vogel

For the past four issues I’ve been using this space to talk about ways that you can manage your career to ensure that you can have the jobs you want (and stay employed). This is the last editorial in this series (I promise!), and I’m going to use it to talk about what you can do to improve in any particular skill.

For any line of work that you want to get involved in, you have to identify the Critical Success Factors (CSFs) required to succeed. CSFs vary tremendously from one skill to another. For instance, as I suggested last month, I feel that excellent listening skills are key to being a great database designer. When you’re pulling together a skill map, you want to make sure that the skills that you’re identifying are the critical ones (and not just the skills that you’d like to have or already own).

One way to determine which skills are essential is to find someone whose work you respect and watch them like a hawk. Don’t hesitate to ask people that you admire what the secret to their success is. Often just listening to the war stories that these people tell you can give you tremendous insight into what makes a successful programmer, application developer, or project leader. If you can develop a good relationship with your role model and they have insight into how they do their work, you won’t get a better education. If you can get this person actively involved in helping you get better, what everyone now calls mentoring, you’re even better off. Live by two rules: "Steal from the best" and "Learn from other people’s experience."

There’s a temptation to limit your learning to just the knowledge that these people have. To really succeed, you also need to identify what specific behaviors these people exhibit and start modeling them. I feel, for instance, that a database designer needs persistence and patience. Most of the problems that I’ve had with database designs have come from rushing to a decision and then hurrying to build code based on that design. On the other hand, I feel that the key to successful user interface design is to produce something as soon as possible and make arbitrary decisions in order to get something into the users’ hands so that they can start telling you what’s wrong with it.

The next best thing to watching somebody work is to take training. Training is not a substitute for experience, but it does expose you to a lot of knowledge in a short period of time. Even better than taking training is giving training. I firmly believe that you don’t really understand something until you teach it to someone else (and, preferably, teach it frequently).

Training takes a lot of forms. Reading a book or an article counts as training, as does writing a book or an article. And, of course, you can always take courses if you can get away from the office. In fact, many people attend classes simply because it’s the only way that they can learn without being interrupted.

Volunteering to work in an area that you don’t know is often an excellent form of training. As I mentioned two issues back, developing skills often have to be given away. However, you should also make sure that you have access to the skills and knowledge to complete the job. Volunteering to network a client’s office without knowing what you’re doing or having someone to fall back on is just foolish. I didn’t pick that example at random, by the way. Fifteen years ago, I sold a client on installing a network and, surprisingly enough, I successfully carried through. Three years later, though, they wanted to upgrade and I found myself in over my head. Fortunately, my brother-in-law did know how this stuff worked and didn’t mind being called at 2:00 in the morning with a cry for help.

You also need to build in feedback loops that will tell you if you’re successfully acquiring the skills that you need. I started working in the manufacturing industry for a company that made rubber. The model for this company was a pipeline: Crude oil poured in one end of the plant, was processed, and large quantities of rubber came out the other end. Based on my presumed manufacturing experience, another company hired me to head up their IT division. As time went by, I began to realize that I had no idea what was going on. Everybody was finding it very difficult to explain anything about what was important about the company’s operations to me.

Unlike my previous employer, the model for my new employer was individual, not mass-produced, products. Each product that we made was specially tailored for each customer. Undifferentiated raw material didn’t just pour in one end of the plant like the crude oil at my previous employer. Instead, we had to carefully manage what we ordered from our suppliers to ensure that we could build the constantly changing products that our customers requested from us.

Fortunately, I had a mentor in the plant who decided it was his job to help me understand how his business worked. I actively solicited feedback and input from this person and, as a result, eventually came up to speed in the business that I was part of. I won’t say that people still didn’t have to use lots of pictures to explain things to me, but they put away the sock puppets.

Finally, here’s the best training that you can get, once you’ve identified what you need to know: Fail. When we succeed, we figure that we know what we’re doing and assume that we’re wonderful. When we fail, we assume that something went wrong and set out to learn what went wrong. Only by constantly thinking about what you can do better next time, can you actually do better next time.


See all the Editorials   or ALL THE ONLINE ARTICLES