On management vs engineering (and my career story so far)

NOTE: This is a lightly edited version of a post I made at work, as part of a series of career stories. The edits were mostly for formatting and removing sensitive information.

Hi! My name's Hasnain and I'm here to talk about my career journey. I haven't had as long or as successful a career as many others, but I have had a somewhat unique experience (transitioning to management and back) which I've been asked about a few times. I've tried to summarize lessons I learned both as an engineer and as a manager - hopefully this story will be useful for you, dear reader, and if it leads to any questions feel free to ask me anything!

TLDR

Since this note is quite long, I've pulled out a few of the more important meta lessons I learnt below:

• Careers are marathons, not sprints: Slow and steady career growth over time can get you incredibly far over long time periods. If you try to overdo it for too long, you risk burnout, and that can set you back and undo a lot of the progress you've made. As long as you regularly set aside time for growth (career growth is exponential!) and put in the work (e.g. seeking feedback, working on growth tasks) - you'll be successful.
• Take ownership of your career and work: Don't confine yourself to the work you've been assigned. Invest time in learning what your team/org/users care about, and ensure you focus on that. Your coworkers/users will be happy, and you'll be happy and rewarded. Similarly, you're the best judge of your career growth: make sure you are getting the time/experiences needed to grow - if not, talk to your manager, adjust your workload, and ensure your needs are met.
• Be kind: The people who I've learnt from the most over my career, and the ones I want to work with again, are not necessarily the most successful people I know. They're the ones that have been friendly, gone out of their way to help, or shown genuine interest in helping me grow/feel welcomed at work. Be that person, and you will find people seek you out for advice, want to collaborate with you, and will send opportunities your way. It's a win-win, and for me personally, it's also extremely rewarding.

2012: Applying to Facebook

I studied computer science at a college in Pakistan. If you told me back then I'd be working in Silicon Valley, I wouldn't have believed you. It was just unthinkable for anyone from Pakistan to work in the valley, and I wasn't that smart. Beyond the technical challenges, it was also (near) impossible to get visa sponsorship - a situation that has only gotten worse since.

In my junior year of college, I had the opportunity to do research work that eventually lead to a research internship (in computer security) a few miles down the road from MPK, at SRI International. While I'd made it to the Valley, I still thought I was going to continue in academia once I was back, and didn't think to apply for jobs. My dad, however, disagreed and pushed me to apply. In his words, “don't reject yourself, let them reject you.”. I YOLO applied (read: got referrals via my advisor) to the three companies I knew would sponsor visas - Google, Microsoft, and Facebook. After profoundly messing up my google interview, I practiced a bit more and eventually got offers from both Microsoft and FB (despite getting one question wrong) - and decided to accept the FB offer.

My first time visiting the Facebook campus.

Though this was before I officially started my career, I learnt from this experience. First and foremost, I learnt to acknowledge the luck and privilege I had to even get this far: I was able to apply to these jobs while in the US (so companies actually looked at my application), and I was able to get a work visa. This (sadly) continues to come up, as I would hear genuine surprise from my fellow country-folk that facebook even hires Pakistanis during company events. While it seems commonplace while living/working here, it's humbling to remember how lucky I am to be here. Secondly, I learnt to go outside my comfort zone and apply despite rejection anxiety: I wouldn't be where I am today were it not for those nudges. It can be really hard, but it's worth it.

2013 - 2014: SRI International

Despite accepting an offer to start at FB in October 2013, I started my career at SRI. The project I'd worked on during my internship got funded for another year and I was asked to return to continue my work. I was lucky enough that Facebook was okay with deferring my start date a whole year (!), so off I went.

During that year, I worked on ENCODERS, a solution for efficient mobile P2P networking - and that work lead to 4 publications, which I was happy with. The experience taught me a lot:

• How to be effective in an environment with a long feedback cycle: SRI's model was the polar opposite to FB's: We had one long term deliverable, everything was meticulously designed upfront, and we spent a lot of time on thorough testing (that was a significant portion of my job). Development was slow, and the final delivery was slightly underwhelming: we had to burn all the software and documentation onto a CD so we could mail it to DARPA (even though the code was on GitHub!).
• Independence is great, but not without its downsides: I was expected to work independently from day one, from developing new features and owning the integration of code from subcontractors to doing performance evaluations. This helped me grow a lot: I learned project management, had the experience and freedom to set my own goals/schedules, and figured out how to collaborate with others. But the absence of a formal mentorship structure meant I had no way of knowing what I was missing out on - and I learnt how crucial that was to an early career engineer.

