Socio-Technical Architectures: Informality from Mining to Today[1]

This article is part of a series

• Part 1: Common Approaches in the Field of Socio-Technical Architectures
• Part 2: Platforms, Teams, and APIs: How Do They Fit Together?
• Part 3: Socio-Technical Architecture as a Competitive Advantage
• Part 4: Don’t Forget the People
• Part 5: How Much Thinking Can a Team Handle?
• Part 6: Internal Development Platforms
• Part 7: Enabling Stakeholders as a Success Factor
• Part 8: Socio-Technical Architectures: Informality from Mining to Today[1] (this article)

At that time, the “economic man” perspective dominated, where people were primarily motivated by financial incentives. The focus was therefore on payment, bonuses, and piecework. About 20 to 30 years later, this view shifted toward the “social man.” Now, social relationships and leadership styles were considered key to promoting motivation and satisfaction.[2]

During this period, coal was being mined extensively in Great Britain. Coal miners worked predominantly in autonomous groups that organized their own work processes. Despite established safety procedures, they enjoyed considerable freedom. From the 1940s onward, however, working conditions changed due to mechanization and specialization.

Work areas expanded, making communication more difficult, and the decision-making freedom of these groups was severely restricted.[3]

The result was a breakdown of social bonds and increasing conflicts. Both productivity and job satisfaction declined.

In the 1950s, research by Trist and Bamforth[4] showed that increasing bureaucratization and the loss of informal processes negatively affected efficiency. The concept of “socio-technical systems” emerged from this research.

What is a Socio-Technical System?

A socio-technical system is a complex work system in which technical and social subsystems jointly perform tasks.

The technical subsystem encompasses the tasks and the supporting or executing technology. The social subsystem describes the members, their roles, and the structure in which they operate. The technical system creates framework conditions for the social one, while the social system drives the evolution of the technical system.[5]

What Does This Have to Do with Us?

Why is INNOQ interested in the history of mining? Because the parallels to today’s organizational structures can teach us a lot. In the past, miners worked in fixed systems – today we enter our clients' often rigid socio-technical systems as external professionals.

Like the miners back then, we too must adhere to informal rules and unwritten laws that can strongly influence project dynamics. An example from our practice shows how such informal structures become visible in development projects and how they shape our approach.

Case Study: The internal Organization App

INNOQ was commissioned to develop an internal app for a company where working conditions have changed significantly due to the Covid pandemic. The app is intended to serve as a flexible solution to adapt work organization and internal communication channels to the new reality.

The following areas are affected and should be addressed in the app:

Office Spaces

Many colleagues work at least part-time from home or even in other countries. To accommodate this situation, the company has already downsized its office space. In fact, there are no longer enough workstations for everyone. Management therefore wants a system where desks can be booked.

Cafeteria

Similar challenges apply to the new cafeteria, which is also not designed for a large number of people. However, there are “peak periods” when the number of tables is insufficient.

Communication

In addition, internal interaction and exchange have become much more asynchronous, as employees no longer automatically work in the same location (and often not in the same time zone).

The initiative for the app came from management, not from the staff, which already creates potential hurdles.

Informal Structures

This shift in everyday work brings informal structures into play that the company has not officially established but which are nonetheless firmly anchored in daily routines. Such structures are not conscious directives from management or the works council but emerge through established practice. In this context, Stefan Kühl refers to “undecided decision premises”[6] that have been established through regular practice.

This isn’t a one-time improvisation – these structures are more like a well-trodden path. However, no documented decisions about this path can be found anywhere. Informal structures can be very stable and long-lasting, even persisting when regulations exist that contradict them.[7]

In practice, organizations frequently toggle between formality and informality. In fact, organizations benefit from informality. We all know the expression “work-to-rule,” which simply means adhering exclusively to formal rules. However, this expression is often understood almost as a form of protest.

Informal structures are therefore by no means exclusively negative for an organization. They are adaptable (unlike technology), promote innovation, and contribute significantly to the company culture.

