Tag: business

Developing Application Strategy – Managing the Intangibles

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.

-CJG 10/22/2025

Culture and Sustaining Success

“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, and the 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.

-CJG 10/03/2025

Visualizing Experience

“Are we set up for success?”

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.

-CJG 08/24/2025

The Intelligent Enterprise 2.0 – IT Organizational Implications

“Go West, Young Man”

I remember a situation where an organization decided to aggressively offshore work to reduce costs.  The direction to IT leaders was no different than that of the Gold Rush above.  Leaders were given a mandate, a partner with whom to work, and a massive amount of contracting ensued.  The result?  A significant number of very small staff augmentation agreements (e.g., 1-3 FTEs), a reduction in fixed, but a disproportionate increase in variable operating expenses, and a governance and administrative nightmare.  How did it happen?  Well, there was leadership support, a vision, and a desired benefit, but no commonly understood approach, plan, or governance.  The organization then spent a considerable amount of time transitioning all of the agreements in place to something more deliberate, establishing governance, and optimizing what quickly became a very expensive endeavor.

The requirements of transformation are no different today than they ever have been.  You need a vision, but also the conditions to promote success, and that includes an enabling culture, a clear approach, and governance to keep things on track and make adjustments where needed.

This is the final post in a series focused on where I believe technology is heading, with an eye towards a more harmonious integration and synthesis of applications, AI, and data… what I previously referred to in March of 2022 as “The Intelligent Enterprise”.  The sooner we begin to operate off a unified view of how to align, integrate, and leverage these oftentimes disjointed capabilities today, the faster an organization will leapfrog others in their ability to drive sustainable productivity, profitability, and competitive advantage.

 

Overall Approach

Writing about IT operating models can be very complex for various reasons, and mostly because there are many ways to structure IT work based on the size and complexity of an organization, and there is nothing wrong with that in principle.  A small- to medium-size IT organization, as an example, likely has little separation of concerns and hierarchy, people playing multiple roles, a manageable project portfolio, and minimal coordination required in delivery.  Standardization is not as complex and requires considerably less “design” than a multi-national or large-scale organization, where standardization and reuse needs to be weighed against the cost of coordination and management involved as the footprint scales.  There can also be other considerations, such as one I experienced where simplification of a global technology footprint was driven off of operating similarities across countries rather than geographic or regional considerations.

What tends to be common across ways of structuring and organizing is the various IT functions that exist (e.g., portfolio management, enterprise architecture, app development, data & analytics, infrastructure, IT operations), just at different scales and levels of complexity.  These can be capability-based, organized by business partner, with some centralized capabilities and some federated, etc. but the same essential functions likely are in place, at varying levels of maturity and scale based on the needs of the overall organization.  In multi-national or multi-entity organizations/conglomerates, these functions likely will be replicated across multiple IT organizations with some or no shared capability existing at the parent/holding company or global level.

To that end, I am going to explore how I think about integrating the future state concepts described in the earlier articles of this series in terms of an approach and conceptual framework that, hopefully, can be applied to a broad range of IT organizations, regardless of their actual structure.

The critical challenge with moving from our current environment to one where AI, apps, and data are synthesized and integrated is doing it in a way that follows a consistent approach and architecture while not centralizing so much that we either constrain progress or limit innovation that can be obtained by spreading the work across a broader percentage of an organization (business teams included).  This is consistent with the templatized approach discussed in the prior article on Transition, but there can be many ways that that effort is planned and executed based on the scale and complexity of the organization undertaking the transformation itself.

 

Key Considerations

Define the Opportunities, Establish the Framework, Define the Standards

Before being concerned with how to organize and execute, we first need to have a mental model for how teams will engage with an AI-enabled technology environment in the future.  Minimally, I believe that will manifest itself in four ways:

  • Those who define and govern the overall framework
  • Those who leverage AI-enabled capabilities to do their work
  • Those who help create the future environment
  • Those who facilitate transition to the future state operating model

I will explore the individual roles in the next section, but an important first step is defining the level of standardization and reuse that is desirable from an enterprise architecture standpoint.  That question becomes considerably more complex in organizations with multiple entities, particularly when there are significant differences in the markets they serve, products/services they provide, etc.  That doesn’t mean, however, that reuse and optimization opportunities don’t exist, but rather that they need to be more thoughtfully defined and developed so as not to slow any individual organization down in their ability to innovate and promote competitive advantage.  There may be opportunities to look for common capabilities that make more sense to develop centrally and reuse that can actually accelerate speed-to-market if built in a thoughtful manner.

Regardless of whether capabilities in a larger organization are designed and developed in a highly distributed manner, having a common approach to the overall architecture and standards (as discussed in the Framework article in this series) could be a way to facilitate learning and optimization in the future (within and across entities), which will be covered in the third portion of this article.

 

Clarify the Roles and Expectations, Educate Everyone

The table below is not meant to be exhaustive, but rather to act as a starting point to consider how different individuals and teams will engage with the future enterprise technology environment and highlight the opportunity to clarify those various roles and expectations in the interest of promoting efficiency and excellence.

While I’m not going to elaborate on the individual data points in the diagram itself, a few points to note in relation to the table.

There is a key assumption that AI-related tools will be vetted, approved, and governed across an enterprise (in the above case, by the Enterprise Architecture function).  This is to promote consistency and effectiveness, manage risk, and consider issues related to privacy, IP-protection, compliance, security, and other critical concerns that otherwise would be difficult to manage without some formal oversight.

It is assumed that “low hanging fruit” tools like Copilot, LLMs, and other AI tools will be used to improve productivity and look for efficiency gains while implementing a broader, modern and integrated future state technology footprint with integrated agents, insights, and experts.  The latter of these things has touchpoints across an organization, which is why having a defined framework, standards, and governance are so important in creating the most cost-effective and rapid path to transforming the environment to one that create disproportionate value and competitive advantage.

