The Hedberg Strategy

Mitch Hedberg, a beloved comedian taken from the world too soon, once said, “If you find yourself lost in the woods, f%&! it, build a house. ‘Well, I was lost but now I live here! I have severely improved my predicament.’”

Many of us have met organizational leaders who employ the Hedberg strategy. The combination of people, process, and systems in which they find themselves could be equated to being lost in the woods. Rather than work their way back out of the woods, they build a house. They grow comfortable with the lack of vision, the disjointed culture, and the poor quality of the results stemming from their team or organization. Then they decorate, trimming inefficiencies and adding incremental value from within a broken system. They may even get bonuses and promotions. The short‐term loss from the employment of this strategy is wasted human and organizational potential. The long‐term loss is the risk of the organization becoming defunct or reaching an existential crisis that requires a top‐to‐bottom redesign and restructuring of the whole organization.

A Broken System

The prevailing process by which most information or operational technologies intake projects from the rest of their organizations is focused on use cases and problems. This is then transformed into requirements that become the basis for finding an adequate vendor or designing and building a solution. When a given solution introduces a new problem, a new set of requirements to solve that problem are generated. The default trajectory of this process is incremental improvements on an existing system of ever‐growing technical debt.

It should be noted that this process, with its emphasis on governance and streamlining, arose as a problem‐solving response to the chaos experienced by most organizations in the early days of migrating from an analog to a digital world. When marketing analytics platforms, developed to understand viewership and engagement of an organization's website, first became available, in the absence of a process, marketing executives signed purchase orders or, more often than one would believe, used a corporate credit card, without the knowledge of the information technology organization. This behavior spread across organizations despite attempts to add processes for governance and streamlining. Even today, many business unit leaders choose to move forward on a vendor or solution while intentionally leaving their internal information technology colleagues out of the process entirely, or at a minimum, out of the procurement process. This takes place when they do not agree with the decision of their internal information technology organization or when they are not willing to wait for a formal review or procurement process.

Advisors who see this paradigm and its long‐term implications face a moral dilemma when they know that their solution will solve a current problem (or use case) at the risk of detrimentally impacting the whole system in the future. They are incented to sell their solutions, not to solve a client's systemic trajectory. Additionally, the client is typically incented to report a specific, measurable impact (such as an increase in profitability) within the quarter or fiscal year, and is therefore likely to move forward with another vendor who is willing to propose a solution. The successful delivery of the project can then be used to secure more budget or be leveraged by the internal leader to get promoted, be granted additional headcount, or win an award.

On this last point, any systems‐thinking‐oriented advisor has undoubtedly run into this with their clients when they have defined a discrete problem they would like to solve, ideally within a certain time frame, and within their budget. When external advisors go through the process of pulling back the layers to ensure that the engagement will produce the best possible impact on the organization as a whole, and they identify that the problem the client has identified will not improve the performance of the broader system and that it would be best to include leaders from other organizations or to rescope the initiative, clients have reactions ranging from shock to rage to gratitude. The experience of shock and/or rage leads to less and less of this behavior except with clients with whom there is established trust.

Based on this history, the current iteration of the informational and operational technology project intake process is an improvement of the system. To any rational technology leader confronted with the obvious problem of each business unit making technological purchases without technological expertise or a system‐wide view of the long‐term implications, governance and process become the logical solution.

So why isn't it working?

It is a systems issue. The complexity of digital capabilities and advanced technologies have outgrown mechanistic processes and approaches, and a social systems approach is now needed. We are trying to improve on the current system without reexamining these organizations (information technology, operations technology, marketing, finance, etc.) as parts of a larger containing system.

That larger system exists to create value in a given sector at a pace that retains or expands its customer base and market competitiveness in order to sustain its ability to create value. Another layer upward shows that the organization exists within the broader system of the market, which has undergone a sweeping change, with looming disruptive forces, requiring the organization to accelerate its rate of value creation.

This understanding of the larger system, disaggregated back to an understanding of the subsystems within an organization, reveals the problem with the current structures and processes, which have not been designed with market competitiveness in mind, nor the broader organization's ability to create value in the market. Rather, the current structure and processes in most, but not all, organizations, is designed to maintain the current system.

Within this dynamic, innovative projects or new technologies discovered by business units become a threat to the stability of the existing system. The resultant adverse reaction in many organizations, unfortunately, has often increased the likelihood that business unit leaders create partnerships and sign agreements without consulting their internal counterparts.

One Reimagining of Internal Technology Organizations

To borrow from the story of Bell Labs earlier in this book (Chapter 6), if one were to design an organization from scratch today, given the understanding of the market just described and without any context of the existing organization, that design, along with other strategic priorities, would ensure that anything that provides “drag” to the speed of value creation is reimagined.

