October, 2021 blog, twitter, linkedin
Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do.
I am a Staff engineer at Medium and Team Lead of Payments. Payments is responsible for two core areas:
- Inflow of payments: enabling users to purchase membership and other products as smoothly as possible, supporting multiple payment providers globally
- Outflow of payments: paying Partner Program writers each month, calculating earnings, taxes and the systems to facilitate these payouts
This puts my team at a unique intersection of product and infrastructure. Along with delivering great user experiences, maintaining a high bar for security, preventing fraud and building trust with writers and readers is crucial.
Apart from these core areas, there are many initiatives like launching referred memberships, free trials, gifting that fall under the Payments domain. What excites me most about this domain is how much it is evolving both within Medium and in the world, especially in the context of creator economy.
As Tech Lead, I play the role of technical partner to product and engineering manager. I am responsible for ensuring our architecture choices in the Payments domain serve the organization’s future needs and for defining the technical vision for Payments team. I advise other engineering teams and cross-functional partnerships for both immediate projects and long-term alignment, mentor team members and improve team processes. I also delve into early research to test viability of project ideas and high level scoping.
How do you spend your time day-to-day?
I like dedicating specific days to certain types of tasks. When this isn’t feasible, I still do calendar blocking. I find it very helpful to segregate chunks of time especially when switching gears between long term vision projects, nitty-gritty of ongoing projects and coding.
During the initial phase of a project, a lot of my time is dedicated to writing or reviewing technical architecture specs along with cross-functional syncs with other engineering teams, product, design, and marketing to gain alignment. This transitions into planning for launch once things are in flux, like metrics to measure, rollout plan and organizing or delegating bug bashes. One of my favorite processes is a pre-mortem meeting with all stakeholders involved to anticipate what might go wrong and how we might address these issues.
Apart from this, the constants each week are coding regularly, reviewing technical specs and pull requests, team meetings (sprint planning, retrospective, standup) and a leads sync meeting.
What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?
As a founding engineer, I quickly learnt that high impact projects are more valuable than perfect execution on smaller scale projects. Even as I moved to a larger company, this view helped me stay focussed on thinking about how I can add more value to the engineering organization and company instead of following the growth rubric to a T or optimizing for short term wins. I like to use the 10/10/10 approach when thinking about long term decisions - how will I feel about this decision in 10 minutes? 10 months? 10 years?
Since early on in my career, I was consistently taking on things I had no idea how to do and with limited resources. Accomplishing these challenges over the years helped me build confidence to take on projects with larger ambiguity, which is a big part of a Staff Engineer’s role.
Visibility is an important aspect of getting to Staff. When describing projects and achievements, I found it immensely helpful to frame projects and achievements in terms of impact to the company instead of only technical complexity and direction. This is especially true when the audience is non-technical.
What’s your advice to people pursuing a Staff role?
Some tactical advice:
- Keep a record of things you’ve accomplished week to week, often known as a Hype Doc. I tracked what projects I worked on, my role in them, why the project matters, technical details, and most importantly what value it delivered to the company. Github PR links, screenshots and anything else that can add more details are also great to add. There’s no better person than you to give context for all your work, and this doc makes it extremely easy for you/your manager to put together a promotion packet.
- Instead of focussing solely on a Staff project, explore other ways of improving the organization like processes and such. A staff project is not a necessity by any means, but it can help establish domain or product area expertise.
Mindset shifts:
- Once it’s established that you can constantly execute well and deliver, the returns on committing code are diminishing. Focus less on committing code and more on technical architecture and project orchestration.
- The formal title is a lagging indicator of the role you’ve already been performing at. This is especially true for Staff where the role is still vaguely defined in most companies.
Some of Rebecca's writing
Do you spend time advocating for technology, practice, process or architectural change? What’s something you’ve advocated for? Can you share a story of influencing your organization?
Yes, along with empowering others to advocate for the technology or process changes they deem important.
When the company went remote in 2020, I started an Engineering Communications Initiative to address the growing communication gap. I set up an internal newsletter as part of this, approached some team members to come onboard as contributors and editors, and then grew the team to a diverse group of 5. The newsletter covered announcements and open opportunities, demos of what teams were working on, learnings from other teams, and People Spotlight which was one of my favorite sections!
I also put together a proposal for smoother team transitions and internal onboarding. I collaborated with many engineers across the org as part of initial research and feedback phases, and got this proposal approved and added to the engineering manager handbook.
Within the team, we have a process of verification which is much like reviewing PRs, except with a focus on product and user experience instead of code. At one time, the team was getting bogged down in this process so I revamped it to streamline things. The new changes also needed team members to have enough context which encourages us as a team to avoid engineering silos.
How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role?
Yes, I wouldn’t be here without the opportunities given to me and it’s one of my core values to do the same for others. It’s incredibly rewarding to see the people around me grow and thrive.
For me, sponsorship starts with good listening, being approachable and asking good questions to understand where someone’s interests lie. Prior to becoming Staff, it would look like sharing someone’s contribution that I found particularly helpful with a broader audience, making introductions, encouraging someone to participate in a discussion. Nowadays, I can create more opportunities and encourage people to grow into them. This can look like finding projects or tasks that would be growth opportunities for someone, nominating someone to be a project lead, or suggesting someone as DRI (Directly Responsible Individual) for org-wide initiatives.
With having more visibility in the org, I realized how even with a transparent culture where docs are visible to everyone, we need to push out information about new opportunities rather than rely on people to find these. As part of the internal newsletter I started, I shared these new opportunities widely and was happy to give a nudge of confidence to someone who was interested and just needed an extra push.
I remember thinking early on that only engineering managers or leadership could sponsor, but in reality it can come from anyone and in many forms.