High Output: The Future of Engineering

Most engineering leaders spend enormous energy on process. Which agile framework. Which sprint cadence. Which AI coding tool to adopt. How to standardize workflows across teams. The assumption is that the right process produces the right outcomes.Gaurav Gargate has come to believe the opposite. Get the principles right, and the process can flex.Gaurav is VP of Engineering at Confluent, where he runs their Security Products and Cloud Platform powering their cloud-native data streaming ecosystem. He joined when the business was sub-$100 million; today it’s $1.1 billion. Before Confluent, he spent seven years at Box and six years at Microsoft. And before any of that, he started his career at a 15-person startup in India — “Didn’t know what we were doing, but it was fun.”Across all of those environments—from a scrappy team of 15 to a billion-dollar enterprise—one pattern has held: the organizations that thrive are rigid about their principles and flexible about everything else. The ones that struggle have it backwards.The Agile Dogma Aha MomentGaurav has a specific story about when this clicked. Early in his career, he was a believer in classical agile—sprints, scrums, the full playbook. He thought it was the way to run engineering projects.Then he hired a leader who was completely aligned on the principles: execution pays the bills, work needs visibility and traceability, quality gates matter. But the process? Different.“Look, I don’t necessarily care about the book process, whether you call it agile or you call it scrum or something else. I would love to have the agency to ensure I manage and track my work. My engineers feel like they’re actually doing the best work of their life and there is quality gate and accountability.”Gaurav calls this a strong aha moment. “I realized I was being unnecessarily dogmatic in my approach. And actually this additional way of doing it opened up so many gates.”The lesson wasn’t that agile is bad. It was that confusing a specific process with the underlying principle is a trap. The principle—visible, accountable, high-quality execution—can be achieved multiple ways. Insisting on one process locks out people who could deliver the same outcomes through a different path. It closes doors you didn’t know existed.The constraint is real, though. “You don’t wanna have 30 teams have 30 different innovative ways.” There’s a phase where letting a thousand flowers bloom is the right move, and there’s a point where you need to converge on five or six archetypes. The art is knowing when you’re in which phase.Culture Add Over Culture FitThe same logic applies to hiring. Early in his career, Gaurav screened for culture fit—people who matched the team’s existing style. Over time, he realized this was the same mistake as the agile dogma, applied to people instead of methodology.“It’s actually a bad idea to have a very closed door—only follow this culture and nothing else.”When you hire exclusively for fit, you get a team that reinforces its own assumptions. The same instincts. The same blind spots. The culture calcifies instead of evolving.His alternative: hire for culture add. Find people who share your principles and values, but bring their own approaches and experiences. “New people join in, people grow in their roles, people from different companies and backgrounds and experiences come together—the beauty is that an evolving culture being held strong on the principles of the company actually makes it a success story.”The distinction is subtle but important: principles are fixed, culture is not. Values are the foundation. Everything built on top should be allowed to shift.Share the Why, Trust the HowGaurav applies the same framework to day-to-day management, and he sums it up bluntly: “The fundamental principle is to treat people like adults and they will behave like adults.”In practice, that means sharing context aggressively—where the business is going, how decisions get made, what the company needs right now—and then stepping back. “Enable them, let them have that agency to make those micro decisions as much as possible.”He’s not flexible about everything. Collaboration, one-team attitude, flat hierarchy, open communication—these are non-negotiable. “There are certain principles which I’m actually not ready to compromise on.”But beyond those fixed points, he lets leaders find their own style. “Ultimately what every strong individual or leader wants is to be held accountable for the outcomes and the results they deliver. And nobody likes to be micromanaged on how they get there.”Rigid on values. Flexible on methods. The same pattern, applied to management instead of hiring or methodology.The SDLC TreeWhere this gets most interesting is how Gaurav applies the framework to AI adoption. His approach is different from the typical “push coding copilots” playbook—and the principle underneath it is the same one driving everything else.The principle: engineers should spend their time on high-value, creative work. The process for achieving that? That’s what changes.Gaurav looks at the entire software development lifecycle as a tree of workflows and targets the branches no engineer enjoys. “Especially as a cloud infrastructure company, there is a ton of work in operating, managing, keeping your infrastructure secure, scaling the business. There are a lot of things that AI can generally do well.”Confluent handles security patches and vulnerability management across three clouds and roughly a hundred regions. Infrastructure gets set up, tested, and torn down constantly. These are the branches AI is taking over completely—with engineers administering and managing rather than doing the work by hand.“Engineers actually love to do the innovation. They love to do the new problem solving. They love to have that ability to write new code in a way they feel is appropriate.”His conclusion follows directly: “I would love my engineers to actually have that mental space to invest their time in that high value work and let all the undifferentiated work be taken over completely by AI.”This is a fundamentally different framing from “AI makes engineers faster.” It’s not about speed. It’s about expanding what engineering teams can accomplish. “The pie is getting bigger. We gotta look at AI as a way to expand the pie of work that an engineer can do, not necessarily just what they were doing last year.”He invokes Jevons’ paradox—the idea that when something becomes more efficient, total consumption increases rather than decreases. Because it’s easier to build, more will get built. More demand, more opportunity, more roles. And his take on whether AI threatens engineering jobs is unequivocal: “Every role, every job category is going to change because of AI.” But change isn’t elimination. It’s the same transition the industry went through when cloud replaced data center ops. The people who understood first principles learned the new layer and kept going.The Fundamentals Don’t ChangeThis is the thread that ties everything together. Principles endure. Process shifts.When Gaurav joined Microsoft, people questioned whether he was a real engineer because he didn’t write device drivers. “The previous generation did something at a lot lower level, and then the next generation is doing something at a different layer. That’s always been happening for decades.”But through those decades of transformation, the fundamentals haven’t changed. Understanding operating systems, databases, memory management—”the fundamental understanding of these core principles is what allows a great engineer to learn and pick up new things.”His advice to new graduates is the same advice he’d have given five years ago: focus on the fundamentals. “Learning new things has become easier. Building and experimenting has become a lot easier than before. If people can really spend time understanding the core fundamental building blocks of computer science, applying them to learn and build new things is actually gonna be easier going ahead.”The career lesson mirrors the organizational one. The engineers who thrive across generational shifts are the ones grounded in principles, not attached to any particular layer or tool. The organizations that scale from startup to $1.1 billion are the ones that hold their values tight and let everything else evolve. The leaders who get the most from AI are the ones who know which work matters and which work is just process.Same pattern. Every level.What This Means for YouFirst, separate your principles from your processes. Gaurav’s agile aha moment came when he realized he was treating a specific methodology as a principle. Identify which of your team’s practices are genuinely non-negotiable values and which are just comfortable habits dressed up as requirements.Second, audit your hiring for culture fit vs. culture add. Are you screening for people who share your principles, or people who share your habits? The first builds a team that evolves. The second builds one that calcifies.Third, when deploying AI, map your SDLC and target the work nobody wants. Instead of asking “how do we code faster,” ask “which branches of our workflow tree drain engineers without engaging them?” Security patches, infrastructure provisioning, repetitive operations—these are the high-ROI AI targets that also free engineers to do the work that drew them to the field.Fourth, give context instead of instructions. If you want people to make good micro-decisions without being micromanaged, they need the same information you have. Share the why and how you measure the what—then trust them to figure out the how.The question worth asking your team: Are the things you’re rigid about actually principles—or are they processes you’ve held onto so long they just feel like principles?High Output is brought to you by Maestro AI. Gaurav talked about giving teams the room to deliver their own way. But when you stop prescribing process, you lose the visibility that proce

