Transformation

Three ways to think differently in 2015, Part 3 of 3: Technology and Talent

Technology and Talent: The under-rated link between simple tools and employee happiness

In the running of a company of whatever size, the hardest thing to manage is usually this: the delicate balance between the necessity for centralized control and the equally strong need for employees to have enough autonomy to make maximum contributions to the company and derive satisfaction from their work. To put it another way, the problem is exactly where within the company to lodge the power to make different kinds of decisions.”
— Thomas McCraw, American Business, 1920–2000: How It Worked

The tools organizations use have a direct impact on the quality of life of their employees. Good tools make people’s work lives better; bad tools make them much worse. Yet, hard-to-use tools continue to take center-stage for a significant portion of companies’ users. Why are we still accepting poor usability as a matter of course in the enterprise? Today we will discuss some of the reasons for this and look at several techniques to help you and your peers in leadership prioritize their people when making technology decisions.

The McCraw quote above is a broader expression of why companies often choose to implement technology: the need to establish control over business processes. This is most transparent in ERP implementations where the very concept is rooted in establishing more controlled business processes. Something we used to say about ERP systems is that even though they make some individual jobs more difficult, there is benefit to the overall organization that outweighs it. This type of thinking is still used to justify avoiding customizations or third-party bolt-ons that would make an individual’s job easier. These turn into “process fixes” which, translated to normal human language, means shifting unpleasant burdens away from the tool and onto the people doing the work. [I redacted an Uber joke that was here – we’ll open that can of worms another day]

Big technology implementations are really hard and take an enormous amount of people’s personal attention and effort. The reason people are generally ok with this is because they think they will benefit from the changes. But too often, when you look at less successful implementations, you see that things actually became more difficult for a substantial number of people.

The Problem with Complexity

Making people's jobs harder, of course, creates problems with “efficiency” and “effectiveness” and “productivity” – the pinnacle of talent management insight. All of these certainly suffer as a result of lackluster tools. The nice thing is that all three can be measured and discretely improved and they’ve been discussed extensively in research related to technology projects. In my mind, they also are only important to a point. Many companies who are focused on these metrics have reached a point of diminishing returns by now anyway.

There is an outcome that you cannot really measure: the connection between the tools and people’s happiness in their jobs. In most situations, people will not draw a direct connection between the clumsiness of their jobs and why they aren’t terribly happy performing them.

There are many reasons for this. Job happiness doesn’t represent a single factor – there is a complex matrix of factors that are weighted differently for different individuals. There are personal and professional reasons, tangible and abstract; physical and metaphysical; social and individual. Talent surveys do their best to pinpoint the source and quality of employee satisfaction, but even the people who create those surveys will tell you that establishing causality through them is an inherently flawed science. Fundamentally, most research agrees that a primary source of people’s job happiness (“satisfaction” is a loaded and misleading buzzword that I try to stay away from) is their feeling of personal connection to the overall mission of the company, and their belief in that mission.

Rosabeth Moss Kanter (@RosabethKanter), a professor at Harvard Business School, has done some wonderful research in this area. Among my favorite of her quotes is the following from a 2011 article called “How Great Companies Think Differently” (which won the McKinsey award for best business article that year). Kanter posits:

…people can be trusted to care about the fate of the whole enterprise—not just about their own jobs or promotions—and to catalyze improvements and innovations without waiting for instructions or sticking to the letter of a job description.
— Kanter, “How Great Companies Think Differently”

She prefaces this with a lengthy examination of why self-organization is desirable and why you don’t want to pigeonhole your people into overly rigid work structures. When the tools and processes people are using consume most of their time, they do not have capacity to accept change, let alone drive it. When those activities become visibly disconnected from the overall institutional mission, we need to expect they will lose a feeling of connection with the enterprise, experience less happiness about their jobs, and this will likely snowball into a number of symptoms of disconnected employees.

Arguments in Defense of the Status Quo

There are common responses to this critique I have had client leaders use as an argument against disruptive change. None of them are focused on the user. 

  • “Our retention rates are above industry averages, therefore our employees’ job satisfaction is acceptable.”

This is an incorrect attribution of causality. The assumptions in this statement include a) industry average retention rates are acceptable. Industry benchmarks can be directionally helpful, but some industries are way behind when adopting change; b) there is adequate mobility in the local market for people to change jobs at will. This is not true for many areas. Retention rates are important for a lot of reasons, but unless your tools are so bad that they are driving people away (which at this point in history would mean using UNIVAC-cards), they don’t really indicate satisfaction with tools one way or the other.

  • “Our HR surveys say our satisfaction rates are high!”

