I took the helm of an IT operations department at a financial firm faced challenges in balancing its operational duties with urgent projects like audit findings and security fixes. The department had been through a fifteen-year period of high turnover at the top—nine people had held the role in that time. Among the forty personnel were fifteen who worked for a vendor who had been under contract for more than thirty years. Despite the size of the team the management structure had only been rebuilt three months prior to my taking the job, as one of the previous department managers had flattened the organization.
Operations were stable due to the tireless efforts of engineers who in many cases had been operating without a boss for years. But the list of challenges that would require special projects was daunting: the baseline technology level was fifteen years out of date; a new compliance regime assumed roles and processes that simply didn't exist; an aggressive security campaign was needed, following a series of breaches; urgent networking changes and extensive automation were required to support the pandemic-fueled shift to work-from-home; and Group IT services had mandated a cloud migration.
A management team had been assembled, but a lack of firm roles or a "big picture" led to prioritization conflicts, duplication, rework, missed deadlines, and outright project failure. Asking the new management structure to deal with this meant that they had to sort out the company's priorities while already swamped with normal operations. Some typical quandaries:
Some of these were management decisions within reach of the line managers, but many required a view that spanned the new management structure.
We spent several weeks putting an end to projects that had no business case or no staff to execute them. This caused some embarrassment as we cancelled things we'd already paid for, but this only served to highlight the need for a tightly-managed program. I came to realize that making lasting sense of our countless initiatives was going to take time. And it was a big enough job that it would take a dedicated owner. But I couldn't very well undo the reorganization just completed—it would not only kill momentum but it would be perceived as prolonging a long history of annual reorganization. I realized that a "weak matrix" structural model with a dedicated program manager would preserve the new chain of command while balancing the priorities.
A matrix organization has a structure in which teams report to multiple leaders for different purposes. Typically for an IT department, the two purposes are: operations; and the change program. Because this organization needed to run a number of multi-year programs that would change its processes and its ways of working, change would be constant companion. A matrix reporting structure aims to strengthen projects by ensuring that those projects are staffed and get continuous attention. Naturally, this breaks management principles such as unity of command, and it can lead to confusion and infighting if not handled properly. But the matrix design breaks down silos and causes improved communication between teams. It also means that teams need not realign with every new project—the department is already partially structured for change. The difference between "weak" and "strong" matrix models is the degree to which the teams report to the project managers: strong matrix models reduce the functional management team to ensuring that the project teams are staffed. We didn't need to go that far; a weak model in which decisions are kept with the functional management team would suffice.
I found a talented internal candidate for the change program manager, and appointed her to the task of discussing the various priorities to see if an agreed program could emerge. The resulting set of broad activities clearly had inter-related causes and benefits:
We arrived at this conclusion by deriving and adhering to some basic rules. As a "run" organization rather than a "build" team, we had to keep the lights on. Where our staff simply couldn't tackle something, we would spend on outsourced activities—this, painfully, included much of the cloud migration work. Where automation was possible, we focused on things that would result in the most dramatic improvements: freeing people's time and hopefully freeing them from having to go to the office during the pandemic.
Throughout this, it was important that the appointed change program manager was able to work without any operational deliverables. The firm had certain 7x24 obligations as well as the need for timely and accurate delivery of data. The change program manager touched none of these. And while no one understood the new compliance regime at the time, the change program manager was only asked to ensure that a tracking system was devised and faithfully employed.
We published a plan for the year to come, and with a comprehensive approach to the program we began to deliver. As the project graveyard took shape it wasn't pretty but within that year the failed projects gave way to completed projects. We started to make serious headway on our to-do list while improving production stability.
I developed a steady process of delivering written and verbal updates to the staff. This included celebrating our successes, and explaining new challenges in a consistent fashion. I took it upon myself to keep positive messages around human resources and risk management a part of each communication, and constantly emphasized that we needed to train our personnel on all the new things we were doing. And though it doesn't sound like much, simply telling the staff that certain projects were coming down was a revelation. I received feedback that I had eliminated the "mystery" from the compliance and risk processes.
More formally, we started documenting our projects. Demonstrating that there was a clear connection between our investment in properly initiating our projects with a written scope and plan and then actually delivering on them, we slowly drew these project initiation artifacts into the cycle of delivering.
Though we didn't know it, we were earning the right to an improved budget. It started with the risk efforts. The audit initiatives started to close one by one. In each case, they resulted in changes to our operations and risk management maturity that we carried on as new "business as usual" processes. In some cases they gave rise to analysis that led to further long-term programs of further change to deal with underlying problems. In others, simply conducting the improvements led to necessary changes around staffing, organization, and roles.
The completion of the cloud migration led immediately to a complete overhaul of our monitoring and alerting regime. With all the assets moved to a new platform, we needed a system for tracking and responding to incidents. This entailed a discussion about who would receive such alerts, and where we would take them. This led us to the conclusion that we didn't have the right mix of personnel and that we would need a second operations office in a distant city in order to carry on operations when HQ was unavailable for weeks or months.
Our successes earned our embattled division some much needed credibility. By the beginning of the first year we found ourselves the subject of a curious reversal of fortune: I was asked what I could do with a renewed staffing budget.
We immediately made more investments into our "acceleration" team—automation, reliability, and the cloud center of excellence. We also doubled the size of the Enterprise Architecture team. The common theme between all four was that while they did not run operations, they would help us improve the throughput of the entire technology department. They would, respectively:
Three permanent results can be named: organizational, process, and culture.
The process changes were the most obvious. The new regime differed primarily from the former chaos in that with every new project we now ensure that we had the required skills and capacity for the job. This may sound obvious but it simply wasn't the case prior. Having documented projects and a visible project chart with fixed scope and objectives meant we could explain our workload and our remaining capacity for additional change. We also had an effective "project graveyard".
The key organizational change was the employment of a change program manager in a weak matrix role; this person didn't have staff of their own, but rather worked through the operations teams to make things happen. This single role change opened all of the possibilities detailed here.
Culture isn't something you can change directly. But with a new era of accountability backed by a management team that was able to execute, we made it possible for people to understand that things would get done if we put them in the right priority and built on our successes. This improved the mood so much that in employee engagement surveys, the "net promoter score" rose from zero to fifty. And with an improved mood we started to see consistent collaboration, improved innovation and execution, and a great sense of pride in accomplishment.