What Does This Mean for the App INNOQ is Supposed to Develop?

As a reminder: Informal structures are primarily found in the lower part, in the social subsystem.

The members of the system are the users of the app – i.e., the employees and management of the company – but also us as external developers. These members operate in formal structures and roles, such as departments or project management, which are often clearly documented.

Alongside these, informal structures exist that only long-term members know and which vary greatly depending on the area. The task set by management is to support internal work organization and communication through the app – even though management itself may not have a complete picture of all informal processes.

Technologically, the app should flexibly support users in their way of working without creating unnecessary complexity. It needs to function without dictating processes too rigidly. How the software allows users to intuitively control work processes and accommodate informal, established procedures plays a crucial role here.[8]

Challenges in Developing the App

The application formalizes and bureaucratizes processes that previously ran informally (e.g., finding a free desk in the office or communication channels). Recall the mining example: There too, processes were formalized and established when machines came into play.

If the app fails to reflect informal structures, it may face resistance. It will then only be used to the extent absolutely necessary, while informal structures will likely continue to exist in parallel.

If the application ends up not being used, the project has failed. However, it can be extremely difficult to formalize shadow processes – as they are often called in the literature. This can become an extensive and complicated undertaking, as informal structures are highly dynamic and adaptable, which is often not the case with technology.[9]

Informal processes are often invisible because they are not documented, are based on relationships, and are influenced by subtle signals.[10]

What to Do?

How can we, as newcomers, recognize the informal structures so that we can take them into account when developing the app?

1. Requirements Analysis:

Informal processes are dynamic and based on human interactions. To capture them, we speak not only with management but especially with the end users. Methods such as sociomatrix, sociogram, or collaborative modeling help to map relationship networks and bring together expertise.

2. Build Systems to be Expandable and Flexible:

The app must be designed flexibly and leave room for adaptation. Development should be user-centered and agile, with regular user tests and feedback. It is particularly helpful to observe users in real scenarios, even with prototypes. Expandability and flexible use are crucial – even if this makes the UX more complex. Evolutionary architecture, lean methods, and agile development offer valuable approaches here.

3. User Testing:

Feedback is worth its weight in gold. Prototypes and MVPs (Minimum Viable Products) should be tested early – long before the final implementation. This allows us to directly check whether the application truly meets the requirements and will be well received. MVPs help to develop the most important functions in a targeted way from the beginning, without needing to complete the entire product first.

References

[1] Based on the podcast by Katharina Baur and Lena Kraaz titled “Sociotechnical Systems – Informality from Mining to the Present Day”, recorded on April 8, 2024
[2] Prof. Dr. Simone Kauffeld, Dr. Nils Christian Sauer (2019): The Past and Future of Work and Organizational Psychology. Springer Berlin Heidelberg.
[3] Trist, E. L., & Bamforth, K. W. (1951): Some Social and Psychological Consequences of the Longwall Method of Coal-Getting. Human Relations, 4(1)
[4] Tom Galvin, Pedro Monteiro, Miranda Lewis, Joe Bradley (2017): Sociotechnical Systems – Trist and Bamforth. Talking About Organizations Podcast, Episode 34
[5] Sutter, Anke et al. (2021): Sociotechnical Systems: The Human Factor in Industry 4.0
[6] Kühl, Stefan (2010): Informality and Organizational Culture – An Attempt at Systematization. Working Paper 3/2010
[7] Tretschok, Katja (2019): The Relevance of Informal Structures within Organizations. Master’s thesis, University of Applied Sciences Mittweida, Faculty of Social Work
[8] Wikipedia: Sociotechnical System. Revision as of November 8, 2024
[9] Sutter, Anke et al. (2021): Sociotechnical Systems: The Human Factor in Industry 4.0
[10] Kühl, Stefan (2010): Informality and Organizational Culture – An Attempt at Systematization. Working Paper 3/2010