grad doc

[gradoc]

Conclusion

Due to the lack of time, and the need to start work on the second part of the project, i wasn’t able to create the final outputs of the collaboration toolkit. However I have started work on writing the Greenhouse Collaboration Manual, and the condensed ready reckoner. But the learnings from this are to be used in the next part of the project, and the collaboration project outputs will continue to be worked on to completion.

[gradoc]

Condensed Ready Reckoner

For those who have already been through the guided workshop or read the guide, this ready reckoner will be very useful for them to brush up on, or have as a guide to refer when needed. It’s the distilled condensed version, with only the hard facts written on them. Compiled in an easy to to carry form of printed cards and digital images, this will allow collaborators to ensure that they have followed up on the good practices that they wish to follow that have been listed and explained in the book. 

[gradoc]

Collaboration Manual

This is the one direction in which we were very interested in taking forward is to explore a format which could replace traditional toolkits. We had initially planned for this to be a book of case studies, suggested exercises, and interviews with experts. But almost immediately there was a flaw with this plan. It’s fair to say that I’m not an expert on collaboration, so for me to write this guide from a supposed position of authority would completely devalue the end result. It would be a dishonest approach and I simply wouldn’t have the content.

But perhaps there is some value in me editing and writing the content. All of my data and research has been gleaned from credible sources and experts in the field of collaboration. If I did write the guide to good practices of collaborations, it would be very interesting and insightful if I wrote it from my inexperienced perspective. Having been involved in many collaborative projects in design school, now working in a collaborative studio, and now having studied the finer details of collaboration, I would have a distinct take on specifics of collaboration. 

This further sparked a conversation of lived versus read experiences. Was there any point in me writing about collaboration if its simply better for the readers to learn by making the mistakes that the guide warns them about. After all, it’s only after you touch a hot vessel do you actually learn not to touch hot vessels, inspire of your parents repeatedly telling you not to do so. Without question, lived experiences are immensely more valuable as compared to just having read about them. But perhaps, in this context of collaboration, the guide can augment your experience of collaborating with others. There is no guarantee of the content being 100% correct as collaboration is a subjective phenomenon that varies from individual to individual. 

This guide, tentatively titled The Greenhouse Collaboration Manual, will have essays, illustrations, interview transcripts, academic research and activities to help the reader understand the grammar of collaboration. The objective is not to preach to the reader a definitive process of collaboration, but to explain the various factors and parameters that affect the grammar of collaboration. The aim is to give the readers and understanding of how a collaboration works, so that they can craft their own approach to collaborations.

[gradoc]

Workshop Guided Toolkit

The traditional toolkit still does have its place, and is most effective when used in a guided workshop setting. Toolkits contain tools which are activities and exercises which are always more useful when performed under supervision of a subject expert. This method of dissemination is ideal for an audience that has to be introduced to good collaborative practices. The operative word here being, ‘has to’. It’s not to say that all those who use toolkits are not participating non-volountarily. But a guided experience through a topic is preferable for those who aren’t doing it of their own accord. 

The tools that we short listed in the hack method can be used here to construct a toolkit.

[gradoc]

The new ‘toolkit’

The target audience for the collaboration toolkit are young people, or organisations looking to collaborate. They are relatively inexperienced with collaboration, and are looking for something to give them a heads up on what to expect, and what to be aware of. Based on my interviewers with young freelancers and artists who will be heavily collaborating in the future, they aren’t afraid of collaborating, but would definitely want to learn about the nitty gritties of the grammar of collaboration so that they know how to deal with unexpected situations. But not everyone has the same demands from the toolkit either. 

The target audience can broadly be divided into three categories.

The ones that have been asked to refer to the toolkit (non-volountarily). This is a situation where a guided workshop with a traditional toolkit would be the most effective. Traditional toolkits work best when used in a workshop setting, and facilitated by an expert. 

