Engineering and Trust

After 4+ years of working as a Software Engineer at a tech company, there’s been quite a lot to takeaway. But I think the biggest thing I’ve learned is that understanding trust is key to being effective and efficient in a team setting. Here are some thoughts I’ve put together on trust.

Why talk about trust

It’s all about trust. Trust enables speed. Trust enables risk. While my main focus is shipping impact by builidng software systems, I have found that the trust I’ve built within the org is a gate to the scale of that impact. If you’ve lost the trust of your manager, it’s unlikely they’ll ask you to take on the most critical/impactful work for the team. Honing in on “building trust” and understanding the importance of it has helped me focus on following up on the little things and details that make/break a succesful project or quarter. As a result, the trust I’ve built up has opened the door to larger scope opportunities.

Tips for building trust

  • Do the hard work. If you take nothing else from this post, I would ask that you take this: there is no replacement for doing the work. Sometimes the work will be hard, and doing that work will matter. The worst thing you could do is do all the things in this post except the hard work. I think this results in someone coming off as sleazebag-y/manipulative/grift-y, and that’s the worst thing to be. So, make sure that you do the hard work when it’s asked of you and sometimes when it’s not. It lays the foundation for all the things you want to build in your career.
  • There’s nothing wrong with saying “I don’t know.” A critical step in building trust is not being wrong. And the best way to not be wrong is to be honest about when you’re not sure about something. An hour of research/fact finding is well worth the days/weeks/months(?!) of time you and your team will save from working with unchecked or incorrect assumptions/assessments.
    • One of the nice things about saying “I don’t know” is that it dovetails nicely to doing some work: finding out. Gotta do the hard work.
    • The sinister part about imposter syndrome is it will push you away from this very powerful tactic. I felt a lot of pressure when getting into tech to act like I knew everything. Luckily, by the time I was interviewing at Plaid I was a bit more comfortable saying “I don’t know”. This saved me in my system design interview, as being transparent about what I didn’t know (how databses work/schema design) was taken as a positive signal.
  • Write tests for your sanity. There has been a lot written on testing (overview, stripe increment issue). But the thing that has pushed me to test diligently has been paranoia. As the complexity of code paths and systems I worked on increased, it crystallized that there really isn’t another way to know my code is doing what I want to do. After my first couple re-depoys/SEVs, I had a healthy dose of paranoia and fear around deploying my code. Now my default assumption is that my code is broke. It isn’t until I write (and break) my unit and integrations tests, and verify in the production environment, that I am convinced my code works. More than any advice or requirement, my own paranoia pushed me to test comprehensively. Testing empowered me to trust myself and sleep easily.
  • Deadlines are trust-building exercises. Most deadlines in tech are arbitrary. Some are real (event-based releases e.g. a messaging app wants to release special content for Diwali), but the overwhelming majority of deadlines in an engineer’s career are self-imposed. A lot of engineers’ first instinct is to build trust by aspirationally promising fast turnaround times on their work. However, you’ll lose a lot more trust missing a deadline than you will delivering 2 days later (or 2 weeks later) while holding true to your word. When the date is fixed, see if it’s possible to scope down the work or assess if adding another person would help ease time pressure.
  • Speak minimally, be wrong less. Habitually, I do a lot of thinking out loud, and that hurt me a lot in the workplace. Technical communication (and communication skills in general) are really important. We only get so much synchronous time with each other, and less so with higher leverage folks (tech leads, managers, CTOs, etc.), and thus the skill of succinctly and effectively communicating thoughts becomes critical to making the most of everyone’s time. One huge step in communicating more effectively for me was to be cognizant of what I was saying. Lowering my signal/noise ratio (I am very noisy, colloquially and info-theoretically) helped me make more out of mentor/mentee meetings and gain the trust of other technical leaders. Now I’m in the habit of considering the precision/scope of my language before saying anything.
  • Leverage narrative responsibly At some point in your career, you might ask your self, or be asked by someone else, to increase the scope of your work. Narrative becomes a really powerful tool to do this. Building a narrative is critical to aligning your team and stakeholders behind a single vision. The corollary to this is at some point the data will be inconclusive. Many times, the point where this happens is prioritization (e.g. it can be tough to quantify if the team should build a foundational project vs a new feature. You’ll end up comparing apples and oranges). I used to distrust narratives and the people that used them to push their case forward, almost as a blanket policy. Now, I recognize them as necessary/required to increase impact/scope at a company. Narratives get others excited to join in on your effort, and that’s critical to solving the really hard problems effectively and efficiently. The flip side of this is that the hypotheses that underlie the narratives can be wrong, and a strong narrative/narrative-builder will be questioned less, which can result in lots of bad things happening. In this situation, be intentional about testing the hypotheses so that you can trust that what you’re building is worth it.

A note on Trust and Equity in the Workplace

Trust is subjective and subject to the biases we all have. There’s a pattern throughout tech (and many other industries) of Underrepresented Minorities not being rewarded with equal opportunities as those who are relatively more privileged. Among other factors, the racism and sexism of those in power has driven this.

So, as I build my own trust models, I think it’s important to question myself and my own biases. To try my best to resist “feels trustworthy”, as this becomes a feedback loop for those I’ve been told I can trust (by society). And while I won’t advocate for going against one’s gut, I think understanding how we can build trust/evaluate performance in more objective, equitable ways, can help us form the right “gut”.