How to work together: Difference between revisions

From Hackers & Designers
 
(One intermediate revision by the same user not shown)
Line 46: Line 46:




Thanks for advice Andre Castro
Thanks for advice [[André Castro]]

Latest revision as of 19:34, 9 January 2020

About working in interdisciplinary teams by Anja Groten

In your hands you are holding a collaboratively made publication. The content of this collaboratively created publication is also made collaboratively, mostly during the H&D Summer Academy 2015. As the organizers of the H&D Summer Academy we decided to implement collaboration as the striving mode of production during the program to stimulate different disciplines to engage with each other and to create a breeding ground for cross-disciplinary discourse. Thus it seemed natural to approach the documentation in a collaborative manner as well. Ultimately the nature of those two collaborative processes seem to differ. The content of the publication was produced during 1 or 2-day workshops, in groups, which were assembled differently every day, in a total time period of 10 days. The publication itself was made afterwards, collaboratively as well, but during a longer period of time, without a strict end date, and with a more or less fixed group of collaborators.

I would like to reference a book, written and designed during a book spring at Transmediale in 2010. The book is about Collaborative Futures. The co-writers distinct between two different motives of collaboration. One is "the internal motive: curiosity, hunger for knowledge, the pleasure of participation or of belonging to something bigger than themselves.“ On the other hand there are „stimuli provided by the outside world: money, prestige, the promise of reward or the threat of punishment." As one of the collaborators of this publication I would, without hesitation, subscribe to the first motive. However the outside stimuli seem to inevitably sneak into the process if you are not situated in the 'save environment' of a cohesive summer academy program. Nevertheless we succeeded in creating a publication that is informed by technology as well as design thinking.

Since a documentation of the intense Summer Academy program was imminent we decided to use the chance and research new means of documenting and publishing and challenge the role technology can play in that. The question of new forms of documentation already arose during the Summer Academy itself. During the workshops people experimented with git repositories and EtherPad for collective note taking and local networks created with Raspberry pi’s to share and exchange files. After the Summer Academy the ambition was to create an on and offline publishing infrastructure, optimally using open source software, and using this moment to challenge all before experienced editorial workflows and hopefully have an infrastructure for co-documenting ready by the time the next Summer Academy starts.

A number of steps to consider along the way of co-creating and publishing documentation material:

1. Critical consideration of the medium: What is the main goal of your documentation? Do you want to archive for the sake of evidence and completeness or do you rather want to create a reflected editorial work? In our case we decided we would like to do both. The Wiki serves as the complete archive. Having gathered a variety of media, such as videos, sound files, images, short texts and bits of code as well as longer reads like transcriptions of lectures, we decided we would like to show content both online and offline. (See also the article: How to document a summer academy)

2. A red threat: Coming up with a topic, ethos, concept, thematic agreement, or whatever you want to call a red threat, helps to tie the collaborative content production together. None of us is a professional writer. Therefore we decided to write most texts in the style of DIY manuals. That style didn’t have to be taken literally but served as a common intention in order to navigate and order the diverse content produced.

3. Create a collective baseline: What are the challenges and interests this investigation has to offer? What is everyone's individual interest in creating this documentation? What does the process have to offer and how could all interests together be formulated into one common goal? We haven’t defined that baseline at the beginning of the process. Looking back it could have helped formulating a clearer action plan as a group and kick-off the process properly.

4. Create a workflow based on the baseline: Who are all collaborators involved? How much can everyone invest? Who is going to work on what? What is the time frame? What are in-between deadlines? Based on how much time everyone can spend, the deadlines and a detailed process plan can be formulated down to what needs to be accomplished every week.

5. Acknowledging and complimenting each other's contributions to the process seems like an obvious step but is often forgotten during collaborative non-hierarchical processes.

Glossary of potentials for friction during collaborative processes:

Time-planning: Projects like this are often done with no or low budgets. Accordingly they tend to be postponed. It can lead to frustrations that collaborators have different priorities at different times, and have different external stress factors to deal with. In order to proceed with the project decisions sometimes have to be made even if not everyone is present. That can cause misunderstandings and eventually a delay.

Cross-disciplinary vocabulary: The different languages everyone is speaking (international as well as interdisciplinary vocabulary) shouldn’t be under estimated.

Modes of production: Following up on the topic of interdisciplinary vocabulary, productivity is not necessarily considered productive in all disciplines. Marshall McLuhan said: "As new technologies come into play, people become less and less convinced of the importance of self expression." We experienced a highly practical definition of productivity versus a more discursive, conceptual definition of productivity. Some collaborators considered "talking" as frustrating whereas others considered immediate "making" such as programming or designing as overhasty as the concept 'wasn’t straight yet'.

Collaboration does not equal teamwork: There are different forms of working together. Some believe collaboration means that every part of the process needs to be shared. Others consider the idea of constant sharing of the process and working only in the presence of the others as inefficient. Not everyone can necessarily apply to the same working conditions. Leaving enough space for individual thinkers without isolating them and at the same time creating the space for collective thinkers is the challenge here.

End notes

I added the glossary of potential friction as an attempt to give a complete and realistic image of our process and to acknowledge these frictions. Instead of trying to overcome frictions and stop them from interrupting the process I would like to promote the idea of accepting and even embracing these unavoidable frictions and recognize their importance for cross-disciplinary and collective learning achievements. Accepting different ways of thinking and embracing opposing ideas and ways of working can be very inspiring and productive and carried on into future collaborations.


Resources


Thanks for advice André Castro