Finally, there are adjustments to be made in various operating aspects of running IT, which is to reinforce the idea that AI should not be a separate “thing” or a “silver bullet”, it needs to become an integrated part of the way an organization leverages and delivers technology capabilities.  To the extent it is treated as something different or special and separated from the ongoing portfolio of work and operational monitoring and management processes, it will eventually fail to integrate well, increase costs, and underdeliver on value contributions that are widely being chased after today.  Everyone across the organization should also be made aware of the above roles and expectations, along with how these new AI-related capabilities are being leveraged so they can help identify continuing opportunities to leverage and improve their adoption across the enterprise.

 

Govern, Coordinate, Collaborate, Optimize

With a model in place and organizational roles and responsibilities clarified, there needs to be a mechanism to collect learnings, facilitate improvements to the “templatized approach” referenced in the previous article in this series, and drive continuous improvement in how the organization functions and leverages these new capabilities.

This can be manifest in several approaches when spread across a medium to large organization, namely:

  • Teams can work in partnership or in parallel to try a new process or technology and develop learnings together
  • One team can take the lead to attempt a new approach or innovation and share learnings with other in a fast-follower based approach
  • Teams can try different approaches to the same type of solution (when there isn’t a clear best option), benchmark, and select the preferred approach based on the learning across efforts

The point is that, to achieve maximum efficiency, especially when there is scale, centralizing too much can hamper learning and innovation, and it is better to develop coordinated approaches that can be governed and leveraged than to have a “free for all” where the overall opportunity to innovate and capture efficiencies is compromised.

 

Summing Up

As I mentioned at the outset, the challenge in discussing IT implications from establishing a future enterprise environment with integrated AI is that there are so many possibilities for how companies can organize around it.  That being said, I do believe a framework for the future intelligent enterprise should be defined, roles across the organization should be clarified, and transition to that future state should be governed with an eye towards promoting value creation, efficiency, and learning.

This concludes the series on my point of view related to the future of enterprise technology with AI, applications, and data and analytics integrated into one, aligned strategy.  No doubt the concepts will evolve as we continue to learn and experiment with these capabilities, but I believe there is always room for strategy and a defined approach rather than an excess of ungoverned “experimentation”.  History has taught us that there are no silver bullets, and that is the case with AI as well.  We will obtain the maximum value from these new technologies when we are thoughtful and deliberate in how we integrate them with how we work and the assets and data we possess.  Treating them as something separate and distinct will only suboptimize the value we create over time and those who want to promote excellence will be well served to map out their strategy sooner rather than later.

I hope the ideas across this series were worth considering.  Thanks for spending the time to read them.  Feedback is welcome as always.

-CJG 08/19/2025

The Intelligent Enterprise 2.0 – Managing Transition

A compelling vision will stand the test of time, but it will also evolve to meet the needs of the day.

There are inherent challenges with developing strategy for multiple reasons:

  • It is difficult to balance the long- and short-term goals of an organization
  • It generally takes significant investments to accomplish material outcomes
  • The larger the change, the more difficult it can be to align people to the goals
  • The time it takes to mobilize and execute can undermine the effort
  • The discipline needed to execute at scale requires a level of experience not always available
  • Seeking “perfection” can be counterproductive by comparison with aiming for “good enough”

The factors above, and other too numerous to list, should serve as reminders that excellence, speed, and agility require planning and discipline, they don’t happen by accident.  The focus of this article will be to break down a few aspects of transitioning to an integrated future state in the interest of increasing the probability of both achieving predictable outcomes, but also in getting there quickly and in a cost-effective way, with quality.  That’s a fairly tall order, but if we don’t shoot for excellence, we are eventually choosing obsolescence.

This is the sixth post in a series focused on where I believe technology is heading, with an eye towards a more harmonious integration and synthesis of applications, AI, and data… what I previously referred to in March of 2022 as “The Intelligent Enterprise”.  The sooner we begin to operate off a unified view of how to align, integrate, and leverage these oftentimes disjointed capabilities today, the faster an organization will leapfrog others in their ability to drive sustainable productivity, profitability, and competitive advantage.

 

Key Considerations

Create the Template for Delivery

My assumption is that we care about three things in transitioning to a future, integrated environment:

  • Rapid, predictable delivery of capabilities over time (speed-to-market, competitive advantage)
  • Optimized costs (minimal waste, value disproportionate to expense)
  • Seamless integration of new capabilities as they emerge (ease of use and optimized value)

What these three things imply is the need for a consistent, repeatable approach and a standard architecture towards which we migrate capabilities over time.  Articles 2-5 of this series explore various dimensions of that conceptual architecture from an enterprise standpoint, the purpose here will be to focus in on approach.

As was discussed in the article on the overall framework, the key is to start the design of the future environment around the various consumers of technology, the capabilities being provided to them, now and in the future, and prioritizing the relative value of those capabilities over time.  That should be done on an internal and external level, so that individual roadmaps can be developed by domain to eventually surface and provide those capabilities as part of a portfolio management process.  In the course of identifying those capabilities, some key questions will be whether those capabilities are available today, involve some level of AI services, whether those can/should be provided through a third-party or internally, and whether the data ultimately exists to enable them.  This is where a significant inflection point should occur: the delivery of those capabilities should follow a consistent approach and pattern, so it can be repeated, leveraged, and made more efficient over time.

For instance, if an internally-developed AI-enabled capability is needed, the way that the data is exposed, processed, the AI service (or data product) exposed, and integrated/consumed by a package or custom application should be exactly the same from a design standpoint, regardless of what the specific capability is.  That isn’t to say that the work needs to be done by only one team, as will be explored in the final article on IT organizational implications, but rather that we ideally want to determine the best “known path” to delivery, execute that repeatedly, and evolve it as required over time. 

Taking this approach should provide a consistent end-user experience of services as they are brought online over time, a relatively streamlined delivery process as you are essentially mass-producing capabilities over time, and a relatively cost-optimized environment as you are eliminating the bloat and waste of operating multiple delivery silos that will eventually impede speed-to-market at scale and lead to technical debt.