Great! This is important. It also probably means you’re compensating for your weaknesses in other areas. Like you’re giving lots of compensation and a whole bunch of PTO to people may be masking the fact that they really don’t like their jobs. The dimensions these surveys measure tend to move as a group. This doesn’t discredit the importance of the surveys and your ratings, but we need to recognize there are limits to measuring human attitudes. 

  • “Our leaders have many years of experience at our company – we promote from within so they understand the complexity truly required in our business.”

This is also great for many reasons, but it doesn’t really speak to the potential problem. This can also mean that people have accepted your processes and tools as “normal” even more and may be less likely to think changing them is feasible.

What do we do about it?

In general, enterprise technology is too complicated. There are young companies trying to change that (@Netsuite, @Zuora, @Zendesk, @SlackHQ, @Asana just to name a few), but solutions that are currently used at most organizations are overly complex. The complexity of those solutions is made up of three factors:

  1. Business processes
  2. System capabilities (including their relationships with each other)
  3. The cycle of inertia

Business process and system capabilities are complexities that most business leaders understand well. The cycle of inertia is harder to grasp and what, in my experience, leads to the least user-centered enterprise systems. Paradoxically, it’s often the users themselves who advocate for this cycle and their leadership that promotes it. 

The cycle of inertia is as follows:

  • Evolution: Organizations do things in a certain way and change it gradually over time to accommodate immediate business needs
  • Stabilization: Because they are no longer immediate needs, they stop simplifying and innovating how they do these things which eventually leads to an unnecessary amount of complexity in the business. This complexity is absorbed by the people who do the work as it is integrated into their jobs
  • Improvement: When the time comes to evaluate “improving” these things, there is resistance to change because people know how to do the more complex processes really well and they perceive the change as risky to their personal value. The improvement is stripped down to accomplish incremental benefits in the areas of most immediate importance to the users.
  • Inertia: Once the “improvement” is implemented, it ends up creating even more complexity because the incremental improvements add variation to the number of processes, data or systems. Since the organization has convinced themselves it is required for their business, they interpret this complexity as maturation. The cycle starts again.

The bigger the project and more people are involved, the harder it is to avoid this cycle. The only really effective way to overcome fully counteract inertia is by strong leadership support, but there are a few questions you should ask that can make it more likely you will be successful.

Key Questions to Ask

When talking about a prospective project, planning the project, and undergoing design, always ask these questions:

  1. Is this process absolutely necessary for our business? Can any steps be removed or variations be eliminated? The goal is to simplify. Even if the business says they need a certain process, make sure you understand what the intended outcome of that process is. Users are usually correct in insisting they need to do things in a certain way to meet their requirements; the real question is are the requirements important in the first place.
  2. What part of our business mission does this feature, software or process support? If it can’t be easily mapped – if it’s clumsily shoehorned into a part of the mission statement or if its relationship to strategy is heavily assumption driven (e.g. the strategy says we’re growing our services division and we’re assuming those services may be custom products, but that has never actually been established) then it’s not important enough to put effort into.
  3. Is the new system, bolt-on or customization required to make the system easier to use or to support a critical business process? Do not purchase additional software if it doesn’t make things significantly better from a usability or functionality standpoint. If it’s going to be supporting a specific business process, refer to question #1. It it’s critical for the business process but doesn’t make things easier, look for another option. Every additional piece of your ecosystem makes things become geometrically more complex to support. Make sure it’s justified by making the business processes simpler.

And one special question. You know if this applies to your organization. For systems that are replacing Excel or Access: Is the new system going to be easier to use than Excel and/or Access? Excel-intensive operations yield really smart Excel users. People who are great at Excel are not going to want to switch to a system with basically the same functionality they have today but without the flexibility Excel provides. Make sure the system adds value to the user experience – not just to the enterprise.

Technology Characteristics to Prioritize

These three technology characteristics have the most substantial impact on usability and the perception of usability. Weigh these strongly when evaluating a new solution anywhere in the business.

  1. User interface: Does the interface look like something employees use at home? This is too often minimized in the interest of functionality or cost. Make no mistake: for systems, form is function. If the interface isn’t as friendly as Amazon or Zappos or Zillow, it will not be considered user-friendly. Be specific and don’t be afraid to be critical. As a side-note, when working with smaller vendors don’t be afraid to communicate your ideas on how the products can be improved. Many startups will work with you on improving their products and actually rely on that type of feedback.
  2. Mobile: Will the system by available to my employees on more than one platform and does it at a minimum allow, at a maximum encourage mobility? This assumes you have a hardware policy that allows laptops, tablets and smartphones for these employees. If you have any group that is still tethered to their desks, think very long and hard about whether it is truly necessary. Mobility doesn’t just mean working from home; mobility means the ability to work in flexible teams around the office, hold group working sessions and, when necessary, work from home, hotels, airports, etc.
  3. Integration: Do the activities supported by this software interact with other groups or systems? If so, is that integration native or at least buildable? It needs to be. If you are integrating a system that will require users to complete dual entry or run reports to make the data portable you’re purchasing the wrong system.

