Evolutionary Alignment

Alignment refers to the way that the organisation is structured. An organisation’s alignment is the path of minimum friction within the organisation - the easiest way to get things done. Traditionally, organisations tended to align themselves around internal concerns - business functions, work phases, resource pools, and so on. These make for efficient delivery of work within a particular domain. The finance team delivers financial reports efficiently, the legal team provides legal advice, the IT teams deliver within their specialty and so on.

Internal alignment is a constraint we impose on organisations to make the job of managing specialised resources easier. It is much easier for a single manager to manage all the data architects, or Java developers or marketing specialists. They all have the same career needs. They do similar work, they have the same skill sets. It's easy to see who outperforms who and should be promoted, and who is underperforming and should be let go. It's easy to manage them as a group. So to make the job of managing people easier, we impose a constraint of internal alignment on the organisation.

The internal structure of the organisation makes cross cutting work difficult. Each team reports to different managers, has different priorities and strategies, different KPIs to meet and so on. Even within a function like “business” or “IT” there are internal structures that work quite separately with little collaboration, and often a lot of internal competition for resources. I worked for a large organisation once where we followed a small project through the process to see if there were any bottlenecks. It was a tiny piece of work - grab a file from a third party, load it into the data lake, then write a report to use the data. It was 2 week’s work for a single developer. That work took 4 months to deliver - first the file transfer team was engaged to get the file. The request went into their queue, where it sat for 2 weeks before they did their ten minutes or so of work to set up the file transfer job. Then the scheduling team had to be engaged to schedule the job to run every day. The request went into their queue where it sat for 2 weeks, then the firewall team had to be engaged and so on. None of these teams would accept a request before the previous team had finished because that would introduce uncertainty into their planning. All up there were 6 internal teams involved for a total delay of 4 months. All the while, the contractor engaged to write the report is billing $1K/day to do nothing. The business team who wanted the report, and needed it urgently, got sick of waiting and hired their own contractor to build a database, load the data and produce the report, which created a nice piece of shadow IT, and ensured that after 4 months of waiting, the “official” solution produced by IT was never used.

Aligning around internal concerns creates situations like this all the time. Teams that are focussed on their own internal processes, and not on delivering end to end value for the organisation and its customers. The way most organisations deal with this is through projects. Create a project that temporarily brings people from different groups together to build something end to end.

As we know, projects have their own issues, like lack of long term ownership, key people being sliced thinly across dozens of different projects and so on. They are also their own internal concern. Projects are only concerned with building the thing they are tasked to build. Anything outside that is firmly “out of scope”. So things like test frameworks, infrastructure upgrades, fixing technical debt, improving processes, and so on, are frequently resisted by project managers on the grounds that they don’t directly contribute to the thing they are building, and will essentially steal part of their precious budget to build things that will help other teams and not them. Projects need to compete for resources with existing demand just like any other internal concern in the organisation. How many times have we seen a project fighting for access to a particular SME whose manager doesn't want them distracted from the important BAU work they do? Or a BAU team struggling to meet demand because all of its best people have been seconded into projects?

Projects don’t fix the alignment problem. They magnify it. But organisations persist in using them because they are often the only way to get cross cutting work done.

So internal alignment gives us isolated teams of specialists who find it difficult to collaborate across the organisation. It gives us projects as a mechanism for getting things done, which amplifies the problem by adding a new set of internal concerns and a parallel structure competing for the same resources. It also gives us structures that are rigid, inflexible and difficult to change.

Our internal silos resist change. They have their own KPIs, their own processes and, often, their own cultures. They focus on their own internal needs and not on the environment that is changing around them. They resist change that may reduce their importance. They form rigid and inflexible interfaces with other silos geared around protecting their own KPIs and resources. They limit the organisation’s ability to change and adapt.

What is needed is a switch towards an external alignment - to the way organisations deliver value. The path of least friction in an organisation should be to deliver value to its customers or clients, not around the internal management concerns of the organisation. Aligning around value gives the organisation the ability to sense and respond to changes in customer needs. It allows the organisation to sense and respond to its environment. It unlocks the organisation’s ability to evolve.

Next time we will look at the third of our Evolutionary perspectives - Evolutionary Governance.