From an architecture standpoint, without wanting to go too deep into the mechanics here, to the extent that the current state and future state enterprise architecture models are different, it would be worth evaluating things like virtualization of data as well as adapters/facades in the integration layer as a way to translate between the current and future models so there is logical consistency in the solution architecture even where the underlying physical implementations are varied.  Our goal in enterprise architecture should always be to facilitate rapid execution, but promote standards, simplification, and reduce complexity and technical debt wherever possible over time.

 

Govern Standards and Quality

With a templatized delivery model and target architecture in place, the next key aspect to transition is to both govern the delivery of new capabilities to identify opportunities to develop and evolve standards, as well as to evolve the “template” itself, whether that involves adding automation to the delivery, building reusable frameworks or components that can be leveraged, or other assets that can help reduce friction and ease future efforts.

Once new capabilities are coming online, the other key aspect is to review them for quality and performance, to also look for ways to evolve the approach, adjust the architecture, and continue to refine the understanding of how these integrated capabilities can best be delivered and leveraged on an end-to-end basis.

Again, the overall premise of this entire series of articles is to chart a path towards an integrated enterprise environment for applications, data, and AI in the future.  To be repeatable, we need to be consistent in how we plan, execute, govern, and evolve in the delivery of capabilities over time.

Certainly, there will be learnings that come from delivery, especially early in the adoption and integration of these capabilities. The way that we establish and enable the governance and evolution stemming from what we learn is critical in making delivery more predictable and ensuring more useful capabilities and insights over time.

 

Evolve in a Thoughtful Manner

With our learnings firmly in hand, the mental model I believe would be worth considering is more of a scaled Agile-type approach, where we have “increment-level”/monthly scheduled retrospectives to review the learnings across multiple sprints/iterations (ideally across multiple product/domains) and to identify opportunities to adjust estimation metrics, design patterns, develop core/reusable services, and anything else that essentially would improve efficiency, cost, quality, or predictability.

Whether these occur monthly at the outset and eventually space out to a quarterly process as the environment and standards are better defined could depend on a number of factors, but the point is not to make it too reactive to any individual implementation and to try and look across a set of deliveries to look for consistent issues, patterns, and opportunities that will have a disproportionate impact on the environment as a whole.

The other key aspect to remember in relation to evolution is that the capabilities of AI in particular are evolving very rapidly at this point, which is also a reason for thinking about the overall architecture, separation of concerns, and standards for how you integrate in a very deliberate way.  A new version of a tool or technology shouldn’t require us to have to rewrite a significant portion of our footprint, it ideally should be a matter of upgrading the previous version and having the new capabilities available everywhere that service is consumed or in swapping out one technology for another, but everything on the other side of an API remaining nearly unchanged to the extent possible.  This is understood as a fairly “perfect world” description of what likely would happen in practice, depending on the nature of the underlying change, but the point is that, without allowing for these changes up front in the design, the level of disruption they cause will likely be amplified and slow overall progress.

 

Summing Up

Change is a constant in technology.  It’s a part of life given that things continue to evolve and improve, and that’s a good thing to the extent that it provides us with the ability to solve more complex problems, create more value, and respond more effectively to business needs as they evolve over time.  The challenge we face is in being disciplined enough to think through the approach so that we can become effective, fast, and repeatable.  Delivering individual projects isn’t the goal, it’s delivering capabilities rapidly and repeatably, at scale, with quality.  That’s an exercise in disciplined delivery.

Having now covered the technology and delivery-oriented aspects of the future state concept, the remaining article will focus on how to think about the organizational implications on IT.

 

Up Next: IT Organizational Implications

I hope the ideas were worth considering.  Thanks for spending the time to read them.  Feedback is welcome as always.

-CJG 08/15/2025

The Intelligent Enterprise 2.0 – Deconstructing Data-Centricity

Does having more data automatically make us more productive or effective?

When I wrote the original article on “The Intelligent Enterprise”, I noted that the overall ecosystem for analytics needed to change.  In many environments, data is moved from applications to secondary solutions, such as data lakes, marts, or warehouses, enriched and integrated with other data sets, to produce analytical outputs or dashboards to provide transparency into operating performance.  Much of this is reactive and ‘after-the-fact’ analysis of things we want to do right or optimize the first time, as events occur.  The extension of that thought process was to move those insights to the front of the process, integrate them with the work as it is performed, and create a set of “intelligent applications” that would drive efficiency and effectiveness to different levels than we’ve been able to accomplish before.  Does this eliminate the need for downstream analytics, dashboards, and reporting?  No, for many reasons, but the point is to think about how we can make the future data and analytics environment about establishing a model that enables insight-driven, orchestrated action.

This is the fifth post in a series focused on where I believe technology is heading, with an eye towards a more harmonious integration and synthesis of applications, AI, and data… what I previously referred to in March of 2022 as “The Intelligent Enterprise”.  The sooner we begin to operate off a unified view of how to align, integrate, and leverage these oftentimes disjointed capabilities today, the faster an organization will leapfrog others in their ability to drive sustainable productivity, profitability, and competitive advantage.

 

Design Dimensions

In line with the blueprint above, articles 2-5 highlight key dimensions of the model in the interest of clarifying various aspects of the conceptual design.  I am not planning to delve into specific packages or technologies that can be used to implement these concepts as the best way to do something always evolves in technology, while design patterns tend to last.  The highlighted areas and associated numbers on the diagram correspond to the dimensions described below.

 

Starting with the Consumer (1)

“Just give me all the data” is a request that isn’t unusual in technology.  Whether that is a byproduct of the challenges associated with completing analytics projects, a lack of clear requirements, or something else, these situations cause an immediate issue in practice: what is the quality of the underlying data and what are we actually trying to do with it?

It’s tempting to start an analytics effort from the data storage and to work our way up the stack to the eventual consumer.  Arguably, this is a central premise in being “data-centric.” While I agree with the importance of data governance and management (the next topic), it doesn’t mean everything is relevant or useful to an end consumer, and too much data very likely just creates management overhead, technical complexity, and information overload.