Some engineering teams are seeing real, measurable AI productivity gains. Cursor is transforming how frontend developers build React apps. AI-assisted code review is catching bugs before deployment. Prototypes that took weeks now take days.But not everyone’s seeing the same results.Raju Matta runs engineering for Cambridge Mobile Telematics—200+ engineers, three countries, petabytes of real-time sensor data processing driver safety. Six months ago, he formed a tiger team to systematically track AI tool adoption. Status reports every two weeks. Multiple tools tested: Copilot, Cursor, PR review bots.His finding? “I’ve not seen the measurable velocity increase that people are saying out in the market—but that doesn’t mean I have totally written off LLMs yet.”This isn’t skepticism. It’s measured evaluation. And the pattern Raju’s seeing reveals something important about when AI tools deliver and when they don’t.Where AI Tools ExcelAs part of their evaluation, CMT ran an internal hackathon to see what AI tools could do in practice. The results told a clear story. Eighteen projects, all using AI. Teams built fully working web apps—complete with datasets—in 2-4 hours.“For that purpose, it’s great. It’s not bad at all,” he says.The pattern: AI coding tools work brilliantly for rapid prototyping with established patterns, web development using well-documented frameworks, mechanical coding tasks like boilerplate and test generation, and quick experiments to validate product ideas.These are real productivity gains. The people claiming 2x-3x aren’t exaggerating—they’re working in contexts where AI capabilities align perfectly with task requirements. When your bottleneck is writing React components or generating CRUD endpoints, AI tools deliver measurable acceleration.But CMT’s production systems are different.The Complexity MultiplierThey’re processing petabytes of data from gyroscopes, accelerometers, GPS sensors, video streams. They’re distinguishing potholes from crashes, sharp corners from reckless driving. They’ve been using AI and machine learning for this work for 13 years—long before LLMs became everyone’s productivity obsession.The engineering challenge isn’t writing code. It’s architecting systems that handle sensor fusion at scale, debugging why clusters fail under load, ensuring accuracy when lives depend on your classifications, and managing tech debt across distributed teams in six countries.“You can outsource your engineering and coding with AI tools, but not your thinking,” Raju explains.In complex production systems, the thinking is where the time goes. Code generation helps, but it’s not the bottleneck. The productivity multiplier drops from 3x to “incrementally helpful” because the constraint isn’t in the typing—it’s in the architectural decisions, the system design, the understanding of how everything fits together.This doesn’t make AI tools useless. They still catch bugs in PRs. They still help prototype solutions. They still accelerate certain tasks. But the overall velocity gain is modest because code generation often isn’t the long pole.The Tiger Team ApproachHere’s what makes Raju’s perspective valuable: he’s not guessing. Six months ago, CMT’s CTO gathered the engineering leaders. “How are you guys thinking of AI?” The response: treat it like a first-class citizen.They formed a dedicated tiger team. Three people producing status reports every two weeks on tool adoption, usage patterns, and measurable impact. “We have about three or four tools that we are using all the way from PR review tools to tools like Copilot, Cursor.”This is systematic evaluation, not anecdotal impressions. And the data shows results that differ from the market narrative: “My general experience is that it’s good, it’s doing its job, but I haven’t seen the measurable velocity increase as much as what people are saying out in the market.”His peer conversations confirm the pattern isn’t unique to CMT: “Even other leaders and my peers that I speak with, who are working at big tech companies, have said similar things. So it’s not uncommon.”But Raju’s not dismissing the technology. “The tools are progressing at a very fast pace. I wouldn’t be surprised if it’s another six months or a year where we get to exhaust more pieces of the tool and get more done.”That “yet” matters. He’s still tracking, still evaluating, still expecting improvement.When Mistakes Have ConsequencesWhen Raju says “we have to save people’s lives,” he’s not being dramatic. CMT’s technology directly impacts driver safety. Their telematics platform processes sensor data to detect dangerous driving, assess risk, and potentially prevent accidents.This creates a different bar for “move fast and break things.”“We are a little bit more diligent because at the end of the day, we have to save people’s lives. So for us, we’d rather spend the time beforehand than reactively trying to address it.”The stakes are high—both financially and ethically. When your technology directly impacts human safety, you can’t afford to ship fast and fix later.The constraint isn’t just technical complexity—it’s consequence of failure. “AI tools can take you north, but with the same speed, they can take you south.”In safety-critical systems, the review time, the testing time, the verification time doesn’t compress even if code generation does. You can’t ship and iterate rapidly when mistakes could harm people. The overall productivity gain shrinks accordingly because the non-coding portions of the development cycle remain unchanged.This applies beyond telematics. Financial systems. Healthcare platforms. Infrastructure control. Any domain where errors have serious consequences faces the same limitation: AI can accelerate code generation, but it can’t compress the necessary validation and testing cycles.Where AI StrugglesAI’s limitations show up in unexpected places. CMT uses AI to filter thousands of resumes for each job opening. The results? “50% makes sense. And 50% don’t make sense.”This split illustrates a broader pattern. AI works brilliantly for well-defined, repeatable tasks. It struggles with judgment calls, context-dependent decisions, and situations requiring nuanced understanding.The tool saves time on mechanical filtering. But the judgment about who’s actually right for the role? Still human. And critically, the humans can immediately spot when AI recommendations miss the mark—they don’t trust it blindly.This mirrors the coding experience. AI generates boilerplate quickly. But understanding whether the generated code fits the broader system architecture, handles edge cases properly, and follows team conventions? That requires human judgment that doesn’t compress.Where This Leaves Engineering LeadersThe mistake isn’t believing AI tools work—they demonstrably do in many contexts. The mistake is assuming your context will see the same gains as someone in a completely different situation.Raju’s systematic evaluation reveals the variables that matter:Your problem domain determines gains. Web apps and prototypes with established patterns can see significant productivity improvements. Complex distributed systems with unique requirements tend to see incremental improvements. The difference isn’t the tool quality—it’s how much of your bottleneck typically sits in code generation versus system design.Your constraint defines the impact. If implementing features is your rate-limiting step, AI delivers massive value. If architectural decisions and system design are your constraint, AI helps less. Most production systems fall into the second category after the initial prototyping phase.Your risk tolerance changes the math. If you can ship and iterate rapidly, AI accelerates that cycle. If mistakes have serious consequences, the review and testing time doesn’t compress proportionally. The overall velocity gain depends heavily on how much of your process can safely be accelerated. Your system complexity matters. Greenfield projects with established patterns see huge gains. Legacy systems with unique constraints and interconnected dependencies see modest gains. The complexity of your codebase directly impacts how useful AI-generated code becomes.The Honest AssessmentRaju isn’t claiming AI tools are overhyped. He’s providing the nuanced reality: they work extremely well for specific contexts and deliver modest improvements in others.His 6-month tiger team experiment with dedicated tracking hasn’t found a productivity revolution. They’ve found incremental gains with clear constraints. That’s the honest number engineering leaders need for planning.“LLMs can help us experiment and prototype features faster. They can help developers catch mistakes in our pull requests. They can help us find answers faster, and we are constantly evaluating,” he explains. “But I’ve not seen the impact that people are saying out there.”This doesn’t mean ignore AI tools. It means understand your context, measure systematically, and set realistic expectations.For rapid prototyping and web development? The 2-3x gains are real. For complex production systems with safety requirements? The gains exist but are much more modest. Both can be true simultaneously—the difference is context.What This Means for YouFirst, measure systematically rather than relying on anecdotes. Set up dedicated tracking like Raju’s tiger team—assign ownership, establish regular reporting, and gather actual usage data. The hype cycle around AI tools means everyone has an opinion, but data reveals what actually works in your specific context.Second, understand where your bottleneck actually sits. If architectural decisions and system design consume most of your time, AI tools will help less than if code generation is your constraint. Be honest about what’s actually slowing you down before expecting AI to solve it.Third, adjust expectations based on risk profile. If your domain allows rapid iteration and tolerable failure rates, AI tools can deliver signi

