In my previous post, I described the elements necessary for fostering
collective intelligence in Open Source projects. That synthetic
description was very absolute, and for a proper implementation it needs
some adjustment regarding both space and time.
The space variable is environmental, where the project takes in
account its surrounding. Partnerships, dependencies, markets, and customers
are some of the impacting external factors that need to be taken
The time parameter involves considering the intermediary steps leading to
the birth of a project, the seeding, the evolutions, the mutability and
transmission procedures between actors, and the death of the project.
Where space is all about environment, time is all about evolution.
By addressing both those factors, I think we are much closer to a blueprint
that would make sense to the adoption of Collective Intelligence in Enterprise.
Space, or environment, or external impacting factors, are bringing some constraints:
- events taking place at given dates,
- synchronization with other projects,
- unexpected hazards like security alerts,
- partnership contractual obligation,
- legal obligations from local state,
Instinctively one could think that deadline are a time parameter, but actually
their impact is more environmental than evolutionary. Setting hard time constraint
has for only purpose synchronization with external factor: customers communication,
market events or strong trends, predictability in the case of fixed deadlines. All
those factors are geared toward collaboration.
Deadlines impact the emerging whole, in the sense that an organized group cannot rely
on unpredictable emergence, and requires some enforcement mechanism to comply with deadlines.
It leads to the necessity to setup a steering system, that will watch over deadlines and
adjust the whole for timely emergence. This can be done in a very soft way, by nudging
more than hardcore enforcement. But there are many situations where it’s obvious that
arbitrary decisions have to be made for the sake of meeting deadlines.
Many Open Source projects have very small concern for deadlines, because they reduce their
environmental surface area. But large Open Source projects can’t escape this. For example
it’s very convenient for large projects to make a contract with user about the release
cycle periodicity. Gitlab releases every month, there is a new Ubuntu release every 6 months,
and yes, both those projects are lead by companies.
The ways to address this constraint requires an extra attention to the holopticism.
Each participant needs to be totally aware of deadlines so they can adjust their own pace.
Certain deadlines involve specific tasks, like releases for example, which can be subject to
a rotation for better resiliency, in the spirit of switchable roles.
The example of how Gitlab manages releases illustrates this concept pretty well.
Often there is going to be the need to identify certain roles for deadline enforcement
in the case of events. Depending the scale, it can be clever to create
specialized sub-collectives. Like the “2017 rubyconf team” or the “first tuesday meetup team”.
But it also can be a switchable role in case of small requirements for the task.
For an optimal and fluid operation, those roles and constraints need to be clear in the
rules of the game and possibly in the arbitration mechanism too. Sometimes failing
on a deadline can be very harmful for the project and the collective, and the collective
then need some aggressive process to protect its survival.
It’s especially true for security alerts, in case of software development projects or
projects managing infrastructures, which require a strongly steered crisis management
with very tight deadlines.
- with vendors
- with customers
- with contractors
- with specialized third parties (press, social media, integrators)
We saw that specialized sub-collectives can be required to handle deadlines.
The same goes for dependencies with other projects or vendors, or even customers. The
Collectively Intelligent organization usually needs to provide some dedicated contact role
which can be either a person or a group. Such a group or person will then be in charge
to inform the rest of the organization about their own deadlines and other requirements.
Those sub-collectives are in charge of doing a proxy-triage work in the communication between
the collective and the rest of the world. For example the Support team can handle user requests,
communication team the press releases and press events, the community team would handle events, etc.
The responsibility on such teams is both internal and external. They need to make sure that
the collective knows about external inputs, and the external actors know about the internal activity
that may impact them.
- legal requirements
- standards compliance
- intellectual property liability
- contractual liability with partners or vendors
There can be a wide range of conformity requirement that a project can’t ignore. It may be hard
to predict them all, but a general approach could be taken about them. Such requirements can
be very disruptive in the engineering of internal collective intelligence, in some occasions.
It’s even worse when conformity requires some form of secrecy, which tampers the need for
For open conformity requirements, they need to be made public, at least in the circle of
the project, by the way of the rules of the game. It may be necessary to appoint a
specialized sub-collective for enforcing certain type of conformity, like for example
a legal team, or a special quality assurance team that will make sure contractual
requirements are met. Some conformity rules may involve some special skill or certifications.
But as a general rule, the impact surface of conformity compliance should be kept at its minimum
- office conventions
- resources management
- expenses coverage
- toolset and procedures
When a physical space is involved, some chores have to be organized for its maintenance.
They can be shared by some sort of common greed convention, or handled by a dedicated group.
There is not much challenge about this, as it calls for practices that are very well documented.
When it comes to tools and procedures, it’s about making the space adequate for collaboration.
Open space stimulates transparency, for example, and direct and quick access to others.
There is a trend currently that frowns upon open spaces in the workplace, because it’s
disturbing concentration and breaks the ‘zone’ state that developers can try to maintain.
But in my opinion shared physical spaces should only be used for interactive activities.
If one needs concentration, they should isolate themselves, either at home or in a closed space.
The consequence of such a statement is that remote activity should be possible, depending the
kind of activity of each member of the collective. Some will need more isolation than others.
- online sync and async tools
- knowledge database and shared memory
- remote presence tools
- structured and transparent tasks tracking
Taking in account that economy cannot be made of a virtual activity except in rare cases,
a proper thinking has to be made about the tools deployed to serve such purpose. Details
will obvisouly depend the craft of the trade at hand, but there are some constant.
A common space for synchroneous communication is required, for all participant to access
each others in a fluid and interactive way. If this interaction can be seen by all others,
it’s even better. Transparencey by default is a factor of success. Nowadays solutions like
IRC, Campfire, Hipchat, Slack, Rocketchat, satisfy the requirement for such a platform.
The common sync space needs to be archived and its content needs to be searchable. This ensures
that async knowledge can be guaranteed.