Mind the Gap: State of the Art vs. State of the Industry

If you’ve ever been on a subway, you’ve probably seen or heard “mind the gap.” It’s a reminder that there’s a gap between the train car and the platform – and you want to make sure you’re paying attention to it. It’s a reminder that there is supposed to be a gap. It exists for a reason, but, at the same time, there’s a risk to the gap that must be managed.

I’ve been an IT consultant for nearly three decades. A lot has changed, but there are some patterns that have remained the same. When I first started, it was the PC under someone’s desk that was the server for the entire organization and the Paradox database that kept the entire place running. Today, it’s the “green screen” application that hasn’t been updated. It’s the forms technology that hasn’t been updated yet. (See Using InfoPath Today (Not Just Say “No”) for more.)

There’s always a gap between the state of the art and state of the industry. The state of the art is the absolute best, while the state of the industry is where most people are. It may be state of the art to have responsive websites, but most internal corporate applications don’t meet this standard. Many corporate systems require a specific browser, because they were built with the quirks of that browser in mind. They don’t display well on a tablet, much less a phone.

The state of the art exists to pull people forward, so we build systems that are more effective. “More effective” may mean more secure, more accessible, more scalable, or some other desirable characteristic we expect will make things better in the future. We’re hearing a lot about artificial intelligence and how it will revolutionize the things we do.

It seems like many of the folks I meet are ashamed of the gap. They have the expectation that they must be at state of the art or they’re not doing their jobs. State of the art is necessarily supposed to be ahead of where everyone is. If it’s not, we’re not moving forward. Despite this reality, we somehow feel ashamed that our systems aren’t state of the art.

The truth of the matter is that state of the art is expensive. It’s expensive both because the costs are higher and because there are sometimes missteps, which you’ll never have to take if you’re not on the “bleeding edge.” The leading edge of state of the art has been nicknamed such because of the tendency to get cut up when there’s a rapid shift in where it’s going.

For instance, for a while, if you wanted to be cool doing web work, you were encouraged to use Silverlight. Then Microsoft announced that it was discontinuing support for Silverlight. If you had an investment in Silverlight, your investment was wasted. (There’s an argument to be made that the core XAML lives on – and it does, but it’s not the same.)

There are countless dead ends when you’re trying to remain state of the art. All those dead ends cost time and money – and it’s caused more than a few people to lose their jobs when they made the wrong bet.

Many wise people insist on staying behind the bleeding edge and only doing a technology when it’s proven effective. They may miss out on being case studies for vendors, but they typically enjoy lower overall costs and fewer sleepless nights.

The question then becomes how soon you should upgrade systems. Unfortunately, the answer gets murkier here. Consider the “green screen” application. If it’s on a mainframe, it’s running on 3270 terminal emulation. If you followed the trend, you would have bought a mini-computer and migrated to VT 100 (RISC) or 5250 (AS/400, now called iSeries) emulation. From there, you would have built a client-server architecture application that could have run on a local area network. More recently, you’d build responsive websites and applications that run on phones and tablets as well as desktop PCs.

To be sure, there’s a cost to maintaining an old system, from maintenance costs, to keeping expertise, productivity issues with users, and even the reputation of the organization. However, do these costs outweigh the cost to convert the system three times just for the sake of keeping up with the state of the art? It’s not that clear.

Car Replacement

Some people I know feel compelled to have a new car all the time. The true believers work in the automotive industry. They may sell software to dealerships. They may work at a dealership. They may work for the manufacturer. In any case, their involvement in the industry means they must have a new car.

The second tier of people who feel like a new car is a necessity are sales folks. Having a new car implies success to their prospects, or so the theory goes. I’ve literally had friends in sales told they needed to get a new car. Some of them get a stipend for their car – and some don’t.

If you’re not in either of these two categories, you get to choose how frequently you get a new car. Sure, everyone likes the thought of getting a new car – but not necessarily the cost. This awareness of the cost keeps them from buying a new car every year. Whether you choose to buy a new car after your loan for the previous car is paid off or you decide to keep the car until “the wheels fall off” is personal decision.

Some people don’t like having a car payment and are willing to put up with larger repair bills while the vehicle is relatively reliable. Others have car payments in their budgets and simply maintain a car payment perpetually. For those that run their cars until they fail, they know there are risks to the approach. They know, at any time, they may have to go out and get a new car with little notice – but that’s acceptable for the savings. They know they may have a problem with their car that will transition it from relatively reliable to unreliable, but that’s OK, because it’s not that hard to get a temporary solution for transportation.

Cost, Risk, and Reward

It all comes down to a math problem:

(Cost to operate existing system + risk to operate existing system) – (cost to operate new system + risk to operate new system) = savings

When the savings becomes larger than the transition cost, it’s time to make the change. The problem is that most of these variables aren’t well known. They must be estimated. Typically, the costs are estimated over a year so that there’s some stability in the numbers, and momentary concerns or costs are averaged out.

