Crafting Space to Be Ourselves20 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.”
As a senior engineer or a technical team lead, it's perfectly okay to say "I don't know, let's research this together."— Celestine Omin (@cyberomin) October 3, 2017
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”.
“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.
Wish they had avoided “ownership” as the primary metaphor. Otherwise many thumbs up.— Matthew Bischoff (@mb) July 8, 2017
Steward, maintainer, yeah— Matthew Bischoff (@mb) July 8, 2017
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:
The best definition of "senior engineer" I've ever heard pic.twitter.com/ewN7yz1xtn— Jasdev Singh (@jasdev) June 1, 2017
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.
Gonna start approving all code reviews at Peloton with cycling emojis pic.twitter.com/ZlAqjpdiPS— Jasdev Singh (@jasdev) April 5, 2017
My favorite type of comment pic.twitter.com/v348yz9oyd— Jasdev Singh (@jasdev) July 6, 2017
realtalk: we decided to call it appperson at work bc inclusivity— laura (@eleichsea) July 7, 2017
brb doing the same— Jasdev Singh (@jasdev) July 7, 2017
Nixed all instances of it I could (in our source), thanks for mentioning this <3 pic.twitter.com/hINAEDZRe0— Jasdev Singh (@jasdev) July 7, 2017
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 ✨
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.”
Related Links and Footnotes:
⇒ I was lucky enough to attend the Recurse Center back in the fall of 2015. Many of the techniques mentioned in this essay are second-order effects of their fantastic social rules. These carefully selected rules make RC an escape from the often-imperfect tech industry.