00:00:12.200
Welcome! I hope lunch was great. My name is John DeWyze, and I work at Shopify. I'm here today to talk about trust. So, do you trust me? I actually already know you might trust me a little. Maybe not directly; we've never talked, but perhaps because the RailsConf committee chose this talk, or maybe you think Shopify is cool, or at the bare minimum, you trust that this is a better way to spend the next 30 minutes than doing nothing. That's impressive considering how gorgeous it is outside, so I appreciate that.
00:00:30.540
So, who am I? My name is John DeWyze, and I use he/him pronouns. I’m a Staff Developer at Shopify, originally from the suburbs of Chicago. I've been a developer for eight years after a complete career change. I care a lot about healthy teams and the people side of development, and I've always enjoyed that in a technical role rather than as a manager. I'm also a dad of two with another one on the way. I love card games, especially Bridge. Does anyone here play Bridge? Oh my gosh, six of you! That's really cool.
00:00:48.360
I also love making bread and pizza and I'm getting into woodworking. If any of those things interest you, I'm happy to talk about them. Before we jump in, I have a few caveats. If I ask you to raise your hand, you don’t have to if that’s not your thing—no problem! You can leave whenever you want. Just please do it quickly and quietly so that others can listen, and don’t feel like you're stuck here. If you need to leave during the talk due to an emergency, for water, or if you want to leave because you’re bored, that's fine. Please just try to be quiet.
00:01:06.780
If I say something ignorant, harmful, wrong, or offensive, please let me know. My email is at the end, and you can come find me after the talk. I'm always looking to grow and fill in my gaps as a developer, a speaker, and just as a human being. I’m not a psychologist; I'm a developer married to a therapist, which doesn’t necessarily give me any credentials for this talk. I just care about trust.
00:01:23.319
For better or worse, a lot of us talk about these topics because we care, but please don’t take my word as gospel. This talk is sort of focused on teams and companies because trust doesn't quite matter as much at an individual level, although whether we trust ourselves is important. If you're a solo developer, this might not apply directly to you, but I hope that if you’re on a team someday, you find it helpful.
00:01:43.020
Much of my outside data comes from something called the Truth Project, which is a large initiative out of Northwestern University. It’s cross-disciplinary, covering various aspects of life, relationships, business, teams, organizations, governments, finance, bioethics, and more. They have really interesting findings around trust globally and the cultural differences in trust among individuals and in systems and institutions. That said, it does seem to have a Western focus, so take that for what it's worth. If you're on global teams, do check it out; they have a bunch of bite-sized four to seven minute videos that you can watch at any time, and it's really cool.
00:02:05.220
So, what are today's goals? We’re going to discuss the systems of trust within our companies and the broader world. We will also talk about the trust rituals on our teams and explore the relationship between trust and time. We'll delve into the psychology of trust, what it is exactly—we all have a working definition, but we do need to examine it more closely. We'll also discuss the benefits of using this lens, and finally, we'll talk about practically building and maintaining trust on our teams.
00:02:29.340
Now, I’m not sure if this is the right term, but I’m going to use “a system of trust.” This describes the institutional aspects that are more stable and not as easy to change, but are intended to be reliable and consistent. We have these systems because taking the time to trust every single person we encounter within a culture, a group, or a team is hard. So, we rely on these systems to remove that burden.
00:02:52.620
We don’t necessarily have to know or like someone to trust them or to trust that working with them will turn out okay. Many factors contribute to how we trust and why. I want to highlight a few cultural aspects. Every culture has different norms that determine how we trust. In cultures where social norms are explicitly followed, the need to trust individuals diminishes because we can put our trust in the system.
00:03:12.300
For example, if you're in a country that strictly respects lines or queuing, you know line jumpers will face consequences for trying to cut in front of you. You grow to trust that system, as well as the understanding of that cultural context. However, this isn’t universal; depending on where you are, the expectations around trust can differ. For instance, how old children must be to play alone at a park or whether stoplights are seen as optional reflects this variability.
00:03:31.460
There’s also our experiences to consider. We could delve into attachment theory, which explains that our first relationships, good or bad, inform our ability to trust the world. In our jobs, we often notice that the most skilled collaborators or great teammates are the ones who get promoted, which reinforces our trust in hierarchical systems. On the other hand, when we see loud, unqualified people getting promotions, it shakes our trust in that system.
00:03:50.579
We also have contracts. In some cultures, a contract allows us to trust less in individuals because there's a legal requirement governing our interactions. This acts as a safeguard; if someone violates the contract, they know there will be consequences. Therefore, we don’t have to rely on personal trust when an external system helps ensure it. Then there are titles and certifications—these imply that a person has the necessary qualifications. Think of an electrician: they have certification, which gives us basic trust in their skill. While we might not trust them to give us a fair price, we trust their ability to work safely with electricity.
00:04:14.160
However, when we're trying to determine the fairness of a price, we reach into our web of trust. For example, we use Yelp as our universal web of trust. If a business has a thousand good reviews, that information can guide us, especially when we have no other options. However, we also have different levels of trust; if my best friend vouches for someone, I might disregard what Yelp says. All of these elements inform our internal understanding of trust.
00:04:42.060
We also have internal systems within a company. We trust teams, comprising people with diverse skills, to perform certain functions and become subject matter experts. Managers can be seen as defenders of trust, determining who deserves trust based on their titles and promotions, and upholding our rituals. Hopefully, they do this to protect the team from external interference.
00:05:10.440
Then you have tech leads, who function as builders and maintainers of trust. They’re responsible for ensuring that enough systemic checks and balances, like continuous integration (CI) or quality assurance, are in place during action. All of us can contribute to this trust, but in some companies, that's not encouraged or recognized as much. Both systems of trust can grow or erode over time, impacted by personal interactions and company culture.
00:05:35.760
Now, let's talk about trust rituals—a term I completely made up. We’re going to discuss things like PRs and tests as trust rituals. Now, you might not think of these as trust exercises, but I would argue otherwise. Building trust takes time, and we do many things without needing to fully trust every person on our team. These rituals are designed to save us time, but they still require a foundation of trust.
00:05:56.340
When those systems fail, we get frustrated because the system broke down, and the question becomes: who do we blame? Generally, we need the system to function well, but when it doesn't, it can create trust issues. Thus, these rituals end up being crucial, as they help us offload trust at a local level, making it easier to handle the complexity of our relationships.
00:06:15.420
Building trust is challenging and time-consuming. If we were tasked with trusting every person on our team completely, we would never accomplish anything. Maintaining friendships and relationships involves cycles of growth and decay, making it inefficient to trust everyone entirely. Offloading trust to these rituals and systems is normal and beneficial, as long as we do it the right way.
00:06:33.780
Let’s take a deeper dive into pull requests (PRs) and how they facilitate trust. Instead of needing domain experts to review each line of code as it's written—which leads to rewriting and second-guessing—we trust the process in place. We can verify at the end and check together as a collective, rather than needing to involve every team member during the writing phase.
00:06:51.420
This allows us to share knowledge and trust that our team members will improve by reviewing each other's code. Additionally, addressing edge cases can benefit from having someone with expertise review the code. This mutual collaboration creates systems like pull requests, allowing us the freedom to write code without constant worry about its quality throughout the process.
00:07:09.780
But why do we proceed this way? Generally, we are creating a product that we’re selling, and improving our skills as teammates creates better outcomes. Our aim is not just to become better developers, but to ensure we deliver a reliable product. Bad code can be costly, leading to trust violations, and we'll discuss that more in a moment.
00:07:30.540
Trust violations stem from unmet customer expectations. If downtime occurs or bugs are present, customers may question whether they can trust us moving forward. This can lead to financial losses, which are also time-consuming to rectify. If we are allocated time to develop new features but instead spend it fixing bugs, it becomes a trust issue.
00:07:51.480
Let’s not forget about tests, another trust ritual in Ruby environments. Tests serve as documentation, preventing regressions that could violate trust and ultimately cost us money. Realistically, the integrity of our customers’ trust in us is arguably more critical than our financial losses. If our customers feel secure about their interactions, they are more likely to continue working with us.
00:08:10.260
Our jobs rely on the expectations set for us, and if we lose a customer who doesn’t share expectations about the product, we’re assured they won’t leave due to financial reasons. Trust is built through shared expectations.
00:08:29.520
What are some other rituals? Continuous Integration (CI) is a prime example. Instead of having to test every interaction and every piece of code in the entire code base, we can trust CI to identify issues down the line without the delay of waiting to test each change as it’s made. Pair programming is another method where time invested is expected to yield valuable results.
00:08:51.420
For those who have tried it, they’ll attest to the heightened productivity that can often exceed working alone. Type systems in programming languages offer indicators that highlight incorrect usages during development, preventing mental overload later. This assumption allows us to trust that style issues are resolved automatically, saving mental energy.
00:09:12.660
Design patterns also facilitate trust since they provide a consistent approach to coding. With frameworks like Rails, developers do not have to relearn how to structure code every time they write a controller. Additionally, project management tools like Jira and Trello reinforce organizational trust, as teams can maintain oversight without needing to know all details constantly.
00:09:37.620
It's essential to ensure trust is robust across these systems. For example, many teams have experienced PR exhaustion cycles, where an overwhelming number of requests causes frustration over review delays. If reviews seem to take too long, teams may feel tempted to add unnecessary processes that do not build trust.
00:09:58.380
Why do we implement additional rituals? Oftentimes, it’s because systems are predictable in theory, while people can be fallible. Blaming a person for a failure isn't fun; sometimes, it's beneficial to reinforce our systems to shore up our trust in them. But fundamentally, all these rituals serve one crucial purpose: saving time.
00:10:20.160
Today's talk has had a somewhat visually aggressive theme around the interplay of trust and time. The rituals and systems we've discussed aim to prevent trust violations while saving us time, enabling us to focus on adding features and continuing our growth without losing our customers' trust.
00:10:42.540
These rituals can become burdensome if we deem them unnecessary. If we find these trust-building rituals bothersome, we risk undermining the intricate trust system we've built within our teams. Trust is also especially critical for personal growth; if someone from an underrepresented group in tech experiences trust violations, their pathways can be more complicated.
00:11:01.440
Time is an essential resource in tech, and violations cost us time that could otherwise be spent on meaningful projects. We haven't stressed time enough, but it remains a primary goal, building trust while preventing violations and reserving time for productive work. At this point, let’s define what trust truly is.
00:11:20.160
Having discussed systems of trust, I’ve been utilizing an assumed definition throughout the talk. It’s essential to articulate what trust actually means. When I refer to the Truth Project, I see varied definitions combined into a consensus: trust is about the relationship we have with others, whether that might be individuals or systems.
00:11:39.300
Trust is a reliance that can breed either betrayal or camaraderie. Consider my toaster; if it breaks, I don’t feel betrayed since I had alternative ways to cook. However, if my car lets me down before an important appointment, it negatively impacts my life. This highlights how trust differs from mere reliance—it ties to expectations and what one seeks from different relationships.
00:11:57.780
So, what comprises trust? Two core components of trust exist in nearly every definition encountered through the Truth Project. First, predictability: someone or something behaves consistently over time, the friend who is always there for you in tough moments.
00:12:08.880
The other two components worth mentioning are integrity—the commitment to following through on promises—and benevolence, which speaks to kindness. One can exhibit integrity without being benevolent; perhaps it's a matter of honor among thieves—they keep promises but remain morally questionable.
00:12:25.380
There are also trust violations, primarily divided into two categories: integrity violations—which breach predictability and integrity, often driven by reckless choices—and confidence violations, which represent when someone misses a mark not out of ill intent, but due to lack of skill or ability.
00:12:46.920
To repair trust, dealing with competency violations typically requires a simple apology. Admitting to a failure usually suffices, and so long as improvements are noted, we can often reintegrate individuals back into a trusting space. However, when integrity violations occur, an apology carries little weight.
00:13:10.740
If there's a breach of integrity, trust can’t be regained just by an apology. You may show improvement, but trust remains in doubt unless one can prove their intentions for bettering themselves are genuine. Integrity violations are challenging to repair and require considerable effort, humility, and time.
00:13:27.720
Repairing systemic violations of trust is much harder than inheriting it. If you take a trusted position within a company, it’s crucial to avoid losing that trust. Conversely, if you walk into a situation lacking trust, you’ll have extensive work ahead to rebuild it.
00:13:46.440
Leaders inherently possess a bias for action; they tend to add systems intended to build trust. However, real action requires addressing trust deficits first—resolve the issues that instigated the violations in the first place. A comical yet informative story revolves around Doug Conant, who took the helm at Campbell Soup when it had the worst trust scores of any Fortune 500 company.
00:14:07.800
To deal with this, he implemented a mission of valuing people and ensuring they valued Campbell in return. The order of this mantra is significant; he identified a critical truth: unless employees felt valued, they wouldn’t care about the product, rendering future efforts useless.
00:14:29.460
In practical terms, Conant handed out Post-Its every day highlighting positive contributions he observed without merely writing, 'great job!' Across several years, he distributed around 10,000 of these notes, demonstrating recognition that helped rebuild trust within Campbell's workforce.
00:14:49.280
Now, what are the tangible benefits of trust? We continuously revisit trust systems and rituals because they yield significant advantages. I'll share some quotes overheard in the workplace that succinctly illustrate varying approaches to these systems throughout my career.
00:15:14.460
The veteran might declare, 'Back when we started, we paired and committed to master.' This sentiment resonates across many environments where efficient practices may dissolve as teams scale or processes become cumbersome. It's common for teams to reminisce about times when things were simpler.
00:15:36.080
You might gather someone new with optimism claiming, 'If we just implement this design pattern, we’ll eliminate all problems!' Meanwhile, I found myself asking for an extra set of eyes on a pull request—this request denotes the trust we seek in validation through ritual.
00:15:59.460
It’s also essential, at times, to lean on better processes—developers often encounter requests from management urging them to consider using more robust tools. Alternatively, frustration can arise when delivering work becomes entangled in tedious bureaucracy.
00:16:19.560
Reflecting upon the office culture, trust fosters an environment conducive to experimentation without the threat of repercussions. When team members are aware that they can explore risks, they can innovate without the fear of failure.
00:16:36.080
This concept resonates with what Amy Edmondson describes as 'psychological safety,’ underscoring trust as a shared belief that enables safe interpersonal interactions. At Shopify, we utilize something termed the 'trust battery.' This concept integrates trust, respect, and reputation. As trust accumulates, team members develop confidence enabling greater autonomy.
00:16:57.600
In practice, when a team member exclaims, 'I’ve got this!' it signals confidence in their abilities; that individual doesn’t face micromanagement and can admit mistakes without fear of detrimental repercussions.
00:17:19.620
Ultimately, if our aim revolves around preventing trust violations while fostering an environment where trust can thrive, time must be a central focus. Early in the talk, I mentioned how managers play a vital role as defenders of trust.
00:17:41.280
If they defend trust, it stands to reason they must also defend time. When tech leads cultivate trust, spending time effectively must correlate with that trust-building. There are complex questions to navigate here. For example, do people trust the systems you've implemented regarding promotions and feedback?
00:18:03.600
Without such understanding, all prescribed rituals might become ineffective. Once trust deficits have been established, it becomes essential that team members buy into the rituals. Clarifying goals and expectations around these rituals assists in their understanding; if the importance of engaging with these practices is lost, they may trail off.
00:18:35.760
In my experience, I’ve seen a manager approach each planned project by running through the rituals in place to ensure everyone is aligned. They ask: 'What’s working? What can we improve?' This level of consideration encourages teamwork that adapts to project needs.
00:19:12.420
Employing defined minimum timeframes dedicated to activities like PR reviews could alleviate pressure. By solidifying these periods of time, we can hopefully eliminate unnecessary interruptions and allow space for collective input. It's easy to stand up here and mandate this, but pressing deadlines may hinder implementation.
00:19:41.940
As we reach the conclusion, a couple of final reflections. Consider asking the essential questions we’ve explored: 'Do team members understand how a specific ritual fosters trust?' and 'Do they believe these practices ultimately save time?' Assessing systems such as style linters allows for productive discussions about how consistent code construction can mitigate future misunderstandings.
00:20:00.880
As for team leads, spending time effectively entails facilitating learning opportunities. Teaching doesn't mean doing the work for others but understanding effective pedagogical approaches. Each employee will absorb guidance in varied ways, and it's crucial to tailor teaching methods.
00:20:22.640
Helping team members learn how to appropriately review pull requests is vital. As a guideline, foster a culture of inquiry—encouraging probing questions enhances collective understanding. This encourages transparency and access to vital knowledge without fear of judgment.
00:20:45.860
Lastly, mindfulness in our roles reinforces our trust-building efforts. Not to be confused with the meditative concept, the second meaning of 'ohm' relates to electrical properties, advising us to slow down and evaluate our approaches. The resistance signifies our ability to adapt; making it normal to take pauses encourages reflection.
00:21:12.600
I hope these insights resonate with you. Thank you for staying over time. Did anybody feel a connection with my thoughts? Any disagreements? I'd love to know your biggest takeaways. You can reach me through various social media platforms. To anyone interested, Shopify is hiring, and I truly love working here. I'll be around if you want to chat! Thank you, and enjoy RailsConf!
