Scaling Up without Slowing Down

Watch this livestream from Wed Oct 29th, 2025 at 9 PM

Summary

Adding people doesn’t guarantee more output.
Sometimes it just guarantees more chaos.


Scaling a team isn’t like stacking Lego bricks. It’s more like piecing together a giant jigsaw puzzle — if you don’t know where the pieces fit, doubling the pile just makes it harder to finish.


So how do you grow without slowing down?


That’s exactly what we’ll explore with Inga Pflaumer on my upcoming LinkedIn Live.


🌟 Here’s What You’ll Discover:

  • How to keep your team performing as headcount grows.
  • Whether the definition of “scale” itself changes as you grow.
  • When (and how) to evolve team structures.
  • What to do if you’ve over-hired, under-hired, or made the wrong hire.
  • Why per-engineer velocity often drops—and how to keep overall productivity high.
  • How to anticipate communication overhead before it stalls your team.

💡 What you’ll leave with:

  • A clear framework for maintaining velocity through deliberate practices.
  • Confidence to shift from flat teams to specialized structures without losing startup agility.
  • Data-driven ways to hire (and fire) without relying on gut feel.
  • Early warning signs of bad hires—and the confidence to act decisively.
  • Systems to keep teams productive even as communication complexity rises.

If you’re an engineering leader this conversation will help you reframe scaling as more than “just more people”—and give you the tools to grow without dragging your team down.

Resources

DORA Metrics (DevOps Research & Assessment):

SPACE Framework (Nicole Forsgren et al.):

The Mythical Man-Month (Classic Book):


Team Topologies (Book & Community):



Transcript

[02:59] Welcome and Introductions

Andrew Murphy: Hello, good morning if it's morning where you are, good afternoon if it's afternoon, and good evening if it's evening. I am Andrew Murphy and welcome to another Tech Leaders Launchpad livestream. These are the events where I share the people that I learn from, the people that I get better by listening to. And that's no different today. Today I have Inga joining me. Welcome to the livestream, Inga.

Inga Pflaumer: Hello everyone. How are you? It is pretty early morning here in Sydney, so thank you everyone who's joined in from the same time zone.

Andrew Murphy: Yeah, it is early. I like to do these early so that we get a little bit of learning in before work. You know, things just get away from you. I like to do these at 8am because it's close enough to the start of the day. You don't feel like you're guilty for doing it. But you also, you're not caught up by your work email yet for sure.

Inga Pflaumer: It's hopefully after a first cup of coffee.

[04:08] Icebreaker: Favorite Tech Gadget (Not Phone or Computer)

Andrew Murphy: Speaking of coffee, I generally start these off with an icebreaker. The one that I normally like to use is: is there a tech gadget or something that you use on a daily basis that is technology related that isn't your phone or your computer? What's your favorite tech gadget you use on a daily basis?

Inga Pflaumer: I think you can guess just from my background, but it's probably my PlayStation or maybe my Xbox or maybe my Switch, but one of those devices because I'm a gamer and it's a good way for me to relax.

Andrew Murphy: Yeah, I love gaming. I recently, in fact a couple of days ago I installed a new cooler into my gaming PC. I hadn't realized how loud my old one was... my wife said, why is it so quiet? Is it turned on?

Inga Pflaumer: I generally just blame dust and dog fur that I have everywhere because I have a dog.

Andrew Murphy: Yeah, there you go. I have chickens. I can't really blame chicken feathers.

Inga Pflaumer: You can try.

Andrew Murphy: I can try. I think if I put my gaming PC outside with the chickens, it would be a problem. My gadget is this thing here, which is an electronic cup warmer... it's a game changer. I hate, you know, you're in that flow state and then you go and try and take a drink of your cup of coffee and it's freezing cold...

Inga Pflaumer: That's how you know you're in the flow state. That's a perfect indicator.

Andrew Murphy: Yeah, that's, we should put that on a rubric somewhere. Like, number of cold coffees per day is an indicator of your engineering velocity.

Inga Pflaumer: Oh, we'll talk a lot more about that, but we can start there.

Andrew Murphy: Awesome. All right, let's get into the topic then.

[07:07] Setting Intentions for the Livestream and Audience Participation

Andrew Murphy: If you're watching this, please don't forget this is a livestream. It's a livestream for a reason. Please feel free to ask questions. I've obviously got my list of questions for Inga, but a big part of these is you asking your own. My goal with these livestreams isn’t just for you to know something different—it’s for you to DO something different. The best way to make that jump is to ask a question that applies to your context. And with that, Inga, maybe give us a bit about your background and segue into our topic.

[08:29] Inga’s Background and Passion for Metrics-Driven Management

Inga Pflaumer: So I'm Inga. I have an accent. You get used to it. I made a conscious choice to keep my accent because apparently the Eastern European accent sounds authoritative, which helps in my job.

I switched to management about seven years ago, from the IC track—I was a technical lead. I loved solving technical problems, but the problems I was solving got too big for one person or team. That’s how I moved to management: to solve more difficult problems with more people.