The ones that want to use the toolkit of their own accord (voluntarily). This is meant for those who want to understand the process of collaboration, see case studies and interviews for a deep dive. In this situation, a helpful guide, with stories, essays, interview transcripts, and illustrations would be ideal as it allows the user to explore the grammar of collaboration. 

The ones that have already been through the toolkit (follow up). For those who have already been through the guided workshop or read the guide, this would be a useful follow up, a ready reckoner with the core data and research condensed in a concise form. 

[gradoc]

New Method

Both the studio and I were in agreement about toolkits not being the ideal solution in this situation. But what other solution could we pursue to disseminate information and scale impact? One critical issue with traditional method toolkits is that they are designed around the information rather than the intended recipient of the information. Hence users often find toolkits out of context in their use case.

As I pondered over this situation, Avinash left a book on my desk. This book attempted to educate its readers on how to become entrepreneurs with the help of their craft skills. Although it wasn’t a toolkit, the book employed case studies, condensed information into a few simple sentences, and recommended simple exercises for the readers to follow along. It was a refreshingly simple take on the dissemination of knowledge, and it did so in a way that empathises with the target audience. The people who will buy that book are the ones who are skilled in what they do, but are nervous or afraid of starting a business. The tone of the language used is designed to allay the fears of the readers, and gently encourage them into becoming entrepreneurs. The narrative breaks down the process of entrepreneurship, and presents each part of the process in smaller, easy to understand parts. It was not only a joy to read, but immensely resourceful as well. 

I discussed this idea with the studio, and we agreed that this was a good direction to follow. A new take on toolkits would be an interesting project in itself, so it was definitely worth seeing where this would lead. In further discussions with Neha, she showed me handbooks and guides written by Laurie Baker, a well known architect. The books he composed were meant for even the most technically illiterate, and so they were designed with simple sketches, rudimentary english, and clear step by step directions. Reading these books further reinforced the fact the concept of designing dissemination methods according to your target audience. 

[gradoc]

Interview Insights

From the first set of interviews, conducted I found many overlapping insights. Most of them felt clear communication was a key ingredient to good collaboration. Problems only arise due to miscommunication and lack of clear articulation when talking to each other. They also felt that not taking feedback to heart is important when in a collaboration. There is a tendency of many to let professional feedback affect them personally, when it is never the intention to do so.

Having a common goal or vision is needed to keep the team working together and pulling in the same direction. They might be some conflicts along the journey, but that friction is important to continuously re-align the group and course correct when needed. In smaller groups, team members will also have to wear different caps in a collaboration. Members must play different roles in a collaboration, to ensure smooth running.

No matter what role you play in a collaboration, you must be as invested in its future as anyone else is. Only then will you be able to give your 100% to the cause. In many ways, a collaboration is very similar to a relationship or a marriage. The personal relationships between people are just as important as the professional ones. So you must learn how to work with different people. Above all, try to understand that everyone is also trying to figure it out, just as you are.

Collaborations can broadly be divided into two divisions — organic and planned. Sometimes, collaborations simply come together, and happen so naturally that no one thinks of structuring it or giving it any form of formal hierarchy. The other is when collaborations are carefully mediated and structured. Although when collaborations come about organically, a structure also naturally falls into place sometimes. If it doesn't, then it is important to have one, as it ensures accountability and thus, productivity.

[gradoc]

Toolkit Crisis 2

My mistrust of toolkits started long before the project started. I would never use a toolkit unless I was mandated to, or in a workshop setting. The list of things I detest in toolkits is long, so I’ll focus on the big ones.

The sheer inaccessibility of toolkits is the most frustrating. The language, the way the tools are structured and the tone of the content makes it seem cold, aloof, and almost academic. Then the lack of context is borderline criminal. Sure, it broadly works in a few situations, but there will always be exceptions and special cases.

