Wednesday, October 3, 2018

Governance of purpose-driven work in municipalities using an agile mindset

In purpose-driven work with an agile mindset, the purpose is defined together with inhabitants and periodically evaluated. Purpose teams play a central role and they are responsible for the purpose, results and they are 'accountable' to inhabitants, the alderman and to management. This requires a different municipal organization and positioning of actors. The municipal council will have to be involved in the purpose. The purpose-owner and the alderman regularly play each other's ball, for an inhabitant-oriented and decisive service by purpose-teams. The agile principles and scrum structure provide a foothold and you really need it; otherwise, intentions about self-management, transformation are not very appropriate (download pdf)
In my previous article, together with Ido van der Meulen, I introduced purpose-driven work using an agile mindset. The agile way of working offers the municipality a perspective to anticipate flexibly and decisively on the wishes of inhabitants and civil organizations by listening carefully to them. This is all the more important given the decentralization from government to municipalities. I considered the core values and cultural characteristics of agile-oriented work, such as autonomy, self-managing teams and serving leadership. I then discussed the central position of the customer, the public interest, in municipalities.

In this article I will focus on the implications of purpose-driven work for the municipal council, aldermen and the municipal organization could have. First, I describe the agile pillars that also apply to purpose-driven work in a municipality. As an outsider I want to give some notions to municipalities, where a number of my experiences come together. I was a council member and chairman of the accounting and audit committee of 2006 - 2010 in Amsterdam Oost. Professionally I have been working for many years on designing and organizing learning processes. Agile coaching and advice have been added in recent years. I spent a year in a medium-sized municipality as a designer and advisor for purpose-driven work.

In municipalities, it is increasingly common to describe the major issues as a purpose. A purpose would help to better understand the inhabitant in all its diversity. In business, complex issues are increasingly being tackled with scrum and the agile mindset; also, because speed of change is a matter of survival. And that also applies to municipalities: care for children who need acute help and care for the elderly require quick decision-making and adequate services. And it must all be arranged with a smaller budget. This requires a creative and smart approach and everyone is needed, not only the smartest policymaker. The business community has started using agile for this and now it is up to the municipalities. And when you compare the complexity of a municipality with IT companies, agile with municipalities is of a different order. There are so many more stakeholders in a municipality, including the city council and politics.

Externally focused on inhabitants
Purpose-driven work fits well with the concept of new public governance, with its emphasis on cooperation and co-creation with external actors. Municipal issues are defined and realized in collaboration with external actors; management and their executors / officials get a position and work from these purposes (Anderson, 2018). This implies that Inhabitants from the purpose have the 'right to challenge', organized through sprint reviews and purpose meetings. With 'external actors' I distinguish between inhabitants, entrepreneurs and partner organizations. The legitimization of activities carried out by the municipality and partner organizations is about the needs and wishes of inhabitants and entrepreneurs. The term 'cooperation' also requires a note. External focus means that the municipality focuses on the demand of inhabitants and entrepreneurs: from the outside in. Of course, demand-oriented does not mean: your wish is our command. The municipality has a limited budget, which is why the purpose teams also should have the courage to sell 'no' to inhabitants and to the alderman. I prefer to talk about 'customers' and 'customer groups', because these terms better define what I mean. In the agile mindset with its scrum methodology, the customer is the most important pillar; it is about serving customers perfectly. In agile customer stories are central and they serve as a stepping stone for the activities in the sprints. And at the end of a sprint, the team presents its results to inhabitants, to the customer. For more background information about the roles and the various meetings that suit an agile mindset, see the scrumguide.

The above means a lot. If the municipality collects questions from society and anticipates this quickly. This may call for friction with the policy role of the city council. Better said, with the interpretation that many city councils give to their role. What role does the annual plan play with a wide range of goals, when the municipality will actively anticipate customer questions and determine priorities together with inhabitants? Is the annual cycle with annual plan and budget not up for discussion when you start working cyclically? Working together with inhabitants will be a challenge for many civil servants.

When working with the agile mindset in a purpose-driven way, 'cross functional' teams are one of the three pillars, besides customer focus and working in networks. It is important to give purpose teams as much space as possible, so that they can optimally serve inhabitants with a fixed budget. The purpose-owner is also budget holder. Teams embrace self-managing as much as possible and are responsible for their services and results, with team members determining how they do it and experiencing ownership of the purpose. In municipalities the word responsibility is often used; the alderman, the city council, the department manager, they are all responsible, it is logical that teams cannot come into their power. The Dutch word responsibility has its limitations; in English the words 'responsability' and 'accountability' are used and that creates more clarity: the purpose team is accountable to the alderman. To put teams in their power servant leadership has been asked, emphasizing the hierarchy of 'competences' (Gary Hamel and Laloux). ). For more information about management functions, see my previous article.

Governance and interactions between actors
The external focus of purpose-driven working with a central role for purpose teams from an agile mindset, means a lot for the organization and governance of the municipality: for the municipal council, the alderman and mayor, management, the tribelead (department manager) and cooperation with partner organizations. Below I present the most important actors and their interactions in the governance of the municipality. In the picture the so-called accountability loop is central to the relationship between resources (time, money and people) and accountability. Especially the purpose team, the alderman and the municipal council members have contacts with inhabitants. The management has the task of organizing resources, in addition to coordination and information provision.

Municipal council
The municipal council focuses on the so-called 'purpose' from its framework role and distributes the scarce resources in general. In the Anderson study (2018), the municipality demonstrated that the district committees were very satisfied and that the municipal council members were dissatisfied. In other words, the customer was satisfied with the services and the municipal councilors as representatives of inhabitants did not ... it does not get much wackier than that! Council members can view the formulation and realization of objectives with inhabitants as an erosion of their own role as council members, especially if they are not involved in the new way of working (Anderson, 2018). Anderson hits the nail here on the head. Council members are generally strongly involved in the internal formulation and realization of objectives and then feel more comfortable with the (waterfall) project management method, even though it often does not work in complex situations. They want to be in the driver’s seat, from their role in the municipal law. A similar reaction was visible in the business world when working with scrum, without an extensive plan of action that people have worked on for month. Teams work with 'sprints' and a 'purpose' and then the management quickly loses the in-control feeling and should have confidence in its teams.

The annual plan is in any case a complicated document for many council members; a budget of more than 100 million can only be understood by a few council members. The vast majority of council members get lost in thick packs of paper and do not see the financial implications of goals and programs. Council members want to be in the driver’s seat, while the policymakers have written the annual plan for more than 90%. How many council members take the initiative to be informed in a private conversation by the controller or department manager about the budget? Writing the annual plan also costs (senior) policy staff a lot of time, time that they cannot spend on the 'customer'. Many agile organizations have stopped for a large part with extensive annual plans, it has to be much more cyclical in our dynamic society. And that also applies to municipalities! Even though you cannot escape an annual budget. The board's supervisory role also takes on a different character in the case of a purpose-driven approach. When you work with an agile mindset, sprint results are discussed in the review meeting, for example. Council members are free to visit these meetings and above all to listen carefully (many employees will find the presence of council members uncomfortable). It is logical that council members crave more insight into youth and WMO programs; a lot of money is involved and in many municipalities council members are faced with substantial cost overruns. But it is complex and the issue is constantly changing. In their supervisory role, council members can emphasize the enormous cost overruns; they can emphasize the urgency of action, but they cannot do more and that is frustrating

The city council is ultimately responsible for the allocation of resources, read money. Purpose-driven work requires a flexible attitude in terms of resources and a budget with policy-free space fits in with this. It is not feasible to ask permission from the city council for smaller expenses outside the budget. This is indeed a question that almost all agile organizations are struggling with. A solution could be that there is a fund managed by a few strategists who advise the board and municipal management. Purpose owners then submit with each other and together with their tribelead a proposal in which additional resources should be allocated for certain teams. Of course, they are assisted and not controlled by the controllers of the municipality.

The research by Anderson (2018) concludes that council members should be much more involved in the purposes. Correct. However, a council member cannot join a purpose team. We will have to think of something whereby council members are involved in the choice and the definition of the 'purpose'. Of course, it cannot be the case that policymakers of the municipality define the purpose in all their wisdom. For example, you could organize a meeting every six months with all actors involved in a purpose, including council members and representatives of inhabitants; such as the participation council. Together the 'purpose' of the purpose is defined and questions, wishes are given to the purpose team. The purpose team reports on its developed products and services six months later and, for example, the client or participation council shares its findings. During that meeting the purpose will be adjusted and the most important dilemmas and wishes will be collected. It is important that council members get a better understanding of the complex matter of the issue and experience that inhabitants, the customer, are in the lead in terms of services to be provided and that all parties do their utmost to serve target groups properly and efficiently. Could it be an option to transform the council meetings into purpose meetings? Commission meeting 1 is then about the purpose youth, month 2 about the purpose care and the elderly, etc. In fact, the framework role of council members is then delegated to that semi-annual meeting. In the city council, the proposals are mainly confirmed. This may mean or feel as a depoliticization of the city council. These meetings will have the character of open-space, deep democracy or hackathon.

It is important that the city council can call the purpose team to account when it makes a mess of it. This often has to do with significant cost overruns. The council holds the alderman 'accountable' and again holds the account teams 'accountable' and an audit can be carried out. The council will usually contract an organization with subject matter experts to set up an (audit) investigation. When it subsequently turns out that the municipal organization can be charged for anything, the municipal council will act.

The alderman
The aldermen manage the municipality together with the mayor and they implement the decisions of the city council. In a purpose-driven approach, the alderman is generally the administrative client of the purpose team with its purpose owner, as is stated. That would also mean that the alderman provides frameworks in terms of content. The alderman would be responsible for the purpose ...? No, the purpose team is responsible for the results and its services, she collects customer stories. The team is not for nothing the crucial pillar for purpose-driven work. Better to say: team is 'accountable' to the alderman. And what do we mean by that, when purpose teams join forces with inhabitants, with teams that handle the variety in a complex environment and when you know that teams are put their strength into effect to achieve results? Before you know it, the purpose team operates in a situation with satisfied neighborhood committees and aldermen feel that they are out of the game. And that must not happen!

