Trying to disrupt your management model?
Computational heuristics applied to management
Heuristics define approaches to problem-solving, system mental representation and in a broader way, a way of thinking. Heuristics we handle daily largely impact the way we think.
This article is meant to demonstrate the use and pertinence of typical programing and engineering heuristics in the management field. As I often noticed in my work experience, we tend to develop a much more rational approach on engineering problems than in the management ones. It is mainly due to the fact that program design is logical and computational by nature. At the opposite, management involves much more human problematics and fuzzy decision makings. The rationalisation process of management often invites to a deep dive into archetypal and fake rationality. For exemple, uses of poorly collected metrics, misuses of data and fuzzy ideas that falsely look binary because these are framed in diagrams are frequently observed in the management process of many organisations even at NASA. Even if management tends to be a rational science, it is hard to apply a logical thinking as safe and trivial as in programatic thinking.
Organisations tend to be more fuzzy than programs and that is not new, meanwhile, due to the trivial logic thinking of programming, the domain is gifted with a rich heuristics and paradigms library that should be useful to management people and help us all gain in rationality.
Here is a collection of raw but resourceful heuristics commonly used in programming and engineering ( not only ). Take it as it comes.
Why should management get inspired by computational heuristics ?
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway 1967
Here are some facts:
- we live in a computational world
- a large amount of activity, exchange and value exists only in a digital ecosystem
- businesses and organisations are becoming more and more digital in its structures and tools
- there is a fair chance that as you ( a management fellow) work closely on a daily basis with engineers and programers.
- computation seems pretty limitless
- computation is either logical or dysfunctioning.
As Conway stated there definitely is a symmetry effect between the organisation and its system, but we must take in account that the balance between the device built by an organisation and the organisation itself is not the same than in the 60’s. Today, a large amount of companies rely on their home designed back-offices, CRMs, web-apps. As it is true that these devices structures reflect the organisation’s one, the opposite is now equally true. In a broader observation, the way our society and businesses are structured around the web and digital tools reinforces the probability that your organisation‘s structure should reflect [ the web and digital tools one ]. If not, I encourage you to think about it, it might be interesting.
And… The more you will think like a geek, the more you will optimize your communication with the geek team. And that is good for everybody.
Objet-oriented management
In computer sciences, the core concepts of Object Oriented Programming ( OOP ) are : encapsulation, abstraction, inheritance, polymorphism and each element can be considered as an object ( ex : functions, variables, constants, classes of object, etc… )
Encapsulation is a phenomenon by which each object keeps its state private, inside a class. Other objects don’t have direct access to this state. Instead, they can only call a list of public functions — called methods.
Abstraction means that each object only exposes high-level actions and relevant for external object. Abstraction is considered as an extension of encapsulation because it naturally inherits from it
Speaking inheritance, it is a sort of genetic link between objects with similar attributes that are not self-generated but inherit common logics from [ less specific ] objects.
Polymorphism is the propriety of an object class to be employed via the same interface that its parents.
In the management field, Object Oriented Management (OOM) derived from programming aims at obtaining results scoring the “Total Quality” defined as the quality of the results from the client’s point of view. Every aspect of the project is an object. The trick is to define those objects in a relevant way from your project’s perspective.
We tend to define two objects types : Static ones ( cannot self-alter , ex : physical spaces, projects, tasks, etc…) and Dynamic ones ( can alter other objects state, ex : organizations, groups, humans, etc…)
Objects in OOP are usually connected by relations of hierarchy, action upon, dependency, triggers…
The main advantages of such paradigm are the development of a rational strategy and representation of an organisation or a project, a better, healthier approach to conceptualisation of the management itself, a methodology “assorted” to the computational part of your organisation. It is an extremely powerful and reliable framework and offers a great set of mechanisms for conceptual thinking and creativity in management.
hierarchy and inheritance principles
While engaging on Object Oriented concept and its principles, the inheritance principle offers a new way of empowerment across the hierarchy. Indeed, one of the most obvious mechanisms of the organisation’s hierarchy structure is the relocation and delegation of responsibilities and tasks. An inheritance conceptualisation of hierarchy let us operate a fine-tuning of the responsibilities repartition over the team and gives a chance to the organisation to build an optimal and rational empowerment strategy as each node of the hierarchy inherits from the parent one, but also compositely inherits from classes like its particular field of expertise, a team, etc… enriching the objects identity.
the graph representation
Graphs are mathematical structures representing relations between objects and are basically made up of nodes which are connected by edges.
In graph theory, relations can be directed ( edges link nodes asymmetrically ) or undirected ( edges link nodes symmetrically ).
In OOM , we tend to represent the organisation and its object’s set as a tree structure which is an undirected graph where two nodes are connected by exactly one path.
Graph theory is a powerful tool for management heuristics as it offers a wide specter of abstraction methods and logics but also a resourceful ruleset for Object Oriented design in management as it can frame any relation or state of these entities
sets
Sets, in set theory roughly are collections of object. Theoretically any object can be collected in a set and a set can also be considered as an object.
Sets in logical structures are designed to contain objects sharing common properties ( for exemple, classes inheriting from the same parent class ).
Sets can be represented in Euler circles diagrams particularly useful for demonstrating complex hierarchies and overlapping collections. The most useful tools from set theory are its operators :
We define two sets : A and B which respectively contain na and nb objects.
- Union of A and B, denoted A ∪ B is the set of all objects that are a member of A, or B, or both.
- Intersection of A and B, denoted A ∩ B is the set of all objects that are members of both A and B.
- Set difference of A and B, denoted A \ B is is the set of all object of A that are not in B.
- Symmetric difference of A and B, denoted A △ B is the set of all objects that are a member of exactly one of A and B.
- Cartesian product of A and B, denoted A × B, is the set whose members are all possible ordered pairs, (a, b) where a is a member of A and b is a member of B.
Management strategy and design often rely on a naïve or intuitive set conception ( ex : teams, products, customers… ) and can be rationalized and controlled by a reliable approach of the set theory : a tool that proved to be solid and powerful in many fields such as computer sciences.
control, reliability, test and coverage
In software design, tests are conducted to provide the engineering team with informations about the quality and reliability of a feature or a set of features.
The tested proprieties of a system indicate if :
- the system meets its requirements.
- the system responds correctly to all sort of inputs.
- the system performs its duty in time.
- the system is usable.
- the system can function in the proper environment and context
- the system achieves the right results.
There exist different levels of test and controls that let the engineering team explore the most wider range of features, uses and mechanisms to spot the design weak spots :
- Unit testing refers to tests that verify the functionality of a single part of software. In an object-oriented approach, this is usually at the class level.
- Integration testing seeks to verify the interfaces between components against a software design.
- System testing verify that the system in its whole meets its requirements.
In the management pipeline, during the design of a structure, a test framework following this guideline can be implemented concurrently to the core system. Managing teams can adopt a test-driven approach ( which consist of a step by step incremental design process where test and controls are determined before strategy and structure and where these are defined by the tests and controls. )
Versioning
In software programming, version control is a set of systems managing changes to the project. It is a powerful tool useful in the development pipeline. Ones of its heuristics are :
- Branching that consist of managing multiple concurrent versions of the same project. In this way, different versions can be deployed in different environment or different team members can work on encapsulated versions of the same project implementing new features ( for exemple but mainly) without disturbing the others members workspace and avoiding conflicts.
- Change commit protocols that let the team deal with implementations with a defined nomenclature and with a robust history of the project.
- Merging which means incorporating changes made in a specific branch to another with conflicts resolving and detection.
- Promotion means changing the official release from one branch to another.
All these heuristics brought by VCS ( version control systems ) are secure ways to collaborate on and deploy a management strategy and structures. Ideally, each project on each field in a professional environment should be gifted of an appropriate VCS. As each actor gets a proper workspace and material, peer reviewing and collaboration becomes rational and dramatically trivial, release of stable versions of the projects gain controls and the notion itself of stable version becomes true in the most fuzzy projects.
Bonus : PlantUML
PlantUML is an open-source tool allowing users to create UML ( Unified Modeling Language ) diagrams from a plain text language. Various extensions exist to interpret and render PlantUML diagrams from web browsers plugins to text editors extensions.
It lets the user easily create a wide range of diagrams without worrying about elements styles or positions. Different modes are accessibles such as Sequence Diagrams, Use case diagrams, Class diagrams, Activity diagrams, Components… etc ( total : 19 different diagrams types are supported )
Here is a syntax exemple :
@startuml
left to right direction
actor "Developer" as dev
package Computer {
usecase "Write code" as UC1
usecase "Manage server" as UC2
usecase "Go on imgur" as UC3
}
dev --> UC1
dev --> UC2
dev --> UC3
@endumlAnd the result :
The syntax is quite trivial and there is a great project documentation over the web. This is a tool that can be used after a quite short learning period and eases the production of diagrams. A really helpful tool for rational thinking notebooks, team communication and internal doc.
A curated collection of laws to live by
Engineers and developers often talk and rely on a lot of rules and some of these are particularly true and useful in the management field. Here are some of them.
Ockham’s razor
Entities should not be multiplied without necessity.
— William of Ockham
In management, this law is particularly true and we can observe how over-sized teams underperform due to lack of synchronisation means or poor quality members.
Brooks’s Law
Adding human resources to a late software development project makes it later.
— Fred Brooks
We consider that the necessary time to train a new member to act on the project will always be larger than the time it takes to finish it. The team has time consuming teaching tasks and the new member is not enough agile to act on a project that he barely knows.
Gall’s Law
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
— John Gall
This law is a good warning that helped me a lot but it also is the reason of my most unpleasing past failures.
Goodhart’s Law
Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
— Charles Goodhart
That simply means that when a measure becomes a target, it ceases to be a good measure. Metrics incoherences and distorted goals are recurrent management problematics. I would complete this quote by an Albert Einstein’s one :
Some things can be counted but don’t count, other count but cannot be counted.
Hick’s law
Decision time grows logarithmically with the number of options you can choose from.
— William Edmund Hick and Ray Hyman
One should be aware that flexibility can be the most time consuming value. Rationality needs asceticism and asceticism leads to rationalisation.
Hofstadter’s Law
It always takes longer than you expect, even when you take into account Hofstadter’s Law.
— Douglas Hofstadter
A day to day constatation in our work life that too often makes us stress out and develop guilt. Being aware of it makes delays so much healthier.
Hutber’s Law
Improvement means deterioration.
— Patrick Hutber
In other words, complex systems are fragile balances.
Kernighan’s Law
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
— Brian Kernighan
The same applies to system design and strategy. This quote should invite to a real effort in robustness in the conception because weak spots, when released become too hard to strengthen and the next point is a real reinforcement.
Murphy’s Law
Anything that can go wrong will go wrong.
— Edward A. Murphy, Jr
That doesn’t mean that your paranoïa is always true and justified but instead, when probabilistically, a problem can exist, it will exist in an infinite time space.
References
- CriM — Petit bréviaire des idées reçues en management
- Giorgio Argamben — Che cos’è un dispositivo ?
- Jean-Michel Salanskis — le monde du computationnel
- Jacques Chaumier — Les techniques documentaires
- Mikael Krogerus, Roman Tschäppeler — The decision book 50 models for strategic thinking
- Computational Management Science Journal
- Professor William A. R. Weiss — An introduction to set theory
- Dave Kerr — hacker laws
- Rajendra Singh Thapa — Project Development & Management: The Object Oriented Approach
- Graph Theory — Frank Harary