The merit of any toolkit is judged on how often is it used. If no one feels like using the tools then it has failed, no matter how technically resolved it may be. There is a caveat to add here: toolkits are always aimed at a very particular target audience, people who are in specific position at a specific time, doing a specific activity.

I could be completely wrong about this, and statistics will probably prove so, there being enough numbers to prove the success of toolkits. But for me, personally, they simply don’t work and there are better ways of disseminating information. It’s also important to recognise that the method of dissemination should entirely depend on the target user, and not on the nature of the knowledge itself. Of course, in an ideal world every specific problem would have its own bespoke solution, but since that not going to happen anytime soon, we have to do the best we can with general solutions.

In my poorly informed, highly inexperienced opinion, I feel that toolkits shouldn’t teach a fisherman how to fish, because unless you cover every single type of fishing technique, it’s not going to be a very helpful guide to those who aren’t in the same situation as described in the toolkit. What they should do is, to teach the principles and concepts of fishing. So that you can learn and develop your own unique fishing technique. So, teach a fisherman to teach himself how to fish. Everyone is creative in their own way, and will figure out solutions to their own particular problems when taught the basic principles and concepts.

It’s a lot like mathematics. Once you learn the basic formulas, and learn how to derive them, you can then apply it to any problem. Another lesson I learnt from mathematics is that you have to understand the problem very well. Once you understand what the situation needs and requires, you can then use the necessary formula. Of course, real life is nothing like mathematics, there exist many complexities that no toolkit can handle.

I really like reading case studies. Harvard Business Review is a magazine that is full of them and I devour it the moment I can get my hands on a copy. On the face of it, case studies are just another layer of abstraction between the reader and the information. But that layer of abstraction gives the information context and tells the reader how it was relevant in that context. So one can separate the context from the story with the additional understanding of knowing how it was used in that setting, hence giving a better understanding of the information. So I tend to understand concepts a whole lot better when presented to me in case studies. The power of narratives to explain a concept should never be underestimated.

The other alternative is that we look at the other end of the spectrum by making a checklist of sorts, which the user can use as reference to get through the process. This would leave the entire process in the creative control of the said user, and would merely direct them in a particular order of things to do. This is suitable for a limited number of tasks/processes and would compromise on the quality of the process.

At the other extreme, is to individually train people for the task that they’re trying to tackle and give them the knowledge and the ability to execute that know-how. This, of course is highly resource intensive but will guarantee results. Also, highly inefficient when trying to disseminate knowledge to scale up impact. The ideal solution lies somewhere at some multi-cross-section of these methods, and will change according to the broader context.

A toolkit is not the best way to scale impact, and there are better, more customised solutions available. Toolkits have become a buzzword, and are designed around the information rather than the intended recipient of the information. Users cannot connect with it if its not contextually applicable.

So what is the solution to this conundrum?

[insert quotes from QS articles on toolkits]

[gradoc]

Primary Research

Now that we had collected enough secondary research, and decided upon a content driven narrative direction, it was time to go out and get some data from people who collaborate day in-day out. Collaboration is different for different people in different professions. Because of the varied demands of different professions, even the grammar of collaboration differs. To try and get as many diverse opinions on collaboration as possible, we drew out a list of people to interview, from various disciplines/professions. Many of these people were located in Delhi, so I worked at the Quicksand studio in Delhi for a month, leveraging various contacts to get interviews. 

I interviewed ~20 people on their collaboration process, and although there were many overlaps with the secondary research, I found some very interesting nuggets of information which I could only have found from people who have had rich experiences of collaborating with others. 

Listed below are the people who I interviewed. 

From educators, to freelancers and all the way to racing drivers, the breadth of insight I gleaned was immensely resourceful. It was very interesting to see how each profession had their own take on collaboration. 

[insights from interviews][snippets]

[gradoc]

Toolkit Crisis 1