There are many ways this could be reimagined, the best of which would take into account both analysis of the existing organization, as well as synthesis of the broader market in which the organization creates value.

Counterintuitively, at first, the context of the technology market and ecosystem should also be considered, as information and operations technology organizations are not only a part of the system of their overarching organization or company, but are also a part within the system of the technology market and ecosystem, with whom they are competing for budget for technology projects, talent, and on whom they rely in order to create and maintain value.

When examining the broader technology market within which internal information and operations technology organizations are competing for projects from business units, there are two primary external competitors: consulting firms and product companies.

Consulting firms provide a rich repository of different structures, processes, and systemic design when examining how one might reimagine an internal technology organization.

An example of the difference between consulting firms and most modern organizations is that the structure of almost all consulting firms includes multiple reporting lines. At any given time, consultants are responsible to an account to which they have been assigned, a practice in which they are responsible for developing themselves as well as others, and whatever projects they have sold or to which they have been assigned. Incentives are aligned to delivering on existing projects, practice development, contribution to an account, and, depending on position, selling new projects.

In my own experience as a practice leader, my annual salary was broken into parts that relied on my ability to balance these priorities. I needed to find, attract, hire, retain, and grow the best talent in my practice areas while supporting sales discussions and providing attractive project proposals to clients to win the business and contribute margin to the firm while also maintaining consistent, quality delivery of existing projects to maintain client trust, gather case studies, and earn the right for future projects.

Put simply, my annual incentives would be reduced if my proposals were not the top proposals in a given procurement process, and even if they were, my incentives would be impacted if my team could not deliver the project at the right quality and within the budget that I had proposed. Furthermore, these were interdependent, as my ability to secure interesting and meaningful projects with clients was the basis of my ability to hire the best talent, which was the basis of my ability to secure and deliver projects.

Translating this example back into the context of reimagining internal technology organizations, if those organizations transitioned to “internal consulting firms,” approaching the business units they supported as accounts, the technological areas in which they develop and maintain as practices, and (1) structured incentives based on the ability to deliver initiatives on time and at the right level of quality, and (2) structured their entire budgets on the basis of what initiatives they were able to win from their internal clients in a competitive bidding process.

Another rich insight from the field of consulting that could be applied to internal technology organizations is the idea of the bench. For those unfamiliar with the consulting industry, “the bench” is where consultants go in between project assignments. The bench exists in consulting because consultants can only bill to projects for which a project leader has budgeted a set of hours assigned to a specific task within the overall project plan. In other words, if there is not a need for a specific consultant on a project that could be justified to directly impact the margin of that project or an increase in spend from the client, that consultant is instead directed to the bench until they are able to secure their next project assignment.

“The bench” in consulting has two other important implications in the context of organizational reimagining. The first is the motivation the bench provides to consultants. Boutique firms typically do not pay consultants when they are on the bench. This is extremely motivating for consultants in terms of ongoing skill development as well as building deep relationships with clients and practice leaders. Being relegated to the bench means either that the market does not currently have a need for a consultant's skill set, that the consultant does not have the confidence of practice leaders or clients to deliver within that skill set, or that the firm is not able to gain client confidence in the firm's ability to deliver within that skill set. The first drives consultants to keep a razor‐sharp perspective on the direction of the market and the ongoing development of their skills so as to secure assignments over other consultants. The second drives consultants to be rigorous in their delivery so as to foster and maintain confidence in their ability to deliver value within their domains. Even in organizations where there is a “paid bench,” a low level of allocation or billable hours brings the risk of eventually being let go from the firm. In other words, the system of a consulting firm is designed in such a way that it is virtually impossible to “coast.” Keeping one's job within a consulting firm requires constantly honing one's skills, ensuring exposure of those skills and delivery to leadership, and developing meaningful relationships.

On top of this, if a consultant does not exhibit high‐quality work, the way most contracts are structured, the whole project could be canceled or the client can request that the consultant be dropped from the project, which would yield a severe blow to that consultant's career trajectory within that firm.

An examination of the typical modern internal technology organization, as a system, reveals a lack of these fundamental motivational drivers. Internal technology team members do not face the risk that, if their skills are deemed below the standards required by a business unit they support, they could be allocated to the bench and their salary or chargeability be dropped until they are reassigned. They also do not face the same risk that, if they deliver below expectations or fail to adequately maintain a positive relationship with their internal client, they could once again be relegated to the bench and not selected for future projects.

Likewise, most internal practice leaders, such as an internal software development leader, are not funded based on approved proposals for their internal counterparts, the successful project awards of which would be directly tied to their incentives and ability to maintain their practice. Instead, they generally serve as an internal bureaucracy, taxing business units regardless of the degree of the value they create.