When you’ve bootstrapped an engineering org from 2 people to 500, working with Fortune 500 clients like Intel and Samsung, you learn something most AI builders miss: the best technology doesn’t always ship.Muhammad Atif, President and CTO of PureLogics, recently deployed an on-prem AI model that hits 70% of the accuracy of their original cloud-based prototype. That 30% accuracy gap represents the tradeoff required for HIPAA compliance. The cloud-based prototype couldn’t be deployed—patient data can’t touch external APIs under their client’s compliance requirements.This is the reality healthcare engineering leaders face: you’re building for the best model that meets your compliance requirements, not just the highest-performing model in isolation.Since co-founding Pure Logics in 2007, Muhammad has grown it from 2 people coding in a room to a 500-person global engineering firm. They build on-prem models that achieve 60-70% of cloud-based prototype accuracy while meeting the strict data security requirements that healthcare demands.The Compliance Wall Everyone HitsMuhammad’s team was prototyping an AI feature using OpenAI’s API. Fast iteration, impressive results. Then the client’s compliance team saw the architecture diagram.“When the customer said they need to have on-prem AI, we changed the entire paradigm,” Muhammad explains. The entire approach had to be rethought.The paradigm shift required rethinking four critical areas. First, hardware specification: what GPU specifications, how much RAM, what storage architecture. These decisions determine whether your model trains in days or weeks, whether inference is real-time or batch. Second, model selection: which open source model fits your domain? Healthcare has different requirements than generic NLP—you need models that work for medical terminology, clinical workflows, provider documentation patterns.Third, and most challenging, training data acquisition. You need millions of records to train effectively, but healthcare data is protected. “We need to have millions of records of data to train that model to bring up to that accuracy,” Muhammad explains. Where do you get training data that doesn’t violate HIPAA?Fourth, compliance layers: NIST AI RMF compliance, HSS trustworthy AI practices, OSAP LLM practices, HIPAA audit trails. “We need to make sure that we have all these security and safety guardrails implemented, especially when dealing with live patient data,” Muhammad says.“We have deployed an onsite model. It’s almost 70% accurate compared to the one we used to have in the initial POC,” Muhammad says.That 30% accuracy gap represents the tradeoff for meeting compliance requirements. The on-prem model that meets HIPAA requirements ships. The cloud-based prototype doesn’t.This is the reality healthcare leaders face. The question isn’t “what’s the highest-performing model?” It’s “what’s the best model we can deploy within our regulatory constraints?”What Compliance Expertise EnablesPure Logics’ on-prem AI capabilities unlock healthcare applications that wouldn’t be possible without deep compliance knowledge.Take their diabetic foot monitoring project. Diabetic patients often can’t feel temperature changes in their feet—a dangerous condition that can lead to undetected injuries and infections. Pure Logics is building algorithms that analyze thermal images of patients’ feet to detect temperature anomalies, giving providers early warning signs before problems escalate.Or their women’s health platform, which helps women track and manage their health throughout hormonal and menstrual cycles. These aren’t trivial consumer apps—they’re handling protected health information that requires the full compliance framework Pure Logics has built.“We have also been working with few startups who are working on like diagnostics and disease detection kind of algorithms, and we are really proud that we are going to be part of those teams,” Muhammad says.This is the payoff for solving the hard problems. Teams that can’t navigate HIPAA constraints can’t build these applications. Teams that can navigate HIPAA but can’t achieve reasonable AI model performance on-prem can’t make them useful. Pure Logics’ expertise in both areas—compliance frameworks and on-prem AI deployment—creates the foundation for meaningful healthcare innovation.The Hidden Cost of Moving FastMuhammad sees a pattern with technical debt. “Tech debt is mostly built due to business pressure—’keep delivering, I need this thing or that thing’—or it can be due to poor planning or prioritization.”Add AI to the mix, and the pressure intensifies. Your CEO reads about companies shipping 4x faster with AI. Your board asks why you’re not seeing similar gains. Your competitors claim massive productivity jumps.But in healthcare, you can’t just vibe-code a system into production. “You can keep building things, but especially with AI—we are generating code through AI as well—we wanted to make sure we’re not building a product that reaches a certain level where we can’t add any further features, or it’s not scalable.”Pure Logics’ solution: quarterly audits. Load testing. Security reviews. Code quality checks. Database design reviews. Access audits—who has credentials to which systems. And version upgrade planning—if you’re on Python version X but version Z is stable, what’s the migration path?This sounds expensive. It is. But Muhammad has watched what happens without it: systems that need complete rebuilds after two years. Technical debt that makes simple features take weeks. Security vulnerabilities that surface during compliance audits.The paradox: moving slower with proper guardrails lets you move faster long-term.The Twenty-Year ViewMuhammad started Pure Logics in 2007 with one other person. They worked 12-14 hour days, went home at midnight, worked weekends. “The initial four to five months were quite challenging.”By 2008, they landed Fortune 500 clients—Live Nation, where they managed web presence for Maria Carey and Taylor Swift. By now, they have 500 people across multiple countries.This growth path offers a different model than the typical startup story. No VC funding. No blitzscaling. Just steady, sustainable growth by solving real problems for enterprise clients.What does this teach about AI adoption? “We need to have people who are not just coders, but they are also thinking from an end-to-end problem solving mindset. And they are great at other areas like soft skills—communication, explaining and connecting with people and driving to a solution.”The companies that win with AI won’t be the ones that generate the most code the fastest. They’ll be the ones that understand the complete problem: technical constraints, compliance requirements, security frameworks, and human workflows.What This Means For YouIf you’re building AI products in regulated industries, Muhammad’s framework offers a practical path:First, map your constraints before you optimize. Don’t start with “what’s the best model?” Start with “what meets our compliance requirements?” An on-prem model that achieves 70% of your prototype’s accuracy but ships is more valuable than a cloud-based prototype that can’t be deployed.Second, build security guardrails into your development workflow. Muhammad’s team achieves 20-25% productivity gains from AI coding tools while maintaining code quality through static analysis, peer review, and technical debt checks.Third, audit regularly, not reactively. Quarterly reviews of code quality, security, database design, and access controls catch problems when they’re manageable, not when they’ve compounded into system-wide issues.Fourth, choose tools for integration, not hype. The best AI tool isn’t the one with the most impressive demos. It’s the one that integrates with your existing quality processes and workflow.Fifth, remember that constraints can become advantages. Pure Logics’ on-prem expertise differentiates them. Companies that need HIPAA-compliant AI need teams that understand both AI and compliance frameworks. Your constraints are your moat.The critical question: are you building AI products that work within your industry’s reality, or are you trying to force approaches that only work for unrestricted consumer apps?About PureLogics:PureLogics is a global engineering firm specializing in healthcare software development with deep expertise in HIPAA compliance and on-prem AI deployment. Founded in 2007, they’ve grown from 2 engineers to a 500-person team serving Fortune 500 clients including Intel, Samsung, and Live Nation.The company focuses on building compliant AI solutions for healthcare organizations, from e-prescription systems and EMR integrations to on-prem AI models for sensitive patient data. Their expertise in both AI implementation and healthcare compliance frameworks enables them to build applications that meet strict regulatory requirements while delivering meaningful clinical outcomes.Learn more at purelogics.com.About Maestro AI:High Output is broght to you by Maestro AI. Maestro is an engineering visibility platform that helps leaders make data-driven decisions backed by narrative context. While most dashboards offer surface-level metrics, Maestro analyzes your team’s actual code, PRs, tickets, and communications to reveal not just what’s happening, but why.The platform automatically synthesizes this activity into real-time feeds for every project, team, and individual—replacing subjective status meetings with objective truth. This allows you to identify blockers before they impact deadlines, de-risk key initiatives, and measure the true impact of tools like AI on your organization.Visit https://getmaestro.ai to see how we help engineering leaders build more predictable and efficient organizations.Leading distributed engineering teams? We’d love to hear your challenges. Schedule a chat with our team → https://getmaestro.ai/book This is a public episode. If you would like to discuss this with other subscri

