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 in account.

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.

In Space

Space, or environment, or external impacting factors, are bringing some constraints:

Deadlines

• 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.

Dependencies

• 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.

Conformity

• 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 transparency.

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 if possible.

Physicality

• 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.

Virtuality

• 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.