My name is Zoe Sobin. I’ve worked at HubSpot for over six years now. First as an intern, then a full time engineer, then a tech lead and now an engineering lead. I’m also a woman in tech! And as a woman in tech, there have been many times throughout my career where interactions and experiences I’ve had made me feel like I don’t belong. Through my own personal experiences and spending time mentoring and talking to newcomers in the industry and at HubSpot, I’ve developed some opinions on changes we can make to help software engineering become a more inclusive environment.
I cannot speak for everyone, especially for people who identify as BIPOC or are members of marginalized groups, but I want to use my limited experiences and my position of power as a growing leader to try to shine a light on areas where we as engineers can go about our jobs in a way that fosters an environment where everyone feels like they belong.
Why does coding with inclusivity matter?
We’ve learned from countless studies that diverse teams outperform homogeneous teams. We’ve also learned that psychological safety is the most important factor in defining a high-performing team. The tricky part of this is that creating psychological safety for a diverse group of people requires much more thought than it does for a team where everyone shares the same skin color, gender, and background.
You may have had really wonderful experiences at your job where although you felt challenged, you felt comfortable stretching yourself and taking risks. You found people like you or people who went out of their way to make you feel comfortable and at ease. Not everyone has that experience. As we hire more people who add value to our teams, in addition to, and often because of, a diversity of thought and experience, we need to spend more time and energy on ensuring that they have the inclusive environment and support that they need to truly flourish.
So what is HubSpot doing about it?
In addition to creating content that highlights a diverse array of voices and backgrounds, and running programs and ERGs to support growth and psychological safety for all of our HubSpotters, we have a number of manager-specific measures in place. To start:
- Anti-racism trainings
- Psychological safety trainings
- Role requirements that include fostering an inclusive team + commitments to DI&B
This kind of operationalized accountability is TABLE STAKES and its importance is not to be undermined. I can’t stress enough how critical these measures are. But accountability doesn’t end with managers.
A true sense of inclusion and belonging also comes from the people you work and interact with throughout every day.
When I was a brand new software engineer and my confidence in myself was the lowest, the most impactful thing was finding the right people to support me. The people who would go out of their way to make me feel comfortable and like a valued member of the team. As I got PR reviews, sat in team meetings, ate at the lunch table, they were the ones who helped me feel like I truly belonged.
So with that in mind, I want to call out a few ways that you all can strive to be that person for the people on your teams.
1. Fully internalize that there are no dumb questions *
We want people to feel safe asking questions anywhere to anyone at HubSpot. While I could say this with a wink and whisper “well, don’t openly judge bad questions,” what really needs to happen is that you actually need to believe deep down inside of yourself that there are no dumb questions. You need to have empathy for where a person is in their career and truly believe that they are on a journey to becoming a strong, autonomous engineer. Only then will you actually go about your work in a way that doesn’t send the wrong message. Here are some ways you can make sure that you’re sending the right one:
- When you are about to respond to a question that you think should have been obvious, SLOW DOWN. Be thoughtful and empathetic.
- If you are feeling heavily burdened by answering too many slack questions or reviewing too many PRs, don’t put that on the person asking the question by answering in a way that is sloppy/curt/harsh. Ask for help.
- Ask your own questions in public channels to set an example that even if you’re experienced and comfortable you still need help.
- Be careful about accidentally sending hostile signals, like piling a ton of upvotes on a correct answer in Slack. A few will send the message without also signaling “isn’t it obvious.”
* Although there are no dumb questions, it’s important to call out that asking really good questions is an incredibly important skill to develop as an engineer and is really helpful for the people trying to answer your questions. There are great resources out there, from straightforward tips on how to improve your question-asking skills to more specific takes, like the 15-minute rule. Never heard of it? It’s worth a read.
2. Look at PR reviews as a chance to build people up, not knock them down
Before you light up a PR with 1000 comments, take a step back. Without an empathetic approach, that can quickly make someone feel really demoralized and demotivated. The most important question to ask yourself — do you have enough trust built with this person to deliver effective feedback in this way? Here are some more PR review tips:
- Sometimes a better approach is to summarize the feedback and remove yourself from the literal code. This is a great strategy for teaching a lesson rather than correcting a mistake.
- Tone can easily be lost over asynchronous messages. Don’t be afraid to chat through your feedback in person or over Zoom.
- Knowledge-share if you see gaps — I like to joke that at a fast growing company like HubSpot, we are just as much in the business of growing engineers as we are writing code.
- Avoid projecting your opinion as fact. This can be really stifling or demoralizing, especially when someone is new and they might not have enough context to know what is fact vs opinion. When you find yourself coming in strong with an opinion, make sure to look for the gray area and highlight that. Instead of saying “X is the right way to do this”, try “Here are some other things you should consider with your approach” or if you are really getting into minutiae about things that are super subjective, consider if it’s even worth bringing up.
- Vocalize positive feedback!! I can’t stress this enough!!!
3. Avoid ‘assume best intent’
Candidly, I think that this saying can be helpful in the context of actual work. Such as when you’re reviewing a PR that is all over the place and you start to think ‘Did this person even try?!’ You should always assume that the writer is trying their best and approach their work product accordingly, with patience and empathy.
When you get into the realm of interpersonal exchanges or emotional impacts, though, it gets a lot messier. Why? Instructing people to assume best intent minimizes their feelings and devalues their perceptions and reactions. This is especially harmful for people in marginalized groups.
Where I see this come up a lot is the matter of tone. Tone is hard to convey through text, it really is. That isn’t an excuse, though. What that means is that you need to work that much harder to make sure your words land how you intend them to. When someone provides you with feedback either for yourself or someone else and you find yourself leaning toward saying ‘assume best intent’, remember that intention matters less than how it made them feel. Own that impact and work to make adjustments.
I am a privileged white woman so take this with a grain of salt, but here’s a personal anecdote to try to highlight this more clearly. When I first started working professionally, nothing made me feel worse than getting my PRs blown up with tons of really curt comments. When I brought it up, I was encouraged to assume best intent in those people — that they were just trying to help. I’m absolutely certain that there were no bad intentions, but I walked away feeling like it didn’t matter how it was making me feel, and I needed to get over it and make it work. My feelings and the impact of the unwanted behaviors weren’t centered in that conversation — the intent of the other people and justifying their behaviors were. What did that teach me about the next issue that might arise?
Don’t forget — society primes us to assume best intent from those in power.
4. Extend your comfort to the people around you
If you are feeling socially and professionally secure, you should feel an obligation to make people feel welcomed to your team. Be intentional about it. Schedule 1:1s, hangouts, etc. If you are starting a project with someone you’ve never worked with, go out of your way to set up a Zoom introduction. These small gestures can create a world of difference. All this holds even more true when someone is new. The first two months or so are what will tell them whether they made the right choice in trusting us as teammates and whether this is the place to grow their career. Here are some other ways to extend your comfort to those around you:
- Be vulnerable about your own feelings and experiences in order to create space for others to be, as well. Share your stories and struggles and make space for others to do so, too.
- Be free and liberated with your questions and your curiosity. Take your questions back to basics and ask them in public channels. In essence, do whatever the opposite of “flexing” is. :)
- Use your position of comfort and power to hold others accountable to coding with inclusivity, too. This means providing real-time feedback to those you work with. Make sure to use the well-documented SBI model for providing feedback.
These are just a few thoughts on how to go about your job as a software engineer in a more inclusive way. It’s by no means a complete list. The challenging thing about this stuff is that there is no one right answer and there are no shortcuts. We’re never done building an inclusive workplace and we are all responsible for doing so in every interaction we have. Every single person at your company plays a part in helping it become a place where anyone can grow and flourish.