Siddharth Rao

Hello! What's your background and what do you do?

Hey, I’m Siddharth and am a Staff Software Engineer at Twitter, and a Technical Lead in the Revenue Product organization where I’ve led multiple teams working across our ads stack.

My journey into engineering started when I was in fifth grade with the BASIC language. The fact that I could build something that me and my friends could interact and play with was fascinating. It started with quite simple programs but soon enough, I started putting building blocks together and writing rudimentary video games like Snake and Pong. Writing software all throughout highschool, I knew exactly what I wanted to do with my life and therefore, choosing an area of study was extremely simple during college. I graduated from University of Washington in Seattle in 2017 and joined Twitter as a Software Engineer right after.

At Twitter, I started in our Advertiser Experience team where we owned and built ad campaign creation, editing, and managing software for advertisers across the globe. Over the multiple years here, I’ve led frontend, fullstack and platform teams, all inside our Ads org. After our Advertiser Experience team, I worked in our Revenue Platform organization for some time, leading the Callback team. That team builds systems that allow us to store and retrieve ads data for analytics. Then, I moved back to Revenue product where I’ve recently led our Web Formats and Ad Targeting teams.

How was your transition from software development to management like?

My transition from an Individual Contributor to a Technical Lead role wasn’t exactly a conscious or planned move. However, I believe the career goals I set for myself unintentionally led me to be well set up to be a technical lead. Here are a two of them and how they helped me:

• Review as much code as humanly possible: I wanted to learn extremely fast and code reviews are one of the best ways for ICs to learn about what their team is doing. My goal was to review more code than any IC was reviewing. I switched my late night novels to code changelogs. Usually this practice initially was more about me reading code, than it was about me reviewing it. Over time, I gained context on almost all projects our team was working on.

• Writing code in unfamiliar codebases: Everyday, I’d spare around 2 hours after work to learn about different microservice or libraries that weren't owned by my primary team. In some cases, I’d start refactoring code in common libraries owned by our organization to learn about code and get my code reviewed by more senior engineers. This unlocked two different doors for me: learning from a different set of individuals, and two, being uncomfortable by writing code in different projects.

Doing things like these really helped me set myself in a position where I was in a position to drive small projects. Slowly took over large scale projects, and eventually teams. I’d say there was enough self preparation in my career to be able to lead teams where I didn’t think it was a sudden transition into this role. Regardless of if people move into this role or not, it is quite important that every engineer set goals and challenges for themselves that push them beyond what the current or even the next ladder step requires of them.

What does your day-to-day work look like, and what motivates you to do it every day?

My day to day responsibilities are driven by what I believe my job function is. At the highest level, my job is to create conditions of success. Breaking this further apart, here’s what I believe helps me achieve that:

1. Setting Technical Direction for the team
2. Mentorship
3. Core Engineering
4. Planning and Process Definition

If you think of these as four different levers I have access to, it requires me to pull or push on these with different amounts of force at different times. It’s almost impossible to break down any particular day into a uniform division between the four things I mentioned. Generally at the beginning of a quarter or half, my main focus is around Setting Technical Direction for the team. This sets the tone for the team and defines the short and long term vision. In addition to setting the direction, it’s extremely important aligning the team around it and to ensure that everyone on the team understands the direction and believes in it. The days leading up to a new half, quarter, or year are mostly spent on doing exactly that.

Mentorship is one of the most valuable job functions I have. I spend around 30% of my time mentoring others around me and enabling them to grow. This can be in the form of coaching them or providing technical growth and feedback. In addition, it’s my responsibility to create and foster an environment in my team where skill development of engineers is heavily focused on. On a day to day basis, this might look like providing feedback on technical designs, teaching someone about some system or architecture, or coaching in 1:1 settings.

