LeSS is the Holocracy for IT

In the past I wrote about holocracy and self managing teams as a system of balance, stressing mutual interest propagating overall business goals like in feudal society. All teams are driven by a purpose of providing a certain service to some other entity or to the final customer.  Teams specialise in a functional domain. Coordination between teams is done through a team delegate participating in the team meetings of teams for which they have a client or provider relation.
Large Scale Scrum (LeSS) is a methodology for developing products along the lines of SCRUM adapted for scaling. It depends largely on focused teams directed at customer, product or product feature, functioning with minimal or no management overhead. Member teams work together at realising a complex product for a business represented by what is called a Product Owner in SCRUM. Coordinating happens through participation of a team members in each others team. A team is tasked with developing a component or better a feature that fits in the overall product and therefore they have to understand what is needed by the business team/unit that will be using the software product supporting their processes. As such it applies the same philosophy as Holocracy but adapted for software or ICT departments.
As holocracy teams are oriented at certain products or customer groups there should be a match with the product or feature teams identified in the software development LeSS teams. This match will ensure better understanding, efficiency as well as continuity in the development and direction of development.
When applying the logic fully, it means pairs are formed between business and ICT teams. In some cases the product provided by the ICT group might cover different customer channels, customer target groups or products addressing the clientele or at least parts of it. It might lead to priority discussions. However, relations between both sides of the story are clear. The lines of communication are short and priority discussion can be held in a transparent way with all parties involved present. Pairing will improve focus, direction and understanding of needs of both customer and the people providing the necessary services. Integrated working will avoid the need of translating business needs to IT requirements. The Product Owner as linking pin is part of the business team who understands due to proximity better than ever how development of software solutions work. The IT team will understand the needs of the business team better as they have a structural and long term relationship with the business team(s) they support even when stories are rather vague and lack information about the technical implementation of the request.
The functional focus will require a mix of technical skills and requires knowledge sharing on this level. Therefore, the creation of functional/product clusters should not lead to new silos. Technical oriented communities of practice covering the technology used within the organisation should provide a space for sharing knowledge and experiences concerning development practices and infrastructural issues related to deployment and system management. Alternatively people with specialist technical knowledge can be delegated to participate in development of a feature team to bring them up to speed. In this way one can avoid the reflex existing in current organisations to build technology oriented teams focusing on technical components  that tend to live in their world having a hard job understanding business needs.
Pushing the envelope further, a good understanding between business and ICT teams can and will lead to more innovative products and fundamental digitalisation of business processes and customer interaction. The SCRUM methodology stresses the importance of the Product Owner as the person representing the business needs and thus piloting the development team laying out priorities and explaining the underlying reasons for a requested functionality. The relationship is mainly one directional, resulting in smaller incremental changes than what would be able to achieve when ICT potential would be used at its potential. Often scanning incoming documents is positioned as process digitalisation, actually it hardly changes anything more than facilitating the communication of the document through the process. Using a structured data entry form at the start of the process would permit instant data quality controls with the possibility to change and enhance data on the spot. Other examples can be imagined resulting in better use of digital technology. This potential often is not recognised by non tech savvy people concerned mainly with coping with the incoming work volume.
Establishing a tight relationship between ICT and business teams will most certainly enhance business performance when the purpose is clear and bidirectional communication facilitating the creation of added value. Therefore all talents should be used in an environment of mutual willingness to understand participants having different backgrounds.

The feudal organisation

Most of us know feudality from school, being the predominant way of organising a state during the Middle Ages. Although embedded in a traditional society based on a stable order imposed by god, some elements may still be of value in current contexts.
Discarding the basis for legitimising the position of nobility as the leaders in the Middle Ages, feudality is mainly a method for distributing power and a way for the king or emperor to exert control over his realm while having a sustainable community.
Looking at the material context of medieval society, feudality was a logical organisational format. Traveling even over short distance was difficult and took time. Roads were rarely paved so using them was mainly restricted to summertime when it was dry and days were long. As it easily took a day to travel to the next village, it was hardly feasible for the lord to enforce strict control on regions further away. Giving instructions and receiving feedback on them easily took weeks. On matters not involving the overall structure, fiefs were alone in their decision process. Although set in a rigid and strictly hierarchical context, legitimised by god, fiefs were largely independent, autarchic units. They had to decide on their operational besognes.
A fief had to be able to subsist independently of others. It could and should survive on its own, provide in its victuals, producing enough agricultural produce for its own inhabitants, be able to construct housing, furniture and tools to get necessary production going. Specialisation was limited. They were also self policing on the level of internal peace keeping and justice. They also produced enough surplus to support nobility and clergy. Their focus was on their purpose: subsist.
They were only called to help when neighbouring or when fiefs of which they were part of were under attack of an external source. On the other hand they presented enough force to ascertain the equilibrium with neighbouring fiefs.
In the ceremony, where a lord got ordained, tokens of trust were exchanged delegating full control to the lord while promising the lord eternal support and assistance. As such the local lord was also representing his higher master to which he had sworn obedience, while assuring representation of his domain with higher authorities when it came to engagements of a broader nature. Other interlinking was extremely limited, thus evolution was slow.
This is the basic setup of feudal society without distortions incurred by powerplay or unbalancing privileges.
Considering current organisations and societal evolutions a new type of distance could be identified. Increasing specialisation, either technical or functional, makes communication across the board more difficult. Vocabulary and practices often differ between groups and they have different support, infrastructure and tooling needs. Competition requires light, flexible and adjustable setups, quick on their feet to respond to changing contexts under their own responsibility not needing to go long ways through the overall organisation to obtain feedback or authorisation. This would take too long.
The medieval principles of autarchic units existing in balance with neighbouring units are also found in new organisation types heralded in modern management literature.
The Connected company defines it a podular organisation where “you divide labor into “businesses within the business”” fully oriented at its customer. An infrastructural platform sees to it that the necessary information and knowledge can be shared and common support activities are mutualised.
In holacracy work is organised in holons, “a whole that is part of a larger whole”. These holons or circles are organised along the lines of business functions and processes and fundamentally autonomous for their internal organisation of work, however constrained by the need of other circles and anchored in the context of the organisation. “The “Lead Link” is appointed by the super-circle to represent its needs in the sub-circle. A lead link holds the perspective and functions needed to align the sub-circle with the purpose, strategy and needs of its broader context. The other link, called a “Representative Link” (…) is elected by the members of the sub-circle, and represents the sub-circle within its super-circle.”
Different to the past, management or leadership overhead is out of the question. Each unit should be self steering based on a set of basic governing principles, mutual member negotiation and unit democracy.
Although recurring in other contexts mechanisms from the past re-appear, ideas are recycled and depend on similar conditions for their success and sustainability.
Each member of the organisation should be taking up responsibilities for the role (holacracy) or tasks assigned to or taken up by him/her, he should act as an engaged adult
Have a clear view on the organisational purpose and vision
Share the common vision or purpose declared or grown in the organisation
Avoid powerplay, created when units see possibilities to lift the equilibrium instated in the initial organisation
When providing a governance framework keep it crisp and stick to general widely applicable rules. Avoid to let it become an elaborate set of detailed rules and procedures.
In this context it is also tempting to retreat in the own autarchic circle, not sharing any knowledge or learning and to focus on the internals of the working of the circle. The businesses in the business not contributing to the whole will eventually lose efficiency by not sharing experience across the board, merely being a franchise or an independent organisation. The potential for corporate learning is clearly available based on the platform services on global level.
Keep connected to your customer (in a broad definition) and continue to observe how needs and behaviour are evolving while capitalising on your talents, knowledge, competences and experience.