Engineer to Engineer: Don’t Be Afraid to Rock the Boat

Left: Elizabeth Funk | Right: Samantha Abbot

In this edition of Engineer to Engineer, Elizabeth Funk, Director WWCode New York and a Software Engineer at Medium, sat down with Samantha Abbot, Senior Software Engineer at Braze to discuss self-advocacy, communicating with colleagues, and her experience in tech as a queer woman with a disability. 

It’s nice to meet you, Samantha. What got you interested in coding, and what inspired you to study computer science in college? 

Great meeting you, too, Elizabeth! My path to becoming an engineer started when I was around nine years old. Growing up in New Mexico, I wanted to be either a writer or a librarian. I was also really into Neopets and I decided that I wanted to make my own custom Neopets page. In order to do so, I taught myself HTML and some CSS.

My family is also full of engineers. My mother worked as an electronics technician, my father is a mechanical engineer, my grandfather was a computer scientist, my aunt is a computer engineer, and my little brother is graduating from college with a mechanical engineering degree. When I went off to college to pursue being a librarian, I took a web design course as an elective and I loved it! 

Soon after, I switched to computer engineering. When I told my mother that I was making the switch from English into engineering she was overjoyed. However, I knew the field wasn’t for me after taking a circuits class, but I found my way into computer science not long after and ended up graduating with my degree in that field. 

It’s awesome you have so many engineers in your family. I’m a software engineer, but that doesn’t stop my relatives from asking for help with hardware issues because they don’t understand the difference.

Luckily, my mom understands it because she's the electronics tech in the family. She's the one who always says, “Don't wrap your cables like that.” Between the two of us, we make one entire computer engineer. 

How did you rise through the ranks to become a senior software engineer, and what made you decide to move to New York City after living in New Mexico for most of your life?

One of my friends moved to New York City when we were 16 and I went out to visit for her birthday, which happened to be during New York Comic Con. I got to hang out in Manhattan and I absolutely loved the city! I knew from that moment that I was moving to New York.

Now, as far as how I become a senior software engineer, that one took a little while. I started out working as a web developer for this tiny company in Albuquerque and I eventually became a software engineer there.

A year or two later, I worked for a different company and thought to myself, “Hey, my front-end skills are just as good as all the other senior front-end people’s skills. I should be in a senior role.” Just as I was having those conversations with our leaders, management changed in a way that made the workplace untenable for me. I changed jobs and had to start convincing people I should be a senior engineer all over again. 

It was frustrating, but they finally promoted me to a senior title six months after starting. Ultimately, my journey required me to look around and realize I am just as adept as the other senior engineers and advocating for myself. 

I think a lot of people don't realize that they need to advocate for themselves and make a case for their deserved titles. Unfortunately, as long as a company is getting what they want from you as an employee, it's not necessarily on their radar. But it should be! 

I don't want to discount my previous direct manager. When I mentioned that I thought my title should be senior, he was incredibly helpful and supportive. I didn’t feel that immediate management wasn't paying attention to me, per se, but I did have to bring up my request and fight for it. 

It’s great to have managers who push for you. Were you nervous or anxious to advocate for yourself? I know some people are worried about rocking the boat.

Oh, definitely. It doesn't help that I have an anxiety disorder. I went home to my partner and shared my hesitations about it. My partner was extremely supportive and calmed me down a bit. 

I was worried about wording it correctly and making sure I didn’t come across as too aggressive. I didn’t want people to put any unjust stereotypes on me. I spent so long agonizing over it; it was not an easy thing to do. 

I completely understand. In Sheryl Sandberg's book, Lean In, she spoke about the fine line between advocating for yourself and seeming too demanding. You’re put in this situation of asking for what you want while making somebody feel comfortable and assured you’re still willing to collaborate with them. 

I find it really difficult when collaborating with certain men in engineering spaces. I have to be firm enough that they take my ideas seriously, but soft enough that they don't feel threatened by them. I sometimes have to work to ensure that they actually listen to me. It’s rarely necessary, but it does happen. 