The cost to operate the existing system has components that are easy. Any maintenance fees, utilities, space, etc., can be estimated. However, the big cost to operating a legacy system is the productivity cost of the users. Over time, these numbers really add up, as labor is the most expensive cost in most organizations.

The risk of operating the existing system isn’t particularly hard to arrive at – but converting that into a number is often resisted. A simple way to approach this is to evaluate the probability (or frequency, if it occurs regularly) of a risk and then the estimated impact. These are multiplied together to establish the cost of a risk. You do this for each of the risks of operating the legacy system and then add them together. The result is the risk cost for operating the legacy system.

Similarly, the cost to operate the new system isn’t known but can be estimated. The risks for the new system are often like those of the legacy system. but the expected probabilities are lower. These are added and totaled.

The final step is the return on investment. That is, comparing the cost to change and seeing how many years (or months) it will take to recoup the investment in the transition. Organizations typically prioritize the projects that will require the least amount of capital to complete and have the shortest payback period and therefore the best return on investment.

There’s one exception to this math problem.

Must Have

Sometimes, replacement becomes mandatory not because the old system is no longer functioning but instead because it no longer meets the needs of the organization. Whether it’s new markets or new ways of operating the business, there are times when the business changes, and it drives the change in the technology systems that support the business.

Invariably, these cause a ripple effect that delay other projects from getting upgraded, but that’s a problem for after the must have changes are done.

Indy CIO Network Lunch: Collaboration

Collaboration means working together towards a common goal. However, what does that mean in the context of IT at an organization? How can CIOs foster collaboration, and what’s the role of tools? That was the topic of discussion at a recent Indy CIO Network lunch. Everyone in the room makes investments to collaborate. Their attendance demonstrates that, since the group gathers to network and collaborate with other CIOs to improve their ability to support their organizations.

Though our conversation drifted past various collaboration tools, most of the time was spent speaking of the larger factors that influence collaboration. While collaboration vendors want you to believe that their brand of solution causes collaboration once deployed, it’s closer to say that tools can remove barriers and enable collaboration – if your organization wants to do it.

Culture

Most corporate cultures may belong in a petri dish, but we’ve all got one – whether it’s bad or not. From the smallest organization to the largest, every company has a culture. That culture dictates how the organization will respond. Organizations themselves resist change. They’re designed as a stabilizing influence, and that influence means whatever has been the rule is likely to stay the rule unless someone can break the inertia.

Organizational culture comes from the people and the processes. The people you have in an organization have a way of approaching things. They have their feelings of safety and of fear. If collaboration conflicts with someone’s basic desires, it will be very hard to accomplish collaboration – unless and until you change the people. However, people are only half the battle. The other side is the processes, the rules – both written and unwritten – inside the organization about how it works.

Organizations that have a stack-rank approach to employee performance, which rewards the top performers and “releases” the lowest performers, will find that collaboration won’t blossom, because the workers inside of a department are effectively pitted against one another. While some coalitions may develop where groups of employees work together – and against others – for the most part, a structure of constant conflict will stamp out collaboration and prevent it from taking root.

Trust

At some level, it’s a matter of trust. Trust that you and your colleagues are really working towards a common goal. Trust that if you help them, it won’t hurt you – and that they’ll return the favor. Organizations where trust is broken find it difficult to generate widespread collaboration, because there’s no belief that in the end it will be beneficial to them – and everyone else.

Being vulnerable in a group of others requires a perception of safety. The perception of safety comes both from the individual’s experiences and from the experiences they’ve had at the organization. The safer the environment seems, the more vulnerable – and therefore collaborative – that they can be.

Of course, just being safe doesn’t mean that they’re bought into the mission.

Ownership

The topic of how to generate ownership in the idea of collaboration resonated with the group, as they sought ways to help build buy-in across all levels of the organization to really work together – rather than to defend territories. Building that ownership revolves around helping everyone realize the importance of collaboration, both to the organization and, more importantly, to each person individually.

Barriers

Even with the right levels of trust and ownership, there are sometimes things that get in the way of collaboration. A lack of clarity on what is expected and desired as well as a very hierarchical and rigid structure leads to barriers to collaboration that are hard to knock down.

Communicating Clarity

One of the hardest problems when a new initiative is started is the lack of an expectation about what it should be like. When faced with a lack of clarity, most people freeze. If you don’t know how to use the collaboration tool, most will simply not use it. How to use something is very contextual and tacit. It’s hard for someone to know how to use the new tool until they’ve done it.

Organizations can communicate clearly what the expectations are with regard to collaboration, including which tools to use for what, and why. The communication needs to be in the context of the person and how it impacts their world and what is expected of them. It also needs to be multi-channel, as all of us are overwhelmed and may miss communications provided in a single channel.

Mindset

