Wielding influence

A SIZEABLE PORTION of the weekly e-mail responses I get from this column come from high school and college students asking what it takes to become a CTO. Fortunately, InfoWorld produces a yearly list of the 25 most influential CTOs to serve as role models for these aspiring tech execs as well as for us existing ones. (Nominations are open until July 31. For more details, go to /cto/ctonominee.html .)

While thinking about whom I would nominate, I started thinking about some of the people and ideas that have influenced me in one way or another in my career.

I’ll never forget one of the pieces of advice I got in my first job out of college. I was working so far down the IT career ladder that calling me an entry-level help desk technician would have been an overstatement, so I was trying to make my mark and advance up the chain.

One day, one of the older, more seasoned IT staffers pulled me aside with a warning: “Listen. In this kind of work, you can either be smart or helpful but never both at the same time. If you’re smart and unhelpful, people will leave you alone for the most part, and you can focus on learning more technology. If you’re helpful but not smart, no one will ask you any questions, and you won’t be bothered too much during your workday. If you’re helpful and smart, everyone will come to you all the time and expect their problems to be solved quickly and intelligently every time. You don’t want that — you have to work too hard every day.”

At the time, I thought the advice was counterproductive for me and my company, so I ignored it. Looking back now, I’m even more certain that the advice was just plain bad. Being smart and helpful at the same time is what every CTO should aspire to, and most CTOs I meet regularly are nothing but smart and helpful. Ignoring the needs and problems of people in a company is antithetical to a CTO’s mission. This kind of negative calculation blunts the true passion required to execute at the level required of the CTO.

Another practice that influenced me early is promoting the sense that everyone in a company is on the same team, working together to solve the same problems. CTOs need to constantly fight what I call the “Dilbertization” of IT — the feeling some IT staff have that technology work would be a lot more fun if those pesky nontechies would just go away.

Fortunately for me, I worked at a newspaper company early on where the person leading the developers was a journalist himself. We all did our respective parts to make sure that the newspaper went out on time with no “us vs. them” — it was all “us.” It was all about making the business work, as it should be.

Fundamentally, the CTOs and others who have influenced me most take broken things and fix them, whether the problem is a mundane system issue or a struggling business model that requires the strategic implementation of technology to turn things around. Although most CTOs are spending much of their time in the boardroom these days, I’m consistently amazed at the grasp of detail that the CTOs I meet still maintain.

I spoke to a fellow CTO recently who has responsibility for managing dozens of people on a number of multimillion dollar projects, and I asked him how much detail he gets pulled into when problems arise. “Sometimes I’m looking at single lines of code with everyone else,” he said.

Maybe he should get my nomination.