There have been times when I had to be pushy. I always have data to support my opinion and demonstrate how it’s the best path forward, but I still needed to be soft enough that my colleagues were willing to listen. As you said, you want people to collaborate with you in the future. Unfortunately, women have to strike a strange balance. 

Outside of speaking to people of different genders, learning to pick your battles and frame things so people don’t take offense is good advice.

 

I’ve noticed that my English background helps me form an argument and communicate with more malleable language. Sometimes, I find myself weighing my words much more carefully than my male colleagues, and I spend more time thinking about how I'm going to argue for a particular architectural, coding, or process decision that I want to implement. 

I also spend a great deal of time thinking about how I can approach conversations to convince as many people as possible to be on my side, whereas some of the other engineers I've worked with don't think like that. They're just bulls in a china shop. That can work, but I tend to get more people on my side by massaging situations more. It’s certainly a double standard. 

I believe that getting buy-in is really important, and it’s an important managerial skill. It sounds like you may already be headed toward that next level. 

Eventually! I’m not currently considering it because I want to spend a few more years at the senior level and refine some of my skills before I start thinking too seriously about entering management. 

I do think buy-in is important, though. Even at a senior level, it’s good to recognize that you aren't effective if you’re always a bull in a china shop. Commanding junior and mid-level developers around you to do what you say isn’t effective. Teams need to be cohesive. 

I think there's a myth that if you’re a software engineer, you sit in a closet all day coding in front of a computer. The reality is that you're part of a team working with product managers, designers, and other engineers. Getting everyone’s work to align is almost as important as writing the code.

As a senior engineer, it's expected of me to develop junior and mid-level team members’ skills. I have to be able to talk to the people on my team and mentor them. Sitting in a closet coding all day and not paying attention to what's going on around me isn’t an option. 

You need to be able to elevate people around you and convince others that your architecture, code, and process decisions benefit the company as a whole. You need to be capable of bringing people together to execute your plans, otherwise, you won't accomplish anything. 

You’ve mentioned architecture and process decisions a few times. Did you ever ask for more responsibility?

I’ve always been a little assertive, so I don’t request more responsibility — I ask to work on projects I find interesting or that I don’t know much about. For example, we were developing a project in React that required using Suspense. I’d never used Suspense before, so I joined the project to try using it. Working on projects to learn a particular skill has helped me grow significantly. 

That’s interesting. I'm very type A and I like everything to be perfect, so I feel anxious when I take on a project that has parts I don't know everything about. Do you ever feel anxious, and if so, how do you manage the stress? 

I certainly do. Testing something new always makes me a bit anxious — can I figure out the problem in the time we have? 

If it's something I'm really worried about, then I'll do a personal project and work with the program or software beforehand. I'll conduct research and look at documentation. If I still don't feel like I understand it, I read the source code. I read React’s source code probably once every other month. It’s a great way to learn how stuff actually works under the hood.

That's great advice for becoming a subject matter expert. On a different note, are you proud of any recent accomplishments you want to share?

This sounds small, but I was working on a project with a bug where the Select rendered over a pop-up. If you had a Select on the base page and you opened a modal with the Select also open, the Select menu would show over the pop-over. 

It was so frustrating. I didn’t want every developer who's touching this Select to have to manually put in the Z index for the menu. To fix it, I did something that I thought was very clever: I set up context that holds the Z index of the highest currently open pop-over. The Select, if there, then consumes that context if it exists. So, if that context exists, it takes the Z index and it adds to it so that it shows above the pop-over. The person using the Select and the modal doesn't have to touch anything — it just works!

I fixed that bug so other engineers would not have to put in the index every time. I thought it was a pretty clever solution and I was proud of it. 

I think it's really cool, too! Job descriptions often say things like, “write maintainable code,” and this is exactly what they're talking about. 