The other key barrier is mindset. When we think only of our own situation and our ability to keep our own job, we’re necessarily unable to work collaboratively for the greater good. We simply can’t see the forest when we’re worried about saving our own tree.

The effects of fear and stress on creativity and collaboration are well documented. If everyone is afraid or stressed out in their work with others at the organization, collaboration just won’t form. Conflict has a negating effect on collaboration.

The Role of Conflict

We spoke briefly about the conflict that arises between two groups even inside the technology organization. We spoke of the developers who are goaled on new features and the operations folks who are goaled on uptime. Whether these goals are explicitly stated or are simply a part of the individual’s expectations, this difference in goals creates a conflict.

Organizations try to eliminate this by providing explicit goals that are around revenue – larger goals – than individual expectations about their goals. However, these internal goals still hold. They believe that the best path to revenue is through increased features – or improved uptime. There’s a persistent pull towards individual goals that can be influenced or controlled within the group.

The real work of a CIO – in their department – is to continuously realign employees towards the work of delivering value to the organization and understanding that they’re all a part of that. To make bread, you need flour, water, salt, eggs, and yeast. If you leave an ingredient out, the bread doesn’t work – it takes everyone in the organization to be able to support the organization.

Tools

It’s difficult to have a conversation like this in a room full of problem solvers with great experience without descending into what tools are effective for different kinds of collaboration. Despite the occasional mention of tools, for the most part, we spent our time speaking of the business challenges and how we change the way we approach collaboration – more than just adding another collaboration tool.

Author’s Notes

While this summarizes our conversation, I’ve editorialized a few things and tried to make some concepts more explicit than someone listening might have heard through the conversation – thus, the perspectives here are mine but are thoughtfully informed by the 20 or so attendees.

I’d like to suggest some resources for more information about the topics that are related here:

• Trust => Vulnerability => Intimacy – for the role of trust, safety, and vulnerability.
• Collaboration – for a definition of collaboration and tips for management.
• Collaborative Intelligence – for a solid definition of collaboration and how to measure effectiveness.
• Demand – for a discussion of barriers and their disproportional impact they can have.
• Trust: Human Nature and the Reconstitution of Social Order – for a comprehensive understanding of the impacts of trust.

Effective IT Steering Committees

A board of directors for an organization can be a liability – or they can be a serious asset. They can connect the organization to other organizations. They can bring insight into the organization and steer the organization away from potential disasters. A strong IT steering committee can do the same for an IT organization. However, getting a steering committee to be effective isn’t as easy as it sounds. The Indy CIO Network tackled the challenge of effective steering committees at the May 2017 meeting, and here’s what the group said (from my point of view).

Steering or Status

Getting the appropriate people involved in the steering committee is essential. If you don’t get anyone engaged, the meetings become little (or nothing) more than IT reporting status on its projects. It becomes a monologue of what IT thinks should be done, with passive listeners yawning, writing notes, or answering emails from their phone.

An effective steering committee isn’t getting status updates from their IT team members, it’s participating in an active discussion by asking questions – including questions that are sometimes difficult and uncomfortable. That’s the value of a steering committee. Just like a board of directors, it’s important for the CIO to get pushed out of their comfort zone – in a generative and safe way.

Looking for Trouble

If you’ve ever had kids, there are times you know that they’re just looking for trouble. They’re trying to get in trouble – generally for inexplicable reasons. However, good IT organizations aren’t looking to create trouble as our children sometimes are, they’re looking to find trouble before it becomes something bigger.

Like going to the mechanic when the check engine light comes on in the car instead of ignoring it, steering committees can provide valuable diagnostic information about how the IT organization is doing. While the feedback may not always feel good, it’s much better to solve a problem when it’s small and can be easily addressed than when it’s become a systemic problem that’s taken hold.

Sometimes trouble comes in the form of the opposite problem from the disengaged steering committee that won’t interact. It comes in the form of another master that the CIO must serve.

Too Many Masters

Sometimes the steering committee puffs up and becomes another master for the CIO to serve. Instead of advising, informing, and suggesting, the committee tries to assert its power to instruct – rather than guide – the CIO in what needs to be done. Many a CEO has had to manage this with a board of directors. On the one hand, the board of directors in an organization is the ultimate authority, but on the other, they’re only effective when they allow the CEO to make the calls they need to make and only intervene when it is appropriate.

IT steering committees don’t have the power of a board of directors, but even so they try to assert a level of control that would be inappropriate. Here the CIO must acknowledge the feedback but ultimately explain that the steering committee’s recommendations aren’t the final word. Ultimately the CIO reports to the CEO, not the steering committee.

In the end, the effective steering committee is like a board of directors in that it supports the CIO and the IT mission out to the organization. They’re bought in like a board of directors is when it has invested in the success of the organization.

Buy In

