Engineering Ideas
Published in

Engineering Ideas

Thoughts on Henri Mintzberg’s coordination mechanisms at organisations

The quotes below are from here.

Mutual adjustment

1. Mutual adjustment, which achieves coordination by the simple process of informal communication (as between two operating employees)

Mutual adjustment doesn’t require any up-front investment and produces good results, albeit at the highest coordination cost per unit of work among all the coordination mechanisms.

Direct supervision

2. Direct supervision is achieved by having one person issue orders or instructions to several others whose work interrelates (as when a boss tells others what is to be done, one step at a time)

Direct supervision reduces the coordination cost and thus might be helpful in challenging activities when attention is scarce. But, of course, direct supervision is not generally scalable. People dislike when someone orders them to do something unless in specific, agreed-upon situations.

Standardisation of processes

3. Standardization of work processes, which achieves coordination by specifying the work processes of people carrying out interrelated tasks (those standards usually being developed in the technostructure to be carried out in the operating core, as in the case of the work instructions that come out of time-and-motion studies)

Standardisation of processes (procedures) saves some coordination costs compared to mutual adjustment and requires a moderate up-front investment. Standardised processes that the coordination costs for the practice are zero, though, far from that. This is because processes almost always fail to produce results on their own and people have to resort to mutual adjustments outside of the formalised procedures. Something unexpected always comes up. This is why, in product development, adaptive case management is recognised as superior to process management or the classic project management in recent decades.

Standardisation of work processes makes sense for the practices in which digressions from the standardised paths are rare, such as for triaging support cases or performing manual tests before a release in product development. Whether the specific practice is a good candidate for process standardisation depends on the specifics of the particular organisation and project.

In the situations when full standardisation is possible, it’s also often possible at IT organisations to completely automate the process, such as running a suite of unit tests before merging some change into the code repository. Then, no coordination is needed at all.

Standardisation of outputs (work products)

4. Standardization of outputs, which achieves coordination by specifying the results of different work (again usually developed in the technostructure, as in a financial plan that specifies subunit performance targets or specifications that outline the dimensions of a product to be produced)

It makes the most sense to standardise outputs (work products) at the organisation boundaries (between organisational units, or between the organisation and the external world), for example, support request forms, or, when one organisational unit produces some work products and stores them in some informational bank of the organisation (per DEMO) and another organisational unit uses these work products later, such as test cases stored into a database by developers and later used by the testing team.

Standardisation of skills (practices) and knowledge

5. Standardization of skills (as well as knowledge), in which different work is coordinated by virtue of the related training the workers have received (as in medical specialists — say a surgeon and an anesthetist in an operating room — responding almost automatically to each other’s standardized procedures)

Standardisation of knowledge about the engineered systems and the organisation

Standardisation of knowledge about the breakdown of the engineered systems (and the organisation) into subsystems (organisational units and organisational functions, for the organisation) and using consistent terminology reduces the cost of coordination, as I noted here, in the section “Communication should become more reliable with shared reference frames”. This also permits scaling the coordination to a larger number of people.

The only way to achieve such a synchronisation among the employees and to keep it up as the engineered systems and the organisational structure are constantly changing is to actively maintain a set of system-centric views of the engineered systems and the organisation itself and to have a norm (see below) that people should correct each other when they notice someone digressing from the current conventions in their writing or speech.

Another reason (unrelated to coordination per se) for making the knowledge about the organisation and the future of the organisation, i. e., the plans and the strategy, explicit and available for the employees comes from the theory of Active Inference: people like certainty and seek to be in the environment and the context where they can understand and predict what will happen to them and their environment in the future.

Standardisation of practices is more effective than standardisation of processes in the long term

Standardisation of skills (practices) usually allows saving more in coordination costs than standardisation of processes, which is discussed above. However, standardisation of practices requires a bigger up-front investment in training people in those practices. Therefore, if the organisation (or the organisational unit performing the given practice) has a relatively short average employee tenure, or if the company has the expected runaway shorter than two years, or if we are talking about the coordination in the practice that is probably going to change radically (or is going to be completely automated away with the help of AI) sooner than in two years, then sticking to mutual adjustment or to standardisation of processes is preferable to standardisation of practice. Otherwise, standardisation of practices is more effective in the long term.

If people who are involved in some case know the practice well and know about each other that they know the practice, they can tune the level of formality and detail commensurate to the size and the importance of the case, while following the spirit of the practice. Moreover, this tuning doesn’t require any extra coordination because all involved people can see for themselves the steps omitted from the “maximal version” of the practice and will understand why this simplification is adequate for the case at work.