When you provision thousands of GPU clusters weekly for Apple, Spotify, OpenAI, Uber, Runway, and Cursor, you see something nobody else does. From the infrastructure layer, the patterns are unmistakable. Different companies, different products, different use cases—but they’re all hitting the same bottlenecks.Jaikumar Ganesh would know. As Head of Engineering at Anyscale, he runs Ray—the distributed compute engine that powers production AI at scale. Ray sits in the stack between Kubernetes and the AI workloads, orchestrating the compute that makes everything run. When you’re that deep in everyone’s infrastructure, you see the convergence before anyone else does.And what he sees right now? Companies are throwing money at GPU shortages while their GPUs sit idle half the time, waiting for CPUs to finish resizing images. It’s not a GPU problem. It’s a coordination problem. And it’s just one of several patterns everyone’s hitting—patterns most don’t even realize are shared.🎧 Subscribe and listen now → The bottlenecks everyone’s hittingHere’s what actually happens in production. You need to process multimodal data—audio, video, robotics sensors, Zoom recordings. Reading images and resizing them? CPUs. LLM inference? GPUs. Writing results back? CPUs again. These are staged pipelines.“In a lot of legacy systems, you read an image and you have to wait till all the images are read till you activate the GPU,” JK explains. “Now what happens is there’s a GPU shortage, but you have a GPU sitting there idle, and so your GPU utilization is low and your finance team is like, ‘Hey, you’re spending so much money.’”This is the shift that sounds obvious but isn’t: we’ve moved from a CPU-centric world to a heterogeneous compute world—CPU plus GPU. Most frameworks were built for one or the other. Very few handle the handoff well. Ray Data solves this by handling the transitions without writing to disk at every stage. Different pipeline stages execute on the right resource, and nothing sits waiting.The companies that figure this out have massive cost advantages. The ones that don’t keep throwing money at GPU clusters that spend half their time idle.But here’s what’s remarkable: when you’re provisioning clusters at this scale, you see more than just the GPU coordination problem. You see the entire stack converging. Pull up any major AI company’s infrastructure and you’ll see the same architecture:At the top: AI workloads (data processing, pre-training, post-training, model serving)Below that: Training frameworks (PyTorch, JAX)Then: LLM-specific engines (VLLM for serving, DeepSpeed and FSDP for parallelism)Distributed compute: RayContainer orchestration: KubernetesAt the bottom: Cloud providers and GPU providers“Across all the companies we have worked with, in open source as well as those who are Anyscale customers, this pattern is consistent,” JK explains.Here are the four patterns driving convergence:* Heterogeneous compute coordination: CPU-centric thinking doesn’t work anymore. You need CPU and GPU working together efficiently. Most frameworks handle one or the other well, but the handoff between them is where money gets burned. Multimodal data processing—audio, video, sensor data—exposes this immediately.* Post-training infrastructure complexity: Everyone thinks pre-training is the hard part. Wrong. Post-training is where the real infrastructure complexity lives, and it’s where customization happens. Eight of the ten most popular open source post-training libraries are built on Ray. Why? Because you need inference stages mixed with training stages, all within the same workload. Someone has to orchestrate where each stage runs, whether to transfer model weights, how to handle the compute efficiently.* Multimodal data pipeline bottlenecks: It’s not a model problem—it’s an engineering problem. The bottleneck isn’t which model handles video best. It’s moving data between CPUs and GPUs efficiently without writing to disk at every stage. Fix the pipeline, not the model selection.* Domain-specific approaches returning: While everyone obsessed over LLMs, reinforcement learning quietly came back in gaming and simulation. Riot Games—one of Ray’s largest customers—uses RL to power the models behind their characters. When you have a physical world or game environment to model, RL still wins. Different problems need different approaches. They all need the same underlying infrastructure to scale.The interesting part isn’t that everyone uses similar tools. It’s that the bottlenecks are identical. They’re all hitting the same walls—and most of them think they’re the only ones.Where the real moat livesPre-training gets the headlines and the hype. Post-training is where the actual differentiation happens.Think about it: pre-training is increasingly commoditized. You can use foundation models from OpenAI, Anthropic, or Meta. But post-training—fine-tuning models for your specific use case, your specific data, your specific product needs—that’s where you build something defensible.And post-training infrastructure is brutally complex. You need inference stages mixed with training stages. You’re constantly moving between different compute resources. You’re orchestrating model weight transfers. You’re debugging why your pipeline breaks at 2am.This is why eight of the ten most popular open source post-training libraries are built on Ray. Anthropic Claude uses them. Cursor’s agents use them. Not because Ray is magic, but because orchestrating this complexity requires infrastructure built specifically for heterogeneous compute.“They all use post-training libraries, and someone has to orchestrate and handle compute efficiently,” JK explains. “You can have inference stage, your training stage within the post-training libraries itself, and there’ll be a lot of complexity around where each one of these stages runs.”Your competitors are using the same foundation models. They’re reading the same papers. The differentiation isn’t in the base technology—it’s in how efficiently you can customize it for your needs. That’s an infrastructure problem, not a model problem.The distance that creates the viewJK’s ability to see these patterns comes from somewhere specific. He grew up in a classroom with one other student—not a small private school, but a remote village in India where it took 10 days to receive a telegram about his grandmother’s death. The world had phones. His village didn’t.Years later, visiting relatives in the city, he saw a two-line pager clipped to his uncle’s belt. “I was like, whoa, what the hell is this?” he recalls. He asked which company made it. Motorola. “That’s where I want to be.”That distance from infrastructure—then getting close to it—shapes how you think about abstraction layers. He joined Motorola during its decline, then landed on the early Android team at Google when they were 10-15 people figuring out what they were building. Then co-started Uber’s AI group. Then Anyscale.JK has been in this position before: seeing the platform-level patterns emerge while individual companies think they’re solving unique problems. The moment that crystallized it happened on a bus in Panama in 2012. A local spent the entire ride on WhatsApp. JK asked what he was doing for so long. “He kind of gave me this look saying, dude, what a stupid question,” JK remembers. “He just said that this has allowed me to keep in touch with my family in remote village.”From Android enabling that Panama bus connection to Ray enabling AI at scale—JK’s entire career has been about building the infrastructure layer that lets others build. And that vantage point is what lets him see the convergence happening now.The honest take on AI coding agentsAnyscale is targeting 30% productivity gains from AI coding tools. Not 10x. Not zero. Thirty percent.That’s the honest number—and it’s harder to achieve than you’d think.JK tried an experiment a year ago: fed Ray code to an AI agent without reviewing it, just to see what would happen. His cluster crashed. He spent the next two hours debugging why. The agent had written code that consumed too much memory, causing out-of-memory errors.This is someone who runs production AI infrastructure at massive scale. Even he can’t blindly trust AI-generated code.What works instead: spec-driven development. Detailed markdown files. Clear design documents. Tell the agent exactly what you want—function length limits, testing requirements, how to use specific libraries. Then review what it produces.“You cannot just vibe-code a system into production,” he explains. “I’ve seen engineers who say, ‘Oh, I just used agents for this,’ and they’ll look at the crap it has produced and it’s caused me more problems.”But here’s where it gets interesting. One of Anyscale’s senior engineers was firmly in the anti-LLM camp. Then he worked on a complicated problem with a distinguished member of the staff who used agents effectively. Two days later, JK got a Slack message: “Couldn’t have produced this code in three days. It would’ve taken me two weeks.”The pattern? Senior engineers who’ve been through previous platform shifts (internet, mobile, cloud) adapt faster. They recognize tectonic change when they see it. Junior engineers coming in fresh adapt quickly too—they haven’t developed rigid workflows yet. It’s the engineers in the middle who struggle most.The critical part: humans stay in the loop. “We do not want to be completely dependent on agents that we lose the critical thinking part,” JK emphasizes. “You need to understand your code at a deep level. You need to understand your design at a deep level and then let agents do their thing.”That’s the realistic target: 30% productivity gains with spec-driven development, human review, and clear expectations. Anyone claiming 10x either hasn’t shipped to production or is starting from scratch.What this actually meansAI coding agents can deliver 30%—if you do it right. Write detailed specs. Review everything. Keep human

Most engineering leaders learn leadership the hard way.They get promoted from IC roles and suddenly find themselves managing people they used to work alongside. They default to command-and-control because that's what they've seen. They struggle with influence across teams they don't control. The transition is messy, stressful, and often unsuccessful.Richard Ford took a different path. He's the VP of Engineering at CyberCube, with a resume that spans a PhD in Quantum Physics from Oxford, developing IBM's computer virus immune system, and building the world's largest web hosting system at Verio. But his most valuable leadership training came from an unexpected place: 10 years as a university department head.This wasn't a detour from his tech career—it was the perfect laboratory for mastering engineering leadership.🎧 Subscribe and Listen Now →The Academic Leadership Laboratory"Being a professor, being a department head specifically was the best training in the world for running engineering teams," Richard told me. "Because as a department head in a university, you have no carrot and you have no stick."Think about this constraint. His biggest reward? "I can give you a slightly bigger office next year." His biggest punishment? "I will give you a bad review, but it won't make any difference to your raise and it won't make any difference to your employment because you're tenured."This forced Richard to develop something most engineering leaders never master: pure influence without authority."What you learn to do is manage by influence, to get people on the boat and make them want to come with you, and to build consensus," he explained. "And I think there's a lot of parallels with engineering where it's all about the people and it's about having influence across groups that you don't control."The academic constraint created the perfect training ground. No shortcuts. No positional power to fall back on. Just the fundamental skill of making people want to follow your vision.The Influence ToolkitRichard's academic experience gave him what he calls "a big grab bag of different techniques for getting people to come along, ranging all the way from 'Hey, let's try it your way' to really let them explore, give them a lot of freedom, all the way down to 'No, I'm calling the ball. This is getting done this week and this is what we're doing.'"The key insight: "You shouldn't just default to a style. You should look at the personal group that you're working with. You should figure out what is the most effective approach to get the result that we need to get as a team."This adaptability comes from understanding that "this sort of failure mode where we have a default style as a manager, as a leader, it is actually terrible. It's a snare."Instead of one-size-fits-all leadership, Richard developed situational mastery. By nature, he's "much more of a consensus builder and a group builder, but that's not my only style, and I can pull in whatever style the situation requires."The Partnership MindsetAcademic leadership taught Richard something else crucial: how to think about working relationships."I don't think of my employer as my overlord. They're my partner. We're doing this together," he said. "You want to find an employer and an environment that suits your skillset, that suits how you think about the world."This partnership mindset extends to his team management. "If you're not in the right environment, you'll never do the best work of your career. And what are we here to do? We're here to do the best work of our career because it's so fulfilling to be at the top of your game."The practical result: Richard gravitates toward environments that bring out his team's best work, not just maximum compensation. "There's such a thing as enough when it comes to comp. Money isn't my primary motivator. It's fulfillment."Communication Across DifferencesAcademic leadership also taught Richard that "everyone's different, and so you have to take a variety of approaches to get your message across."His communication strategy is deliberately multimodal: "There's physical—we're in the same room, one-on-ones or group meetings. There's presence going out to the satellite office. Then yes, I send out an email every few weeks to the team telling them what's up next. And we have all hands and we have smaller group meetings and I push stuff out in Slack."The principle: "We shouldn't require the consumer to match our style. We should try and match the style of the consumer because that's gonna be most effective."Even his meeting structure reflects this understanding. "It's always the last thing somebody says in the meeting that's the thing they actually set it up for," so he books 30-minute meetings for 25 minutes, knowing the real conversation happens when people feel they have time to bring up what's actually on their mind.What This Means for Your Engineering LeadershipFirst, develop your influence toolkit beyond hierarchical authority. Practice getting alignment through understanding and motivation, not just positional power. The academic exercise: try leading a volunteer project where you have no formal authority.Second, build situational leadership skills. Don't default to one style—develop approaches ranging from collaborative exploration to decisive direction-setting. Match the approach to the specific challenge and team dynamic, not your comfort zone.Third, think partnership, not hierarchy. Optimize for environments that bring out your team's best work, not just maximum individual compensation. As Richard puts it: "There's such a thing as enough" when it comes to money, but no limit to fulfillment and growth.Fourth, communicate multimodally. Different people consume information differently. Don't make your team adapt to your preferred communication style—adapt your communication to reach everyone effectively.The leadership question: Before making any major team decision, ask yourself: "How can I get people to want to come with me on this?" The answer will usually produce better decisions and stronger team alignment than pure top-down directives.Richard's academic detour wasn't a detour at all. It was deliberate preparation for the influence-based leadership that modern engineering teams actually need. The constraint of no authority forced him to master the skills that make authority effective when you have it.About CyberCube:CyberCube is the leading provider of cyber risk analytics for the insurance industry, delivering the data and modeling capabilities that power over 70% of global cyber insurance premiums. Founded in 2015 and now backed by over $180MM in recent funding from Spectrum Equity and others, CyberCube serves more than 130 clients across the insurance value chain—including 75% of the top 40 US and European cyber insurers.The company’s engineering teams, led by VP of Engineering Richard Ford, build AI-powered software solutions that help insurers, reinsurers, and brokers quantify and manage one of the most complex risks facing organizations today. With a multidisciplinary team spanning San Francisco, New York, Chicago, London, and Tallinn, CyberCube is on a mission to build societal resilience to cyber risk by making it quantifiable, insurable, and manageable at scale.Learn more at cybcube.comHigh Output is brought to you by Maestro AI. Richard talked about how academic leadership taught him to "get people on the boat and make them want to come with you"—but that influence-based approach creates a new challenge for engineering leaders. When your team is distributed across Slack, Jira, and GitHub, it becomes impossible to see who's actually engaged and where your influence is working. Maestro cuts through that chaos with daily briefings that reveal where your team's time and energy actually go, so you can spot when your leadership approach is building momentum or hitting resistance.Visit https://getmaestro.ai to see how we help engineering leaders measure influence and team engagement beyond vanity metrics.Leading through influence instead of authority? We'd love to hear your approach. Schedule a chat with our team → https://cal.com/team/maestro-ai/chat-with-maestro This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit maestroai.substack.com