While the feedback and advice from the steering committee is valuable, the real value is in helping to build buy-in for the priorities of IT – and that not everything can be a priority. Building the buy-in that IT only has so many resources, and that those resources need to be allocated to the business areas based on need, is an important step to building sustainable relationships between IT and the business.

In a strange twist of fate, one business division thought that the CIO was trying to dictate their priorities with the steering committee. When the word “priorities” was swapped out for “capacity management,” the division leader joined in the conversation to make sure that IT knew about their needs and how IT could help.

Partners

When you can get the right people in the organization on the IT steering committee, the whole tenor of the conversations can change. Instead of IT being an order taker from the business – or dictating what the organization can and can’t do – IT becomes a key enabler for the business. Few IT organizations really dictate what the organization can and can’t do – but it can feel this way at times when IT conveys what it can and can’t support.

When the IT organization is already seen as a partner, there may not be a need for a steering committee.

Alternative Steering

Sometimes a steering committee isn’t even a steering committee. In effective organizations, the feedback needed to guide the IT department comes in the form of an agenda item for existing operational and strategic meetings. There’s no need to have something separate for IT if it can fit into the existing organizational management approaches.

It’s not that these CIOs get a free pass to do anything they want – or at least avoid getting feedback. It’s that the feedback they get comes directly as a part of normal operations rather than needing yet another meeting. This level of integration is healthy inoculation against “shadow” IT.

Shadow IT

In most large organizations, there’s some level of information technology work going on outside the IT department. Some level of this is right and appropriate. The business hires technically savvy people and they handle some of their own problems. It creates challenges, however, when these technically savvy people don’t work with centralized IT. That is, instead of viewing central IT as the partners that provide the core services that the business unit IT needs, they see centralized IT as a competitor, an enemy, or an impediment.

When the business and IT are in partnership, there’s no need to be competitive. IT does some core functions and business unit IT builds on those platforms. When there’s a solution to be created, or purchased for the business unit, all the parties sit down at the table and find the best solution for the organization. One of the best ways to do this is to align the mission and values.

Mission and Values

Almost every organization has a corporate mission statement. Whether it’s posted on the walls or buried in the employee handbook, it’s there. However, very few organizations live out their mission and values. Very few are able to build partnerships based on a shared understanding of what the organization is on this Earth to do – and not to do.

Powerful organizations build coalitions based on the idea that we’re all in this together, and so there’s no need for competition. Once there’s a mission and values in place, it’s possible to create a roadmap that’s effective for everyone.

Roadmap

IT, like the rest of the organization, can’t be all things to all people. There are fixed resources, and therefore a fixed capacity for new projects. By establishing a roadmap – and getting steering committee buy in – the friction is shifted from the gap between IT and the business to the gap between different areas of the business. By establishing a roadmap, everyone knows when their projects will get done – and what is ahead of them in line. Instead of arguing with IT about getting a better position, they can negotiate with other business units to get a better spot on the roadmap.

They can also become advocates for additional IT capacity so that their projects can be done sooner. By allowing the business to drive the roadmap, there’s the ability to have the business itself be champions for temporary or permanent changes in funding.

The challenge with this roadmap process is that sometimes it leaves internal cost optimization projects in IT under-appreciated and under-funded.

Managing the Mix

Every IT budget includes operational line items and developmental line items. The operational line items change when you implement cost reduction programs, switch vendors, or find a better way to buy the resource. However, all of these are projects that – if IT doesn’t get an appropriate voice at, the steering committee will die – can represent real cost savings to the organization over the long term.

Managing the mix of operational costs, investments in new solutions, and investments in cost optimization is a real challenge. If you optimize costs, you’re not delivering new functionality to the business. If you’re always focused on getting the business features, then you’ll have high operating costs. The reality is the mix of projects is dictated by the organization and what it needs to keep IT effective.

In the end, the steering committee is designed to help surface the business and IT operational issues in a way that the entire committee can design a roadmap that everyone can live with. If you can get that, then you know you’ve got an effective IT steering committee.

IT as the Catalyst for Organizational Change

In the April 2017 lunch meeting for the Indy CIO Network, we took up the topic of organizational change and how IT often gets thrust into the position of being organizational change agents with neither support nor training. However, instead of lamenting about the position we’re in, we discussed ways for our organizations and our IT organizations to be successful.

Not an IT Project, a Change Project

By far the most challenging issue we confronted was the idea that many organizational change projects are running around like a wolf in sheep’s clothing. Projects to upgrade systems or install new systems are often times moved to change the way the organization operates; but despite efforts to the contrary, the projects often get labeled with the name of the new system or version of the system.

The easy and tangible part of the system – the technology – becomes the moniker for the entire effort. As a result, people think that this is an IT project to change technology when that may be an afterthought or just the result of changing the business.

The need to clearly articulate the “real” project isn’t enough. This is a people problem, where everyone needs to hear in tangible terms how things will change and what it will mean to them.

80% People

