Engineering a culture of fluidity and learning at Nextdoor

For me, part of the allure of small companies and startups has always been that the delta between what they are today and what they can become tomorrow is often very large. Bridging this delta is where the risks, inherent challenges, and rewards all ultimately lie. Teams need to be able to adapt quickly and often as the organization grows, product requirements change, resources fluctuate and different types of expertise are suddenly needed. At Nextdoor, we’ve recognized that deliberately supporting a culture of continuous learning and organizational fluidity enables us to adapt and move faster. We think it’s better for the company as a whole but also better for our people at an individual level. From the way we’ve organized our Engineering teams to the support systems and processes we’ve put in place for people to grow: these all contribute to the type of culture we want to encourage.

Organized by product, not platform

How an organization is structured can have a profound effect on fluidity. It can influence how often people move around an organization and their comfort working outside of their comfort zone. At Nextdoor, we like to think of our organization and various sub-teams as being “loosely coupled, yet strongly aligned”. There’s no single “iOS Team” or “Android Team” or “Web Team” but rather, there are Engineers with various skillsets that work on particular products together.

If I’m an engineer who works on Nextdoor for Public Agenices, for example, then I’d sit in a pod with everyone who was working on that project (from Marketing to Engineering and everything in between). I might primarily be working on the iOS component of that product, but I can also jump in and do some Web tasks or help design the APIs — whatever helps push the project forward. This prevents our engineers from thinking they are an “iOS Engineer” or an “Infrastructure Engineer”. It allows for fluidity of roles and encourages people to look to contribute wherever they can rather than only in one area.

There are other great companies that we respect that do something similar. Spotify comes to mind with their detailed description of their engineering culture. So does Dropbox, which started off with more rigid roles and then had to blow that notion up in order to scale their team. Here’s an excerpt from a Fast Company article on why they thought that was necessary:

Up until about a year ago, Dropbox organized itself based on platforms, with an infrastructure team, a web team, an iOS team, an Android team and a desktop client team. After coming up with a product roadmap, each team focused on the product work for its own platform.

“We ran into the problem that you’d anticipate,” Agarwal says in hindsight. “We didn’t have enough cross-platform coordination, and there was a reluctance for engineers to expand outside of their core expertise. We had to blow that up.”

“The key was to essentially break that model, where somebody thought that they could only work on one particular platform,” says Agarwal. “This was painful, but we had to pay that learning cost.”

Support systems for learning

We’ve found that deliberately supporting our employees’ interests and curiosity is one of the best ways to grow our team and cultivate in-house expertise. It’s not some crazy or unique notion that we’ve stumbled upon, but being deliberate and recognizing that there are ways to accelerate and encourage the process is important.

I’ve always been a huge Apple enthusiast, so it was natural for me to eventually want to contribute to Nextdoor’s iOS app (which is awesome by the way, you should go download it!). However, I’d never even opened Xcode before or written a line of Objective-C, so there were a lot of things I needed to learn. Having a dedicated mentor, pair programming early and where it made sense, and deliberate managerial support were all essential catalysts and sources of support for me as I jumped into iOS.

People supporting you from day one

Managerial support is important because it sets the tone for the engineering culture from the top down. Having support from both your direct manager and your team throughout the process is invaluable; after all, you’ll definitely move slower when picking up something completely unfamiliar, and that’s to be expected and accounted for by everyone. Perhaps deadlines need to be moved or you need to switch teams to work on a different part of the product where you can be more experimental with your learning. Whatever it is, having an environment around you that can adapt to your “active learning state” is necessary.

When I first started learning iOS, my manager came to me and gave me a bunch of resources that he felt would help my learning. He offered to let me expense any books or course material that would help me learn faster or more efficiently. In addition, both he and my team offered to give me some space in our sprints so that I had the opportunity to slow down and learn the fundamentals.

Having this breathing space was vital in the long run. I was able to better understand the things I was doing rather than trying to keep up my usual pace by taking shortcuts. Counterintuitively, going slower in the beginning ensured that I can be faster in the long run. Having a healthy understanding of when it’s okay to go slow and steady is a key piece of any engineering culture.

Mentorship not an afterthought