Most engineering leaders are still running interviews like it's 2004.Multiple coding rounds. Brain twisters on whiteboards. Engineers throwing their favorite puzzle at candidates. The whole process optimized for showing off interviewer cleverness rather than predicting job performance.Ashwin Baskaran figured this out early. He's the VP of Engineering at Mercury, the fintech that more than 200,000 companies trust with their finances. Over his 20+ years in engineering leadership—from startups to Citrix to scaling Mercury—he's watched the industry slowly realize that technical depth alone doesn't predict success.The companies still doing leetcode marathons are missing the point entirely.🎧 Subscribe and Listen Now →The Product Sense Revolution"I would say interviews in the early part of when I became a manager tended to be very technical," Ashwin told me. "Multiple coding rounds. But simply doing more technical interviews doesn't necessarily give you more signal."Here's what's interesting: a well-designed single coding interview gives you more signal than four or five ad hoc brain teasers. But that's not even the biggest shift.The real evolution is recognizing that engineers need product sense. "I think the typical product company has more of an expectation that engineers will have ideas on the product and have product sense and not outsource their thinking."At Mercury, Ashwin literally asks candidates: "Define the product." He leaves it vague on purpose. Whether it's infrastructure for databases or tools for general contractors, he's looking for people who understand boundaries—who built this, who experiences it, how they're experiencing it."I'm looking for people who have the sense like, there's a boundary and this boundary is being experienced by somebody."The AI Testing GroundBut here's where it gets really interesting for the AI era. While everyone's debating productivity gains, Ashwin's team has been quietly experimenting across their 250+ engineer organization."Our general hypothesis is that it's gonna be a net positive," he said. "But it is going to be a bit of a journey."The key insight: different types of problems benefit differently from AI assistance. Greenfield applications? AI shines. Legacy systems with complex context? Much harder. Python and TypeScript seem to get better results than other stacks, though the data is still anecdotal.This creates a new interview challenge: "Do we change our interview structure and measure for proficiency with AI tools?"Mercury is exploring screening processes that actually watch candidates use coding assistants in real-time. Not just prompting—sophisticated use of the tools integrated into VS Code. The question isn't whether someone can code, but how effectively they can collaborate with AI.The Architecture AdvantageAshwin's prediction for the future cuts through the hype: "I like this concept that this will actually drive extreme modularity."His reasoning is compelling. Today, creating microservices means dealing with schemas, protocol buffers, gRPC boilerplate—all the toil that makes developers avoid proper boundaries. But AI excels at generating exactly this kind of repetitive infrastructure code."All of those things that are toil associated with building something that way could vanish. Those could be some of the early things that vanish."The result? Systems with much better boundaries. Code that's easier for both humans and AI to understand and modify. The less context an AI needs to incorporate, the better outcomes you can expect.Even more provocatively: "Prompts, or some variation of the prompt plus other contextual information could actually be the new code. And your code itself is like assembly code or machine code—the thing you produce whenever you need it, not the thing you version control."What This Means for YouFirst, audit your current interview process. If you're still doing multiple coding rounds or whiteboard brain teasers, you're optimizing for the wrong signal. Design one well-calibrated coding interview and invest the saved time in assessing product sense and communication skills.Second, start experimenting with AI-augmented interviews for appropriate roles. Not every position needs this, but for roles involving rapid prototyping or greenfield development, understanding how candidates collaborate with AI tools is becoming critical.Third, prioritize modular architecture now. Whether AI reaches its full potential or not, better boundaries between systems will benefit your team. And if AI does deliver on code generation, you'll be perfectly positioned to take advantage.Fourth, recognize that technical interviews are moving toward assessing judgment, not just implementation ability. In a world where AI can generate code, the premium is on engineers who understand what to build and how it fits into the larger context.The question for your next hire: Are you screening for someone who can write algorithms on a whiteboard, or someone who can define product boundaries and collaborate effectively with both humans and AI?The leaders who evolve their hiring practices now will build significantly stronger teams than those still stuck in 2004.High Output is brought to you by Maestro AI. Ashwin talked about how "simply doing more technical interviews doesn't necessarily give you more signal"—the same principle applies to measuring your engineering team's performance. While most leaders rely on outdated metrics like story points, the real signals about velocity and blockers are hidden in your team's daily work. Maestro reveals which practices actually drive results and which just create noise.Ready to move beyond surface-level metrics? Schedule a chat with our team → https://cal.com/team/maestro-ai/chat-with-maestro This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit maestroai.substack.com

