In his new book, “Empowered,” co-author Ted Schadler tells the story of how a bunch of employees at big-box retailer Best Buy created a “twelpforce” to respond to customers talking about their experiences on Twitter. It was done to improve customer service, with the added benefit of preventing a negative experience from exploding all over social media into a public relations nightmare. (“DON’T SHOP AT BEST BUY! I bought a TV there. It broke, and they won’t honor my warranty. WTF???”)
This was not a corporate mandate from on high; the project was conceived of and implemented by people in customer service, marketing, communications and IT. Best Buy had empowered its employees to run with their expertise in social media, and the effect has been quite positive.
Another example from his book: Business information organization Thomson Reuters was looking for a down-market channel to find independent investment advisors and distribute information to them; the company has built its delivery network for large institutional investors. An employee in the company’s business development area, Ross Inglis, suggested using a cloud approach for content delivery, and using Salesforce.com for tracking customers and payments. An application developer played around with Salesforce.com, while Inglis got business, marketing and IT on board with the effort. The result, as of this writing, is that Thomson Reuters is close to realizing more than a million dollars in return on a project that cost around US$100,000.
Schadler describes these people as HEROes (Highly Empowered and Resourceful Operatives). These things that are going on the consumer market, he said, need to work their way into other types of organizations.
In software development, the idea of empowering individuals flies in the face of common IT practices and policies. Most organizations do not want their workers downloading rogue software that isn’t managed on some central server. They don’t want open-source code introduced willy-nilly into their organizations for fear of violating licenses. And they certainly don’t have the excess manpower to allow developers to go off on their own and create one-off projects.
But Schadler, a Forrester Research vice president and principal analyst, and his colleague there, Jeffrey Hammond, said developers are likely candidates to be HEROes. “Developers cracked the code on community-led, bits-at-a-time incremental development,” Schadler said. “That was an early form of self-organizing, bottom-up innovation. Developers have always been at the bleeding edge of it.”
Hammond pointed to data that shows developers choosing Apache Tomcat as the No. 1 server they use, and that Eclipse tools, MySQL and Amazon EC2 use is widespread. “Even though IT’s not comfortable with it or might not condone it, [developer self-empowerment] is happening.” So organizations should give developers the autonomy to get to a better outcome, he said. “If you unleash your developers, you’ll see incredibly innovative things being done.”
There is, of course, the matter of trust, which is a two-way street. The company has to trust that developers won’t “go rogue,” and the workers need to trust that the company isn’t simply giving them enough rope to hang themselves with. In an agile development shop, “If you let the agile team work how it wants, what’s to stop them from being undisciplined? You have to judge the outcome at the end,” Hammond said, to know if the trust placed in the agile team was misplaced.
Schadler and his co-author, Josh Bernoff, describe the “HERO Compact,” which essentially is an agreement that states the HERO will work within the organization’s safety principles (for developers, it means adhering to policies regarding downloads, working inside the corporate security structure, and the like), while the development manager will work with IT to manage risk, make innovation a priority and support the HERO’s efforts. Yet giving workers broader control involves more than just implementing IT. It touches the legal and human resource departments as well, in many cases.
“This is probably the hardest shift in the whole ‘Empowered’ theme,” Schadler said, “to get [HEROes] to trust that you’re looking out for them.”
There will be times when an organization has to say “no” to a HERO. Four examples from the book are: when new laws are enacted with which the organization cannot yet comply; when customer contracts prevent you from sharing anything about the contract, such as in government contracts; when the organization’s legal team advises against it; and when the actions of the HERO compromise customer or employee data.
And what about Ben Hedrington? He’s the guy who created the technology behind Best Buy’s “twelpforce.” According to Schadler, “He is so motivated to utilize Web technologies that he’s become something of a guru in the company on how to drive business forward.”
Being a HERO certainly paid off for him and for Best Buy. What can you do to drive your company’s business forward?
David Rubinstein is editor-in-chief of SD Times.