A window into tomorrow's software organizations through conversations with visionary engineering leaders who are redefining the profession. Join us to explore how leadership will evolve, what makes high-performing teams tick, and where the true value of engineering lies as technology and human creativity continue to intersect in unexpected ways. <br/><br/><a href="https://maestroai.substack.com?utm_medium=podcast">maestroai.substack.com</a>
High Output: The Future of Engineering
Claim This Podcastby Maestro AI
5.0(2 reviews)
18 episodes
Updated Daily
Accepts GuestsHas Sponsors
24
Podcast Authority
BetaPoorBased on show quality, social media presence, reviews, charts, and more
Quality10
Social0
YouTube64
Engagement32
Podcast Overview
A window into tomorrow's software organizations through conversations with visionary engineering leaders who are redefining the profession. Join us to explore how leadership will evolve, what makes high-performing teams tick, and where the true value of engineering lies as technology and human creativity continue to intersect in unexpected ways. <br/><br/><a href="https://maestroai.substack.com?utm_medium=podcast">maestroai.substack.com</a>
Language
🇺🇲
Publishing Since
5/21/2025
Unlock The Full Podcast Authority Score Report
See how your podcast performs across key metrics
24
Podcast Authority
BetaPoorBased on show quality, social media presence, reviews, charts, and more
Quality10
Social0
YouTube64
Engagement32
7
Excellent Areas
1
Good Performance
11
Growth Opportunities
excellent
Episode Length
35 minutes
Performing excellently!
good
iTunes Tags
6.5/10
Recommendations available
Unlock the full report to see detailed tips
needs improvement
Publishing Consistency
Every 16 days
Recommendations available
Unlock the full report to see detailed tips
+16 More Metrics
Unlock comprehensive insights including:
- • YouTube presence analysis
- • Social media reach metrics
- • RSS compliance scoring
- • Podcast 2.0 features
- • Technical standards
What's Included in Your Full Report
Detailed Analytics
- Complete breakdown of all 19 authority metrics
- Personalized recommendations for each metric
- Industry benchmarks and comparisons
- Technical RSS feed analysis and compliance scoring
Growth Strategies
- Step-by-step action plans for improvement
- Quick wins to boost your score immediately
- Pro tips from successful podcasters
Get your free podcast insights report
See how your show performs across every key metric
Instant delivery
No spam
Attract Better Guests
High authority scores make your podcast more attractive to industry leaders and influencers who want to appear on credible shows.
Secure Sponsorships
Sponsors look for podcasts with proven authority and engagement. Your score demonstrates your podcast's value to potential partners.
Grow Your Audience
Understanding your strengths and weaknesses helps you make data-driven decisions to expand your listener base effectively.
1 verified contact email on file for High Output: The Future of Engineering
Pitch yourself as a guest, propose sponsorships, or reach out directly to the host.
Recent Episodes
July 25, 2026
AI Fails Like We Do
<p>Ten minutes into our conversation, Sylvain Kalache drafted me into a role-play. “Let’s say I’m the SRE and William, you are the developer,” he said. Production is down. He runs git blame on the broken microservice and finds my name. “Hey William, how about you come sit next to me, or let’s jump in a Slack channel — maybe you can help me solve it.” That’s the oldest move in incident response: find the author, sit them next to the problem, let what’s in their head speed up the debugging. And git blame will still find the author fine. What it can’t find anymore is an author who knows the code. “But now with GenAI, you actually may not know what you wrote, because you prompted an AI assistant to do it.” </p><p>His summary: “Potentially more incidents, and also less help when you have to troubleshoot something.”</p><p>Sylvain has been on the receiving end of that pager for most of his career. He started out building private clouds in France before public cloud was really a thing (“crawling in data center floors, passing cables”), then joined SlideShare as the SRE practice was first emerging, and rode the acquisition into LinkedIn, where he spent three-plus years as a senior SRE. Along the way he co-founded Holberton School, an engineering school with no teachers and no lectures that has trained thousands of engineers across more than 25 countries. Now he runs AI Labs at Rootly, the incident-response platform, where his job is to prototype what AI can do for reliability. “It’s kind of a constant hackathon,” he told me. Sylvain hedges everything he hasn’t verified, flags his theories as theories, and, as it turns out, will happily tell you about the time his own conference talk fell apart on him.</p><p>The bummer</p><p>Last October, Sylvain gave a talk at <a target="_blank" href="https://www.usenix.org/conference/srecon25emea/presentation/kalache">SREcon</a>, the conference where the reliability community compares notes. When he sat down to prepare it, the plan was to catalog all the novel ways generative AI breaks production: have some fun with AI slop, watch the LLMs fail, name the new failure modes the industry needed to worry about. The plan didn’t survive the preparation. “I was really trying hard to find new failure cases,” he admitted. “To be honest, I didn’t find them, which was a bummer, because my entire talk was about that.”</p><p>It’s not that he found nothing. If you ask a coding assistant to write a unit test for code it just wrote, “it will write a unit test replicating the already broken code.” There’s slopsquatting, an attack that at least sounds brand new: LLMs hallucinate package names, attackers register those names and fill them with malicious code. In <a target="_blank" href="https://www.lasso.security/blog/ai-package-hallucinations">one experiment</a>, a researcher registered a hallucinated package name with a dummy library, and it was downloaded thousands of times in a matter of months and cited in README files across GitHub.</p><p>Then he showed the list to a friend, an SRE leader at Airbnb. The reaction he got back: “Boy, I’m pretty sure that humans do the same type of mistake.”</p><p>So Sylvain checked. Slopsquatting is blindly pulling in a package you’ve never inspected, and we already do that: it’s curl | bash, which we’ve been piping into our shells for decades and which, he pointed out, is still how Docker recommends you install it. AI agents hallucinating their way into deleting someone’s files? “We’vebeen ding rm -rf by mistake, using root.” One by one, the novel failures paired off with old habits, and what he was left with was the opposite of the talk he’d planned: “The way that LLMs are failing is stuff we’ve been doing for the longest time as humans.”</p><p>On cats and LLMs</p><p>The strangest example he brought up involved cats. <a target="_blank" href="https://arxiv.org/abs/2503.01781">Researchers</a> gave an LLM a problem statement with one irrelevant sentence appended: cats sleep for most of their life. With the cat fact in the prompt, the model was something like 40% less likely to solve the task correctly. The machine gets distracted — and nobody needs a study to prove that humans do too. “As you know, you also get distracted,” he said. “Cats are the most important thing on the internet.”</p><p>By this point it was all starting to sound a little too tidy, so I pushed on the example that seemed most machine-shaped: the lazy unit test. A human could write a test that just ratifies their own broken code, but a human who generally likes their job mostly doesn’t. Isn’t that a class of failure that’s simply more prevalent in the machines? Sylvain didn’t defend the thesis. “I think what you described is absolutely true, but I’m not sure if the issue is the LLM or the prompt.” The chaos of LLMs, he pointed out, is that they’ll produce something no matter what you give them: “whatever prompt you give them, it’s gonna work.” And the gap between a good prompt and a bad one is enormous. His own <a target="_blank" href="https://github.com/Rootly-AI-Labs/sre-skills-bench">benchmark project</a> found that <a target="_blank" href="https://rootly.com/blog/benchmarking-llms-for-sre-tasks-boosting-sonnet-4-5-performance-by-100">prompt optimization alone</a> could double some models’ performance on SRE tasks. So maybe it’s a new failure class, or maybe it’s an old one: garbage instructions, confidently executed. He wasn’t sure, and he said so.</p><p>V times P</p><p>What he is sure about is the arithmetic. For the talk, he deconstructed incident rate into two numbers: V, the volume of changes to a system per unit of time, and P, the probability that any one change breaks something. AI is driving V up dramatically; that’s the whole point of it. Hold P anywhere near constant and the conclusion writes itself: “The incident rate will drastically grow.” Then he immediately fenced it in: “That’s actually the theory on paper. I’m not saying this is happening.”</p><p>The concern survives the hedge, though. Even if AI’s mistakes are our mistakes, “it’s doing it at least 10 times faster.” The failure modes are reruns; the throughput is new. The guardrails SREs have spent the last ten or fifteen years building (test coverage, deployment gates, observability, chaos testing, capacity planning) were designed to catch mistakes made by unpredictable humans, and in Sylvain’s telling that work is “not becoming obsolete, but more important than ever.”</p><p>He also thinks the same force pushing V up can push P down. Mutation testing has been around for years without much adoption; throw an LLM at it and it scales. He pointed to Meta’s <a target="_blank" href="https://engineering.fb.com/2025/02/05/security/revolutionizing-software-testing-llm-powered-bug-catchers-meta-ach/">published work</a> on <a target="_blank" href="https://arxiv.org/pdf/2501.12862">LLM-powered mutation testing</a>: roughly 10,000 mutants generated across the Facebook, Instagram, and WhatsApp codebases, around 500 generated test cases, three quarters of them approved by engineers. Run the two effects against each other and “it might equalize, or we might even end up with better reliability at the end of the day.”</p><p>The dream machine</p><p>There’s a portion of his community that wants nothing to do with any of this, and he role-played them too: “I’m not touching systems that are non-deterministic. It’s absolutely against everything I’ve been doing. And now you’re telling me to use this dream machine.”</p><p>His answer to the skeptics was the closest thing the conversation had to a thesis. “Humans are unpredictable. We’re non-deterministic.” Every guardrail in the SRE canon exists because the industry already learned to run reliable systems on top of unreliable authors. The blameless postmortem, trust-but-verify, defense in depth. None of it assumed the code’s author was trustworthy. “We’ve already been doing this with humans,” he said. “It’s trust but verify. Make sure that whatever they do is fine.”</p><p>That’s why the failure mode he’s actually worried about is cultural, not technical. He told me about a consultancy that surveyed engineers at a bank about their outages. The answer that came back: “It’s not my fault. GenAI wrote that.” One survey, one company, he cautioned. But if one engineer says it out loud, others are thinking it. “There is an erosion of the ownership of the code base, which I think is totally wrong. And I think engineers need to start thinking more as SREs.” His suggestion is concrete: don’t just accept what your assistant writes. “How about using another model to judge your code?” The blameless culture survives the agents fine. What can’t survive is blameless sliding into ownerless.</p><p>SEV2, maybe SEV1</p><p>Fifteen years ago at LinkedIn, annoyed by repetitive incident work, Sylvain wrote up a concept for a system that would learn from logs and signals and heal itself. “We have all these signals, all these logs, all this data — we should be able to learn from that and correlate.” Machine learning wasn’t good enough to build it. His employer patented it anyway (“that was not really my goal, but my company was like, hey, we need to patent stuff”), and he moved on to found a school.</p><p>Now he’s at Rootly watching the industry build the thing. The tools are called AI SREs (he knows people hate the name — Rootly wrote a whole <a target="_blank" href="https://rootly.com/blog/borrowed-gravity-words-worth-changing">post</a> about it), and the first thing they do isn’t even intelligence, it’s logistics: pulling context from Slack, postmortems, Git, and observability tools into one window in minutes, work that used to mean tab-hopping between Grafana dashboards mid-outage. The second thing is the intelligence: developing the intuition a tenured SRE has, the “when this service breaks, it’s usually that database” sense, and investigating on its own. For simple incidents, the SEV2s and SEV3s, “we are seeing customers where the incidents are no longer handled by humans.” Complex distributed failures, not yet. There, it “kickstarts your investigation, gets some context going, and then the human can take over.”</p><p>Nobody’s job disappears in his telling; it relocates. “We’re all becoming managers in some ways — or maybe not managers, but team leads.” Engineers move “away from the manual work of typing lines of code to directing,” closer to the business, further from the craft of typing. And the incidents themselves? He loves the thrill, he admitted, just not at night. “I think that’s definitely something we want to solve, and not say, hey, let’s keep this problem for humans.”</p><p>Sylvain went looking for proof that the machines fail in ways we’ve never seen, and found a mirror instead. That’s the reassuring part. We know how to build for unreliable authors; we’ve never had any other kind. The uncomfortable part is the other thing he found: the guardrails we built for mistakes made at human speed now have to hold at machine speed. When did you last check that yours would?</p><p>High Output is brought to you by <a target="_blank" href="https://getmaestro.ai">Maestro AI</a>. Sylvain’s prescription for AI-written code is trust but verify: don’t blindly accept what the agent produces, put a second set of eyes on it, even a second model. But verification is a habit, and it happens (or doesn’t) inside the working session between an engineer and an agent, where a PR count can’t see it. Your Anthropic bill tells you something is happening. Maestro tells you what. Maestro plugs into Claude Code and Codex and turns agent sessions into an honest record of the work: where the tokens went, what kind of work they bought, and whether anyone verified the result before it shipped.</p><p>Visit <a target="_blank" href="https://getmaestro.ai">https://getmaestro.ai</a> to see how we help engineering leaders calibrate AI sessions against shipped outcomes.</p> <br/><br/>This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit <a href="https://maestroai.substack.com?utm_medium=podcast&utm_campaign=CTA_1">maestroai.substack.com</a>
July 1, 2026
The Handoff Tax
<p>I asked Muddassar Shaikh where engineering work is actually heading, and he answered with what he admitted could be the setup to a joke.</p><p>“This can be the start of a great joke,” he said. “A product manager and a designer and an engineer walk into a room, and then jam on the idea together. And they come out with a working prototype instead of coming out with a spec.”</p><p>What’s missing is the handoffs. No PRD for a designer to interpret. No mockups for an engineer to build from. No ticket waiting to be picked up. The session ends with a thing that runs, not a document describing the thing that should run. He kept returning to that image, and most of our conversation was about the distance between that room and the one his teams actually work in.</p><p>Muddassar is the SVP of Engineering at GoodRx, with two decades behind him — Ticketmaster, where he grew the app install base to 42 million users, then Beachbody, now GoodRx. He’s led the kind of multi-year migrations that reshape an org chart, and so his first instinct about AI is that it’s familiar. “I would say this is part of my playbook,” he said. “I’ve led technology transformation and organizational transformation at a number of companies.” Cloud was one. Monolith to microservices was another. AI, in his telling, is just the next. Hold onto that, because by the end he complicates it himself.</p><p>Leakage</p><p>When I asked him to walk through how software actually gets made at GoodRx, the answer ran long. A PM talks to a business stakeholder. The ideas become product specs. The specs get handed to a designer, who makes visual artifacts. Those go to an architect or tech lead, who writes the technical diagrams. Then a team builds it.</p><p>Business intent into PRD. PRD into wireframes. Wireframes into architecture. Every arrow is a person reading what the last person produced and trying to figure out what they meant.</p><p>There’s “a lot of potential of leakage,” he said, as “these handoffs are happening between different roles.” Leakage is the right word for it. Each handoff is a lossy compression: the stakeholder had something in their head, the PM wrote down a version of it, the designer drew a version of that, the engineer built a version of that, and what ships is four translations downstream of the original intent. No single handoff is broken in a way you can name. But by the time the thing reaches production, some real fraction of what the business actually wanted has been quietly washed out of it.</p><p>Muddassar’s read is that AI’s real leverage is on the chain itself, not on the code at the end of it. “What AI will do, already doing, is diffusing these different roles. So one person can play multiple roles. We can also find ways to reduce the leakage as handoffs go on. Or we can completely eliminate certain handoffs.” Most productivity tools just speed handoffs up. He’s saying some of those handoffs shouldn’t exist in the first place.</p><p>Collapsing the chain</p><p>That room from the joke — GoodRx isn’t in it yet. “We are not there yet,” he said. So he’s working toward it one handoff at a time. He gave me three examples, each killing a different translation step.</p><p>JIRA automation closes the gap between a ticket and a branch: “add a label, or add a bot. It’ll read the JIRA specification. It’ll recognize what parts of the code need to change. It’ll go make the changes.” A tool his team open-sourced, called Lifecycle, shortens the engineer-to-QA loop by spinning up an ephemeral environment for every PR and posting the test link back to the ticket. And the third handoff isn’t technical at all: “We’ve had a lot of product managers starting to deploy quick fixes. AI has truly enabled me to democratize access to code.” For a copy change, the PM just ships it. The handoff to engineering disappears.</p><p>Each one cuts out a step that used to be just how work moved through the org. You make progress by subtracting, and the subtractions stack. His last transformation cut cycle time from “13 days or so to about six days,” and “that took us about two and a half years.” Since adopting AI: “the cycle time has again reduced by half in the last eight months.” Same size of gain, a quarter of the time.</p><p>Two workforces</p><p>This is where his just-another-transformation framing breaks, and he knew it.</p><p>“Previous transformations were primarily human driven. And now you have to manage humans, and you have to manage non-humans — the agents.” There’s a second workforce in the org now. It doesn’t attend standup, isn’t bound by morale or meeting culture, and runs at a pace no migration ever did. A cloud migration never made anyone manage a fleet of teammates that don’t sleep — and it never made the human teammates wonder, as Muddassar put it, whether “this role is even going to be around two years or five years from now.”</p><p>So a leader now runs two workforces at once, and can see neither clearly. The pace is the part that surprised me — Muddassar told me he used to read a daily brief on the AI world and had to give it up for a weekly one, because there was too much shipping in any given day to keep up with. And the humans? Their most important work has moved to a place the old dashboards don’t look. When the act of coding gets cheaper, the value moves upstream of the code: into how an engineer scopes a problem, what they ask the model, whether they catch it when it’s wrong. As Muddassar put it, “the act of coding itself will become less and less important.” What survives is “system thinking” and “your ability to give really clear specs.” That work happens before a single line is committed — and none of it shows up in a PR count.</p><p>The one handoff you can’t collapse</p><p>For all the acceleration, the thing he was most insistent on was the part that doesn’t speed up. With more code generated by models — and then read and changed by models — the old review process strains. But the answer isn’t a lower bar. “The bar for product quality cannot reduce. So we have to have stronger harnesses to test the changes.” He’s seen the cautionary tales: “changes at much bigger companies being rolled out with AI that have caused business impact.”</p><p>His reframe is that the code itself stops being the artifact you guard. “The quality of code will matter less and less. The outcome that comes out of the coding session, the final output — that’s gonna matter. If you’re able to write a well-defined spec, and if you have well-architected harnesses to evaluate the output of the prompt, then how the code is actually written matters less and less.” Not how it’s written. Whether it does the thing, and whether you can prove it.</p><p>If the leverage is in collapsing handoffs, the one handoff you can’t collapse is between “the model produced something” and “we know it’s right.” That one you have to build deliberately, stronger than before.</p><p>High Output is brought to you by <a target="_blank" href="https://getmaestro.ai">Maestro AI</a>. High Output is brought to you by Maestro AI. Muddassar described leaders running two workforces at once — the humans and the agents — and being able to se neither clearly. The agents are the newer blind spot. Teams are all-in on AI with almost no view into how it’s actually being used: what’s working, what’s wasted effort, and which engineers have learned to direct an agent well.</p><p>Maestro plugs into Claude Code and Codex and gives you that view. The point isn’t to grade your engineers — it’s to help every one of them get better at directing AI. We see what your strongest AI users actually do differently and turn it into patterns the rest of the team can learn from, so every engineer on your team can master AI.</p><p>Your team adopted AI. Maestro helps you see how it’s really going — and helps every engineer learn to direct an agent well.</p> <br/><br/>This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit <a href="https://maestroai.substack.com?utm_medium=podcast&utm_campaign=CTA_1">maestroai.substack.com</a>
June 3, 2026
Open the Barn Door
<p>Twenty minutes into our conversation, I asked Charity Majors how engineering leaders should be finding good junior engineers right now.</p><p>“God, I don’t fucking know.”</p><p>She apologized, then doubled back. “Sorry. Excuse me. You do need them. They’re not hard to find.”</p><p>That answer is the whole interview in miniature. How a junior breaks into engineering today, Charity will tell you, is genuinely unresolved. None of the paths that worked for her exist anymore. How an engineering org builds a healthy pipeline, on the other hand, is not particularly hard. The two questions sit next to each other, and she refused to collapse them into a tidy answer.</p><p>Charity is the co-founder and CTO of Honeycomb, twenty years into the industry, two O’Reilly books behind her and the second edition of one in progress. Her career has been built on distributed systems — production engineering at Parse, then Linden Lab, then founding an observability company. But most of what she said over the next half hour was about people, and she came back to one idea four or five times: engineering teams are not social systems and they are not technical systems. They’re sociotechnical systems, and the way you reason about one shapes the way you have to reason about the other.</p><p>Idaho</p><p>Charity grew up in the backwoods of Idaho. No computers, no phone line for most of her childhood. She got to college on a classical piano scholarship and noticed something there. “People who studied music were still hanging out working minimum-wage jobs in their thirties, forties, and fifties. And I was like, I grew up being poor. I am not going to be a poor adult. And so I switched lanes.”</p><p>She got into tech in the late nineties. “Any smart kid who is willing to work weird hours and try a lot of stuff could make a go of it.” She doesn’t romanticize that. Tech was a toy then, she said, and now powers nuclear power plants, so the bar going up is correct. But twenty years on, she’s worried about what’s happened to the door behind her. “I think we really risk it becoming the sort of ivory tower where we keep out anyone who has a non-traditional background. You need to think harder about crafting paths into technology to meet the moment.”</p><p>I asked how she got into management. “I was a reluctant manager.” She drew a line between management and leadership before I could follow up. These are sociotechnical systems, she said, “they’re not social or technical, or we could just take the great managers from Starbucks and put them in charge of engineering teams.” The reason she ended up doing the job at all was anger. “I got into people management the same way a lot of people do, which was enraged, because I didn’t like the way it was being done. And I was like, *god damn it, I guess I will do it differently. I will not make any of these mistakes.* So I made different mistakes, of course.”</p><p>The self-correction is constant in conversation with her. She said something close to it three more times over the next half hour.</p><p>The freeze</p><p>When I brought up the AI-killing-the-junior-pipeline discourse, she pointed to something specific. She’d just read a piece by Annie Lowrey in the Atlantic that morning. <a target="_blank" href="https://www.theatlantic.com/ideas/archive/2025/09/job-market-hell/684133/">The Job Market Is Hell</a>. Unemployment is around 4.7%, which is historically fine, but nobody is leaving their jobs and nobody is hiring. On both sides of the resume, AI is doing the talking. Recruiters feed inbound applications into screening tools. Candidates feed job listings into chatbots. “The result is there are no people talking to people. Nobody’s figured out how to do this.”</p><p>The framing she rejected was the one that treats this as inevitable.</p><p>“What I don’t like about the way people talk about bringing juniors into tech is they talk about it like it’s some force of nature that we have no control over, which is absolute horseshit. This is a world we create. It’s a world that we reinforce.”</p><p>It’s a sequence of decisions made by people in rooms. And the people most responsible for those decisions, she would argue later, aren’t the ones the org chart suggests.</p><p>Make friends with the discomfort</p><p>Before she got to the operational claims, she walked me through what she thinks her generation of managers got wrong, because the failure mode shapes everything else.</p><p>“My generation swung the other way and was like very rigorous about, *you should have work-life balance. Nobody should be pinging you after hours.*” The intent was correct. She was managing in reaction to the era of people sleeping under their desks. But she watched it overcorrect. “I see some managers being like, *you’re working more than 40 hours, stop.* And honestly, we live in a very complex, fast-changing world, and if you’re intrinsically motivated to be working, if you’re learning, if you’re having fun, nobody should be stopping you, because that really is the path to success.”</p><p>She isn’t arguing for the swing back, either. I brought up 996, the Chinese nine-to-nine, six-days-a-week framing that’s been making the rounds on Hacker News. She had nothing nice to say about the swing-back. “It all swings back. It all swings back, doesn’t it?” Then, more bluntly: “That’s bullshit.” She read the cycle as a generational pattern, and she was harder on her own generation than on either pole. “If anyone had told me that, if I had followed that advice, I would not be where I am.”</p><p>The piece of this that connects to junior hiring is the part most management writing skips. “You need to learn to make friends with the discomfort. You need to learn to find joy in the pain.” None of us, she said, evolved to handle data structures and algorithms, and the early years of an engineering career are genuinely agonizing. The juniors who make it through are the ones who learn to like the agony. A lot of senior engineers, looking back, have forgotten that they once lived through it.</p><p>It’s a humanistic argument, not just an operational one. She talked for a while about school stamping out the curiosity children are born with. Twelve, twenty, twenty-five years of report cards, conditioning us to associate learning with extrinsic reward. What she loves about adulthood is the chance to rediscover the original instinct. Engineering is one of the few careers that pays you for it.</p><p>50 to 1</p><p>Her first operational claim was about team composition.</p><p>“For every staff engineer that you have, let alone principal engineer, you need 50 intermediate engineers.”</p><p>The number is a gesture. The shape of the argument is specific. Most companies have over-corrected toward senior hiring on the theory that they’ll get more leverage per dollar. The people who actually ship the bulk of features, she said, aren’t seniors. They’re intermediates. “Some of the most productive engineers that I’ve ever worked with have been intermediate engineers. They can just put on their headphones, beginning of the day, go deep, and just pound out the features and the bug fixes.” Heads down, pattern matching, finishing things. “Nobody who’s been in engineering for seven, ten years wants to do that. They’re sick of that.”</p><p>The bored staff engineer is not a leverage win. “When people get bored, you do not get great work out of them. You get the best work out of people when they are working at that place that’s right on the edge of their ability.”</p><p>And the supply chain only runs one direction. “Nobody stays a junior engineer for long, two years at most. So you’ve gotta keep feeding the system. You’ve gotta keep bringing new blood in.”</p><p>Opening the barn door</p><p>I asked what she’d recommend to companies that are paranoid about hiring right now.</p><p>“I would advocate for opening the barn door a bit wider, giving more people a shot. Understanding that it means you will have to fire more of them. You will have to let more of them go. But I feel like it’s worse to never give people a shot.”</p><p>The second half is the part she emphasized. A wider door costs you in faster, more honest performance management, and most engineering managers are bad at that part. “Nothing demoralizes a team more than when someone that they work with every day, who’s not pulling their weight, just hangs around forever.” The unsalvageable cases weren’t the ones that escalated. They were the ones that drifted. “Some of the most heartbreaking situations I’ve ever been in as a manager are when a person’s being let go after years of them doing exactly the same thing, and they’re legitimately dumbstruck.”</p><p>There’s a side benefit she pointed out that I hadn’t considered. Junior engineers audit your systems in a way nobody else can. “If you’re an engineer joining a team where there is very low turnover, where people never join, where people never leave, that is not likely to be a very high functioning team either.” Old docs. Idiosyncratic mental models locked in three people’s heads. A dev environment that takes a month to set up because nobody’s tried in six. “If you’re used to bringing on junior engineers, oh boy, those kids will audit your systems like no one else.”</p><p>That’s the sociotechnical argument in plain language. The team isn’t separable from the systems it owns, and the hiring policy isn’t separable from the operational health of the codebase. Both improve together or neither does.</p><p>What she watches for in a junior</p><p>The most optimistic moment came when I asked what she watches for in her own juniors.</p><p>“Some of our junior engineers talk about how they are in conversation with Claude all day long. By the time they bring a question to their senior engineer, which they do very often, they have tried all the low-hanging fruit, they’ve tried a bunch of stuff, they’ve asked a lot of questions. So it is very well worth that senior engineer’s time.”</p><p>That’s not the threatened-junior story most engineering leaders are telling right now. The juniors she described are using the model to exhaust the obvious before they ask, and arriving at the senior with the harder version of the question.</p><p>I asked what the leading indicator is for a junior who’s going to make it.</p><p>“Are they asking good questions? Are their questions getting better? Do they have a good sense of how to use their time and how to use their mentor’s time? That is the best leading indicator.”</p><p>Not output. Not commit volume. Question quality, over time. She added, almost in passing, that her management chain handles the day-to-day evaluation. “I really trust Emily and all of them.” The broader discipline she described combines two things engineers tend to mistrust: the data, and the conversations. “It’s actually really important that there be data in addition to conversations, because the data and the conversations are bookends. They help you understand each other.” Lean on either alone, she said, and you get either a “people manager” with no technical judgment, or a manager who reads PR counts as a personality assessment. Both fail in different ways.</p><p>Consent of the governed</p><p>Near the end, I asked who she thought was actually responsible for fixing the junior pipeline. The pattern she described is counterintuitive.</p><p>“The places that I know of that actually are successfully recruiting, hiring, bringing in junior engineers, and making them successful, it was *not* the engineering managers who pushed for that program. It was the senior engineers. They were the ones who were like: *we know what it takes to have a healthy, high-performing team. It takes a steady influx of new blood, and we feel this conviction so strongly that we’re gonna go make it happen ourselves.*”</p><p>The senior ICs went to bat. The managers ran the mechanics afterward. Then the line that anchored the whole conversation:</p><p>“There is no engineering leadership without the consent of the governed.”</p><p>Charity has been an executive long enough to watch a lot of decisions get made about engineers, by engineers, with or around engineering management’s input. “If there’s anything that I have learned being in senior management, it’s how much power individual ICs have when they choose to flex it.”</p><p>I asked whether she meant it literally. Were the senior ICs really the deciding force? She walked through the pattern again. The companies hiring juniors successfully are the ones where the senior engineers made it their problem. The ones not hiring are the ones where they didn’t.</p><p>I came in expecting a programs-and-processes answer. Recruiting funnels, intern conversions, the mechanics of a pipeline. What I got back was about consent. The senior ICs in your org, the ones who don’t have manager in their title but have weight in every staffing conversation, are the people who decide whether the next generation gets in. Without their buy-in, no pipeline exists. With it, almost any pipeline works.</p><p>The feedback loop of feedback loops</p><p>I asked at the end what she’s working on now. She’s writing the second edition of *Observability Engineering*, and she was honest about how it’s going. “It’s not going super great.” She read the first edition recently and found it embarrassing, which is not how most authors I’ve talked to describe their own work. “But now I think my co-authors and I, we know who we’re writing for and we know what they need to hear.”</p><p>Then she connected the book to the show in a way I wasn’t expecting.</p><p>“It’s a true fact reality that high-performing engineering teams are about fast feedback loops, and observability is the feedback loop of feedback loops. It is the sense-making apparatus of engineering teams.”</p><p>That landed for me. A lot of what she’d argued for over the prior half hour started looking like a feedback-loop argument. Open the barn door, but tighten the loop on managing out, so performance information moves fast. Watch question quality, because it’s a faster signal than output. Bring juniors in, because they shorten the loop on every undocumented assumption your team has accumulated. The senior ICs are the deciding force because they’re the only people positioned to keep all those loops short.</p><p>A team is a sociotechnical system. The systems that team owns are sociotechnical systems too. The discipline of running both well is the same: short feedback, an honest signal, and the willingness to look at uncomfortable data.</p><p>Charity’s question, the one I’ve been sitting with since we hung up: in your engineering org, who is actually deciding whether the next generation gets in?</p><p>High Output is brought to you by <a target="_blank" href="https://getmaestro.ai">Maestro AI</a>. The thing Charity said that stuck with me most was about leading indicators. The junior worth investing in isn’t the one shipping the most code. It’s the one whose questions are getting better. The juniors using Claude well at Honeycomb are showing up to their senior engineers having already exhausted the obvious. That’s a different trajectory than the one most dashboards see.</p><p>PR counts and cycle time can’t pick that distinction up. The work that builds judgment, or fails to, happens in the back-and-forth between an engineer and an AI agent, before any PR is opened. Your Anthropic bill tells you something is happening. Maestro tells you what.</p><p>Maestro plugs into Claude Code and Cursor and looks at the work itself: how engineers scope a problem before they prompt, what they verify, what they accept on faith. Scored against shipped outcomes, not vibes. You can see which engineers are leveling up and which are accumulating comprehension debt.</p><p>Visit <a target="_blank" href="https://getmaestro.ai">https://getmaestro.ai</a> to see how we help engineering leaders spot which engineers are developing real AI craft, and which are just generating more output.</p> <br/><br/>This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit <a href="https://maestroai.substack.com?utm_medium=podcast&utm_campaign=CTA_1">maestroai.substack.com</a>
18 total episodes available
Recent guests on High Output: The Future of Engineering
Guests from recent episodes — sign up to see every guest that has ever appeared on this show.
Tacita Morway
Guest
Glenn Veil
Guest
Raquel Rodriguez
Guest
Deep-dive analytics for High Output: The Future of Engineering
Frequently asked questions
Have a different question and can't find the answer you're looking for? Reach out to our support team by sending us an email and we'll get back to you as soon as we can.
- What is High Output: The Future of Engineering?
- How often does this podcast release new episodes?
This podcast updates daily.
- Where can I listen to this podcast?
This podcast is available on 4 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.
- Does this podcast accept guests?
Yes, this podcast regularly features guests.
Legal Disclaimer
Pod Engine is not affiliated with, endorsed by, or officially connected with any of the podcasts displayed on this platform. We operate independently as a podcast discovery and analytics service.
All podcast artwork, thumbnails, and content displayed on this page are the property of their respective owners and are protected by applicable copyright laws. This includes, but is not limited to, podcast cover art, episode artwork, show descriptions, episode titles, transcripts, audio snippets, and any other content originating from the podcast creators or their licensors.
We display this content under fair use principles and/or implied license for the purpose of podcast discovery, information, and commentary. We make no claim of ownership over any podcast content, artwork, or related materials shown on this platform. All trademarks, service marks, and trade names are the property of their respective owners.
While we strive to ensure all content usage is properly authorized, if you are a rights holder and believe your content is being used inappropriately or without proper authorization, please contact us immediately at hey@podengine.ai for prompt review and appropriate action, which may include content removal or proper attribution.
By accessing and using this platform, you acknowledge and agree to respect all applicable copyright laws and intellectual property rights of content owners. Any unauthorized reproduction, distribution, or commercial use of the content displayed on this platform is strictly prohibited.