All in all, I'd definitely make the same decision again (working elsewhere first) - working elsewhere helped me appreciate how a change in work environment brings out different strengths and weaknesses in myself.

2014H2: Bootcamp

I started at Facebook as a starry eyed new grad engineer: eager to learn more about how big tech companies work, and how to build systems at scale. I was astonished to see how fast things moved: I was able to push diffs to production in my first week! Of course, I ended up breaking messages on for a small subset of users on mobile, so in my second week I learnt what a push-blocking task was, what it meant to receive a UBN (UnBreakNow, i.e. a page to go fix something), and why you should be very explicit about in diff test plans (I'd tested the wrong mobile site, and I was in the class which taught the difference when I got paged!).

Bootcamp is all about team selection: I suffered from analysis paralysis and had a hard time deciding which team to join - I sat with something close to 10 teams if I recall right. I got some really helpful advice at the time to make a pros/cons list for each team, and match that against what I was looking for at the time. I eventually joined the ads and pages reporting backend team - responsible for the metrics that we show to advertisers and page admins. The team was working on large-scale systems problems, and there were enough senior engineers to provide mentorship - something I was looking for.

2015H1 - 2016H1: Insights - migrate all the things

actual picture of me during this period

My main contribution in my first full half was to build a service to migrate page insights data from our old backend to the new one. This was a seemingly perfect project: I got to design a new service from scratch, had to tackle scaling challenges, and was able to focus on greenfield code so there wasn't much to ramp up on. It worked out well - in my first half I got a great rating because I independently delivered a project I was expected to need a lot of help on - primarily because no one told me I'd need help. Over the next two halves, I continued to expand these services to migrate instagram, and then ads insights data, while growing my knowledge of the broader systems as well and contributing to smaller projects. During this time, I got to write and review a lot of code, understand what it meant to be oncall for a production service (I still have some nightmares of babysitting Hive pipelines), feel the camaraderie of working in a war room, and really grok what it meant to be part of an engineering team. I learnt that I'm my most productive when I have a clear goal to ship a system once the requirements are clarified.

Working on this team was a pretty formative experience, and even if most of the lessons I took away were technical, there were a number of career lessons:

• Give up on perfectionism, focus on getting feedback early: For the first couple of months, I kept hacking away at my ‘perfect' system design, building components on top of each other and creating a stack of diffs locally. My (very understandably worried) manager nudged me to put up some code for review ASAP and then I got a lot of feedback that helped me improve my code, and forced me to rewrite a chunk of it. With the benefit of hindsight, I learnt I should minimize the time-to-first-feedback: put out code early, put up a rough design doc, have a quick 1:1, etc. This improved both my execution speed and quality of work.
• Take ownership of the problem - go beyond your project: When I started out, I focused purely on the code/services I had to build. I learnt that to increase my impact I need to see if my work helps push our team/org's goals forward - and if I see an opportunity, I need to either push it forward myself or convince someone of its importance. Sitting back and waiting for others to point out improvements, while not harmful, actively limits growth.
• Make time for the things that give you energy: I was working more than was healthy at the time. While I probably should have set better boundaries back then, one thing that helped keep me going was to carve out time for things I enjoyed. At the time, that was focusing on recruiting (I enjoyed doing interviews) and finding a way to help improve our recruiting pipelines.
• Focus on learning and growing: Career growth truly is exponential - investments early on have disproportionate impact. I signed up for literally every training course available - from technical ones to non-technical ones. Some things can only be learned via experience, but for the other 99% there's always a course, book, or mentor. At Facebook we have so many courses, so many people sharing their experiences in posts and groups, and so many mentors to learn from.

It was this last point that pushed me to consider a hackamonth once we'd completed the migrations. The timing was perfect: it was the end of a half, I'd shipped my projects, and the work on my team was slowing down. I wanted to learn how other teams work and how Facebook approached security. This lead me to Product Security, where I've been since.

2016H2: New challenges

I'm calling this one out because it was one of the toughest halves I've had. I had just switched teams, becoming the only owner for an unowned project/area (this eventually grew to be the dynamic analysis team), with expectations to define the roadmap and deliver it. I hadn't really done this before, and it was a struggle. Add onto this a tough personal situation which destroyed my concentration (lots of difficulties, including my grandmother's worsening health and eventual passing), I didn't feel like I got much done. This was the first half (and thankfully only one so far) where I put in my self review that I expected to get a Meets Most rating, and I would regularly express that fear to my manager in our 1:1s.

