The Line Manager gets IT right: Why Line Managers should take technology decisions.

Last spring, we found ourselves working with a global media giant,  to understand why their new high tech enterprise information sharing IT system was not being used by employees. As we plowed through the usual rigors of analyzing feedback from front-line staff, department managers and BU heads, we discovered something puzzling. While the new state-of-the-art system was hardly being used by anybody, few departments and teams used alternate custom-built IT systems to automate their processes. Most of these custom-built systems were rudimentary and offered poor user experience, and yet, every team member had adopted and used their system every day! Digging deeper, we discovered something even more surprising – The development and deployment of these systems were managed by the Line Manager (s) of these departments, who had little to no knowledge of IT or Software Development!

Why did an expensive, cutting-edge digital information system fail miserably, where a less sophisticated, custom built software succeeded with aplomb? How did non-technical line managers succeed in deploying technology effectively, where senior IT specialists failed?

Sure, deploying a new, large, complex, and organization-wide system across different locations is fraught with enormous technical challenges, but the real answer to these questions lies elsewhere.

The IT department, was attempting to solve a technology problem. However, none of the users had a technology problem. They had business problems.

Problems about information availability, sharing and communication in the context of how they got work done. Divisional, middle and operational managers, i.e. the Line Manager was in a much better position to understand these problems, since he knows the people in his teams and how they get work done. Direct involvement of the Line Manager enabled the building of IT tools which solved business problems that his/her teams faced.

In hindsight, the centralized top-down approach of IT system deployment was a mistake. The IT department never stood a chance.

Understanding the processes, practices, people and nuances of every team in a 6000 person global organization was an unrealistic expectation, especially under a tight budget and timeline. A decentralized approach to technology development and deployment, where the Line Manager was empowered to take technology decisions for his or her team, would have yielded better results.

Decentralization, as a management concept, has been around for a while. William B. Given Jr.’s book Bottom-Up Management, 1949 was probably the first to talk about Decentralization, while Drucker’s works over the last 50 years have often made the case for giving front-line managers greater control. However, it is only in the last decade that we saw an increased devolution of formerly centralized responsibilities (like human resource management, risk management, and strategic planning) to the Line Manager.
In this context, the decentralization of IT decisions is a natural step forward. Looking at our own portfolio of projects at Fingent, we see a steady increase in Line Managers successfully creating, customizing and deploying technology solutions for their departments. I believe that there are three key reasons why the Line Manager is successful in independently managing core information technology needs of his/her teams:

• Line Managers, especially those who are hands-on, are able to derive a good understanding of information architecture requirements
• A Line Manager understands of how the team gets work done, and
• A Line Manager’s ability to lead and manage changes to the ways of working.

The right information, at the right time

In relatively flat, multi-functional organizations, workers at every level have decision-making responsibilities. For such a knowledge worker, the ability to assimilate, interpret, arrange, sift and process relevant information is critical for the successful execution of day to day tasks.
Take the case of the failed digital-information IT system; asked to identify the single most important cause of failure, users across departments answered that the information necessary for work was either unavailable in the system, or was not available at the right time or in the right format. Each of the smaller systems that they were using daily was tailored to meet the specific needs of the team, providing different roles in these teams with the information they required to operate efficiently and effectively. Information was shared in the context of the tasks and stage of work, ensuring that it was available to the right person at the right time. These systems thus organized and structured information in a manner best suited to the team’s objectives. Or in other words, they had good information architectures.
Different departments/teams adding value to the organization in different ways need radically different information architectures. Information required for software developers to execute their day to day tasks is usually different from information necessary for a hardware engineer, HR personnel or Sales personnel. The IT department, which led the deployment of the failed solution, tried to create a system of compromises, and in doing so, compromised the critical needs of almost every department. This flawed approach resulted in a significant wastage of money and time.

A good information architecture secures that the right information is available to users; enabling a good technology system to use this information architecture for delivering the right information to the employee at the right time.Creating a good information architecture requires: the allocation of the right resources, interfacing with supplier and customer teams ( internal or external), a good understanding of current and desired processes, and a good understanding of the strategic and tactical objectives of the department. The Line Manager for the team/department is in the best position to take ownership of this activity and to use his resources to drive the creation of a good information architecture for his team or department.

There is one specific aspect of the information architecture where the Manager must be hands-on; performance measurement. Early measurement systems were top down, with KPIs being set by Senior Executives cascading down to the teams. However, with the greater empowerment of teams, we now see teams, designing their own measurement systems, in line with corporate strategy and measurement systems, to gauge own progress. The manager of a team is often responsible for the KPIs, its methodology and also the measurement. He should determine the level of access that different roles in his team, have to these measures.
Providing the right information, to the right person at the right time often provides the base for realizing the value added by technology. This “right information” is realized using the Information Architecture used by a team. Technology can then be deployed to use this Information Architecture to deliver information to employees in the context of their day to day work. The Line manager is in the best position to drive the creation of the information architecture for his team, while securing that it is aligned with organizational strategic goals and the team’s tactical objectives.

Processes and Practice: A Line Manager knows the difference between theory and application

In addition to a good information architecture, technology must also be aligned to systems used by the department, to add value to the organization. These systems are deployed via processes, and these days almost all self-respecting departments and teams of knowledge workers have documented processes. Whether the documented process meets practice is another story entirely. In the case of knowledge work, especially work that requires moderate to high degree of autonomous and creative thinking, tacit knowledge and improvisation trumps documented processes in practice.

