Views in this post are solely my own, and do not represent any current or past employers.
I started writing this post about 2 years ago and could never get the inner strength to just go ahead and post it. I kept editing it to add new life experiences and learned lessons, and today I feel ready to post it.
This post is geared towards Software engineering in the US, and the suggestions here applies to anyone who is “different” trying to make it as an individual contributor software engineer. I define “different” to be characteristics like:
- a minority race or gender in the tech industry
- a nontraditional entry into computer science (no CS degree)
- CS degree, but going to a school that isn’t necessarily a top school.
- Growing up in another country with a very different education system and culture
- Not having a good network of people who can give you professional advice/mentorship
There are 10+ years of lessons in this post so it’s quite long. I am sharing this because these are all lessons I’ve had to learn, after making mistakes over the years. There might be information in here that applies to non URMs(Under Represented Minority) too, but my perspective primarily is as an URM.
Am I even an URM (under represented minority)?
I went back and forth on this. One one hand, Indians are aplenty in the tech industry. We often get accused of “taking American tech jobs”. On the other hand, there is a subset of things in my life experience being in the tech industry that made me reconsider. I had my daughter at a relatively young age while working at a startup. My daughter has severe autism, so every day is a new challenge. I don’t think any of my other coworkers were going through what I was going through (this started for me in 2009). I used to have these huge crying fits in the restroom after getting yet another assessment that my kid was at 1 percentile in all development milestones, then have to wipe those tears off and go push code to production. I had to work limited hours, unlike the mega geek stereotype that does side projects and is so passionate about programming that they work outside of business hours too. I had to deal with immigration issues. I had to learn how to communicate effectively. I didn’t come into my first job with stellar credentials like a CS degree from a top school. For these reasons, I concluded that I am an URM in some small ways.
There are also many ways in which I am not an URM. I had a very stable middle-class upbringing in India. My mom who is a physician was a huge role model for me as I saw her as a badass lady that juggled work and family responsibilities. My parents paid for the first six months of graduate studies in the US until I could get a student job and a research assistantship to pay my way through the rest of grad school.
I think that other underrepresented groups have had to deal with way worse problems than I did. I still hope this post is helpful as I share my perspective.
Dead Reader, thanks in advance for your patience.
First, a little more about my background. I went to Arizona State University for a Masters in CS, and before that to an engineering school in a small town in India. My first job in the US was at a small AI research company. After that, I was engineer #6 at indeed.com, and I built search and recommendation systems applications that processed millions of requests per day. When I left Indeed, I was a principal engineer — a level that required having organization-wide impact. I now work for Hashicorp, on widely used open source software. I’ve made significant technical contributions to Nomad and Consul. I have also recently taken on engineering management while continuing to make technical contributions. Its early days yet but I am determined to support my team as a good engineering manager. I’ve always wanted to explore engineering management so I am glad to have gotten the opportunity to do so.
ASU is known for being a party school, it is nowhere in the same league as Stamford, Brown, UIUC, CMU, Georgia Tech or UT. No one in my immediate family had traveled outside India for graduate studies. In fact, I barely knew how to use the internet properly when I applied to grad school. I didn’t know about websites that rank schools and CS programs. I wrote the GRE and TOEFL exams, and choose a few schools based on whether the state they were in sounded interesting, from using extremely out of date books from a library in Chennai.
Arizona State was a random choice for me — I had heard that there were many other Indian students there, and so I chose it amongst the ones I got accepted to. I didn’t even apply to any top-ranking CS schools. Pretty much every grad school in the US has many Indian and other international students, so my reasoning about ASU didn’t make sense. But I did it based on the information I thought I had, without working at figuring it out correctly.
Actively seek out information you don’t have. If no one in your family or immediate circle of friends or co-workers can help you, make it your number one priority to seek advice outside that circle. It is up to you to find who or what group that is, but the information is available online. You will have to seek it out though. This is so true if you are the first person in your circle to do a CS program in a different country.
If you don’t have the same kind of network and connections that others do, you start out with that disadvantage that can only be eliminated with the effort put in to answer those questions. This applies at every step of your career, not only when you are starting out. No one will know you need help unless you seek it out — so figure this out sooner rather than later.
Never stop learning hard things — Whether you work at a very small company, or a behemoth like Google or Amazon that employs tens of thousands of engineers, excelling at software engineering is always going to be about learning and executing on hard problems to deliver value. What is “hard” changes based on your level of experience, and the projects going on around you.
Compare yourself to where you were the previous year, and don’t compare yourself to other engineers. As long as you see growth in terms of the complexity of problems you are attacking, or the variety of things you learned and are getting better at that you weren’t the year before, you are still “moving forward” even if your career level doesn’t yet reflect that. Thinking about my career this way, has led to personal satisfaction at the things I know to build because of never shying away from learning something difficult.
The recipe, if I could put it that way, involves — learning something hard (hard for you), collaborating with others, and going from an idea to working in production through successful execution. That’s the big point I want to get across, ideas are great but they need to ship and provide value in production for your company to recognize your value. ShipIt
Actively absorb from people around you, including other engineers, PMs, and QA will lead to personal improvement and great products. For example, if another engineer in a code review gives a suggestion that is going to make you rewrite a bunch of stuff, think of it as “wow, I just learned a new design pattern” and not “Man, what I wrote already works, why should I rewrite it?”.
My first Go code review had 70 comments from 6 different men on the devops team at Indeed. It was so intimidating. Less than a year later I had a PR in Hashicorp’s Raft project. I truly believe that if I hadn’t put in the effort to learn from those code reviewers rather than giving up I wouldn’t be where I am today.
Over time, you will learn to recognize the difference between comments and reviewers that have “bike shed color” value(ignore those), vs value that’s like “wow, that is something new I learned, that I can do in all my future projects”. Seek out those types of reviewers, and work on becoming a code reviewer like that.
This does not stop with just software engineer peers. If your team has a PM who is solid on product strategy and prioritizing features, take the time to learn from how they make their decisions so that if you ever find yourself having to wear a PM hat for a while, you’ve got a head start through your learning. If you know a really good manager — observe how they communicate, how they run meetings. Being an effective communicator is good even if that’s not your main focus as an engineer. Smart and driven people are all around you, learn through them to become more effective.
Ownership is a very broad and abstract term. To me it means:
Own your work and design decisions and don’t pass the buck. For example if you see a badly designed system say “I am responsible for this now, how can I make this code better” vs “I didn’t write this, not my problem”.
Asking yourself “what would you do differently next time” when things go wrong
Understand the big picture in your work. Even if the project is interesting and technically challenging, is it the right thing to build? Is it solving the right problem? These are questions that an ownership mindset software engineer would ask, rather than thinking “I have X tasks assigned to me, I am going to go ahead and finish them”.
Often engineers say “Product told me X is a priority so I did it”. A ownership mindset person would know to ask questions and clarify *why* a product manager said that X is important. A good PM provides context and data to back their asks, and equally so, a good engineer understands that context deeply and critically questions it.
Learn how to influence others — If you are in a company that’s not a collaborative environment, then the best advice I have is to leave and find a better place. However, even in very transparent and collaborative environments, unless you are in the right meetings, your perspective is not always going to be actively sought out. So, If you have ideas or suggestions on something that is not necessarily in your immediate sphere of responsibilities, you have to seek out the right people to go talk to, to give that perspective to.
There are a number of ways to do this, depending on your company. internal project mailing lists, your 1:1 with your manager or developing a network outside your team of software engineers and other roles who are doing interesting work. A former co-worker of mine used the word “technical allies”. Think about who your technical allies are in the company and how you can influence them.
Advocate for what you want — I felt pretty vulnerable the first few years of my career — every other engineer was either a Turing scholar at UT or was from another top 20 CS school. I had imposter syndrome or it could be because there were very few highly technical women. I used to feel that I wasn’t smart enough and I was only there out of luck. It took me years to advocate for myself. I would do whatever work was asked of me, without necessarily working through whether it was something I wanted to do or not, and a good growth opportunity.
My advice for anyone that’s been in this position is:
- Believe in yourself
- Learn what motivates you early on, and focus on building your strengths in that area.
- Its ok to say NO to things you don’t want to do.
- ANYTHING can be learned if you work at it.
Learn to recognize the signs if your company tries to shuffle you from project to project, or doesn’t provide you with opportunities to grow. And yes it will be terrifying to ask for what you want if you look different from everyone else. I’ve been there. But if you don’t learn to do this, you have to rely on a perceptive manager or peer to notice and help you out, and that may never happen.
Front line managers have a core responsibility to actively learn about their reports based on their background. If they notice a URM on the team not advocating for themselves, they should be coaching them to do that rather than assuming “X doesn’t say much, so everything is fine with them”.
Titles do matter — I’ve observed this with well-meaning senior level (director or above) level folks, where they will use phrases like “Titles don’t matter” or “I am just a manager, what do I know”, when you approach conversations about your own career with them. I get that they are trying to be humble. However, the more someone says this to you in a way that feels dismissive of your own career growth, the more of a red flag that is. It’s almost like they are saying “you are doing a great job at your current level, keep doing the same”. Don’t stay too long in such organizations.
It’s okay to be ambitious and want more. If your organization is saying this to you a lot, and you don’t see advancement prospects, it is time to leave. If you are saying this to someone that reports to you who wants to grow, its a huge personal red flag that you need to work on.
It’s better to start creating a network outside your organization and planning your exit in advance to get out of such situations. We are very lucky to be in the tech industry where both core technical skills and technical leadership skills are in high demand, so there are plenty of organizations to move to, in order to advance your career if you feel stagnated.
Organizations that want to improve diversity in their upper ranks should begin by being transparent around promotions. When someone is promoted, a few lines describing their impact and career trajectory can go a long way towards transparency, as well as showing an URM what it takes to be successful at higher levels.
Understand how compensation works — There are many web sites and quora posts around software engineer compensation. You should learn how compensation is determined, and know your own worth. If you are the first in your family or friends circle to even work in the tech industry, it is natural to be happy with whatever initial offer you get because that’s likely already going to be pretty good.
In the first few years of my professional life, I used to convert my salary to Indian Rupees and think “holy s***T that’s a lot of money, why do I need a raise”. I always waited for raises to come naturally and never asked for them because I felt that it was more than enough compared to what I would make if I was still in India. That is the wrong way to think about compensation, it’s not about whether you can make do with that pay. Depending on your background and how you think about money, of course, it is quite possible to live with $70K annually as a software engineer by living frugally. Don’t do that though! This is why we have salary comparison websites, and a market rate. If you are being underpaid, it is time to negotiate or find a place that will value you.
Learn the details about stock options, what each stage of venture capital funding means to your stock, and recognize the signs of a business that is not in good shape. Learn to cut through the hype that many companies present when they try to recruit engineers.
Figure out what matters to you. You should know how to evaluate an offer for all aspects — stability, flexibility, monetary rewards, good business sense in the people running the company, work culture and your new team members. Note that the order of importance of each factor is totally up to you, and changes as you mature as an engineer.
Immigration and Visas
Being on a work visa means you do have to have a fallback plan before you change jobs. That’s just the reality of what you have to deal with. However, it doesn’t mean you have to abide when your employer treats you differently because you know you can’t easily make a job change. Read about the company’s culture before you join, so you don’t end up getting stuck in places like this. I’ve been lucky to never have been in such situations, but it’s quite common with immigrants, particularly from India and China where the green card backlog is huge.
Avoid doing glue work at the cost of innovative/business critical work
In your early days, it is super important to establish technical credibility first — you do that by successfully shipping useful things to production. My career stagnated for a bit because instead of building innovative things, I worked on what I call “the last 99%”. I did projects like — “working with ops in doing whatever’s needed to get an application into production”, “unblocking other developers on the team by doing little things that would help”, “facilitating another team adopting a certain design pattern because they were having problems with stability in prod”. Then I realized when review season came along that I didn’t get impact points or the time/chance to do innovative work. I don’t know how common this is with other women, I certainly did fall prey to this urge.
Managers should notice when they see only one person on the team doing this, and try to spread the load around. Stay away from things like “taking meeting summaries and emailing them”, “organizing lunch and learn events”, “speaking at meetups and conferences” unless you know your organization actually values those behaviors.
If you do these activities, make sure to document your contributions in a clear manner where the narrative is that “X would not have shipped this quarter if I didn’t do Y”, rather than saying “I helped with big project X”. If your organization does not value this sort of work, avoid it and play by the rules if you want to get promoted, that’s my blunt advice.
If you are in a management role, you could change the culture so that people are given explicit feedback about what is required to move to the next level. You could also help create a fair review process that rewards critical glue work to incentivize more people to want to do them. You could work with the rest of the organization to make sure the review process doesn’t indirectly punish the quiet people in the background that work to get things over the finish line.
Help others grow
Many organizations have their review process valuing a few “superstar/rockstar individual contributors” who are so technically capable that can solve any problem, and somehow only they can solve hard problems. However, I think a true “rockstar” is someone that directly teaches or grows others to build similar skill sets as them. These rockstars create challenging opportunities for members of their team to level up their technical skills, without waiting for a manager to tell them to coach. These sorts of engineers are often overlooked.
Always be helpful to others. There may not always be a monetary reward, but there is an incredibly rewarding feeling when you hear from people years after you stopped working together that they valued what they learned from you. Also, even if the recipient doesn’t realize or acknowledge your help, you know what you did and that should be a good intrinsic motivator.
I realize this advice seems a bit opposite to the previous paragraph, where I basically tell you to look out for your own interests first. Beyond the warm fuzzies from doing good, the strategic reason for doing this is to build a professional network. The people you work with today can leave and go somewhere else tomorrow, and they are more likely to remember and connect with someone that helped them grow, over someone that was known as a kickass engineer but was always heads down in their own work.
If you believe in yourself, and approach your career with a constant growth mentality, good things will happen. I am not claiming that for URMS it’s smooth sailing if you have the required skill set to be successful as an engineer. Unfortunately, bias is very real, and you have to work hard on demonstrating those skills effectively until the industry changes. I think the most challenging bias to overcome is the “URMs are promoted on accomplishments, others are promoted on potential to accomplish”. As organizations hire more URMS into leadership roles and processes become more transparent, the eternal optimist in me believes that this bias will be overcome.
Under current conditions, I believe that if you persist, you will get to a place where you can be a sponsor to other underrepresented people wanting to level up. You can change the culture in the org by pushing for fairness. You can be in meetings where perhaps you are the only URM and can bring that viewpoint. Keep that goal in sight, and it does help you get over feelings of unworthiness, or feelings that the system is stacked against you.
I had so much to say on this subject, so thanks to readers who made it to the end on this one.
PS: This article was sent to me by someone who said that it resonated with every woman that read it. Its an open letter to managers of women, https://medium.com/@JasonShen/an-open-letter-to-managers-of-women-58b1655943ce