Leaders are made, not born. It's also true for software Engineering Leaders. This is what we believe we are depicting through our Q&As with some great software Engineering Leaders around the world!

Their diverse professional and personal backgrounds point to the importance of self-reflection and perseverance. Each Engineering Leader has their own interpretation of what key factors can help you become a manager that leads with empathy, and inspires software engineers.

Some of them will even share their most stressful moments with us; from managing engineers to managing managers!

In today’s interview, we’re particularly excited to share with you our conversation with Swarup Karavadi, currently Engineering Manager at Postman. Enjoy!

Could you tell us about yourself and your professional journey?

I am an Engineering Manager at Postman. I work with product teams to ensure we frequently ship value to our users while maintaining a high level of engineering maturity. I have 13 years of experience building and shipping software on the web. I’ve tried my hand at setting up multiple startups and failed spectacularly - they’ve been a formative experience in my life - both professionally and personally!

What made you decide to become an Engineering Manager?

From my experiences and failures, I learned that there is so much more to running and growing a successful product than just programming. Product development is a team sport.

Anything that is worth building takes a village.

Once I realised this, I wanted to increase the scope of my impact and that’s what led me to become an Engineering Manager. This is not to say that individual contributors cannot have a broad scope of impact. They often do. Enabling ICs to create that impact is what separates the great Engineering Managers from the good.

What advice(s) would you give to a software engineer that is considering becoming an Engineering Manager?

Based on the interactions I’ve had with software engineers, the deliberation on becoming an Engineering Manager happens when they start getting good at playing the role of technical lead and start wondering what’s next. The tech lead role tends to have an overlap with what Engineering Managers do, but the roles are quite different.

I would encourage folks to check out the spider charts here & here to understand the differences between a tech lead and an engineering manager.

As an Engineering Manager, how do you delegate effectively?

I don’t delegate. Delegation implies the existence of authority. Existence of an authority implies members of the team feel disempowered. You can delegate work, but you can’t delegate outcomes.

As an Engineering Manager, I choose to empower team members instead of delegating authority to them. I utilise rituals like 1:1s and sprint retrospectives to get insights into my team’s sense of agency. In areas where I find it lacking, I try and understand if it’s an issue with the individual or an issue in the environment and initiate a course correction accordingly.

What is the role of an Engineering Manager?

Apart from the usual suspects like owning the vision, recruitment, onboarding, people management, scaling a team, etc., I’d like to refer to what Will Larson describes as the four stages of a team in his book The Elegant Puzzle - Falling Behind, Treading Water, Repaying Debt, Innovating. I look at the role of an Engineering Manager as moving teams to a stage where they are innovating.

What is the hardest lesson you have learned as an Engineering Manager?

That I need to get extremely comfortable with the feeling of being uncomfortable. Dealing with ambiguity is central to the role of an Engineering Manager - Will this feature be shippable by this date? Does the Tech Lead buy into the vision of the team? How do I help an engineer whose performance has tanked? How do I negotiate scope? How do I resolve conflict? Is my team happy? You get the idea.

I realised that once I got comfortable with ambiguity, it helped me disambiguate. I used the feeling of discomfort as a feedback loop to improve processes, set up rituals, and have difficult conversations. Having a set of first principles that you can use to navigate ambiguity definitely helps.

How do you enable knowledge sharing, and aligned decision-making across, multiple teams, especially during remote work?

I must admit this has been a difficult thing to do. I’ve been part of initiatives that required multiple teams to collaborate. In a couple of these initiatives, we have been able to deliver a quality product on time. There have also been instances where the initiatives didn’t go as well as we would’ve liked.

While there is no silver bullet on driving cross team initiatives successfully, there was a recurring theme in the initiatives that didn’t go well - there were too many last minute surprises that delayed releases. These surprises stemmed primarily from a lack of shared understanding of scope, priority, ownership and even product behaviour.

In the initiatives that did go well, we kick started the cross team collaboration way ahead in the game. Engineering Managers & Tech Leads started getting involved in the middle to later stages of product discovery. By the time we started delivery, teams had a clear understanding of what was expected, ownership boundaries and clean interfaces between the teams. A dedicated slack channel for the initiative and weekly synchronous check-ins helped with the remote situation.

What metrics have you found most useful for teams to measure their performance?

Performance is a very subjective term. I do not think we can reduce the performance of a team to a metric(s). There are so many intangibles. A team almost never exists in isolation, it almost always operates within a larger ecosystem - any metric we use has to factor this in. Having said that, it helps to have a metric(s) that is indicative of a team’s performance so that a baseline can be set and continuous improvements can be made. I measure cycle time and lead time. I use cycle time (time spent in one phase of delivery) to baseline the performance of the team and lead time (total time to ship to production - from inception to delivery) as an indication of the overall org performance. For example, if a product feature has a high lead time, I look at which cycles it has spent most time in. If the time spent in design review is high, but the time spent in development is low, then I know this is a problem that has to be addressed elsewhere in the system. If the time spent in development is high, then I know there’s scope to improve there.

Eventually though, I’d like to get the teams I work with and the rest of the org to a point where we can start measuring DORA metrics.

Often Cross-team collaboration is beneficial, but how do you balance this with a culture of team ownership, where a team is responsible for releasing and supporting their own code?

This is a hard problem to solve. In my experience, if there is too much friction in cross-team collaboration, it is usually an architectural smell. As much as possible, we should align teams along product architecture and not architect the product so that we end up shipping our org structure to the customer (Conway’s law, Inverse Conway maneuver). While the short term hack for this situation is for an Engineering Manager to form partnerships, coach the team and incentivise the right behaviours, one long term solution is to utilise strategic domain-driven design so that teams don’t have to step on each other’s toes. Having said that, strategic DDD is no silver bullet either. Beyond a certain scale, you have to get people to collaborate - you have to figure out how to make this happen without too much friction. And that’s where setting up processes and framework for collaboration really helps.

Would you encourage teams to include tech debt in their backlogs & make it visible to POs, etc.?

Absolutely. The product manager is the engineering team’s partner in the truest sense. I don’t see any good reason why a product manager should not be privy to the different workstreams the engineers are working on. A good product manager understands tech debt. Fixing tech debt and shipping more value to users are not mutually exclusive. Both can happen simultaneously. The amount of tech debt in the backlog is also an indication of the stage that the team is currently in. The product manager can use this signal to understand engineering bandwidth and manage any external communications and expectations.

In this new blog series, we are aiming to share useful personal stories to inspire software engineers to take the leap to management. But also, as pointed out by some of our interviewees, the insights shared will be useful for other Engineering Leaders looking for new perspectives on all things related to software engineering workflows, software development, team management!

Swarup's interview was particularly insightful, thank you for sharing about your background, what led you to become an Engineering Manager, and for sharing your perspective on some tough questions! 👏


About our Q&As with Engineering Leaders
Every two weeks we will be sharing a personal interview with some great Engineering Managers, Directors, VPs, and CTOs. We are lucky to have a vibrant and dynamic community and it would be a shame not to share these experiences and insights with the small but growing world of Software engineers and Engineering leaders!

If you’re looking to join our weekly intimate roundtables or if you’re interested in sharing your perspective on the topics we’re covering, click here and see you soon!