A thoughtful approach needs to start with identifying the end consumers of the data, their relative priority, information and insights needs, and then developing a strategy to deliver those capabilities over time.  In a perfect world, that should leverage a common approach and delivery infrastructure so that it can be provided in iterations and elaborated to include broader data sets and capabilities across domains over time.  The data set should be on par with having an integrated data model and consistent way of delivering data products and analytics services that can be consumed by intelligent applications, agents, and solutions supporting the end consumer.

As an interesting parallel, it is worth noting that ChatGPT is looking to converge their reasoning and large language models from 4x into a single approach for their 5x release so that end customers don’t need to be concerned with having selected the “right” model for their inquiry.  It shouldn’t matter to the data consumer.  The engine should be smart enough to leverage the right capabilities based on the nature of the request, and that is what I am suggesting in this regard.

 

Data Management and Governance (2)

Without the right level of business ownership, the infrastructure for data and analytics doesn’t really matter, because the value to be obtained from optimizing the technology stack will be limited by the quality of the data itself.

Starting with master data, it is critical to identify and establish data governance and management for the critical, minimum amount of data in each domain (e.g., customer in sales, chart of accounts in finance), and the relationship between those entities in terms of an enterprise data model.

Governing data quality has a cost and requires time, depending on the level of tooling and infrastructure in place, and it is important to weigh the value of the expected outcomes in relation to the complexity of the operating environment overall (people, process, and technology combined).

 

From Content to Causation (3)

Finally, with the level of attention given to Generative AI and LLMs, it is important to note the value to be realized when we shift our focus from content to processes and transactions in the interest of understanding causation and influencing business outcomes.

In a manufacturing context, the increasing level of interplay between digital equipment, digital sensors, robotics, applications, and digital workers, there is a significant opportunity to orchestrate, gather and analyze increasing volumes of data, and ultimately optimize production capacity, avoid unplanned events, and increase the safety and efficacy of workers on the shop floor.  This requires deliberate and intentional design, with outcomes in mind.

The good news is that technologies are advancing in their ability to analyze large data sets and derive models to represent the characteristics and relationships across various actors in play and I believe we’ve only begun to scratch the surface on the potential for value creation in this regard.

 

Summing Up

Pulling back to the overall level, data is critical, but it’s not the endgame.  Designing the future enterprise technology environment is about exposing and delivering the services that enable insightful, orchestrated action on behalf of the consumers of that technology.  That environment will be a combination of applications, AI, and data and analytics, synthesized into one meaningful, seamless experience.  The question is how long it will take us to make that possible.  The sooner we begin the journey of designing that future state with agility, flexibility, and integration in mind, the better.

Having now elaborated the framework and each of the individual dimensions, the remaining two articles will focus on how to approach moving from the current to future state and how to think about the organizational implications on IT.

Up Next: Managing Transition

I hope the ideas were worth considering.  Thanks for spending the time to read them.  Feedback is welcome as always.

-CJG 08/03/2025

The Intelligent Enterprise 2.0 – A Framework for the Future

Why does it take so much time to do anything strategic?

This not an uncommon question to hear in technology and, more often than not, the answer is relatively simple: because the focus in the organization is delivering projects and not establishing an environment to facilitate accelerated delivery at scale.  Those are two very different things and, unfortunately, it requires more thought, partnership, and collaboration between business and technology teams than headlines like “let’s implement product teams” or “let’s do an Agile transformation” imply.  Can those mechanisms be part of how you execute in a scaled environment?  Absolutely, but choosing an operating approach and methodology shouldn’t precede or take priority over having a blueprint to begin with, and that’s the focus of this article.

This is the second post in a series focused on where I believe technology is heading, with an eye towards a more harmonious integration and synthesis of applications, AI, and data… what I previously referred to in March of 2022 as “The Intelligent Enterprise”.  The sooner we begin to operate off a unified view of how to align, integrate, and leverage these oftentimes disjointed capabilities today, the faster an organization will leapfrog others in their ability to drive sustainable productivity, profitability, and competitive advantage.

Design Dimensions

In line with the blueprint above, articles 2-5 highlight key dimensions of the model in the interest of clarifying various aspects of the conceptual design.  I am not planning to delve into specific packages or technologies that can be used to implement these concepts as the best way to do something always evolves in technology, while design patterns tend to last.  The highlighted areas and associated numbers on the diagram correspond to the dimensions described below.

User-Centered Design (1)

A firm conducts a research project on behalf of a fast-food chain.  There is always a “coffee slick” in the drive thru, where customers stop and pour out part of their beverage.  Is there something wrong with the coffee?  No.  Customers are worried about burning themselves.  The employees are constantly overfilling the drink, assuming that they are being generous, but actually creating a safety concern by accident.  Customers don’t want to spill their coffee, so that excess immediately goes to waste.

In the world of technology, the idea of putting enabling technology in the hands of “empowered” end users or delivering that one more “game changing” tool or application is tempting, but often doesn’t deliver the value that is originally expected.  This can occur for a multitude of reasons, but what can often be the case is an inadequate understanding of the end user’s mental model, approach to performing their work, or a fundamental misunderstanding that more technology in the hands of a user is always a good thing (when it definitely isn’t the case).

Two learnings that came out of the dotcom era were, first, the value to be derived from investing in user-centered design, thinking through their needs and workflow, and designing experiences around that.  The other common practice was assuming that a disruptive technology (the internet in this case) was cause to spin out a separate organization (the “eBusiness” teams of the time) meant to incubate and accelerate development of capabilities that embraced the new technology.  These teams generally lacked a broader understanding of the “traditional” business and its associated operating requirements, and thus began the ”bricks versus clicks” issues and channel conflict that eventually led to these capabilities being folded back into the broader organization, but only after having spent time and (in many cases) a considerable amount of money experimenting without producing sustainable business value.

In the case of artificial intelligence, it’s tempting to want to stand up new organizations or repurpose existing ones to mobilize the technology or to assume everything will eventually be relegated to a natural language-based interface where a user provides a description of what they want into an agent acting at their personal virtual assistant, with system deriving the appropriate workflow and orchestrating the necessary actions to support the request.  While that may be a part of our future reality, taking an approach similar to the dotcom era would be a mistake and there will lost opportunity where this is the chosen path.