One of the key systemic differences between internal technology organizations and an external consulting firm, which has no doubt been in the back of the mind of anyone from those organizations who is reading this chapter, is the need to develop and maintain the network of technological systems required for the overarching business and all of its functions to continue to create value. This is not a trivial task, and has historically been one of the key inhibitors of the reimagining of these functions.

There are many ways in which this aspect of the system could be addressed. For example, an committee for applied analysis and synthesis could be instilled to benchmark the competitiveness and performance of the network of technological systems against the backdrop of the broader market (like an internal Gartner or Forrester), and an element of each practice leader's incentives could be based on the health and performance of any aspects of the overarching system impacted by their practice throughout a given fiscal period. A corporate tax could continue to be maintained across the broader organization, but rather than funding the core headcount of the organization, it could be leveraged for building components of the network of systems that would improve the performance of the whole system and unlocking new horizontal capabilities that are irreducible and would not have been justifiable within the context of a single, vertical initiative.

This kind of internal transformation would also impact the overarching organization's approach to the ecosystem. This book dives deeper into ecosystems and the idea of “surprising and remarkable” partnerships later, but in the meantime, imagining a before/after paradigm of a conversation with a business unit leader, an internal technology organization, and an external consulting firm or product company illustrates the potential of this kind of reimagining.

Today, external organizations systematically target both internal technology organizations and business unit leaders, depending on their strategy and offerings. Meeting with a business unit leader without an internal technology counterpart is likely, and there is sometimes even a discussion on how to jointly navigate the internal technology process or team. Conversely, I have been told by account leaders that the chief information officer expressly instructed them, as external advisors, never to speak with business unit leaders without the presence of information technology team members. These are symptoms of this systemic issue, and not necessarily the fault of any one person, but, as my former boss at Underwriter's Laboratories would say, “It doesn't matter if it's our fault, it's our responsibility to fix it.”

In the future of this reimagined scenario, because internal technology organizations share an incentive to ensure that the overarching organization delivers value at the speed necessary to retain and/or expand market share and market competitiveness, the idea of “shadow IT” could be eliminated almost overnight.

I recently spoke with a leader from a multibillion‐dollar manufacturing company, in which new team members, when they are hired into their internal technology organization, go on a tour of the various groups the organization supports—not just to watch, but to participate. They spend a shift picking in the warehouse, taking customer calls, and assisting in manufacturing. This is a phenomenal method to generate understanding of what it takes to perform those jobs and would be great to see adopted more broadly. Taken a step further in the reimagining above, these team members could be incented based on business outcomes for the organizations they support. If a new team member not only takes customer calls to generate empathy and understanding of the experience of the internal customer support agents and customers, but does so with the knowledge that their incentives will be directly tied to metrics such as customer satisfaction (CSAT), average time to resolution, and net promoter score, this “skin‐in‐the‐game” approach would pivot the orientation from reactive to proactive, driving team members to keep up with the latest technological advancements and methodologies for increasing customer satisfaction.

I saw this firsthand when I worked with a company whose product team created a subproduct team focused on improving the customer service experience. They built an entirely new suite of tools from the ground up to create the future of customer service that could not be supported by existing tools in the market, creating multiple capabilities that had not existed before. These technologists were coming up with extremely creative ideas and launching new software features to the customer service organization every two weeks. They treated the customer service agents like their end customers and they came to the table in each meeting with the customer service organizational leaders with their technological plans and ideas for tools they wanted to build and buy to improve the agent and end customer experience. It should be no surprise that this kind of internal partnership drove the net promoter score to an industry‐leading number and customer service agents reported much higher job satisfaction than their peers within a different team in a different customer service team within the overarching organization.

In the case that an organization does not have the headcount to dedicate internal technology team members to individual lines of business, the outcome‐based incentives could align to individual projects.

A Second Reimagining of Internal Technology Organizations

It was noted earlier that there are many possible reimaginings of internal technology organizations (as there are of any internal organization). Another reimagining is based on a second external force that competes with internal technology organizations for budget: product teams. These product teams are delivering new features to market at high speeds, are obsessed with their customers, and are focused on being easy to do business with. Examining product companies through the lens of analysis and synthesis yields a multitude of insights.

Product companies do not have practices as consulting firms do—they are organized by product. Each product typically has a vertically integrated team that includes all of the skills and capabilities required to build and maintain their product.

There are several different types of product companies: those focused on solving specific problems (point solutions), those focused on creating platforms for customers to solve their own problems (often with the help of consulting firms), and those focused on solving a suite of problems within a specific vertical domain.

