# engineering-leadership Engineering leadership is the practice of leading software engineering teams and systems through people management, delivery coordination, technical decisions, architecture, reliability, and engineering standards. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Presentation: Lead Without a Ladder: How I Climbed Into Engineering Leadership DevFeed: [Presentation: Lead Without a Ladder: How I Climbed Into Engineering Leadership]() Original publisher: [Read original article]() Author: Pauline Jepp Published: 2026-09-15T09:10:00Z Content type: opinion Language: en Sources: [InfoQ]() Topics: [engineering-leadership](), [systems]() Tags: [alignment](), [careers](), [chief-engineer](), [culture-methods](), [engineering](), [engineering-leadership](), [infoq](), [leadership](), [mentorship](), [presentation](), [qcon-san-francisco-2025](), [qcon-software-development-conference](), [safety](), [team](), [transcripts](), [trust]() ### AI overview Pauline Jepp discusses how systems thinking, rock climbing, and flocking behaviors inform engineering leadership. She covers balancing team autonomy with alignment, supporting mentorship and other invisible work, and transitioning from hands-on engineering to leadership while maintaining organizational trust and psychological safety. ### Source excerpt Pauline Jepp explains how systems thinking, rock climbing, and flocking behaviors apply to engineering leadership. She shares strategies for balancing team autonomy with alignment, supporting invisible work like mentorship, and navigating transitions from hands-on engineer to engineering leader while maintaining organizational trust and psychological safety. By Pauline Jepp ## Engineering quality compounds DevFeed: [Engineering quality compounds]() Original publisher: [Read original article]() Author: Mike Shaver, Avery Pennarun Published: 2026-07-21T13:00:00Z Content type: news Language: en Sources: [Blog on Tailscale]() Topics: [engineering-leadership](), [Architecture & Design](), [Firefox](), [systems](), [JIT](), [Linux](), [JavaScript](), [Security](), [Shopify]() Tags: [developer](), [engineering](), [engineering-leadership](), [firefox](), [javascript](), [jit](), [linux](), [news](), [platform](), [security](), [shopify](), [systems]() ### AI overview Mike Shaver joins Tailscale as VP of Engineering, bringing experience in platform engineering, Firefox, Facebook's mobile transition, security products, systems programming, and edge infrastructure. The article frames his role around scaling engineering quality while keeping Tailscale's product reliable, useful, and understandable. ### Source excerpt Mike Shaver joins Tailscale to scale engineering quality. ## 5 pitfalls to avoid when measuring DevEx in the AI era DevFeed: [5 pitfalls to avoid when measuring DevEx in the AI era]() Original publisher: [Read original article]() Author: Candace Shamieh; Teddy Gesbert Published: 2026-06-30T00:00:00Z Content type: article Language: en Sources: [Datadog | The Monitor blog]() Topics: [devex](), [code productivity](), [engineering-leadership](), [Artificial Intelligence](), [Code review]() Tags: [ai](), [ai-adoption](), [ai-impact](), [ci-cd](), [ci-visibility](), [collaboration](), [developer-experience](), [devex](), [devops](), [dora-metrics](), [engineering-management](), [internal-developer-portal](), [metrics](), [performance](), [productivity](), [review](), [software-delivery](), [test-optimization]() ### AI overview This article examines common pitfalls in measuring developer experience during the AI era. It argues that individual output metrics, including token consumption, lines of code, pull request counts, commits, and story points, can undermine trust and collaboration when treated as measures of personal productivity. ### Source excerpt Don't mistake AI adoption for productivity. Learn how to avoid 5 common pitfalls when measuring DevEx, with practices from Datadog engineering ## The Strange Theatre of Technical Hiring DevFeed: [The Strange Theatre of Technical Hiring]() Original publisher: [Read original article]() Author: Daniel Glejzner Published: 2026-06-18T18:15:04Z Content type: opinion Language: en Sources: [Daniel Glejzner]() Topics: [engineering-leadership](), [Software Engineering](), [Code Challenge](), [Development]() Tags: [challenges](), [coding](), [developers](), [engineering](), [engineering-leadership](), [hiring](), [interview](), [software](), [software-engineering](), [technical](), [technical-interview]() ### AI overview The article argues that technical hiring often evaluates experienced engineers through narrow, timed coding exercises that may reward speed, recall, confidence under pressure, and familiarity with interview rituals more than the judgment and contextual skills required in software engineering work. ### Source excerpt A senior engineer joins a technical interview... Hi Angular Space community :) It's been a while since I pushed myself to write something. AI is changing the way we consume literally everything online, and I'm still trying to figure out what the best and most compelling way ## Revised rules of engineering leadership. DevFeed: [Revised rules of engineering leadership.]() Original publisher: [Read original article]() Published: 2026-06-15T13:00:00Z Content type: article Language: en Sources: [Will Larson - Irrational Exuberance]() Topics: [engineering-leadership](), [migration](), [Development](), [CI/CD](), [Code]() Tags: [ci-cd](), [code](), [development](), [engineering](), [engineering-leadership](), [leadership](), [migration](), [tests]() ### AI overview An engineering leader revises their approach based on experience in hypergrowth environments and recent AI-tooling changes. The article argues that individuals can own much larger migrations, while the quality and speed of working code depend heavily on development harnesses such as tests, CI/CD, validation environments, and change previews. It also discusses designing processes so agents can handle common cases with appropriate controls and context. ### Source excerpt From early 2014 through late 2020, I was working in hypergrowth environments, which are challenging, but also educational. The most valuable feature of hypergrowth is that your mistakes reveal themselves next month rather than next year, because things go wrong very loudly when you're moving fast. I've been thinking a lot about hypergrowth recently, because Imprint's business is growing quickly and we did a large batch of hiring last year, but also because the AI-tooling shift has changed the pace at which it's possible to work. This post documents the new rules I've revised my approach to engineering leadership around, and then talks through the specific projects I've worked on over the past year that caused me to believe in these rules. Revised rules Migrations can be done by an individual rather than a team. Even complex, large changes can be 95% owned by the driving individual or team, and done in 10% of the time. As the initial cost of migrations goes down, the reward/penalty of each migration's quality goes up: even small sharp edges will break your colleagues' mental models about the software you co-maintain. The impact of individual judgment on your company has never been higher. While 1st-pass code is nearly free, the cost of working code depends on your development harness, and is not free. We're in an era when many companies say that everyone should be writing code, however our experience is that writing code that works well, while avoiding messy edgecases, remains difficult. Just how difficult remains a factor of your development harness, e.g. your tests, CI/CD, validation environments, preview-ability of changes, and so on. While I personally don't imagine it's valuable for most folks at a company to be contributing code, I suspect that most disagreement about that topic is actually a miscommunication: even at a company where "everyone codes", the marketing team isn't reducing allocations in your servers, instead it's about whether there is a safe bound ## Signs That an Engineer May Be Planning to Leave DevFeed: [Signs That an Engineer May Be Planning to Leave]() Original publisher: [Read original article]() Author: Ryan Murphy Published: 2026-04-17T10:02:43Z Content type: opinion Language: en Sources: [The Software Engineering Times]() Topics: [engineering-leadership](), [engineering-culture](), [Code review]() Tags: [engineering-leadership](), [opinions](), [quality](), [team]() ### AI overview The article discusses observable signs that an engineer may be disengaging and considering leaving, including reduced input, less challenge to decisions, lower participation in future planning, and less investment in work quality. ### Source excerpt Most engineers decide to quit long before they tell anyone. Here is what to watch for. ## Tech Lead vs Engineering Manager. Which Path Is Right for You? DevFeed: [Tech Lead vs Engineering Manager. Which Path Is Right for You?]() Original publisher: [Read original article]() Author: Ryan Murphy Published: 2026-04-07T15:33:44Z Content type: opinion Language: en Sources: [The Software Engineering Times]() Topics: [Tech Lead](), [engineering-leadership](), [Job]() Tags: [career](), [engineering-leadership](), [leadership](), [tech-lead]() ### AI overview This article compares the Tech Lead and Engineering Manager career paths, explaining that they are separate routes rather than steps on a single ladder. It also notes that both paths generally involve becoming less hands-on over time and that engineers can change direction later. ### Source excerpt Most engineers assume it's a one way ladder. It isn't. ## Top engineering voices to follow in 2025 DevFeed: [Top engineering voices to follow in 2025]() Original publisher: [Read original article]() Author: Kate Bernacchi-Sass Published: 2025-07-18T13:00:00Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [engineering-leadership](), [Platform Engineering](), [GitHub Copilot](), [coding]() Tags: [2025](), [community](), [copilot](), [engineering](), [engineering-leadership](), [follow](), [github](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [outage](), [platform-engineering](), [post-mortem](), [slack-incident](), [voices]() ### AI overview An editorial list highlights engineering voices to follow in 2025, focusing on people who share technical insights, leadership experience, organizational perspectives, practical engineering advice, and community contributions. It profiles Camille, Cassidy, and others, with topics including platform engineering, leadership growth, productivity, mental health, coding, and developer tools such as Copilot. ### Source excerpt We launched our list of Top engineering voices to follow in 2025 to spotlight those engineers who aren't just building behind the scenes, but also writing, posting, and contributing in ways that make the whole community smarter. ## Taking Ownership and Handling Difficult Responsibilities as an Engineering Manager DevFeed: [Taking Ownership and Handling Difficult Responsibilities as an Engineering Manager]() Original publisher: [Read original article]() Author: Anna J McDougall Published: 2025-06-25T12:20:24Z Content type: opinion Language: en Sources: [Anna J McDougall]() Topics: [engineering-leadership](), [Development]() Tags: [engineering](), [engineering-leadership](), [engineering-management](), [engineering-manager](), [leadership](), [leadership-team](), [management](), [management-skills](), [software-engineering](), [teams]() ### AI overview This commentary argues that engineering managers must sometimes accept conflict and deliver difficult feedback instead of trying to remain peers with their teams. As leaders move away from hands-on development, they must balance engineers' needs with stakeholders, product, and business expectations. ### Source excerpt An Engineering Manager's Guide to Taking Ownership by Taking Heat Title Image: a vibrant yellow background with a picture of Anna smiling, with two red devil-horns superimposed on top. Title text reads: "It's time to be the BAD GUY. An Engineering Manager's Guide to Taking Ownership by Taking Heat"Introduction At my first project management job, I was given the nickname "Mad Dog".* Any time new sales reps would join the company, the existing reps would try to scare them by telling them "Oh shit, you're on Mad Dog's project". The joke, of course, is that I'm a big ol' ray of sunshine: After a few days of being scared to encounter Mad Dog, those reps would meet me and realise they weren't going to have a problem with some hard-ass micromanager. The same is still true today, but I've also come to realise that there are some benefits to being Mad Dog. Sometimes, the best way to help your team is to lean into being the bad guy. In this post, I'll cover some situations where it's good to be bad, and why being the bad guy is a core management skill. * The nickname came about due to my name's similarity to a famous football player (Adam "Mad Dog" MacDougall). Say "Anna McDougall" and "Adam MacDougall" ten times and you'll hear it. Leadership means stepping out of the team As you move up the engineering leadership chain, from EM to Director to VP to CTO, you become less and less a part of the development teams. This sense of social isolation often drives leaders to try their best to be buddy-buddy with developers, to attempt to completely eradicate any sense of hierarchy, and to improve psychological safety. In general, this is a great idea. As a leader, you do need people to know that you're just human. You should have people trust you with their real thoughts. You must enable a culture where failure and feedback are freely given and learned from. But... You are also the one who has to take the heat from above, and sometimes you have to be the bad guy to the team when it come ## How a manager mindset shapes LLM-assisted coding DevFeed: [How a manager mindset shapes LLM-assisted coding]() Original publisher: [Read original article]() Author: Calvin French-Owen Published: 2025-02-11T12:00:00Z Content type: opinion Language: en Sources: [Calvin French-Owen]() Topics: [Vibe coding](), [Large Language Model](), [cursor](), [engineering-leadership](), [coding]() Tags: [ai-coding-assistants](), [cursor](), [engineering-leadership](), [opinion](), [vibe-coding]() ### AI overview The author examines why engineers differ in their views of LLM-generated code. Drawing on experiments with vibe coding and AI coding assistants, the article argues that success depends partly on how engineers augment themselves with LLMs and how much of the work involves defining goals, guardrails, and desired outcomes rather than implementing technical details. ### Source excerpt There's a lot of debate around how much 'good code' LLMs can write for you. Some engineers claim coding with LLMs is amazing, while others think they are trash. Ultimately, it depends on how much of a manager you are. ## 3 main soft skills a Tech Lead needs to develop DevFeed: [3 main soft skills a Tech Lead needs to develop]() Original publisher: [Read original article]() Author: Anemari Fiser Published: 2024-12-18T15:01:56Z Content type: article Language: en Sources: [Level up as a Tech Lead]() Topics: [Tech Lead](), [engineering-leadership](), [Learning]() Tags: [article](), [developer](), [leadership](), [skills](), [tech-lead](), [tech-leadership]() ### AI overview This article argues that Tech Leads need soft skills in addition to technical expertise, focusing on active listening and examples involving conflict resolution, ownership, team growth, and tech debt. ### Source excerpt Become a great Tech Lead by focusing on these 3 main soft skills! ## Code.Lead.Succeed is changing DevFeed: [Code.Lead.Succeed is changing]() Original publisher: [Read original article]() Author: Dariusz Sadowski Published: 2024-06-30T12:35:50Z Content type: opinion Language: en Sources: [Thinking in Tech]() Topics: [engineering-leadership](), [Software Engineering](), [engineering-culture]() Tags: [engineering-leadership](), [engineering-manager](), [software-engineering](), [updates]() ### AI overview The author explains changes to the Code.Lead.Succeed newsletter and broader publishing strategy for 2024. Long-form content will move to the author's website, while the newsletter will continue with monthly software engineering philosophy articles and personal updates. The author also explains plans to focus more on an engineering leadership coaching business and why they are reducing activity on Substack. ### Source excerpt Code.Lead.Succeed is changing ## DeveloperBridge: SoundCloud's Program for Training People from Diverse Backgrounds to Become Engineers DevFeed: [DeveloperBridge: SoundCloud's Program for Training People from Diverse Backgrounds to Become Engineers]() Original publisher: [Read original article]() Published: 2020-07-17T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Programming](), [engineering-leadership]() Tags: [careers](), [code](), [collaboration](), [community](), [course](), [developers](), [diversity](), [engineering](), [engineering-culture](), [junior](), [leadership](), [learn](), [learning](), [programming](), [recruiting](), [skills](), [training]() ### AI overview SoundCloud's DeveloperBridge is a year-long, paid traineeship that gives people without prior professional experience the opportunity to learn engineering, receive mentorship, and potentially transition into full-time roles. The program also aims to improve diversity and inclusion through broader recruitment and support for underrepresented communities. ### Source excerpt DeveloperBridge is a year-long, full-time, paid traineeship program where participants learn from and work with engineering teams at... ## The Queen of the Skies and Innovation DevFeed: [The Queen of the Skies and Innovation]() Original publisher: [Read original article]() Author: Adam Published: 2019-02-10T00:00:00Z Content type: opinion Language: en Sources: [Shostack & Friends Blog]() Topics: [Flight](), [engineering-leadership](), [Mobile](), [Security](), [Networks](), [vulnerability](), [iphone](), [Windows]() Tags: [aircraft](), [apps](), [aviation](), [engineering](), [government](), [innovation](), [iphone](), [mobile](), [networks](), [security](), [vulnerability](), [windows]() ### AI overview This commentary compares aviation and computing to examine how regulation affects safety, innovation, and security. It argues that aviation regulation has improved safety while slowing innovation, whereas rapid innovation in phones, computers, and networks has created substantial privacy and security risks. ### Source excerpt Innovation, regulation, and more. ## Why I joined Apollo DevFeed: [Why I joined Apollo]() Original publisher: [Read original article]() Author: Claire Hough Published: 2018-10-17T22:28:00Z Content type: opinion Language: en Sources: [Apollo Blog]() Topics: [engineering-leadership](), [dev-tools]() Tags: [community](), [culture](), [engineering](), [inclusive](), [leadership](), [leadership-team](), [team](), [vp-of-engineering](), [work]() ### AI overview Claire Hough describes joining Apollo as its VP of Engineering, drawing on her experience leading engineering teams and outlining her emphasis on learning, psychological safety, inclusive culture, and a supportive work environment. ### Source excerpt We're proud to introduce Claire Hough as our new VP of Engineering. Claire joins Apollo with over 20 years of experience building impactful and inclusive engineering teams at Udemy and Napster. She will be responsible for leading our engineering efforts and ensuring that Apollo continues to help developers build great apps. Please read this post from Claire outlining her vision for Apollo Engineering and help me welcome her to the Apollo community!