For example, there is a very heavyweight template for engineering change proposals (see alphas of project decisions) which engineers may follow in full only for the most important and consequential change proposals. But if all engineers discussing a change proposal know this template well (that is, used it meticulously a couple of times for didactic purposes), the quality of their proposals, discussions, and decisions will be higher than if they just strictly followed a simpler template with a few sections such as “Context”, “Issue”, “Solution”. Such a template is essentially a form of a process.

Checklists are more flexible than templates in this regard because they allow for more open-ended questions such as “Didn’t you forget to think about aspect X of the system?” and “Didn’t you forget to think about concern Y of the role for the system?”. There could be many more such questions than sections in a reasonable document. Sometimes, these checklists even fuse into some form of a body of knowledge (for a certain practice), such as in my Java concurrency checklist.

Amazon’s famous six-pager (see Working Backwards) is a good example here: there is no template for a six-pager, but there is a curated practice of writing six-pagers at Amazon. New employees acquire this practice from their colleagues in a peer-to-peer fashion: new employees read multiple examples of particularly good, exemplary six-pagers from the past, and also write their first several six-pagers pairing with colleagues who are already good at this practice.

Google is also known for the standardisation of its working practices. Programmers at Google should earn a “badge” that they have acquired the Google’s practice of coding in a certain language, and every change in their codebase must be either written or reviewed by an engineer with such a badge (search for the “readability training process” in this paper). Google also standardises their project management and site reliability engineering practices. These are just the example that I’ve heard of, but I assume there are many more.

High-level coordination practices which every employee at a development organisation should acquire

The following practices (either of coordination, or involving a lot of coordination) are very high-level and thus are unlikely to change often, so it makes sense to train in these practices all employees at an R&D organisation:

  • [Async, written] communication, active listening and giving feedback.
  • Participating and running meetings.
  • Operational management a-la The Principiles of Product Development Flow by Donald Reinertsen and TameFlow.
  • Proposing changes, discussing the proposals, and decision-making
  • The core types of objects of attention for systems thinking: system, system view, role, concern, project, practice, case, alpha, and the relationships between them. This is a prerequisite for two other practices:
    — Systems management: the way status updates between a manager and a team member and business review meetings are organised.
    — Systems engineering (or, knowing the principles of it).

Some of these skills and practices are so generic that we could also look at them as standardised norms, as discussed below.

Standardisation of norms

6. Standardization of norms, in which it is the norms infusing the work that are controlled, usually for the entire organization, so that everyone functions according to the same set of beliefs (as in a religious order)

This notion of norms is close to Amazon’s notion of principles (see here, the section “Write down the organisation’s principles and put them to use”), as well as Ray Dalio’s principles (see Principles: Life and Work) and Steven Covey’s principles (see The 7 Habits of Highly Effective People).

Standardisation is impossible without writing the norms down and integrating them into the organisational systems and practices. Indeed, all three sources mentioned above emphasise that principles should be written down.

I suppose that standardisation of norms probably becomes more important at large organisations (I’m not sure how large though, and whether the Dunbar’s number is relevant here) as well as at organisations with a portfolio of relatively loosely coupled projects if these organisations want to maintain a certain style, hiring brand, and to have an ability to transfer people between their projects at a lower cost and a lower risk of a failure, which also translates into the expected cost.

Writing down the norms at a small organisation may seem preliminary or overkill, but on the other hand, making the norms explicit probably increases the chances that the organisational culture (the set of norms) will be set at the point where the founders actually want it to set. Once the organisation grows larger than a few dozens of people, it’s notoriously hard, sometimes impossible to change the norms significantly. “Culture matters” by Dan Luu and “Don’t fuck up the culture” by Brian Chesky are the relevant reminders here.

However, one can note that although it became trendy for startups to write down their aspired norms (or values, as they more often label them) very early on, this alone doesn’t work, and most such values remain aspirational at best:

The norms of professional trust and role-based responsibility

The norm that seems particularly relevant to coordination is trusting the work of other people who are professionals at their job within their area of responsibility. This means not second-guessing each other at everything, unless there are very serious reasons for doing so, or outside of the time periods dedicated to discussing the idea and collecting feedback.

This idea is related to the following idea from systems methodology: when discussing any question on a project, people should keep in mind the role (or multiple roles) they are taking in this discussion, and the roles of every participant should be clear to everyone. The same person should not have a conflict of interest due to their multiple roles in a system.

This post was originally published on Substack.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store