Dropbox Paper: how to stay alert
- Transfer
How can I and my team be on the drive all the time?
If you have ever worked in a small team with limited resources, you are most likely familiar with this drive experience. Some kind of itch that makes you move forward when something struggles backwards with all its might. The unusually strong tide of motivation that you feel when they tell you that you are not good enough.
Again and again, I noticed what miracles are starting to happen when you come across this sensation of drive. But how to keep this spirit of drive, if the team becomes more and more?
A few months ago, I joined the Dropbox Paper team. By that time, the team had already grown to fairly large sizes. I still remember my first meeting with the team and the thought that we might have enough to fill an entire cinema. (I think I already dreamed of outdoor meetings).
Today, I have been working here for several months now, and I noticed something: even when our team grows, we somehow manage to keep this spirit of drive inherent in small teams. I don’t know if this happens by chance or according to plan, but I have several theories about how we stay on the drive.
The translation was made with the support of the EDISON Software company, which is professionally engaged in web development and recently redesigned its website .
The other day I talked with Kavita Radhakrishnan, our management team of products, and she said what shocked me:
The list of requirements is great to get acquainted with the goals and scope of the project. But as soon as you begin to put your plans into action, things rarely go as planned. At this point, progress becomes a priority. Documentation becomes a secondary issue.
I would say that 25% of the real work on the project occurs after the developer transfers it. That's when experts begin to test your projects for strength, and they will definitely present new requirements and advanced examples that you could not even think about. At this point, you need to feel the drive and do everything possible to achieve progress.
At Dropbox Paper, we learned how to deal with the blows of fate and accept the fact that plans will change - no matter how well designed your requirements are.
As a company grows, people who create a product tend to move farther and farther from those who use it. Familiar with the developer or production manager who work in a large company? Ask them how often they talk to their everyday consumer. I bet you will be surprised at what you hear.
In the Dropbox Paper team, we try not to build “ivory towers” that distance us from our audience. Instead, we do things on the drive to meet people who use Paper.
For example, the project “Environments of the Real World”, which was launched by Mira Rao, one of our researchers. Every Wednesday we invite people to come to our office to tell them about what we are working on. It looks like a quick date session: a participant talks with several people from our team, with each person individually. And the most cool thing about this is that it is often developers, specialists and production managers who communicate with them from our side, and not researchers. Such meetings have taught us to talk with consumers on a regular basis.
In addition, we arrange widespread meetings with teams that use Paper. We are interested in how people use Paper in a real situation, and we are ready to go to their office, if possible. Any of our team can join such trips - developers, authors, experts, anyone. Each meeting is a chance to be inspired by something and learn something new about our audience.
Several Paper researchers talk with a team at Airtasker
Many information technology companies have “hacking weeks” during which you can work on any project you want for the whole week. Paper also hosts hacking weeks, but other than that, it also has a “Hour of Hacking.”
Every few weeks, Friday afternoons, we all gather together, take drinks and work on everything we want. We can spend a whole hour on this or spend the rest of the day doing it.
Believe it or not, many of the features that Paper users really like today were created during these meetings. Have you ever used presentation mode? Coined during the hour of hacking. Names for Emoji? The same story.
Paper would not be what it is today if it were not for these sessions of hacking. If you give people time and space for improvisation, they will come up with surprisingly inventive ideas.
Leandro Castillo and Sheila Ramaswami during the Hacking Hour
In the Paper team, people often play different roles in different projects. I saw how production managers conducted research on the usability of the product. Seen how researchers do design work. Each of us has a specified role, but we also have the opportunity to try on different masks.
In large companies, it is easy to retreat and say: “Sorry, this is not my job,” because in large companies, everyone has a rigid role assigned to him. There you will not find just a "developer". There is an interactive designer, visual designer, motion designer, system designer, etc.
Our job title does not define a person. We just do everything we can to get everything done. I write articles, but from time to time I do design. Neil Seti and Caroline Frost are production managers, but I saw them write code and create amazing things.
It is very embarrassing to see how everyone around you becomes energetic, just to help each other.
For some reason, our team loves to like each other. Seriously, I have at least two appointments every week where we meet, just to express admiration and thank other people in the team.
We also created anonymous forms so that people are less shy about expressing love and it was not so ... awkward.
At first glance, the expression of admiration may seem a silly tradition, but I noticed how it brings good fruit one after another. Person A publicly expresses admiration for Person B, and then person B feels good and “gives five” to person B. You will not have time to notice how more and more people will take part in this.
Everyone wants to feel appreciated, and simple gratitude helps people very much to feel meaningful, energetic and to feel the team spirit. Not only big projects matter. Celebrate and small driving victories.
The Paper team loves to experiment. Constantly on the agenda are dozens of experiments with features that we can run to learn them in practice from the inside. We have experiments related to various mockup projects, experiments related to different versions of a copy of the user interface, experiments on just about anything.
For example, here is an internal experiment created by Aisha Ferrazares and Harold Chek, where we show a warning if you try to send a notification to everyone in the document:
We will not run it as it is now, but a demonstration of this helps to understand whether it is useful or not.
We try to make it as easy as possible to conduct experiments in our team, because we want to make it easy to check which one is good and which one needs to be improved.
We also experimented with different ways of working. Now we are trying a way called "hakai-and-run." It lies in the fact that a small group focuses on one project for the whole 6 weeks. They can skip all meetings and other responsibilities to focus only on this project. It looks like a driving startup in a larger team.
So that's it. I am not a production psychologist, so take this article with a pinch of distrust. But, judging from my experience, the above things make our team feel at the drive and happy.
If your team is growing and is looking for ways to stay the same drive, I hope these tips will help you with this.
If you have ever worked in a small team with limited resources, you are most likely familiar with this drive experience. Some kind of itch that makes you move forward when something struggles backwards with all its might. The unusually strong tide of motivation that you feel when they tell you that you are not good enough.
Again and again, I noticed what miracles are starting to happen when you come across this sensation of drive. But how to keep this spirit of drive, if the team becomes more and more?
A few months ago, I joined the Dropbox Paper team. By that time, the team had already grown to fairly large sizes. I still remember my first meeting with the team and the thought that we might have enough to fill an entire cinema. (I think I already dreamed of outdoor meetings).
Today, I have been working here for several months now, and I noticed something: even when our team grows, we somehow manage to keep this spirit of drive inherent in small teams. I don’t know if this happens by chance or according to plan, but I have several theories about how we stay on the drive.
The translation was made with the support of the EDISON Software company, which is professionally engaged in web development and recently redesigned its website .
Progress is more important than process.
The other day I talked with Kavita Radhakrishnan, our management team of products, and she said what shocked me:
“Process requirements will become obsolete as soon as you formulate them.”If you read my article on project documents, you know how I like well-designed documentation. But as soon as I thought about my latest projects, I realized that she was right about something.
The list of requirements is great to get acquainted with the goals and scope of the project. But as soon as you begin to put your plans into action, things rarely go as planned. At this point, progress becomes a priority. Documentation becomes a secondary issue.
I would say that 25% of the real work on the project occurs after the developer transfers it. That's when experts begin to test your projects for strength, and they will definitely present new requirements and advanced examples that you could not even think about. At this point, you need to feel the drive and do everything possible to achieve progress.
At Dropbox Paper, we learned how to deal with the blows of fate and accept the fact that plans will change - no matter how well designed your requirements are.
No ivory locks
As a company grows, people who create a product tend to move farther and farther from those who use it. Familiar with the developer or production manager who work in a large company? Ask them how often they talk to their everyday consumer. I bet you will be surprised at what you hear.
In the Dropbox Paper team, we try not to build “ivory towers” that distance us from our audience. Instead, we do things on the drive to meet people who use Paper.
For example, the project “Environments of the Real World”, which was launched by Mira Rao, one of our researchers. Every Wednesday we invite people to come to our office to tell them about what we are working on. It looks like a quick date session: a participant talks with several people from our team, with each person individually. And the most cool thing about this is that it is often developers, specialists and production managers who communicate with them from our side, and not researchers. Such meetings have taught us to talk with consumers on a regular basis.
In addition, we arrange widespread meetings with teams that use Paper. We are interested in how people use Paper in a real situation, and we are ready to go to their office, if possible. Any of our team can join such trips - developers, authors, experts, anyone. Each meeting is a chance to be inspired by something and learn something new about our audience.
Several Paper researchers talk with a team at Airtasker
Time for hacking
Many information technology companies have “hacking weeks” during which you can work on any project you want for the whole week. Paper also hosts hacking weeks, but other than that, it also has a “Hour of Hacking.”
Every few weeks, Friday afternoons, we all gather together, take drinks and work on everything we want. We can spend a whole hour on this or spend the rest of the day doing it.
Believe it or not, many of the features that Paper users really like today were created during these meetings. Have you ever used presentation mode? Coined during the hour of hacking. Names for Emoji? The same story.
Paper would not be what it is today if it were not for these sessions of hacking. If you give people time and space for improvisation, they will come up with surprisingly inventive ideas.
Leandro Castillo and Sheila Ramaswami during the Hacking Hour
Role-playing games
In the Paper team, people often play different roles in different projects. I saw how production managers conducted research on the usability of the product. Seen how researchers do design work. Each of us has a specified role, but we also have the opportunity to try on different masks.
In large companies, it is easy to retreat and say: “Sorry, this is not my job,” because in large companies, everyone has a rigid role assigned to him. There you will not find just a "developer". There is an interactive designer, visual designer, motion designer, system designer, etc.
Our job title does not define a person. We just do everything we can to get everything done. I write articles, but from time to time I do design. Neil Seti and Caroline Frost are production managers, but I saw them write code and create amazing things.
It is very embarrassing to see how everyone around you becomes energetic, just to help each other.
Small victories
For some reason, our team loves to like each other. Seriously, I have at least two appointments every week where we meet, just to express admiration and thank other people in the team.
We also created anonymous forms so that people are less shy about expressing love and it was not so ... awkward.
At first glance, the expression of admiration may seem a silly tradition, but I noticed how it brings good fruit one after another. Person A publicly expresses admiration for Person B, and then person B feels good and “gives five” to person B. You will not have time to notice how more and more people will take part in this.
Everyone wants to feel appreciated, and simple gratitude helps people very much to feel meaningful, energetic and to feel the team spirit. Not only big projects matter. Celebrate and small driving victories.
Love to experiment
The Paper team loves to experiment. Constantly on the agenda are dozens of experiments with features that we can run to learn them in practice from the inside. We have experiments related to various mockup projects, experiments related to different versions of a copy of the user interface, experiments on just about anything.
For example, here is an internal experiment created by Aisha Ferrazares and Harold Chek, where we show a warning if you try to send a notification to everyone in the document:
We will not run it as it is now, but a demonstration of this helps to understand whether it is useful or not.
We try to make it as easy as possible to conduct experiments in our team, because we want to make it easy to check which one is good and which one needs to be improved.
We also experimented with different ways of working. Now we are trying a way called "hakai-and-run." It lies in the fact that a small group focuses on one project for the whole 6 weeks. They can skip all meetings and other responsibilities to focus only on this project. It looks like a driving startup in a larger team.
***
So that's it. I am not a production psychologist, so take this article with a pinch of distrust. But, judging from my experience, the above things make our team feel at the drive and happy.
If your team is growing and is looking for ways to stay the same drive, I hope these tips will help you with this.