My dad is responsible for introducing me to technology and encouraging my love of building. He is a professor of management information systems. As a kid, I didn’t really understand what that meant—but I did know he had access to computers. One day, he brought one home and programmed a math game just for me. Every time I got a question right, it would say “Shaabaash!”, which is a Hindi exclamation for “Good job!” 

That early experience with technology exposed me not just to the final product, but the way it was built. I couldn’t believe my dad wrote this game, and then, just like that, I could practice math. And somehow it said shaabaash, just like my dad would say to me! It was the coolest thing in the world.  

As a fifth birthday present, my dad gave me a small red toolbox (that closely resembled his big silver one). There wasn’t much to do in our tiny apartment, but I did have a kids-size chair. Again and again, I would lock myself in the bathroom—with the toolbox—to take the chair apart and see what happened when I put them together the right way, or swapped the legs or directions. I wondered, Why do these fit the way they do? Why do some configurations still work and some don’t? 

That curiosity stayed with me in engineering magnet high school, where I got involved with the robotics team and competitions. It stimulated my love for building, but I found myself gravitating toward the overlooked areas. While everyone else worked on the robot, I was concerned about the fringes: What about documentation? How did we get sponsorships so we can go to extra competitions? How did we ensure other people are having a good time? 

From the beginning, I’ve been passionate about people having good experiences. Wherever I am, if I can create a culture where people are empowered to have fun and do their best work, that comes through in the project—and people on the other side experience that as well. 

Transition to tech, code and finding momentum

I graduated from MIT with a mechanical engineering degree with a concentration in energy, then became an energy consultant with clients all over the U.S. I would fly in on Monday and out on Thursday or Friday. At one point, I was on a special project that had me flying to 10 cities every two weeks. Even so, I wanted a faster pace of life, where I could see the impact of my work immediately. I got interested in startups and quickly realized one of the fastest avenues into that world was to join the tech side. I needed to program. 

There are a thousand ways to learn how to code, but it was hard for me, and I was slow to put myself out there. I got involved just as Massive Open Online Courses (MOOCs) became popular, and people advised me to “do the hardest thing.” I’d done some programming in school, but was trying to learn Scala from the beginning, and they taught the curriculum assuming we knew Java. I didn’t know Java. And I felt that frustration strongly.

Then I read a blog post about the process of learning, which gave advice to “follow your momentum.” I was trying to learn Java because I thought I had to, and this advice empowered me to drop what wasn’t working and try new paths until I found what worked. It was a huge turning point. Java just wasn’t for me. Pythonenabled me to write how I speak and think, so that’s where I started. Instead of forcing the path that was “supposed” to work, I embraced the one that felt more natural—and built a deeper, more intuitive knowledge base. 

I’ve been using this mantra ever since, especially when I face friction. If one area isn’t working, find another way to approach it. Follow your momentum. Your way won’t always be the same as everyone else’s. Drop what doesn’t work. Believe it or not, if it’s important, it will surface again.

Falling into a transformative leadership opportunity

Along my journey, I went to a Write/Speak/Code event and met founder Rebecca Miller-Webster. I shared my great experience at the event, and she mentioned they needed board members. I went to a board meeting thinking I’d get more information about the board, but everyone got straight to the future of Write/Speak/Code. I asked where I could learn about the board, and they said, “Oh, you’re on it.” 

I think that’s how a lot of opportunities work, especially in volunteer-led organizations. When you show a little bit of interest, you get as much mileage as you’re willing to put in. I initially put on a one-day workshop in San Francisco, and then I helped start a new chapter, and then I was in charge of all chapters. 

Prior to my arrival at Write/Speak/Code, there were a lot of undocumented processes and best practices, with no way to scale or systematize. But Rebecca noticed I was good at organizing information in a way that other people could easily leverage, and convinced me I could be good at this, and by translation, a good manager. Managing was something I always wanted to do, but I hadn’t previously gotten any encouragement to pursue it.