When automating the change management system for the pharma enterprise, we discovered that different project coordinators had different approaches, planning, reporting, risk management and interdepartmental cooperation, which often resulted in significant deviations from the documented processes. For such a department to realize the benefits of automation, documented processes alone are insufficient. It is vital to consider the entire system as practiced and applied by the users, and in doing so, prioritizing the creation of tools to automate the desirable aspects of the system. It is the promise of predictability and stability in the way things get done using a system that often determines the effectiveness of deploying the software application. The Line Manager of the Department has a good view of the overall picture, people and the operational details; all of which are critical inputs to good decisions about balancing process and practice to achieve a stable system.

In the case of the pharma company, the Line/Department Manager was able to obtain the necessary strategic, operational and tactical perspective to determine specific processes and practices which were important to automate. Only he had sufficient authority and responsibility to ratify and take responsibility for these decisions. The IT department, or a 3rd party consultant, or even most people in his team would not be able to provide the unique perspective necessary to take these decisions.

The software solution we deployed for this department not only provides the benefits of automation, but also helps the team identify process deviations, enabling good decisions about the acceptance and mitigation of these deviations in day to day operations.

Often, the development of new tools and technologies is a trigger for teams to introspect and overhaul their existing systems. One of our clients, a property acquisition department at a national property management firm, re-architected their processes to take advantage of the benefits that a custom-built software application could provide. Their old system was built around the tools of pen-paper and a commodity desktop solution available then. During our early stages of pre-development analysis discussions, they realized that a custom software application, could free the department from the constraints of the commodity software, and open the doors to add value in new and innovative ways. Through mobile devices, real-time updates, and improved reporting, they could realize benefits that were not accessible to them before. They reinvented their property acquisition processes, providing significantly greater value and increasing the department’s strategic value to the organization. Such successful change was possible because the Line Manager was able to allocate a good team to work with the core process changes and technology upgrade, while he also worked with his peers and governance board, to plan and manage the delivery of business benefits.

 Providing change leadership: Who better than the Line Manager?

Like any other change program, the deployment of new software technology invariably runs into resistance from employees; often the biggest challenge to software deployment.

IT deployment often makes some previously subjective measures objective and visible to all. Employees may be nervous to reveal more information than they used to do before. Then there is inertia, the reluctance to shift from comfortable routines and practices to a different way of working.

Supporting the team to see the change brought about by technology deployment is a leadership challenge. The Line Manager is in the best position to take up this challenge.

Leading such a change requires the active, consistent and continuous engagement of all employees who will ultimately be impacted by the change. It requires the creation of trust, so issues and concerns can be discussed and evaluated freely, together with the perceptions of value and benefits of the new system. This is an undertaking that requires significant effort, often at an interpersonal level. The Line Manager is the ideal candidate to lead such an effort. As organizations become flatter, the manager is a coach and a mentor to the individuals in his/her team. Alongside tactical directives, a Line Manager can use one-to-one meetings, coffee machine conversations and other informal discussions to evangelize the need for the new system and reinforce the benefits: a better work profile, reduced workload, skill upgrades and much more.

Leading such an effort also means assembling the right people, from the very start of the technology development initiative. These are people with the right skill set, organizational credibility and influence. Assembling such a team, and providing them with purpose, while leveraging their strengths and abilities at the right time can make a big difference to the progress and the success of a technology deployment project. Some team members may be good with early phase visioning, while others may be simulated by the challenges of training and change management. Choosing the right people for the right task, and giving them the ownership of creating and deploying the new system can increase interest levels in the entire team. This also leads to  greater participation, and mitigating resistance during deployment. The Line Manager knows the strengths and weaknesses, the goals and aspirations of the individuals in his team. This enables him or her to make good decisions about mobilizing the right people for the project.

Leading this change, requires the management of day to day operations, while resources are devoted to the deployment of the new system, and while the department migrates from the old way of working to the new system. The Line Manager can secure minimal impact on ongoing operations, by allocating the necessary time (and backups) for those involved. And also providing the necessary time and support for the entire team to learn and use the new system. He can use his resources and forums to identify potential deployment blockers and mitigate such risks early. For example, staff meetings provide good opportunities to build cohesion and agreement about the new system and the deployment plan. It is also an effective way to source ideas and motivate volunteers for beta testing.

Conclusion

The choice of tools to execute a task requires combination of strategic, operational and tactical knowledge to make informed choices. The IT department in an organization, which services many lines, sections and departments, cannot be expected to have such an in-depth understanding.

The Line Manager is best positioned to have such an intimate understanding of the business and its operations. The Line Manager understands the formal and the informal processes, which gets the work done within his team. He/She knows the measures and indicators on his department’s scorecard, the data required for these and the processes which define these. He/She knows and often owns the processes that detail how his team interacts with other teams, within and outside the organization. The Line Manager understands a team’s suppliers and customers. And most importantly, the Line Manager understands the team today – the people who work for him today, their capability, their skillset and he/she understands the team required for business tomorrow – the capabilities and skill set required to keep up with a changing business environment. From an organizational perspective, giving ownership of technology to the people who will use it, empowers them with greater control and responsibility towards the outcomes expected from them.