Microsoft's Fowler Links Principal Leap to .NET Core Delegation

Ryan Peterman

The perfectionism and individual coding control that propel engineers to senior rank actively sabotage their ability to reach principal scope.

AI-assisted summary of Microsoft Distinguished Eng: His Principal Engineer Promotion Story | David Fowler — original source. Check the original for full context.

Source published: 2026-10-21

Key ideas

David Fowler was selected alongside one principal engineer to lead the architecture of .NET Core while still a senior engineer, directing roughly 30 engineers to rebuild the runtime, package manager, and base libraries from scratch. (0:00)
Reviewing every single pull request across the new project pushed Fowler into severe exhaustion within 12 months, forcing him to shift from micromanagement to architectural trust and delegation. (0:00)
The transition from senior to principal hinges on scaling impact through others rather than personal output, as Fowler notes that engineers 'aren't going to type harder and make a bigger impact.' (3:09)

Detailed notes

## Background Published on YouTube by Ryan Peterman on October 21, 2026, this video excerpt features Microsoft Distinguished Engineer David Fowler discussing his career journey across 11 promotions over 17 years at Microsoft. The discussion centers on the pivotal lessons Fowler learned during his promotion from Senior to Principal Engineer while helping architect .NET Core, as well as general advice for navigating software engineering growth at large companies.

## TL;DR After receiving discouraging feedback that his career trajectory would stall after making senior engineer, David Fowler was chosen to co-architect the ambitious .NET Core reboot across a team of thirty engineers. He quickly faced severe burnout from trying to micromanage every design detail and code review, forcing him to recognize that individual coding velocity does not scale to larger organizations. By shifting his focus from personal perfectionism to delegating tasks, mentoring junior colleagues, and triaging urgency, Fowler amplified his team's output rather than acting as a bottleneck. This operational and psychological transition enabled the foundation of .NET Core and earned him his promotion to Principal Engineer.

## Atmosphere & style The conversation has a candid, reflective, and grounded tone, free of corporate buzzwords or self-congratulation. Fowler shares his missteps with disarming humility, recalling the exhaustion of trying to out-code his team before realizing that sheer typing speed cannot produce organizational impact. Listening to the exchange feels like sitting in on an intimate mentoring session between engineering peers, charting an emotional arc from overstretched anxiety to mature leadership clarity.

## Bulletin - [00:00](https://www.youtube.com/watch?v=a2G58axJZOc&t=0s) David Fowler was selected alongside one principal engineer to lead the architecture of .NET Core while still a senior engineer, directing roughly 30 engineers to rebuild the runtime, package manager, and base libraries from scratch. - [00:00](https://www.youtube.com/watch?v=a2G58axJZOc&t=0s) Reviewing every single pull request across the new project pushed Fowler into severe exhaustion within 12 months, forcing him to shift from micromanagement to architectural trust and delegation. - [03:09](https://www.youtube.com/watch?v=a2G58axJZOc&t=189s) The transition from senior to principal hinges on scaling impact through others rather than personal output, as Fowler notes that engineers 'aren't going to type harder and make a bigger impact.'

## Key takeaways - [00:00](https://www.youtube.com/watch?v=a2G58axJZOc&t=0s) Upon reaching senior engineer, Fowler was cautioned by his manager to expect promotions to stall, an assumption he defied by focusing on high-impact projects. - [00:00](https://www.youtube.com/watch?v=a2G58axJZOc&t=0s) Fowler built his early reputation working on SignalR and co-creating Kudu, an early Azure engine inspired by Heroku's git-push deployment workflow. - [00:00](https://www.youtube.com/watch?v=a2G58axJZOc&t=0s) Microsoft leadership tapped Fowler to architect .NET Core despite his senior title, giving the team wide creative freedom to rebuild the ecosystem from scratch. - [00:00](https://www.youtube.com/watch?v=a2G58axJZOc&t=0s) Attempting to personally review every pull request for a 30-person team created a bottleneck and led to severe burnout during his first year on .NET Core. - [00:00](https://www.youtube.com/watch?v=a2G58axJZOc&t=0s) Fowler's promotion to principal engineer coincided with the birth of his first child and the successful first year of the .NET Core initiative. - [03:09](https://www.youtube.com/watch?v=a2G58axJZOc&t=189s) Senior engineers frequently fall into the trap of self-reliance because implementing features directly often feels faster than teaching junior engineers. - [03:09](https://www.youtube.com/watch?v=a2G58axJZOc&t=189s) Delegating tasks to junior engineers should be treated as an investment in team capacity that yields significantly higher long-term compounding output. - [03:09](https://www.youtube.com/watch?v=a2G58axJZOc&t=189s) To sustainably manage large teams, senior technical leaders must stop treating every code imperfection or missing test as an immediate emergency. - [03:09](https://www.youtube.com/watch?v=a2G58axJZOc&t=189s) The individual control, perfectionism, and brute-force execution that propel engineers to senior levels actively hinder their progression to principal and distinguished tiers. - [03:09](https://www.youtube.com/watch?v=a2G58axJZOc&t=189s) Operating at principal or distinguished scale requires influencing through 1:1 mentorship and solid foundations rather than trying to out-code the organization.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=a2G58axJZOc&t=0s) The Road to Principal and the Birth of .NET Core