To be effective in a future digital world with AI, we need to think of how we want things integrated at the outset, starting with that critical understanding of the end user and how they want to work.  Technology is meant to enable and support them, not the other way around, and leading with technology versus a need is never going to be an optimal approach… a lesson we’ve been shown many times over the years, no matter how disruptive the technology advancement has been.

I will address some of the organizational implications of the model in the seventh article in this series, so the remainder of this post will be on the technology framework itself.

Designing Around Connected Ecosystems (2)

Domain-driven design is not a new concept in technology.

As I mentioned in the first article, the technology footprint of most medium- to large-scale organizations is complex and normally steeped in redundancies, varied architectures, unclear boundaries between custom and purchased software, hosted and cloud-based based environments, hard coded integrations, and standard ways of moving data within and across domains.

While package solutions offer some level of logical separation of concerns between different business capabilities, the natural tendency in the product and platform space is to move towards more vertically or horizontally integrated solutions that create customer lock in and make interoperability very challenging, particularly in the ERP space.  What also tends to occur is that an organization’s data model is biased to conform to what works best for a package or platform, but not necessarily the best representation of their business or their consumers of technology (something I will address in article 5 on Data & Analytics).

In terms of custom solutions, given they are “home grown”, there is a reasonable probability that, unless they were well-architected at the outset, they very likely provide multiple capabilities, without clear separation of concerns in ways that make them difficult to integrate with other systems in “standard” ways.

While there is nothing unique about these kinds of challenges, the problem comes when new technology capabilities like AI are available and we want to either replace or integrate things in a different way.  This is where the lack of enterprise-level design and a broader, component-based architecture takes its toll, because there likely will be significant remediation, refactoring, and modernization required to enable existing systems to interoperate with the new capabilities.  These things take time, add risk, and ultimately cost to our ability to respond when these opportunities arise, and no one wants to put new plumbing in a house that is already built with a family living in it.

On the other hand, in an environment with defined, component-based ecosystems that uses standard integration patterns, replacing individual components becomes considerably easier and faster, with much less disruption at both a local- and an enterprise-level.  In a well-defined, component-based environment, I should be able to replace my Talent Acquisition application without having to impact my Performance Management, Learning & Development, or Compensation & Benefits solutions from an HR standpoint.  Similarly, I shouldn’t need to make changes to my Order Management application within my Sales ecosystem because I’m transitioning to a different CRM package.  To the extent that you are using standard business objects to support integration across systems, the need to update downstream systems in other domains should be minimized as well.  Said differently, if you want to be fast, be disciplined in your design.

Modular, Composable, Standardized (3)

Beyond designing towards a component-based environment, it is also important to think about capabilities independent of a given process so you have more agility in how you ultimately leverage and integrate different things over time. 

Using a simple example from personal lines insurance, I want to be able to support a third-party rating solution by exposing a “GetQuote” function that takes necessary customer information and coverage-related parameters and sends back a price.  From a carrier standpoint, the process may involve ordering credit and pulling a DMV report (for accidents and violations) as inputs to the process.  I don’t necessarily want these capabilities to be developed internal to the larger “GetQuote”, because I may want to leverage them for any one of a number of other reasons, so that smaller grained (more atomic) transactions should also be defined as services that can be leveraged by the larger one.  While this is a fairly trivial case, there are often situations where delivery efforts move at such a rapid pace that things are tightly coupled or built together that really should be discreet and separate, providing more flexibility and leverage of those individual services over time.

This also can occur in the data and analytics space, where there are normally many different tools and platforms between the storage and consumption layers and ideally you want to optimize data movement and computing resources such that only the relevant capabilities are included in a data pipeline based on specific customer needs.

The flexibility described above is predicated on a well-defined architecture that is service-based and composable, with standard integration patterns, that leverages common business objects for as many transactions as practical.  That isn’t to say that there are times where the economics make sense to custom code something or to leverage point-to-point integration, rather that thinking about reuse and standardized approaches up front is a good delivery practice to avoid downstream cost and complexity, especially when the rate of new technologies being introduced is as high as it is today.

Leveraging Standard Integration (4)

Having mentioned standard integration above, my underlying assumption is that we’re heading towards a near real-time environment where streaming infrastructure and publish and subscribe models are going to be critical infrastructure to enable delivery of key insights and capabilities to consumers of technology.  To the extent that we want that infrastructure to scale and work efficiently and consistently, there is a built-in incentive to be intentional about the data we transmit (whether that is standard business objects or smaller data sets coming from connected equipment and devices) as well as the ways we connect to these pipelines across application and data solutions.  Adding a data publisher or consumer shouldn’t require rewriting anything per se, any more than plugging in a new appliance to a power outlet in your home should require you to either unplug something else or change the circuit board and wiring itself (except in extreme cases).

Summing Up

I began this article with the observation about delivering projects by comparison with establishing an environment for delivering repeatably at scale.  In my experience, depending on the scale of an organization, there will be some level of many of the things I’ve mentioned above in place, but then a potentially large set of pain points and opportunities across the footprint where things are suboptimized.

This is not about boiling the ocean or suggesting we should start over.  The point of starting with the framework itself is to raise awareness that the way we establish the overall environment has a significant ripple effect into our ability to do things we want to do downstream to leverage new capabilities and get the most out of our technology investments later on.  The time spent in design is well worth the investment, so long as it doesn’t become analysis paralysis.

To that end, in summary:

  • Design from the end user and their needs first
  • Think and design with connected ecosystems in mind
  • Be purposeful in how you design and layer services to promote reuse and composability
  • Leverage standards in how you integrate solutions to enable near real-time processing

It is important to note that, while there are important considerations in terms of hosting, security, and data movement across platforms, I’m focusing largely on the organization and integration of the portfolios needed to support an organization.  From a physical standpoint, the conceptual diagram isn’t meant to suggest that any or all of these components or connected ecosystems need to be managed and/or hosted internal to an organization.  My overall belief is that, the more we move to a service-driven environment, the more of a producer/consumer model will emerge where corporations largely act as an integrator and orchestrator (aka “consumer”) of services provided by third-parties (the “producers”).  To the extent that the architecture and standards referenced above are in place, there shouldn’t be any significant barriers to moving from a more insourced and hosted environment to a more consumption-based, outsourced, and cloud-native environment in the future.

