Office Hours: I led the payments engineering team at WhatsApp and now lead the Engineering team at Modern Treasury. I’m Shruthi Murthy. AMA!Featured

Hi everyone!

I’m Shruthi Murthy, Head of Engineering at Modern Treasury where we’re building a payments platform to power money movement for businesses. Currently the Modern Treasury platform reconciles over 2.8B dollars in transaction volume every month.

Prior to joining Modern Treasury, I was an early engineer at WhatsApp, and witnessed it grow, through many points of scale, to become one of the largest consumer apps in the world. Most recently, I led the payments engineering team at WhatsApp.

I have come to recognize the differences and similarities between building payments in consumer applications and enterprise software. The biggest commonality is that payment flows are on the critical path for consumers and businesses alike. Building a reliable and fault tolerant payments platform while working with multiple entities and partners is crucial. It has definitely been a challenging and fulfilling experience scaling and building resilient teams that can work on these hard problems to prioritize the stability of the product.

When I’m not thinking about scaling the product and the team, I spend time cheering for the Warriors with my family, walking and waxing philosophical with friends, and most recently learning to play the drums.

I’m excited to be meeting you all through Elpha’s Office Hours. Ask me anything about leading an engineering team (large or small), working at big tech versus startups, standardized APIs, what makes me thrive at work, or anything else!