When David Fowler was promoted to senior engineer at Microsoft, his manager at the time gave him an unexpected buzzkill rather than pure congratulations. Sitting down in that meeting, thrilled about the milestone, Fowler was told plainly that his promotions would slow down from that point forward and that he should not expect rapid progression anymore. Fowler did not take the discouraging advice to heart, but he recognized that jumping to principal was indeed a massive leap. During that era, Fowler had been working on SignalR and had collaborated with an architect to develop Kudu—an early Azure engine inspired by Heroku and AppHarbor that enabled developers to deploy applications instantly via git push. While deep in that work, Fowler's director pulled him aside to reassign him based on his proven track record, asking him to step onto an unannounced project despite Fowler's initial desire to finish what he was already building.

That new initiative became.NET Core, an ambitious, cross-platform, modern reboot of the entire.NET ecosystem. The sheer scale was both thrilling and intimidating: Fowler, still a senior engineer, was chosen alongside one principal engineer to serve as the project's lead architects, overseeing roughly thirty engineers with total creative freedom to build what they felt was right. Lacking previous experience directing a team of that size, Fowler initially fell into the trap of trying to personally code review every single pull request across the codebase. That bottleneck led to severe exhaustion within twelve months. He realized he had to learn how to triage urgency, establish architectural trust, and let go of micro-oversight. That foundational first year of designing and building.NET Core culminated in two major life milestones: the birth of his first child and his promotion to principal engineer.

```mermaid flowchart TD accTitle: Evolution to Principal Engineer accDescr: Progression from SignalR and Kudu to architecting.NET Core and scaling engineering practices.

subgraph EarlyWork["Early Foundation"] A["SignalR Development"] B["Kudu (Azure Git Deployments)"] end

subgraph Transition[".NET Core Inception"] C["Director Pulls Fowler to New Project"] D["Senior + Principal tapped as Lead Architects"] end

subgraph BottleneckBreakthrough["Scaling Throughput"] E["Initial Burnout: Reviewing Every PR"] F["Triage Urgency & Delegate"] G["Promotion to Principal Engineer"] end

EarlyWork --> C C --> D D --> E E --> F F --> G ```

- Fowler was warned by his manager upon making senior: “I sat down and I got this I got I got the promotion. I was really happy. he kind of gave me this downer like don't expect more promotions like from here because you know I was like what does that mean?” - Heroku popularized git-push deployments, which was mirrored in the.NET ecosystem by AppHarbor and subsequently built for Azure as Kudu. - Fowler and one principal engineer served as architects for roughly 30 engineers on.NET Core. - The promotion to principal arrived the same year Fowler welcomed his first child and navigated the first year of architecting.NET Core.

---

