But there are ways IT leaders can foster greater accountability among their developers, engineers, and programmers without scaring them off completely. Max Katz knows all about the willingness to take ownership for an IT project. Head of developer relations at Tiggzi, a software application development company in San Francisco, Katz said, "Here in Silicon Valley, there are a lot of start-ups so there's a kind of natural inclination to take a lot of responsibility and take on a lot of accountability. That's because there are a lot of people who want to get ahead."
When that is not necessarily the case, there are steps IT leaders can take to spur IT workers into action and accept greater responsibility, said Katz. Here are four.
1. Reward creatively. Stepping up to the plate is a scary position that should be rewarded in some way, said Katz. Many IT leaders might be inclined to toss bonuses at developers and engineers who claim a project as their own, but Katz said vacation time is a far more valuable commodity among IT professionals today. Although "giving more money is always good, more flexibility from a work perspective is a pretty hot topic right now among a lot of start-ups, especially in companies that don't have a vacation policy," he said--all the more reason for companies to offer stand-out IT workers time off for a job well done.
[ Read Rev Up Your IT Career. ]
2. Don't punish. One of the most common disincentives for taking greater responsibility for a project is the chance of failure. How IT leaders respond to the odd failure or fumble can have a significant impact on an IT team's morale--and on a leader's ability to foster accountability. "Failures happen," said Katz. "The key is to learn what happened and to make sure it doesn't happen again. If you read about successful start-ups, one of the best things they did is fail a number of times. If things don't work as expected, you learn from it and hopefully it'll never happen again. At the end of the day, it's a good experience." Besides, warned Katz, reprimanding an IT professional who took a chance on a doomed project is likely to backfire. "There are so many companies today looking for developers, if something doesn't work, and you reprimand them, they'll just leave the company and go somewhere else," he said.
3. Look beyond tasks. There's more to accepting greater responsibility than becoming a project lead. Katz said he looks beyond IT tasks when evaluating workers' efforts to play a starring role. For example, Katz said, "It's becoming popular to launch inside hacker-thons where employees get one or two days to build whatever apps they want." Taking it upon oneself to stage such an event is as much a demonstration of commitment as taking over a project.
4. Recognize risks taken. Anyone can attach his name to a project that's destined to succeed, but being willing to inherit risk is the greatest show of accountability, said Katz. If someone took on a job developing apps for RIM's Blackberry instead of Apple, for example, he also took the risk that Blackberry isn't doing well right now and that perhaps in a year or so, everything he spent his time working on might not pan out. That would be unfortunate, but this person tackled a project head-on, against all odds, said Katz. He also had the foresight to realize that even if things didn't work out with one project, if he did a good job he could easily transfer his skills to another platform.
At this year's InformationWeek 500 Conference, C-level execs will gather to discuss how they're rewriting the old IT rulebook and accelerating business execution. At the St. Regis Monarch Beach, Dana Point, Calif., Sept. 9-11.