One of my pet peeves is that as engineers, designers, or product people, when we release a feature, we discuss user journeys, what we’ll measure, and so on. But when it comes to teams, we just say, “We’ll hire people, then they’ll do something, and hopefully we get to some ideal state.” That’s illogical. As a software engineer, I love structured, logical approaches. That’s why I’m known as the metrics person—I metricize everything: engineering, velocity, teams, startups, scaleups.

[10:27] On the Value—and Misuse—of Engineering Metrics

Andrew Murphy: Metrics have gotten a bad rap because they’ve been used badly, but they absolutely add value. Still, a lot of engineers have a visceral reaction when metrics come up. In your mind, what’s the difference between effective and ineffective metrics?

Inga Pflaumer: First, honesty. Metrics should be open and a conversation. They shouldn’t be a surprise in your 1-1s—like “You had 7 PRs less last week.” Ouch. The important thing is to agree on metrics together; they should be collaborative, not pushed on anyone. Decide as a team what’s important. If you want thoughtful PR reviews, measure those. If you want to move fast, agree on how you’ll measure speed. Metrics should never be forced on a team. Used the right way, openly and collaboratively, they’re healthy.

[12:23] What Does 'Scaling' Actually Mean?

Andrew Murphy: That’s a healthy way of looking at it. So as we scale, we need to talk about what “scaling” actually means. It could be revenue, headcount, team numbers, architecture complexity, etc. Does scaling one thing impact the business more than another?

Inga Pflaumer: When we talk about scaling, we need to transform it into a “why.” Are we scaling our systems for more customers? Are we scaling our team because there’s too much work? Are we selling more so we need to build more? There should be a clear goal—not to just scale for the sake of scale. Hiring to hit a headcount target is a strange conversation to me. It’s not about the size of the herd (like a shepherd), but the skills people bring. So yes, “scaling” is always about adding more to achieve something specific.

[15:33] The Challenges of Scaling: Adding People Isn’t Linear

Andrew Murphy: Good analogy with the shepherd—number of sheep is almost linear with revenue, but in a software company, it’s not. I’ve seen teams go from 50 to 300 people and actually deliver less value after. What goes wrong when scaling a team?

Inga Pflaumer: You want to deliver more value, so you assume more people will help. But onboarding, knowledge sharing, and processes get complicated. If you add 30 people and your process was just “talk to this person,” suddenly everyone is always talking and getting context is a nightmare. People spend all day in catch-ups and fall out of context elsewhere. You need processes that scale. And you have to be intentional about your reason for scaling—don’t just add people without a clear goal.

[17:26] Cultural Clashes and the Importance of Honest Hiring Conversations

Andrew Murphy: Sometimes you hire frontend engineers, but suddenly need backend people later. How do you navigate those situations?

Inga Pflaumer: It’s important to have honest conversations, even when hiring. If you know you’ll expect someone to do backend later, be upfront about it. People who don’t want to do that will self-select out, and that’s a win.

Andrew Murphy: Losing a smart person who’s not a great fit can actually be a win—especially in hypergrowth phases where flexibility is key.

[21:18] Defining 'People-Shaped Holes' Instead of Headcount Targets

Inga Pflaumer: Especially in startups, needs change fast. I get asked what headcount I want to hire, but I don’t think in headcount. I have “people-shaped holes” in my org chart. At different stages, those holes are shaped differently (security, reliability, etc). Sometimes you need soft skills: an engineer who can talk to enterprise customers or mentor juniors. It’s partly art, partly based on actual needs.

[23:56] The Fallacy of Culture Transplants and the Perils of Forced Change

Andrew Murphy: I often warn that hiring a bunch of big-co engineers to “import” culture into a 100-person company doesn’t work. It’s not a tug-of-war that resolves; it’s just a culture clash.

Inga Pflaumer: A more experienced manager told me: don’t have teams balanced between two different cultures, or all they’ll do is fight about culture and nothing will change. Every team already has a culture, whether or not they can articulate it. If you bring in outsiders to change things, you need to be clear about what changes you want, and empower those people to drive it. Are you even sure you need it?

[28:07] Knowing Which Behaviors to Keep and Which to Let Go

Andrew Murphy: Some founders want to keep their early-stage culture forever, but that’s impossible at 200 people. There’s exponential growth in communication needs and required changes. Which cultural things do you have to let go of as you scale?

Inga Pflaumer: The key is to get specific about culture: culture is “behaviors.” Translate cultural values into observable behaviors you can measure or encourage. Some behaviors serve you at one stage but not the next—like being directly involved in every PR as a CTO. As the team grows, you can’t do that and have to let go.

[34:51] What Should You Measure When Scaling?

Andrew Murphy: We’ve touched on metrics—you light up every time we mention them. What’s important to measure when scaling, and why?

Inga Pflaumer: It depends on what you value and your stage. Metrics organize people but also get gamed—that’s fine, as long as you’re aware. Figure out the user journey you want for your engineers: what behaviors do you want? Quality? Speed?

There are well-known metrics: cycle time, lead time, incident resolution, bug triage. Pick which to care about and involve the team in setting them. But you need metrics over time to give context. For example, if bug count triples after a release, maybe delivery speed and quality are both affected. Share your metrics transparently and use them to start conversations.