The purpose team is best informed about all the questions and wishes of inhabitants in the municipality. If it is good ... but that is often not the case. I see municipal purpose teams that do not visit constantly the network outside the town hall. Sometimes you see aldermen fulfilling that role constantly in conversation with inhabitants. Ignorance characterizes the municipality when it outsources the fieldwork and stays in its ivory tower itself and where policy and implementation are also strictly separated. The founder of scrum Jeff Sutherland argues that product owners, read purpose owners, should spend 50% of their time with customers; that's the purpose! You could say that purpose owners and aldermen keep a close eye on questions and wishes of inhabitants. They can then properly involve council members and the alderman can set out action via management. The alderman can work hard to free up extra funds and ultimately the city council will go over it again.

The alderman depends for a large part on the information and advice that comes from the purpose team. In order to ensure that the aldermen can properly fulfill their role, the purpose owner and the alderman will be constantly in discussion with each other, they are a team and they regularly play each other's ball. Together they come to the priorities for the coming months and thus secure the connection with the multi-year policy agreement. Management should not want to join, they operate more at a distance and that might be hard for many managers, willing to be in-control. Through the half-yearly meeting with all actors; you prevent that it becomes a one-two between alderman and purpose owner. Of course, the alderman is welcome at the review meeting, where the team presents its results to customer representatives, read inhabitants, who then provide feedback. The alderman mainly has a listening attitude during such a meeting; tries to understand what is going on and experiences how a purpose team anticipates developments in the municipality.

When you start working with an agile mindset as a municipality, you choose for serving leadership and then you use the hierarchy of competences (Gary Hamel). This means that the alderman should be the wise and smart adviser for purpose teams; in order to be able to perform even better, also in his or her own interests. Not all aldermen will have this in mind and sometimes do not understand it, after all it is a political appointment. The alderman will act when inhabitants are not satisfied with the performance of the municipality (which falls into his / her portfolio) and when he / she thinks that the purpose team does not perform well. In general, the purpose owner and the alderman will come to an agreement. But it is not up to the alderman to intervene in the purpose team and to give directions, in other words it is not up to the alderman to exercise the hierarchy of authority towards a purpose team. That is a job for the municipal hierarchy, which takes a request from the alderman into consideration. The top of the municipal organization will not blindly follow the request of the alderman, she will first carry out her own analysis (audit). Sometimes it can be important to protect a team for an alderman. If all goes well, the hierarchy of authority is rarely applied in an agile work environment and it is only up to the tribelead to intervene after thorough investigation in the purpose team. If the training team needs extra resources, the municipal organization hierarchy will submit this request to the alderman and the alderman in the city council. Of course, the purpose team will inform the alderman in advance.

Tribelead (department- or team manager)
The department manager, also known as the tribelead, facilitates and creates an optimal playing field, allowing purpose teams to flourish. It serves as a buffer for the whims of management and creates the conditions for psychological safety in teams. He/she is responsible for the management of the organizational change, coordinates strategically with the management and is responsible for organizing the purpose team support by policy support staff, personnel policy, IT, subsidies, finances, etc.

If there is no chapter lead, the tribelead will also be responsible for the HR and performance cycle. As far as the HR cycle is concerned, part of that job can also be laid with the team, team members then decide with each other which skills and competences should be strengthened in the context of the purpose. In the agile way of thinking, professional competence regains the recognition it deserves (via chapters), professional development is therefore a natural choice (see also Tonkens, et al. 2018) and the team works as a learning community. You could also delegate the HR cycle to the organization coach with HR in the background. With regard to the performance cycle, it concerns the periodic and annual assessment. In addition to the tribelead, the purpose owner and organization coach are also involved in these assessments. The tribelead will generally conduct the interview with the team member and preferably a few times a year. You could also ask team members to assess each other. Make it not too complicated.

The tribelead plays an important role in the provision of 'resources', such as time, people and money, which means that the purpose owner is a budget holder. The tribelead ensures that the team has a good composition so that the team can do its job well. And sometimes it appears in a review meeting that certain expertise is needed and then the tribelead gets to work. Extra expertise sometimes also means extra expenses, not budgeted, and the municipal organization must be aware of that. The tribelead also guards that there is time; that agendas are not densely paved and that team members have time to experiment. Especially the tendency to invest a meeting about everything has to be confined.

Is the tribelead the municipal client of the team? And what do we mean by that, when purpose teams define the purpose together with inhabitants? In business you are not talking about commissioning; I find it a confusing concept. The purpose team is responsible and she does everything possible to serve the customer optimally. You could say that the team is 'accountable' to the tribelead and the tribelead is 'accountable' to the team. However, accountability has more significance between the purpose team and the alderman.

From an agile mindset, the tribelead uses the hierarchy of competences. The team and team members like to ask the tribelead for advice for an even better service. And once in a while the tribelead uses the hierarchy of authority and a decision is made. The tribelead is the only one in the organization that can exercise the hierarchy of authority with regard to the team. In other words: she intervenes. You could position the tribelead next to the network of purpose teams or as a spider in the web and that is he/she is in the middle of the network of purpose teams, in the team-of-teams, as a spin-doctor.

The purposes
It is obvious that in the social domain the three major decentralizations will be dealt with, along with the housing purpose and the environmental law purpose. The different purposes are quite obvious and yet it is important to define them together with inhabitants, so you make a good start.

Composition of purpose teams and partner organizations
With regard to the composition of a purpose team, policymakers and people implementing the policy work together; you can only quickly anticipate changes in the outside world if you do this together, experiment together and learn from each other. Policymakers have to unlearn to spend months to develop a policy paper. Working in a team will not be easy for many officials; since they can no longer retreat to their island! Employees can also no longer rely on their job description because they are contracted for a purpose on the basis of their professionalism, knowledge and experience.

IT increasingly plays a role in the digitizing world. The purpose team can only operate effectively when it has access to brand new data. Each tribe should have its own information specialist (s) who participate in the purpose teams. At an agile organization like ING, data specialists are often in the team! The information specialists are in general positive about it; it motivates to get an information question in a planning meeting and to present the information within two weeks. Then you feel that you are meaningful. And it also works the other way around: team members get more affinity with IT and data. Information analysts also ensure that teams have insight into the expenditures and how they relate to the budget. Management information is first of all meant for the purpose team, which is ultimately responsible. This information is also accessible to the tribelead, the management and the alderman, so that they can support the purpose team even better.

When you operate from the purpose perspective, important partner organizations will also participate in the purpose team. People have to get used to the idea that for example the welfare organization or a care organization will join the team, "is it possible and allowed?" The municipality is often the client and financier of partner organizations and she will generally have to take off her cap from the client, otherwise you cannot cooperate. In first instance, partner organizations often react enthusiastically to the invitation to join the team: "are we allowed to be in charge of the purpose program?" And that is how the network organization takes shape from bottom up and step by step; with a municipality that takes the lead. Working intensively and working with sprints on complex issues also means that the municipality as a client is less able to quantify the output contribution by the partner and to pay off partners. A municipality must be a reliable partner; it cannot be the case that the municipality wants to build up a relationship of trust on one side and confront the partner organization with a sharp budget cut on the other. The purpose owner is in direct contact with the management of the partner organization, whereby the management of the partner organization is accountable to the purpose owner (and not the department manager) and vice versa. The contours of an advisory board for the purpose team become visible consisting of management members of the most important partner organizations, the municipality and the alderman.

Purpose-driven work also has consequences for the partner organization. To begin with, she will have to spend time in the purpose team. Intensive cooperation means that the municipality gets much better insight into the actions of the partner organization; much more will become transparent. The director of a partner organization may shy away from that. Previously, for example, the partner organization did not take it so closely with declarations and the municipality becomes aware of that. Of course, you have to deal with that. To get right out of this wisdom is required; both from the municipality (alderman and declaration owner) and from the partner organization (director and department managers). This also means that the municipality will not abuse the new insights in its supervisory role. That is why the crucial value of trust gets meaning in daily practice. This of course also applies the other way around: the partner organization gets a lot more insight into the activities of the municipality. Do not let fear be a guide, the agile mindset builds on trust and you build that up with each other.

In purpose driven work with an agile mindset, inhabitants, purpose teams and their interaction are the cornerstones for sounding results. All actors do everything to put the purpose team in its power; that is the task of the municipal hierarchy, serving leadership is not something for free. The team is responsible and nobody else! The purpose owner and his/her alderman always play each other's ball; they are 'accountable' to each other. City council members are involved, for example with six-monthly purpose framework meetings, in which all relevant actors participate. During these meetings, the team and the alderman are also accountable, starting with inhabitants. The most important partner organizations participate in the purpose team and the network organization is gradually taking shape.

Governance van opgavegericht werken in gemeenten met een agile mindset

Bij opgavegericht of -gestuurd werken vanuit een agile mindset worden de opgaven samen met inwoners gedefinieerd en periodiek geëvalueerd. Opgaveteams hebben daarbij een centrale rol en zij zijn verantwoordelijk voor de opgave en resultaten. Dit vraagt een andere gemeentelijke organisatie en positionering van actoren. De gemeenteraad zal bij de opgave betrokken moeten worden. Opgaveteams zijn ‘accountable’ naar inwoners, de wethouder en naar de directie, waarbij de opgave eigenaar en de wethouder elkaar elkaar regelmatig de bal toe spelen, voor een inwonergerichte en daadkrachtige dienstverlening door opgaveteams. De agile principes en scrumstructuur bieden een houvast en die heb je hard nodig; anders komt er van intenties over zelfsturing, transformatie en kanteling weinig terecht (download pdf)
In mijn vorige artikel heb ik samen met Ido van der Meulen opgavegericht werken vanuit een agile mindset geïntroduceerd. De agile werkwijze en mindset biedt de gemeente een perspectief om wendbaar en daadkrachtig te anticiperen op wensen van inwoners en maatschappelijke organisaties door goed naar hen te luisteren. Dit is eens te meer van belang gezien de decentralisaties. Ik heb stil gestaan bij de kernwaarden en cultuurkenmerken van opgavegericht werken, zoals autonomie, zelfsturende teams en dienend leiderschap. Vervolgens heb ik de centrale positie van de klant, het publieke belang, in gemeenten besproken.

