This is our first panel discussion of 2021 and we're thrilled to share with you a conversation we had with three top managers!

In January 2021, we hosted a second successful panel discussion for Engineering Leaders! We invited 3 top leaders from Amazon, Stripe, and Immersive Labs, to discuss in an interactive environment various engineering topics such as high-performing teams, engineering metrics vs biz metrics, employee engagement, amongst others.

All the questions asked during the panel discussion came directly from our vibrant community of 250+ Engineering Managers. In this blog post, we will be sharing key takeaways about managing software engineers in high-growth environments but also how to convince business stakeholders to devote more time to engineering metrics. Enjoy!


Chris Newton, VP of Engineering, Immersive Labs
Smruti Patel, Head of LEAP and Data platform, Stripe
Nik Gupta, Software Development Manager, Amazon

Alignments & prioritization between teams in a high-growth environment


How do you handle alignments & prioritization of tasks between teams in a rapidly growing company?

Key takeaways

Panelists' personal feedback

It’s no mystery that scaleups are a tough environment for maintaining software engineering teams aligned and productive.

Managers and software engineers will often experience the pressure of fast growth over and over again in the same scaleup - whether it is from 30 engineers to x number of engineers, or later from x number to an even higher number of engineers and managers.

For Chris Newton, VP of Engineering at Immersive Labs, there are some grounding principles that can help you managing alignments and prioritization in scaleups.

Vision → “You need a clear, inspiring, and well-understood company vision that will be guiding every department in the business, not just product and tech. Underpinning that is going to be the product and tech side of things. You will have your product vision: 'what are we trying to achieve for our customers through the product'. Then you have the engineering vision that underpins the product vision. It is complementary to the product vision, and it supports it. The engineering vision & strategy lines up to delivering the best outcomes for customers through the product vision.”

It crucial to have a clear and comprehensible vision, but for Chris, other principles need to be looked into if you want to successfully manage your software engineering teams in a scaleup:

Transparency with goal setting → “Once you know where you’re going, it’s about how you’re getting there! That's really where objectives and goal setting is key, especially as you start to scale out. Cascading objectives framework, such as OKRs, can be a really powerful tool in terms of getting that prioritization and alignment right. It’s great to make a clear and visible link between what software engineers and managers are doing on the ground and how that then ties back up to top-level objectives.”

Communication → “In a high-growth environment, communication becomes very complex; especially communication of progress. Other teams need to know transparently how you're progressing with the piece of work that you're doing and this kind of flows into dependency management which gets harder as you grow. Scheduling becomes a thing you may need to look at putting in more processes as you begin to grow because there's just a need to have some kind of structure in place to enable decision making, sequencing of work, and to deliver the best outcomes for the business as efficiently as possible.”

Nik Gupta, Software Development Manager at Amazon, also highlighted the importance of taking the necessary time to get the basics right when it comes to OKRs.

“Without going into much specifics, the third to the fourth quarter, we spend about two months just getting our metrics right. Literally, just figuring out what are the right metrics we should track worldwide - are they instrumented, are they reliable, and how would we validate them, etc. It is absolutely essential to get that framework built before you start delving into 'what projects are we going to do and why.'”

Answering a question by Smruti Patel, Head of LEAP and Data Platform at Stripe, about bad OKRs, Chris briefly shared with us 3 anti-patterns - click the number next to each anti-pattern to learn more!

  • #1 - Void between top-level objectives and team objectives
  • #2 - Misalignment of OKRs between departments
  • #3 - The importance of drafting inspirational OKRs

Further resources

Convincing business stakeholders to devote more time to engineering metrics


How do you get buy-in from business stakeholders to manage tech debt specifically? And in general, how do you convince business stakeholders that they should devote time to engineering metrics along with new product features?

Key takeaways

Panelists' personal feedback

As discussed in a previous blog post, tech debt is an inherent part of what engineering leaders need to manage. It is crucial to incorporate technical debt into a roadmap and communicate openly with your software engineers to understand what is going on and try to find some proxies to objectively measure tech debt.

For Nik Gupta, Software Development Manager at Amazon, tech debt is a practical problem that every engineering function faces. The most important step before convincing business teams is to have a clear understanding of your tech debt and see if it is worth resolving.

“You need to be able to demonstrate that by not solving a particular problem (hard coding, manual process, etc.) it will decrease your overall agility, or lead to churn on the team because you must do that manual process every x days or x weeks or x months, or that it leads to operational load in the sense that it leads to an increasing volume of on-call tickets or high severity incidents.”

Adding to that, Nik also specified that quantifying these with the right metrics will be part of the demonstration - you also need to spot the metrics that speak to your business stakeholders:

“Take all the data that will get you some tangible material about business costs to the organization, distill them in a crisp summary of the impact on customers, business, your teams’ agility, the operational cost, your quality of life [...] and also find the patterns which talk about why an engineer or a particular team says their life is not good because of all the operational costs they have to bear. If you believe it’s the right story to look at, you are looking at the right metrics and you can present that analysis to your non-tech stakeholders.”

There’s definitely no cookie-cutter, and as Nik explained, his team at Amazon has also adopted another mental model:

“We acknowledge that no team, no world, no company is perfect and there will always be tech debt that is unknown, which we don't know about and we will discover as we go along. In this case, we strike an agreement with the business at times is that over this year we will block 10 percent of our capacity to address those things as they come along.”

It seems clear that for managers, building a strong case takes time and must be structured well throughout the year by gathering the right data. For Smruti Patel from Stripe:

“Owning that narrative and using qualitative and/or quantitative metrics to be able to talk about, and demonstrate, the cost of tech debt to the organization, in the long run, is something that really resonates with me. Tech debt, and the investment you make in tech debt, typically comes at the expense of the business in terms of for example future velocity or go to market - so I like the idea of being strategic about it and helping drive predictability in the long run by quantifying it and that through a story and a narrative.”

Communication with stakeholders goes beyond tech debt, Engineering Managers need sometimes to make their case for other engineering metrics and priorities. So how do you convince your business stakeholders to devote time to engineering metrics in general?

During the conversation, Chris shared with us what an engineering manager needs to clarify before getting buy-in for any engineering metric.

What's the stage of growth of your company, the business model, and the characteristics of your industry. For example, as you kind of hit the scaling phase, like Immersive Labs I'm working for now, at that moment you need to think about a transition and this shift towards engineering excellence. You focus on stability, security, and scalability as you go. Are you in a B2C model where for example stability is directly attributed to revenue impact? [...] You really need to understand what you're operating in and where those parameters come up from.”
“Regarding metrics, you really want to understand what your customer experience is, what drives customer experience and how do they correlate with engineering metrics.”

Chris also gave an insightful example with SRE, site reliability engineering!Data - quantifiable information: “Data helps massively, so once you've got a view of those metrics you can quantify the customer experience through those metrics and quantify things tangibly like revenue impact. Let's say that your target is 99.5, or 395 availability, but you're only hitting 99.2; if you can quantify that into a business impact, that's the best way to talk to your business stakeholders to make a case for why that investment is going to have a massive impact.”

Smruti Patel, Head of LEAP and Data platform at Stripe, also shared two different kinds of experiences she had regarding how to determine the right set of metrics for business stakeholders.

At LEAP, the Latency, Efficiency & Performance engineering team: “The metrics here are more tangible, it's easier to measure how much you're spending on your infrastructure or how much time the customer waits when they make a request.”

However, with the teams working on data infrastructure:

“ some of the inherent qualities or principles from the platform, or that the internal users require, are security, reliability, availability, and leverage in terms of product enablement - which then enables stripes users - identifying the right set of metrics for infrastructure work has been a challenge. Specifically in terms of how do you communicate to the business, especially as your internal user cohorts vary within the company itself. That's something we still sort of work in progress and trying to see what we can leverage from LEAP.”

Smruti also pointed out that “historically, it's easier to have metrics when you're building products in terms of customer experience -- translating that to your customers being your internal customers, treating our internal users as customers, is slightly harder when you're building out infrastructure or platforms.”


  • Interesting blog post by Camille Fournier (seems sponsored) on what CTOs should measure and how to sync with non-technical CEOs
  • Connecting business and tech debt, why not check what a leading consulting company suggests: Tech debt: Reclaiming tech equity
  • Published in 2015, this article by Paul Ford is relevant because it depicts what the others’ perspectives on what “tech teams” do
  • 'What' & 'why': questions EMs should be asking themselves when managing software engineers. Neat blog post by Mathieu Bastian, Director of Data Science & ML at GetYourGuide.

Every three months, we invite Engineering Leaders from around the world to join an online panel discussion for all things related to their software engineering teams, engineering workflows, and even metaphysical questions that might affect our daily lives! In these online discussions, you will have the opportunity to ask questions across any of the topics listed during the event. In this blog post, we've written about some of the topics discussed last January 2020.

“How to manage low performers during the pandemic?”

This is one of the questions that will be touched upon in the second part of An online discussion with Engineering Leaders, for Engineering Leaders! The upcoming blog post will be transcribing what our panelists had to share about high-performance, low performers and how to sustain motivation and engagement. See you next week!