What It Is: IT Operations provides “IT for IT”, the infrastructure to track, monitor, and manage operating performance across various dimensions, depending on the scale and complexity of the organization
Why It Matters: The more an IT organization scales in headcount and complexity, the more important it becomes to have a way to benchmark performance and enable operational excellence
Key Concepts
IT Ops is a support organization meant to promote effectiveness, not create bureaucracy
Ops should be centralized regardless of the IT operating model (functional, product-based, etc.)
For large-scale organizations, a federated IT Ops model is preferable for overall org effectiveness
Key Dimensions
Transparency
Without visibility, it is nearly impossible to promote excellence and operational improvement
Focus should be on critical, minimum metrics that enable governance and benchmarking
Metrics can span from a leadership IT scorecard to portfolio and delivery metrics
Governance, Compliance, and Risk Management
IT Ops doesn’t need to provide PMO services, but it should ensure they exist and are effective
Compliance capabilities can be everything from regulatory and SOX to cyber security and audit
Portfolio Management
IT Ops may not provide the services, but should ensure that transparency and governance exist
Capabilities can span demand generation and prioritization to monitoring and value realization
Workforce and Sourcing Strategy
IT Ops should monitor internal/external performance, utilization, and workforce composition
Financial Management
IT Ops should help benchmark value/cost across IT at a service level and identify improvements
Continuous Improvement
IT Ops should identify and track operational excellence opportunities on an ongoing basis
Part of ongoing improvement should be reviewing and ensuring efficacy of IT services overall
What It Is: IT Portfolio Management is the process whereby technology investments are prioritized, managed, and governed (from demand management through delivery) on an ongoing basis, in the interest of enabling business strategy, maximizing return, minimizing risk, and providing security and compliance.
Why It Matters: Organizations don’t have unlimited capacity in terms of people, funding, ability to adopt new solutions, etc. and ensuring investments is essential to maximizing value in relation to spend
Overall Concepts
Portfolio management is about leadership and business partnership first, and process second
Portfolio reviews should produce schedule changes, delivery engagement, or risk management
Understanding total cost of ownership and effective resource management are critical input
Performing named resource planning versus role-based is important for critical roles
Transparency and Governance
Provide visibility into demand, scope, value, complexity, critical resource needs
Monitor ongoing delivery to proactively address risk and maintain and adjust release calendar
Evaluate and report on value realization, adjust metrics on new demand to improve efficacy
Portfolio Allocation
Typically includes: Innovation, Business Projects, Modernization, Security, Compliance, Operate
Prioritization model balance local versus global efforts, short- and long-term value
Release Management
Have a structured release approach with deployment windows to reduce risk and ease adoption
Frontload the first half of the year to avoid excess resource availability issues near the holidays
Separate major and minor releases, maintenance, and experiments into defined release slots
Change Management
Manage a global view of deployments to avoid schedule conflicts and manage end user change
Maintain an end-user view of technology and consider integration to avoid being project-centric
Tools
Portfolio management tools should enable and support the process, never become the focus
Gather only critical data that is actionable, or it is administrative overhead and likely wasteful
What It Is: An overall IT Strategy sets direction for an organization, providing a framework for the services IT provides, along with key dimensions and objectives, with flexibility to evolve over time
Why It Matters: With the ever-increasing demand for innovation in a competitive, but cost-conscious environment, a thoughtful strategy accelerates results, reduces cost and risk, and enables sustainability
Key Concepts
Technology strategy always needs to be rooted in a business-enabling approach
It is tempting to over-index on one dimension (e.g., cost management) and sacrifice capability
Excellence in IT is rooted in having business aligned objectives, with a disciplined approach
This model is organized around five key dimensions, which should be defined and prioritized
A simple IT scorecard could be created using how business partners evaluate each dimension
This article focuses on delivering IT objectives, IT Excellence focuses on “how to operate” in IT
Key Dimensions
Innovate – Promote Competitive Advantage
Map to business goals, establish a disciplined innovation process aligned to architecture strategy
What It Is: Excellence is core to creating sustainable value through technology in any organization
Why It Matters: Technology advances so rapidly that most organizations can’t keep up. The balance of agility and discipline, speed and quality are essential to optimizing the value of IT at the right cost
Key Dimensions
Courageous Leadership
Excellence requires tenacity, agility, flexibility, risk appetite, humility, and discipline
Given leadership sets the tone and direction for everything else, this is critical to get right
Need to be an advocate, champion, and business partner, knowing when to say “no” if needed
Transformative Culture
Remaining competitive in a continually evolving world requires a culture that enables change
Culture is expressed in what people see as much or more than anything they hear in speeches
Core values need to be consistently demonstrated from leaders to individual contributors
Relentless Innovation
Consider what happens in the technology strategy if core solutions are obsolete in 18-24 months
Make disciplined innovation part of the ongoing portfolio strategy to maintain competitive edge
Plan for “urban” renewal so there is minimal need for large scale, disruptive modernization
Operating with Agility
Establish strong business partnerships to respond to changes in portfolio composition/priorities
Create a minimally invasive, highly transparent operating infrastructure to drive efficiencies
Leverage workforce and sourcing strategy to provide the right capabilities at the right cost
Framework-Centric Design
Leverage enterprise architecture to establish a connected enterprise of intelligent ecosystems
Develop standards to enable ongoing integration of best-of-breed technology capabilities
Integrate artificial intelligence in thoughtful ways that scale and provide sustainable value
Delivering at Speed
Create a disciplined and repeatable environment for delivering solutions that can scale
Design with architecture, quality, and security in mind, not as an afterthought
Understand that total cost of ownership is as important as speed-to-market most of the time
What It Is: Workforce and Sourcing Strategy is the long-term approach that an organization uses to provide the necessary skills, internal and external, to enable capabilities to deliver on business commitments and support the current and future technology footprint
Why It Matters: Having a deliberate and thoughtful strategy not only creates an agile and responsive workforce to meet ongoing and variable business demand, but also does so at the right cost. Where a defined strategy is not in place and being governed, there is very likely cost optimization opportunity
Key Concepts
Business and technology needs fluctuate. A strategy helps mitigate the cost impact of change
Leverage a competency model internally and externally to benchmark roles, capacity, and costs
Generally speaking, it’s better to align variable capacity to areas of variable demand
Benchmark internal cost of service against best-in-class providers, make adjustments as needed
Understand that not everything needs differentiated service, keep the lights on is valid in cases
Invest in areas where technology creates competitive advantage and IP, outsource elsewhere
Actively manage and govern talent development and performance to optimize productivity
Never assume HC = FTE. Used named resources for capacity planning of critical roles vs FTEs
Source where technology is emerging and immature to facilitate experiments and early learning
It is a reasonable strategy to engage partners in simplification efforts through mutual incentives
Never assume shifting sourcing to captives for arbitrage benefits is a 1:1 FTE exchange, it isn’t
Be mindful in how you manage overall tenure. Motivated inexperience introduces risk and cost
Leverage role-based capacity agreements to shift contract labor costs to a defined model
Scrutinize contracting heavily to avoid inflated cost. Convert or hire longer-term needs
Establish consistent contract language that aligns to service delivery roles and expectations
Define primary and secondary partners for individual sourcing needs, manage them consistently
Negotiate aggressively but fairly, “partnerships” produce more value than a “vendor” mentality
Benchmark and leverage consistent performance metrics across internal and external partners
Apply vendor management and governance processes to captives the same as external partners
Approach
Understand Current State – Benchmarking capacity by role across sources of staff, including cost
Determine What You Need – Evaluate business and industry trends, do the same for technology
Define Sourcing Approach – Identify critical skills to retain and source, and where to get them
Refine Talent Strategy – Clarify gaps between current and future IT staffing, skills and capacity
Develop Transition Plan – Plan change to talent pool and make explicit sourcing decisions
What It Is: With the advent of AI, the question ishow to integrate it effectively at an enterprise level. The long-term view should be a synthesis of applications, AI, and data, working in harmony, providing integrated capabilities that maximize effectiveness and productivity for the end users of technology
Why It Matters: Much like the .com era, there are lofty expectations of what AI can deliver without a fundamental strategy for how those capabilities will be integrated and leveraged at scale. Selecting the right approach that balances tactical gains with strategic infrastructure will be critical to optimizing and delivering differentiated value rapidly and consistently in a highly competitive business environment
Key Concepts
AI is a capability, not an end in itself. User-centered design is more important than ever
Resist the temptation to treat AI as a one-off and integrate it with existing portfolio processes
The end goal is to expose and harness all of an organization’s capabilities in a consistent way
Agentic solutions will become much more mainstream, along with orchestration of processes
The more agentic solutions become standard, the less application-specific front ends are needed
Natural language input will become common to reduce manual entry in various processes
We will shift from content via LLMs to optimizing processes and transactions via causal models
AI should help personalize solutions, reduce complexity, and improve productivity
Only a limited number of sidecar applications can be deployed before overwhelming end users
The less standardized the environment is, the longer it will take to achieve enterprise AI benefits
As with any transformation, don’t try to boil the ocean, have a strategy and migrate over time
Approach
Ensure architecture governance is in place quickly to avoid accruing significant technical debt
Design towards an enterprise architecture framework to enable rapid scaling and deployment
Migrate towards domain-based ecosystems to facilitate evolution and rapid scaling of capability
Enable rapid, disciplined, and governed experiments to explore tools and solution approaches
Place heavy emphasis on integration standards as a means to deploy new AI services with speed
Develop a conceptual “template” for how AI capabilities will be integrated to facilitate reuse
Organize AI services into insights (inform), agents (assist), and experts (benchmark, train, act)
Separate internal from package-provided AI services to provide agility and manage overall costs
Evaluate internal and external solutions by their ability to integrate services and enable agents
Reinforce data management and data governance processes to enable quality insights
Define roles and expectations for those in the organization who develop, use, and manage AI
What It Is: App Rationalization is the process of reducing redundancies that exist in an application portfolio in the interest of reducing complexity, cost of ownership, and improving speed-to-market.
Why It Matters: Organizations typically spend anywhere between 50-80% of their IT budget maintaining and supporting systems in place. That limits investment in innovation and competitive advantage.
Key Concepts
Understand that rationalization is more about change management than technology
Ensure there are healthy relationships in place and strong leadership support for the work
Focus in on critical areas of the portfolio that drive cost. Don’t boil the ocean
Don’t worry about creating the perfect infrastructure day one. Clean that up along the way
Start with how your business operates and simplify and standardize processes first
Align your future blueprint as cleanly to your desired operating footprint as possible
Consider your Artificial Intelligence (AI), cloud, and security strategies in the future vision
Simplification can come through reducing both unique applications and instances of applications
Address how systems will be supported and enhanced moving forward in your design
Explicitly include milestones for decommissioning in your roadmap. Don’t let that go undone
Expect the work to continually evolve and adapt. Plan for change and adjust responsively
Include rationalization as part of your ongoing portfolio strategy so it’s not a one-time event
Approach
Align – Obtain organizational support critical to defining vision, scope, and facilitating change
Understand – Gather an understanding of the current state and alignment to operations
Evaluate – Leverage something like the Gartner TIME model to evaluate portfolio quality and fit
Strategize – Develop a future state blueprint, CBA, and proposed changes to the environment
Socialize – Obtain feedback, iterate, clarify the vision, and finalize the initial roadmap
Mobilize – Launch first wave of delivery, realign ongoing work as required
Execute – Deliver on 30-, 60-, and 90-day goals, governing and adjusting the approach as you go
It ought to be easier (and cheaper) to run a business than this…
Complexity and higher than desirable operating cost are prevalent in most medium- to large-scale organizations. With that, generally some interest follows in exploring ways to reduce and simplify the technology footprint, to reduce ongoing expenses, mitigate risk and limit security exposure, and free up capital either to reinvest in more differentiated and value-added activity, or to contribute directly to the bottom line overall.
The challenge is really in trying to find the right approach to simplification that is analytically sound while providing insight at speed so you can get to the work and not spend more time “analyzing” than is required at any step of the process.
In starting to outline the content for this article, aside from identifying the steps in a rationalization process and working through a practical example to illustrate some scenarios that can occur, I also started noting some other, more intangible aspects to the work that have come up in my experience. When that list reached ten different dimensions, I realized that I needed to split what was intended to be a single article on this topic into two parts: one that addresses the process aspects of simplification and one that addresses the more intangible and organizational/change management-oriented dimensions. This piece is focused on the intangibles, because the environment in which you operate is critical to setting the stage for the work and ultimate results you achieve.
The Remainder of this Article…
The dimensions that came to mind fell into three broader categories, into which they are organized below, they are:
Leading and Managing Change
Guiding the Process and Setting Goals
Planning and Governance
For each dimension, I’ll try to provide some perspective on why it matters and some potential ideas to consider in the interest of addressing them in the context of a simplification effort overall.
Leading and Managing Change
At its core, simplification is a change management and transformational activity and needs to be approached as such. It is as much about managing the intangibles and maintaining healthy relationships as anything to do with the process you follow or opportunities you surface. Certainly, the structural aspects and the methodology matter, but without giving attention to the items below, likely you will have either some very rough sledding in execution, suboptimize your outcomes, or fail altogether. Said differently: the steps you follow are only part of the work, improving your operating environment is critically important.
Leadership and Culture Matter
Like anything else that corresponds to establishing excellence in technology, courageous leadership and an enabling culture are fundamental to a simplification activity. The entire premise associated with this work rests in change and, wherever change is required,there will be friction and resistance, and potentially significant resistance at that.
Some things to consider:
Putting the purpose and objective of the change front and center and reinforcing it often (likely reducing operating expense in the interest of improving profitability or freeing up capital for discretionary spending)
Working with a win-win mindset, looking for mutual advantage, building partnerships, listening with empathy, and seeking to enroll as many people in the cause as possible over time
Being laser-focused on impact, not solely on “delivery”, as the outcomes of the effort matter
Remaining resilient, humble (to the extent that there will be learnings along the way), and adaptable, working with key stakeholders to find the right balance between speed and value
It’s Not About the Process, It’s About Your Relationships
Much like portfolio management, it is easy to become overly focused on the process and data with simplification work and lose sight of the criticality of maintaining a healthy business/technology partnership. If IT has historically operated in an order taker mode, suggesting potentially significant changes to core business applications that involve training large numbers of end users (and the associated productivity losses and operating disruptions that come with that) may go nowhere, regardless of how analytically sound your process is.
Some things to consider:
Know and engage your customer. Different teams have different needs, strategies, priorities, risk tolerance, and so on
You can gather data and analyze your environment (to a degree) independent of your business partners, but they need to be equally invested in the vision and plan for it to be successful
Establishing a cadence, individually and collectively, with key stakeholders, aligned to the pace of the work, minimally to maintain a healthy, transparent, and open dialogue on objectives, opportunities, risks, and required inventions and support, is important
Be a Historian as Much as You are an Auditor
Back to the point above on improving the operating environment being as important as your process/ methodology, it is important to recognize something up front in the simplification process: you need to understand how you got where you are as part of the exercise, or you may end right back there as you try to make things “better”. It could be that complexity is a result of a sequence of acquisitions, a set of decentralized decisions without effective oversight or governance, functional or capability gaps in enterprise solutions being addressed at a “local” level, underlying culture or delivery issues, etc. Knowing the root causes matters.
As an example, I once saw a situation where two teams implemented different versions of the same application (in different configurations) purely because the technology leaders didn’t want to work with each other. The same application could’ve supported both organizations, but the decisions were made without enterprise-level governance, the operating complexity and TCO increased, and the subsequent cost to consolidate into a single instance was deemed “lower priority” than continuing work. While this is a very specific example, the point is that understanding how complexity is created can be very important in pivoting to a more streamlined environment.
Some things to consider:
As part of the inventory activity, look beyond pure data collection to having an opportunity to understand how the various portfolios of applications came about over time, the decisions that led to the complexity that exists, the pain points, and what is viewed as working well (and why)
Use the insights obtained to establish a set of criteria to consider in the formation of the vision and roadmap for the future so you have a sense whether the changes you’re making will be sustainable. These considerations could also help identify risks that could surface during implementation that could reintroduce the kind of complexity in place today
What Defines “Success”
Normally, a simplification strategy is based on a snapshot of a point in time, with an associated reduction in overall cost (or shift in overall spend distribution) and/assets (applications, data solutions, etc.). This is generally a good way to establish the case for change and desired outcome of the activity itself, but it doesn’t necessarily cover what is “different” about the future state beyond a couple core metrics. I would argue that it is also important to consider what I mentioned in the previous point, which is how the organization developed a complex footprint to begin with.
As an example, if complexity was caused by a rapid series of acquisitions, even if I do a good job of reducing or simplifying the footprint in place, if I continue to acquire new assets, I will end up right back where I was, with a higher operating cost than I’d like. In this case, part of your objective could be to have a more effective process for integrating acquisitions.
Some things to consider:
Beyond the financial and operating targets, identify any necessary process or organizational changes needed to facilitate sustainability of the environment overall
This could involve something as simple as reviewing enterprise-level governance processes, or more structural changes in how the underlying technology footprint is managed
Guiding the Process and Setting Goals
A Small Amount of Good Data is Considerably Better than a Lot of Bad
As with any business situation, it’s tempting to assume that having more data is automatically a good thing. In the case of maintaining an asset inventory, the larger and more diverse an organization is, the more difficult it is to maintain the data with any accuracy. To that end, I’m a very strong believer in maintaining as little information as possible, doing deep dives into detail only as required to support design-level work.
As an example, we could start the process by identifying functional redundancies (at a category/component level) and spend allocations within and across portfolios as a means to surface overall savings opportunity and target areas for further analysis. That requires a critical, minimum set of data, but at a reasonable level of administrative overhead. Once specific target areas are identified and prioritized, further data gathering in the interest of comparing different solutions, performing gap analyses, and identifying candidate future state solutions can be done as a separate process. This approach is prioritizing going broad (to Define opportunities) versus going deep (to Design the solution), and I would argue it is a much more effective and efficient way to go about simplification, especially if the underlying footprint has any level of volatility where the more detailed information will become outdated relatively quickly.
Some things to consider:
Prioritize a critical, minimum set of data (primary functions served by an application, associated TCO, level of criticality, businesses/operating units supported, etc.) to understand spend allocation in relation to the operating and technology footprint
Deep dive into more particulars (functional differences across similar systems within a given category) as part of a specific design activity downstream of opportunity identification
Be Greedy, But Realistic
The simplification process is generally going to be iterative in nature, insofar as there may be a conceptual target for complexity and spend reduction/reallocation at the outset, some analysis is performed, the data provides insight on what is possible, the targets are adjusted, further analysis or implementation is performed, the picture is further refined, and so on.
In general, my experience is that there are always going to be issues in what you can practically pursue, and therefore, it is a good idea to overshoot your targets. By this, I mean that we should strive to identify more than our original savings goals because if we limit the level of opportunities we identify to a preconceived goal or target, we may either suboptimize the business outcome if things go well, or fall short of expectations in the event we are able to pursue only a subset of what is originally identified for various business, technology, or implementation-related issues.
Some things to consider:
Review opportunities, asking what would be different if you could only pursue smaller, incremental efforts, had a target that was twice what you’ve identified, could start from scratch and completely redefine your footprint with an “optimal case” in mind… and consider what, if anything would change about your scope and approach
Planning and Governance
Approach Matters
Part of the challenge with simplification is knowing where to begin. Do you cover all of the footprint, the fringe (lower priority assets), the higher cost/core systems? The larger an organization is, the more important it is to target the right opportunities quickly in your approach and not try to boil the ocean. That generally doesn’t work.
I would argue that the primary question to understand in terms of targeting a starting point is where you are overall from a business standpoint. The first iteration of any new process tends to generate learnings and improvements, so there will be more disruption than expected the first time you execute the process end-to-end. To that point, if there is a significant amount of business risk to making widespread, foundational changes, it may make sense to start on lower risk, clean up type activities on non-core/supporting applications (e.g., Treasury, Tax, EH&S, etc.) by comparison with core solutions (like an ERP, MES, Underwriting, Policy Admin, etc.). On the other hand, if simplification is meant to help streamline core processes, enable speed-to-market and competitive advantage, or some form of business growth, it could be that focusing on core platforms first is the right approach to take.
The point is that the approach should not be developed independent of the overall business environment and strategy, they need to align with each other.
Some things to consider:
As part of the application portfolio analysis, understand the business criticality of each application, level of planned changes and enhancements, how those enable upcoming strategic business goals, etc.
Consider how the roadmap will enable business outcomes over time; whether that is ideally a slow, build process of incremental gains, or more of a big bets, high impact changes that materially affect business value and IT spend
Accuracy is More Important Than Precision
This point may seem to contradict what I wrote earlier in terms of having a smaller amount of good data, but the point here is that it’s important to acknowledge in a transformation effort that there is a directly proportional relationship between the degree of change involved in the effort and the associated level of uncertainty in the eventual outcome. Said differently: the more you change, the less you can predict the result with any precision.
This is true because there is a limited level of data generally available in terms of the operating impact of changes to people, process, and technology. Consequently, the more you change in terms of one or more of those elements, your ability to predict the exact outcome from a metrics standpoint (beyond a more anecdotal/conceptual level) will be limited. In line with the concepts that I shared in the recent “Intelligent Enterprise 2.0” series, with orchestration and AI, I believe we can gather, analyze, and leverage a greater base of this kind of data, but the infrastructure to do this largely doesn’t exist in most organizations I’ve seen today.
Some things to consider:
Be mindful not to “overanalyze” the impact of process changes up front in the simplification effort. The business case will generally be based on the overall reduction in assets/ complexity, changes in TCO, and shifts (or reductions) in staffing levels from the current state
It is very difficult to predict the end state when a large number of applications are transitioned as part of a simplification program, so allow for a degree of contingency in the planning process (in schedule and finances) rather than spending time. Some things that may not appear critical generally will reveal themselves to be only in implementation, some applications that you believe you can decommission will remain for a host of reasons, and so on. The best laid plans on paper rarely prove out exactly in the course of execution depending on the complexity of the operating environment and culture in place
Expect Resistance and Expect a Mess
Any large program in my experience tends to go through an “optimism” phase, where you identify a vision and fairly significant, transformative goal, the business case and plan looks good, it’s been vetted and stakeholders are aligned, and you have all the normal “launch” related events that generate enthusiasm and momentum towards the future… and then reality sets in, and the optimism phase ends.
Having written more than once on Transformation, the reality is that it is messy and challenging, for a multitude of reasons, starting with patience, adaptability, and tenacity it takes to really facilitate change at a systemic level. Status quo feels safe and comforting, it is known, and upsetting that reality will necessarily lead to friction, resistance, and obstacles throughout the process.
Some things to consider:
Set realistic goals for the program at the outset, acknowledge that it is a journey, that sustainable change takes time, the approach will evolve as you deliver and learn, and that engagement, communication, and commitment are the non-negotiables you need throughout to help inform the right decisions at the right time to promote success
Plan with the 30-, 60-, and 90-day goals in mind, but acknowledge that any roadmap beyond the immediate execution window will be informed by delivery and likely evolve over time. I’ve seen quite a lot of time wasted on detailed planning more than one year out where a goal-based plan with conceptual milestones would’ve provided equal value from a planning and CBA standpoint
Govern Efficiently and Adjust Responsively
Given the scale and complexity of simplification efforts, it would be relatively easy to “over-report” on a program of this type and cause adverse impact on the work itself. In line with previous articles that I’ve written on governance and transparency, my point of view is that the focus needs to be on enabling delivery and effective risk management, not administrative overhead.
Some things to consider:
Establish a cadence for governance early on to review ongoing delivery, identify interventions and support needed, learnings that can inform future planning, and adjust goals as needed
Large programs succeed or fail in my experience based on maintaining good transparency to where you are, identifying course corrections when needed, and making those adjustments quickly to minimize the cost of “the turns” when they inevitably happen. Momentum is so critical in transformation efforts that minimizing these impacts is really important to keeping things on track
Wrapping Up
Overall, the reason for separating the process from the change in addressing simplification was deliberate, because both aspects matter. You can have a thoughtful, well executed process and accomplish nothing in terms of change and you can equally be very mindful of the environment and changes you want to bring about, but the execution model needs to be solid, or you will lose any momentum and good will you’ve built in support of your effort.
Ultimately, recognizing that you’re both engaging in a change and a delivery activity is the critical takeaway. Most medium- to large-scale environments end up complex for a host of reasons. You can change the footprint, but you need to change the environment as well, or it’s only a matter of time before you’ll find yourself right back where you started, perhaps with a different set of assets, but a lot of same problems you had in the first place.
I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.
“Something needs to change… we’re not growing, we’re too slow, we’re not competitive, we need to manage costs…”
Change is an inevitable reality in business. Even the most successful company will face adversity, new competitors, market shifts, evolving customer needs, expense pressures, near-term shareholder expectations, etc. While it’s important to focus on adjusting course and remedying issues, the question is whether you will find yourself in exactly the same (or at least a relatively similar) situation again (along with how quickly) and that comes down to leadership and culture.
Culture issues tend to beget other business issues, whether it’s delayed or misaligned decisions, complacency and a lack of innovation, a lack of collaboration and cooperation, risk averse behaviors, redundant or ineffective solutions, high turnover resulting in lost expertise, and so on. The point is that excellence needs to start “at the top” and work its way throughout an organization, andthe mechanism for that proliferation is culture.
The focus of this article will be to explore what it takes to evolve culture in an organization, and to provide ways to think about what can happen when it isn’t positioned or aligned effectively.
It Starts with the Right Intentions
Conformance versus Performance
Before attempting to change anything, the fundamental question to be asked is why you want to have a culture in place to begin with? Certainly, over the course of time and multiple organizations (and clients), I’ve seen culture emphasized to varying degrees, from where it is core to a company’s DNA, to where it is relegated to a poster, web page, or item on everyone’s desk that is seldom noticed or referenced.
In cases where it’s rarely referenced, there is missed opportunity to establish mission and purpose, rallying people around core concepts that can facilitate an effective work environment.
That being said, focusing on culture doesn’t necessarily create a greater good in itself, as I’ve seen environments where culture is used in almost a punitive way, suggesting there are norms to which everyone must adhere and specific language everyone needs to use, or there will be adverse consequences.
That isn’t about establishing a productive work environment, it’s about control and conformance, and that can be toxic when you understand the fundamental issue it represents: employees aren’t trusted enough to do the right thing, be empowered, and enabled to act, so there needs to be a mechanism in place to drive conformity, enforce “common language”, and isolate those who don’t fit the mold to create a more homogenous organizational society.
So, what happens to innovation, diversity, and inclusion in these environments? It’s suppressed or destroyed, because the capabilities and gifts of the individual are lost to the push towards a unified, homogenized whole. That is a fairly extreme outcome of such authoritarian environments, but the point is that a strong culture is not, in itself, automatically good if the focus is control and not performance and excellence.
I’ve written multiple articles on culture and values that I believe are important in organizations, so I won’t repeat those messages here, but the goal of establishing culture should be fostering leadership, innovation, growth, collaboration, and optimizing the contribution of everyone in an organization to serve the greater good. If that doesn’t apply in equal measure to every employee, based on their individual capabilities and experience, that’s fine from my perspective, so long as they don’t detract from the performance of others in the process. The point is that culture isn’t about the words on the wall, it’s about the behaviors that you are aspiring to engender within an organization and the degree to which you live into them every day.
Begin with Leadership
Words and Actions
It is fairly obvious to say that culture needs to start “at the top” and work its way outward, but there are so many issues I’ve seen over time in this step alone, that it is worth repeating.
It is not uncommon for leaders to speak in town hall meetings or public settings and proclaim the merits of the company culture, asking others to follow the core values or principles as outlined, to the betterment of themselves and everyone else (customers and others included as appropriate). Now, the question is: what happens when that person returns to their desk and makes their next set of decisions? This is where culture is measured, and employees notice everything over time.
The challenge for leaders who want excellence and organizational performance is to take culture to heart and do what they can to live into it, even in the most difficult circumstances, which is where it tends to be needed the most. I remember hearing a speaker suggest that the litmus test of the strength of your commitment to culture could be expressed in whether you would literally walk away from business rather than compromise your values. That’s a pretty difficult bar to set in my experience, but an interesting way to think about the choices we make and their relative consequence.
Aligning Incentives versus Values
Building on the previous point, there is a difference between behaviors and values. The latter is what you believe and prioritize, the former is how you act. Behaviors are directly observable; values are indirectly observed through your words and actions.
Why is this important in the context of culture? It is important, because you can incent people in the interest of influencing their behavior, but you can’t change someone’s values, no matter how you incent them. To the extent you want to set up a healthy, collaborative culture and there are individual motivations that don’t align with doing the right thing, organizational performance will suffer in some way, and the more senior the individual(s) are in the organization, the more significant the impact will likely be.
This point ultimately comes down to doing the right level of due diligence during the hiring process, but also being willing to make difficult decisions during the performance management process, because sometimes individual performers with unhealthy behaviors cause a more significant impact than is evident without some level of engagement and scrutiny from a leadership standpoint.
Have a Thoughtful Approach
Incubate -> Demonstrate -> Extend
As the diagram above suggests, culture doesn’t change overnight, and being deliberate in the approach to change will have a significant impact to how effective and sustainable it is.
In general, the approach I’d recommend is to start from “center” with leadership, raise awareness, educate on the intent and value to the changes proposed, and incubate there. Broader communication in terms of the proposed shift is likely useful in preparing the next group to be engaged in the process, but the point is to start small, begin “living into” the desired model, evaluating its efficacy, and demonstrating the value it can create, THEN extend to the next (likely adjacent) set of people, and repeat the process over and over until the change has fully proliferated to the entire organization. The length of any given iteration would likely vary depending on the size of the employee population and the degree of change involved (more substantial = longer windows of time), but the point is to be conscious and deliberate in how it is approached so adjustments can be made along the way and to enable leaders to understand and internalize the “right” set of behaviors before expecting them to help advocate and reinforce it in others.
An Example (Building an Architecture Capability)
To provide a simple example, when trying to establish an architecture capability across an organization, it would need to ultimately span from the central enterprise architecture team down to technical leads on individual implementation teams. It would be impractical to implement the model all at once, so it would be more effective to stage it out, working from the top-down, first defining roles and responsibilities across the entire operating model, but then implementing one “layer” of roles at a time, until it is entirely in place.
Since architects are generally responsible for technical solution quality, but not execution, the deployment of the model would need to follow two coordinated paths: building the architecture capability itself and aligning it with the delivery leadership with which it is meant to collaborate and cooperate (e.g., project and program managers). Trying to establish the role without alignment and support from people leading and participating on delivery teams likely would fail or lead to ineffective implementation, which is another reason why a more thoughtful and deliberate approach to the change is required.
What does this have to do with culture? Well, architecture is fundamentally about solution quality in technology, reuse, managing complexity and cost of ownership, and enabling speed and disciplined innovation. Establishing roles with an accountability for quality will test the appetite within an organization when it comes to working beyond individual project goals and constraints to looking at more strategic objectives for simplification, speed, and reuse. Where courageous leadership and the right culture are not in place, evolving the IT operating model will be considerably more difficult, likely at every stage of the process.
Manage Reality
To this point, I’ve addressed change in a fairly uniform and somewhat idealistic manner, but reality is often quite different, so I wanted to explore a couple situations and how I think about the implications of each.
Non-Uniform Execution
So, what happens when you change culture within your team, but it doesn’t extend into those who work directly with you? It depends on the nature of the change itself, of course, but likely the farther “out” from center you go, the more difficult it will be for your team to capitalize on whatever the intended benefits of the change were intended to be.
My assumptions here are in relation to medium- to larger-scale organizations, where the effects are magnified and it is impractical to “be everywhere, all the time” to engage in ways that help facilitate the desired change.
In the case that there isn’t broader alignment to whatever cultural adjustments you want to make within your team, depending on the degree of difference to the broader company culture, it may be necessary to clarify how “we operate internally” versus how “we engage with others”. The goal of drawing out that separation would be to try and drive performance improvement within your team, but not waste energy and create friction in your external interactions.
There is a potential risk in having teams with a very different culture than the broader organization if it creates an environment where there becomes an “us and them” mentality or a special treatment situation where that team demonstrates unhealthy organizational behaviors or is held to different standards than others. Ultimately those situations cause larger issues and should be avoided where possible.
Handling Disparate Cultures
Unlike the previous situation where there is one broader culture and a team operates in a slightly different manner; I’ve also seen situations where groups operate with very different cultures within the same overall organization and it can create substantial disconnects if not addressed effectively. When not addressed there can be a lot of internal friction, competition, and a lack of effective collaboration, which will hinder performance in one or more ways over time.
One way to manage a situation where there are multiple distinct cultures within a single organization, would first be to look for some level of core, universally accepted operating principles that can be applied to everyone, but then to focus entirely on the points of engagement across organizations, clarify roles and responsibilities for each constituent group, and manage to those dependencies the same as you would if working with a third-party provider or partner. The overall operating performance opportunity may not be fully realized, but this kind of approach could be used to provide clarity of expectations and reduce friction points to a large degree.
Wrapping Up
The purpose of this article was to come back to a core element that makes organizations successful over time, and that’s culture. To the degree that there are gaps or issues, it is always possible to adapt and evolve, but it takes a thoughtful approach, the right leadership, and time to make sustainable change. In my opinion, it is time worth spending to the degree that performance and excellence is your goal. It will never be “perfect” for many reasons, but thinking about how you establish, reinforce, and evolve it in a disciplined way can be the difference to remaining agile, competitive, and successful overall.
I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.
This is a question that I’ve heard asked many times, particularly when there is a strategic initiative or transformation effort being kicked off. Normally, the answer is an enthusiastic “Yes”, because most programs start with a lot of optimism (which is a good thing), but not always a full understanding of risk. The question is… How do you know whether you have the necessary capabilities to deliver?
In any type of organization, there is a blend of skills and experience, whether that is across a leadership team or within an individual team itself. Given that reality and the ongoing nature of organizations to evolve, realign, and reorganize, it is not uncommon to leverage some form of evaluation (such as a Kolbe assessment) to understand the natural strengths, communication, or leadership styles of various individuals to help facilitate understanding and improve collaboration.
But what about knowledge and experience? This part I haven’t seen done as often partially because, if not done well, it can lead to a cumbersome and manually intensive process that doesn’t create value.
The focus of this article is to suggest a means to understand and evaluate the breadth of knowledge and skills across a team. To the extent we can visualize collective capability, it can be a useful tool to inform various things from a management standpoint, which are outlined in the second section below.
Necessary caveats: The example used is not meant to be prescriptive or exhaustive and this activity doesn’t need to be focused on IT alone. The goal in the illustration used here was to provide enough specificity to help the reader visualize the concept at a practical level, but the data is entirely made up and not meant to be taken as a representation of an actual set of people.
On the Approach
Thinking through the Dimensions
The diagram above breaks out 27 dimensions from a knowledge and skills standpoint, ranging from business understanding to operations and execution. The dimensions chosen for the purposes of this exercise don’t particularly matter, but I wanted to select a set that covered many of the aspects of an IT organization as a whole.
From an approach standpoint, the goal would be to identify what is being evaluated, select the right set of dimensions, define them, then determine “what good looks like” in terms of having a baseline for benchmarking (e.g., 10 means X, 8 means Y, 6 means Z, etc.). With the criteria established, one should then explain the activity to the group being evaluated, prepare a simple survey, and gather the data. The activity is meant to be rapid and directionally accurate, not to supplant individual performance evaluations, career development, or succession plans that should exist at a more detailed level. Ideally the dimensions should also align to the competency model for an organization, but the goal of this activity is directional, so that step isn’t critical if it requires too much effort.
Once data has been collected, individual results can be plotted in a spider graph like the one below to provide a perspective on where there are overlaps and gaps across a team.
Ways of Applying the Concept
With the individual inputs from a team having been provided, it’s possible to think about the data in two different respects: how it reflects individual capabilities, gaps, and overlaps as well as what it shows as the collective experience of the team as a whole (the green dotted outline above).
The data now being assembled, there are a number of ways to potentially leverage the information outlined below.
Talent Development: The strengths and gaps in any individual view can be used to inform individual development plans or identify education needs for the team as a whole. It can also be used to sanity check individual roles and accountability against the actual experience of individuals on the team. This isn’t to suggest rotations and “learn on the job” situations aren’t a good thing, but rather to raise awareness of those situations so that they can be managed proactively with the individual or the team as a whole. To the extent that a gap with one person is a strength in another, there could be cross-training opportunities that surface through the process.
Coordination and Collaboration: With overlaps and gaps visible across a team, there can be areas identified where individual team members see opportunities to consult with others who have a similar skillset, and also perhaps a different background that could surface different ways to approach and solve problems. In larger organizations, it can often be difficult to know “who to invite” to a conversation, where the default becomes inviting everyone (or making everyone ‘mandatory’ versus ‘optional’), which ultimately can lead to less productive or over-attended conversations that lack focus.
Leaders and Teams: In the representative data above, I deliberately highlighted areas where team members were not as experienced as the person leading the team, but the converse situation as well. In my experience, it is almost never the case that the leader is the most experienced in everything within the scope of what a team has to do. If that was the case, it could suggest that the potential of that team could be limited to that leader’s individual capabilities and vision, because others lack the experience to help inform direction. In the event that team members have more experience than their leader, there can also be opportunities for individuals to step up and provide direction, assuming the team leader creates space and a supportive environment for that occur. Again, the point of the activity is to identify and determine what, if anything, to do with these disparities where they exist.
Sourcing Strategy: Where significant gaps exist (e.g., there is no one with substantial AI experience in the example data above), these could be areas where finding a preferred partner with a depth of experience in the topic could be beneficial while internal talent is acquired or developed (to the extent it is deemed strategic to the organization).
Business Partnership: The visibility could serve as input to a partnership discussion to align expectations for where business leaders expect support and capability from their technology counterparts versus areas where they are comfortable taking the lead or providing direction. This isn’t always a very deliberate conversation in my experience, and sometimes that can lead to missed expectations in complex delivery situations.
Risk Management: One of the most important things to recognize about a visualization like this is not just what it shows about a teams’ capability, it’s also what isn’t there.
Using Donald Rumsfeld’s now famous concept:
There is known – something for which we have facts and experience
There is known unknown – something we know is needed, but which is not yet clear
And the pure unknown – something outside our experience, and therefore a blind spot
The last category is where we should also focus in an activity like this, because the less experience that exists individually and collectively in a leadership team, there will be a substantial increase in risk because there is a lack of awareness of all the “known unknowns” that can have a material impact on delivering solutions and operating IT. To the extent that a team is relatively inexperienced, no matter how motivated they may be, there is an increased probability that something will be compromised, whether that is cost, quality, schedule, morale, or something else. To that end, this tool can be an important mechanism to identify and manage risk.
Wrapping Up
Having recently written a fairly thorough set of articles on the future of enterprise technology, I wanted to back up and look at something a little less complex, but also with a focus on improving transparency and informing leadership discussions on risk, development, and coordination.
Whether through a mechanism like this or some other avenue, I believe there is value in understanding the breadth of capabilities that exist within a team and across a leadership group as a means for promoting excellence overall.
I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.
Organized Chaos 