In dit artikel sta ik stil bij de implicaties die opgavegericht werken voor de gemeenteraad, wethouders en de ambtelijke organisatie zou kunnen hebben. Ik beschrijf eerst de agile pijlers die ook voor opgavegericht werken gelden. Als buitenstaander wil ik een aantal noties aan gemeenten meegeven, waarbij een aantal ervaringen samenkomen. Ik was raadslid en voorzitter reken- en rekenkamercommissie van 2006 – 2010 in Amsterdam Oost. Professioneel houd ik me al vele jaren bezig met het ontwerpen en organiseren van leerprocessen. De laatste jaren is agile coaching en advisering daar bij gekomen. Ik heb een jaar meegedraaid in een middelgrote gemeente als ontwerper en adviseur van opgavegericht werken.

In gemeenteland is het steeds meer gemeengoed om de grote vraagstukken vanuit de bedoeling als opgave te betitelen. Opgavegericht zou je kunnen vervangen door ‘samenlevingsgericht’, daarmee komt de inwoner in al haar verscheidenheid beter in beeld. In het bedrijfsleven worden complexe vraagstukken steeds vaker met scrum en de agile mindset aangepakt; ook omdat snelheid van verandering een kwestie van overleven is[1]. En dat geldt natuurlijk ook voor gemeenten: zorg voor kinderen die acuut hulp nodig hebben en zorg voor ouderen vraagt om snelle besluitvorming en adequate dienstverlening. En het moet allemaal geregeld worden met een kleiner budget. Dat vraagt om een creatieve en slimme aanpak en daar is iedereen bij nodig, niet alleen de slimste ambtenaar. Het bedrijfsleven is hiervoor agile gaan gebruiken; nu de gemeenten nog. En wanneer je de complexiteit van een decentralisatie vergelijkt met IT bedrijven, dan is agile bij gemeenten van een andere orde. Er zijn in een gemeente zoveel meer belanghebbenden, waaronder de gemeenteraad en de politiek.

Extern gericht op inwoners
Opgavegericht werken past goed in het concept van new public governance, met haar nadruk op samenwerking en co-creatie met externe actoren. Maatschap­pelijke opgaven worden in samenwerking met externe actoren gedefinieerd en gerealiseerd; de bestuurders en hun uitvoerders/ambtenaren krijgen positie en werken vanuit die opgaven (Anderson, 2018). Dit impliceert dat inwoners vanuit de opgave de ‘right to challenge’ hebben, georganiseerd via sprint reviews en opgave bijeenkomsten. Bij ‘externe actoren’ maak ik onderscheid tussen inwoners, ondernemers en partnerorganisaties. De legitimering van activiteiten uitgevoerd door de gemeente en partnerorganisaties gaat over de behoeften en wensen van inwoners en ondernemers. Het begrip ‘samenwerken’ vraagt ook om een kanttekening. Externe gerichtheid betekent dat de gemeente zich richt op de vraag van inwoners en ondernemers: van buiten naar binnen. Natuurlijk betekent opgavegericht niet: u vraagt, wij draaien. De gemeente heeft namelijk een beperkt budget, vandaar dat opgaveteams ook ‘nee’ moeten durven verkopen aan inwoners en aan de wethouder. Ik heb het liever over ‘klanten’ en ‘klantgroepen’, omdat deze begrippen scherper aangeven wat ik bedoel. In de agile mindset met haar scrum methodologie is de klant de belangrijkste pijler; het draait om het perfect bedienen van klanten. In agile staan de klantverhalen centraal en zij dienen als kapstok voor de activiteiten in de sprints. En aan het eind van een sprint presenteert het team haar resultaten aan inwoners, aan de klant. Klik hier voor meer achtergrondinformatie over de rollen en de verschillende bijeenkomsten die passen bij een agile mindset.

Bovenstaande betekent nogal wat. Als de gemeente vragen vanuit de samenleving ophaalt en daar snel op anticipeert, dan kan dit op gespannen voet staan met de kader stellende rol van de gemeenteraad. Beter gezegd, met de invulling die veel gemeenteraden aan hun rol geven. Welke rol speelt het jaarplan met een breed pallet aan doelen, wanneer de gemeente daadkrachtig gaat anticiperen op klantvragen en samen met inwoners prioriteiten bepaalt? Staat de jaarcyclus met jaarplan en begroting niet ter discussie, wanneer je kort cyclisch gaat werken? Samenwerken met inwoners zal voor veel ambtenaren een uitdaging betekenen.

Bij opgavegericht werken met de agile mindset zijn ‘cross functionele’ teams 1 van de drie pijlers, naast klantgerichtheid en werken in netwerken. Het is van belang om opgave- en wijkteams zoveel mogelijk ruimte te geven, waardoor zij inwoners optimaal kunnen bedienen met een vastgesteld budget. De opgave eigenaar is dan ook budgethouder. Opgaveteams zijn zoveel mogelijk zelfsturend en zijn verantwoordelijk voor hun diensten en resultaten, waarbij teamleden bepalen hoe zij het doen en eigenaarschap over de opgave ervaren. In gemeenten wordt het woord verantwoordelijkheid te pas en onpas gebruikt; de wethouder, de gemeenteraad, de afdelingsmanager, zij allen zijn verantwoordelijk, het is logisch dat teams dan niet in hun kracht kunnen komen. Het Nederlandse woord verantwoordelijkheid kent haar beperkingen; in het Engels worden de woorden ‘responsability’ en ‘accountability’ gebruikt en dat schept meer duidelijkheid: het opgaveteam is accountable naar de wethouder en dat gaat gepaard met weinig bureaucratie. Om teams in hun kracht te zetten is dienend leiderschap gevraagd, met een hiërarchie van ‘competences’ (Gary Hamel en Laloux). Voor meer informatie over de agile managementfuncties, klik hier.

Goevernance en interacties tussen actoren
De externe gerichtheid van opgavegericht werken met een centrale rol voor opgaveteams vanuit een agile mindset, betekent van alles voor de inrichting en ‘governance’ van de gemeente: voor de gemeenteraad, het college van B&W, de directie, de tribelead (afdelingsmanager) en de samenwerking met partnerorganisaties. Hieronder presenteer ik de belangrijkste actoren en hun interacties in de governance van de gemeente. In het plaatje staat de zogenaamde accountability-loop centraal met de relatie tussen middelen voorziening (tijd, geld en mensen) en accountability. Vooral het opgaveteam, de wethouder en de gemeenteraadsleden contacten hebben contact met inwoners. Het management heeft als taak middelen te organiseren, naast afstemming en informatievoorziening.

De gemeenteraad richt zich vanuit haar kader stellende rol op de zogenaamde ‘purpose’ en zij verdeelt in grote lijnen de schaarse middelen. In het onderzoek van Anderson (2018) bleek in de gemeente met opgavegericht werken, dat de wijkcommissies zeer tevreden waren en de gemeenteraadsleden ontevreden. Oftewel de klant was tevreden over de dienstverlening en de gemeenteraadsleden niet... het moet toch niet gekker worden! Raadsleden kunnen het formuleren en realiseren van doel­stellingen met inwoners opvatten als uitholling van hun eigen rol als raadslid, zeker als zij bij de nieuwe werkwijze niet betrok­ken zijn (Anderson, 2018). Anderson slaat hier de spijker op de kop. Raadsleden zijn over het algemeen sterk betrokken bij het intern formuleren en realise­ren van doelstellingen en voelen zich dan meer senang met de (waterval) projectmanagement methode, ook al werkt die vaak niet in complexe situaties. Zij willen aan het stuur zitten, vanuit hun rol in de gemeentewet. Een vergelijkbare reactie was zichtbaar in het bedrijfsleven toen men met scrum ging werken, zonder forse plan van aanpakken waar voorheen maanden werk aan werd besteed. Teams werken met ‘sprints’ en een ‘purpose’ en dan verliest het management al snel het in-control gevoel en moet zij vertrouwen hebben in haar teams.

Het jaarplan is sowieso voor veel raadsleden een ingewikkeld document; een begroting van meer dan 100 miljoen is slechts voor enkele raadsleden te begrijpen. Het overgrote deel van de raadsleden raakt de weg kwijt in dikke pakken papier en doorziet niet de financiële implicaties van doelen en programma’s. Raadsleden willen het gevoel hebben aan het stuur te zitten, terwijl de ambtenaren het jaarplan voor meer dan 90% geschreven hebben. Hoeveel raadsleden laten zich in een privégesprek uitgebreid door de controller of afdelingsmanager voorlichten over de begroting? Het schrijven van het jaarplan kost (senior) beleidsmedewerkers trouwens ook heel veel tijd, tijd die zij dan niet aan de ‘klant’ kunnen besteden. Veel agile organisaties zijn voor een groot gedeelte gestopt met uitgebreide jaarplannen, het moet veel kort cyclischer in onze dynamische maatschappij. En dat geldt natuurlijk ook voor gemeenten! Al ontkom je niet aan een jaarlijkse begroting. De toezichthoudende rol van de raad krijgt bij opgavegericht werken ook een ander karakter. Wanneer je met een agile mindset gaat werken, worden sprintresultaten bijvoorbeeld besproken in de review bijeenkomst. Het staat raadsleden vrij om die bijeenkomsten te bezoeken en vooral goed te luisteren (menig medewerker zal de aanwezigheid van raadsleden trouwens ongemakkelijk vinden). Het is logisch dat raadsleden hunkeren naar meer inzicht over de jeugd en WMO-programma’s; er gaat veel geld in om en in veel gemeenten worden raadsleden geconfronteerd met forse kostenoverschrijdingen. Maar het is complex en het vraagstuk is constant in beweging. In hun toezichthoudende rol kunnen raadsleden tamboereren op de enorme kostenoverschrijdingen; zij kunnen de urgentie van actie benadrukken, maar meer kunnen ze eigenlijk niet en dat is frustrerend.

