The best advice I ever got

Network professionals, industry watchers and vendor executives share the tips that helped them get ahead.

As advice columnist Ann Landers once wrote, "Know when to tune out. If you listen to too much advice, you may wind up making other people's mistakes."

In the network world, Landers' notion is well-heeded. The trick, of course is deciding which advice can make your life easier and which could derail your career.

Network World took an informal poll of our readers, network executives and others to find out what was the best advice they ever received and what they did with it. Not surprisingly, the results show that the best advice is to learn about what goes on in your IT shop, being open to its rapidly changing nature and understanding how networks are the backbone of business. It also doesn't hurt if you can solve technology problems, manage others as a team and keep customers happy.

To continue reading, register here to become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

As advice columnist Ann Landers once wrote, "Know when to tune out. If you listen to too much advice, you may wind up making other people's mistakes."

In the network world, Landers' notion is well-heeded. The trick, of course is deciding which advice can make your life easier and which could derail your career.

Network World took an informal poll of our readers, network executives and others to find out what was the best advice they ever received and what they did with it. Not surprisingly, the results show that the best advice is to learn about what goes on in your IT shop, being open to its rapidly changing nature and understanding how networks are the backbone of business. It also doesn't hurt if you can solve technology problems, manage others as a team and keep customers happy.

Specifically, the best advice to get ahead in the network arena starts with the basics. Network executives say learning the details of networks and the equipment that runs on them will get you far.

"You can never see too many networks," says Luis Henriques, senior network engineer at Coast Capital Savings in Vancouver, the second-largest credit union in Canada.

When he began his career, about 10 years ago, Henriques saw the "one little network" his small company had implemented and thought he had seen it all - until he moved to his next employer.

By the time Henriques was at his third company, his boss told him to go out and see as many networks as he could so he could advise his employer about how to implement its own new technology. "He said, 'We don't really know how this works, so I want you to go and meet these other companies and talk to their networking people and see how they do this,' " Henriques explains.

Henriques says that while he was working for a telecom service provider, the customers showed him a thing or two.

"Time passes by, technology changes. That's yet another reason to keep seeing more networks . . . throughout your career, because it's too hard to keep up with everything. Now and then it's good to step outside and go see how somebody else has already implemented their network," he says.

But before examining networks, practitioners might immerse themselves in the basics of the things attached to the networks. Such as PCs.

Craig Paul, systems software analyst in the Applications Technology Group at the Kansas University Computer Center in Lawrence, says the best advice he's received and would give is to learn the basics of computer hardware architectures.

"Routers are essentially special-purpose computers," Paul says. "If you study about computer architecture, you learn about I/O buses and things that computers can do in terms of memory and memory protection. It also leads to the realization that most host computers could be routers . . . and can be firewalled even without a firewall."

Paul says there are some people he works with - even those higher in the management pecking order - who have no idea about internal computing architectures.

Paul recalls a Java course in which he says the instructor and many students didn't know such deep details about computing architectures, such as memory paging sizes and page-size restriction. Paul even volunteered after class to instruct the embarrassed teacher about Java behavior so the instructor could impart that knowledge to the class.

Be business-savvy

Even those pursuing the executive ranks should become conversant in technology. Learn to balance technical acumen with business savvy, says Larry Jarvis, senior vice president of network and voice engineering for Fidelity Investments in Boston.

"I seem to see consistently one of two types of executives: One is the type that came up through the technology ranks and was promoted into management . . . with little to no formal management training. And then executives that come out of more of the business-school side and don't grasp the technology," Jarvis explains. "While they have good leadership skills, their ability to lead these highly technical teams wanes, because they can't have that dialogue with those contributors that are really making it happen."

Jarvis says he went through a rigorous conversion from technology into management early in his career at a former Fortune 500 employer.

"They really encouraged folks coming from technology into management with a very formalized training program to make that transition," Jarvis says. The advice was, you focus on the customers and the requirements of your customer, focus on your team, run your technology like a business, and you will be successful as a manager, Jarvis says.

"As easy as that may sound, managers that can do that successfully . . . [find it] a very difficult challenge. I think that's what makes a great leader in the technology-skills space," Jarvis says.

But so many network and business executives struggle because they are either well-versed in the nitty-gritty technology details, or they only know the business perspective. Focusing on only one of the two results in failure, Jarvis says.