Management Speak: We need to leverage our brand name.
Translation: We're going to cut the quality, raise the price, and buy a TV ad.
-- In order to preserve his personal brand, this week's phrase-donor has asked to remain anonymous.
In the beginning was EDP (electronic data processing). Using EDP, we wrote computer programs to automate business processes. Ignorant about methodologies, we just talked with the people who were going to use the system, figured out together what it should do, and tweaked things until everyone was satisfied. Eventually these programs turned into legacy systems.
Like baseball managers, most of whom once played the game, the guy who ran EDP was a former programmer who could talk to the company's business leaders without scaring them. A lot of his conversations started, "Didja know ... " as in, "Didja know we could automate that and save you a lot of money?"
Then database management systems happened, and some genius decided our real job was to manage information -- a clear case of confusing means and ends. EDP became IS, the person in charge became chief information officer, and theorists inflicted bulky methodologies on project teams. The result? Long delays before the writing of actual code, and an organisational hierarchy to separate programmers from the people who need the programmers' product.
Along the way we gave up on the baseball-manager theory of CIO selection. Instead we focused on the need for business knowledge. If that wasn't bad enough, we defined business knowledge as "understands how to perform a ROI analysis."
We got what we asked for: late, bloated projects, fictional ROIs, and a management-fad orientation leading to the belief that late projects and fictional ROIs are fine so long as we "satisfy our internal customers." Mired in these time-wasters, most CIOs missed the Internet. Oops.
So now we have chief technology officers.
Sometimes the CTO is the CIO's peer, with the former focused on the Internet and the latter on everything else. This is worrisome from the organisational design perspective because it has strong potential for dividing accountabilities.
If your company insists on having both titles, minimise conflict by giving the CTO application-layer authority only, but responsibility for all customer-facing applications, not just the Internet.
Why? If your CTO owns the Internet, your telecommunications manager (presumably retitled to chief voice officer, or CVO) will own your interactive voice-response and call centers, another bizarre title will own sales force automation, and the chance customers have of getting consistent service across all channels is exactly zip.
In most companies, though, CTO is the new title for "the person we hold accountable for all of our computer stuff," accompanying a name shift from IS to IT. CTO implies rejection of a lot of the intellectual baggage we've accumulated since EDP first changed its name.
Like the EDP manager, but not the CIO, the business wants its CTO to have a strong technical focus because that's how you figure out what the business can do today that it couldn't do yesterday. And where EDP lacked formal methodologies, in the CTO's world they exist, but they're pretty lightweight, because the ones we've been using are way too slow. Mostly, programmers work with whomever to design the customer interface, then work backward to design the system's innards.
Best of all, CTOs reject the ridiculous concept of "internal customer." They're far too busy worrying about real ones.
Does this sound right to you? Send an e-mail message to email@example.com. Bob Lewis is a Minneapolis-based consultant at Perot Systems.