Governance to create the ultimate state of flow (3-3)

The biggest performance increase within an organisation can be made in the way we organise our work and the way we make decisions. Both are invoked by great leadership. Over the years we found out the organisational model we choose has no impact if the right example is not set by our top-level managers. Hierarchical, Metrix, Holacracy; I personally have worked with all these models and they all have advantages and disadvantages.

How to establish effective governance step by step? Read it in our whitepaper here

If the following rules of engagement are not realised, trying to become a high performer is useless because performance will be undermined somewhere somehow inside of your organisation.

There are a few rules or elements which are the basics to become a high performer:

• It all starts with behaviour and involvement of leaders because as we all know good examples will be followed.
• Vision of leaders is needed, which will be reflected in the vision and the culture of an organisation.
• Storytelling to create great trust and emergence will make people join in the organisation's strategy and add energy to the company.
• Transparency in leaders and two-way communication is fundamental for a reliable and safe environment to work in.
• Autonomous decision-making within teams in line with the organization’s strategic intentions and goals is essential to lower the impact of bureaucracy and wait states. Leaders should get involved only when performance is in trouble.
• Selection and rewarding of individuals and teams based on performance and outcome. Working with high, medium and low performing teams and a training facility gives maximum performance and keeps everybody motivated.
• Way of Work and craft above people gives flow, employers should to a certain extent be able to attend in different roles.
• Well performing machines, tools and facilities make people perform better.
• The organisational decision-making should under no circumstances influence performance in work in progress and therefore the way we do our work. Only by small correction is it possible to find out if the right decisions were made. If we need to make big corrections then we did not choose the right way of work.
• Managers within an organisation should only be responsible to facilitate an organisation to get the job done. They communicate decisions but do not make decisions. Leaders make decisions and teams make decisions.
• Last and not least: diversity in background, culture and sex, and an organisation of optimal polarity, will give the turbo we should all love to have.

When continue reading then keep the following organisational layers in mind.

Governance impacts our whole organisation and it’s often an underestimated factor to success. Governance should set our organisation into a cycling mode “to ensure low dependencies throughout the organisation and the minimisation of wait states, and to facilitate the learning from small mistakes to stay away from big ones and falling off your bike” on your way to reaching strategic intention. When you look more closely you will see it’s actually a Tandem bicycle with the business at the front constantly communicating with IT at the back, building up a relationship of trust to reach a higher performance continuously.

Like to read more about the billiards mode?

The organisational layers are only there to make it possible to look at the horizon (Board) while at the same time deciding (ITGB) which corner to take a bit ahead, and meanwhile keep on delivering the best performance possible (Cockpit and CD Teams).

Purpose of The (Executive) Board

What is the rationale of our existence? Why are we here on earth? How do we influence our operations? Operations are supported by IT to a high degree. The CEO puts IT support and the production of IT on the agenda. The CIO is accountable for effectively translating business ideas into supporting IT. The “Next” CEO will have to put a significant amount of his or her time into IT and should also be trained and experienced in the IT domain. They can no longer delegate blindly to their CIO; no modern CIO should accept this anymore.

Purpose IT Governance Board (ITGB)

Making policies and executing them is an important task of the executive board. It’s also very time-consuming. The average board spends a lot of time on financial affairs and a lot less on IT issues. This is partly because most boards don’t have enough IT expertise yet to discuss it in sufficient depth, and partly because in IT issues, practically all business aspects are involved. IT issues affect all levels of the business and determine a significant part of the financial scope.

An ITGB is a delegated body of the company board. The CEO is its chairman, the CIO manages it and/or is its secretary. An ITGB consists of people from the business as well as from IT who are responsible for producing IT. ITGBs focus specifically on issues where IT is not (yet) running properly or is not (yet) productive. Usually this means subjects like managing your substantive governance based on “preferable lightweight” Enterprise Architecture (https://architectural-thinking.com/), Portfolio Management, Risk Management, and Auditing.

The ITGB is the place where business issues and IT issues meet, where business and IT convene, and where directive decisions are made through the board.

The purpose of the Cockpit “for DevOps”

Innovation on scale is impossible without a firm grip on business capabilities, business rules, business objects, service contracts, and a strong framework of detailed company models, in my favorite way of expressing them in terms of Tasks, Activities, Rules, Information, and Integration (TARI2).

Together, these aspects indicate the direction in which the solutions lie. This direction is then determined by a multidisciplinary team called The Cockpit. It comes under the ITGB and it builds up and maintains the aforementioned aspects. There are a lot of names in circulation for this organ, but in our experience most of them don’t really cover the aspects below. That’s why we introduce a new name for it: Cockpit.

The Cockpit is the starting point for new IT solutions to be produced and to manage transience of current solutions, because it has an overview of which reusable and/or adjustable business patterns and services are available. It’s done based on a model-type construction of the operational management (company models) and IT service contracts. The existing IT portfolio is always taken into account (sometimes it contains a large amount of IT legacy). Examples are generic services (as useful) for the support of several similar (company) activities and specific services for specific (company) activities.

For each business solution produced, the Cockpit provides models, service contracts, and systems and services to be connected, and hands them over to one or more multidisciplinary production teams (Continuous Delivery Teams).

The Cockpit consists of roles like Business Owners of the business departments involved, DevOps, Analysts, Solution Architects and Lead Developers. Innovation by applying new techniques takes place after a solid testing and preparation phase before being used in a daily production of IT. The support for business solutions already in production takes place separately, but still under the direction of the Cockpit and not within a separate organisation.

New craftsmen within the IT organisation are appointed as instructed by the Cockpit, with a strong emphasis on what they can actually deliver – as opposed to a well-written CV and a good interview. You don’t want IT staff preparing main courses in the kitchen while they haven’t yet learned to peel onions. This is one of the biggest mistakes: to have highly skilled work done by people who have yet to master the craft.

The purpose of Continuous Delivery Teams

Continuous Delivery is a software production strategy aimed at taking ideas into production as fast and as efficiently as possible. It’s based on a highly automated process in the delivery pipeline, enabling a swift transition from change to production; the results will be immediately apparent and invite direct feedback from the user. This means relatively smaller risks, lower production costs, higher quality along the way, and a faster time to market.

The Continuous Delivery team comprises of roles like DevOps, Solution Architect, Back-End Developer, Front-End Developer, Integration Developer, Security Developer, Business User and again the Business Owner. A Continuous Delivery team works autonomously in small iterations, and reports pro-actively and fully automated to the Cockpit based on performance. Obviously the teams are only allowed to make adjustments to the IT service contracts and company models based on collaboration and strong communication with the Cockpit. If this does not happen, efficiency problems will arise along the way, which does not fit in with the new demand for flexibility. Let a team experience this for themselves, and let them learn from these small mistakes and overcome them.