One of the most powerful tools at a developer’s disposal is recursion. Whether the job at hand is defining a bill of materials or the management hierarchy, recursion is the only tool for the job. (If you aren’t familiar with the term, the GAWK manual defines it thusly: “When a function calls itself, either directly or indirectly. If this isn’t clear, refer to the entry for ‘recursion’.”)
Few CIOs design data structures or write code anymore, but those undertaking the coming transformation of information technology will be hip deep in recursion themselves. The coming IT transformation is a radical change in mission, from delivering working software to collaborating in business change. The recursion: This transformation is a business change itself, requiring all the same techniques as the business changes in which IT will collaborate if it happens.
So let’s talk about the nature of business change.
Many business leaders think it’s enough to state the change, evangelize it, and “hold people accountable,” whatever that means. If that’s your strategy, good luck, because you’re going to need it. It’s a strategy that counts on luck and lots of it. The likely outcome is that you’ll get lip service from executives, business users and IT staff who, when you aren’t looking, ignore your ideas completely. The lip service does have some value, of course: It gives you the ammunition you need to blame someone else when the change fails.
To successfully lead change you need much more: Consensus among all stakeholder communities that the change is necessary and important, a plan, and a way of determining whether you’re making progress.
You need the consensus because this has to become how the enterprise does business, and it won’t do business that way if its leaders and staff don’t want to. Building this consensus is hard, because what’s good for the enterprise as a whole won’t be particularly popular among those most affected. Under the best of circumstances, those in the middle experience the invalidation of hard-won skills, a requirement that they acquire new ones, and extra work as they figure out how to make the new way of doing business, which always looks phenomenal in PowerPoint, work in the realities of their cubicles. A frequent concomitant is having to cover both their work and the work of those employees laid off in anticipation of promised efficiencies.
In a well-designed business change program, employees who support the change can see a path to personal success. All too often, though, there isn’t even a connection between their support of the change and mere survival. In fact, some companies manage change so badly that the sole benefit of participation, received by supporters, resisters, and agnostics alike, is a free copy of Who Moved My Cheese, provided by helpful managers so employees will understand that their discomfort is the result of their being stubborn and irrational, too ignorant to understand that all change is good.
Consensus isn’t enough, of course. You also need a plan, because if you don’t have one, nobody knows what they have to do to make the change happen. It’s astonishing, by the way, how many otherwise savvy business leaders think that if they just explain the nature of the change and build consensus, it will happen all by itself through the magic of everyone behaving in ways that are consistent with the intent. If you’re one of them … imagine a program manager responsible for implementing an ERP system working this way. There’s no chance of it succeeding. To achieve major business change, someone needs to manage it, and that includes defining the tasks that need to be undertaken and their schedule.
Then there’s knowing what constitutes progress. This is harder than it sounds, especially because in most cases a major change makes the organization less effective for awhile. It has to: You’re invalidating old skills, requiring new ones that have to be learned, and blowing up the old way of getting things done. It will take awhile for everyone to get in the groove.
This is all true of any business change. Any IT organization that wants to collaborate in business change will have to master these disciplines, as will its collaborators in the rest of the business. That won’t happen through wishful thinking: As an IT leader, you have to practice them yourself so as to get the rest of the enterprise to move to this new way of doing business.
It’s recursion at its finest.