STRUCTURING A WORLD-CLASS IT ORGANIZATION

STRUCTURING A WORLD-CLASS IT ORGANIZATION

Creating a world-class Information Technology department requires more than scrum masters, servers, tablets, software, IoT, artificial intelligence and the technology lingo of the day – Cloud, Bi-Modal, Containers, DevOps, Agile. All of these are useful and have a place. However, we often lean on these new technologies and technology fads so much that we tend to overlook the human element of IT. World-class IT departments understand how to employ the technical tools and innovations, as well as understand that people are the ones who employ the tools to innovate, optimize value chains and solve problems.

Elements of a World-Class Organization Model

There are four major elements to any discussion on organizations and people:

  • Structure – how we align within IT and interact with the lines of business
  • Leadership – the values and personality traits of the team that leads
  • Culture – expectations and acceptable behaviors of the team
  • Workforce – the talent and the management of our job families/positions, hiring, training and performance management

These four interact with each other to form the ecosystem of the organization. Individually, these can make a department good, but when aligned, they can make the department great. The greater their alignment, the more consistent and predictable the organizational outputs. Whereas misalignment results in employee and customer frustration, lost productivity and ultimately turnover within the IT department.

As Charlie wrote in one of his previous blogs, leadership matters most when it comes to organization and building a great team. However, structure, and its alignment with the other three aspects also matter. In this post, we’re focusing specifically on structure.

Structure: Architecting for Success

Any discussion on organizational structure must start with speaking the unspeakable; Most organizational structures are ultimately the result of compromise. No matter how ideally or perfectly the functions are decomposed, usually, the structure is sub-optimized to accommodate available leadership talent, spans & layers and “deals” made between leaders. That being said, there should be an Ideal State picture that describes the alignment of functions into organizational structures. Without a “go to” version, it’s easy to lose sight of what functions are required and to suffer from organizational drift and incrementalism.

IT functions and structures should be pragmatic and easy to understand for both employees and business teams. The structure should reflect what’s common and unique within IT and within the business. Quite a few organizations get overly concerned with debates about centralization vs. decentralization, but we’ve found that a more relevant conversation is describing functions in terms of common & unique. This allows for a different dialogue altogether.

Common vs. Unique: A Different Dialogue

What should be a “common function” in IT has evolved from 1960s to today. Early in the history of IT, computers were too expensive for any one department. Therefore, the enterprise took on the burden. The cost of the equipment, people and operation ensured that few machines were in the company and by default it was common. In the 1980s-1990s the explosion of inexpensive departmental and desktop computing made IT affordable and within reach of almost every business department. The affordability and diversity of choice led to more “uniqueness” in the infrastructure function. This same pattern has extended to various software components, such as database management systems, middleware/messaging, web, networking, etc. As companies have gone through these cycles, they’ve learned that more common is more affordable for acquisition and operations.

Today, there’s general acceptance that the infrastructure, middleware/messaging and database/data management should be a “common function” for most enterprises. This means that within IT, there’s one or more shared service groups that perform those. For practical and very real business reasons, some IT functions have stayed “unique,” specifically those functions that support autonomous business units in a holding company context or widely distributed and vastly different geographic units.

The Modern IT Organization

In the Modern Era, as we work to enable agility and adaptability into our businesses, this set of decisions about which business and technical capabilities are “common” and which ones are “unique” has become significantly more complex and more important. To get the Business Outcomes we want – typically things like seamless omnichannel customer experience, process and cost leverage, cross-functional growth programs, growth through acquisition and/or bundling of services and products across business units – we now see an even greater benefit to making more things more “common” across the enterprise. We also want architectural leverage and re-use, which are about the Architectural Outcomes that are there to create future Business Agility.

On the other hand, allowing the right degree of “unique” autonomy and customization or specialization by department, business unit and/or geography could also be critical to customer/market intimacy, efficient operations, quick market response/competitiveness and even executive accountability. These are difficult but important choices.

Aligning IT and Business

From an IT perspective, we’re not necessarily looking to mirror the business structure. Rather, we’re trying to organize, structure and shape decision rights aligned to portfolios of business solutions that are supported by cross-cutting enterprise shared services for high-leverage architectural functions, such as data, common services and infrastructure. This avoids fighting the business physics of funding models and decision rights.

While there are no perfect structures, IT should be organized in a way that gives the business transparency and clarity, in terms of simplified accountabilities and less bureaucracy, on who is fulfilling their technology solution needs. In addition, IT needs to be structured in a way that allows for the right things, not all things, to be architected and built “common” for leverage, re-use, integration and seamless customer and employee experiences – or whatever enterprise-wide objectives the business has.

Guidelines for Designing the IT Organization Structure

  • Start with a Clean Sheet – Don’t be encumbered with the current state. Instead, imagine the opportunity to start fresh.
  • Understand the “Business Physics” – Where are the P&Ls managed? Where are the major business decision rights?
  • Design for Leverage – Have an understanding of where you want to leverage technology, data and services, and then make sure they can be represented in the structure.
  • Be Practical – Complicated structures and “overspecialization” generally dictate complex work and “handoffs,” which often, institutionalizes more overhead, confusion and costs.

With that, it’s important to note that employees want this same level of clarity and structure so that overlapping functions and the associated frustrations are eliminated, or at least minimized. Working on assignments and solutions only to find out another group is doing the same thing is very frustrating, not to mention wasteful.

At the Feld Group Institute, we recognize that restructuring your organization can be quite the undertaking, and can often be overwhelming, especially to do it the right way. Whether it be through programs, workshops or consultations, we’re here to help you transform your organization’s structure to lead into the modern era.

Author: Mike Childress, Feld Group Affiliate
Connect with Mike on LinkedIn

 

Posted in: IT leadership, The Feld Group Institute

Leave a Comment (0) ↓

Leave a Comment

You must be logged in to post a comment.

Processing...
Thank you! Your subscription has been confirmed. You'll hear from us soon.
Join Our Mailing List
ErrorHere