De gemeenteraad is uiteindelijk verantwoordelijk voor de allocatie van middelen, lees geld. Opgavegericht werken vraagt een flexibele opstelling wat betreft middelen en daar past een budget met beleidsvrije ruimte bij. Het is niet werkbaar dat voor kleinere uitgaven buiten het budget toestemming van de gemeenteraad gevraagd moet worden. Dit is trouwens een vraagstuk waar bijna alle agile organisaties mee worstelen. Een oplossing zou kunnen zijn dat er een reservepot is, dat beheerd wordt door een paar strategen die B&W en de directie adviseren. Opgave eigenaren dienen dan met elkaar en samen met hun tribelead een voorstel in welke extra middelen toegewezen zouden moeten worden voor bepaalde teams. Uiteraard worden zij bijgestaan door de controllers van de gemeente.

Het onderzoek van Anderson (2018) komt tot de conclusie dat raadsleden veel meer betrokken zouden moeten worden bij de opgaves. Helemaal waar. Echter, een raadslid kan niet meedoen met een opgaveteam. Je zal iets moeten bedenken waardoor raadsleden betrokken zijn bij de keuze en de ‘purpose’ van iedere opgave. Het kan natuurlijk niet zo zijn dat beleidsmedewerkers van de gemeente in al hun wijsheid de opgaves definiëren. Je zou bijvoorbeeld elk half jaar een bijeenkomst kunnen organiseren met alle actoren rondom een opgave, inclusief raadsleden en vertegenwoordigers van inwoners; zoals bijvoorbeeld de participatieraad. Met elkaar wordt de ‘purpose’ van de opgave gedefinieerd en worden vraagstukken aan het opgaveteam mee gegeven. Het opgave team doet een half jaar later verslag over haar ontwikkelde producten en diensten en bijvoorbeeld de cliënten- of participatieraad deelt haar bevindingen. Tijdens die bijeenkomst wordt de purpose bijgesteld en worden de belangrijkste dilemma’s en wensen geïnventariseerd. Belangrijk is dat raadsleden iets beter de complexe materie van het vraagstuk gaan begrijpen en ervaren dat bewoners, de klant, in de lead zitten wat betreft te leveren diensten en dat alle partijen hun uiterste best doen doelgroepen goed en efficiënt te bedienen. Zou het misschien een optie zijn om de commissievergaderingen te transformeren naar opgave bijeenkomsten? Commissievergadering 1 gaat dan over de opgave jeugd, maand 2 over de opgave WMO en ouderen, etc. In feite wordt de kader stellende rol van raadsleden dan gedelegeerd naar die halfjaarlijkse opgave bijeenkomst. In de gemeenteraad wordt dit kader dan vooral nog bekrachtigd. Dit betekent wellicht enige depolitisering van de gemeenteraad. Deze bijeenkomsten zullen het karakter hebben van open-space, deep democracy of hackathon.
Het is belangrijk dat de gemeenteraad het opgaveteam ter verantwoording kan roepen wanneer de zij er een potje van maakt of lijkt te maken. Dit heeft vaak te maken met forse kostenoverschrijdingen. De raad houdt de wethouder ‘accountable’ en die houdt weer de opgaveteams ‘accountable’ en er kan er een audit uitgevoerd worden. Veelal zal de raad een adviesorganisatie organisatie met inhoudsdeskundigen contracteren om een (rekenkamer) onderzoek in te stellen. Wanneer vervolgens blijkt dat de ambtelijke organisatie van alles aangerekend kan worden, zal de gemeenteraad actie ondernemen.

De wethouders besturen samen met de burgemeester de gemeente en zij voeren de besluiten van de gemeenteraad uit. Bij opgavegericht werken is de wethouder over het algemeen de bestuurlijk opdrachtgever van het opgaveteam, van de opgave eigenaar, zo wordt wel gesteld. Dat zou ook betekenen dat de wethouder kaders geeft qua inhoud. De wethouder zou verantwoordelijk zijn voor de opgave…? Nee, het opgaveteam is verantwoordelijk voor de resultaten en haar diensten, zij verzamelt de klantverhalen; het team is niet voor niets de cruciale pijler bij opgavegericht werken. Beter is om te zeggen: team is ‘accountable’ naar de wethouder. En wat bedoelen we daar dan mee, wanneer opgaveteams samen met inwoners optrekken, met teams die de variëteit in een complexe omgeving hanteren en wanneer je weet dat dat je teams volop in hun kracht moet zetten, wil je tot resultaten komen? Voor je het weet opereert het opgaveteam in een situatie met tevreden wijkcommissies en hebben wethouders het gevoel buiten spel te staan. En dat mag niet gebeuren!

Het opgaveteam is het best geïnformeerd over alle vragen en wensen die bij inwoners in de gemeente spelen. Als het goed is… maar dat is vaak niet zo. Ik zie gemeentelijke opgaveteams die weinig het netwerk buiten het gemeentehuis opzoeken. Soms zie je wethouders wel die rol vervullen en zijn zij constant in gesprek met inwoners. Onwetendheid werkt de gemeente in de hand wanneer zij het veldwerk uitbesteed en zelf in haar ivoren toren blijft zitten en waar beleid en uitvoering ook nog eens strikt gescheiden zijn. De grondlegger van scrum Jeff Sutherland stelt dat productowners, lees opgave eigenaren, 50% van hun tijd bij klanten zouden moeten zitten; dat is de bedoeling! Je zou kunnen zeggen dat opgave eigenaren en wethouders met elkaar goed zicht houden op vragen en wensen van inwoners. Vervolgens kunnen zij raadsleden er goed bij betrekken en de wethouder kan lijnen uitzetten via de ambtelijke top. De wethouder kan zich hard maken voor het vrij maken van extra middelen en uiteindelijk gaat daar de gemeenteraad weer over.

De wethouder is voor een groot deel afhankelijk van de informatie en adviezen die uit het opgaveteam komen. Om ervoor te zorgen dat de wethouders goed zijn of haar rol kan vervullen, zullen de opgave eigenaar en de wethouder constant met elkaar in gesprek zijn, ze zijn een team en zij spelen elkaar aldoor de bal toe. Met elkaar komen zij tot de prioriteiten voor de komende maanden en borgen zo de verbinding met het collegeakkoord. Daar moet de ambtelijke top niet tussen willen zitten, zij opereert meer op afstand en dat zal menig manager lastig vinden. Door de half jaarlijkse bijeenkomst met alle actoren; voorkom je dat het teveel een een-tweetje wordt tussen wethouder en opgave eigenaar. Natuurlijk is de wethouder van harte welkom bij de review bijeenkomst, waar het team haar resultaten presenteert aan klantvertegenwoordigers, lees inwoners, die vervolgens feedback geven. De wethouder heeft tijdens een dergelijke bijeenkomst vooral een luisterende houding; probeert vooral te begrijpen wat er speelt en ervaart hoe een opgaveteam op ontwikkelingen in de gemeente anticipeert.

Wanneer je als gemeente met een agile mindset aan de slag gaat, dan kies je voor dienend leiderschap en dan hanteer je de hiërarchie van bekwaamheden (Gary Hamel). Dit betekent dat de wethouder vooral de wijze en slimme adviseur voor opgaveteams zou moeten zijn; die opgaveteams ondersteunt om nog beter te kunnen presteren, ook in zijn of haar eigen belang. Niet alle wethouders zullen dit scherp voor ogen hebben en soms ook niet begrijpen, het is ten slotte een politieke benoeming. De wethouder komt in beweging wanneer inwoners niet tevreden zijn over de prestaties van de gemeente (wat in zijn/haar portefeuille valt) en wanneer hij/zij meent dat het opgaveteam onvoldoende presteert. Over het algemeen zullen de opgave eigenaar en de wethouder er met elkaar wel uitkomen. Maar het is niet aan de wethouder om in het opgaveteam te interveniëren en opdrachten te verstrekken, met andere woorden het is niet aan de wethouder om de hiërarchie van autoriteit uit te oefenen richting een opgaveteam. Dat is een klus voor de ambtelijke hiërarchie, die een verzoek van de wethouder in overweging neemt. De top van de ambtelijke organisatie zal het verzoek(opdracht?) van de wethouder niet blindelings opvolgen, zij zal eerst haar eigen analyse (audit) uitvoeren. Soms kan het namelijk van belang zijn om een team voor een wethouder te beschermen. Als het goed is wordt de hiërarchie van autoriteit zelden toegepast in een agile werkomgeving en het is enkel aan de tribelead om na grondig onderzoek in het opgave team te interveniëren. Wanneer het opgaveteam extra middelen nodig heeft, dan zal de ambtelijke hiërarchie dit verzoek bij de wethouder indienen en vervolgens kan de wethouder in de gemeenteraad aan de slag. Natuurlijk stelt het opgaveteam de wethouder alvast wel op de hoogte.

Tribelead (afdeling- of teammanager)
De manager van de afdeling, ook wel tribelead genoemd, faciliteert en creëert een optimaal speelveld, waardoor opgaveteams tot bloei kunnen komen. Zij dient als buffer voor de grillen van de directie en creëert de randvoorwaarden voor psychologische veiligheid in teams. Hij/zij is verantwoordelijk voor de sturing van de organisatieverandering, stemt strategisch af met het management en is verantwoordelijk voor het organiseren van de opgaveteam ondersteuning door beleidsondersteuners, personeelsbeleid, IT, subsidies, financiën, etc.