Did you catch it? Even the way product companies are often described is in the context of problems. This thinking is so pervasive that it will take an intentional, focused effort to peel it back (if you are not reading this book linearly, I am referencing Chapter 6).

Ignoring the “problem” problem for now, synthesis thinking applied to product companies asks what role or function product companies serve in the broader system of the market. This can be observed through a thought experiment: imagining the market without any technology product companies. No Microsoft, no Apple, no Alphabet, no IBM, and so on. Imagine the path ahead if all of these companies and technology product companies as a category vanished overnight, and each individual organization was required to develop its own technologies to improve its ability to create value in the market. Every corporation would need to write its own software for spreadsheets and then build a team to maintain, add new features to, and debug that software, along with homegrown software applications for every imaginable function across the organization; the cost center for technology within the organization would skyrocket.

Technology product companies alleviate this need by providing solutions and capabilities to every organization at a fraction of the price it would cost them to develop and maintain it themselves. When Microsoft releases a new feature for Excel, whether it costs them a million or $200,000 to build, the cost only occurs once, and more than 30 million users around the world benefit from that new feature while continuing to only pay a monthly subscription fee as opposed to hiring and maintaining a spreadsheet software development team.

This approach is valuable for organizations not only from a cost perspective, but also from a feasibility perspective, as there is a limited number of advanced computer scientists in the world. When technology organizations incubate new products with a dozen or couple dozen researchers, that benefit is provided back to customers who may not have the resources or be able to source and retain the talent necessary to create that capability within their organization.

Disaggregating the function product companies play in the broader system of the market back down to insights that could inform the reimagining of internal technology organizations, product companies create value and are measured on their user base and subscription revenue.

If internal technology organizations were measured on usage and subscription revenue, an approach notably more experimental than the consulting‐firm approach, business units could choose to unsubscribe from a service when they feel that the cost of that service does not justify the value it provides. This would mean bundling each service provided by the internal technology organization into a subscription price, which business unit organizations could weigh against subscriptions outside the organization. An important caveat to this approach is, because the entire stack would be vertically integrated, the subscription would almost inevitably be more than an external subscription. In order to ensure that the entire long‐term picture is taken into account, external proposals should be weighed together with the implementation cost. I observed this mistake at a former organization, which ended up paying $65 million for the implementation of software that could have been built for less than $2 million and maintained for less than $500,000 per year.

This line of thinking begins to develop a hypothetical system that, now that a rough structure has been described, could be incrementally improved and examined from multiple angles until a clear picture has emerged and the organization can consider whether the proposed reimagination is both viable and the right direction to consider taking the organization.

A second line of thinking when considering the reimagination of internal technology organizations within the context of product companies through the lens of synthesis is whether product companies serve any other functions in the market beyond those previously examined. Cost savings and centralizing talent for solutions that impact a broad swath of organizations is critically important, but there is a limit to the function these companies can serve in this capacity, as the more domain‐specific value created by a given product, the fewer overall customers they can serve.

This leaves a gap in the market, as the companies with the most revenue, and that can therefore offer the most competitive packages to secure top talent, are incented to create domain‐agnostic software. The prevailing solution to this gap is a reliance on partners to directly build solutions on behalf of customers as well as intellectual property that can be leveraged to shorten the length of time it takes to implement a domain‐specific project for future clients on the product company's platform.

The relevance of this paradigm for an organization in any industry other than technology is that if there is a need to build a new capability that does not yet exist in the market, is not simple enough to be a simple off‐the‐shelf solution from a platform company, and would therefore require a multimillion‐dollar custom solution from a systems integrator, the organization would either be paying a premium on the system integrator's existing intellectual property, or would be funding that systems integrator's development of further intellectual property. There are cases in which either of these approaches is best for the organization. The case in which it would be worth considering an alternative approach is when the solution would be greatly applicable to many other organizations within the industry, and has yet to be developed due to the degree of domain expertise required. If the degree of required domain expertise aligns well to the core competencies of the organization, this solution could be developed in‐house, with the plan to commercialize, funneling the profits back into the internal technology organization.

The goal of walking through these thought exercises together is not to provide specific recommendations for transforming internal technology organizations. Rather, it is to demonstrate the organizational context that leaders and managers must transform in order to effectively embark on an Autonomous Transformation journey. Each suborganization within a broader enterprise or organization can be similarly examined through the lens of the problem with solving problems and the negative effect system maintenance has had on the modern organization, and how the process of applying synthesis could be leveraged to reimagine an organization. This could be applied to any vertical or horizontal aspect of an organization once a desired future state of the organization has been determined, with the goal of ensuring organizational readiness, across the social system, to advance toward a more human future.