“That’s how we’ve always done it!” (A guide to using PTR)

Last updated: October 12, 2021
Estimated reading time: 4 min


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:

Illustrative graphic with three rows, each including an icon inside a hexagon shape. The first one says Preferences with an adjacent image of a written document and the text, “I prefer updates in writing.” The second row says Traditions with a mailing envelope icon representing emails and the text, “We do these weekly and send them over email.” The third row says Requirements with an adjacent gold star. The icon shows a computer with chat bubbles and a person, alongside text that reads, “All team members have the info they need to make decisions, feel connected, and collaborate.”

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. 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.

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.

return to Delegation main page return to Equity & Inclusion main page