Wanneer er geen chapterlead is, zal de tribelead ook verantwoordelijk zijn voor de HR-cyclus en de performance cyclus. Wat betreft de HR-cyclus kan een deel van die klus ook bij het team gelegd worden, teamleden bepalen dan met elkaar welke bekwaamheden versterkt dienen te worden in het kader van de opgave. In het agile gedachtegoed krijgt vakbekwaamheid weer de erkenning die zij verdient (o.a. via chapters), professionele ontwikkeling is dan ook een vanzelfsprekende keuze (zie ook Tonkens, e.a. 2018) en het team werkt als een leergemeenschap. Je zou de HR-cyclus ook bij de organisatiecoach kunnen beleggen met HR op de achtergrond. Wat betreft de performance cyclus gaat het om de periodieke en jaarlijkse beoordeling. Naast de tribelead worden de opgave eigenaar en organisatie coach hier ook bij betrokken. De tribelead zal over het algemeen het gesprek met het teamlid voeren en liefst een paar maal per jaar. Je zou ook aan teamleden kunnen vragen elkaar te beoordelen. Maak het vooral niet te ingewikkeld.

De tribelead heeft een belangrijk rol in de voorziening van ‘resources’, zoals tijd, mensen en geld, waardoor de opgave eigenaar budgethouder kan zijn. De tribelead zorgt ervoor dat het team een goede samenstelling heeft waardoor het team haar werk goed kan doen. En soms blijkt in een review bijeenkomst dat bepaalde expertise extra nodig is en dan gaat de tribelead aan de slag. Extra expertise betekent soms ook extra uitgaven, niet gebudgetteerd en daar moet de gemeentelijke organisatie op bedacht zijn. De tribelead bewaakt ook dat er tijd is; dat agenda’s niet dicht geplaveid zijn en dat teamleden de tijd hebben om te experimenteren. Vooral de neiging om over van alles een vergadering te beleggen moet ingedampt worden.

Is de tribelead ambtelijk opdrachtgever? En wat verstaan we daar dan onder, wanneer opgaveteams samen met inwoners de opgave definiëren? In het bedrijfsleven heb je het niet over opdrachtgeverschap; ik vind het een verwarrend begrip. Het opgaveteam is verantwoordelijk en zij zet alles op alles om de klant optimaal te bedienen. Je zou wel kunnen zeggen dat het team ‘accountable’ is naar de tribelead en de tribelead is ‘accountable’ naar het team. Echter, accountability heeft meer betekenis tussen het opgaveteam en de wethouder.

Vanuit een agile mindset hanteert de tribelead de hiërarchie van competenties. De tribelead is iemand waar je als team en teamlid heel graag advies aan vraagt voor een nog betere dienstverlening. En een heel enkele keer maakt de tribelead gebruik van de hiërarchie van autoriteit en wordt een besluit genomen. De tribelead is de enige in de organisatie die naar het opgaveteam en de hiërarchie van autoriteit kan hanteren. Met andere woorden: zij grijpt in. Je zou de tribelead naast het netwerk van opgaveteams kunnen positioneren of als een spin in het web en dat zit hij/zij midden in het netwerk van opgaveteams, in het team-van-teams, als een spindokter.

De opgaves
Het ligt voor de hand dat in het sociale domein de drie grote decentralisaties aan bod komen, met daarnaast de woonopgave en de omgevingswet. De verschillende opgaves liggen nogal voor de hand en toch is het van belang om ze samen met inwoners te definiëren, zo maak je een goede start.

Samenstelling van opgaveteams en partnerorganisaties
Wat betreft de samenstelling van een opgaveteam trekken beleidsmedewerkers en uitvoerders samen met elkaar op; je kunt enkel snel anticiperen op veranderingen in de buitenwereld als je dat samendoet, samen experimenteert en van elkaar leert. Beleidsmedewerkers moeten afleren om maandenlang op een nota te broeien. In een team werken zal menig ambtenaar nog niet meevallen; aangezien zij zich niet meer kunnen terugtrekken op hun eilandje! Medewerkers kunnen ook niet meer terugvallen op hun functiebeschrijving omdat zij op basis van hun professionaliteit, kennis en ervaring ingezet worden voor opgaves.

In de digitaliserende wereld speelt IT steeds meer een rol. Het opgaveteam kan enkel effectief opereren wanneer zij de beschikking heeft over kersverse data. Iedere tribe zou haar eigen informatiespecialist(en) moeten hebben, die meedoen in de opgaveteams. Bij een agile organisatie als ING zitten dataspecialisten vaak in het team! Aan de informatiespecialisten zal het niet liggen; het motiveert om in een planningsbijeenkomst een informatie vraag te krijgen en binnen twee weken bij de review de informatie te presenteren. Dan voel je dat je van betekenis bent. En het werkt ook andersom: teamleden krijgen stapje voor stapje meer affiniteit met IT en data. Informatieanalisten zorgen er ook voor dat teams inzicht hebben over de uitgaven en hoe die zich verhouden tot het budget. Managementinformatie is er voor het opgaveteam, zij is ten slotte verantwoordelijk. Die informatie is ook toegankelijk voor de tribelead, de directie en de wethouder, waardoor zij het opgaveteam nog beter kunnen ondersteunen.

Wanneer je vanuit de bedoeling opereert, hebben belangrijke partnerorganisaties ook een plaats in het opgaveteam. Dat is vaak wel even wennen; de welzijnsorganisatie of een zorgorganisatie gaat meedoen in het team, “kan en mag dat wel?” De gemeente is vaak opdrachtgever en financier van partnerorganisaties en zij zal haar pet van opdrachtgever over het algemeen af moeten zetten, anders kan je niet samenwerken. Partnerorganisaties reageren in eerste instantie vaak enthousiast op de uitnodiging mee te doen in het team: “mogen wij aan het stuur zitten van het opgave programma ?” En zo krijgt de netwerkorganisatie van onderop stapje voor stapje vorm; met een gemeente die het voortouw neemt en waar het woord regisseur minder van toepassing is. Intensief samenwerken en werken met sprints aan complexe vraagstukken betekent ook dat de gemeente als opdrachtgever minder goed op output kan sturen en partners kan afrekenen. Je zult als gemeente een betrouwbare partner moeten zijn; het kan niet zo zijn dat je linksom een vertrouwensband wilt gaan opbouwen en rechtsom de partnerorganisatie met een forse bezuiniging confronteert. De opgave eigenaar staat in direct contact met de directie van de partnerorganisatie, waarbij de directie van de partnerorganisatie accountable is naar de opgave eigenaar (en niet de afdelingsmanager) en vice versa. De contouren van een raad van advies voor het opgaveteam worden zichtbaar met de directies van de belangrijkste partnerorganisaties, de gemeente en de wethouder.

Opgavegericht werken heeft ook consequenties voor de partnerorganisatie; om te beginnen zal zij tijd moeten steken in het opgaveteam. Intensief samenwerken betekent dat de gemeente veel beter inzicht krijgt in het doen en laten van de partnerorganisatie; van alles gaat transparant worden. Daar zal menig directeur van een partnerorganisatie misschien voor terugdeinzen. Voorheen nam de partnerorganisatie bijvoorbeeld het niet zo nauw met declaraties en daar komt de gemeente dan achter. Natuurlijk moet je dat met elkaar aanpakken. Om hier goed uit te komen wordt er veel wijsheid gevraagd; zowel van de gemeente (wethouder en opgave eigenaar) als van de partnerorganisatie (directeur en afdelingsmanagers). Dit betekent ook weer dat de gemeente in haar toezichthoudende rol de nieuwe inzichten niet gaat misbruiken. Vandaar dat de cruciale waarde van vertrouwen inhoud krijgt in de dagelijkse praktijk. Dit geldt natuurlijk ook andersom: de partnerorganisatie krijgt veel meer inzicht op het doen en laten van de gemeente. Laat angst geen leidraad zijn, de agile mindset bouwt op vertrouwen en dat bouw je met elkaar op.

Bij opgavegericht werken met een agile mindset zijn inwoners, opgaveteams en hun interactie de pijlers om tot klinkende resultaten te komen. Alle actoren doen er alles aan om het opgaveteam in haar kracht te zetten; dat is de taak van de ambtelijke hiërarchie, dienend leiderschap is niet iets gratuit. Het team is verantwoordelijk en niemand anders! De opgave eigenaar en zijn/haar wethouder spelen elkaar aldoor de bal toe; zij zijn ‘accountable’ naar elkaar toe. Gemeenteraadsleden worden erbij betrokken, bijvoorbeeld met halfjaarlijkse kader stellende opgave bijeenkomsten, waar alle relevante actoren aan meedoen. Tijdens die bijeenkomsten leggen het team en de wethouder ook verantwoording af, om te beginnen aan inwoners. De belangrijkste partnerorganisaties participeren in het opgaveteam; de netwerkorganisatie krijgt zo geleidelijk vorm.

[1] Steve Denning: the age of agile

Thursday, May 24, 2018

The two blind spots of business agility: Allocating resources and accountability

Agile leadership conferences are popping up; there is apparently a need how to lead so-called autonomous teams and team-of-teams. Of course organizations need management functions to support these viable teams and the question is what are these management functions? Leadership is not one of the pillars in the age of agile described by Steve Denning, how come? Cross functional (self-organized) teams are rightly so in the picture but then only when intimately linked with delighted customers in a complex business environment (see previous article). Variety is an important indicator for complexity and only variety can absorb variety, learns the requisite law of variety developed by Stafford Beer for viable systems. Beer’s model is based on the maximum autonomy of operational or frontline teams; they should be viable to be able to absorb variety and deal with complexity. I ask myself how a network or ecosystem could be dynamic with autonomous viable frontline teams and also be vertically aligned with strategy. In agile we say goodbye to pyramid bureaucratic organization structures and inspired by Intel and Google companies introduce OKR performance systems and surprisingly a new pyramid top-down structure is created. Strategy alignment overwhelms values like empowerment, autonomy, trust and it frustrates experimenting. The agile mindset is horizontal in orientation, argues Steve Denning and that sounds rather vague. All well and good, but teams or their team leader should also be 'accountable' to ... management? And in order to obtain extra resources (talent, time or money) to better serve the customer, the frontline team is asked to write a well-founded business case and then, due to the slow procedures, they would have to wait months for an answer. In this way agility vanishes like smoke in the wind. Hamel fulminates against bureaucracies and proposes to move from a hierarchy of authority to a hierarchy of competences. And how does accountability fit in Hamel’s view? What is the role of leaders in a system or network of viable teams? It is time the business agility community bites the bullet about accountability and allocation of resources and that will pave the way for appropriate agile leadership.