Organizational change initiatives do have a technology component, however, that technology component of the project may only represent 20% of the overall work of the project. After all, changing the technology is the easy part. The hard part is changing people. Murry Gell-Mann once said “Think how hard physics would be if particles could think.” Instead of following the straightforward rules of ones and zeros they would be free to make up their own minds – just like people are.

People’s feelings aren’t even just a factor in their behavior. They’re THE factor. We like to believe that we’re rational decision makers but, as Gary Klein points out in Sources of Power, we make recognition-primed decisions – not rational ones. The Happiness Hypothesis (and Switch) take this further to speak of Jonathan Haidt’s model of the Rider-Elephant-Path. In this, our rationality is sitting on top of a massive elephant that is really in control. Thinking, Fast and Slow and Incognito both point out that our emotions – or System 1 – can lie to our rational selves. Whatever the lies are, they’re always lies about how change will impact us personally.

WIII-FM

What Is In It For Me (WIII-FM) is everyone’s favorite radio station. It’s the radio station that plays in our head all the time. We’re always considering what we’re experiencing based on the idea that it may – or may not – impact us. So whatever change we propose to the organization, we have to remember that it has impact to people – and that impact to people will always be personal.

In a discussion about a mainframe elimination project, we asserted that we had to be honest that there were some jobs that were going to go away. Because even though the truth is hard, it is the truth that everyone knows. By sugar-coating the message, we run the risk of eroding trust – and it’s trust that is the lubricant to getting change done.

The Lubrication of Trust

One of the reasons that organizational change initiatives fail is that there is a growing lack of trust. John Kotter, a Harvard professor emeritus says that about 70% of organizational change projects fail. (See Leading Change and The Heart of Change.) At least some of that is due to the lack of trust that an organization’s employee has for the organization and it’s getting worse. America’s Generations reports that, starting at Generation X, there has been a building skepticism towards large organizations.

Trust: Human Nature and the Reconstitution of Social Order spends a great deal of time exploring the impact of trust on organizations and nations – including how trust in one area can reduce trust in another area. Trust lubricates an economy and an organization by reducing the amount of effort that must be put into protecting ourselves.

Building Trust and Making Change Work

Rebuilding trust and making change work function in the same way. You build trust by making and meeting small commitments until you can make larger ones. In the same way, we make changes by breaking them down into small, incremental steps so that they don’t seem daunting.

While leadership maybe thoroughly entrenched in the vision of the future, the everyday worker in the organization lives in the world of now. Without a path between the now and the future, they’ll keep doing what they’re doing – or worse, they’ll freeze. Often, we get into the valley of despair in a change, when productivity is low and things aren’t quite working yet, and people freeze and end up not able to move forward to accomplish the productivity that everyone wants.

In the end, we need our business leaders to join us – and lead the charge – in changing the organization. IT can be the catalyst, but the business has to start the reaction to change.

What’s Your Cloud Strategy?

I love learning how people come from different places based on their perspectives. The March 2017 meeting of the Indy CIO Network took up the topic of cloud strategy and the conversation was remarkable.

What Kind of Cloud?

As a pilot, I was trained to identify different kinds of clouds so that I could avoid getting caught in weather that either the pilot (me) or the plane couldn’t handle. I came to appreciate the number of different kinds of cloud formations there were and how knowing what they were could keep me safe.

When we’re talking about technology clouds, there are a few options:

• Infrastructure as a Service (Iaas) – Virtualized machines that you can manage as if they are on premises.
• Platform as a Service (Paas) – Containers that you can deploy your solutions into to take advantage of larger data centers and other resources that may not be practical to deploy yourself.
• Software as a Service (SaaS) – A software package licensed with hosting of the application included. This bypasses the hidden maintenance costs of running a server and managing a software package.

With flying, the challenge was always safety; with the technical cloud, it comes down to security.

Security – Better or Worse

On the one hand the availability of cloud-hosted resources would seem to have a worse security profile than something locked away in our respective data centers. After all, availability and security have been natural-born enemies since the beginning of time. It intuitively makes sense that if it’s more available then it’s got to be less secure.

On the other hand, the cloud service vendors generally have better resources than a small- or even medium-sized company might have to purchase intrusion detection and pay security analysts to continuously monitor what’s happening on the systems. So they’re a bigger target in aggregate, but they’re also bringing substantially more resources to bear than we could if we had the services in our network.

From a practical point of view, the surface area – or availability – isn’t all that different between a server hosted in the cloud platform vs. one that’s on your local network. Most organizations recognize the need for employees to work while traveling. As a result, virtual private networks (VPNs) have become common, so most employees really have availability to get to information no matter where they are on the planet – or in the air.

In the end, the kind of security technology being deployed and the rigor of the security policies – including checks and balances – generally means that cloud-hosted systems are more secure, even if this seems at times to be counter-intuitive.

Goals

