Guiding principles for teamwork on Search Product
This document outlines some guiding principles we seek to follow when welcoming engineers onto the Search Product team. It also serves as shared vocabulary on the team, when we talk about the culture we try to foster.
You’re trusted by default
The notion that one must “earn the trust” of their peers or manager is extremely limiting for newcomers, who are faced with this arbitrary “bar of trust” they must meet before they can deploy agency.
On this team, trust is a given. Your teammates will value the opinions, questions, ideas and concerns you will bring forward from day zero. When we ask you questions, it’s out of genuine interest for what you might have to answer, not as a test of your worth. You will not be judged or dismissed for bringing your thoughts forward.
Liberating ability through context
We trust in your skills and ability; this is why you are on this team. But raw ability must be coupled with context on the team’s technical domain and its goals in order to produce impact.
As you onboard, our focus is to equip you to do your best work. For us, this means providing extra care to help you understand how the team works and communicates, what our goals and priorities are, and any other useful information (technical bigger picture, historical decisions, etc.). During these first few weeks, your focus should be on learning, not executing. We believe that you’ll be in the best position to execute if you have a good grasp of tying tasks back to this wider context.
We’ll provide direction, not tasks
While we will provide you with some initial tasks to help you understand how we work, the eventual end goal is that you are able to identify the work you should tackle to produce impact towards team and company goals. This impact can be direct or indirect. An example of direct impact is building functionality that will directly unblock a user outcome. An example of indirect impact is ensuring we have a solid foundation to build upon, so that we can build functionality that unblocks user outcomes.
Our job is to help provide input and clarity on direction: what problems are we seeking to solve as a team, as a company? Why do these problems matter? What are the north star outcomes? We want you to understand how these questions relate to your domain of expertise, because then you’ll be empowered to directly identify and break down the work that makes progress towards our north star outcomes. As you wrap up a work item, you should feel empowered to ask yourself: “what should I work on next? why?”, and to bring your answers to the team. In your first few months, you may find that we end up asking you these questions (“what do you think you should work on next?”), to encourage this practice.
Your scope can be arbitrarily wide
It’s natural to gravitate towards the types of problems you have the most expertise solving, and initially we’ll suggest tasks that match your expertise. But you do not need special permission to tackle problems outside of this scope! A practical example could be a backend-leaning engineer tackling frontend-leaning tasks. However, scope extends beyond the technical realm here: you should feel empowered to, for instance, suggest improvements to our team processes, challenge or clarify our team strategy, or bring forward opportunities to collaborate with other teams.
We trust you to leverage this freedom with discernment, keeping good forward momentum towards the outcomes you, the team and the company are targeting. If in doubt, we’re always ready to help you identify the best strategies to do so.
Keep plenty of breathing room
Breathing room, or slack time, means leaving a portion of your total work schedule unallocated to specific tasks. This portion is traditionally hard to quantify, but you should aim for a ballpark 50% of your total bandwidth. We trust you with how you employ this breathing room. We have found the team to be most effective when teammates keep plenty of breathing room: the team is more relaxed, has room for creativity, the quality of our work improves, and we end up making faster overall progress towards roadmap outcomes.
You may find yourself using this breathing room to:
- Absorb an occasional underestimated task without straining your schedule
- Be able to pursue codebase health improvements that you identify as you work towards roadmap outcomes
- Grow your skills and scope
- Develop and explore ideas you’re passionate about
- Or, sometimes, simply to breathe.
It may take time to adjust to having more breathing room in your schedule. Don’t hesitate to talk to your teammates about their experience organizing their time and bandwidth.