Most hypergrowth startups hire fast and regret it later.They compromise on quality to fill seats, rationalize cultural misfits as "learning experiences," and spend months fixing the technical debt created by rushed hires. Adam Kirk took a different approach: he hired 35 engineers in 12 months and raised his quality bar with each hire.Adam is co-founder and CTO of Jump, where they've built a note-taking platform specifically for financial advisors that grew from 4 people to 50 in one year. But here's what makes his story different: instead of the typical startup hiring playbook, he invented a process that lets him see how candidates actually work before making decisions.The result? A team scaling at breakneck speed without the usual quality compromises. Here's how he did it—and why traditional hiring advice fails when you're moving this fast.🎧 Subscribe and Listen Now →The Extreme Ownership FilterTraditional hiring advice says "hire for potential and train for skills." Adam learned this doesn't work when you're drowning in growth and can't afford hand-holding."As a matter of survival, I'm looking for somebody who can just, you know, I can say like, look, take this part of the product and own it, and I don't make it so that I don't have to think about it anymore," he explained. "Make excellent decisions, build it really fast. Fix all the bugs. Deliver a ton of value to customers such that I don't really have to think about it anymore."This isn't just preference—it's survival. When you're making 100 decisions per day and reading hundreds of Slack messages, you need people who can take complete ownership without ongoing guidance.The contrast with most companies is stark: "One feedback I got from somebody was that most companies want engineers to constantly be asking for permission or getting validation on what they're doing. The way that we work is sort of like, no, I trust you. Just go get it done."This filter eliminates 90% of candidates immediately. But for hypergrowth companies, hiring someone who needs constant direction is actually more expensive than not hiring at all.The Trial Week RevolutionHere's where Adam's approach gets innovative: instead of trying to predict performance through interviews, he pays candidates to work for a week on real problems."We give them an actual real difficult challenge, like a ticket that we need built. We get to see them actually working on our code base, actually building something that we need," he said.The process starts with a 30-minute coding exercise to screen basic proficiency, then moves directly to a paid trial week. No multi-round interviews, no theoretical problems, no whiteboarding sessions.What this reveals that traditional interviews can't:* How they handle ambiguity when requirements aren't perfectly defined* How they communicate when they're stuck* How they integrate with the existing team and codebase* Whether they can actually deliver results in your specific environment"Usually by halfway through the week, we know that this is somebody that we want to work with," Adam noted. The approach is intensive—"you're onboarding them, getting them set up, you're evaluating their work constantly"—but it dramatically reduces hiring mistakes.Most importantly, it works for candidates too: "It's good for applicants because they get to see how's the team? Do they like the code? Do they like the tech stack? Working with us for a week, they're pretty sure whether or not it's a good fit for them."When the CTO Can't ScaleAdam's honest about the personal cost of hypergrowth: the system that got them here isn't sustainable for him personally."I make too many decisions every day. I have too much context switching fatigue. I'm reading hundreds of messages in Slack every day. I am being asked to make a hundred decisions every day," he told me. "I wouldn't describe my state as sustainable right now."The challenge isn't just volume—it's that the hardest problems naturally filter up: "All the crap kind of filters to the exec, up to the CEO or to the top. All engineering problems, the worst problems filter to me. And a lot of them are stuff that are not fun to deal with."But here's his insight: there are only two "glass balls" he can't drop that will compound over time—code quality and hiring quality. Everything else can be managed or delegated, but these two mistakes get more expensive every day you don't fix them.His solution is to hire people who can completely remove decision-making burden: "I need you to take one of these bricks that I'm holding and take it completely from me."The AI Productivity Reality CheckWhile the industry debates whether AI will replace engineers, Adam has measured actual results in a hypergrowth environment where productivity matters immediately."For some things it makes you 10 times faster, like writing tests. AI is so good at writing tests you should never write your own tests anymore," he said. "Maybe it five Xs you while you're typing out the code, maybe it two Xs you answering questions about the codebase."His measured assessment: "The effective increase over all those things combined is probably around 1.5 to 2x more productive."But here's the strategic insight most leaders miss: this doesn't reduce hiring needs. "If you take your 10 engineers, give them AI, and now they're 20, your competitors are gonna hire 20 and double it to 40. You can't hire less engineers."The competitive advantage isn't using AI to hire fewer people—it's using AI to make your existing team more capable while continuing to hire aggressively. Adam's team uses AI extensively during trial weeks to see how candidates leverage these tools in real work.What This Means for Your StartupFirst, design your hiring process around actual work, not theoretical scenarios. If you can't afford to pay someone for a week of real work, you probably can't afford to hire them full-time either.Second, hire for extreme ownership when scaling fast. Hand-holding kills velocity when you're trying to move at hypergrowth speeds. Look for people who can take complete ownership of product areas without ongoing management overhead.Third, accept that hypergrowth means accepting some unsustainability in exchange for speed. The question isn't whether you'll be overwhelmed—it's whether you're building systems that will eventually let you delegate the right decisions.Fourth, use AI to amplify your best people, but don't expect it to replace hiring. The 1.5-2x productivity gains are real, but your competitors will use the same tools. The advantage goes to whoever can hire and scale the fastest while maintaining quality.The trial week test: Before your next hire, ask yourself: "Would I be comfortable paying this person for a week to work on a real problem?" If not, keep looking. The cost of a failed trial week is much less than the cost of a bad hire.This conversation with Adam Kirk originally appeared on the High Output podcast. For more from-the-trenches insights from engineering leaders navigating hypergrowth and AI transformation, subscribe here.High Output is brought to you by Maestro AI. Adam talked about drowning in "hundreds of Slack messages every day" and making "a hundred decisions every day"—but that decision fatigue creates a visibility problem that most engineering leaders face. When your team is distributed across Slack, Jira, and GitHub, it becomes impossible to see who's actually delivering and where bottlenecks are forming. Maestro cuts through that chaos with daily briefings that reveal where your team's time and energy actually go, so you can spot the high performers worth promoting and the blockers slowing everyone down.Visit https://getmaestro.ai to see how we help engineering leaders make better decisions about their teams and projects. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit maestroai.substack.com

Mike Weaver followed every rule in the engineering playbook.When LLMs started disrupting Replicant's voice automation platform, he did exactly what conventional wisdom dictates: "Let's incorporate it in parts of the product. Let's improve these parts of the experience." Keep the legacy system running, gradually migrate functionality, minimize risk.But months into this approach, Mike hit the wall every engineering leader knows: "The way that story always seems to end is the new one never launched."That's when Mike discovered something that changed everything. AI coding tools had fundamentally altered the economics of rebuilds. "The velocity you can move at with greenfield development is just preposterous," he realized. Instead of years-long migrations that typically fail, his team could rebuild Replicant's core platform in 90 days with 12 people.The result? They "threw things away and started over"—successfully. This breakthrough demonstrates how AI fundamentally changes the strategic calculus for engineering leaders.This reveals what most leaders are missing: AI fundamentally changes the strategic calculus of engineering decisions. Before AI coding tools, engineering leaders faced an impossible choice—keep maintaining legacy systems that block innovation, or attempt risky, years-long rebuilds that usually fail. AI creates a new strategic option: rebuilds that are both fast and low-risk, fundamentally shifting how leaders think about technical debt and resource allocation.🎧 Subscribe and Listen Now →The Demand Multiplier Nobody Talks AboutHere's what Mike discovered at Replicant: AI doesn't reduce the need for engineers—it multiplies what's economically possible to build.Mike started programming in the late '80s with BBSs, graduated during the dot-com boom, and learned hardcore C++ from "absolute badasses" who came out of Bell Labs. Over 16 years of engineering leadership, he's seen every technology wave—and this one is different."The overall need and desire for software in the world just seems to completely outstrip supply," he told me. "I just don't see” AI killing software jobs. “It'll just be more software.""I was just talking to a guy today who runs this gym that I work at," Mike explained. "He says he cannot find any software anywhere that will do this biomechanics type analysis that he wants to do. They do motion capture on people who work out there to analyze all this stuff about how their performance is and create custom workout plans for them."Mike's reaction: "How does that not exist? Like all that, none of that technology is like hard to do. Like the motion capture stuff's all figured out. It's just sort of a data munging application with like a UI and some ML in there."The answer: "I think it's just 'cause the market's too small."But here's the insight: "If you change the economics, maybe not."This is the job creation mechanism nobody sees. AI isn't replacing engineers—it's making thousands of niche markets suddenly viable. Software that was too expensive to build for small markets becomes profitable when development costs drop 10x.Why Companies Do More, Not Hire LessMike's experience challenges the conventional wisdom about AI-driven downsizing. When I asked if he thought people would still have engineering jobs, his response was immediate:"I do, I do. I think there's this whole talk about companies will be smaller. I just think companies are just gonna do more."He made it concrete: "If you're at a startup right now. How long is your to-do list? Like if I double the size of your engineering team tomorrow, would you have stuff for them to do? Yes."This matches what Mike saw at Replicant. With AI tools like Cursor, his team rebuilt their entire conversation automation platform in 90 days—something that would have taken two years before. The result wasn't fewer engineers. It was more ambitious product goals and rapid team growth."There's so many parts of the business world, the industrial world, that have not really been penetrated by technology," Mike observed. "Those are all ripe for people to go in there and do it."The Skills That Matter MoreMike sees the real challenge differently than most. It's not about AI replacing engineers—it's about engineers adapting to work effectively with AI tools."Experienced engineers who can use those tools, have experience with the tools as well—'cause I think it takes, there's some learning curve to get the most out of them—can just produce an enormous quantity of reasonable quality software very, very quickly."But the bigger shift is social, not technical. "As you become a more senior engineer, I see it's all about communication," Mike explained. "There's only so much you can get done as an individual. And then you need to go outside yourself."With AI handling more routine coding, human coordination becomes the bottleneck. "If everyone can produce code at four times the rate they used to, it's like, okay, well now, there are no more solo projects. You're gonna have to coordinate."What This Means for YouMike's experience reveals four principles for engineering leaders preparing for the AI-driven future:First, stop asking whether AI will replace engineers. Start asking what becomes possible when engineering costs drop dramatically. The constraint isn't demand for software—it's our ability to build it economically. AI removes that constraint.Second, embrace the rebuild option. Mike's 90-day platform rebuild would have been impossible before AI coding tools. If you're carrying technical debt from pre-AI architectures, the cost-benefit analysis of rebuilds has fundamentally changed.Third, invest in communication skills across your team. "I think the only challenge junior engineers are gonna have is that their expectations will be higher, quicker," Mike noted. When AI handles routine coding, human coordination becomes the new bottleneck.Fourth, think about untapped markets, not just optimization. Mike's gym example illustrates thousands of niche applications that were previously uneconomical. The next decade belongs to engineers who can identify and serve these newly viable markets.The question for your next strategic decision: Instead of asking "How do we stay competitive?" ask "What becomes possible now that wasn't possible before?"High Output is brought to you by Maestro AI. Mike talked about how AI tools let his team "produce an enormous quantity of reasonable quality software very, very quickly"—but that speed creates a new challenge. When your team can build 4x faster, staying aligned on what you're actually building becomes critical. Maestro cuts through the noise with daily briefings that reveal where your team's time and energy actually go, so you can spot when that increased velocity is pointing in the wrong direction.Visit https://getmaestro.ai to see how we help engineering leaders maintain alignment in the age of acceleration.Have your own story about AI changing your engineering strategy? We'd love to hear it. Schedule a chat with our team → https://cal.com/team/maestro-ai/chat-with-maestro This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit maestroai.substack.com

