Restructuring IT: Anticipatory Responsiveness Michael Milken, the former junk bond king, has a charitable foundation. His foundation did some research a few years ago that determined that 70% of 7 chronic illnesses - things like diabetes, heart disease, lung cancer and so forth - are preventable through lifestyle change. They concluded that if people took better lifestyle decisions, doctors could focus their energies on enhancing and improving the quality and duration of life. But they can’t, because people create so much “remediation work” for them to do through poor lifestyle choices.

This is an apt metaphor for IT. We do a lot of things, such as introduce situational complexity and technical debt, that pile on the work we have to do.

This is at the heart of what we have to pay attention to in our restructure from industry to profession: if we know that we are not doing things that make more work to be done, and if we also know that we are doing things that consistently result in quality outcomes, we’re much less likely to self-inflict more work.

Restructuring IT requires us have a different set of expectations. When we follow traditional restructuring led with org charts and budgets, we take behaviours for granted. We simply can’t. Like US policy on nuclear disarmament in the 1980’s, we must trust, but verify.

The good news is, behaviours are actionable. There are things we can do to bring about the right behaviours in an organization. The bad news is, this is vastly different from everything we’ve been taught about reorganization.

The purpose of this restructure isn't to assign people into roles, but to build an IT organization that is durably, anticipatorily responsive. That’s a mouthful. “Durable anticipatory responsiveness” is the extent to which we’re consistently able to do things that allow us to get things done – complete things, useful things, not just bit twiddling. But it isn’t enough to just “get things done.” We have to avoid launching any self targeted missiles, like creating high-maintenance code and therefore high cost assets. So being responsive means doing useful things, and it means not making work for ourselves.

The “anticipatory” bit means that we’re doing things that allow us to look ahead to figure quickly out where we’re at risk, or where we have an opportunity. Anticipation is important. We’re not simply waiting around for things to happen. That was how IT applied Rapid Application Development. We tried it in the 1980s, and it let us be better, faster, cheaper… pick any two. We need to anticipate. We need to get in front of things. So, dealing with whatever comes through the door isn’t enough; we also influence the business agenda in a meaningful fashion. That means positioning IT as a peer with the business, not in a power struggle with it or subservient to it.

To restructure this way, we have a model . We look at 10 practices, each decomposed into 6 stages, that allows us to assess a team, department or organization. Each practice is explained in sufficient detail to allow us to identify how a team gets things done today, how people behave. We recognize there are behaviours that inhibit responsiveness (“regressive” behaviours), and there are increasingly aligned behaviours. Especially in the early stages of restructure, we want to establish basic collaborative behaviours, because we’re creating new work patterns among people in a team. We're building “muscle memory” of how people in a cross-functional team must work together.

Fundamental collaborative behaviours cannot be taken for granted. I was working with a program team last year that had hundreds of people working in different technology silos, delivering a solution that impacted 4 distinct lines of business. Originally, they were spread out across the building. The only physical organization they had was by area of technology (client-side devs sat together, server-side devs sat together, QA sat on a completely different floor, etc.) So we organized people into line-of-business teams and co-located them in the same physical space. But changing physical layout wasn’t enough to change behaviours, because somewhere along the way people ended up working on missions divergent from that of "develop a software asset."

One example of this was that teams were in the "defect tracking" business more than they were in the "defect fixing" business. Following the relocation, QA analysts were sitting next to developers in the same team, but rather than talk to each other, developers and QA continued to work independently and communicate exclusively via the defect tracking tool. Defect reports, questions, "non-replicatable" and "ready for retest" and so forth we're all communicated via tracking tool. Not surprisingly, this led to re-opens, failed retests, questions, requests for additional documentation, and all kinds of other hand-offs. That not only made the remediation process inefficient, it created very long histories of defect tracking activity that were more noise than signal as a lot of the data captured was irrelevant to the actual problem.

Because it was more important to show effort as opposed to results, they weren't behaving as a team delivering a software asset, they were behaving as a team that needed to track details about defects. By asking people to collaborate on solving defects at time of discovery, we were able to make defect repairs available sooner. In fact, it wasn't unusual for a repair to be available in a build in less time than it took to submit an initial defect report. Getting into a state where this was the de facto behavior did not happen simply because people were physically co-located and had some collaboration tools. It required active intervention by management working directly with developers and QA solving specific problems in a collaborative manner.

Behaviour change is not a one-time action. Team circumstances change: people come and go, technology is upgraded, business needs change, etc. That means we must constantly pay attention to behaviours if they are to be durable. To do that, we can apply the model as often as we need - annually, quarterly or monthly - to ascertain whether people are making good "lifestyle" decisions." This allows us to assess the extent to which we are restructuring the fundamental organizational behaviours to focus on results as opposed to effort.

However, we must be careful. Competent assessment is a capability, not a task. Assessment is not done by questionnaire or checklist, and "objective self-assessment" - asking teams to critically analyze their own behavioural restructure - is most often wishful thinking. It requires an experienced touch to apply a combination of archeology and sociology to separate the opinion of how people aspire to work from the fact of how they are actually working. Creating a competent assessment capability requires investment, but it is critical to success as the assessments provide the telemetry of restructure.

We now know that to be a results-based organization, we must reorganize around behaviours. We have a good idea of what those behaviours are from an established model. We can use this model as both guide to and instrumentation of our restructure. But before we go off in pursuit of restructure, we must first internalize some guiding principles. We'll cover in the next installment of this series.

Labels: Change Management, IT Governance, Restructuring IT, Strategic IT

  ¶ 6:00 AM