I believe we need guidance or something to fall back on, that makes it easier to structure business agility with viable operational teams and appropriate leadership, based on the agile values. It is time to consult the experts on organization, like Mintzberg or the system builders of the Cybernetics like Stafford Beer. Beer introduces management functions to support and facilitate the viable frontline teams. Management then has the task of nurturing the team and the team-of-teams, providing them decisively with resources; to ensure that these teams can be highly successful instead of drying out. 

The Viable System Model( VSM ) of Beer describes four management functions that are minimally needed so that a system or operational unit (1) can function 'viable' in a changing and complex environment; these management functions are:
2. Coordination and communication,
3* Audit, information & data,
3. Integration & alignment, management in the moment: a. Accountability, b. Resources,
4. Intelligence & strategic planning,
5. Purpose and values.

Since the (relative) autonomy of the operational team is the starting point, the task of the other four functions is to provide support and services to the team. Beer uses nature as a source of inspiration and in a living system is no hierarchical power model. The communication between the (sub)systems is never one-way traffic but happens via closed information loops. For the tribe or department, you can visualize it as follows:
Viable system model (Beer, 1979)
In the picture there are three operational teams that have a relationship with their customers. These three teams are in three ways connected with the management function: Integration & alignment: coordination (2), audit & information (3*) and the 'hierarchical' relationship with resources and accountability (3). It is a complicated picture and in the course of this article I will highlight the parts, thus making it easier to understand. A remarkable feature of Beer's model is that the organization with management functions and operational systems connected with the environment are repeated in the subsystems. Besides it is not the case that the management functions 3, 4 and 5 would be higher or more important, even though the picture might suggest this. Therefore, Beer introduced the word recursion levels. I have adjusted the figure slightly to make it current: I replaced the word audit with audit, information & data.

The management function 4: 'strategic planning and intelligence' concerns also the exploration of markets for the future: to develop market-creating innovations. Beer relates intelligence (innovation) mainly to the external environment and to the R & D department of the past. Building up intelligence can now be found at all levels, it is a function and that means that team members also develop activities in the field of management function 4: strategic planning & intelligence. I will return to this in a next article, in which the MT and operational teams build intelligence on business development models. In this article I focus on management functions 3 and 3*. I discussed coordination (2) in my former blog.

Note, a viable system is about functions and not about people. It is common agile practice that a person operates in the operational team as well as in management function 3: Integration and alignment. For example, you can often see this with product owners performing regular team tasks. And since informal leadership is encouraged with all team members, it makes sense for team members to take on management functions from time to time. At Riotgames for example, they separate roles and responsibilities and team members can take on certain responsibilities which belong to the management function.

At team level the picture of Beer looks like this:

The leadership team with their leadership roles, like the product-owner, chapter-lead and agile coach operate in the management functions. The visualization shows that the operational team interacts with its customers and not just the product-owner. The product-owner has the responsibility to record customer (user) stories in the backlog. In the sprint planning meeting the team is in management function 4: planning. The team is responsible for the minimum viable products and in the review and retrospective meeting the team operates in management function 3: integration & alignment. She is accountable to herself and the customer. In addition to the responsibility of having developed a product in accordance with the agreements during the sprint planning meeting, the team checks whether they have developed a product in line with the wishes of the customer and whether they are still working on the right track. In other words, they collect new information for the next sprint planning meeting. The Agile & Learning (A&L) advisor (organization coach) facilitates the smooth cooperation between team members and monitors that individual activities do not interfere negatively with the activities of other team members (coordination 2).

Integration and alignment (3) 
System 3 optimizes the internal business environment and the synergy of the (sub)systems. A point of attention in the organizational structure is the vertical alignment between teams and the organization. Teams will have to coordinate their activities, to fit into the bigger picture. And that is not always easy. At the tribe level, the leadership team has an important task to monitor and promote the alignment with the organization through targeted (management) information provision for example in team-of-team meetings. In other words, it creates conditions in such way that teams have the ability to arrange alignment as much as possible themselves (Kniberg, 2015). The teams check whether their products are 'aligned' with the strategy. It is up to every team to anticipate on that information. And sometimes that information from the Management Team will look like an order. It is important that teams digest information about new directions, after all, they are viable systems. It is also possible that the team has crucial information from its customer world, which is important for other teams and for the strategy choice of management. The crux is that teams are involved in the strategy choice of management and management is hopefully aware that frontline teams have to offer a lot to build up new business models and an effective strategy. The entire organization need to have a voice in creating strategy (Hamel), see also the strategic agility case of Sri in book Denning

The team-of-teams must of course have a clear and sharp target (management function 4) and the tribe leadership team ensures that everyone has a clear vision. Since it is a management function, the representatives of the teams, usually the product-owners, participate equally in the determination of tribe goals and strategy. At this higher recursion level, participants analyze whether the result of the sprint is 'aligned' with the products of the other teams. Alignment is not just about goals and strategy; it can also be about the 'architecture' to align the products made in the different teams, see the SAFe approach.

'Accountability' is also part of the management 3 function: the tribe holds the teams to account for their results, for the teams themselves, for the customer and for the other teams. Operational teams are held to account about their contribution to the company. However what can you expect when accountability is an attenuation of high variety happenings (Beer, 1985) ? Also, it is said that the team holds management to account, the purpose of management in any agile organization would be to accept accountability for results. This would help to assure that the focus of management remains on the support, care and feeding(resources) of their frontline teams. In other words how can a team be hold accountable when she depends on resources provided by management and when she has no control or influence all the environmental variables that influence a set of OKR’s? Also I ask myself how to understand accountability with agile values like trust and empowerment. Below I will elaborate on the allocation of resources and accountability.
Figure: Accountability loop (Beer, 1985)

Allocation of scarce resources 
A viable system needs food and that comes from outside. By purpose Haier and McCrystal speak about “watering plants” by management as a metaphor. The operational team needs time, money and sometimes extra manpower with specific expertise. For a viable frontline team, it is crucial that she has the time to carry out activities and experiments in coordination with her customers. This means, for example, that the team members' agenda is not completely sealed and there is room for flexibility and experimentation. In the sphere of agility there is a lot of experimenting and then the team sometimes need extra funds which is not budgeted. Sometimes the team needs specific expertise from 'outside' to make activities a success and often it is about people who are being questioned by many teams.
There is a shortage of mental healthcare nurses in the neighborhood teams. In consultation between the district teams, it will be discussed how these nurses can be useful in the various neighborhood teams. The district team manager mainly has the task of helping the team representatives to come to a workable decision-making process. 
The hierarchy has the power over the distribution of scarce resources. The resource bargain is the deal by which some degree of autonomy is agreed between senior management and operational teams. Management provides negotiated resources for certain objectives. The bargain itself constitutes a variety attenuator. When the management handles requests for additional resources from operational teams in slow procedures, the viable system quickly dries out with all its consequences. This will have to be done differently, otherwise there will be no results of the micro-battles together with the customer. The management positioned in the management unit has to take care about feeding the frontline teams. The challenge is to use resources mainly in those teams that (might) generate most value.

But, who assesses which potential product would generate most value? The strategy analysts at C-level? With regard to allocating extra resources for a team, the temptation is to lay down decision-making in the hierarchy. You can read the degree of autonomy on the freedom levels of the agile teams in terms of access to scarce resources. In practice, teams often have little room for maneuver and management limits the resources in its limited wisdom, since it does not oversee the variety in the team's business environment. For example; when a team comes to the conclusion that certain expertise must join the team, to what extent can they recruit a new team member themselves or receive extra money avoiding time consuming procedures? It is obvious that the team justifies the application; this is also important in the negotiation with the management. But the management must also have confidence, otherwise there is a risk that the team is busy for weeks to write a bulky document and then you put the cart before the horse.

It becomes even more delicate when a frontline team creates new business.
In the 'founders mentality' approach of the Bain & Company, teams with their 'franchise player' as lead, implement micro-battles in the market. The management will think up three times to refuse a request for more resources, such as money, expertise or time. James Allen argues that the application of extra resources for micro-battles is often of small order (Bain & Company, 2017). In a 'founder’s' organization you often see that the 'franchise player' has short lines of communication with the CEO.
The open dialogue between frontline teams (the franchise-players) and top management is key to decide about the allocation of scarce resources. And a bit of friction between the actors is OK, acknowledge it openly and deal with it.

 A tribe leadership team or the company must have the resources to be able to anticipate the requests from the frontline teams. For such situations, McGrath (2017) argues that there should be a separate group in the organization that falls directly under the CEO that can make small amounts of resources in short time available for experimentation and that may open doors to future opportunities, even if they can’t be assessed in conventional financial terms. In this way the resource channel will also amplify the variety absorb capacity of the team and not only attenuate it.

What do we mean with accountability when we talk about viable systems and business agility? Agility opinion leader Ahmed Sidky from Riotgames spoke several times about accountability at conferences. I agree with Ahmed that accountability is a key factor in business agility but remarkably at the moment it seems not to be a hot topic. Ahmed argues that in the scrum design or agile framework no one is authorized to hold teams to account: not the team itself, not the product owner, not the scrum master, not the chapter-lead. You cannot say that the product-owner is accountable for the performance of the team.

Ahmed Sidky (Riotgames) distinguishes between responsibility and accountability:
  1. Accountability To hold someone to account and question their fulfillment of the duties and tasks assigned to them. Accountability acquires answers and entails consequences. 
  2. Responsibility A strong feeling driving someone to willingly perform their duties with total ownership (no excuses, no blame). Do whatever it takes to make it happen attitude. Ownership is a collective responsibility and the team is responsible for its results. . 
