If you’ve ever made a decision—from how you communicate important announcements to staff to what you ate for breakfast—you’ve used PTR.*
PTR, which stands for preferences, traditions, and requirements, is a tool that can help you focus on what really matters so that you can mitigate bias and get to better outcomes. From an equity and inclusion standpoint, PTR is an invitation to pause, consider new perspectives, and be more explicit about organizational norms, culture, or expectations. Using PTR can help you mitigate bias in hiring, communicate more effectively when delegating, and stay open to new approaches.
Let’s say you’re a senior leader for a school or nonprofit. For as long as you’ve been there, all managers and project leaders have been asked to produce polished, written progress reports weekly. As you’re onboarding a new manager, here are some things you might communicate:
“Our leadership team meets weekly to make joint decisions and give input. I prefer updates in writing in advance, so we do these weekly and send them over email.”
It’s tempting to start with our traditions or preferences, which are often tied to our personal values and experiences. Habits are hard to break, and sometimes there’s a good reason for the approach we’ve used. If there is, be sure to share it. However, we recommend that project leaders and managers start from the bottom: get clear on the R, and then consider the preferences and traditions that might help or hurt your path toward results.
By isolating the three components, you can manage with an eye toward the requirements, seek other perspectives, and be explicit when there’s a reason for requesting a particular approach.
In the example above, you might start with, “Our leadership team meets weekly to make joint decisions and give input. Traditionally, we’ve shared updates over email in advance. I’d love to discuss what works best for you. My only requirement is that all team members have the info they need to make decisions, feel connected, and collaborate well during meetings.”
Separating your PTRs takes practice. Here are some considerations as you get started.
1. Articulate the requirements or outcomes
Be specific about the goal you’re trying to achieve to build the team’s sense of ownership over getting great results. In the example above, you could start by looking at your organizational values—let’s say they include transparency and collaboration. With these values in mind, you clarify that the requirement is really for everyone to have timely access to the information they need to feel more connected, make decisions in their realm, and spot opportunities to collaborate. Writing is a preference and weekly emails are a tradition.
By distinguishing the requirement, you may find you want to explore new paths to the same outcome, such as video updates with transcripts, which could be even more engaging and accessible.
2. Be flexible and seek other perspectives
Seek other perspectives as you separate your R’s from your P’s and T’s. Sometimes, you’ll need to let go of your preferences or work with staff to revise traditions (however beloved) as your team grows in size and/or diversity. This is an important choice point. When we rely on preferences and traditions as a shortcut to outcomes, we risk short-circuiting our team’s ingenuity and missing new approaches that come from diverse experiences.
3. Watch out for sneaky P’s and T’s
We all tend to conflate our preferences and traditions with requirements. Some P’s and T’s have been around so long that they sneakily become auto-pilot requirements. This can impact the success, participation, and belonging of your team members who have different needs, experiences, or ideas. It can also obscure your goal. If you find yourself dictating how you’d like something done instead of the result you’re aiming for, pause and ask yourself if the “how” is really a requirement.
Above all, never let P’s and T’s become default expectations that only you’re aware of. When this happens, staff who are more like you (or know you better) are more likely to pick up on those expectations. Conversely, staff who are less like you may not be able to read your mind.
4. Be explicit about preferences and traditions—and why they exist
There’s nothing inherently wrong with preferences or traditions—as long as you acknowledge them openly and distinguish them from requirements. When you’re suggesting an approach to meet a goal, name it as a preference or tradition, share the “why” alongside the “how,” and indicate how open you are to other ideas.
- When you feel strongly about a preference or tradition, you might say: “For this project, I prefer we use the software we have, given the tight timeline and budget. Adopting new technology will take time we don’t have, but I’m happy to consider ideas for next time.”
- When your preference or tradition is a suggestion, but you’re open to other ideas, you might say: “We’ve been doing X because we’ve had good outcomes with X in the past, but I’m open to other ideas. What’s your experience been? Do you have another approach you think will get even better results?”
When a particular approach (mindset, behaviors, or values) is essential to getting results, you should be explicit about why, while inviting new ideas and being clear how (or how quickly) you’ll take them into consideration.
Now, check out some additional examples of PTR in action.
*Credit where credit is due: we got hooked on the idea of PTR because of this Fortune article.