Most engineering leaders think about AI wrong.When they see a new model, they ask: "How fast can we ship this?" But the interesting question is: "Where will this break?"Troy Astorino figured this out early. He's the CTO of PicnicHealth, and they've built something remarkable: an 8 billion parameter model that beats much larger frontier models at medical tasks. Because Troy understood exactly where large, general models fall short—and he engineered around those constraints.His company built what might be the world's best LLM for medical records—working with 7 out of 10 largest pharma companies and collecting 350 million clinician annotations over a decade. But Troy's most valuable insight isn't about AI's capabilities. It's about the immovable constraints that determine whether your AI implementation succeeds or becomes expensive theater.The Filing Cabinet ProblemTroy grew up around medicine. Both his parents were doctors. As a kid, he worked in their offices and was "horrified by walls of filing cabinets." When the government spent $40 billion digitizing medical records, Troy thought: finally. Software will fix this mess.It didn't. Most EMR systems made doctors less efficient, not more. This taught Troy something important: you can't just layer technology onto broken processes. The process has to change too.This insight shaped everything that came after.🎧 Subscribe and Listen Now → When Leaders Need to Code AgainHere's what's interesting about leadership during technological shifts: engineering leaders may need to get more technical, not less.Troy started PicnicHealth in 2014, writing code all day. As the company grew, he did what every engineering leader does: stepped back from implementation to focus on team building. "The highest leverage way for me to work is less building everything directly and more building out the team."But when LLMs emerged, Troy had to reverse course. "The ability to understand where opportunity is requires more direct hands-on experience," he told me.Why? Because understanding real constraints requires hands-on experience. Where does fine-tuning actually help? Which domains are narrow enough for reliable automation? You can't evaluate these opportunities from team status reports, because the technology is changing too fast.Troy recognized that during periods of rapid technological change, engineering leaders need deeper technical fluency to make good decisions. He had to balance staying close enough to the technology to spot constraints while still enabling his teams to do their best work.This isn't micromanaging. It's strategic intelligence gathering about what's actually possible.The Data MoatPicnicHealth's advantage isn't the size of their models. It's their data.They have 350 million annotations from real doctors using their system over a decade. Every time a doctor corrects the AI, the model gets better. "That kind of medical record data is not in the public training corpus," Troy explains.This creates something interesting: a feedback loop that gets stronger over time. The more doctors use the system, the better it gets. The better it gets, the more doctors want to use it.Most AI companies focus on building more powerful models. PicnicHealth focused on building better data collection systems.The Application Layer SurpriseIn 2022, everyone thought AI value would flow primarily to model creators—OpenAI, Anthropic, Google. The reasoning seemed sound: models are the hardest part to build, so they should capture the most value.This turned out to be incomplete."I'm very glad that we live in a world where a lot of value is delivered and captured by the application layer," Troy says. Here's why: foundation models are commoditizing, but domain expertise isn't.A general-purpose model might have broad knowledge, but it doesn't know the specific workflows of clinical trials, or how doctors actually review patient records, or which edge cases matter most in your domain.This is where constraints become advantages. By focusing on medical records exclusively, PicnicHealth could optimize for things that matter in healthcare but nowhere else.The Narrow Domain StrategyMost AI implementations fail because they try to solve everything at once. Picnic Health builds AI agents that operate within their integrated clinical trial system. This sounds limiting, but it's actually powerful.When you control the entire workflow—from data ingestion to final output—you can build in validation loops, human oversight, and error correction at every step. You can define clear success metrics and create tight feedback cycles.General-purpose AI tools can't do this. They have to work for everyone, which means they're optimized for no one.Bottlenecks Don't DisappearHere's the thing about technological progress: it doesn't eliminate bottlenecks, it just moves them.AI accelerates drug discovery, but regulatory approval still takes 7-10 years. "Even if there's way more potential assets," Troy observes, "you're still 10 years away from people actually being able to use that."This pattern repeats everywhere. Technical capabilities advance at an amazing pace, but distribution into real industries and workflows takes much longer. It requires changing human behavior, not just building better software.The leadership lesson: don't assume AI will solve your bottlenecks. Assume it will create new ones. Your job is figuring out where.What This Means for YouIf you're building with AI, Troy's approach offers a different path:First, understand your constraints before you optimize for capabilities. Most processes have hidden bottlenecks that no amount of AI will fix. Find those first.Second, build data flywheels, not just models. Look for workflows where user corrections create proprietary datasets. This is how you build moats in a world of commoditized models.Third, go narrow before you go wide. Start with controlled environments where you can measure success precisely and iterate quickly. Reliable automation in a narrow domain beats unreliable automation everywhere.Fourth, during technological shifts, technical leaders need to stay technical. You can't evaluate AI opportunities from conference rooms. You need to understand the constraints firsthand.The question for your next AI decision: are you solving a real constraint, or just adding sophisticated automation to a broken process?The difference determines whether you build a moat or just an expensive feature.A Note About Maestro AITroy described a challenge most engineering leaders face: as you grow from writing code to leading teams, you lose visibility into what's actually happening. When the work is scattered across Slack, Jira, and GitHub and more, it becomes impossible to see where time goes or what's blocking progress.Maestro AI solves this with daily insights that show where your team's energy actually goes, so you can spot problems before they compound.If you're tired of guessing what's really happening with your team, visit getmaestro.ai or schedule a chat with us here: https://cal.com/team/maestro-ai/chat-with-maestro This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit maestroai.substack.com

This week on High Output, Adil Ajmal, CTO of Fandom, tackles the question every engineering leader is wrestling with: How do you get an entire organization to adopt AI without simply mandating it?While many engineering leaders are navigating AI adoption with a mix of top-down encouragement and bottom-up experimentation, Adil took a more structured path. He set a specific, measurable goal: 80% AI adoption across Fandom's engineering organization this year. Not 100%. Not "eventually." Exactly 80%—because he learned that successful technology adoption is about deliberate change management, not just wishful thinking.Managing AI strategy for 350 million monthly users across 250,000 communities, Adil has discovered that the challenge isn't the technology itself—it's getting distributed teams to embrace it while maintaining the stability that massive scale demands.🎧 Subscribe and Listen Now → What's inside (34 min):→ The 80% strategy. Why Fandom set a specific AI adoption goal rather than hoping it happens: "We've set a goal of AI adoption for our teams... we measure our usage." The framework includes enterprise licenses, internal champions, and treating it as deliberate change management, not a tech rollout.→ Measuring what matters. How Fandom tracks adoption across different tools and teams: "We also bring in the right tool for the right thing. So if you're doing more front end development, you know, we have cursor that you can use... copilot is better for a bunch of other things."→ The champion strategy. Instead of mandating from the top, finding internal advocates who can show others what works: "We try to find champions within our team who've had good experiences so that they can be the promoters of it for other team members."→ Experimenting safely at scale. How Fandom balances AI adoption with stability for 350 million users: "You don't want to skip the code review part. You don't want to skip the automated test suites." The key is knowing what AI is good at—and what it's not.→ The global content challenge. Why AI translation works perfectly for Shogun but breaks for Expedition 33: "Your translation may be factually correct, but if it doesn't actually match with how people are using it, it's not going to work out." Human oversight becomes critical at scale.Why it mattersWe're past the point of debating whether to adopt AI—the question now is how to do it effectively across entire engineering organizations. Most companies are taking one of two approaches: mandate it from the top or hope engineers adopt it naturally. Both strategies fail.Adil's 80% goal reveals a third way: set specific, measurable targets and treat AI adoption like any other major organizational change. It requires champions, metrics, enterprise-grade tools, and deliberate change management.His experience managing multiple company acquisitions (Twitter, Amazon, Intuit) taught him that successful technology adoption isn't about the technology—it's about people. The same principles that work for integrating acquired teams work for AI adoption: alignment, context-setting, and giving people time to internalize change.At Fandom's scale, the stakes are higher. With 350 million users depending on platform stability, they can't afford to experiment recklessly. But they also can't afford to fall behind on AI capabilities. Adil's approach shows how to thread that needle.Your turnAdil's framework challenges us to be more deliberate. Here are two questions to consider:* Can you actually measure your team's AI adoption, or are you flying blind? What would change if you could see exactly how AI tools are impacting your team's velocity and output?* As AI creates more efficiency, where are you reinvesting that time—into your product, your platform, or your people?If you're wrestling with AI adoption strategy for your engineering team, we'd love to hear your story. Schedule a chat with us → https://cal.com/team/maestro-ai/chat-with-maestroHigh Output is brought to you by Maestro AI. As your teams adopt AI tools to ship faster, staying aligned on what you're actually building becomes the critical challenge. Maestro cuts through the noise with narrative status updates that digest every ticket, code change, and team discussion—because in a world where you can build anything, you need clarity on what you should build.Visit https://getmaestro.ai to see how we help engineering leaders maintain alignment in the age of acceleration. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit maestroai.substack.com