The group agreed that cloud hosting doesn’t save you direct costs – or at least not much. What the cloud services give you are features that you can’t afford to implement on your own. Whether it’s a service level agreement (SLA) that includes a lot of 9s or elasticity, cloud isn’t about cost savings. It’s about mindshare and capital savings.

In some scenarios, the goal is to increase uptime and geographic diversity to handle outages in a way that just isn’t practical to do internally.

Very High Availability

Some systems just can’t be down. The business cost of being down, both directly and in terms of the brand damage, are just not tolerable. Even when the primary operations are on your environment locally because of proximity or other needs, having the ability to switch to a cloud backup when you’re not able to service customers is essential.

While there are very high profile outages at Microsoft, Amazon, and others, these outages are, generally speaking, quite rare. The amount of redundancy that exists in their environments simply isn’t practical for the mid-sized organization to buy.

The Real Risk and Opportunity

It seems that the real risk and opportunity with developing a cloud strategy is scaring your IT professionals with not having a job. My observation, and those of some of my national peers, has been that it isn’t IT professionals losing their jobs – it’s that their jobs are changing to be more customer-focused and interactive.

So while the fear of being replaced is there, the real opportunity is for our IT staff to become more closely aligned and embedded in the organization, so that IT isn’t seen as something distant and far away, but is instead seen as a partner trying to help the business get things done.

Understanding Bimodal IT

Gartner’s model for bimodal IT has both its zealots and its detractors. However, as a CIO how does one cut through the noise and leverage an understanding of the model to help optimize IT operations in their organization? At this Indy CIO event, I shared a table with some CIOs and explored the concepts in bimodal IT while listening to our host’s perspective and checking in with the rest of the room periodically.

Join me for a quick synopsis of what we came to know about how IT has two modes, how to harness that, and where things can go awry.

A Tale of Two Modes

The two modes in the Gartner model are:

• Mode 1 – “Optimized for areas that are more predictable and well understood.”
  • Repeatability over Agility
  • Low Risk Tolerance
• Mode 2 – “Exploratory, experimenting to solve new problems and optimized for areas of uncertainty.”
  • Agility over Repeatability
  • High Risk Tolerance

The most common misconception was that everyone should want to move from Mode 1 to Mode 2 IT. Inherent in the Gartner model is that you should be using both modes of operation. That is, some of the functions inside of IT should be operating in Mode 1. Other functions inside of IT should be operating in Mode 2.

You can’t treat an exploratory area, like telemedicine, like you treat the core electronic medical record (EMR) system. In telemedicine, the need for rapid adaptation and velocity of change exceeds the need to not fail. For an EMR, you need repeatability and low probability of failure more than you need adaptability and velocity of change.

Managing the Mixture and Match

Managing effectively in a bimodal IT paradigm isn’t about which mode you’re operating in, but rather is assessing the mixture of areas where Mode 1 is optimal and those areas where Mode 2 is optimal – and aligning the way that you address them to the way that they are best handled. As one participant noted, it’s not that the bimodal model is really all that different from what we’ve done in IT for a long time, but it’s giving a language to the differences so that we can clearly articulate what we’re doing.

It gives us a shared language to speak about the fact that, in some areas, we’re going to tolerate failure, because the impact of failure is low and the need for adaptability or velocity of change is high. We aren’t going to “throw out the baby with the bathwater” and pick only one way of operating, we’re going to develop a ratio of delivery in our organization that matches the needs.

Beyond matching the mode to the area, there’s the need to match the mode to the person, so that their natural talents, behaviors, and dispositions align. We spoke of the challenge of small IT shops where individual contributors and managers may need to work on both Mode 1 and Mode 2 areas. We acknowledged that there are some behavior/psychological assessment models like DISC that can be effective at helping us identify which mode team members might be better at. Those with D or an I focus are more action-oriented and are more suited for Mode 2-type areas, where professionals who are more S- or C-focused have the diligence necessary to continue to advance Mode 1 areas.

Iterative and Agile

An area of confusion in our discussion was exactly what characterized Mode 2 activities and what characterized Mode 1. Despite Gartner’s definitions, it wasn’t always clear what Mode 2 was, though it was clear that it didn’t mean traditional agile development or DevOps or any of the new methodologies for development and continuous improvement.

In fact, we discovered that either mode could be delivered with either agile or traditional waterfall development. The secret seems to live in the iteration cycles. That is, the cycles of development, integration, testing, and deployment are happening faster in Mode 2 – where the cycle costs are lower. Mode 1 cycle costs are much higher due to the much more extensive testing cycles.

So it’s not that you have to pick a delivery approach based on Mode 1 or Mode 2 – it’s that you have to attenuate the cycle times based on the cost per cycle.

Preplanning, Waterfalls, and Staying Agile

