Distillations About

Crafting space to be ourselves

20 Oct 2017

My all-time favorite quote from Rainer Maria Rilke is

“Where I create, there I am true.”

I certainly feel this way about writing. Committing thoughts to prose is easily one of the most vulnerable and rewarding things I do1. Moreover, hammering away at my keyboard on idle Saturdays gives me space to be my true self.

In a similar vein, I’ve been supporting two junior engineers on my team, which got me thinking about creating spaces that harbor psychological safety. As one of the more senior engineers in the group, the onus is on me to make sure teammates can comfortably pose questions, ask for help, be their true selves, and feel welcome. Below are a few ways I try to accomplish this, capping off two small details I’ve found valuable during interviews and one-on-ones.

Not Being Afraid to Say “I Don’t Know“

While interning, a reassuring statement to hear from my mentor was “I don’t know.” It reminded me that we’re all human and a competitive advantage for knowledge workers isn’t what you know internally, but rather the ability to sift through the noise in finding an answer. I’ve tried to do the same for my mentees2. A good suffix to this phrase is “let’s research this together.”

Collective Code Ownership

Sarah Mei wrote a great thread on our industry’s tendency to conflate code authorship and ownership (and ultimately responsibility). That is, if person X wrote the code that caused a production issue, the (internal) limelight is often placed on X instead of their larger team (in the absence of sound company values). Doing so is a failure to realize that “most non-trivial issues come from a confluence of problems and usually are driven by misunderstandings at multiple points in the process.” A way to mitigate this is being explicit about collective ownership. Just because X shows up in git blame doesn’t mean the “blame”3 is on them. To reinforce a sense of group ownership, I’ve made it a point to prefix code review comments with “let’s”.

An example of a GitHub code review comment that uses “let’s”

An example of a GitHub code review comment that uses “let’s”

An example of a GitHub code review comment that uses “let’s”

“Let’s” is an acknowledgement that although I’m not committing the code under review, we’re crafting it together and should treat any downstream fallouts as such. Scoping out, this might hint at the unfortunate power of the phrase “ownership” and connotation of git blame. I don’t seem to be the only one who feels this way.

Asking Questions Publicly

I err on the side of asking questions in public channels, as opposed to direct messages. This normalizes asking for help, regardless of seniority. In addition, it allows knowledge to be open and easily sharable for others.

Being Transparent About Goofiness

This is one of the best definitions of a senior engineer I’ve heard:

Just because we’re surrounded by skilled colleagues, doesn’t mean we have to appear “with it” all the time. It’s alright to be open about the embarrassing moments. We’re all making it up as we go. However, this doesn’t imply an obligation to be “goofy,“ which might be natural for some, but forced for others. Everyone has their own way of recharging after periods of intense focus which should be acknowledged, not prescribed.

Accounting for Future Teammates

At Peloton, we started having our client teams—iOS and Core Android—review OpenAPI docs, prior to server-side implementation. During these reviews, I’ve often found myself pushing to have the team write down our assumptions, avoid temporary (internal) codenames, or other hurdles that would make on-boarding difficult for future teammates. While the three engineers on the initial iOS team identify as male (we’ve since benefited from hiring more teammates of other genders), I’ve made nuanced efforts to ensure our culture and code are welcoming to everyone by default.

(Note: Appboy is an external SDK that we use in the app, which necessitated a thin veneer of types in our codebase. The company recently announced a re-brand.)

Interview Development Environments

A seemingly unquestioned aspect of our industry’s default interview style is the use of online editors (e.g. CoderPad and HackerRank). This never made sense to me. I spend all of my development hours in carefully configured IDEs and toolchains. Why should I expect candidates—who likely do the same—to feel comfortable in a minimal text editor they rarely use? To break down this mismatch, I rely on screen sharing. Doing so allows the potential hire to be in an environment they’re familiar with, so we can focus on letting them shine ✨

Walking One-on-Ones

A cue I’ve picked up from a couple of my mentors is the walking one-on-one. Being adjacent to, instead of directly facing one another is subtle reminder that mentoring and management dynamics are bidirectional, not top-down. Additionally, walking outside—often in pursuit of coffee, tea, or juice (for the decaf folks)—is a refreshing retreat from open offices and glass-walled conference rooms.

It’s important to remember that one-on-one’s are the (mentee|direct report)’s time and letting them drive the conversation. If the (mentor|manager) has anything to bring up, it should be deferred until after the former has had the opportunity to address anything on their end.

A long-term goal of mine is to make the world better through people. Crafting spaces for my teams to be their true selves has helped here, as the caliber of output when our work and personal-selves align is incredible. Here’s to turning “where I create, there I am true” into “where we create, we are true.”

Special thanks to Kate, Paul, and Julian for reading early drafts of this entry and to Ryan for motivating me to write about this topic.

⇒ I was lucky enough to attend the Recurse Center back in the fall of 2015. Many of the techniques mentioned in this entry are second-order effects of their fantastic social rules. These carefully selected rules make RC an escape from the often-imperfect tech industry.

Poster with the following contents: “Social Rules: No Feigning Surprise, No Well-Actually’s, No Backseat Driving, No Subtle -isms”. Below the poster are signs that read “Help me!” and “BUSY, but I still love you <3”

  1. Shout-out to Jacob for this phrasing in the context of building Bootstrap. ↩

  2. I use “mentor” and “mentee” in this entry in a bidirectional manner. Knowledge transfer isn’t exclusively top-down, it’s probably more like a graph. ↩

  3. Handling retrospectives on production issues with care is crucial. Etsy does this extremely well with “Blameless Postmortems.” ↩

Distillations is maintained by Jasdev Singh. To get notified about new entries, subscribe via RSS.