Lessons learned:

• Code is not the only impact you can have: I quite surprised when I received my rating and it was better than I expected. Even though I didn't write as much code as I'd done in the past, I had done a meaningful amount of collaboration with other teams and come up with a roadmap for shipping my new system. And even though I hadn't shipped something end to end, I had made meaningful milestone progress by individually building one component of a larger system.
• Create opportunities for growth where they don't exist: I wanted to grow my mentorship skills, but the sub-team I was on didn't have anyone else. Following advice, I signed up to be a bootcamp mentor so I could practice mentoring in a lightweight way; while we hired for the team.
• Slow and steady progress goes a long way: On particularly rough days, I would set myself a simpler goal - just do one small thing, whether it's putting up a small diff, attending one meeting, or just one interview. More than anything else, this helped me feel productive and much better about myself. I did a lot of this - that half, I conducted 70 interviews (batch days help get a lot of them done), and delivered a workshop on messenger bots to engineers in Pakistan:

The smog did not prevent us from having a great time

2017H1 - 2018H1: Invariant Detector and growing the dynamic analysis team

Note: unfortunately I had to cut out 70% of this section as it was mostly discussing confidential information.

At the start of 2017, the stars aligned and I had the opportunity to pick up work on Invariant Detector (IVD) - an extremely cool dynamic analysis tool for finding security bugs. The team that had owned the system was being reorg'd, my team (dynamic analysis) was looking for more projects, and it seemed to be a perfect fit.