The word toolkit carries with it many connotations, both negative, and positive. Although toolkits are useful, and can be used to great effect, there are a few drawbacks. The vast majority of toolkits available are worded in language thats difficult to read, and this makes accessing the content of a toolkit difficult and intimidating. I personally feel that most toolkits employ a very sterile and cold tone, which detracts me from wanting to use them. The sentiment was shared by the partners of the studio, and we wanted to change that in our toolkit. The aim is to make the toolkit as approachable and accessible as possible. The first step in this process was to remove the word ‘toolkit’ from the title entirely. Instead, the word ‘manual’, or ‘handbook’ made more sense, and made it seem more approachable. It also made sense to include tips, and case studies alongside the activities and exercises to create a more rounded end product. 

[gradoc]

Process One Narrative

Fixing on a narrative was a difficult process, and in hindsight, probably a futile exercise. I looked at multiple ways to break down the process of collaboration, trying to find a one size fits all solution which would still be specific enough to give direction to the users. 

From the tried and tested, but basic Why-What-Whom-How, to breaking down the process to a very general Start-Framework-Follow, we tried to make find a valid narrative. We finally settled on using a narrative using the breakdown of a collaborative work process, similar to the one followed at the Greenhouse. 

Inception: The coming together of the partners to for a common goal to  collaborate on.

Brief Development: Forming a brief to work on, planning out the work needed.

Fund Raising: Figure out the financials for the project, and raising funds if needed via proposals, grants, tenders.

Research: The research phase, collecting data and information required.

Co-Creation: Working together collaboratively on the project.

Output/Documentation: Compiling and designing the documentation of the project to share.

Research Management: A guide on how to manage resources/spending between partners.

This narrative can apply to both a standalone project, or a long term collaboration. However, once we started figuring out the content to fit the narrative we realised that fixing on a narrative initially meant that some key research that we had couldn’t be included. That’s when we decided that perhaps this wasn’t the best way to tackle this.

Going back to basics, to the mantra of a good toolkit is all about asking the right questions, we decided to forego a narrative and concentrate on asking and answering the correct questions which would then form a narrative. 

[gradoc]

Process One Hack Method

A quick and dirty prototyping method to is to put together existing tools to create toolkit. The easiest way to do this is to print out tools available on the market, segregate the tools by what they do, and choose the ones that seem most relevant to the needs of your toolkit. It’s not an uncommon method to do so. Most toolkits available use very similar tools, sometimes re-contextualised to suit their users needs. 

As we started picking out the tools that could potentially be useful for the collaboration toolkit, we also understood how toolkits are structured and the gaps within the structure and narrative that would need to be filled. We followed the initial task based narrative that was decided earlier, and grouped the selected tools within those categories. 

[gradoc]

Process One Toolkit Questions

2Simply researching the best practices for collaboration and slotting it in a toolkit wouldn’t work. I was struggling to fix upon the brief, the need for the toolkit. The point being, if there is no demand, or no place for the toolkit, then it is a hollow exercise. The toolkit has to be used by someone, and for that it has to be useful for that certain someone. Right now, its not clear who the toolkit is meant for. Drawing on our thoughts of previous toolkits, we know that the traditional toolkit format is cold, and not very approachable. I wouldn’t use a toolkit myself. I would take inspiration for the format and framework, but toolkits have never appealed to me as an actual, useable tool. This attribute of traditional toolkits has to be remedied in the one I make. The toolkit has to have a narrative, which defines the content. The initial narrative:

Inception

Brief Development

Fund Raising

Research

Co-Creation

Output/Documentation

Resource Management

This narrative needs to be re-contextualised and fixed according to the new brief that I have to form for the toolkit. The problem with the initial plan of the toolkit is that it’s not aimed at anyone specific enough for it to be marketable or viable. For starters, we can re-contextualise it by saying its meant for India exclusively and that it’s meant for creative creators, and innovators who wish to create change in their communities by producing hyperlocal work. It’s possibly also meant for smaller organisations, or startups who might want to collaborate with others to reduce their going alone costs. India used to, and currently does have a lot of co-operative organisations, like banks, and housing societies, with Amul being a good example of that culture. 