I find your courage to dive into problems and fix them inspiring. A previous boss once told me software engineers are problem solvers. However, I sometimes feel pressured to work quickly and not focus on the best possible solution. Did you feel any pressure to fix something as quickly as possible just to say it's done?

My current job at Braze is particularly good about that sort of thing. If I feel I need to take extra time working on something to optimize it, then I have the space to do that. I’ve been in workplaces where there was tremendous pressure to get stuff out by a deadline, even if it wasn’t ideal. 

My formula for deciding what I can let go of and what I need to give my managers pushback about is based on whether I go to bed at night thinking about it. If a problem pokes at my mind like a rock in my shoe, then I know I need to confront my managers about addressing it properly.

It's a balancing act, though. You do have to get stuff out eventually and your code will never be 100% perfect. You need to get it at least 95% there and then ship it.

Have you learned any good strategies to effectively communicate the importance of those kinds of tasks? 

If I know there will be pushback, I'll sit down beforehand and write an outline that lays out what the problem is, what I want to do, why it's important from an engineering perspective. 

I break the outline down by what the solution impacts and, most importantly, how it affects the company’s bottom line. For example, I’ll explain that the problem makes the engineers take longer, which costs more money. How is it affecting our customers? The pages are slower, and if pages are slow, it makes the company look less professional and it’s harder to maintain customers. 

Product managers and business people understand that language pretty well. If they come back and they tell me they still want to move forward before we can polish, then I know I did the best I could to argue my opinion. I’ll work on it in the margins when I have free time. 

I love that you said you sit down, write out your thoughts, and speak to various stakeholders. That's also part of being a software engineer — thinking and planning ahead. 

Switching gears, I think many of us worry about how our differences could impact our experience. Before our conversation, you let me know that you identify as a queer woman who is hard of hearing. I’m interested to know how that has affected you interviewing for jobs, feeling comfortable in your workplace, and what accommodations you may have needed?

I'm lucky in multiple ways. I am hard of hearing, but my hearing loss isn't extreme. I miss syllables sometimes, but growing up I learned how to fill those in. I don't need an interpreter or captions when I interview, but I might ask people to repeat themselves sometimes. 

Otherwise, I don’t have to ask for many accommodations. Braze has been remote since I started, so we work primarily through Google Meet, which is advantageous because I can turn on auto-captioning during meetings. It's pretty easy for me to find little accommodations that fill the gaps I missed. 

As far as being a queer woman, my queerness is around my sexuality. I'm attracted to mostly women and nonbinary people, but the occasional dude as well. It’s pretty difficult, actually. When I first went in to interview at my current company, I pretended I was straight. I specifically talked about my husband and did not reference the fact that I was queer at all. I definitely felt pressure and anxiety when interviewing. 

When I got hired, people made a concerted effort to make me feel comfortable. I was working with other queer and LGBTQIA+ people and it just became really easy for me to be like, “Yeah, I'm a queer woman!” People were totally chill with it, so I got really lucky. 

I imagine you're worried about how people will perceive you and how it could impact your chances of being employed. 

To wrap up, I want to ask if you feel like you’ve been able to use your different perspectives to really help make a product better for one of your employers?

As a front-end developer, my work doesn't really lend itself to video or audio, so I rarely experience being hard of hearing as an accessibility issue. 

However, when I’m working on projects, I do tend to think seriously about other accessibility issues, such as vision impairment. I'll turn on the color-blindness imitation software to make sure that the colors look okay. If they don't, I’ll go to our designer and collaborate to ensure we’re considerate of color-blindness and that it’s as screen-readable as possible. It's something I try to do because I know from what it's like not to have access to something from personal experience. 

As for being a queer woman, I feel I'm able to get buy-in more easily than some of my peers can, partly because I've been socially trained as a woman and as a queer woman to get people to listen to me. That's something I had to learn how to do from a pretty young age. Ultimately, getting people all on the same page is something that helps me improve the product.