Why Do We Underutilize Human Potential?

Large and small corporations, both in high-tech and traditional industries, now owe most of their value to investments in knowledge. These investments, creating value from the intangible assets of intellectual capital, have a better return on investment (ROI) than physical assets.  In our knowledge-based economy, effectively developing and applying intellectual capital is the key to creating value. Intellectual capital is defined by businessdictionary.com as the "Collective knowledge (whether or not documented) of the individuals in an organization or society. This knowledge can be used to produce wealth, multiply output of physical assets, gain competitive advantage, and/or to enhance value of other types of capital. Intellectual capital is now beginning to be classified as a true capital cost because (1) investment in (and replacement of) people tantamount to investment in machines and plants, and (2) expenses incurred in education and training (to maintain the shelf life of intellectual assets) are equivalent to depreciation costs of physical assets. Intellectual capital includes customer capital, human capital, intellectual property, and structural capital." 

One of the fundamental tenets of lean is the reduction of underutilized human potential. What exactly does this mean? Systems2win defines the underutilization of human potential elegantly:

Restricting employee's authority and responsibility to make routine decisions. Having highly paid staff do routine tasks that don't require their unique expertise. Not providing the business tools needed to perform and continuously improve each employee's assigned work. Not trusting your people to stop production to stop and fix a problem (jidoka). Not trusting your people to be responsible for the cleanliness, maintenance, and organization of their own work area. Not trusting people with a flat organization structure of largely self-directed teams. Not expecting (and measuring) every person to contribute to continuous improvement.

The intriguing concept in this statement is the inability to trust. This lack of trust speaks to the ecosystem of current organizational structures. Peter F. Drucker stated that the organization hierarchy in most organizations today developed as a result of World War II and the attempt to create efficiencies by structuring the firm like the military. While this organizational structure may have made sense 50 years ago, the command and control model is one which does not support the facilitation of human capital to better your organization. Through my research I would argue the military type structures in place today are ineffective in developing and applying intellectual capital and need to change.

Turf wars, politics, red tape, budget nepotism, envy, ego, greed, cronyism, short-term thinking, and rapid changes in strategic direction for no apparent reason must be removed from the culture and replaced with the fuel, the tools, the resources, and the attitudes that drive the innovative process. Any organization, whether a for-profit business, a nonprofit organization, a government agency, or an academic institution, that has a culture where there is a direct or indirect, explicit or implicit, stated or whispered vested interest in keeping things exactly the same to produce continuity and to win the elusive prize of job security will surely die a slow death and will never be a place where creativity is cherished or innovation is harvested. Cultures of innovation are places where creativity is celebrated, rewarded, and cherished at all levels in the organization. When teams are truly inspired and passionate about their work, they are much more likely to discover and to dream without the fear of “extra effort” or discretionary time (e.g., time and effort expended in the workplace beyond what is typically expected) that innovation can flourish and valuable crops can grow.

Leveraging Knowledge

In my experience, about 80% of a company's knowledge is undocumented or unshared and thus lives in the tacit knowledge world while the remaining 20% of explicit knowledge lives in documents or procedures which in that are often ignored. Think about that ratio in terms of your organization. If you are only utilizing 20% of the knowledge of your employees, what is the opportunity cost to your firm for what you miss out of your intellectual capital? If 80% of your organization's capital resides in the knowledge of your workers, managers are hobbled in their ability to make decisions regarding how those assets are utilized.

CEO's are frequently asked "What is the most important asset to your organization?" The standard response is, "Our people." While this is often the general response, it is rarely true. When asked to further define why people are an organization’s most important asset, most managers will resort to primitive answers such as, "They make our products," or "Without them we can't do anything." While these responses are certainly correct, they are a subtle gauge of a lack of trust because they only refer to the physical output of the employee.  After all what's one the first items to be cut when cash flow goes red?

This line of thinking is not only broken, it's dangerous for the future of your organization. Regardless of your product or service, your greatest asset is your people; not in what they do but in what they know. Their intellectual capital (tacit knowledge) is something that can move you from being a good company to being a great company. With knowledge empowering people, your organization can develop products your competition simply can't given the same resources.

The failure to leverage employees’ knowledge creates the opposite result. We have seen companies falter when people retire from firms that have failed to create an environment of successful knowledge transfer.

Creating Transformation

This problem is not easy to tackle. How do you transform an organization with a culture that doesn't adequately value intellectual capital into one which lives off it? What components must be in place in order to facilitate this change? It starts with management. Once management truly supports an investment in intellectual capital, significant advances can be made by following a few recommendations. As with all change, these take time and effort but they can turn your organization into a world-class institution:

A culture of innovation begins at the top but must permeate and trickle through all levels and all functions within any organization. The work ethic, transparency, simplicity, humility, integrity, and accountability of most farmers offer insights and leadership lessons for all of us, particularly leaders interested in fostering a culture committed to intellectual capital agrarianism. Norms must be put into place and enforced that foster cooperation, teamwork, candor, a sense of a common purpose, and a commitment to a set of institutional core values that transcends individual agendas and priorities. These shared values must be truly embraced by everyone, not just appear on a page on the company’s website. People are more likely to innovate and truly want to improve their workplace when they identify with and want to be governed by a set of shared institutional and consistent values and when they are confident that the fruit of their innovation labors are aligned with overall companywide strategies and goals.