[38:08] Good Metrics Are Transparent and Conversational

Inga Pflaumer: You shouldn’t come to a 1-1 and get blindsided by a metric you weren’t even told was being measured. If a new team’s merging everything without PRs and their speed looks good, it’s a discussion, not an immediate judgment. Metrics should prompt honest conversations, not be used for punishment or blind rewards. Define what “fast” means in concrete, measurable terms.

[40:21] Different Businesses Require Different Metrics: Always Ask Why

Andrew Murphy: The value and meaning of “fast” or “quality” changes dramatically between a bootstrapped scaleup and a VC-funded one. Why you measure something is as important as what you measure.

Inga Pflaumer: Exactly. Maybe 30 bugs a week is fine for a B2C self-serve startup—but it isn’t if you have enterprise customers depending on SLAs. Connect what you measure to where your business is and what it needs; don’t just copy-paste DORA or SPACE metrics unless they fit.

[43:09] Metrics as Culture: What You Celebrate Becomes Who You Are

Andrew Murphy: DORA/SPACE are starting points, but you need to connect them to the “why” for your company.

Inga Pflaumer: And metrics design can reveal what your team values—PR reviews signal one culture, PR quantity another. Which you celebrate is what you reinforce. That’s your real culture.

[44:02] Hiring for Cultural Alignment: It Starts in the Interview Process

Andrew Murphy: This makes me think we should be talking about measurement even in interviews, so candidates self-select based on what matters to them.

Inga Pflaumer: Yes. I always ask, “After two years, what will make you feel fulfilled here?” It tells me what they value, what skills they want to build. In a 100-person team, do you want one knowledge gatekeeper? Maybe not—that’s art and science.

[45:48] Avoiding Culture Fit as a Trap—Look for Culture Add

Andrew Murphy: “Culture fit” shouldn’t mean duplicating everyone. It’s about building on what you have, deliberately.

Inga Pflaumer: Right. It’s about culture add, and being intentional about who you bring in.

[46:54] Signs of Over/Under-Hiring and How to Course Correct

Andrew Murphy: Let’s talk about intentionality in hiring—how do we know if we over- or under-hired, and what’s the rubric for knowing when we got it wrong?

Inga Pflaumer: I don’t believe in “not hiring enough”—it’s more about “not hiring what’s important.” Hunt for skills, for “people-shaped holes.” I like having 30/90/120-day plans for new hires—not as a rulebook, but for direction and alignment. When expectations change, communicate it!

Use your existing metrics as a baseline. If you onboard more people and see delivery stall, look for root causes: too much time onboarding? Not enough documentation? Slowdown is normal during transitions but track why, not just how it feels.

[51:10] Using Subjective Metrics and Combining Feelings with Data

Inga Pflaumer: I’ve used subjective metrics—like engineers voting on how good they feel about deliverables or meetings. Layered onto objective data over time, this helps inform decisions and context. When teams feel worse, dig into why: big launches, incidents, or just a strange week? Don’t weaponize the data—use it to have better conversations.

[52:21] Can We Apply These Metrics to the CEO’s “Feelings” Too?

Andrew Murphy: Sometimes CEOs feel like velocity slowed as teams scale—should we gather CEO “feelings” alongside engineering data and look for correlations? If there isn’t one, maybe we’re not measuring the right things.

Inga Pflaumer: Yes! Gather data about feelings too, then drill down into the factual information beneath.

[54:56] Turning Data into Information: Context Is Key

Andrew Murphy: The difference between “data” and “information” is context. Raw numbers aren’t meaning—they must be linked to business goals and decision points.

Inga Pflaumer: Yes. Data by itself is meaningless; it’s for context and better choices. You can only decide what to measure if you know what you want to encourage or discourage. Always include the team in this conversation.

[56:19] Wrapping Up and Announcing Next Tech Leaders Launchpad Events

Andrew Murphy: We’re at the top of the hour—this hour always disappears! Thank you, Inga, as always. I have 20 questions and we got through about three, which is a success for me.

Next up on Tech Leaders Launchpad: I’ve got a livestream with Randall, who has just taken on their first role as a startup CTO. We’ll cover surprises in the transition from architect to startup CTO. That’s in about a month—27th of November.

Also, you’ll notice a new company name, Debugging Leadership. We’re rebranding and launching a platform for running Communities of Practice for tech leadership—a sort of kanban for learning journeys, with our content plus your own links, videos, and compliance training. If interested, scan the QR or follow our socials for more.

[59:58] Closing: Inga on Relevance and Automating Engineering Metrics

Inga Pflaumer: Please come and use the Relevance platform! You can actually build agents to gather all those metrics I talked about. We also just released Relevance Chat, which lets you talk to AI agents. Metrics can be boring—automate them and make it easier (and more fun)!

Andrew Murphy: I’ll take a look—anything that frees leaders from spreadsheets is worth it.

Thank you again, Inga, and thank you to everyone who joined. We’ll see you next time on a Debugging Leadership livestream.

Inga Pflaumer: What a cool name. Thank you so much. Bye bye.


Newsletter

Subscribe to get leadership tips, news and events straight to your inbox