With the overall framework in place, the next three articles will focus on the individual elements of the environment of the future, in terms of AI, applications, and data.

Up Next: Integrating Artificial Intelligence

I hope the ideas were worth considering.  Thanks for spending the time to read them.  Feedback is welcome as always.

-CJG 07/26/2025

The Intelligent Enterprise 2.0 – The Cost of Complexity

How did we get here…?

The challenges involved in managing a technology footprint today at any medium to large organization are very high for a multitude of reasons:

  • Proliferation of technologies and solutions that are disconnected or integrated in inconsistent ways, making simplification or modernization efforts difficult to deliver
  • Mergers and acquisitions that bring new systems into the landscape that aren’t rationalized with or migrated to existing systems, creating redundancy, duplication of capabilities, and cost
  • “Speed-to-market” initiatives involving unique solution approaches that increase complexity and cost of ownership
  • A blend of in-house and purchased software solutions, hosted across various platforms (including multi-cloud), increasing complexity and cost of security, integration, performance monitoring, and data movement
  • Technologies advancing at a rate, especially with the introduction of artificial intelligence (AI), that organizations can’t integrate them quickly enough to do so in a consistent manner
  • Decentralized or federated technology organizations that operate with relative autonomy, independent of standards, frameworks, or governance, which increases complexity and cost

The result of any of the above factors can be enough cost and complexity that the focus within a technology organization can shift from innovation and value creation to struggling to keep the lights on and maintaining a reliable and secure operating environment.

This article will be the first in a series focused on where I believe technology is heading, with an eye towards a more harmonious integration and synthesis of applications, AI, and data… what I previously referred to in March of 2022 as “The Intelligent Enterprise”.  The sooner we begin to operate off a unified view of how to align, integrate, and leverage these oftentimes disjointed capabilities today, the faster an organization will leapfrog others in their ability to drive sustainable productivity, profitability, and competitive advantage.

 

Why It Matters

Before getting into the dimensions of the future state, I wanted to first clarify how these technology challenges manifest themselves in meaningful ways, because complexity isn’t just an IT problem, it’s a business issue, and partnership is important in making thoughtful choices in how we approach future solutions.

 

Lost Productivity

A leadership team at a manufacturing facility meets first thing in the morning.  It is the first of multiple they will have throughout the course of a day.  They are setting priorities for the day collectively because the systems that support them: a combination of applications, analytics solutions, equipment diagnostics, and AI tools, are all providing different perspectives on priorities and potential issues, but in disconnected ways, and it is now on the leadership team to decide which of these should receive attention and priority in the interest of making their production targets for a day.  Are they making the best choices in terms of promoting efficiency, quality, and safety?  There’s no way to know.

Is this an unusual situation?  Not at all.  Today’s technology landscape is often a tapestry of applications with varied levels of integration and data sharing, data apps and dashboards meant to provide insights and suggestions, and now AI tools to “assist” or make certain activities more efficient for an end user.

The problem is what happens when all these pieces end up on someone’s desktop, browser, or mobile device and they are left to copy data from one solution to the other, arbitrate which of various alerts and notifications is most important, identify dependencies to help make sure they are taking the right actions in the right sequence (in a case like directed work activity), and quite often that time is lost productivity in itself, regardless of which path they take, which may amplify the impact further, given retention and/or high turnover are real issues in some jobs that reduce the experience available to navigate these challenges successfully.

 

Lower Profitability

The result of this lost productivity and ever-expanding technology footprint is both lost revenue (to the extent it hinders production or effective resource utilization) and higher operating cost, especially to the degree that organizations introduce the next new thing without retiring or replacing what was already in place, or integrating things effectively.  Speed-to-market is a short-term concept that tends to cause longer-term cost of ownership issues (as I previously discussed in the article “Fast and Cheap Isn’t Good”), especially to the degree that there isn’t a larger blueprint in place to make sure such advancements are done in a thoughtful, deliberate manner.

To this end, how we do something can be as important as what we intend to do, and there is an argument for thinking through the operating implications when undertaking new technology efforts with a more holistic mindset than a single project tends to take in my experience.

 

Lost Competitive Advantage

Beyond the financial implications, all of the varied solutions, accumulated technologies and complexity, and custom or interim band aids built to connect one solution to the next eventually catches up in a form of what one organization used to refer to as “waxy buildup” that prevents you from moving quickly on anything.  What seems on paper to be a simple addition or replacement becomes a lengthy process of analysis and design that is cumbersome and expensive, where the lost opportunity is speed-to-market in an increasingly competitive marketplace. 

This is where the new market entrants thrive and succeed, because they don’t carry the legacy debt and complexity of entrenched market players who are either too slow to respond or too resistant to change to truly transform at a level that allows them to sustain competitive advantage.  Agility gives way to a “death by a thousand paper cuts” of tactical decisions made that were appropriate and rational in the moment, but created significant amounts of technical debt that inevitably must be paid.

 

A Vision for the Future

So where does this leave us?  Pack up the tent and go home?  Of course not.

We are at a significant inflection point with AI technology that affords us the opportunity to examine where we are and to start adjusting our course to a more thoughtful and integrated future state where AI, applications, and data and analytics solutions work in concert and harmony with each other versus in a disconnected reality of confusion.

It begins with the consumers of these capabilities, supported by connected ecosystems of intelligent applications, enabled by insights, agents, and experts, that infuse intelligence into making people productive, businesses agile and competitive, and improve value derived from technology investments at a level disproportionate to what we can achieve today.

The remaining articles in this series will focus on various dimensions of what the above conceptual model means, as a framework, in terms of AI, applications, and data, and then how we approach that transition and think about it from an IT organizational perspective.

Up Next: Establishing the Framework for the future…