Direct and available mentorship is another important piece of the puzzle. At Nextdoor, we enable this by pairing engineers learning a new platform with someone who already has deep expertise on that platform. These pairs will sit next to each other and the mentor is the go-to person for any questions that the mentee has. If they’re on different teams, it’s no problem — one of them can switch teams for a while.

It’s also understood by everyone on the team that the mentor will be spending time outside of their core responsibilities to help the other engineer. This understanding is necessary because it exemplifies the “available” part of “direct and available.” If this mutual understanding isn’t created, the mentorship is treated (however unintentional it may be) as an afterthought and the mentor will be too swamped with “real work” to take the mentorship seriously enough.

Matt Johnson, a senior engineer at Nextdoor, was my mentor. Because he’d been working on iOS at Nextdoor for a while, I was not only able to learn the fundamentals of iOS from him but also about “The Nextdoor Way” of doing iOS. I also received a ton of support from the entire group of other iOS Engineers when I needed it, which was truly invaluable. I started going to the iOS “Share Your Knowledge” meetings and standups and exposing myself to their way of working. They welcomed me with open arms, but when they were too busy or swamped to help, Matt was always working right next to me to help me solve problems.

Two is better than one

A quite underappreciated and often overlooked way to quickly ramp up in a new environment is through pair programming. There are many other benefits to pair programming — in fact, there are entire books dedicated to the topic — but for now we’ll focus on how pairing helps us ramp up on and learn new systems quickly.

There are many misconceptions out there about what pair programming actually is. At Nextdoor, we like the setup where two engineers share a desk and have two monitors (mirrored, of course) with two keyboards, and two mice. When working on a sizable chunk of work, there’ll be an ongoing discussion among the pair about best practices, tools, and engineering design. The process of engineering becomes a continuous dialog between the pair with one person “driving” (controlling the computer) and translating the dialog into code while the other focuses a bit more on the problem at hand and can think slightly ahead so no time is wasted. The feedback loops are very fast, and this is what enables a higher rate of learning.

I had the opportunity to pair with Sean McQueen (another one of our wonderful Engineers) for a couple of weeks. This was when I wasn’t totally new to iOS, but it was clear that I still had some fundamentals to cover. Sean had been doing iOS for quite some time at Nextdoor, but he too went through the process of learning the platform from scratch since he initially started out doing Infrastructure work. During my time pairing with him, I was able to pick up some productivity tips from his workflow as well as general iOS design patterns and principles that I wasn’t totally comfortable with yet.

It’s always interesting watching someone else work because we’re so used to our own ways of doing things that it’s easy to work in that silo without knowing if there’s a better way of doing things. It’s always a tradeoff between seeking to improve our processes for the long term and getting work done in the short term. With pairing, I was able to accomplish both. It’s also important to point out that this isn’t a one sided process. From Sean’s perspective, he was able to see how I approached certain problems or how I used certain tools and it ended up that we both learned from each other even though he was the more experienced iOS Engineer.

Parting thoughts

Though I’ve been at Nextdoor for only a year and a half, I’ve been fortunate to have worked on a range of teams/projects encompassing infrastructure, frontend, growth, and mobile, the latter being where I spend the majority of my time these days. I joined Nextdoor right out of college (UT-Austin, hook em’ horns!), and I’ve found that having an organizational culture that explicitly emphasizes learning and fluidity is very valuable, especially early on in one’s career. It helps me achieve a breadth of experience, which becomes an important guiding light when I decide to achieve depth.

Many people through college and even at the beginning of their career don’t necessarily have a good idea of what they want to achieve depth in over the course of their career. How should they? Internships are short and only offer a glimpse into real work. College itself certainly doesn’t help cultivate the right kind of experience to obtain this insight. I’ve interviewed a lot of new grads during my time here and this sentiment rings true for many of them. Unfortunately, if you’re too siloed into a role early on, then it’s easy to get get trapped into that role for a defining chunk of your career. Even more experienced engineers can experience these effects, so it becomes important to work in an environment which values learning and encourages fluid roles.

If the Nextdoor environment sounds like something you’re interested in being a part of, we’re hiring across the board for Engineering and Product!

Vivek Karuturi, Engineer

Follow me on Twitter: @Vivekxk

Follow me on Email: vivek@nextdoor.com