After 2016H2 I already had some experience in picking up unowned projects and code - this was much more challenging however. This was a live, production system looking at database traffic in an area where bad bugs could break all of facebook.com. I had to ramp up on this ASAP and gain context to keep the site running. To that end, I started by flying to London and going straight to Maroush for a chicken shawarma (I'd been looking for a good one for years). Shawarma craving satisfied, I showed up to the office the next day and spent the week getting a brain dump from the previous owners on the code and what they thought should be done next.

We set out with very ambitious plans to [ redacted ]. Achieving this in one half seemed very daunting, but I was able to do this after putting in the requisite (grunt) work: Becoming the most expert IVD user at FB. I triaged hundreds of issues that half, regularly posting about the results so we could find groups of false positives and fix them. The most valuable part of this experience was putting myself in our user's shoes (I also held shadowing sessions to get first hand feedback) so I could learn how they used the tool; and what things they found confusing/painful. One lesson I learnt that half was to be open and communicative about my work, especially since I had to collaborate with a lot of folks across various teams.

At the start of 2017H2, we also started to work with the Instagram Privacy team to use IVD to learn data level privacy rules for their codebase. This was a new experience for me: working closely with partners in a different org to meet their goals. We worked on this for about a year — along with other security teams (secure application frameworks), working truly as one team towards a shared goal helped us succeed. You can find a brief mention of this work in a publicly available talk here, near the end (the discussion on inference). This was a tight collaboration, we'd have a shared weekly standup and just crank out diffs/look at data till we were done. We were awarded the axe (IG fix of the week) for this work:

Winning the IG fix of the week along with part of the team.

Note that I've heavily summarized the work done at the time - during this time, we continued to work on WWW invariant detector, and started to look into fuzzing as a long term effort at the end of this period as well. I learnt an incredible amount through this time, especially on how to split my time across various efforts and set them all up for success. The fuzzing journey was also quite insightful (e.g. on how to collaborate across companies), but is too long for this note.

2017H2 - 2018H2: Making a manager

(Yes, this time period overlaps with the prior section)

Around the end of 2017, I started to talk with my manager about my long term career goals and expressed interest in management. I knew it was something I wanted to do eventually in my career - I wanted to do a startup at some point and management skills were needed for that. I wasn't sure I wanted to be a manager for the long haul, and so we discussed ways to explore this and work towards a smooth transition.

In 2017H2, I started to help with hiring and onboarding engineers on the team, and, more importantly, mentoring them and helping them be productive. I also became trained for behavioral interviews which helped me appreciate some of the nuances of management, and managed an intern for the first time. The next half, the need for managers in my broader org became more apparent (my manager was supporting 20+ people) and the transition became a no-brainer: I was interested, the opportunity was there, and we had a nice on-ramp for me: I could manage a 3-person team as TLM (Tech Lead Manager), and decide later whether I wanted to stay a manager or an engineer. I started shadowing 1:1s and taking on dotted line reports. The transition officially happened in September 2018 when my manager went on recharge, and I started by filling in for him, supporting 20 people for a month. I wasn't ready for that at the time but in hindsight it was a great experience as I got thrust into the thick of things and had to figure it all out.

The transition process intentionally takes time: beyond approvals and paperwork, it's important to know you are getting into management for the right reasons, and more importantly that you're not doing it for the wrong reasons. It's also important to try it for a while to understand the weight of responsibilities you have to take. It took me a while to understand the response I got when someone offered their condolences in response to the announcement of my becoming a manager.

Lessons learned:

• It's all about people management: This took me quite a while to internalize. More so than at other places, an EM at FB really needs to focus on people: at the end of the day, your team needs to be well supported, growing in their careers, and that is your primary focus.
• It's about the team, not you: The hardest thing for me to learn was balancing my own individual work and what the team was doing. At the end of the day, a manager is accountable for the team's success. You can do something on your own, but the team only succeeds if you delegate the work and grow people so they can do the work themselves. You absolutely cannot become the single point of failure for your team.
• Your reward functions change: As an engineer, I could get dopamine hits from finishing up a diff and seeing my code work. Management has higher highs (e.g. when you see someone's growth kick in after a while, and watch them do something they couldn't before) but they are fewer and further apart - and the lows are worse. Part of the job becomes managing your own morale.
• Try out lightweight options for management: Bootcamp mentoring, intern management, and mentoring others on your team are all great opportunities to try management-like work and see if you enjoy the people-focused nature of the work.
• People expect you to be an experienced manager from day one: This was a surprise to me initially. Even during my first week as an ‘official' manager, I started getting asked a lot of questions I had no idea about (often about process/policies). As a manager, you aren't expected to know everything, but you should definitely be able to get the right answer back to someone in a reasonable time.

2019: Rebuilding a team

I had a very rough start to 2019. We had one engineer switch teams to try new challenges, and another engineer leave the company suddenly. My role and expectations changed from ‘grow this existing team working on these projects' to ‘build a team from scratch and figure out its charter'. We decided to go all in on fuzzing. Over the year, we went from 1 engineer + 1 half engineer/manager (me) to a small, focused team (4 engineers + me + a few offers out) and a working fuzzing platform that delivered results. That summer we were a team of 3 interns, 2 engineers, and 1 EM - I'm not sure if any other teams ever had more interns than full time engineers! I learnt the importance of time management and balancing between engineer brain and manager brain - the hard way. It's very alluring to try and do both jobs, and I fell headfirst into the trap: I was working unhealthy hours for quite a while and suffered from some burnout which started to show at work. The year had was not without highlights, though: personal ones included a trip to Pakistan to launch an innovation lab, and hosting+presenting at the bay area fuzzing meetup:

Presenting at the bay area fuzzing meetup.

Lessons learned:

• Recruiting is a numbers game: 2019H1 really showed me how hard recruiting is. The numbers say it all, really: I reached out to ~70 bootcampers and we hired one person that half - and that person reached out to me directly and said they wanted to join our team. It's easy to lose faith, but through learning from each attempt and improving, and trusting the process (the right candidate will eventually come by), I was able to grow the team the following half.
• Focus on team balance/growth: The worst thing you can do as a manager is to blindly put butts in seats. To start hiring, you need to develop a clear picture of the types of people the team needs (skills, levels, passions, etc) and ensure that each candidate would be set up for success on the team.
• Feedback is a gift: This took me a while to internalize. I shied away from giving direct feedback for quite a while as I was afraid of confrontation. Couching it in nice words, or not delivering it clearly seems easy at first but over the long term it's actively harmful - both to the team, and the individual themselves - they don't get an opportunity to improve. As a manager it's your responsibility to give feedback clearly, early, and often.
• Be intentional about mentorship: I learned to focus mentorship on one thing at a time and help people grow. The SAR (Situation - Action - Result) model was pretty helpful in understanding if my mentorship was helping. This helps avoid situations where someone is being ‘mentored' for quite a while but not growing.
• Learn from your mistakes: Just like engineering, an effective way to learn skills while managing is to make mistakes and then not repeat them. The cost is much higher as a manager, though - as the blast radius of your mistakes can affect a person's career, livelihood, or even affect multiple people. It's important to actively seek feedback and do what you can to avoid mistakes. But you will make mistakes (it's unavoidable!) and should learn as much as possible from them.
• Learn from others: Facebook has an incredible amount of resources for new managers. From a wealth of training courses, to active mentorship programs (both pairing with external coaches and experienced internal managers), there's more than enough material and all you need to do is ask. I could not have survived without the peer support of managers within my org (shoutout to all the prodsec managers!) and it's important to use whatever support network you have. This isn't just for your own sanity's sake - it helps prevent avoidable mistakes.

2020: The pandemic

2020 started out strong. We'd hired and expanded the team's presence in Seattle and I was committed to flying every 4-6 weeks there for collaboration (oh sweet summer child...) and ensuring the team got to meet regularly to make things work in a remote situation. And then the pandemic hit, and threw a wrench into everything. Despite the set-backs, we grew the team (adding another 3 engineers in H1) and finally became a self-sustaining team; continuing to ship projects and meet most of our goals. Most importantly, though, the team continued to feel well supported and I put that as a priority over everything else. There's no point in trying to hit your team goals if everyone burns out in the process. I hate self-promotion, but I'm particularly proud of the stability I was able to provide during this time (PSC quote: “Your management of the team gets rave reviews from your engineers, with some of the highest Pulse scores in the org (99%) and appreciative upward feedback.”).

The lessons learned during this year were not fully novel (I'd seen hints of them before), but I internalized things a lot better with a larger team and a challenging situation:

• The true test of management is when things go wrong: When I first considered transitioning to management, I had a conversation with my director who asked if I'd managed any interns. I did, and when I told him the intern was doing well, his response was: “Well, shit. That's no good”. I finally understand what that means - that experience did not fully prepare me for management. It's very easy to be a manager when the team is healthy and hitting all its goals - you can disappear for a while, and things will still go on. It's much harder when things are on fire, people need help (or challenging situations arise), and you need to make the best possible decision with the information you have at the time.
• You have to be a different person to everyone: Unlike software systems, people are real, sentient beings with their own thoughts and you cannot suddenly change their programming. What works for one person may not necessarily work for another person - in fact, it may not work for the same person at a future point in time! You need to constantly assess the situation and make sure you are giving the right advice for the right person at the right time.
• Your words and how you carry yourself matters: As soon as you become a manager, you'll be perceived differently and your words carry a lot of weight. You'll have to stop a lot of the off-hand comments/jokes you might make otherwise (I learnt this the hard way). Like it or not, how you behave in meetings also matters. I've had experiences where people thought I was unhappy with project direction because I spoke up less and appeared distracted in a meeting - though I was actively staying in the background to let someone else lead the discussion.
• You do not own your schedule: As an IC (Individual Contributor), I was used to getting a lot of focus time to push forward projects. As a manager, your schedule is not really yours: something urgent can drop at any moment and take up the rest of your day/week. You're effectively oncall for your team at all times. Plan around this - calendar management becomes an active job. Make sure you schedule blocks to handle interruptions (something will always come up!), and have focus time for when you need it. This article goes into this phenomenon well.
• Make sure your expectations are clear: Expectations can vary widely half over half, especially if you're trying to balance technical contributions with people management ones. It's impossible to do both well (split brain syndrome kills productivity), so make sure you prioritize the most important stuff. For me, that often meant that coding was the absolute last thing I'd get to.
• You are part of a broader org, not just a team: As a manager, you're expected to spend at least some of your time on initiatives to help the broader org and company - be it recruiting, mentoring, organizing events, whatever. At first, this might seem like a time sink and not worth it - but the impact from this really adds up when multiplied by all the managers doing this work. And, as an individual, you'll build connections through this work which will help immensely.
• Let go of the technical stuff (seriously!): This is the first thing that every person and book told me when I was transitioning to management. True to myself, I disregarded the advice as I was planning to be a TLM initially. Oh, did I regret this. As a manager, you should never be on the critical path. If you are, you will find yourself working two jobs, holding the team back from its true potential, and lead to unhappy times all around. It's your responsibility to hire, delegate, and coach till the team is self sustaining.

2021: Transitioning back, sustainability

I made the decision to transition back to an IC in March 2020; but I wasn't in a rush (I liked management, and wanted to have a smooth transition back that wasn't disruptive) so I continued to manage the team as we looked for a backfill. I eventually announced this to the team in January 2021 and ramped down in Feb/March 2021.

As an IC, I've continued to play a TL (Tech Lead) role on the team, driving our important projects forward and helping prioritize our long-term investments. It's been interesting re-reading my past reviews and looking at how differently I approach work then vs now: with a more targeted focus on impact, and a much greater appreciation for the people side of things. Having management experience has also helped prioritize work: we ended up being in the right place at the right time, hitting ~all our goals and having the opportunity for some great bug finds. On a more personal note, I was able to finally work on some of my (personal) work-life balance goals and have one of the most sustainable halves I ever had in H1, and thankfully this continued on into H2 where I was finally able to take recharge comfortably without worrying about something going wrong (fun fact: my recharge was initially planned for March 2020, which would have ended as poorly as you might expect).

This section has no lessons - I'll focus on a few of the tradeoffs and factors I considered in my transition back as I wrote my pros/cons list:

• Time spent working on things I enjoy: While I really enjoyed management work, supporting people and seeing them grow, at the end of the day I'd find myself looking forward to writing that one diff/reviewing that piece of code to unwind and I found myself and missing that. As the team grew, it was harder to make time for this, and, honestly, it was a disservice to the team that I was still trying to be in the weeds. It was too tough to ignore this urge, and was my primary motivation for switching back. There's still some technical stuff I want to learn, and the opportunities were too good to pass up.
• Introversion vs extroversion: Despite appearances, I'm a solid introvert, and meetings are quite draining. I'd find myself needing downtime after heavy meeting days (especially days full of 1:1s) and this was definitely much harder with everyone moving remote. As the team grew, the meeting load would grow more-than-linearly and I was worried about burnout. I think in a non-pandemic situation this might have been easier.
• TLM-ing versus people management: Piling onto the above, the team had grown to a point where it needed a strong people focused manager, and while I think I'd be good at that for a while, I didn't see myself being able to sustainably do that (while also spending time on technical stuff/other work I found energizing enough to keep me happy). This is also an area where management at Facebook is different from that at other companies, from what I understand (I don't have personal experience) - the expectations are more heavily people focused here.
• Career growth opportunities: I knew that in the short term this would set my career back: I had a clear growth trajectory as a manager; getting the equivalent as an IC would take some time as I'd need to get back to being a productive IC before I could think about growth. I explicitly decided this was okay - careers are a marathon, not a sprint, and it's important to not over-extend. It was also important to realize this was a (temporary) one-way decision: I would (rightly!) be scrutinized if I tried to transition back to management a few months down the line.
• Management vs engineering is a blurred line: I realized that, even as an IC, I'd have the opportunity to do the work I found most rewarding as a manager: Mentoring and seeing people grow, helping match people to the right projects, driving cross-org collaborations, and delegating work to others. I'd just have to approach the work slightly differently (influence vs authority) and get to miss out on all the not-fun parts like PSC. In my book, this was a win-win.

A few resources

There are a lot of resources we have on management, both internally and externally. Rather than list them all (it would be longer than this note!) I'll link to a few that helped me:

• Julie Zhuo's book, The Making of a Manager, which resonated with me a lot especially when I read it again a year into the job. This is particularly useful for managers @ FB given her long tenure as a manager/director/VP at FB.
• Charity Majors (also ex-FB) has a great set of posts on the engineer/manager pendulum and a follow up on how to consider management vs engineering. They're worth reading if you are trying to decide what to do.
• Adriana Porter Felt has a great list of book recommendations for new and experienced managers here.
• Cindy Sridharan has a great article on understanding how your org works and using that to be more effective.
• Camille Fournier has a great book, The Manager's Path, which is a great complement to The Staff Engineer's Path.
• I've been a huge fan of Addy Osmani's blogs and writings. I recently learnt he's now collated some of them into a book, Leading Effective Engineering Teams.

Parting thoughts

Knowing what I know now, would I still make the same decisions to become a manager and then go back to being an IC? For me it's a resounding yes - I learnt a lot through this experience, and grew both professionally and personally. A++ would recommend trying out management if you feel confident it's the right role for you.

I've barely scratched the surface in terms of management versus engineering and it's hard for me to predict what questions may arise or what may be useful for folks. So, Ask me Anything!

Thanks to Katriel Cohn-Gordon, Amy Xu, Ao Zhang, Jez Ng, Hamza Aftab, and Mehreen Seher Hai for their incredibly insightful feedback on this note, and for all the mentors and people I've worked with over the years who provided me with opportunities to learn and grow - there are too many to list, and I appreciate you all.