I hope the ideas were worth considering.  Thanks for spending the time to read them.  Feedback is welcome as always.

-CJG 07/24/2025

Four Years In: The Patterns That Define Performance and Leadership

Having had this blog for nearly four years, I took a look at the nature of the articles written to date, and subjects included therein, wondering if there were any patterns that emerged.  I found the resulting chart (above) interesting as a reflection of the relative importance I associate with certain topics overall.  To that end, I thought I’d provide some perspective on what’s been written to date before moving to the next article, whatever that may be.

 

Leadership and Culture

The two largest focus areas were leadership and culture, which isn’t surprising given I’ve worked for many years across corporate and consulting environments and have seen the relative impact that both can have on organizational performance on the whole.  Nearly two-thirds of my articles to date touch on leadership and one-half on culture, because they are fundamental to setting the stage for everything else you want to accomplish.

In the case of organizational excellence, courageous leadership has to be at the top of the list, given that difficult decisions and a level of fearlessness are required to achieve great things.  By contrast, hesitancy and complacency will almost always lead to suboptimized results, because there will be apprehension about innovating, challenging the status quo, and effectively managing relationships where the ability to be a partner and advisor may require difficult conversations at times.

With leadership firmly rooted, it becomes possible to establish a culture that promotes integrity, respect, collaboration, innovation, productivity, and results.  Where one or more of these dimensions is missing, it is nearly impossible to be effective without compromising performance somewhere.  That isn’t to say that you can’t deliver in an unhealthy environment, you certainly can and many organizations do.  It is very likely, however, that those gains will be short-lived and difficult to repeat or sustain because of the consequential impact of those issues on the people working in those conditions over time.  In this case, the metrics will likely tell the tale, between delivery performance, customer feedback, solution quality, and voluntary attrition (to name a few).

 

Delivery and Innovation

With the above foundation in place, the next two areas of focus were delivery and innovation, which is reassuring given that I believe strongly in the concept of actionable strategy versus one that is largely theoretical in nature.  Having worked in environments that leaned heavily on innovation without enough substantive delivery as well as ones that delivered consistently but didn’t innovate enough, the answer is to ensure both are occurring on a continual basis and managed in a very deliberate way.

Said differently, if you innovate without delivering, you won’t create tangible business value.  If you deliver without ever innovating, at some point, you will lose competitive advantage or risk obsolescence in some form or other.

 

The Role of Discipline

While not called out as a topic in itself, in most cases where I discuss delivery or IT operations, I mention discipline as well, because I believe it is a critical component of pursuing excellence in anything.  The odd contradiction that exists, is the notion that having discipline somehow implies bureaucracy or moving slowly, when the reality is the exact opposite.

Without defined, measurable, and repeatable processes, it is nearly impossible to drive continuous improvement and establish a more predictable operating environment over time.  From a delivery standpoint, having methodology isn’t about being prescriptive to the point that you lose agility, as an example, it’s about having an understood approach that you can estimate and plan effectively.  It also defines rules of engagement within and across teams so that you can partner and execute efficiently in a repeatable fashion.  Having consistent processes also allows for monitoring, governing, and improving the efficiency and efficacy of how things are done over time. 

The same could be said for leveraging architectural frameworks, common services, and design patterns as well.  There is a cost for establishing these things, but if you amortize these investments over time, they ultimately improve speed, reduce risk, improve quality, and thereby reduce TCO and complexity of an environment once they are in place.  This is because every team doesn’t invent their own way of doing things, ultimately creating complexity that needs to be maintained and supported down the road.  Said differently, it would be very difficult to have reliable estimation metrics when you never do something in a consistent way and analyze variance.

 

Mental Models and Visualization

The articles also reflect that I prefer having a logical construct and visualizations to organize, illustrate, analyze, and evaluate complex situations, such as AI and data strategy, workforce and sourcing strategy, digital manufacturing facilities, and various other situations.  Any of these topics involve many dimensions and layers of associated complexity.  Having a mental model, whether it is a functional decomposition, component model, or some other framework, is helpful for both identifying the dimensions of a problem, and also surfacing dependencies and relationships in the interest of driving transformation.

Visualizations also can help facilitate alignment across broader groups of stakeholders where a level of parallel execution is required, making dependencies and relationships more evident and easier to coordinate.

 

Wrapping Up

Overall, the purpose of writing this article was simply to pause and reflect on what has become a fairly substantive body of work over the last several years, along with recognizing the themes that reoccur time and again because they matter when excellence is your goal.  Achieving great things consistently is a byproduct of having vision, effective leadership, discipline, commitment, and a lot of tenacity.

I hope the ideas were worth considering.  Thanks for spending the time to read them.  Feedback is welcome as always.

-CJG 07/14/2025

Why Excellence Matters

A new leader in an organization once asked to understand my role.  My answer was very simple: “My role is to change mindsets.”

I’m fairly sure the expectation was something different: a laundry list of functional responsibilities, goals, in-flight activities or tasks that were top of mind, the makeup of my team, etc.  All relevant aspects of a job, to be sure, but not my primary focus.

I explained that my goal was to help transform the organization, and if I couldn’t change people’s mindsets, everything else that needed to be done was going to be much more difficult.  That’s how it is with change.

Complacency is the enemy. Excellence is a journey and you are never meant to reach the destination.

Having been part of and worked with organizations that enjoyed tremendous market share but then encountered adversity and lost their advantage, there were common characteristics, starting with basking in the glow of that success too long and losing the hunger and drive that made them successful in the first place.

The remainder of this article will explore the topic further in three dimensions: leadership, innovation, and transformation in the interest of providing some perspective on the things to look for when excellence is your goal.

Fall short of excellence, you can still be great.  Try to be great and fail?  You’re going to be average… and who wants to be part of something average?  No one who wants to win.

Courageous Leadership

As with anything, excellence has to start with leadership.  There is always resistance and friction associated with change.  That’s healthy and good because it surfaces questions and risks and, in a perfect world, the more points of view you can leverage in setting direction, the more likely you’ll avoid blind spots or avoidable mistakes just for a lack of awareness or understanding of what you are doing.