As executives, dedicate yourselves to supporting substantial efforts to prevent lost knowledge but culturally and physically.  Create a culture of lean which empowers knowledge workers. Empowerment is a book in itself but to create this environment you must create what Forrester calls HERO (highly empowered and resourceful operatives). Creating a process of improvement through value streaming and Kaizen where management recruits intellectual capital accepts the recommendations for change.  Emphasize teamwork over teams. Teams refer to small groups of people working together toward a common purpose. Teamwork refers to an environment in the larger organization that creates and sustains relationships of trust, support, respect, independence and collaboration. Creating highly empowered teams that work without titles can create the shift of culture to one that prizes intellectual capital.  Focus on knowledge capture and allowing knowledge transfer. Several methods can entice team members to transfer knowledge, including mentoring, paired teams, work shadowing and simulations.

Utilizing human potential is a complex topic. Although many organizations view capturing the remaining 80% of tacit knowledge as a lost cause, it is certainly worth the effort. In reality, most firms do little to try to capture and use their human potential. However, doing so can provide exponential returns and will enable your organization to achieve greater success with minimal additional resources. I encourage delving into some of the lean communities for more advice on how to utilize human potential within your organization. 

Technical Debt is a Form of Waste

Technical debt. The term has been popular for a while and is used to refer to a lot of scenarios. It was originally coined by Ward Cunningham to help us recognize that quick and dirty coding sets us up for increased future development effort. It has expanded to include the operational support of code. In my experience, one of the most overlooked forms of technical debt is created when operational support requirements are excluded from the project life cycle.

In many companies, operational support is not considered part of the project life cycle. Operational and project work are often completely decoupled at the lower and middle levels of the IT department, only dovetailing because both divisions report to the CIO or VP of IT. However, this very component of the life cycle, operational support, can deliver the most value to the customer.

This disconnect is created when communication between IT and the rest of the business is limited. When the business defines objectives and timelines for a project with limited or no interaction with the operations team, the operations requirements that are needed to support various projects are presented in an abbreviated form or left out entirely. The project team might not even know that operations requirements exist until the code is almost ready to go live, if then.

I recently participated in an emotionally-charged meeting that was scheduled to review the root cause of the failure of a client-facing system. The project team was angry with the operations team for not supporting their code in a highly-available (HA) environment. The operations team was defensive, stating that they didn’t have the time or resources to address their backlog, including the HA environment.

The project team specified an HA environment in their runbook as part of their handoff to IT operations. The HA system was acknowledged by the operations team as a requirement to adequately support the live code, prioritized it and assigned the creation of an HA system to an operations resource. However, the HA system’s completion was not considered release-gating by the project team, so the project was declared complete as soon as the code was live.

The project team expected their live code to be considered part of the production system, with accompanying up-time SLAs. The IT operations group was working on the HA environment, but didn’t have dedicated resources on the project, so its completion was a long, drawn-out process. The same people working on HA were also doing regular maintenance tasks, working on systems for other projects, and putting out fires.

The key point of failure in this conflict was in not consciously determining the value of the various requirements in the project. It is important in this type of dispute for the business to determine where the customer value delivery exists. Most IT departments don’t consider customer value when negotiating this type of delivery. Without this determination, it is almost impossible to correctly determine where to focus resources.

Part of the miscommunication was created in the beginning of the project, when people from the operations team were not included in the project team. It was exacerbated when the code was permitted to launch without an HA environment. It really snowballed when the project team went on to the next project without fully delivering the value of the code in terms of the delivery life cycle. The operations team, with its own unique requirements, pushed code live without ensuring that the requirements were completed, and then repeated the pattern all over again.

After just a few project lifecycles, it becomes clear that the decoupling of IT operations requirements from business requirements within consecutive projects creates a backlog for IT operations that can’t be surmounted without drastic remediation efforts. Furthermore, this lack of oversight often reveals a lack of understanding of value delivery life cycles. When domains are permitted to hand their delivery over the fence to the next group they tend to value less quality over quantity.

Fortunately, this problem has a simple solution. It’s not easy, because it requires being realistic about how many projects your company can complete in a given amount of time. If you have are in the habit of ignoring IT operations requirements, you might be surprised at how much paying attention to them will slow your project completion rate.

You might have to adjust your understanding of the number of operations people you truly need to support your project work. You need to understand the value you’re creating for your customer is not realized until what you have developed is fully implemented and the customer is finding the value in it. You have done nothing relative to value delivery if you’re not ensuring the product you’re delivering is delivered in full.

In summary, pay attention to three key aspects to prevent a buildup of technical debt as a side-effect of project work:

1. Make operations requirements release-gating.
2. Don’t launch on temporary environments to get the product out.
3. Deliver your product to deliver value, not presence.Bring operations people into the project early and often in the life cycle. In fact, make them an integral part of the life cycle.

Projects are not complete unless the systems on which they live are complete and delivering value to the customer. Anything not providing value to the customer is considered waste. Be the change agent in your organization in halting the creation of technical debt.

Jen Browne and Patrick Phillips