Building an Engineering Culture of Sharing and Learning

Over the past few years, the Vox Product Revenue engineering team has been actively trying to build a culture of knowledge sharing and collaboration. If you’ve ever worked on teams, you’ll understand that a team that collaborates well and encourages asking questions is never an accident. It takes work, it takes trust, and it takes time. My team is not perfect; some people have felt more supported and safe than others, so we’re going to keep working on that. But in the past few weeks, I realized that we’ve found some things that really work for us. This post is an attempt to document them in case they help your team.

I think this topic is pressing on my mind because of recent conversations happening in tech spheres. Misguided people have raised questions of who belongs in tech, and while I am not addressing that directly here, a question I have asked myself in the subsequent weeks is how do we work to build a culture that actively fights these structural issues? The things I mention below are not a comprehensive answer, but I think they are helpful in moving us toward the goal. Underlying everything we have been doing is a central belief that every team member is critical to the team, and the easier we make it to share knowledge, the more we can all work together.

Here are some things we’ve tried and why I think they are working for us.

Senior team members own what they don’t know

This is a personal principle for me: the more experience I gain, the more I have a responsibility to make it clear what I am still learning. Senior team members do a lot in setting tone for how safe others feel in asking questions they feel are dumb or will expose potentially embarrassing gaps in knowledge. It’s one thing to state “all questions are ok!” and it’s an entirely different thing to establish a cultural model of explicitly stating when you don’t know things.

The first benefit of this is it invites coworkers of all levels to feel safer in contributing to the conversation. Perhaps a more junior employee recently read something that feels relevant. If your team dynamics prioritize owning what you do and don’t know, they will be less worried about joining in the conversation and adding their ideas. If your senior team members are only seen having things figured out, the social pressure is the opposite: adding anything to the conversation that is not an accurate solution risks embarrassment. The other benefit is much more psychological: if senior team members are regularly seen admitting they don’t know things and calling out things they learn from more junior member’s work then the team culture has the opportunity to be a safe space for learning, questioning, and sharing.

The teams I work on are so good at this and it delights me so much. We regularly call out things we didn’t know, and we regularly start debugging things or building things by confessing we have no idea what we’re doing. This practice makes it safe to laugh at our follies as we rage against computers, safe to ask for help, and strengthens our abilities to learn together.

Document the journey to solutions, not just the solution

So much of programming is swearing at computers because they are not doing what you are pretty sure they are supposed to be doing. So much of learning to be a better programmer is understanding all the things that could be going wrong and finding the best strategies for narrowing down what exactly is the current issue. Your coworkers may know more strategies than you or they may not know the ones you know. Working together to document the fun struggles of getting computers to do what you want them to do helps everyone build a more robust toolset for doing their jobs.

Recently my coworker Becca has been diving into a particularly, um, legacy part of an app our team owns. Her ultimate goal is to make the code much simpler while also adding a couple needed features. As she worked to understand what needed to be refactored, she started writing the story of the data this code handled. As she would dig through all the steps and build her narrative (it’s really quite gripping), she would share in Slack to confirm that what she was finding is what others who had previously worked on it understood to be happening. The story of this data may never find its way into a bookstore, but by going through the effort of capturing it and writing it in an enjoyable form, the entire team has benefitted from her work.

In the case of Becca’s document, there are exciting headings like “Files with a mention but I am pretty sure they are not being used/ do not need to change for various reasons” and “Things I’ve Axed, Why I Axed Them, and Where You Can Find Them Now in the New World of Trackers.” But you don’t have to do this in such creative ways. Sometimes a helpful way to document the journey is to embrace rubber-duck debugging but do it in public forums. We have a dedicated revenue engineering channel now (more on this below) and encourage team members to work through questions in it rather than DMs so that anyone on the team can learn from the process or chip in to help.

Create defined spaces for topical chatter

The teams I work on are very chatty in Slack, but a couple months ago, I noticed only rarely were the conversations specifically engineering-based. I had a feeling we were diverting a lot of code-specific conversations to DMs out of respect for the diverse set of people in the main team channels, so I spun up an engineering-specific conversation channel and opened it up to anyone that wanted in. The results surprised all of us! Lots of conversations that either were happening in DMs or were not happening at all have resulted.

We use the channel to confirm our understanding of code we’re working on, to solicit help debugging things, to clarify why choices were made previously, and to discuss the merits of various options for solving problems. Having these conversations in a public channel means everyone benefits. The Revenue teams at Vox own a lot of code, and it can be hard for any one engineer to keep on top of things. This channel has made it much easier for us to passively be exposed to the various projects and issues that every engineer is working on, thus making it easier to know who has relevant knowledge or might be most capable at fixing a bug that pops up.

Schedule time for team code walkthroughs

My manager Brian started this on our team a few months ago and we’ve found it to be really helpful. He scheduled an recurring meeting every other Friday named “Revenue Code Fridays.” These meetings are open to anyone on Vox Product who wants to join but are specifically designed to help engineers on revenue get exposed to new or important aspects of our codebase. The format is loose: someone who has recently rolled out a PR of interest will take 30 minutes or so to walk through what the code does, explain their thoughts and rationale for decisions, and give context for how it fits into the rest of the app. After that, everyone can ask questions to fill in any gaps they may have. We record these meetings (because they happen as a remote-friendly video call) and archive them, too, in case someone in the future wants a quick deep dive.

There are so many other things I could highlight in this post. Vox Product has a strong culture of writing thorough pull requests when introducing new features, which means there’s often a lot of context around code. We’re working hard to refactor our culture to be more documentation based (certain teams have definitely led the way in this). Good documentation helps move institutional knowledge from people’s heads to artifacts that others can access as needed whether or not the person is around.

Our team’s culture is ever-evolving. We grow and reorganize and hire new people all the time which changes the group dynamic. We’ll have periods of tighter deadlines which increases stress and periods of maintenance work which feels more open-ended and less stressful. These are all things that affect the day-to-day of working on the team. I know for me personally, the things listed above have had a measurable impact on how much I enjoy my job. But I’m also aware that other people on the team have not connected with these experiments as much. Which means all of these things are a work in progress, and we’ll continue to listen and try new ideas. Ultimately the goal is creating an environment where learning is constant, “I don’t know” is a fine starting point, and asking for help is a natural reaction for everyone on the team.

What kinds of things have you found are helpful in creating a similar environment on your teams?

I’d be remiss to point out that if you want to help us improve this culture by adding your presence to it, there are quite a few positions open on Revenue Products!