All Posts in Leadership

|In: Leadership|Last Updated:

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.

Comments

|In: Industry Commentary|Last Updated:

Not all that many years ago, a friend of mine bought a router. When he brought it home to show his wife, she asked, skeptically if it was really worth a week’s lunch money. So to prove its value he’d spend hours in his workshop, using his new router to build nifty items like chairs, tables, and lamps. (Now, of course, the wife is as likely as the husband to bring home a router. Usually, it has Wi-Fi built into it. But I digress.)

Routers are versatile tools. But not so versatile that they solve every problem. To pry the lid off the paint can or hammer nails you’d be better off with other gadgets. It’s a lesson some CIOs need to learn: Having adopted global sourcing as a useful addition to their IT sourcing strategies, they’re now trying to use it for every job in IT.

The problem is, global sourcing vendors aren’t well suited to every job in IT, and in fact some modern trends are converging that should aim wise CIOs squarely at local resources. These trends are the accelerating trend toward making use of commercial software rather than in-house developed proprietary software, the trend toward componentized software architectures, the increasing use of adaptive methodologies such as eXtreme Programming (XP), and the growing awareness that the proper goal of IT isn’t successful software delivery — it’s to collaborate in the delivery of successful business change.

One at a time:

When you buy commercial software, the tasks that remain are to adapt it to your enterprise and vice versa. That means process redesign for the business, configuration and customization of the software, and systems integration work. Sending any of this work offshore is an unnatural act, as the work is highly interactive and heavily dependent on the details of the situation. It’s on-site work, heavy on telephone calls and light on heads-down coding.

With componentized architectures, developers connect software modules that provide generalized business services to support business processes (yes, I’m oversimplifying, but for the purposes of this discussion it should be close enough). While the coding to create components might be accomplished by a global sourcing vendor, the use of the components is, again, light on coding and high on interactivity. Offshore? What’s the point?

Which brings us to adaptive methodologies. Whether you prefer XP or some other flavor, adaptive methodologies all embrace the idea of high interactivity, to the point of having business users looking over programmers’ shoulders during development. You could, I suppose, use NetMeeting to allow end-users to look over the virtual shoulders of third-shift programmers in Bangalore. But then, with enough effort you can make soy paste taste vaguely like hamburger (or so I’m told). That doesn’t make it a good idea.

Adaptive methodologies don’t achieve IT nirvana, though, because they’re still focused on software delivery. And software delivery is yesterday’s news. It used to define success for IT. Now it’s the ante that lets you into the real game: Changing the business.

The traditional methodology used to redesign business functions, business process re-engineering (BPR), closely resembles traditional IT “waterfall” methodologies (those that separate analysis, design and coding into separate sequential phases). Business re-designers figure things out, then let IT know what they need. This isn’t very different from having business analysts figure things out and then hand specifications to developers. Global sourcing can succeed with traditional BPR, because sequential methodologies with strong separation of function is their strong suit.

The problem is one we’ve known for at least twenty-five years but still pretend doesn’t exist: With waterfall methodologies you have to be right the first time, and nobody is ever right the first time. Business redesign succeeds best when it gets the initial elements of a new process into production and then continually improves it until it hums.

There are two ways to continually improve a business process. One is to assume the available tools are fixed and immutable — the machinery, work space, and information technology is what it is, and the process works within those limitations. With this assumption there’s no work to send offshore.

The other assumption is that everything is up for grabs — process flow, work space, information technology, training, and even product design. With this assumption the last thing in the world a business should do is to send the IT part of continuous process improvement half a world away. The proper solution is, in fact, the exact opposite:

Move programmers out of IT and into the business area where they can participate in the work.

Comments