To hold oneself accountable is a crucial task of a person, a team, a system, to take time for reflection about the results and team members should ask themselves now and then if they are still working on the good things.
Every self-employed person is accountable to him/herself in his/her own time. I mean that he/she will occasionally reflect about whether he/she is still busy with the right things and whether the products are in accordance with the expectations and wishes of customers. The self-employed person does this at the higher recursion level: management function 3 Integration & alignment. 
A key element of accountability is that a team presents its minimum viable products to someone external: to avoid groupthink and to reveal the blind spots. In presenting a product to someone external the team will feel an obligation to present a well-founded argument of their story. This means that teams are not held accountable, they make themselves accountable to other people in the management function 3. And since you know that the external party will ask questions, the team can also prepare for this. A team reflects on the sprint results and in the review meeting the team presents and discusses the minimum viable products with their customers. And since the frontline team is the best informed about the variety in the customer’s environment, the review with customers is of great value. In agile terms this sounds so obvious: the customer holds the team to account. The team answers questions from customers and entails the consequences in their backlog. However, in many so-called agile work environments customers or end-users are not invited to the review meeting. I ask myself if representatives of customer service or management are good replacements for customers. Large companies sometimes use the argument that hundreds of teams cannot all consult with the customer. And before you know it, the customer or end-user is not invited to any team.

In the review meeting the team presents its minimum viable products to the product-owner operating in management function 3. The product-owner checks if the minimum viable product meets the expectations set in the planning meeting and collects information for the next sprint. Accountability starts with clear and visualized expectations and commitments. It is not self-evident that expectations are clear and, in that case, to hold the team to account is tricky. The team also holds the product-owner to account. However, you cannot say that the productowner is an external person, he/she is part of the team system.

The team, often represented by the product-owner, presents its minimum viable products and the feedback of customers also in the team-of-teams. The team is held to account. It is important to inform the higher recursion levels to facilitate horizontal and vertical alignment. The participants in the team-of-teams consultations are also 'accountable' to each other (McCrystal). Also, tribe leadership is empowered to get the job done; a team-of-teams needs rituals and triggers to hold tribe-leads to account.

Accountability is the ultimate learning tool, argues Ahmed Sidky, if structured properly. indeed.Accountability means questioning for learning; it gives the product-owner the role to ask questions in the review meeting, it gives tribe leadership the right to ask critical questions in the team-of-teams meetings, it invites all participants in team meetings at all levels to ask critical questions to each other. Asking critical questions in a psychologically safe work environment is key in excellent teams. Next to safety Daniel Coyle (2018) distinguishes openness & vulnerability as a key pillar for team excellence. Vulnerability appears to be key for tough and seasoned navy-seals, with openness in the after-action-review in which all is said what has to be said, for learning and to perform better next time. You do not need a leader for excellence; after action reviews for navy-seals are not led by commanders but by enlisted men (Coyle, 2018). You need an appropriate culture, working methods, rituals & triggers to build up excellence. A smart team asks external smart people for help, they are open and show vulnerability and they apply the hierarchy of 'competences'. The A&L-advisor (organization coach) has a major role to strengthen a team’s culture (safety and vulnerability) and learning climate for excellency.

Management in the founder’s mentality holds franchise-players to account, not to leave management’s mark but to listen, learn, ask many questions and try to understand the variety of customer’s environment, the dilemma’s and the reality of frontline teams. They try to assess patterns as input for broader organization issues, together with franchise-players (team leader frontline team). The franchise-player recognizes that he/she should invest time and energy in management; to give them the opportunity to fulfill their management role. In this way, the word accountability gets a different meaning.

At the Business Agility Congress 2018 in New York, I asked Ahmed Sidky (Riotgames) about accountability and I interpreted his answer also as follows: someone should be authorized to act when a team does not perform or when a team does not come to an agreement or decision. How to act as leadership when a team is not functioning properly and the results are not in line with expectations? And when this is the case, poor results do not mean automatically that a team performs badly; maybe the team is confronted with a complicated persistent problem. or the team decided in sonsultation with the product-owner to spend a considerable amount of time on a promising experiment and postpose delivery of the minimum viable product. So first ask questions and explore the subject matter.
 At Haier the team has to deal with poor results; it is their concern to deal with less sales or less profit and subsequently less income for each team member. In this way you immediately solve the issue of accountability. 
Poor results may have to do with the market (there is less demand for the product or the team does not really understand the needs of the customer), with problems in the team (process) and with problems in the management functions and especially at higher recursion (management) levels. A smart team in trouble asks external smart people for help, they are open and show vulnerability and they apply the hierarchy of 'competences'. And in line with the ING orange culture code; other people jump in to make teams asking for help successful. When a company labels this culture code as a guiding principle and a team does not ask for external help while struggling with a huge problem, then the team risks its viability. She should be aware that she is breaking basic principles of agility, with all that this implies. The A&L advisor will also be alerted when this takes place and will address it in the team. In case of friction or conflicts between teams or between team members, people who mainly operate in the higher recursion level will have to resist the temptation to seize the hierarchy of authority. They have a supporting role so that both teams can reach an agreement. To this end, they will check, among other things, whether all arguments are on the table and whether the balance between these arguments is correct. And last but not least, it might be possible that certain impediments cannot be solved and then together with the tribe-lead in all openness an action plan will be made.

Also tribe leadership might call for help and show vulnerability. People from operational teams might jump in to make tribe leadership successful (executives need reports in 24 hours, because …..). Practice what you preach! In former times these requests would have sounded like an order, in agile times with a hierarchy of competences operational teams will feel pleased to help. Hopefully it is experienced as fun and people will tease tribe leadership: “is the manager back?” and then it is OK. Please note: these requests should not be daily practice, because requests from hierarchy are a sensitive topic and asking for help can be experienced as quite compelling.

Audit (3*) 
But what to do when the team does not call for help or is not aware of a problem? First of all, tribe leadership needs information to become aware of poor performance; she has to be mindful with regard to significant weak signals of poor performance. Then she will have to be able to collect information in the team to get a good insight into the team problems; she enhances her capacity to absorb variety. People in the management function 3* at tribe level will perform an audit in the viable team concerned. All teams know that tribe leadership may decide to undertake an audit. It is not obvious that the tribe-lead should conduct the audit; consider if some people from other teams perform the audit. In that case they operate in the management 3* function. Subsequently the audit team discusses the collected information with the team concerned; also, to understand all the variety and complexity in relation to its environment. Together they will develop an action plan.

If the team with all the support and extra information does not change or even worse is not willing to recognize that there is a problem or if the team is not able to anticipate strategic choices, then a decision has to be made. Of course, as tribe leadership you will not let a team struggle with a known expert but dysfunctional team member, even if that person is of great value. The tribe leadership team, team leader, captain lead (Riotgames), franchise-player (Founder’s mentality) then takes the decision: the hierarchy of competence then makes room for the hierarchy of authority. Team memebers know that management can use this authority sporadically. I suspect that teams in such cases are often relieved that a decision has been taken. The tribe leadership team can ultimately decide to withdraw the resources. Be aware that this leadership behavior should occur only rarely in an agile organization, if not all the all alarm bells have to go off! Than the agile culture is in danger.

Information and data (3*) 
There must also be a transcendent function that monitors the greater good. The whole must be optimized and not the individual parts. Organizations collect information to know whether the system as a whole is capable of absorbing the variety; municipalities check whether all their activities are still in line with the intention and companies check whether customers are still optimally served. Data is collected in the teams and is intended to gain more insight and to learn from. Tribe leadership has also access to these data, without interference of the team. Due to good coordination and communication there is less need for monitoring and control, but there is still some need. After all, self-interest and groupthink can consciously or unconsciously ensure that communication is not free of biased information. A team may have a blind spot for certain issues.

In management function three*, information also flows to the operational teams; it mainly concerns information from management and from other tribes. It may also include information about possible new market-creating innovations, which teams will try to connect with their own customers or market segment. Of course, Artificial Intelligence and smart profiling might help to send relevant information.

The viable system model from Beer provides a framework to position the viable operational team supported by management functions. More and more, I come to the conclusion that an appropriate organization and consultation structure with a sharp view of the roles of people, resulting from the agile core values, plays a major role for successful teams and team-of-teams. The five functions of Beer provide a helpful framework to support viable systems. I plea for a more open constructive dialogue with regard to the vertical alignment between operational teams and management function 3: integration & alignment. Operational systems can only be viable when we are clear what we mean with accountability and when resources like talent, time and money can be allocated quickly on request. With regard to accountability I distinguish between external consultation in line with the hierarchy of competences and decision making by leadership in case of huge problems in teams. Build up a culture based on safety and vulnerability where ownership, questioning, learning and asking for help is normal work practice. In the learning approach of business agility, the hierarchy of competences is leading but you need an escape in case of huge problems in a team or team-of-teams. Top management and in fact everyone should be alerted when this escape is applied regularly; in that case it is not an escape anymore but common practice and then all alarm bells have to go off. Than the culture build on safety and vulnerability vanishes like smoke in the wind. Be mindful about these weak signals for the cause of excellence and success.

Thursday, May 3, 2018

Viable systems in network of teams for business agility in a complex environment

The network of teams is promoted in many places. Steve Denning presents in his new book: The age of agile, for example the 'law of the network' as one of the three pillars for a work environment with an agile mindset or for business agility. Recently, the Scrum Alliance also added its contribution with scrum@scale. Another movement focuses on teams with a lot of self-management that characterizes the self-organization. It is not that difficult to visualize a network of teams, but then you do not solve the question of how well a network of teams could turn out. I ask myself how a network could be dynamic with autonomous frontline teams and still be vertically aligned with strategy. In agile we say goodbye to pyramid bureaucratic organization structures and inspired by Intel and Google introduce OKR performance systems and not surprisingly a new pyramid structure is created. Strategy alignment often overwhelms and values like empowerment, autonomy and trust seem to fall by the wayside. All well and good, but teams or their team leader should also be 'accountable' to ... management? And in order to obtain extra resources (talent, time or money) to better serve the customer, the frontline team is asked to write a well-founded business case and then, due to the slow procedures, they would have to wait months for an answer. In this way agility vanishes like smoke in the wind. Hamel fulminates against bureaucracies and proposes to move from a hierarchy of authority to a hierarchy of competencies. And how does accountability fit into Hamel’s view? How to organize the information flow and which consultation or meeting structures are relevant for business agility? The perspectives of organizational and learning psychologists offer too little perspective, even though learning has been promoted to strategy (in the platform economy). I think we need a guidance or something to fall back on, that makes it easier to structure business agility. It is time to consult the experts of organization, like Mintzberg or the system builders of Management Cybernetics like Stafford Beer. In this post I will elaborate further on the interaction between operational teams and customers. In my second post I will elaborate on the management functions.