There is a level of discipline needed to accomplish great things over time and courage is a requirement, because there will inevitably be challenges, surprises, and setbacks.  How leaders respond to that adversity, through their adaptability, tenacity and resilience will ultimately have a substantial influence on what is possible overall.

Some questions to consider:

  • Is there enough risk tolerance to create space to try new ideas, fail, learn, and try again?
  • Is there discipline in your approach so that business choices are thoughtful, reasoned, intentional, measured, and driven towards clear outcomes?
  • Is there a healthy level of humility to understand that, no matter how much success there is right now, without continuing to evolve, there will always be a threat of obsolescence?

Relentless Innovation

In my article on Excellence by Design, I was deliberate in choosing the word “relentless” in terms of innovation, because I’ve seen so many instances over time of the next silver bullet meant to be a “game changer”, “disruptor”, etc. only to see that then be overtaken by the next big thing a year or so later.

One of the best things about working in technology is that it constantly gives us opportunities to do new things: to be more productive and effective, produce better outcomes, create more customer value, and be more competitive.

Some people see that as a threat, because it requires a willingness to continue to evolve, adapt, and learn.  You can’t place too much value on a deep understanding of X technology, because tomorrow Y may come along and make that knowledge fairly obsolete.  While there is an aspect of that argument that is true at an implementation level, it gives too much importance to the tools and not enough to the problems we’re ultimately trying to solve, namely creating a better customer experience, delivering a better product or service, and so on.

We need to plan like the most important thing right now won’t be the most important 6 months or even a year from now.  Assume we will want to replace it, or integrate something new to work with it, improving our overall capability and creating even more value over time.

What does that do?  In a disciplined environment, it should change our mindset about how we approach implementing new tools and technologies in the first place.  It should also influence how much exposure we create in the dependencies we place upon those tools in the process of utilizing them.

To take what could be a fairly controversial example: I’ve written multiple articles on Artificial Intelligence (AI), how to approach it, and how I think about it in various dimensions, including where it is going.  The hype surrounding these technologies is deservedly very high right now, there is a surge in investment, and a significant number of tools are and will be hitting the market.  It’s also reasonable to assume a number of “agentic” solutions will pop up, meant to solve this problem and that… ok… now what happens then?  Are things better, worse, or just different?  What is the sum of an organization that is fully deployed with all of the latest tools?  I don’t believe we have any idea and I also believe it will be terribly inefficient if we don’t ask this question right now. 

As a comparison, what history has taught us is that there will be a user plugged into these future ecosystems somewhere, with some role and responsibilities, to work in concert (and ideally in harmony) with all this automation (physical and virtual) that we’ve brought to bear on everyone’s behalf.  How will they make sense of it all?  If we drop an agent for everything, is it any different than giving someone a bunch of new applications, all of which spit recommendations and notifications and alerts at them, saying “this is what you need to do”, but leaving them to figure out which of those disconnected pieces of advice make the most sense, which should be the priority, and try somehow not to be overwhelmed?  Maybe not, because the future state might be a combination of intelligent applications (something I wrote about in The Intelligent Enterprise) and purpose-built agents that fill gaps those applications don’t cover.

Ok, so why does any of that matter?  I’m not making an argument against experimenting and leveraging AI.  My point is that, every time there is surge towards the next technology advancement, we seldom think about the reality that it will eventually evolve or be replaced by something else and we should take that into consideration as we integrate those new technologies to begin with.  The only constant is change and that’s a good thing, but we also need to be disciplined in how we think about it on an ongoing basis.

Some questions to consider:

  • Is there a thoughtful and disciplined approach to innovation in place?
  • Is there a full lifecycle-oriented view when introducing new technologies, to consider how to integrate them so they can be replaced or to retire other existing, potentially redundant solutions once they are introduced?
  • Are the new technologies being vetted, reviewed, and integrated as part of a defined ecosystem with an eye towards managing technical debt over time?

Continual Transformation

In the spirit of fostering change, it is very common for a “strategy” conversation to be rooted in a vision.  A vision sets the stage for what the future environment is meant to look like.  It is ideally compelling enough to create a clear understanding of the desired outcome and to generate momentum in the pursuit of that goal (or set of goals)… and experience has taught me this is actually NOT the first or only thing important to consider in that first step.

Sustainable change isn’t just about having a vision, it is about having the right culture.

The process for strategy definition isn’t terribly complicated at an overall level: define a vision, understand the current state, identify the gaps, develop a roadmap to fill those gaps, execute, adapt, and govern until you’re done.

The problem is that large transformation efforts are extremely difficult to deliver.  I don’t fundamentally believe that difficulty is often rooted in the lack of a clear vision or as simple as having execution issues that ultimately undermine success.  I believe successful transformation isn’t a destination to begin with.  Transformation should be a continual journey towards excellence.

How that excellence is manifest can be articulated through one or more “visions” that communicate concepts of the desired state, but that picture can and will evolve as capabilities available through automation, process, and organizational change occur.  What’s most important is having courageous leadership and the innovation mindset mentioned above, but also a culture driven to sustain that competitive advantage and hunger for success.

Said differently: With the right culture, you can likely accomplish almost any vision, but only some visions will be achievable without the right culture.

Some questions to consider in this regard:

  • Is there a vision in place for where the organization is heading today?
  • What was the “previous” vision, what happened to it, did it succeed or fail and, if so, why?
  • Is the current change viewed as a “project” or a “different way of working”? (I would argue the latter is the desired state nearly in all cases)

Wrapping Up

Having shared the above thoughts, it’s difficult to communicate what is so fundamental to excellence, which is the passion it takes to succeed in the first place. 

Excellence is a choice.  Success is a commitment.  It takes tenacity and grit to make it happen and that isn’t always easy or popular. 

There is always room to be better, even in some of the most mundane things we do every day.  That’s why courageous leadership is so important and where culture becomes critical in providing the foundation for longer-term success.

I hope the ideas were worth considering.  Thanks for spending the time to read them.  Feedback is welcome as always.

-CJG 06/05/2025