How do you get time to be an SME or an elite bug hunter?
I am very much aligned and aware with needing to show impact or been seen as an SME to have visibility to move up to a staff level.
My question is one of logistics. How is this possible when you have more work to do than fits in 40 hours, let alone finding extra time to do these other things? For example if you have at least 30 hours of coding, 5 hours of code reviews or scoping documentation, 5 hours of meetings, an additional 5 hours of random things (CI broken, helping colleagues, ad hoc issues etc), where do you even begin to find time for these extra things? Especially when all of the above is barely considered meeting expectations?
I will also clarify that I don't want “get better at coding” as a valid answer. No matter how good you are, you still need to understand the many systems involved which can take a while and if you constantly have to tackle new areas, there's always discovery.
My question is more around how do you ask or “show” you should have time to work on other things. Whenever I would approach my manager with well thought out proposals, buy in, and even timelines the answer was always later.
Discussion
(3 comments)- 4
5 months agoEngineer @ RobinhoodAt Robinhood, I serve as a SME for money movements and debit card products. How I got there was:
- I joined early(ish), allowing me to work on many, many projects across the company.
- I effectively stayed on the same team for 4 years (and counting). This allowed me to watch the codebase and the product evolve over a long period of time.
- Every engineer on frontend that could take the scope as a TL/SME either quit or got laid off. By the time headcount was secured to get a senior-enough engineer to fulfill those responsibilities, I already had the trust, experience, and title to be a TL and SME.
- I had impact across multiple stacks. As an Android engineer, my main impact is naturally on Android. But I'm also the main BFF (backend for frontend) contributor in my org, an occassional participant in backend design review, an ad-hoc data analyst sometimes for projects & SEVs, and I've code-reviewed iOS a few times (with no iOS experience).
- I answer most product and frontend engineering questions within the domains I own. I also consistently have a pretty quick turnaround for answering questions.
- My overall commit and code review count is consistenly in the top 10% of all Android engineers. I write a lot of code, review a lot of code, and I'm usually fast with my turnaround for both.
To extract some tangible advice from my experiences:
- If you stay in the same place long enough, knowledge will naturally build up and the scenarios where domain knowledge is needed will come to you.
- Often times, what's complex and/or unknown can be good growth opportunties. You'll never always know everything in every scenario, so it might be more efficient to just embrace that. Don't proactively learn everything you can, but learn thing that better allow you to address business needs.
- Unfortunately, getting good at coding is a good action item for being a SME. Writing code better and faster means you'll have more time to flexibly use. Being fast also means you can tackle more projects, and being able to successfully deliver more projects relative to your peers means you've had more experiences and more impact (and the people around you will implicitly trust you more). If you use that productivity gain to write even more code, your knowledge and intuition around the code will deepen. Deep knowledge also compounds when you apply your mental models across stacks: I haven't written traditional backend code in years, but I'm participate in backend design reviews using the same mental models I have for building Android apps.
- Be helpful to people. Supporting people who need help with something you own helps reinforce domain knowledge, provides opportunities to identify implementation and process gaps, and builds people's trust and visibility with you.
Hope this helps!
- 55 months agoTech Lead @ Robinhood, Meta, Course Hero
My immediate reaction is that 30 hours of coding is way too much for a senior engineer, especially one going to staff. My advice is to figure out how to scale yourself, particularly through mentorship and delegation. For your coding work, can you give most of it to junior and mid-level engineers on your team?
That's primarily how I found time to do the "other stuff" to show staff engineer signal. I delegated away the more straightforward coding work (it's a waste of my time to do it), so I only coded the hardest problems. At Meta and Robinhood, coding was usually just 5-10 hours per week for me.
If this angle is viable for you, I recommend these:
- 35 months agoTech Lead @ Robinhood, Meta, Course Hero
On top of the mentorship angle, there are 2 broad ways to have more productivity (both of which can and should be implemented in parallel):
- Just do the work faster - This is through traditional methods like focus blocks, building up your flow state, and skipping useless meetings. For this strategy, I recommend this: [Taro Top 10] Time Management And Productivity
- Work on the best things - This is far higher leverage but harder to do. It's also a very important characteristic to go from senior -> staff. Software is a brutal world where you can easily write 10,000 lines of code that accomplishes nothing (I saw so many features take months to write only for it to die in the A/B test at Meta) or a 10 line bug fix that makes millions of dollars (I also saw this at Meta). Developing this instinct takes time and a deep context of your team and its business context. To help with this, I recommend this very thorough discussion: "How to figure out what the most important projects are?"
Lastly, here's our senior -> staff playlist: [Taro Top 10] Senior Engineer To Staff Engineer (L5 To L6)