After a series of long discussions, we finally settled on a brief that we felt was appropriate to the project. We had initially played around with the idea of pitching the toolkit for creative professionals who wished to help the community, but it was aimed at a very specific audience which would have severely limited it’s appeal. The reason why we had even considered that possibility was because that was because that is what the partners of the Greenhouse wish to do. Although that is whom the project is meant for, the partners wished to widen its appeal and make it applicable for a larger audience. We opted to position the toolkit to young people who wish to set up collaborative practices of their own. We chose to target young people because they would be the ones who most need advice and help on starting a collaborative practice. 

[gradoc]

Process One Research Collaboration

As I scoured the internet for good collaborative practices and collated them, I also started work on understand how toolkits work. I have never before designed a toolkit before, so this was a new area of research for me. By first understanding how toolkits work, I could then plug in my learnings from the collaborative practices to the requirements of the toolkit. 

Toolkits are exactly what it says on the tin. A kit of tools, designed to help the user with the task at hand. A method toolkit is a collection of exercises and activities designed to propagate knowledge and scale impact of the same. Research and experiments conducted in one place are usually packaged into a toolkit in an attempt to replicate impact at scale. 

The Collective Action Toolkit, by Frog Design for example, breaks down the process of collaborating and creating solutions for issues affecting a community. The steps are explained with the help of suggested activities, diagrams, and workshop structures. 

Similarly, the Business Action Toolkit by Nesta helps entrepreneurs get their startups running by advising them on creating a business model.

This toolkit created by Nicholas Felton, provides users easy to refer to cards to help them visualise data with Processing. 

Toolkits are very good at breaking down an activity, or a problem into multiple steps that are easier to comprehend and tackle. By making a seemingly difficult process easy to understand and simplify the course of action required. Once the process becomes easier to follow, users are more likely to follow through, and be successful in their task.

[gradoc]

Process One Research

What is collaboration? The action of working with someone to produce something. We, as humans are very familiar with the act of collaboration. We’ve been collaborating with each other, in one way or the other, since the inception of our species. It’s becoming increasingly rare to see any sort of activity in isolation. Collaboration is the primary building block of civilisation, and arguably it might be one of the attributes that made us the dominant species of planet Earth. Collaborating with our fellow humans is what enabled us to evolve. It’s an ever-present undertone of our society, a given in any venture. The act of collaborating is not only normalised, but expected from any activity we partake in. The statistics back up this statement up as well. In the 1980’s, only 20% of the work was collaborative. In 2010, that number had gone up to 80%. The wave of collaboration has since grown into a tsunami, not only embraced by smaller businesses, but by larger corporate setups as well. It’s not only collaboration within organisations, but also across disciplines that go a long way to validate why they make so much sense.

During my time at NID, I’ve been heavily involved in collaborations, for both academic and co-curricular activities, and during this time I had never paid attention to the very act of collaborating. The grammar of a collaboration directly influences the outcome of the collaboration. If this process were to be deconstructed and looked at, the learnings and insights would lead to a more productive collaboration. For this project, we decided to combine secondary research, along with activities, and workshops in the studio to form our opinions on the best practices for collaboration. By applying what we learn from secondary research into workshops and experiments within the studio, we would obtain good data on whether certain practices work or not. 

[gradoc]

Process One MAP

Research

Secondary Research

Studio Observations

Studio Events

Toolkits tools

How do toolkits work?

Narrative

What Why How When

Studio Activities

Output

Content for each chapter

Final form

[gradoc]

Greenhouse Structure

The Greenhouse is an experimental collaborative venture between three partners, Quicksand, The Busride, and Tandem Research. Each of the partners has chosen to bring over some part of their practice from their main studios in Delhi/Mumbai/Bangalore.

Below is a map of the partners and the parts of their practices they bring to Goa.

[map]