Thanks so much for joining us @shruthim!Elphas – please ask @shruthim your questions before Friday, July 29th. @shruthim may not have time to answer every questions, so emoji upvote your favorites 🔥👍🏾➕
Thank you very much for having me here. This is such a delight. And what a great set of questions!
“Scaling and building resilient teams”- what would you describe as best practices, particularly with regards to startups and managers? I’ve not seen a lot of startups that do a great job balancing the need for IC contributions while also honoring the amplifier that good management can bring.
Oh boy, this is a tough one. The best practice is to empower both IC’s and managers to create the best products. A manager’s main role is to build healthy high output teams. An IC’s role is to build high quality software. Set up your managers to optimize along 3 axes – product, process, people. Empower your IC’s along 3 axes – engineering productivity, technical decision making, and collaboration. And good teams are created by having a strong partnership between both roles.
I'm at a startup currently and our engineering team in particular is really struggling with hiring diverse candidates (particularly in terms of gender). At our recent all hands it was reported that the engineering team is 92% male! The good news is they are being so open and transparent about this. Do you have any suggestions I could pass along to our engineering hiring team for how to enable better gender equity in the hiring pool and practices?
I think you make a good point. As the percentage of women entering the tech field each year is extremely low, there will continue to be a gender gap. Ultimately, it's not the fault of any tech company, but rather our own. Therefore, it’s important to keep encouraging women to join the tech world.
As hiring managers, it's our responsibility to build a diverse team. I was not getting good success when I was relying on my company's recruiters as they had multiple roles to support. I started reaching out to female candidates via LinkedIn and via my network. I am thankful to @DianePrince who connected me with Elpha!
Thank you for asking this question. One practice I have found useful is for the engineering and recruiting teams to work together to create a diversity roadmap. The roadmap charts a quarter over quarter plan for – attending diversity-focused conferences, hosting events, or doing other community outreach. It could also include sponsorship or registrations to various diversity programs such as Code2040 or even this very platform, Elpha. Such efforts will enable the team to vastly improve the diversity at the top of the hiring funnel. Over time the roadmap should include goals for hiring and also for retaining and growing a diverse team.
Thanks for the suggestions! I'll pass these along to the engineering team. :)I particularly like the idea of a diversity roadmap and I am confident they will too!
1. How do you manage stakeholder deadlines against third-party timelines? 2. Should the current focus be on growth or stability for people working in this industry? As in, hunker down on what we do best or explore new opportunities?
Good questions. 1. You align on the principles that the product and teams uphold and work those into your estimation process. For example: Set expectations that a large scale product or core infra improvements must ship with a hiqh quality bar. But there may be a case to allow newer products to iterate and ship quickly while making sure to earmark time and resources to work on quality efforts right after. Set expectations across stakeholders and third-parties. Treat third-parties as an extension of your team. Build relationships and a common understanding that gives you the ability to discuss timeline vs quality tradeoffs to resolve contentions.2. That’s a very personal decision. If you want to pursue a new opportunity, make sure you absolutely align with the vision and mission, and make sure you are building with people you like. Even if it fails because of macro conditions, you will have at least spent time building something that appeals to you, and learning alongside people you like. The other practical thing to consider is your risk appetite before making any big changes. Hope this helps.
Hi Shruthi ! I'm curious to learn more about Modern Treasury's journey, what sparked the idea and how did it grow from starting out to reconciling an incredible volume of monthly transactions today? Also, what would you say are some of the biggest engineering challenges when building a payment platform and how do you develop to overcome them?
Great questions. This podcast from our CTO, Sam Aarons, talks about the genesis of the company and growth. second question deserves a talk of its own but I’ll attempt to summarize – Payments products are integration projects spanning several systems and entities (app, processor, network, bank etc). There is no room for error in money movement when stringing along these somewhat disconnected systems. That is the biggest challenge. Building reliable systems and choosing reliability over speed is extremely important. Building fault tolerant work flows to manage error conditions and edge cases is as important as supporting the happy paths. Building API’s that are RESTful, backwards compatible, upholding data consistency and integrity guarantees is critical.
Hi Shruthi! Thanks for the taking time out of your day to answer questions. :)I'm curious to know:1. What do you remember being the most challenging about working with a product management function for first time? If you could go back in time, what do you wish you, your product partner-in-crime, or both of you had done differently?2. What motivated you to learn the drums? And what other instruments do you play, if any?
Nice, one interesting and one fun question! I'll try to answer your first question based on what has worked for me.1. I would say these are the important rules of engagement between product and eng – a) having a clear product vision b) aligning on product principles and strategy c) having clear owners, decision makers and accountability for day-to-day work. I would also say validating each other's decisions and being unafraid to ask hard questions is important. And at the same time taking a stance and having a clear decision maker to not get stuck in endless debate. I think the most challenging situations for me have been when I did not have these insights and more or less did the opposite of what I said above. 2. Haha, thanks for asking. Female drummers and DJ’s are so rare and I have always wanted to be that cool (I wish!). Drumming gives me a chance to improve my hand-eye coordination and sense of rhythm. I’m very much a novice though. It has only been a few months since I started.
Thank you for being here, @shruthim! My Q is how would you recommend structuring the eng and prod team at a growth stage start-up? Our CTO is not a 'product person' (self described) and we don't have a CPO yet. Often I feel like the product voice is a huge handicap for us. We do have a head of product but I want to make sure that the reporting structure is right to allow her to have the influence we need. TYIA!
Yep, product/eng dynamics are very crucial if you want to build a product focused company. Here’s my 2 cents although your mileage may vary– It’s critical to have the engineering team be completely aligned with the product priorities. To do that, the Head of Product and CTO would have to understand each other’s strengths and set up clear ownership, prioritization, and decision making between themselves and the rest of the company. As for the team structure, some companies choose to structure teams by the platform they work in. That could be very effective if you are building on top of several native code bases such as iOS, Android, Web, Desktop, multiple server-side codebases etc. Some companies structure teams by product lines and nest platform work within the product lines. Most are a hybrid of both. An important aspect here is to continuously but carefully tweak the structure to minimize day-to-day dependencies and operational overhead between teams, and maximize parallelization and throughput from teams.
This is very helpful, thank you so much, @shruthim!
Hi Shruthi! Where do you go to get a sense of community within Engineering? How do you connect with like-minded people? Are there some online or in-person communities you recommend?
Great question. Finding your tribe is definitely important. The answer to this question depends on the type of community one is looking for and one’s own capacity to be present and to nurture meaningful relationships. Exactly like a gym membership that I have registered to but may or may not be using. ;) Jokes apart, I know several women who like to be part of larger communities such as Grace Hopper or Anita Borg where there is something for everyone. Some engineers prefer more niche focus groups such as LUGs (Linux User Groups), Girls who Code, or Women in Cybersecurity for example. It’s also valuable to create a women@ group within your own company to discuss company specific issues, or more macro issues, or to simply get together for fun activities such as hikes, book clubs, photography etc.
I'd love to know your experience at big tech vs. startups. In my experience, startups have been exhausting. But I've experienced massive micromanagement at both places. Which do you prefer?
Interesting question. Like you said, I don’t know if micromanagement is an attribute of startups or large companies specifically. Micromanagement is a side-effect of the culture of the company. Find companies that have built and scaled a culture that provides people the space, and empowers people to fail fast, make mistakes, learn, and grow. A good manager is good at evaluating when the stakes are high to step in to set direction (so the team is not repeatedly off-track) and when to step back. Ground beneath your feet, wind beneath your wings, and all that.
What influenced your decision to leave a big company and join Modern Treasury? If you were considering other start-ups, what made this company stand out?
Good question. I was at WhatsApp when we were much smaller than Modern Treasury is today. I really enjoyed working with a small team and building a massively impactful product during my time there. I wanted to go back to that early stage, build large scale products with a small team, and grow along with the company. And that's why I chose Modern Treasury. You can read more about why I joined Modern Treasury here.
Thank you for hosting office hours! Really excited to have you join us.You have lots of experience scaling both product and team, what are your top 3 rule-of-thumb/tips to do that?
Great question. This is something I think about all the time. My top 3 rules of scaling are – 1) Focus on reliability. There are no two ways about it. An unreliable product will not scale. It will crash and burn. Define what reliability means to your product early in the lifecycle and continue to hone it over time. Reliability metrics may be developed from quantitative signals of course but also from qualitative signals like customer reviews or even the intuition of a strong engineer on your team.2) Enable developer productivity and velocity with the right abstraction layers, testing frameworks, monitoring, tooling, release management etc. Evaluate ‘buy vs build’ options rigorously. Tools and workflows should enable engineers to perform complex or repetitive tasks easily with high accuracy. Prioritize testing and ship high quality products.3) Scale the team NOT just by numbers. Scale the team efficiently. Create an optimal composition of skills, interests, areas of expertise, diversity, redundancy in the team, and most importantly build a team that enjoys building with one another.