Core engineering is something that I always ensure I have time doing. A technical lead that doesn’t spend time doing day to day engineering work will be too far removed from the problems their organization is facing. Very often, I jump on oncall issues, hard technical problems, or roadblocks projects are facing, and writing technical design documentation. This enables me to understand where the team stands, where are the biggest bottlenecks, and where do we need to improve our teams, systems, and processes. Of course, I cannot write code as much as I used to when I was an IC, however, I do believe this is one of the most high leverage things I do with my time.

Finally, I spend around 5-10% of my time around process tuning and planning. This is generally less than what other individuals in my position spend on planning and process oriented work, however, I intentionally devote less amount of time here. Processes involve how we plan our weeks and months, how we onboard new engineers, and how we might transfer a service from team A to team B. etc. However, I am a firm believer in keeping processes extremely light weight and ensuring that the sole purpose of a process is to increase the odds of success, whatever that means for the team and the customer. However, if a process makes success a less likely outcome, we abandon it right away. In addition, I tend to let engineers drive and adopt the process that works best for them as opposed to having a singular process for the entire team when suitable.

Generally the ideology I like to drive for myself and my team is that everyone owns their own time. And using that time, create the most leverage for the customer. For myself, spending time in these four categories creates the most leverage for myself, my team, and our customers.

What are the biggest challenges you've faced so far? What did you do to overcome them?

One of the biggest challenges I’ve faced so far is building a culture of innovation and continually creating roadmaps that are aligned with that. With time, it gets exponentially hard to prioritize moonshot ideas and create space for yourself and others around you to experiment and innovate with ideas and technologies. This becomes even more difficult as the size of organizations and systems grow. A strong engineering leader should work with their peers in product, design, and research to amplify the voices of the ICs to ensure enough space is reserved for experimentation. Overcoming this was a mixture of being prepared, forming the right relationships, and ensuring the benefits of experimentation were clearly communicated to the larger organization. As an engineering lead, one should be able to convince others of the benefits of investing in certain technologies and systems and tie it back to how that eventually serves the customer.

What has been the biggest surprise so far? Something you didn't expect?

One of the most common things I see new Technical leads trying to do with all ICs is the idea of setting expectations. I was told that the first thing I should be doing is setting expectations with all engineers. However, I’ve been extremely surprised to see how detrimental this practice can be. Setting any expectations on ICs almost always does a disservice to them. More often than not, people generally only try to meet expectations, but never exceed expectations set upon them. I’ve found that letting people find their own ceilings is almost always a better outcome. Once they do that, I work closely with ICs to ensure they are constantly raising the ceiling they’ve set for themselves.

What's the best advice you've received about being a manager?

That being a technical lead is more about other people’s career’s than it is about your own. With this role, one’s own career trajectory comes in second to the career trajectories of everyone around them. This is a very hard transition for most people because as an IC, you’re almost never really worried about anyone else’s career. However, as a technical lead, when I started operating with this mindset, I realized I was a lot more effective in achieving the goals that I had laid out for my team and even myself.

What do you tell developers who are considering making the switch or new to the role?

There seems to be a lot of misconceptions about being a technical lead or manager at most companies. First, I try to remind individuals that being a technical lead is not a way to be promoted. It’s a completely different job function than that of an IC and becoming a technical lead is a separate ladder. As a technical lead, individuals spend a lot of time doing things that aren’t core engineering and these things take a significant amount of time away from that. If you’re not interested or willing to spend time outside of your individual contributions, this should not be the way to extend your career.

Second, I’ve heard a lot of individuals try to switch to this role as they want a certain level of “control” over decisions. However, I find this extremely contrary to how decisions play out in organizations. Almost all system architecture and design level control is still with ICs. As a technical lead, you can try to influence decisions and technology, but you’re almost never the decision maker in the room. The job is to convince others to align with the direction and vision you’re setting, and almost always comes with relinquishing control that you have as an IC.

Final call to action! Where can we go to learn more about you?

You can follow me on Twitter @sidgrao for my yearly tweet!