[03:09](https://www.youtube.com/watch?v=a2G58axJZOc&t=189s) Shifting from Individual Execution to Team Amplification

Managing the architectural load of thirty engineers forced Fowler to confront how he delegated work. He had caught an early glimpse of delegation on the smaller SignalR team, which consisted of seven or eight engineers, product managers, and technicians, including two new college hires. Fowler’s initial senior engineer instinct had always been self-reliance—assuming that because he could implement features faster himself, handing tasks to junior engineers was inefficient. Over time, he realized that giving work to others is an investment in their growth; while junior developers take longer in the short term, leveling them up amplifies the entire team’s long-term output. This mindset shift—measuring success by team outcomes rather than personal lines of code—became the foundation that allowed him to survive and steer.NET Core, where the team was rebuilding the runtime, package manager, and base libraries from scratch.

To prevent recurring burnout on.NET Core, Fowler stopped treating every change as an emergency. He resisted the urge to block pull requests over imperfect interfaces or incomplete test suites, forcing himself to give engineers room to make mistakes. He observes that the exact traits that push an engineer from mid-level to senior—such as perfectionism, extreme control over code execution, and brute-force individual problem-solving—actively sabotage an engineer's ability to operate at staff, principal, or distinguished scope. Inspiring hundreds or thousands of engineers requires using 1:1 mentorship, setting solid foundations, and leading by example rather than attempting to out-code the organization.

- On the psychological shift required to become a principal engineer, Fowler explains: “I think the leap from senior to principal feels like being able to to do more through others than yourself and it's it's where I think a lot of people end up plateauing because software engineers are very like you know we want to we want to we like coding we want to be alone we want to build the things ourselves software engineering is a collaborative event it's like we want to figure out how to get the customer feedback figure out what to build figure out how to build it the best way and I think that change in in my brain prepared me for like on core because it was such such bigger scale like how do you even begin to manage that many people that that many facets we we rebuilt everything from scratch like we literally rebuilt the package manager the runtime the libraries like everything from the get-go and it was overwhelming at first”. - On the limits of personal output at scale, Fowler stresses: “Being a control freak, being someone who like is amazing at their job, getting stuff done in a very specific way doesn't really help you when you want to appeal to a thousand engineers.” - As Fowler summarizes the scaling trap: “You aren't going to type harder and make a bigger impact.”

## Notable quotes > [03:09](https://www.youtube.com/watch?v=a2G58axJZOc&t=189s) You aren't going to type harder and make a bigger impact. — David Fowler

> [03:09](https://www.youtube.com/watch?v=a2G58axJZOc&t=189s) Being a control freak, being someone who like is amazing at their job, getting stuff done in a very specific way doesn't really help you when you want to appeal to a thousand engineers. — David Fowler

## Mentioned David Fowler, Ryan Peterman, Microsoft, .NET, .NET Core, SignalR, Kudu, Azure, Heroku, AppHarbor, Git

## Video description David Fowler went from an intern to a Distinguished Engineer at Microsoft. That’s 11 different promotions all at the same company. I asked him about everything he learned by going through that process. We cover his full career story and go over general advice he has for software engineers. I was also curious to ask him about Microsoft culture and big company tips he has since he's been there for over 17 years.

Watch the full conversation: https://www.youtube.com/watch?v=d8tRM8RJ52M

[Source](https://www.youtube.com/watch?v=a2G58axJZOc)

中文简报

微软Fowler：晋升首席工程师的关键在于.NET Core项目的充分放权帮助工程师晋升至高级职级的完美主义与对代码的个人掌控欲，反而会阻碍他们拓展至首席工程师所需的影响力范围。在收到关于自己晋升高级工程师后职业发展或将停滞的灰心反馈后，David Fowler被选拔与他人共同主导雄心勃勃的.NET Core重构架构设计，统领一支约30人的工程师团队。起初，他因试图对每个设计细节和代码审查进行微观管理而迅速陷入严重职业倦怠，这迫使他意识到个人的编码速度根本无法随团队规模扩大而扩展。通过将重心从追求个人完美主义转变为下放任务、指导初级同事以及按紧急程度统筹优先级，Fowler放大了团队的产出，不再充当项目的瓶颈。这一工作方式与心理层面的转变不仅为.NET Core奠定了基础，也帮助他赢得了首席工程师的晋升。在仍担任高级工程师期间，David Fowler便被选中与一位首席工程师共同主导.NET Core的架构设计，指导约30名工程师从零开始重建运行时、包管理器及基础库。 (0:00) 在新项目中逐一审查每一个代码拉取请求（PR），导致Fowler在12个月内陷入严重精疲力竭，迫使他从微观管理转向架构层面的信任与任务放权。 (0:00) 从高级工程师到首席工程师的跃迁，关键在于通过赋能他人来放大影响力，而非单纯依赖个人产出；正如Fowler所言，工程师“不可能靠更快地敲代码来产生更大的影响力”。 (3:09)

Reading summary

Microsoft engineer David Fowler argues that advancing from senior to principal engineer requires abandoning the habits of direct control and self-reliance that drive early career success in favor of delegation and team amplification. Reflecting on architecting the rebuild of .NET Core, he highlights how personal execution hits an unsustainable ceiling without an intentional shift toward trusting and developing others. Architecting .NET Core Under Oversight Bottlenecks (0:00) After contributing to SignalR and Kudu—an Azure deployment engine inspired by Heroku and AppHarbor—Fowler was reassigned by his director to co-lead the architectural reboot of .NET Core. Despite recently receiving a warning from his manager that promotions would slow down after making senior engineer, Fowler was chosen alongside one principal engineer to lead roughly thirty developers with total creative freedom to rebuild the runtime, package manager, and core libraries from scratch. Without experience directing a team of that size, Fowler initially tried to review every pull request across the codebase personally. This insistence on total oversight created severe operational bottlenecks and led to severe exhaustion within twelve months. To manage the scope, Fowler had to triage urgency, build architectural trust, and abandon micro-oversight, a transition that coincided with the birth of his first child and his promotion to principal engineer. Shifting from Personal Output to Team Amplification (3:09) Fowler observes that senior engineers often default to self-reliance under the assumption that handing tasks to junior engineers is inefficient because they could write the code faster themselves. While working with junior engineers on SignalR, he realized that hoarding work for short-term speed stifles collective capacity, whereas delegating tasks serves as an investment that multiplies the entire team's long-term output. To sustain .NET Core's scale, Fowler redefined success around team outcomes rather than personal lines of code. He stopped treating every codebase change as an emergency, actively resisting the urge to block pull requests over imperfect interfaces or test suites to give engineers necessary room to make mistakes and build competence. Unlearning Perfectionism to Operate at Scale (3:09) According to Fowler, the specific traits that push engineers from mid-level to senior—including perfectionism, strict control over execution, and brute-force individual problem-solving—actively undermine effectiveness at staff, principal, or distinguished scopes. While individual output suffices on smaller teams, it fails when attempting to direct hundreds or thousands of developers. Fowler stresses that an engineer cannot simply 'type harder' to achieve larger organizational impact. Instead of attempting to out-code the organization, operating at higher technical tiers requires providing one-on-one mentorship, laying solid architectural foundations, and leading by example. Fowler concludes that engineering plateaus frequently occur when engineers view their craft as solitary building rather than a collaborative process centered on customer feedback and team enablement. The source details Fowler's personal transition during the .NET Core reboot, leaving open how these leadership transitions vary across teams with differing levels of creative autonomy.

精炼阅读摘要

微软杰出工程师 David Fowler 回顾了其从高级工程师晋升至首席工程师的经历，指出实现这一跃升的核心在于破除单兵作战和微观控制的惯性，转向通过分权授权、指导他人以及建立团队信任来放大整体工程影响力。执掌大型项目与代码审查瓶颈 (0:00) 在晋升为高级工程师后，Fowler 虽被当时的主管告诫未来的升迁节奏将会放缓，但随后凭借在 SignalR 以及 Azure 部署引擎 Kudu 上的突出表现，被总监抽调至当时尚未公开的重点项目 .NET Core。彼时 Fowler 仍是高级工程师，却与另一位首席工程师共同担纲总架构师，获得了高度的自主设计权，负责指导约 30 名工程师从底层重构运行时、包管理器及基础库。面对前所未有的协作规模，Fowler 初期试图对代码库中的每一个 Pull Request 进行人工代码审查，导致自己在 12 个月内陷入极其严重的精疲力竭。这一瓶颈迫使他意识到必须改变微观把控的习惯，学会区分事务的轻重缓急，并在团队内部建立起架构信任与分级处理机制。从个人单打独斗转向团队赋能 (3:09) Fowler 指出，推动工程师从中级迈向高级的核心特质——例如极度的代码控制欲、完美主义以及依靠个人蛮力解决问题的能力，在向资深乃至首席工程级别跨越时往往会产生反作用。工程师天然倾向于独立编码并认为自己亲自实现功能更快，但 Fowler 从 SignalR 带领校招生的经验中意识到，将工作分派给初级工程师虽然在短期内耗时较长，实质上却是一项提升长期产出的必要投资。在 .NET Core 期间，Fowler 调整了工作重心，不再将每个代码变动视作紧急事件，也不再因接口不完美或测试未完全覆盖而机械性地阻拦合并，而是给予工程师犯错与成长的空间。他强调，当面对数百乃至上千名工程师的组织规模时，单纯依靠个人增加敲击键盘的强度无法扩大业务影响力；工程师必须将成功的度量标准从个人产出转向团队成果，依靠一对一导师机制、奠定坚实的技术基础和以身作则来驱动团队。 Fowler 的经验表明，晋升首席工程师的关键分水岭在于将工程产出模式从“依赖个人交付”彻底重构为“通过他人达成成果”。不过，这种转型对习惯掌控细节的资深工程师而言意味着巨大的心智挑战，如何在放权容错与确保底层架构质量之间维持平衡，仍是团队规模化扩张中需要持续应对的核心课题。

Source quotes

[3:09] David Fowler: You aren't going to type harder and make a bigger impact. [3:09] David Fowler: Being a control freak, being someone who like is amazing at their job, getting stuff done in a very specific way doesn't really help you when you want to appeal to a thousand engineers.

Original transcript

[0:00] Going to your latest stage promos, you [0:03] got the promotion to principal, you got [0:05] the promotion to distinguished at [0:06] Microsoft. I'm curious, what is the [0:09] thing that led to the promotion to [0:11] principal? [0:12] >> Principal was interesting. So, I I had I [0:15] had a one boss. I won't say his name. I [0:17] had a one boss who who told me when I [0:20] got to senior that my promos would slow [0:21] down. And I remember that meeting where [0:24] I sat down and I got this I got I got [0:25] the promotion. I was really happy. he [0:27] kind of gave me this downer like don't [0:28] expect more promotions like from here [0:30] because you know I was like what does [0:32] that mean? Um and I never really took it [0:35] took it to heart but the the jump to [0:37] principle is a big jump. I had been [0:40] working on signal R at the time. I built [0:42] this um if you ever use Heroku, Heroku [0:45] like pioneered git pushing and deploying [0:48] your app like instantly, right? We had [0:51] built there was a there was a tech [0:54] called app harbor for fornet. This this [0:56] company was doing the same thing for [0:58] .NET and we built a similar thing for [1:01] Azure. This is like super early in Azure [1:03] time frame, right? Like we had built [1:06] this like brand new it's actually still [1:07] there. It's called Kudu. Um, and I had I [1:11] had been working with the same architect [1:12] and I had built it with him. Um, and [1:15] then at some point in that time frame, I [1:18] got pulled off of that and I this is one [1:23] of the places where like your track [1:26] record helps just get set up for the [1:28] future opportunities. So I had my [1:32] director tell me, "Hey, we have this new [1:34] thing spinning up and we need you to go [1:36] work on it." And obviously, you know, [1:39] you're working on something else. You're [1:40] like, man, I want to finish what I'm [1:42] working on, but then this thing happens. [1:44] Okay, I'll I'll help you with this [1:45] thing. And that ended up being the [1:48] beginning of the new .NET um net core [1:51] that we write. It was crossplatform and [1:53] modern and new. And it was a big [1:56] opportunity like so big. It was scary at [1:58] first, like, oh my gosh. Like, what do [2:00] you mean you're the architect? Like, and [2:02] I was senior. I was I was it was me. It [2:04] was me and another principal engineer [2:07] that got chosen to be the architects of [2:08] this project and I hadn't had an an [2:11] experience working at that scale before [2:13] because I think we had like 30 engineers [2:15] that were working on this this project. [2:18] Um, we had free reign to kind of build [2:20] whatever we thought was right and that [2:22] was like both amazing and terrifying. [2:25] Um, and I think through that project I [2:28] learned a ton of things like knowing how [2:31] to I I don't want to say we weren't [2:32] managers but learning how to manage a [2:34] project and architecture and scale and [2:37] like initially I was trying to code [2:39] review every single change. You can [2:41] imagine that burnt me out [laughter] [2:44] within within a year I was like okay I [2:45] can't I can't we can't do this anymore. [2:47] had to figure out how to trust people [2:50] and scale and figure out what's [2:52] important, what's not what's not urgent [2:54] versus urgent etc. Um that year I got [2:58] promoted actually I had my first first [3:00] kid and I got promoted that to principal [3:02] that same year I did this um the first [3:04] year of net core um design and and [3:07] building it. [3:09] >> You you mentioned that that the team [3:11] grew so much that you had to scale [3:13] yourself out of necessity. What are the [3:16] things that you did that allowed you to [3:19] be like architect for so many engineers [3:22] without burning yourself out? [3:24] >> So I learned I learned some of this [3:25] during Sigmar. The the the the smaller [3:28] version with Sigma only had like seven [3:30] or eight people overall, right? [3:31] Engineers, text, product managers. And [3:34] we had two new hires. And I had never [3:38] had the experience of delegating in a [3:42] way where I thought it was like if I [3:44] gave you this work, it's to grow you, [3:47] right? I never thought that way before. [3:48] I was always like, I'm a senior [3:50] engineer. I can get this done. I I can [3:52] do it faster than you. Like why would I [3:54] give you this thing when I can do it [3:55] faster? Um, we had really smart [3:58] engineers that we hired from college and [4:02] it took me a while to kind of get past [4:05] it's going to take them longer at first, [4:06] but once they understand all the stuff, [4:09] then we can amplify the impact. And I [4:12] think once I saw that, it flipped my [4:14] brain. So I had I had something from [4:16] from the signal frame from that was like [4:18] okay if you can invest in people and [4:20] kind of get them on the same page as you [4:22] if you are on the same wavelength if you [4:24] can delegate more um then you can kind [4:28] of get get more done as a team right you [4:30] be you begin to be you begin to think [4:32] about outcomes and less about like the [4:34] work you're doing individually I think [4:36] the leap from senior to principal feels [4:39] like being able to to do more through [4:41] others than yourself and it's it's where [4:45] I think a lot of people end up [4:47] plateauing because software engineers [4:50] are very like you know we want to we [4:52] want to we like coding we want to be [4:54] alone we want to build the things [4:55] ourselves software engineering is a [4:57] collaborative event it's like we want to [5:00] figure out how to get the customer [5:01] feedback figure out what to build figure [5:03] out how to build it the best way and I [5:05] think that change in in my brain [5:07] prepared me for like on core because it [5:11] was such such bigger scale like how do [5:14] you even begin to manage that many [5:16] people that that many facets we we [5:18] rebuilt everything from scratch like we [5:20] literally rebuilt the package manager [5:23] the runtime the libraries like [5:24] everything from the get-go and it was [5:26] overwhelming at first um what I think [5:29] helped a lot was not treating everything [5:32] as equally urgent like that was a big [5:35] deal like if this change over here went [5:37] in and it wasn't perfect. I wouldn't be [5:39] like we can't merge this. It needs to [5:42] have this interface, these tests. Um, [5:44] learning how to set foundations for [5:46] others and to trust others and like [5:49] letting people fail was a really hard [5:51] thing for me at first. Okay, I could I [5:53] could avoid the failure [laughter] [5:57] and and it turns out that the team like [6:00] I think a lot of the things that get you [6:02] to senior and maybe principal hurt you [6:06] growing even further, right? Being a [6:08] control freak, being someone who like is [6:11] amazing at their job, getting stuff done [6:14] in a very specific way doesn't really [6:16] help you when you want to appeal to a [6:17] thousand engineers. You have to kind of [6:19] figure out how to inspire others to do [6:21] the same as you through different means [6:23] like one-on ones or or you being an [6:26] example or like more more different [6:28] techniques, but it's difficult to just [6:31] be to type. You aren't going to type [6:33] harder and make a bigger impact. So, [6:35] it's like I shifted my brain to be [6:38] outcome focused. Was a big big change. [6:41] If you