In Summary

Improve people’s tools and give them a path, a method and a reason to continue to improve them and they will be happier with their jobs. Happy people yield positive results for them and for you and good tools multiply improvement. Strive for simplicity, humanity and continuous real improvement in your tools. Who knows – maybe your job satisfaction ratings will even improve.

Subscribe to Ronan Consulting Group - Steve's Blog by Email

Three ways to think differently in 2015, Part 2 of 3: Beyond Enablement

Beyond Enablement

On Tuesday we looked at using your exception-handling process to conceive and drive strategic improvement. Today, we will look at how pre-planned projects should be positioned to maximize their strategic value.

Something I used to tell people is that technology is not a good in-and-of itself, instead it is valuable as an “enabler” for improving something. As a result of my years doing massive transformation projects, I no longer believe this is an adequate explanation. While it’s true that a new tool or redesigned process can enable improvement or growth, if that’s the only thing it’s doing you’re missing major opportunities. If you’re going to go to the effort of doing a substantial project, it should actually propel you forward – not just enable something.

The issue with "enablement"

Some years ago I had a client who brought my team in to analyze, plan and ultimately implement a large systems transformation project. The core of the project would be replacement of a very old, cobbled-together ERP system that was no longer supported, but it would also include a number of enhancements to various boundary systems like CRM, data management, and warehouse management systems. In addition to core benefits like saving on support, less downtime and some replacement savings, the business case included a number of high-value opportunities like such as a) Automating inventory replenishment to match projected demand; b) Enhanced project profitability reporting; and c) When it was being sold to the business, executives and ultimately the board, the main selling point that the project would “enable” change in the enterprise. This was a mistake.

This messaging was interpreted to mean the project would enable them to operate their business a little better because the technology was newer, but wouldn’t substantially change the nature of their operations. As a result, as leadership responded to issues, new requirements, staffing shortages and budget constraints, higher-value “transformational” pieces of the project were shelved and it gradually devolved into a systems replacement project. This resulted in several high-value pieces of the business case going unrealized (they never tracked actual results to the business case either, but that is a post for another day). The project was successfully implemented and everything that was ultimately designed worked really well, but there was still a lot of value on the table. So what should we have done differently?

Why is the language important?

When I think of successful technology investments, I want them to drive the strategy forward. What we should have said was the project would help “drive strategic improvements into multiple areas of the business” or that it would “propel the change that was required for them to react to new market conditions.” Although it sounds like an overstatement, either of these would have been absolutely true. Most importantly, it would have changed how the executives and business leaders reacted to project exceptions:

  • They would have been more eager to put their best people and most influential leaders in key positions since they would be setting and executing strategically important parts of the business
  • They would have been more aggressive about insisting on changes to their processes and job responsibilities
  • The project would have received more visible and more powerful executive
  • There would have been more accountability for justifying the cost of the project by measuring actual benefits

Evolving to technology projects that "drive"

When I think about these projects now, I look at them in four ways:

In the pictures below, the orange dot represents the area the project will impact. The other dots represent four related but distinct areas of the business.

Replacement projects

Some system is outdated or incredibly unreliable so it needs to be replaced or upgraded. See my post from Tuesday on how to make this project more of a game changer. I won’t re-hash this again today

Enablement projects

How does the new solution improve its focus area?

Example: If you’re replacing a project accounting solution, does it make the function of project accounting easier and more accurate?

Improvement projects

This is sort of the “enablement” bucket. Am I improving this immediate area and making it easier for other areas to improve as well?

Blog 1.6.15 tech drives improvement_1.png

Example: When I implement a new project accounting solution, can I make it so the project values are visible to my receivables department and then train them to prioritize billing and cash collections by backlog and revenue? 

Projects that drive strategy

These projects drive the implementation of high-level strategy into the business and force the organization to implement, track, and improve on this strategy. These would achieve holistic transformation across the business and, in addition to achieving its core mission, force meaningful change in other important areas

Example: if your business is a products business but sees most of its future growth on the services side, when I do the project accounting project in points 2 and 3, do I change the expectations of my accounting department to not only track costs for engineering projects but also be able to report on profitability, labor time and expense, automatic estimate-to-complete, etc.? Then can I also change how projects are sold, staffed and billed based on historical data to make them more profitable and improve their quality?

Now is the time to re-frame the conversation

Technology is now going to be part of all strategic decisions you make. This year, all executives should understand how it interacts with your overarching strategy to make sure you're getting the most value out of your investments. Each investment has the ability to drive you forward; not simply to enable incremental improvement.

Last in the series, coming on Friday 1/8: Technology and talent: How tools should improve your people

Subscribe to Ronan Consulting Group - Steve's Blog by Email