When you’re working in a fast paced startup, it’s easy to reach burnout no matter what role you’re in.
But when you work on multiple concurrent projects and across lots of teams, the risk of burnout isn’t just high, it’s almost inevitable. Many individual contributors (such as researchers, visual designers, content strategists, data scientists) who work horizontally across teams can be viewed as an infinite resource. We come in, we work our magic (usually in a short space of time) and then leave again to do the same on another team.
Sometimes when we’re working in a “service” function, we do ourselves a disservice. We essentially “drop into” a project with an unrealistic deadline, do the work anyway and then leave.
And we wonder why teams expect the work to happen faster and faster and with tighter deadlines? It can become a vicious cycle, FAST.
But it doesn’t have to be this way.
By communicating your process to the team, empathy begins to form for the people behind the role of X. Establishing an understanding of not only how much work takes place but how long it takes and how your projects are prioritized can drastically change your work life as an individual contributor.
I’m going to go into detail below about how we’ve worked to tackle this challenge on our research team at Intercom and hopefully you can learn from this too no matter what role you’re in.
Make your roadmap visible to everyone
The first step to communicating your process is making sure your project roadmap is transparent and visible to everyone. Your roadmap is a hugely important material that should be accessible to everyone. This can be a pretty straightforward thing to do. For instance if you have your roadmap in a Trello board or spreadsheet, ensure that it’s accessible for everyone in the company in it’s sharing settings. Then you can link to the roadmap from your internal wiki team page or have it pinned to your team’s Slack channel.
In research, we tend to work horizontally across teams so it’s imperative that these teams (and usually the PMs of these teams) know that you work on multiple teams, not just theirs. This will help immensely when you’re trying to communicate to someone why you can’t work on their project. In theory, if a person isn’t aware of what else you’re working on, they could assume you just don’t want to work on it. And we know this isn’t the case.
Practice the art of the positive “No”
This term was made popular by author William Ury in his book “The Power of the Positive No”. The concept is pretty simple and is described as:
“A Positive No has the power to profoundly transform our lives by enabling us to say Yes to what counts–our own needs, values, and priorities.”
When you have a team requesting more of your time or resources than what is possible, it’s important you don’t dismiss ad hoc, sudden projects by stating “No, I can’t work on that.” This isn’t going to help with building meaningful relationships with your team. When you work in a startup, these requests will be inevitable.
Instead, say something like “That sounds like a great idea. Can we chat more about this to see if I can fit it into this cycle?” Another technique that works well has been used in improv for years whereby you use the term “Yes, and…” instead of saying “No.” By doing this, you’re actively removing yourself from a negative mindset when in a difficult position.
By using terms like this in your vernacular, you’ll notice these tough conversations around bandwidth become easier to handle. Now you won’t be shutting people down, but opening up the conversation of what they need, while also communicating what your constraints are.
Treat any ask as a request before committing to it
In a startup environment, you’re going to find that even when you proactively share your roadmap and practice the art of the positive “No”, ad hoc and sudden projects will still arise. On the research team here at Intercom, the way we handle this is to differentiate between requests and actual projects that need to be worked on.
In a research scenario, if a project owner feels the researcher should STILL work on the project they are proposing after they have been shown the roadmap, we ask them to add it as a research request and outline why it is a priority. Then we can work with our team to allocate the project some time for the research to take place. We use a simple form to scope out requests and ask questions like:
Why is this research taking place?
What decision do you plan to make based on the results of this research?
What are the high level research questions or hypotheses?
This can be a great forcing function for team members to think deeply about the project ideas they have, so that it’s no longer a fuzzy concept but a well thought out idea. No one wants to be in a scenario where they work on a project plan, and then be told that the project has “changed course”. Of course this can happen in any company (especially startups) but ideally we want to work toward an environment where this is not the norm.
It’s all about boulders and pebbles
When I was struggling with saying “No” to projects, one of the best pieces of advice I received was from my manager Sian and involved boulders and pebbles. Strange I know, but stick with me.
Communicating to team members that you work on many teams and many concurrent projects can be difficult. Using the “boulder/pebble” metaphor has been a hugely helpful way of conveying our research process (and our workload!).
So how does it work?
When talking about what projects we have on, we ask the person to imagine a big glass vase. The vase represents a working cycle (for our team, this is 6 weeks). Inside the vase are 2 big boulders. These represent our “priority projects” which are projects that tie into a company goal or correlate to the success of a new feature or product.
Every six week cycle will always have a 1-2 boulder projects. The vase may look full with the two big boulder projects in it but if you look closely, there’s still room for smaller, lower priority projects. These are “pebble projects” and in a research scenario, these can be anything from rustling up a quick survey for a team to get feedback from customers, or pulling together a 1 pager on what we know about X from past research. It can also be a personal goal like writing a blog post or speaking at a meetup or event.
Since we’ve begun using this metaphor to share our research process and our workload, the amount of urgent but ambiguous requests we’ve received has reduced significantly. We’ve even experienced project owners saying “I have an idea for a pebble project! Can we chat about it this week?”.
We’ve also communicated that strategic projects take longer than normal and require more planning and time for analysis. Aspects such as finding exactly the right people to participate in your research study usually takes longer than a typical design research project as the participants needed for a study can be difficult to find and schedule.
A really simple and effective tool we use to raise awareness of what goes into each research project is to include this timeline in every research plan. By highlighting all the critical building blocks of the project that used to be invisible, we’ve created more realistic expectations from the team of our bandwidth. That in turn leads to more reasonable expectations of our time in future.
How we communicate how we work is an ever-evolving process for us and we’re hoping to refine it more as our projects change and our team grows. If you find yourself burning out on a regular basis and are in a position whereby it’s difficult to evoke understanding in others about how your work is conducted, try some of the tips mentioned in this post and adapt it to work for you and your team.
Comments