This week on High Output, Tacita Morway, CTO of Textio, reveals why the biggest challenge in the AI era isn't learning new tools—it's learning what not to build.From landscape design to heavy machinery operation to leading engineering teams, Tacita's unconventional path taught her that management isn't about having all the answers. It's about asking better questions. Now, as AI transforms how we build software, she's applying that same principle to help teams navigate an overwhelming abundance of possibilities.🎧 Subscribe and Listen Now →What’s inside (34 min):→ The brick wall moment. Tacita's transition from engineer to manager felt like "running full force into a brick wall." Her solution? Stop asking "what did I ship today?" and start asking "how are my people growing?"→ The information fire hose problem. With AI breakthroughs arriving faster than anyone can absorb them, Tacita's filtering strategy: problems first, technology second. "What challenges am I trying to solve right now?"→ AI as your most honest critic. Tacita uses AI to get the unvarnished feedback her team might be too polite to give: "These systems won't hold back—they'll tell you when you're missing something your colleagues might be too polite to mention."→ The end of rigid roles. Her prediction: role boundaries between PM, engineering manager, and designer will collapse as AI gives everyone superpowers across disciplines.→ The focus challenge. When you can build anything quickly, staying focused on user value becomes the critical leadership skill: "You can do so much now—that's not what they're trying to buy right now."Why it mattersWe're entering an era where the constraint isn't what we can build—it's what we should build. As Tacita puts it: AI will "unlock creativity and invention," but only if we resist the temptation to build everything just because we can.The companies that win won't be those with the fastest AI-assisted development cycles. They'll be the ones whose leaders can cut through the noise of infinite possibilities to focus on real human problems. This requires a fundamentally different kind of engineering leadership—one that prioritizes strategic thinking over technical prowess.Tacita's vision of "smaller teams" and "fluid roles" isn't about cutting headcount—it's about unlocking organizational agility. AI enables large companies to move like small ones, where people collaborate more intensely, ideate more rapidly, and cross-pollinate ideas across dissolving role boundaries. The focus becomes what machines can't replicate: critical thinking, user empathy, and business judgment.Your turnTacita's approach raises the essential question: In an age where you can prototype ideas in minutes and ship features in hours, how are you maintaining focus on what actually matters to your users and business?In this age of abundance, what are you saying no to?If you're wrestling with these challenges, we'd love to hear your story. Schedule a chat with us → https://cal.com/team/maestro-ai/chat-with-maestroHigh Output is brought to you by Maestro AI. When AI lets your team ship faster, staying focused on what matters becomes the critical leadership challenge. As your engineers become more productive, Maestro cuts through the noise with narrative status updates that digest every ticket, code change, and team discussion. Because in a world where you can build anything, you need clarity on what you're actually building. Visit https://getmaestro.ai to see how we help engineering leaders maintain focus in the age of abundance. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit maestroai.substack.com

As AI reshapes the what of engineering, leadership is about focusing on the who.This week on High Output, Glenn Veil, SVP of Engineering at Order.co, shares how three decades of unplanned leadership taught him the most important lesson of all: technology will always evolve—but people remain the constant.Glenn didn't start out aiming to lead. One sudden promotion, a broken website, and a confused loft full of engineers later, he found himself in charge—and completely unprepared. What followed was a trial-by-fire journey from tech-first problem solver to people-first builder of teams, careers, and future leaders.What's inside (23 min):→ The accidental promotion. Glenn thought he was getting fired when the VP was waiting for him at the front door. Instead: "Glen, you're director of technology." He had to tell his new team: "Hey, I think I'm in charge now."→ The hard lesson: people over code. Glenn started by focusing on what he knew—the technology. But he learned that engineering leadership isn't about fixing code; it's about developing the people who write it.→ The great wave of leaders. Glenn's mission today: leaving behind a generation of engineering leaders who know they can succeed by being authentically themselves.→ Reading people, not trends. His secret to staying ahead isn't predicting the great technology—it's anticipating how people and teams will evolve through change.Why it mattersAs AI handles more of the technical heavy lifting, a counterintuitive truth is emerging: the human side of engineering leadership becomes exponentially more valuable.Glenn's prediction is already playing out—companies will operate at dramatically lower costs within five years as AI optimizes processes. But the real competitive advantage won't come from deploying the smartest AI tools. It'll come from using those tools to create space for deeper people development.Smart engineering leaders aren't just automating code—they're choosing AI solutions that help them understand their teams better, spot growth opportunities faster, and develop the kind of human leadership capabilities that no algorithm can replace.As Glenn puts it: "I don't think we'll ever not need software engineers. But we will be leaner. And we'll need stronger leaders to guide the way."The question isn't whether to adopt AI tools. It's whether you're choosing the ones that multiply your people's potential—not just their productivity.Your turnGlenn's approach raises the critical question: How are you using AI's efficiency gains? Are you reinvesting that time and mental bandwidth into developing your people—or just pushing for faster delivery cycles?If you're ready to move beyond productivity theater and start building the kind of human leadership capabilities that will define tomorrow's engineering orgs, we'd love to hear your story.Schedule a chat with us → https://cal.com/team/maestro-ai/chat-with-maestroHigh Output is brought to you by Maestro AI. If you're an engineering leader looking to improve velocity while using AI efficiency gains to develop stronger teams, visit https://getmaestro.ai to learn how we help teams navigate the future of software development. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit maestroai.substack.com

We’re thrilled to share something we’ve been working on at Maestro AI behind the scenes: High Output, a weekly conversation series where visionary engineering leaders unpack how they’re shipping faster, scaling smarter, and future-proofing their teams. These are unfiltered, from-the-trenches takes on running engineering teams amidst seismic transformations in the tech industry.🌌 Why these conversations matter—right nowThe discipline of software engineering is staring at two vastly different futures:* Future 1 - In 10 years, there will be no more software engineers. AI will write all the code, and entire careers paths will vanish.* Future 2 - In 10 years, there will be 10x more software engineers. Barriers to entering the career will drop. Meanwhile, AI will super-charge every developer, and the demand for talent will explode.Of course, reality is somewhere between these extremes—but that “somewhere” spans an entire universe of possibilities. The uncertainty is feeding real anxiety in engineering orgs everywhere. High Output exists to cut through the noise with candid, first-hand stories from leaders who are making concrete decisions today.🎧 Episode 1—Scaling Lean with Raquel RodriguezOur debut conversation features Raquel Rodriguez, Head of Engineering at TYB, the community-rewards startup powering Urban Outfitters, Rare Beauty, and 100+ other brands.Listen now → https://maestroai.substack.com/podcastWhat’s inside (25 min):* Scaling without bloat. Hiring six new ICs, zero managers—How Raquel reorganized into tech-lead pods with one shared stand-up to keep the org flat and decisions moving.* AI as force multiplier. A candid take on using LLMs to amplify, not replace, dev velocity—and the litmus test she uses before trusting an “AI dev agent” with critical work.* Social dynamics at scale. How a 10× surge in community engagement exposed new cultural and reward-economy pitfalls—and how TYB contained them.* Time-management hacks. The “mornings for meetings, afternoons for deep work” rhythm that sticks.🔄 Navigating the new frontier togetherEngineering leadership isn't just adapting to AI—it's actively shaping how this technology transforms our industry. High Output brings you the leaders making pivotal decisions today that will define tomorrow's engineering landscape.Each week, we'll spotlight innovators who are striking that critical balance: using AI to augment human creativity while maintaining lean, resilient teams. Raquel's approach is just the beginning. The gap between AI replacing engineers and AI empowering them isn't just theoretical—it's being decided right now, in organizations like yours.Our ask to you: don't just witness the transformation—help shape it.At Maestro, these conversations are the fuel for our mission. We've built an AI-first approach to measure and track progress in software teams, motivated by the exact challenges engineering leaders share with us every day.If any of this resonates with you, we want to hear your story! Schedule a chat with us. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit maestroai.substack.com