Customer delight 
We live in the era of artificial intelligence and agile. Steve Denning describes in his recent book that business agility has three pillars:
  1. Customer delight 
  2. Cross functional team 
  3. Network 
  4. I add a 4th pillar: strategic agility, also mentioned in Steve’s book
The 'law of the customer' is not by coincidence number one. Denning refers to Peter Drucker, who argues that the only reason for the existence of the company is the customer. The customer should be leading in everything companies do and how the organization is structured. In his new book, Denning makes it clear that many companies say they are customer-oriented, but that they do not coordinate their processes and the organization of the company accordingly.

In the agile manifesto the highest priority is to satisfy the customer. In the agile methodology or agile framework, the product owner is responsible for the customer stories (user stories) and in the review meeting the team justifies its minimum viable products to the customer. Sounds good, but in how many companies is the customer actually participating in the review meeting? How often do you not see that customer service represents the voice of the customer? Are teams afraid to present an unfinished, a minimum viable, product to customers and end-users? Is the reputation of the business at stake? Barclays gives a good example with agile teams on the stock market floor and in municipalities the purpose teams would organize review sessions in the municipality. Organize the review sessions at customers’ place with the post-it wall at the customers’ place and not at the companies’ office. Be transparent starting with customers, that is the basic idea behind the agile manifesto.

In the business agility conference 2018, James Allen of Bain & Company presented an impactful approach. Bain & Company aptly describes that growing companies often fail to keep the pioneers (founder's) and entrepreneurial mindset, while they need that 'insurgency' in a rapidly changing environment. Companies with a pioneers or 'founders' mentality have three overarching elements:
  • an extraordinary feeling for insurgency, 
  • a frontline obsession (customer delight), 
  • owner mindset.
What appeals to me is that Bain & Company focuses on the interaction between the frontline team with customers and that the rest of the organization is in fact at the service of this interaction. These are also the first two pillars of Denning and they become extra powerful when they are connected to each other. The pillars and the connection between frontline teams and customers form the foundation for building a viable, agile business.

Interaction between frontline team and customers is the core 

Viable system model
Time to switch to the Viable systems model (VSM) of Stafford Beer. The model offers a solid framework that provides guidance for smartly organizing and strengthening the network. The VSM is about the capabilities of a system, read the team, an organism, a department, an organization, to be viable. Beer defines viable as the ability of a system to continue to exist independently, balanced with its environment. Beer uses nature and cybernetics as a source of inspiration; where each organism must be able to deal with the complexity of its environment. The model is based on maximum autonomy of each (sub)system and that fits into agility. The Beer system approach provides insight into the dynamics between teams. He emphasizes that organizations facing disruptions must intervene on the interaction between teams (systems), at all levels of the organization. According to Beer, the clue is who interacts with whom (which (sub)system with which other (sub)system) and how all parts of an organization in a flat and self-organizing structure would work together in order to achieve resilience, flexibility and excellence. Beer offers a guidance to facilitate flourishing interactions. The USA army in Iraq became painfully aware that the interaction between teams is the key factor for successful operations:
General McChrystal experienced the enormous disadvantages of a bureaucratic army. The superior American army suffered enormous losses against a very flexible and poorly armed enemy. The US Army was far too slow. He saw that the problem was not in the cooperation within teams, but rather in the cooperation between teams. The cooperation with partner organizations was much worse. The solution was a network of teams with a team-of-teams.
Variety as indicator for complexity plays an important role in the viable system model of Beer. A system is viable as long as it is able to absorb the external variety. Teams are viable systems and as such autonomous and they independently process the information from the environment. Finally, they have the context specific knowledge about the environment. The starting point of Beer is that the capacity to absorb is the greatest where the variety comes in. Here the law of the so-called 'requisite variety' applies:
Only variety can absorb variety

The (frontline) team absorbs as much as possible all the variety that its rich environment has to offer. Diversity in operational teams would be helpful to be able to absorb the variety.
The frontline team then filters its information for the management. This means that the management can only partly understand the reality of the environment in which the team is operating. Also, the management can in turn add extra variety to the team; for example, with information from other departments or tribes or from the strategy drawn up by management. The team can in turn add new information to its environment. And of course, the subject matter specialists work in the frontline teams; for example, in banks the mortgage specialist works in frontline teams, it is in the business interest that these specialists interact with the variety of the environment.

Beer argues that the team absorbs the variety from its environment and ‘higher’ levels in the organization should not interfere. If they interfere, it will affect the viability of the team. You can ask yourself whether it is legitimate to intervene in a viable system. The operational team is therefore responsible for the relationships and coordination with their customers in their market segment.This applies also for municipalities:
In the complex environment of the municipality with a purpose-oriented approach, the youth purpose team for example has the knowledge, expertise and information about youth in the municipality. This team is also very aware about what is happening in the municipality regarding the youth issues. In line with the Beer approach, the purpose team absorbs the external variety. The hierarchy, read managers, the alderman or the city council support the purpose team and provide information, so that the purpose team can absorb the variety from the environment even better. The hierarchy should not want to interfere with the interactions between the youth team and inhabitants. Unfortunately, this often happens and it is not surprising that the ability of teams to properly absorb all external events is restricted or limited. In the terminology of Beer, you ask for difficulties.
The Chinese company Haier is also a striking example.
Haier uses the platform concept and defines a network organization as an ecosystem without borders with a management without managers. They created self-organized units (micro-enterprises). Haier does no longer try to delegate to, or ‘empower’ employees; every employee is his or her own boss. Ownership is so obvious and it avoids all those complicating accountability discussions. There are no hierarchies and managers: the platform owner, and that is often the CEO, is for example a servant responsible for feeding (watering) the ecosystem (see also McCrystal). What makes Haier outstanding is that an autonomous team, a cell, can recruit and dismiss people themselves and that the income of team members depends on the sales by the team. The team manages its own scarce resources and fits seamlessly within the Beer approach.

Teams at Haier absorb external variety

In Bain & Company's Founder’s mentality approach, everything is focused towards ensuring that the teams with their 'franchise player' can optimally handle the variety from the environment in their micro-battles and can immediately anticipate on new information. The management lead is supporting, listening and learning from the frontline team. This attitude from the management lead is a logical choice when the organization wants to understand the variety in the environment and is willing to act upon. In business agility vertical alignment and business strategy will be positioned differently; the business strategy will result from patterns distracted from the frontline teams and for example a cascading of OKR’s from the top does not fit into this.

You could also consider a network of teams as a system, where the operational frontline teams are connected to their customers.
Viable system model

The 3 teams in the tribe, visualized above, absorb and handle the variety from the environment. The cooperation between the teams is organized in such a way that all changes in the outside world are optimally anticipated. The management unit of a tribe consists of the tribe leadership team organizing periodically team-of-teams meetings. They create conditions that teams are able to absorb the variety from the environment.

Coordination and horizontal alignment (2) 
Teams in a network of teams (tribe) are dependent on each other and this requires coordination (2). Rules are required to deal with disruptions from one subsystem (team) that affect other subsystems; or in terms of Beer the oscillations of a team that affects other teams must be damped. This coordination takes place between teams and also takes place at a so-called higher recursion level: in team-of-teams consultations and with the tribe (department) leadership team. The tribe leadership team has the function to monitor the cooperation between teams; to check whether the horizontal alignment is well organized by the teams and facilitate optimal cooperation. They create conditions that teams have the ability to arrange alignment as much as possible themselves (Kniberg, 2015). The added value of this higher recursion level is that this function has a broader overview; since there are people who have information about what is happening in other teams and in the organization. Beer's starting point is that managing dependencies between teams requires no insight into what happens in the teams themselves (Beer, 1979).

Teams (operational units) work together to achieve desired results and they make the mutual dependencies manageable. Therefore, they make meaningful and effective mutual agreements and they set up the processes that are serving and not leading and are immediately adapted if the circumstances require it. The Coordination (2) function organizes the information flow to signal when rules and agreements between teams are violated. In addition, it is crucial that all parts communicate with each other and share all relevant information with each other and agree when consultation is necessary. The better this goes, the less the management function has to interfere and the greater the stability in the organization. In case of friction or conflicts between teams, people who mainly operate in management functions, the higher recursion level, will have to resist the temptation to seize the hierarchy. They have a supporting role so that both teams can reach an agreement. To this end, they will check, among other things, whether all arguments are on the table and whether the balance between these arguments is correct. It is the task of an A&L-advisor at the tribe level to support and facilitate the interactions between the teams and strengthen horizontal alignment; you could call it a senior Agile &Learning advisor (agile coach).

In business agility a frontline obsession is vital. The law of 'requisite variety' provides an additional argument that operational teams are the actor to absorb variety from the rich environment allowing to respond to the complex business environment for customer delight. The management then has the task of nurturing these teams and the team-of-teams, providing resources with decisiveness; to ensure that these teams do not dry out but can actually flourish. The viable system model from Beer provides a guidance to position the operational team well. Beer defines viable as the ability of a system to continue to exist independently, balanced with its environment. The meaning of viability refers to autonomy and self-management. I come to the insight that the organization and meeting structure with a sharp view on roles of people resulting from the agile core values, plays a major role allowing teams and team-of-teams to be highly successful.

Next blog
Beer distinguishes three management functions. In my next blog post I will describe how these functions can work, allowing the viable system of a team and of a team-of-teams to perform and excel. There seems to be an incongruity with a management unit and an operational team absorbing the variety. What is the role and tasks of leaders in a system of viable (sub)systems? How to understand accountability and how does this relate to autonomous viable systems? And how to organize resources for frontline teams in the moment of need, like: talent, time and money?