Mode 1 is the hallmark of the traditional IT department, where the risks are well-known and are relatively large and the area itself is well-known. Operating a phone system, managing connectivity to the Internet, and managing mission critical systems fit in to this category. There’s the need to have a governance process that reduces the frequency of changes and improves the opportunity to catch errors before they reach the consumer.

In Mode 1 systems, there are many knowns, and so the relative degree of predictability is higher than in new and uncharted areas, where there aren’t established patterns for service delivery. Because of the greater degree of predictability, it’s possible to do better planning and structuring of Mode 1 systems. Mode 2 systems, by contrast, are generally chaotic and don’t follow established rules of how things should be done. Because of these Mode 2 characteristics, planning work and rules are generally less effective.

The velocity of iterations – whether you’re in a waterfall methodology or an agile methodology – is driven by the factors of ability to preplan, tolerance for risk and impact, and urgency of need. A low risk ofimpact tolerance slows cycle times and places a greater burden on each cycle to be “right.” This is convenient when it’s possible to predict and plan the operations – as in a well-established system. A low ability to preplan and a low degree of tolerance for risk and impact means that the costs will be high. This is particularly the case if there’s also an urgency of need.

Scenarios where there are a low (true) need for urgency, low risk and impact tolerance, and a high ability to preplan slow systems into Mode 1 operation. Increasing the tolerance for risk and impact – making failure ok – can move a system from a more Mode 1-like operation to more Mode 2-like operation. Even the “distinct” modes in the model aren’t distinct – they’re points on a continuum.

Our goal in IT is to continue to support responsiveness to the organization while balancing the needs of risk tolerance and impact avoidance. We classically have done that through breaking dependencies, minimizing coordination, and reducing batch sizes.

Breaking Dependencies

When you have complicated systems, you have complicated interactions between them. Systems with well-defined boundaries and contracts look like Lego building blocks. One system can be swapped out with another with minimal – if any – impact on the other systems in the organization. Unfortunately, this is rarely the case in practice, as organizations have connected systems in ad hoc ways. The need for standardization gave rise to the enterprise application integration (EAI) platforms in the 1990s. By defining the EAI or the even more grandiose services bus, the relationships between systems were supposed to be well-known.

Few organizations completed the massive work of deploying an EAI solution or a services bus before they ran out of energy. The work to plan for systems to be changed later and to optimize the interface between the systems was crushed by the realities of needing to deliver something to the organization today.

One of the CIOs I was talking to in this period told me that my project – a SharePoint Intranet project – was the only way that he could demonstrate any tangible value to his efforts for a services bus. For all the work he was doing breaking up dependencies, there was very little to show for it.

When the dependencies are reduced, it becomes possible to reduce the testing scope when you make changes to a system, and this substantially reduces the cost of delivering an update. The heart of reducing dependencies is defining the contracts between systems – whether you implement an EAI tool or not.

Minimizing Coordination

The three-legged race is a famous coordination problem. Friends, classmates, teammates, or members of the same group are paired. Two people each have one leg bound to the other’s. The result is a three-legged competitor. It’s amazingly hard to race in this configuration, as you realize the small differences between the way that you run and the way that the other person runs often leads to falling and tumbling over one another – rather than racing to the finish. This is the essence of the coordination problem.

In IT, we seek to minimize the coordination between systems so that we don’t have to take the cost of coordinating with other systems. Here, too, contracts are the answer. By contracting how the dependency and coordination should happen, you can identify those times when coordination will – and won’t – be necessary. This results in a lower cost of coordination and higher velocity.

Reducing Batch Sizes

Left to the pressures of low risk and impact tolerance, the natural bias of IT is to reduce the frequency that you cycle at. After all, you can absorb the extra testing costs if you only must do it once or maybe twice a year. However, this forgets that the business needs their changes now. To be responsive to the needs of the organization requires delivering more frequently. However, this is in conflict with the need to minimize risk and impact from changes.

Ultimately, this is pressure the CIO must apply to continue to maintain velocity while managing the risk.

Technical Debt

Sometimes the best way to improve velocity is to “buy down” debt. That is, to reduce the number of friction points which make it difficult to operate in shorter cycles. This might be improving the automated or unit testing coverage of an application to reduce the need for manual testing, or it can be retiring old systems which have high maintenance costs and are unnecessarily coupled to other systems.

“Technical debt”, the term often used to describe shortcuts which were taken but never properly addressed, can have a substantial impact on the velocity of the IT department.

Like Clockwork

Looking at a bimodal IT with slower-moving, more risk-sensitive projects and smaller, faster, less risk-sensitive projects is like clockwork. The pieces of the puzzle fit together and work together to provide a time-keeping instrument, even though not all the pieces move at the same speed. The use of different pieces for different needs, knowing where the gears will mesh, and accepting that some pieces will move fast and some will move slow if things are to work properly is like understanding how bimodal IT works. Some things should be Mode 1 and some things should be Mode 2.

Marketing Information Technology to the Organization

