A CIOs Guide to IT Organizational Transformation Part 1: Teams, Architecture, and Operations

I was talking to a friend recently who runs technology for a large company. He and his peers have been debating, “Are we a technology company or a transportation company?” We hear this question a lot from our clients, and while it can be provocative, we think a more helpful question is, “How long can we survive being a transportation company that’s not also great at technology?”  

That’s a critical question for many reasons: 

• Consumers are demanding more self-service, personalized experiences, and this trend has accelerated during the pandemic for services like mobile ordering and delivery.

• More of these experiences need to happen “at the edge”—i.e., in a store, in a vehicle, in the customer’s home.

• Security and privacy needs are evolving. For example, Apple is implementing privacy features that will change digital marketing and personalization strategies.

• Organizations are rethinking outsourcing strategies due to labor shortages and new regulatory requirements.

• Business models need to evolve quickly due to unexpected supply chain disruptions and labor shortages.

Companies that are great at technology can adapt to these and other challenges quickly (in days, not weeks or months), but it requires them to rethink their IT operating model. 

What Needs to Change to Achieve IT Organizational Transformation?

Technology companies like Uber and Facebook are purpose-built around data and digital. They created their technology and organization from the ground up to release new capabilities quickly, experiment, and kill the things that don’t work and scale the ones that do. 

While some leading industrial companies have successfully moved to a platform-based approach, many are still operating with traditional IT models organized around application tiers (i.e., teams for web front ends, back ends, database, infrastructure) and long-running projects that span multiple years. 

Large, global organizations cannot easily change their operating model overnight. They have existing businesses to protect, stakeholder groups outside of IT with teams, workflows, and budgets aligned to traditional ways of working, and legacy architectures that don’t easily adapt to modern engineering approaches. Not everyone needs to release at Google’s pace, but we can learn from their experience and apply those techniques to improve our organizations’ outcomes.

New product features need to be tested, piloted, and measured with a small group of users before scaling up, and large complex organizations also need to avoid the “big bang” approach to operational change.

Complex organizations should take an incremental, outcome-based approach to evolving their operating models across three key areas:

1. Teams: The way people interact with each other to achieve an outcome

• Create more cross-functional, stream-aligned teams.

• Operate independently from one another.

• Own the tech stack for their product.

• Build what customers need and don’t allow unnecessary customization or localization of the product by other teams or organizations.

• Work in small increments.

• Release to production without needing to coordinate or seek approval from other teams.

• Measure outcomes and work in build-measure-learn loops.

2. Architecture: How we design and build technology to meet the organization’s goals

• Create loosely coupled systems with clear domain boundaries.

• Enforce an API-first strategy.

• Balance holistic architecture with independent teams.

• Define a clear strategy for evolving legacy systems and evaluate what needs to change to achieve organizational goals.

• Allow architects to think globally, but act locally—hands on with the product teams.

• Enable fast, independent deployments.

3. Operations: How we deploy, run and maintain systems efficiently

• Provide infrastructure and automation to product teams “as a service”—no handoffs between dev and ops.

• Create infrastructure blueprints that minimize operational and security risks across all products.

• Enable rapid monitoring and alerting: As we deploy faster we need to quickly know when things go wrong and address.

• Define a clear incident response plan that minimizes down time and impacts to business operations.

How Do We Get Started on IT Organizational Transformation?

In this blog series, we will discuss how to make effective changes to the IT operating model across teams, architecture, and operations, and how to measure the progress in a clear, practical way. 

Perfection is not the goal; complex organizations will always have pockets of legacy. But their size and scale can be an advantage. With thousands of locations and millions of customer interactions in play, simple improvements to the technology operating model can have an outsized impact on business outcomes. If you have questions about how to start your own IT organizational transformation, reach out to our leaders at findoutmore@credera.com.

Interested in the rest of the series? Find parts two and three here:

• A CIO’s Guide to IT Organizational Transformation Part 2: Stream-Aligned Teams, Fracture Planes, and Reducing Cognitive Load

• A CIO’s Guide to IT Organizational Transformation Part 3: Architecture and the Role of Architects

• IT
• IT Consulting Firm
• IT Effectiveness
• IT Governance
• IT Project Management
• IT Strategy
• Technical Architecture
• Software Architect
• Transformational Change
• Business Transformation