The organization chart as we know it today was created by Daniel McCallum around 165 years ago, being initially the preserve of industrial engineers. However, by the early 1960s, the term ‘organigram’ had established itself and the organization chart became part of the fabric of corporations across the globe.

The limitations of organization charts have been well documented, including aspects such as the fact that they must be continually reviewed, ignore the customer aspect, show formal rather than informal relationships and provide no clues as to where the talent lies in the organization.

I would argue that in many cases the organization chart even presents a kind of distorted perception among employees on how the business actually functions. They are all too often used to show a ‘chain of command’ which ignores the reality of much of our working life.

Why pick on something as banal as an organization chart you might ask? Well, while the organization chart might have been a useful concept to provide a view of the structure of a business such as the Tabulating Machine Company (pictured above) back in 1917, I believe that it all too often promotes a silo-based culture and thought process that is counter to the transformational shift organizations require to deliver the Digitalisation of business processes.

It has long been understood that software development is much more than coding in that complex social and human factors are critical in delivering successful projects. Agile Development methods were seen as having the potential to alleviate these issues, however, until now much of the agile way of working has been left to the preserve of the IT Division or silo.

I’m sure many of you have seen situations whereby the Product Owner function, which is critical to Agile Delivery, is being carried out by a proxy nominated in the IT Division rather than by someone on the ‘business side’ with embedded knowledge of the actual business processes and the associated revenue responsibility.  

The introduction of a poster child method of scaling agile at Spotify with exotic terms such as Squads, Tribes, Chapters, and Guilds in the last years is an extremely welcome development. However, I would remain concerned about how this is implemented in many corporate settings.

The simple temptation to rename some departments as Squads and divisions as Tribes is one factor as this ignores the demand to step back and make the enterprise-wide transformation that is necessary. One even has to wonder if the term Enterprise Agile is something of an oxymoron akin to a term like Global Democracy. Deciding on how to accommodate the support functions as well as how monolithic legacy platforms are integrated is a significant challenge. It is somewhat comical to see organizations move from implementing standards like CMMI to standards like SAFe (Scaled Agile Framework) in a heartbeat. Regardless of jargon and method, getting the organizational setup right is fundamental to unlocking the potential for digital transformation within the business.   

Moreover, the sheer range of technologies and external partners required to deliver digitalization projects demands new ways of working that are intrinsically cross-functional. The use of group-based communication platforms such as Slack, Jira, and Wrike has made such collaboration much easier and resulted in a marked increase in the capacity of decentralized development teams.

Whatever stage you find yourself at on your journey towards the digitalisation of your core business, why not challenge your existing organisational chart to create a decentralised environment that supports cross-functional collaboration and communities of practice?