At a typical Write/Speak/Code conference, there’s a “write day” where you write your speaker bio, a “speak day” where you create and present a talk, and a “code day” where you commit to an open source project. On code day, we bring in open source maintainers so attendees can have a facilitator right there to help. By the end, no matter what level you come in at, you have the ability to do all three.

When I finally committed to my first open source project, it was actually at a San Francisco Write/Speak/Code “code day” event. Having held them for so many people, I decided it was finally time to see what it was like. I picked up an issue for CodeBuddies, and worked with Linda Peng, a phenomenal person who has helped countless people make their first contribution to open source codebases. I was so nervous, but Linda helped me find the right issue, draft and submit my first pull request. It’s nerve wracking to put yourself out there, figure out the norms, make sure you’re addressing the PR right, and put the right information in the body. Luckily for me, she was right there and merged it with me. 

Through this experience, I gained a better understanding for maintainer and contributor communication. It’s important to be transparent and explain the “why” behind your actions. Giving people a little bit more context takes a lot of empathy and time and can be exhausting. But it’s worth it.  

And if you don’t have the “spoons” for something—spoons being the mental energy or the emotional energy—you can tap out. Being able to rely on your other maintainers and core contributors, and knowing you can do the same for them, brings a sense of camaraderie to open source, and the community picks up on that. As long as you stay true to the values you want to bring, people see the continuity and appreciate the diversity in how people are able to work together. 

Bringing the positive to the front

Write/Speak/Code prioritizes the needs of marginalized genders, and a lot of the curriculum and materials are built by people who are mid- and high-level in their career. This is also true with those who attend; they usually have four to six years of experience. People kept telling us that we’d have to get more people with less experience if we wanted to target women and marginalized people, but we did not experience that, and I think that had to do with our approach.

Driven self-starters are always busy doing great things, which means they seldom get the chance to reflect and talk about themselves. Our workshops and events give them time and space to work on new concepts and reflect on how much they have to offer. We’ve even had advanced tracks to help people plan for their first book, podcast, zine, etc. 

Something the open source and nonprofit worlds have in common is that people are doing a lot of thankless labor. They’re joining a cause because they believe in it and want to give that access to other people. These volunteers are positively impacting so many people, but hear more about the things going wrong than the things going right. The bug count can really get to you, especially issues that are opened documenting bugs that might prevent someone from being able to work.

It’s so important to create a way to connect back to the positive impact people are experiencing, and pass that on to the volunteers. It’s hard in the open source world when you create all this work for a stadium of people and only see the negative. But we have to connect with people on a more individual basis and ensure they understand their impact. Otherwise they’re going to burn out.

Building a culture where everyone does their best work

I ask those new to open source how they best learned in the past—the source of their momentum. Once they understand that, they can find a parallel path in the open source community. If you love research, go find a repository that piques your interest and locate an issue with a `good-first-issue` label. When you have solved the issue, did the community respond in a supportive way? If so, you can feel confident you’ll have the same experience yourself. If you’re socially motivated, you can find a program that pairs you with a mentor, or drop into office hours in Slack. 

The generic advice I’ve gotten is just try it. I would say yes, try it—but find a way that works for you so that you gain confidence. It’s out there if you search for the right style. During months like Hacktoberfest, for example, there are more resources available, more events where people are open to answering questions. If that’s the motivation you need to try it out, do it! Find a way that’s going to give you the momentum you need.

When I try to pinpoint what success looks like, it’s always tied to a goal. What am I optimizing for? What will I make compromises for when I have to make a choice? Right now, I want the people on my team to be able to do their best work—to have a great time and grow in their career—so that they can translate that happiness and productivity into value for our users. But first, they have to tell me what that means for them. I’ll ask my reports and skip levels to share when they did their best work, and what that looked like. I’ll ask for feedback, and define what I can do more (or less) of.

We always talk about being obsessed with our users and understanding who they are and what experiences they’re having. Right now, my primary “users” include everyone around me: my reports, skip levels, team leads and any other teammates I work with. It’s so important not to judge what will make them better, but to stay open-minded about how I can set the stage for them to have the best experience possible.