Last week, I wrote about the common practice of approaching conflicts on your team by asking everyone to “assume best intentions.” This norm can be a roadblock for folks of marginalized identities to address the problems they’re experiencing at their company or community, and does nothing to build the trust that it demands of teammates.
If this is currently a policy on your team, or you’re tempted to make it one, I’d challenge you to instead interrogate whether the policies, processes, and norms on your team promote trust. Are they built on the belief that your teammates are trustworthy and aligned towards a common goal? Do they leave anyone out? Do they promote an unnecessary or arbitrary hierarchy?
People and teams are unique, and there’s no one-size-fits-all solution to building a culture of trust. We can’t just implement a set of rules and think we’ve suddenly arrived at equity.
The following are places in your culture that I might investigate first. They’re often processes that are high-impact and high-traffic; people participate in these processes a lot, and they can have a large impact on how someone perceives their team. Make sure they’re aligned with your team’s values.
The phrase “bottleneck” commonly refers to an engineering problem where the performance of an entire application is limited by the capacity of a single component. Bottlenecks can also exist in your team’s processes.
Process bottlenecks aren’t just strains on velocity. They can also be a sign of distrust.
Take the code review process, for instance. Many teams disable merging to
on an approving review. This can be a bottleneck, because I have to wait for
review again after I have already made the requested changes. It also indicates
a few trust problems.
First, we aren’t trusting that the author will seek out and incorporate feedback
unless they are strictly required to. We also aren’t trusting their judgement of
what code is ready to be merged to
main, even though they are the person with
the most context on the problem.
We additionally aren’t trusting that our non-author team members recognize the value of code review, or that they will prioritize reviewing PRs unless we literally can’t make progress otherwise.
If it’s feasible to remove this bottleneck in your organization, try making the change. Shifting the role of the reviewer away from “gatekeeper” and towards “adviser” makes code review more collaborative, and encourages teammates to approach code review with respect for their teammates’ ownership of their work.
If one of your teammates wanted to change a process or policy, where would they start?
Having a clear, actionable answer to this question is a high-impact way to empower teammates to take collective ownership over your culture and policy.
Is the answer to talk to one specific (likely very senior) person? That might signal a lack of trust in your teammates’ abilities to propose changes that are good both for them and for the organization. And unless it’s a sensitive HR issue, it might also be a sign of a bottleneck.
Having a clear, low-friction process for suggesting changes to how you operate gives teammates ownership and accountability for building a culture that reflects the team values. It also creates opportunities for more perspectives to be heard.
Documenting your policies and processes doesn’t mean they’re set in stone. Choose a central place where people can reference how you operate, and document how people can suggest changes to it. Your handbook should be a living document that evolves over time. Normalize this behavior by having community leaders suggest necessary changes and solicit input.
The tools you choose set a tone about who is welcome and empowered to participate. For example, some video conferencing software have aggressive roles and rules enforced by default. This can be things like who can unmute themselves, who is a speaker vs who is in the audience, and who can grant permission for others to speak.
These features are useful for giving productive presentations to large groups. But in smaller team settings, it can set an expectation about who is welcome to contribute and who is expected to passively listen.
If these features aren’t necessary for your meeting format, consider disabling them or choosing a tool without these restrictions. If that’s not an option, see if you can make everyone an admin of the tool. Trust your teammates to speak, mute, and screen share when appropriate.
How many decisions in your organization are made in direct messages or other private channels? If the answer is “a lot”, consider why that is.
Private channels can obviously lead to information silos, but they can also lead to trust silos, where you end up trusting the people inside a certain channel or DM, and distrusting those outside of it.
Consider opting for public channels where possible. A good gut check if you’re not sure is to ask yourself if you would need to pull your teammate into a private room if you were talking about this aloud. If the answer is no, it probably doesn’t require a DM.
Putting more conversations in open channels, even to just ask a question, helps get answers faster, gives everyone an opportunity to participate, and spreads context more widely. Teammates can trust that if they subscribe to issues and channels they care about, they’ll be in the loop for important changes and can weigh in where relevant.
Building a process for reviewing and adjusting compensation is both extremely complicated and extremely important. Many organizations balance fixed factors, such as cost of living and market rate, with more subjective ones, such as individual performance.
Just because the process is complicated doesn’t mean it has to be secretive. Be transparent with your team about what factors you’re considering for promotions or raises, how much each factor weighs in the final decision, and how they will be evaluated. Review team salaries at least annually for equity and address discrepancies.
Do you currently have a plan for when an employee is concerned about their comp?
If not, make one, and be sure it addresses systemic oversights in your process.
For example, if an employee raises that their time spent on responsibility
is not reflected in their compensation, have a plan to address that concern in
a way that compensates all team members who do responsibility
X, not just
the person who felt comfortable asking.
Being transparent about how you make compensation decisions and how you identify and rectify inequities can build trust with the organization. It can also foster a more collaborative environment where teammate A’s success is not predicated on teammate B’s failure.
How you react to constructive feedback has a huge effect on how your organization will improve over time. This isn’t just because actionable feedback can point out processes and policies that need updating. It also determines whether people are motivated to give you feedback in the future.
A teammate giving you feedback is one of the greatest expressions of trust. They’re telling you that they trust that you are willing to hear criticism, believe that you will act upon it, and think that you are capable of improving. Don’t let that trust go to waste.
Building a culture of trust in any organization is an ongoing process— there’s no checklist that will assure us that our organizations are inclusive. But we can interrogate our processes and ask ourselves if they reflect our stated values. If not, how might we improve them? Integrating this thinking into how we operate is the first, and ongoing, step.