I recently had the opportunity to join the Indy CIO network as they meet each month to talk about issues facing CIOs. Recently the topic of marketing IT to the organization came up. It was a great conversation. What follows is one part notes from the meeting and one part my reflection on the conversation.

How IT is perceived in the organization is critical to its relationship to the rest of the organization. While it would be ideal if the organization would instinctively understand the value that IT can bring to the organization and view us that way, the reality is that it’s not that simple. It starts with the way that IT seeks to understand its broader context in the business.

Understanding the Business

If I had to pick one master theme that resonated through the statements of the members of this merry band, it would be that you must understand what’s important to the business. In my own world, I run into too many technologists that are in it for the technology. They want the cool toys and the shiny new objects. I’ll admit my own fascination with new toys (including the Microsoft HoloLens sitting on my desk for a project). However, I think that we sometimes get wrapped up into the newness of a SAN, a virtual environment, or a firewall and forget that none of these things matter to the business.

For most businesses, the IT function is a means to an end. FedEx doesn’t sell information technology, they sell information access to where your packages are. Starbucks isn’t selling their app, they’re not even selling coffee. They’re selling an experience. The organization doesn’t want an app. They want a way to increase the relationship with their customers.

Understanding that the goal is to enable and facilitate whatever the business does – and then learn what the business does – is critical to changing the relationship that IT has with the organization.

Taking Orders and Seats at the Table

It seems like some organizations have an IT function that is stuck in an order-taking mode. The business comes in the door complete with the solution they want, and it is IT’s job to deliver to that order. That’s quite obviously not the best place to be, since the business can’t know everything that the IT function knows. In this scenario, the organization isn’t valuing the experience and wisdom that the IT group is bringing to the table.

On the other end of the spectrum is a place at the table where the organization is defining new missions, objectives, and directions. Obviously, this is the spot that the CIO desires. It represents the business leadership’s respect for the CIO and the IT function. It means that the IT function can be prepared for impending organizational changes. However, few CIOs get this coveted seat at the table whether they are deserving of the honor and respect or not.

Along the path from order taker to table sitter are stops like being a problem solver, where the business comes and asks IT for a solution. In this case, the tables are reversed: IT comes up with the solution and offers it back to the business for acceptance. The problem is that this isn’t where you want to be, because it ultimately isn’t healthy for either IT or the business alone to create the solution.

A better approach is where the business and IT collaborate on a solution. The problem is laid out and the capabilities discussed. Solutions aren’t the domain of either the IT department or the business coming to them, the solutions emerge from the combination of perspectives and capabilities.

Earning your Seat

Strangely, you can’t get your seat at the table by asking for it. You can’t get your seat at the table, you earn it. You can’t earn your seat by helping with the direction, you have to earn it by nailing the fundamentals. Once you’ve resolved reliability issues, and reduced service times, and delivered projects successfully, then you can start to work your way into the position of earning your seat.

The skills that you need to be successful when you’re working with the organization as a valued partner in the business are strategy. The way to earn that position is in tactical operational execution excellence.

Spend Money to Make Money

Knowing the business means more than understanding the industry or even the organization’s niche within the industry. It means recognizing the personal preferences of the key leadership. Consider, for instance, the difference between an operational excellence-based leader who is interested in supporting the programs that reduce operational costs. Return on investment (ROI) is the mantra, and the projects that reduce operating costs are welcomed.

Conversely, in a sales-driven or innovation-driven company, operational excellence projects aren’t important. Saving on operational costs isn’t the name of the game, growing the top line revenue is. In those cases, IT organizations do well by positioning projects in terms of their potential to help grow the revenue of the organization, rather than how they’ll save the organization money.

It’s not that either approach is “right” or “wrong” – they’re just different.

IT Capacity Not Cost

Sometimes, the way to market IT to the organization is some subtle language shifts that drive a subtle change in view. In too many organizations, IT is viewed as an administrative department. As such, IT is overhead – a cost that reduces the profitability of the organization. Rarely is the IT department considered an IT function; even rarer is IT considered a capacity. Manufacturing organizations know that they have a maximum capacity for product production. Professional service organizations are aware that there are only so many hours in a day.

The capacity of the organization to leverage technology to reduce costs, increase throughput, and to improve customer satisfaction aren’t so easily measured. Shifting the language from department to function or cost to capacity may seem like something small and subtle, but these small changes can have profound results.

Marketing vs. Communication

At the end of our time together, it became clearer that the problem with IT wasn’t marketing; it was – and is – communication. We’re not trying to get the organization to buy IT, they’ve already done that. Our goal is to communicate the value that we are and can be delivering as an IT capacity so that the organization can better leverage the hard work that we’re doing.

We’re trying to connect to the rest of the organization through our communication, not persuade them to do something that may – or may not – be in their best interests.

We realized that sometimes the thing that CIOs don’t do is communicate the value of what they’re doing. But that has the potential to change.