Work environment and Papuasian tribes: how to solve team conflicts

You can think of open space offices and flame mails, but team conflicts are a little bit older than that: Cain and Abel, you know..? Since that time we learned the lesson: conflicts can destroy a team.

You can think of open space offices and flame mails, but team conflicts are a little bit older than that: Cain and Abel, you know..? Since that time we learned the lesson: conflicts can destroy a team.

At the present time the concept of team is reshaping itself: open space offices are not for everybody (and, if they are not your cup of tea, they can also affect your performance: good insight about this issue in Quiet: The Power of Introverts in a World That Can’t Stop Talking by Susan Cain); tons of emails are not for everybody; almost – digital – only relationships (I am currently working also for people that I have never met in person, did it never happen to you too yet?) are not for everybody as well.

Nevertheless we are still speaking of teams, and a team is supposed to be a group of players forming one side in a competitive game or sport. And business is the most competitive sport on this planet. If you don’t find a way to make out a team from a bunch of people, you are going to lose the match.


A team is a system of relationships and different personal needs.

Without a way to bring together that relationships and needs, the system fall apart: it is the concept of Schismogenesis, ”the generation of opposition” a concept developed by the anthropologist Gregory Bateson in the 1930s while studying the Papua New Guinea Iatmul culture.

Your team and an Iatmul village are a system. There are two different ways to destroy it: the Complementary schismogenesis (dominant-submissive behavioural pattern) and Symmetrical schismogenesis (same behavioural pattern, as in the arms race).

In the passage rite named Naven, Iatmul people create a context in which the usual roles are “played” in the opposite way: male becomes (disguising) female. The key of the Naven rite is to allow men and women to experience – in the context – the emotional lives of each other, achieving a psychological integration.

Finding a way to bring this kind of experience to your team is a good way to keep it not alive, but lively! Programmers and creative designers (but it can be sales and buyers, or sales and logistics, HR and administration…): these are probably the men and women of your “village”.

All of us are under pressure. But finding an opportunity to experience a different pressure, the pressure that “the other guys” are experiencing, is a great way to improve the team manager: we have the tools, we have the culture, we just have to build up the opportunities. Because a lot of what makes the difference between success and failure in teams is a matter of empathy.

Think about it next time you are going to share a pizza with a guy of a different department… Meanwhile, a tool that helps team – working is a good way to keep low the schismogetetic fibrillation level…



Easing work relationships on a project-by-project basis

Twproject is a project management tool, and as such it represents work relationships in form of projects, assignments and roles.

But what it can do better with respect to classical hierarchical and role based modeling is that organizations can be projects – related: the same user can be project manager, worker, stakeholder and tester at the same time on different projects. You can get suggestions in a project you lead, and make suggestions in a project you follow.

And indeed you can set up projects where the manager / execution roles are exactly specular, so that users can compare the two experiences. It is not by chance that Twproject is used as a didactical tool in so many universities.

User and projects can spawn different areas, and you can involve resources from other departments in cross area projects: just in the “Naven” ritual, it’s a matter of point of view!

This contextual role playing can be a way to experiment and understand problems relative to your position in a project in different cases, just like in the rites above.


We have the tools, we have the culture.

Predict the future or improve today

Here is a very short video on predicting the future vs. improving the current situation – which assumes that you know what is happening, who is doing what.

Predict the future or improve today - video

Freakonomics radio

The quoted Freakonomics podcast “The Folly of Prediction” is here.



Teamwork for work managementTeamwork, with its focus on recording work in very different ways and from different sources is a good tool to know what is happening and lead change.






Almost a transcript of the video.

Traditional PM tools are based on the attempt to predict the future in detail. This is really hard.

Listen to this great podcast by the Freakonomics economists that studied predictions, “What do Wall Street forecasters and Romanian witches have in common? They usually get away, scot-free, with making bad predictions.”

The increased flexibility of work, people, changing conditions, even more in times of crisis. Being capable of reform, changing ideas in companies can be a great strength.

Base your reform on what is happening every day instead of what could, maybe, maybe not, happen.

Trying a more modest approach of understanding what is happening today, every day, can facilitate reforms.

Teamwork is built around the idea of collecting information, even partial information, of what is happening day by day. The app has great flexibility in handling projects, work logging in the most diverse forms

If you want your ideas of change reform and efficiency – hence also increasing quality of work – knowing what is happening can be a great help.

Used in thousands of medium and large companies to know what is happening – give Teamwork a try.

How do I begin project management?

Project management tools - software

In “Making things happen”, the author (Scott Berkun) states that he assumes that the reader is not stupid, is curious and pragmatic, does not like jargon or big theories, and does not take herself, software, or management too seriously. Well, we do the same in Teamwork.

Still, you may have no or little experience in managing team work. Whatever work you will be doing, you may have some requirements, and some dates. if your company has no notion of project / task / issues, you can start this way: list all the things you are doing in your organization. You could separate internal work / external work. In the list obtained, group dependant activities: each group can be called a project, and the people that should work on it are the assignees.

You may notice that when you are listing “thing that we are doing”, you may also include “things we should be doing”. Notice which of these are stated in the form of concrete actions, like “call X”, or “write Y”, and which are still to be transformed in actions. You should try to transform everything into actions, and get rid of the rest. And still among actions there are simple, brief ones, and others that group many others: you could model the simple ones as issues, and the ones comprising others as tasks (that is, projects which are child of other projects). This is a start of management.

Often we get asked by people evaluating Teamwork:

How do companies really use Teamwork?

In the new user guide you will now find several examples. Here are also some good books where to start learning about personal and project management.

Some reference books:

This book by Berkun is our main reference:

Making Things Happen
Mastering Project Management

By Scott Berkun, publisher  O’Reilly Media, 2008

From a personal productivity perspective:

Getting things done

By David Allen

On the Agile/Scrum theme:

Agile Project Management with Scrum

By Ken Schwaber