What are engineers getting paid for now - CourtneyR.dev's 2nd Brain

What are engineers getting paid for now? ![rw-book-cover](https://readwise-assets.s3.amazonaws.com/static/images/article4.6bc1851654a0.png) 🔗 **Source:** [What are engineers getting paid for now?](https://www.youtube.com/watch?v=4FbAlAxBMwM) > [!note]+ Document Notes > tags: [ai-automation, engineering-career, product-engineering, developer-productivity, engineering-management, technical-leadership] > author: Jennifer Riggins > source: Lead Dev > reference: https://www.youtube.com/watch?v=4FbAlAxBMwM > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: What are engineers getting paid for now? >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - **What happened**: Lead Dev panel discussing how AI is reshaping engineering roles, moving focus from code production to business outcomes and domain expertise. - **Why it matters**: Engineers risk being displaced if they don't evolve beyond coding to become co-owners of business problems and customer outcomes. - **Key stakeholders**: Software engineers (junior and senior), engineering managers, CTOs, product managers, and HR departments evaluating engineering performance. - **Risks and tradeoffs**: Risk of losing craft/judgment by over-relying on AI; tradeoff between speed and learning; junior engineers may struggle to find entry points. - **Bottom line**: Engineering value creation has always been beyond just writing code—AI is simply forcing the removal of barriers that allowed engineers to hide behind "just tell me what to code." ## 📖 Main Content The panel argues that engineering has always been about problem-solving, critical thinking, and business outcome delivery—not just code production. AI is accelerating this shift by removing the friction that previously allowed engineers to operate in silos. ### Core Value Shifts **From Order-Taking to Co-Ownership**: Engineers must evolve from "wrench turners" receiving requirements to co-owners of business problems. The traditional handoff model ("throw it over the wall") is becoming obsolete. **From Lines of Code to Business Impact**: Success metrics are shifting from technical outputs (lines written, features shipped) to business outcomes (revenue, customer adoption, system performance). Engineers need to understand the full problem context to build scalable solutions. **From Specialists to Product-Minded Generalists**: While deep expertise remains valuable, engineers increasingly need cross-functional skills and business domain knowledge. The rise of "product engineers" reflects this trend. ### AI's Role as Amplifier AI tools raise the floor for junior engineers while increasing the ceiling for judgment-based work. They enable faster prototyping and experimentation but require strong fundamentals and clear guidelines to be effective. The panelists emphasize that AI works best when organizations have solid engineering practices already in place—it's an amplifier, not a replacement for good engineering culture. ## 🗒️ Notes #### ⏱️ [00:03:12](https://www.youtube.com/watch?v=4FbAlAxBMwM&t=192) Problem Definition Over Coding - Jeremy emphasizes that software engineering is a "big pipeline" starting with figuring out what problem to solve - Many teams are "slamming slop" at problems not worth solving - Key tip: Adopt product and business mindset first, not crafting code #### ⏱️ [00:06:45](https://www.youtube.com/watch?v=4FbAlAxBMwM&t=405) Growth Beyond Speed - Shalini: Engineers don't grow because they code faster, but because they can translate problems and make technical tradeoffs - Focus on outcomes: "What has changed because you built it" vs. "what you have built" - Building without friction doesn't equal value creation #### ⏱️ [00:09:30](https://www.youtube.com/watch?v=4FbAlAxBMwM&t=570) The Power of Saying No - Phil: Engineers' biggest strength is ability to say no to unnecessary features/complexity - Disruption mainly affects "order-taking" programming roles, not engineering roles requiring domain knowledge - Most engineers are happy to move beyond the "boring bits" of pure implementation #### ⏱️ [00:15:20](https://www.youtube.com/watch?v=4FbAlAxBMwM&t=920) Junior Engineer Adaptation - Change expectations for onboarding: focus on curiosity and adaptability - AI enables asking agents to explain code and decisions, not just write code - Key signal: curiosity to learn across diverse technical areas - Floor is raised but learning acceleration is required #### ⏱️ [00:22:45](https://www.youtube.com/watch?v=4FbAlAxBMwM&t=1365) Avoiding the Dopamine Trap - Jeremy warns against getting caught in AI feedback loops without learning - Need to pause, reflect, and absorb rather than rush through agent responses - Managers must create space for learning, not just increased throughput #### ⏱️ [00:28:15](https://www.youtube.com/watch?v=4FbAlAxBMwM&t=1695) Promotion Criteria Evolution - Shalini: Promotion tied to operating at next level of outcome ownership and domain expertise - Technical judgment becomes more important than pure execution - Need secondary metrics: hypothesis testing, experimentation rate #### ⏱️ [00:35:40](https://www.youtube.com/watch?v=4FbAlAxBMwM&t=2140) Making Others Better - Phil: Key evaluation criteria is "do you make other people better around you?" - Value in negative experimental results if they become institutional knowledge - Glue work becomes more visible and valuable ## 📚 References - [Lead Dev Slack Community](https://leaddev.com/community) - [Story Block Engineering Team](https://www.storyblok.com) - [Palantir SDLC Global Practice](https://www.palantir.com) - [LinkedIn Engineering](https://engineering.linkedin.com) ## 🗣️ Paraphrase The fundamental thesis is that engineering has always been about problem-solving and business value creation, not just coding. AI is simply removing the friction that allowed engineers to hide behind implementation-only roles. The most valuable engineers understand business context, can translate between technical and business domains, and focus on outcomes rather than outputs. For career growth, engineers need to develop domain expertise alongside technical skills, become comfortable with experimentation and hypothesis testing, and learn to articulate their impact in business terms. The role is expanding to include more product thinking while deep technical expertise remains crucial for complex problem-solving. The industry is experiencing a shift similar to cloud adoption—new skills become table stakes while creating opportunities for specialists to enable broader teams through platform thinking and clear guidelines. ## 📰 Newsletter 🚀 **The Great Engineering Evolution is Here!** Fellow WordPressers, the latest Lead Dev panel dropped some serious truth bombs about where our industry is heading. Spoiler: it's not about AI replacing us—it's about AI forcing us to level up in ways we should have been doing all along! **The TL;DR**: Stop hiding behind "just tell me what to code" and start becoming the co-owner of business problems you were always meant to be. Your value isn't in typing speed; it's in judgment, domain knowledge, and making everyone around you better. **For WordPress Developers**: This hits home hard. Whether you're building custom themes, optimizing Core Performance, or architecting multisite networks, your expertise in the WordPress ecosystem becomes even more valuable when you understand the business problems you're solving. That WooCommerce integration isn't just code—it's someone's livelihood. **Key Takeaways for Us**: - Product-minded engineers are the future (hello, full-stack WordPress developers!) - Your platform expertise enables others (think: creating starter themes and development patterns) - Experimentation velocity matters more than being right every time **Worth Bookmarking**: The discussion on junior engineer onboarding is gold for anyone mentoring contributors to WordPress Core or leading team growth at agencies. Level up your game—the WordPress community needs engineers who think beyond the code! 🎯 ## ✅ Action Items #### DevRel - **Developer advocacy**: Create content showing WordPress engineers as product-minded problem-solvers, not just code producers - **Education**: Develop workshops on business context for technical decisions in WordPress development - **Developer experience**: Build tools that enable non-experts to contribute safely to WordPress projects - **Community management**: Facilitate cross-functional discussions between developers, designers, and business stakeholders #### OSPO - **Strategic Alignment**: Align engineering KPIs with business outcomes rather than code metrics - **Developer Support**: Provide training on domain knowledge acquisition and business context understanding - **Community Engagement**: Support engineers in developing cross-functional collaboration skills #### WordPress - **Core**: Emphasize outcome-based contribution metrics over lines of code or tickets closed - **Core Performance**: Focus on business impact of performance improvements, not just technical metrics - **Core Program Team**: Create cross-team rituals that build business domain knowledge - **Training**: Develop curriculum that teaches business context alongside technical skills - **Community**: Encourage product-minded thinking in WordPress meetups and WordCamps #### The WPCC - **Programs**: Fund initiatives that develop business acumen in WordPress engineers - **Projects**: Support tools and processes that enable outcome-focused engineering ## 🧪 Hypotheses 1. **Engineers who develop domain expertise alongside AI proficiency will see faster career advancement** than those who focus solely on AI tool mastery 2. **Organizations measuring engineering success by business outcomes rather than code metrics will see higher productivity** and engineer satisfaction 3. **Junior engineers onboarded with AI-assisted learning and strong mentorship will achieve senior-level domain knowledge faster** than previous cohorts 4. **Engineering teams that embrace experimentation and hypothesis-driven development will deliver more business value** despite some failed experiments 5. **Companies that restructure promotion criteria around outcome ownership will retain talent better** during AI-driven industry changes ### 📊 Methodology - **Longitudinal career tracking**: Follow engineers over 2-3 years comparing domain expertise development vs. pure technical skill advancement - **A/B testing**: Compare teams measured on business outcomes vs. traditional engineering metrics - **Cohort studies**: Track junior engineer progression with different onboarding approaches - **Business impact analysis**: Measure correlation between experimentation rates and business value delivery - **Retention studies**: Compare turnover rates in organizations with evolved vs. traditional promotion criteria ### ❓ Questions - How do you measure "domain expertise" objectively for promotion decisions? - What specific training programs help engineers develop product thinking? - How do you balance AI-assisted speed with necessary learning and reflection time? - What role should customer interaction play in engineering career development? - How do you prevent AI tools from creating a false sense of productivity? ### 🔮 Future Research - Impact of AI pair programming on long-term skill development - Effectiveness of cross-functional embedding for engineer growth - Correlation between business context understanding and technical decision quality - Role of experimentation culture in engineering team performance - Evolution of engineering manager skills in outcome-focused organizations ### 💡 Implications **Practice**: Engineering teams need new performance frameworks, mentorship approaches, and learning cultures that prioritize judgment and business understanding over code production velocity. **Policy**: HR departments must restructure job descriptions, promotion criteria, and compensation models to reflect the evolving nature of engineering value creation. **Education**: Computer science curricula should include more business context, customer interaction, and product thinking alongside technical skills. **Funding**: Investment in engineering productivity should focus on outcome measurement tools and domain expertise development rather than just coding acceleration. ### 🧠 Learning Styles Assessment **Reading level**: Approximately 12th grade (Flesch-Kincaid). Complex technical and business concepts requiring professional experience context. #### 👀 Visual learners - **Present**: Panelist name overlays, speaker identification - **Improve**: Career progression diagrams, AI tool workflow charts, business outcome visualization frameworks #### 🔊 Aural learners - **Present**: Full audio discussion with multiple expert perspectives - **Improve**: Chapter markers for key topics, audio summary of main points #### 🗣️ Verbal learners - **Present**: Rich analogies ("wrench turners," "fire hose"), clear definitions of evolving roles - **Improve**: Glossary of terms like "product engineer," "domain expertise," "outcome ownership" #### 🧩 Kinesthetic learners - **Present**: Discussion of hands-on experimentation and hypothesis testing - **Improve**: Practical exercises for developing business context, checklists for outcome-focused evaluation #### 🧠 Logical learners - **Present**: Clear cause-and-effect relationships between AI adoption and role evolution - **Improve**: Decision trees for career development, frameworks for measuring business impact #### 🧑‍🤝‍🧑 Social learners - **Present**: Panel discussion format, emphasis on cross-functional collaboration - **Improve**: Discussion guides for engineering teams, peer mentorship frameworks #### 🧘‍♀️ Solitary learners - **Present**: Individual reflection prompts about career direction - **Improve**: Self-assessment tools for domain expertise, personal development planning templates #### 🌿 Naturalistic learners - **Present**: Discussion of industry ecosystem evolution - **Improve**: Connections to broader technology lifecycle patterns, sustainability of career approaches ### 📊 Accessibility Assessment #### Screen reader semantics - **Present**: Video has speaker identification in transcript - **Improve**: Structured headings in transcript, speaker role descriptions #### Keyboard navigation - **Present**: Standard video player controls - **Improve**: Transcript navigation shortcuts, chapter jumping #### Contrast and readability - **Present**: High contrast video player interface - **Improve**: Transcript formatting with clear speaker delineation #### Media and captions - **Present**: Full transcript provided - **Improve**: Time-synced captions, downloadable transcript file ### 🌍 DEIB Assessment #### Cultural breadth - **Present**: Global perspective (French engineer in Berlin, various company contexts) - **Improve**: More diverse geographic representation, discussion of cultural differences in engineering roles #### Inclusive language - **Present**: Gender-neutral role descriptions, accessible explanations - **Improve**: Explicit discussion of barriers for underrepresented groups in promotion #### Neurodiversity support - **Present**: Multiple learning approaches discussed - **Improve**: Recognition of different cognitive styles in AI tool adoption #### Representation - **Present**: Mixed gender panel, varied company backgrounds - **Improve**: More diverse racial/ethnic representation, discussion of equity in AI access #### Psychological safety - **Present**: Discussion of learning culture and experimentation - **Improve**: Explicit acknowledgment of anxiety around AI displacement, support strategies ### ✅ Logical Validity #### Strong reasoning - **Deductive strength**: Clear logical progression from "AI automates coding" to "engineers must focus on higher-level value creation" - **Analogical reasoning**: Effective comparison to cloud adoption cycle and historical technology shifts - **Causal reasoning**: Well-established links between business understanding and engineering effectiveness #### Fallacies - **Potential survivorship bias**: Panel consists of successful senior engineers who may not fully represent struggles of displaced junior developers - **Appeal to authority**: Heavy reliance on panelist experience without broader data validation - **False dichotomy**: Some framing suggests engineers must choose between technical depth and business acumen #### Tone of voice - **Optimistic and solution-oriented**: "This is an exciting moment," "incredible win for junior engineers" - **Practical and experiential**: Frequent use of specific examples and actionable advice - **Collaborative**: Emphasis on "co-ownership" and team success over individual achievement ### 🛡️ DARVO Analysis No DARVO patterns detected. The discussion maintains a constructive tone focused on adaptation and growth rather than blame or victimization narratives around AI disruption. ## 🎯 Conclusion The engineering profession is experiencing a fundamental shift where AI amplifies the need for business acumen, domain expertise, and outcome-focused thinking that should have always been central to the role. Engineers who embrace this evolution—becoming co-owners of business problems rather than order-taking implementers—will find greater career satisfaction and advancement opportunities. **Practical next steps for readers:** 1. Start measuring your impact in business terms, not code metrics 2. Develop domain expertise in the industries/products you're building for 3. Practice explaining technical decisions in business context 4. Embrace experimentation and hypothesis-driven development 5. Use AI tools to accelerate learning and exploration, not replace critical thinking The future belongs to engineers who combine deep technical craft with business judgment and the ability to make their entire team more effective. ## 🔄 Refactor Appendix — What are engineers getting paid for now? ### 📚 Literature Atoms (H3) #### Engineers grow through problem translation not coding speed > [!quote] ID:rw_panel_01 > Even in the past when you hire a software engineer and they grow they're not growing because they are faster in coding they're growing because they can translate the problem that need to be solved and break it down and really do that problem solving and critical thinking **Context & use**: - Core argument from Shalini about what drives engineering career advancement - Challenges misconception that AI threatens core engineering value proposition **Tags**: #engineering-career #xref **Highlight**: [view highlight](https://www.youtube.com/watch?v=4FbAlAxBMwM&t=405)  #### AI removes barriers preventing engineers from hiding behind coding tasks > [!quote] ID:rw_panel_02 > We always needed to be co-owners and co-builders with our product managers with the business problem statement so that we could actually build the right solution. And it just became more and more transparent. **Context & use**: - Shalini explaining how AI forces visibility of what engineers should already be doing - Supports thesis that role evolution is correction, not disruption **Tags**: #ai-automation #xref **Highlight**: [view highlight](https://www.youtube.com/watch?v=4FbAlAxBMwM&t=920)  #### Engineering's biggest current strength is the ability to say no > [!quote] ID:rw_panel_03 > One of the biggest strengths for engineers right now is the ability to say no. Like no, we don't build this. No, this isn't how we should go about it. **Context & use**: - Phil's insight on value creation through constraint and judgment - Differentiates engineers from pure order-taking programmers **Tags**: #technical-leadership #xref **Highlight**: [view highlight](https://www.youtube.com/watch?v=4FbAlAxBMwM&t=570)  ### 🧠 Permanent Candidates (H4) #### Engineering value creation transcends code production **Claim**: The most valuable engineering work has always been problem-solving, critical thinking, and business outcome delivery rather than code production speed or volume. **Evidence pointer**: [[#Engineers grow through problem translation not coding speed]] **Scope & conditions**: Holds across all engineering domains and experience levels; becomes more visible as AI removes implementation friction; breaks down in pure order-taking roles without domain context. **Links**: - [[Technical leadership principles]] — because extends beyond individual contributor work - [[Product engineering approach]] — because applies-in cross-functional environments - [[AI amplification effects]] — because contrasts with replacement narratives  ### ✏️ Fleeting Queue - AI adoption success correlates with existing engineering fundamentals strength — investigate measurement approaches #fleeting #articleseed - Junior engineer onboarding evolution in AI era — interview hiring managers across tech companies #fleeting #xref - Glue work visibility and promotion equity — research gender/diversity impacts #fleeting #addendum ### → Things 3 (max 2 actions) - [ ] Research business outcome measurement frameworks for engineering teams — career development #things - [ ] Document current promotion criteria evolution in tech companies — writing project #things --- ## Full Transcript [00:12] Hello everybody and a huge thank you to [00:15] joining for joining us today for this [00:18] panel is a lead dev online panel [00:20] discussion created in partnership with [00:23] story block. The discussion will last [00:25] about 45 minutes after which both myself [00:28] and the panelists will head over to the [00:29] leaves slack to answer some of your [00:31] questions in hashtagpanel Q&A the [00:35] channel. For those of us joining live uh [00:38] I've dropped a link to that Slack in [00:41] your chat. It's just a really great [00:43] community of engineering leaders [00:46] supporting and learning from each other. [00:48] We do have time to answer questions live [00:51] and I think this is a hot button topic [00:53] for a lot of people trying to figure out [00:55] what's going on in the world we are [00:58] living in right now or in the industry [01:00] we're working in. So I do welcome [01:03] everyone joining us live. You do have [01:05] the privilege of answering of asking [01:08] questions in the Q&A feature on Zoom and [01:11] we'll get that to them as we see fit and [01:15] if we don't finish we'll continue in [01:16] that Slack. So I really hope we have a [01:20] great session. So a lot of sea suite [01:23] problematically never knew what [01:25] engineering was doing. It's kind of wild [01:28] because CTO is in the seauite but it's [01:32] even more dangerous now when a lot of [01:36] the senior people at organizations don't [01:38] know what's happening and they just [01:41] think AI can replace engineers. So at [01:45] Lead Dev and on this panel, I can assure [01:48] you that is not the vibe we're going [01:50] for. We're not trying to replace, we're [01:52] trying to help. So this conversation [01:54] hopefully brings a mix of advice for [01:56] software engineers to understand how [01:58] adapt your roles in this tumultuous [02:00] climate as well as for engineering [02:03] leadership to understand how to support [02:04] your teammates in that adapt adaptation. [02:08] So let's get started with some [02:09] introductions. My name is Jennifer [02:11] Riggins and I'm everyone's favorite [02:12] technology journalist and host. And [02:16] today I will be joined by Shalini, [02:19] Jeremy, and Phil who are ready to share [02:21] their experiences with you. So please [02:24] can you each introduce yourself? [02:27] Shallini if you will go first. [02:28] >> Yes, I'm Shalini Agarwal. I lead the [02:31] engineering at LinkedIn uh focused on [02:33] careers and jobs and members uh looking [02:36] for jobs as that's what we call seekers. [02:38] Uh along with that I am responsible for [02:41] AI powered search recommendations and [02:43] most recently agentic experience to help [02:46] our members navigate their careers. I've [02:48] spent like about two decades uh building [02:51] products and systems at scale and uh I'm [02:54] very excited about this moment right now [02:56] um because we are seeing one of the big [02:57] shifts our biggest shifts in software [02:59] engineering since I would say maybe [03:01] cloud or mobile and u even though AI can [03:05] help generate code review code even [03:07] orchestrate parts of our workflows but [03:09] that's not just what engineering is [03:12] about uh and that doesn't make [03:13] engineering less important I truly [03:15] believe the engineering value that we [03:17] create is much more beyond just writing [03:19] code and uh how we define uh our [03:23] performance and promotions. We need to [03:25] be changing that to certain extent but [03:27] uh that's where we why we are here to [03:29] talk about it. [03:31] >> Absolutely. Thank you so much for [03:33] joining us. Phil, please introduce [03:35] yourself. [03:36] >> Hi, I'm Phil Hoop. Uh I run the global [03:38] practice for SDLC here at Balantis. Uh I [03:41] have I have two careers. I first spent [03:44] 10 years in robotics and machine [03:45] learning and I got out right as soon as [03:47] I got hot. Um, the reason no one should [03:50] actually listen to me is I thought deep [03:51] learning was a fat. It would never go [03:53] anywhere. So, shows what I know. Um, [03:55] after that I spent 10 years in tech [03:57] building products, doing product [03:58] strategy, that kind of thing. So, I try [04:00] and help most of our customers nowadays [04:02] figure out how does the SDLC change in [04:05] their organization. Um, and most of it [04:09] is around fundamentals to be honest with [04:10] you. Everybody wants that future agentic [04:13] thing. I think all of it is an option [04:15] once you have the fundamentals down. I [04:17] think that's the theme that uh comes [04:19] into this a lot is like there's a craft [04:21] software development engineering and [04:23] productionalizing all of it. Um and you [04:26] can't just wave a magic wand and have AI [04:28] take care of all of it. You have to know [04:29] what you're asking and having it do. So [04:31] that's kind of the the angle that I come [04:33] from. You mean all those best practices [04:36] we've been talking about for 10 years [04:38] that so many companies follow [04:40] >> among other things? Yeah. [04:43] >> Jeremy, please. [04:45] >> Yes. So, I'm Jeremy. I'm a Frenchie [04:47] living in Berlin. Uh I come from the [04:49] story block side where I'm leading the [04:51] front end uh building the the product of [04:53] Story Block. Um I I actually started my [04:57] career more like on the back end side of [04:58] things. Uh then when I moved to Berlin, [05:00] I moved like more like to the front end. [05:03] did a lot of work on platform [05:04] engineering and how to to enable like [05:07] let's say large teams and most recently [05:10] like when I join story block like really [05:11] supporting like kind of like scaling the [05:14] product in terms of like how we [05:16] collaborate at scale and now how AI [05:19] comes into this mix of like actually I [05:21] really like what already Phil and [05:22] Shalini were saying where like this is [05:25] not something new but like AI especially [05:28] with like or like agentic workflows will [05:30] really work when you have like this set [05:32] of very strong like let's say already [05:34] practices as it's like an amplifier. So [05:36] I'm excited really to talk about that [05:38] and talk about what can how can people [05:41] make the difference with this technology [05:43] and what are let's say the the good tips [05:46] or mindset to adopt when it comes to it [05:48] um because it's it's also creating a lot [05:50] of strain on on engineers right now. [05:53] >> Absolutely. So let's start by just [05:56] talking about the title because [05:58] depending on where I emphasize the word [06:01] it could be very different like what are [06:02] engineers getting paid for now or what [06:05] are they getting paid for now or what [06:07] are they even getting paid for there's a [06:09] lot of interpretation so let's talk [06:11] about like how we're each going to [06:15] approach this conversation maybe to set [06:18] goals [06:20] Jeremy do you want to go first by [06:22] >> yeah I can start I think I think also [06:24] Charini me me me me me me me me me me me [06:24] me me me me me me me me me me me me me [06:25] me me me me me me me me me me me me me [06:25] me me me mentioned it already that [06:26] coding was probably only like only a [06:29] small fraction of the whole of the whole [06:31] thing. I think there's two angles that I [06:33] want to talk about. I think the first [06:34] one is really like engineering or like [06:37] actually putting let's say like let's [06:39] say software like let's say into the [06:42] hands of people or like into let's say [06:44] things that will make money or drive [06:45] your business forward was actually like [06:48] a big pipeline of things right it starts [06:50] from like fig out what is the problem [06:52] that we're trying to solve is the [06:53] problem even worth solving right now and [06:56] this is not something that like that [06:58] fundamentally change with AI right if [06:59] anything I see actually a lot of people [07:01] like like slamming a lot of things a lot [07:03] slop at something that's not even worth [07:05] solving and it's not worth building, [07:07] right? So trying to figure out what what [07:10] your customers want, what the [07:12] stakeholders that you're working on work [07:13] with want, it's a big big part of the [07:16] job. And this is where actually we can [07:18] already throw one of the first tip. I [07:20] think one of the biggest thing for for [07:22] people like to to really try to to adopt [07:25] let's say like agent encoding or like to [07:27] work in this new era of of software is [07:29] having this product and this business [07:31] mindset first, right? It's not about now [07:33] like crafting and building code. Of [07:35] course, I think we'll talk about how [07:36] important the fundamentals are, but it's [07:39] about remind like reminding yourself [07:41] that what matters is really building a [07:43] business outcome and and like the way to [07:46] do that is actually like to puzzle like [07:49] okay like what you already know about [07:50] the business where you want to go and [07:52] how you can use the the software for [07:54] that. So I think at least on this side [07:57] it's like actually like just to [07:59] demystify that's not really where the [08:01] most value for the top engineers was [08:04] already but not on coding it's about [08:06] translating this like okay we want to do [08:08] this we want to be there and how to do [08:10] that is actually like the cost of the [08:12] job but I think like maybe Charlie can [08:14] add to that for sure. [08:16] >> Sure. Yeah. No happy to. Um so even in [08:20] the past um when you hire a software [08:22] engineer and they grow they're not [08:24] growing because they are fast they are [08:26] faster in coding they're growing because [08:28] they can translate the problem that need [08:31] to be solved and break it down and uh [08:34] really do that problem solving and [08:36] critical thinking and use their judgment [08:38] to say what is it that we need to really [08:40] build uh and uh creating that clarity [08:44] among um if you have to solve a problem [08:46] what is it that we trying to really get [08:48] towards and writing code was yes big [08:51] part of the job but was not the only [08:54] job. It was understanding the problem [08:56] figuring out technical tradeoffs [08:58] designing those systems that can scale [09:01] and then ensuring quality and of course [09:03] trust and and then what Jeremy just said [09:06] it's like shipping the outcomes um [09:08] because at the end of the day there has [09:10] to be a business problem that you're [09:12] solving. So it's not so much about what [09:15] you have built or but it's more about [09:17] what has changed because you built it [09:19] and that was always true just that today [09:23] uh there's a lot of things that you're [09:24] building but at the end of the day what [09:27] outcomes those things that you build are [09:29] still the most important thing just [09:31] building for the sake of it is not [09:33] something that was valuable in the past [09:35] people were not able to do it because [09:37] there was a little bit of a friction to [09:39] get to coding getting done but now that [09:42] friction has gone but the value creation [09:44] is still the same, [09:46] >> but a lot of developers the most [09:49] quantifiable like they they've always [09:52] had a tangible result to their job. So I [09:55] think there's a sense of identity tied [09:57] to that code in a way because that's the [10:00] part they could prove they were doing [10:02] their job. So how does that change when [10:04] that is effectively not part of their [10:07] job anymore? [10:08] Well, that's the same thing as like [10:10] lines of code being a metric that you [10:12] want to measure your engineers by, [10:13] right? Like that's it's easy, it's [10:15] visible, but it's not actually a good [10:18] measure. And I think that [10:20] >> one of the key things to point out and [10:22] as as Jeremy and already pointed out is [10:24] like you're supposed to do a thing. [10:26] You're delivering value to customers whe [10:28] they're internal or external. And in [10:30] most cases, I think one of the biggest [10:31] strengths for engineers right now is the [10:33] ability to say no. Like no, we don't [10:35] build this. No, this isn't how we should [10:37] go about it. like we don't need 13,000 [10:39] extra lines of code in this module. We [10:42] don't need to build 15 different [10:43] features because they just distract from [10:45] the core value prop of the product, [10:47] right? Like this was traditionally what [10:48] product managers do and I think they [10:51] still have a big job here. But it's all [10:53] about making sure that end to end you're [10:55] seeing a lot of value there. But where [10:57] this disrupts it is like where an [10:59] engineering team or actually a team of [11:02] programmers was order taking from [11:04] someone else. Like I think that's where [11:05] you're seeing the disruption because [11:07] they didn't need to manage the context [11:09] and the customer problem. They didn't [11:10] have to be experts there. Like if if all [11:13] you were getting as a black box was a I [11:16] need you to build this CRUD app and this [11:18] is what the nonfunctional and functional [11:19] requirements of it are. That's [11:21] disappearing. But to be honest with you, [11:23] I think most people I talked to are [11:24] happy because that was the boring bit. [11:26] The inciting bit is matching domain [11:29] knowledge to the craft of engineering [11:31] and figuring out like how can I solve an [11:33] actual meaningful problem and it's just [11:35] it's harder to measure but it's orders [11:37] of magnitude more impactful [11:40] >> how do you measure then I know it's [11:41] harder but is impossible to measure [11:44] >> it's not impossible to measure but you [11:46] measure it through different things [11:48] right like you can measure it by revenue [11:50] by customer adoption like you can do [11:52] cohort-based analysis on features that [11:55] get adopted and seeing what happens [11:56] there like you have to think about it [11:58] less as the engineering part and more as [12:00] the whole business part. If you think [12:02] software is the revenue engine of your [12:04] company, then yeah, measure it as a [12:06] revenue engine. It may be a little [12:08] uncomfortable for some engineering [12:10] managers who've tried to stay away from [12:11] that. But I think it's where you have to [12:13] lean in like we drive millions of [12:15] dollars of revenue. Absolutely. Then get [12:18] paid accordingly, too. Right. [12:21] >> Yeah. I want to add to that. [12:23] >> Sorry, Jennifer. Um, [12:26] >> please. [12:27] >> Just adding to that. Um I think to [12:30] Jeremy's point, it was never fun to be [12:33] told um what to do. Um uh one of my uh [12:37] previous bosses used to call uh [12:39] engineers are not just wrench turners. [12:41] We are co-owners of the problem and I [12:44] think today that has become so much more [12:47] important. Um because you need to [12:50] understand the business problem to [12:51] really solve it the right way. when your [12:55] product managers tell you create this [12:57] table that should do this CRUD operation [12:59] you only do that much because that's [13:02] what you're told and uh now as engineers [13:05] with AI you don't need to be told that [13:08] anybody can do it if you already know [13:09] that maybe you are a product manager [13:12] that can also do engineering totally [13:14] okay with that like full stack um uh [13:17] engineers or uh full um cycle uh [13:20] engineers are totally okay to have but [13:23] if you're really building scalable [13:24] systems, you need to know what to do [13:26] beyond that table creation. What is the [13:28] problem you're really solving? Maybe you [13:31] need to create the table and put a cache [13:33] in front of it so that you can meet the [13:35] member SLA of a few milliseconds to uh [13:38] deliver that experience to the member. [13:41] So knowing the full problem statement [13:44] was always important but we were trapped [13:47] sometimes in this handing off uh in [13:49] their salos throw it over the wall. this [13:51] is the requirement. You build that and [13:53] you throw it back over the wall not [13:54] knowing what's going to happen. But we [13:56] always needed to be co-owners and [13:58] co-builders with our product managers [14:00] with the business problem statement so [14:02] that we could actually build the right [14:04] solution. And it just became more and [14:06] more transparent. And to your question [14:08] about uh uh how do we measure success [14:11] for engineers? If you're co-owning the [14:14] business problem, you're actually [14:17] equally responsible for that business [14:19] outcome. there's nobody else that is [14:21] responsible for it and you're just doing [14:23] the coding and I think we have just kind [14:25] of removed that wall in between and it [14:27] actually has become more um cohesive and [14:30] partnership across the board [14:33] >> because of AI you're saying [14:36] >> uh well AI has removed that barrier it's [14:38] not like because of AI AI just has [14:41] forced to remove that barrier because a [14:43] lot of times managers or engineers would [14:46] hide behind that I am just the coder [14:48] just tell me what to do that barrier is [14:51] actually um has been removed uh when it [14:55] was sometimes forced by some ENG leaders [14:57] to remove uh now it is just removed for [15:00] you. You can't hide behind it. [15:03] But then [15:05] how are nobody's job descriptions [15:08] changing maybe if a new role is coming [15:10] up but we're having a shift that's so [15:14] much more dramatic when cloud was [15:17] adopted and someone within your company [15:19] moved into cloud or Kubernetes or all [15:21] these cloudnative technologies. It often [15:23] led to a job title change more money and [15:27] a new job description [15:30] company. [15:30] >> That was the short term. [15:32] >> Yeah. Sorry. But what are companies [15:34] doing now even in the short term as the [15:38] job descriptions are dramatically [15:39] changing for their existing employees? [15:42] Well, [15:43] >> there's a bumbling of that too. I think [15:45] there's like jobs evolve naturally [15:47] anyway, right? Like the job description [15:50] you have on day one I don't think always [15:52] matches what you're doing day 90 even. [15:54] Um but [15:56] I think there's an overcorrection of [15:57] people wanting to get ahead of every [15:59] curve right now. if you have a prompt [16:00] engineer or context engineering was [16:02] fancy for a little while. Like all that [16:03] stuff is a great way to say like we're [16:05] leaning into this and we need someone to [16:06] really be an expert in this particular [16:08] piece. But if I look at engineering's [16:10] organizations right now, every engineer [16:13] understands DevOps principles. Like you [16:15] might have an S sur and a DevOps [16:17] engineer on your cross functional team, [16:19] but there's no one that doesn't [16:20] understand what they're doing there, [16:22] right? So like some of this just becomes [16:23] part of the table stakes of what an [16:25] engineer has to understand and be part [16:26] of. And I think that the AI [16:30] component to all this, right? Not just a [16:32] how do I fit this into my loop of [16:34] writing software, but also just how it [16:36] fits in, how does it work, what are the [16:38] limitations, how can I make sure that is [16:40] helping me think better and do better as [16:42] opposed to just offshouring all my [16:44] thinking uh is part of that right now. [16:47] And some people are just trying to [16:48] expedite that by making that someone [16:50] else's full-time job and saying like you [16:52] need to focus on this area, learn this [16:54] really really deeply, share it with [16:55] everybody else so that we can again [16:57] become all like or for everybody to [17:00] become somewhat like fluent in that [17:02] particular space. That's why I think [17:04] companies would tend to lean into like I [17:06] have a Kubernetes engineer, I have a [17:07] DevOps engineer like those still exist [17:10] if they become that important to the [17:12] org. But I think eventually what you [17:14] need is a everybody has a base level [17:16] understanding of what those things are [17:18] so that the expert also can lean on you [17:20] guys to not have to like [17:23] bolt on that particular component within [17:26] the team. It's the same with security, [17:27] right? Security engineers are great, but [17:29] if you if you bring them in at the end [17:31] of the product cycle, there's no way you [17:33] can actually get any meaningful results, [17:35] right? The same with I think applies to [17:38] both the other pieces, right? You have [17:39] to have this as a native part of how you [17:41] do things. [17:44] >> Yeah. And for me I [17:45] >> Yeah. Go. [17:46] >> No, I do I do see still a lot of job [17:48] offers now. I mean it was also a bit [17:50] prei about like just a product engineer, [17:53] right? We've seen the rise of this, [17:54] right? Like it's basically what we [17:56] talked earlier about it's people that [17:58] just like are able to drive like let's [18:00] say projects really end to end across [18:02] the stack. And one thing about just [18:05] purely on job descriptions, I do think [18:08] like the fundamentals of the job as we [18:09] said earlier, they haven't changed, [18:11] right? Like for example, you still need [18:12] people to really understand deeply about [18:14] front end to not chop to not ship like [18:16] 300 megabytes of like of JavaScript to [18:18] website. You still need like a strong [18:21] let's database engineer like maybe like [18:23] a strong let's say like even like [18:25] backend engineer to to really architect [18:27] well. And I think though where there is [18:29] a shift and I think it's something that [18:30] I see like like companies adopting very [18:33] like early very well is when actually [18:35] this these experts or like this people [18:37] that have this deep expertise they start [18:40] to to become more like even more [18:42] platform. So basically this was already [18:44] kind of like the case in in many [18:45] companies but now especially with like [18:48] like agent coding if actually um this is [18:51] what we have right now we are [18:53] experimenting at story block where we [18:54] have the front end team having very [18:56] clear guidelines on okay this is how we [18:57] want to ship front end of story block [18:59] this is a set of libraries or patterns [19:01] what we want to use and what we start [19:03] seeing and actually I'm super happy to [19:04] see that is that we have backend [19:05] engineers now that are like driving a [19:08] project and there's a bit of front end [19:09] like just not not like a fundamental [19:11] change maybe just the change to a table [19:13] or a new page. And because we have this [19:15] set of strict guidelines or like rules [19:18] that have been put in place by the front [19:19] end expert team, they are able actually [19:21] to to do that front end part then just [19:24] maybe get it reviewed and shipped. And I [19:25] think that's where like I think like the [19:27] the jobs are going you have a set of [19:29] experts like that can basically enable [19:31] also others even like maybe even your [19:33] product manager is able to add some [19:35] tracking to to to your front end because [19:37] they understand and they know how to [19:39] plug it in. So I think that's where it [19:41] gets also interesting is like the job [19:43] becomes both broader because you have [19:45] access to different parts but also your [19:48] expertise is still valuable to enable [19:49] others. So that's I think for me that's [19:52] quite interesting. [19:53] >> But if you just to add maybe a tiny bit [19:55] on the job description piece I think [19:57] there was no job description that ever [19:59] said um how many um like the typing [20:01] speed of your code. [20:03] >> Yeah. [20:03] >> Uh we never had that. We never had uh a [20:07] job description that you should be [20:08] writing this many lines of code. Like it [20:10] was always expertise in certain [20:12] languages. And in some ways um that [20:16] expertise like what Jeremy and Phil said [20:18] um is is becoming uh a little bit more [20:21] generic. It's no longer JavaScript [20:23] versus Java. But there are still [20:24] instances where you do need the experts [20:27] to go find that gnarly problem or go [20:30] find that um uh optimization from a [20:34] sight speed standpoint or uh connecting [20:36] the platforms. Um it's sometimes really [20:40] solve those things as a generalist. So [20:43] putting that together. So both the [20:44] generalist part and the specialist part [20:47] is important and the job descriptions [20:50] are not changing because we still need [20:51] those experts. Maybe as an early in [20:54] career you need to start more journalist [20:56] and figure out your path to the [20:58] specialist part. Which part speaks to [21:00] you and I think uh one or all of us have [21:03] moved around in our careers doing [21:04] backend then maybe front end and other [21:07] things and you kind of evolve your [21:09] expertise based on what is interesting [21:11] for you, what is uh the opportunity in [21:14] front of you as well. But being a [21:16] journalist in today's day and age is so [21:19] much more easier. We would have [21:21] engineers initially like earlier uh even [21:23] 10 years ago or five years ago. Oh, I'm [21:26] hiring an iOS engineer or I I'm hiring [21:29] um Android or a web engineer even coming [21:31] right out of college. Now I can actually [21:34] hire just engineers and then help them [21:36] get into the expertise over time because [21:39] with all this agentic code and some of [21:41] the guidelines like what uh Jeremy [21:43] shared, every company is figuring that [21:46] out. for example, like like uh incidents [21:48] when that happen over the weekends or [21:50] whatever. I don't have every uh type of [21:53] engineer on call. If it's an iOS related [21:55] issue, I'm actually have a web engineer [21:57] go figure that out and fix it with the [21:59] agents help. And and that's totally fine [22:01] because you're not writing big pieces of [22:03] code. You're actually fixing small [22:05] changes and that is so much more easier [22:07] to do now with agentic coding than than [22:10] it was in the past. So in some ways it's [22:12] both uh helping us move faster but also [22:16] helping engineers to take more time to [22:18] find their expertise in their [22:19] specialization area uh as they grow into [22:22] their career. [22:24] >> Okay, let's get more into that because [22:26] we do have a question from the audience. [22:27] Thank you Andrew. Uh where do junior [22:32] engineers fit into this new world and [22:34] how do we find senior future senior [22:37] engineers? And I think we all agree on [22:38] the call that you can't have senior [22:42] engineers until you have junior [22:43] engineers. So it's full hearty to not. [22:47] So how do we make sure [22:51] there is a place for them? What are some [22:53] tactics, some active tactics? [22:57] >> There's So this is a conversation I've [22:59] had a couple times now and I think [23:01] there's a couple themes there that I [23:02] think are being successful successfully [23:05] being adopted. One is you have to change [23:07] your expectations of what that [23:09] onboarding process looks like for a new [23:11] junior engineer. So yes, you've agreed [23:14] to hire. We haven't gone all in on the [23:16] seniors, right? Like your team needs to [23:18] be ready to adopt a junior engineer. [23:19] That's kind of always been an [23:20] interesting dynamic. But right now, one [23:23] of the things that we're seeing is [23:25] fundamentally having good knowledge [23:27] bases and access to tools and processes [23:30] documented is an incredible win for [23:34] junior engineers because they don't just [23:36] ask the agents to write the code. Like [23:38] you can ask the agents to explain the [23:40] code. Go through all your ADRs and [23:42] explain why did this like why did we [23:44] make this decision? Why aren't we using [23:45] this technology? like so you you have to [23:48] change the ratio that you're asking [23:50] questions versus you're doing [23:51] implementation for for that when it [23:53] looks to the AI side. I think the other [23:55] piece that's really important is that [23:57] the key thing that to signal like the [23:59] signal you're looking for with junior [24:00] engineers is curiosity, right? That's [24:02] always been the case I think for [24:04] successful junior engineers is like [24:06] you're going to drink from the fire [24:07] hose. You're going to have to learn all [24:08] kinds of different things. Like I know [24:09] we hired you to be a Python dev, but [24:11] here's some groovy scripts that need a [24:12] little help. Like that's that's normal. [24:14] like that's been that's been part of the [24:15] job since I don't know I came out of [24:17] college and I think that that [24:20] adaptability has just become like [24:22] there's a wider set of stuff that you [24:23] could look at but under the hood it's [24:25] still a we're trying to solve a problem [24:27] we have these technical tools at our [24:29] disposal stack overflow Wikipedia claude [24:32] it doesn't matter who you ask you're [24:34] going to be asking people like I googled [24:36] way too much my first couple years when [24:38] I was an engineer I felt guilty about it [24:40] but that's still the case like your job [24:42] as a junior really is to learn mostly [24:45] while also trying to contribute, right? [24:47] I think that that process has [24:49] fundamentally not changed. It's just how [24:52] do you culturally integrate that is [24:54] different and you have to make sure the [24:55] team understands what that looks like [24:57] and gives the right support. Um, but I I [25:00] think fundamentally, like I said, it's a [25:02] you're going to have someone who needs [25:04] to learn a lot of different things. A [25:05] lot of things are going to get thrown at [25:06] them and they have to be comfortable [25:07] with that because no matter how senior [25:10] you get, that's going to be a constant [25:11] through your career. [25:16] I would just maybe add like um adding to [25:19] Phil's point, AI actually raises the [25:21] floor in some ways um because as a [25:24] junior person maybe uh early in career [25:27] as they're coming in the door um with AI [25:30] and agents their floor is so much higher [25:34] than say two years ago when engineers [25:36] were coming out of college and uh [25:39] because of all these tools where they [25:41] don't have to ask there's so [25:43] already available for them to learn and [25:45] grow. But the fundamental thing that [25:47] makes somebody from a junior to senior [25:50] and as they grow is really the same [25:52] things. Your curiosity, are you open to [25:55] absorbing every new thing that is in [25:57] front of you? Uh your problem solving, [25:59] critical thinking and then judgment. And [26:02] it's really about how much are you [26:04] willing to have that um uh yourself uh [26:09] being open to learning and and to your [26:12] question about what is the difference [26:13] between junior and senior and how do we [26:15] help them grow? The answer is [26:19] a junior person has to grow much more [26:22] rapidly because that ceiling uh is is [26:25] much more higher and the base has [26:26] increased. So the floor has increased [26:29] and the ceiling has um uh increased with [26:31] the judgment and the judgment is what [26:32] raises the ceiling honestly and uh it [26:36] just accelerates the execution. So you [26:38] can actually get more done as a junior [26:40] person coming in uh than we were able to [26:42] do when we started our careers uh a [26:44] decade ago or two decades ago. [26:49] >> They hope. Yeah. [26:51] >> I just want to add something actually. I [26:52] like this last point, but it's also I [26:54] just want to recognize also for maybe [26:56] like people that start this career or [26:58] like maybe are like a lot into these [27:01] tools. You can learn much much faster, [27:03] but there is also uh it can be also like [27:06] something to be mindful about that [27:07] sometimes you're overexposed to so much [27:09] things, right? I think like one thing I [27:12] see also is like engineers now trying to [27:14] to push maybe twice as much or three [27:17] times or four times as much tickets in a [27:19] day or in an afternoon without taking a [27:21] break because now it's just one prompt [27:23] away, right? It's like, okay, just maybe [27:24] one more or like and and and I think [27:27] just like when you start, it's still [27:28] very good also to to to pause and to [27:32] reflect and to to to take this time to [27:34] learn, right? I think I've seen it [27:36] myself like it's easy to skim through [27:38] the agent response and just take the bit [27:39] that interests you and you skip that [27:41] learning and I think that's where [27:43] especially for junior folks and also for [27:45] managers alike we need to keep making [27:48] space for people to to to absorb this [27:51] breath of information right this [27:53] experience but it is very exciting that [27:56] they are able to to to browse through [27:58] much wider set of experience to be [28:00] exposed to a bigger set of things but I [28:02] just also like to want to remind people [28:04] maybe watching like just just be mindful [28:06] about not overdoing it too fast, right? [28:08] I see so many people just like getting [28:10] co getting caught into this like like [28:13] dopamine train with the agents. So just [28:16] like absorb and experiment and learn, [28:18] but also give your time give yourself [28:20] time to to to absorb it over like a long [28:23] longer period of time, not just rush [28:25] through it. [28:27] How often do you think developers, even [28:32] senior ones, feel like they have [28:33] permission to take a break and learn [28:35] right now? Because like there's this [28:38] real feeling right now that everyone is [28:40] more productive than me. The headlines [28:42] for three years have been saying 44% [28:45] more increased productivity. And while a [28:48] lot of these companies promise these [28:50] great numbers, [28:53] they're not actually [28:56] finding like they're they're getting [28:58] obsessive in the cycle of feedback from [29:00] AI and they're also not getting these [29:06] productivity returns. So what do you [29:08] tell them? [29:11] So for me, I think first like one thing [29:13] is um about like recognizing that like [29:16] yeah like the loudest people are not [29:18] necessarily the people that like [29:20] actually are like owning the most [29:21] business outcomes, right? But but it's [29:23] also I think like I really want to [29:24] emphasis that it's also responsibility [29:26] of us like maybe managers or people that [29:29] have bit more expertise in the field to [29:31] to recognize or to make that time for [29:33] people to also learn, right? Like if as [29:36] you said like if people are just like [29:37] bombarded with projects and things to do [29:39] and they're just like using these tools [29:41] to go faster and faster. I think it's [29:42] about really are more like senior leader [29:45] responsibility to also carve out that [29:47] time. And the second one I think is also [29:50] to share about kind of like the let's [29:52] say the second face of the coin or like [29:54] this other side of of the coin sorry [29:56] about kind of like this more like just [29:59] being trapped in this loop that I was [30:01] talking earlier. as long as you as you [30:03] recognize it and then you help people [30:04] just like acknowledge it and then for me [30:08] I think it's going back to really is the [30:10] beginning of this conversation again [30:12] you're going back to outcomes I don't [30:13] care how many pull requests or how many [30:16] lines you wrote if if anything we know [30:18] that sometimes the more code is actually [30:20] a worst outcome right so it's really [30:22] about reminding these fundamentals to [30:24] people and that like we are not here to [30:26] count like how many things you're [30:28] churning many you're you're really here [30:30] to see what you can drive. And I think [30:32] for me it's it's a it's a big job of [30:34] like of of managers to really try to [30:37] help reassure folks that like this is [30:40] what matters in the end of the day. And [30:41] also their craft matters, right? Like I [30:43] think one thing that I'm very also like [30:45] worried about or like I tell people [30:48] working with me is like we don't want [30:50] you to to to to really lose your craft [30:53] or like just like like stop like [30:56] delegate your thinking, right? Like the [30:58] judgment everything is still needs to be [30:59] there, right? So I think I think for me [31:02] this this is still also fundamental and [31:04] and I think the burden is still more on [31:07] managers and of course like for people [31:08] that are also maybe in the industry to [31:11] to to recognize these patterns and to [31:13] try to to find the escape hatch when [31:15] they can [31:17] >> there's also [31:19] sorry go ahead [31:21] >> I was just going to add I think it has [31:23] actually make made uh engineers realize [31:26] um to be more self-regulating to your [31:29] question um uh Jennifer around like when [31:32] do we take a pause? It's so easy to get [31:35] trapped into this. Have the agent work [31:38] through the night while you're sleeping [31:40] and give the tasks and well that's all [31:43] extra work for the engineer as well. But [31:46] being self-regulatory around what is the [31:49] outcome and the uh business or system or [31:52] customer uh impact that you're making [31:55] and and being self-regulatory around it [31:58] because you can the agents can work the [32:00] computer can work 24 by7 but as humans [32:03] we need to be more mindful about about [32:05] that and as managers and as leaders we [32:08] need to create that space and talk about [32:10] it openly uh so that uh people can feel [32:13] that they have the permission to take a [32:17] I think it's all kind of summed up in [32:19] engineering culture in most cases, [32:21] right? Like you need to have the culture [32:22] that allows for the exploration of new [32:25] things, the ideas, the sharing, like if [32:28] you have communities of practice, like [32:29] whatever outcome or mechanism you have [32:31] within your organization to do that. And [32:34] Jeremy mentioned this a little bit as [32:35] well. I think seniors have a big [32:36] responsibility here to not just create [32:38] that space, but to model it, too. I [32:40] think that they also need to be able to [32:42] publicly show like like I this time is [32:45] blocked off. I'm I'm reading up on the [32:48] latest developments and everything else. [32:50] I want to find new opportunities. I want [32:52] to stay sharp. Um and I think that [32:54] there's [32:55] there's a a cultural element to it [32:57] that's really important to be able to [32:59] make sure that you share these things. [33:00] You share the learnings that's both good [33:02] and bad, right? Because right now I [33:03] think to your point earlier, Jennifer, [33:05] like a lot of this is FOMO and this is [33:07] the typical social media. We're getting [33:08] the highlight reels for everybody. Like [33:11] I sure I I talk to probably four Fortune [33:14] 500 companies every day non-stop. Nobody [33:18] is seeing those like 5x boosts in [33:20] productivity, right? Like you're seeing [33:22] it in that kind of like maybe 30% across [33:25] the board type of thing. And I think [33:27] that that's where [33:28] >> like we also as an industry maybe need [33:31] to slow our role a little bit and say, [33:32] "Look guys, we're still figuring a lot [33:34] of this out. Sure, I can write boiler [33:35] boilerplate code as fast as any, but [33:38] like that's not how I solve problems, [33:40] right? I have to deal with a messy code [33:42] base and you know inconsistent, you [33:45] know, things applied across these [33:46] different microservices like all that [33:47] kind of stuff. Like that's that's the [33:49] wrangling that happens. And so the [33:51] learning also comes from like having a [33:54] senior engineer show up and be like [33:55] look, let's sit at this together, right? [33:57] Let's sit down together. You and me, [33:58] we're going to go through the codebase [34:00] and we're going to just ask it like why [34:02] is it doing this? let's follow this [34:04] function call. Let's see what happens [34:05] here. Like and like that's part of [34:08] mentoring juniors, but that's also part [34:10] of how you learn how a codebase works, [34:13] right? Like you have to do all the [34:14] fundamental steps. And I think that [34:16] that's realizing that that's part of the [34:17] job, right? It's not cranking out lines [34:19] of code. It's a sitting there, ingesting [34:22] it, understanding the reasoning, making [34:25] sure other people can follow it, too. [34:27] Right? Like one of the things I saw, one [34:29] of the best engineers I've ever seen in [34:30] my life, his commits often were just [34:33] like adding extra code or extra [34:34] documentation to the repository. Like it [34:37] wasn't cleaning any of it up. It was [34:39] making it easier for the next person to [34:41] pick up the thread where he left off to [34:44] make it not as hard. So I think that [34:46] that's the kind of patterns we need to [34:47] follow or fall back on really because [34:49] it's that's always been the case. [34:51] >> Okay, [34:53] that is true. But most job descriptions [34:58] are what people are, you know, evaluated [35:01] against in their stupidly annual [35:03] evaluation. [35:05] And as Sarah asked from the audience, [35:08] how are you thinking about compensation [35:10] and paths to promotion in this new world [35:13] of AI? If everyone moves up faster, does [35:16] that I don't suspect, like you said, [35:19] Shallini that the floor is raised to [35:22] start. I don't suspect in this e current [35:26] economic climate that translates to [35:28] people are going to move up faster. It [35:30] actually feels like it's the opposite. [35:32] It's slowing down. People are not [35:34] jumping from company to company in tech [35:36] for once and they're not for each role [35:39] moving up 20k a year or every six months [35:43] or something. So, how do engineering [35:47] managers and whole HR departments need [35:50] to rethink compensation and this [35:53] hierarchy we've been working on? [35:56] Um, so I think the promotion part of it [35:58] is you're totally right. It's not like [36:00] because the floor is rising, the [36:02] promotion uh rate also rises. It's not [36:05] because I think at the end of the day [36:06] from an HR standpoint or even just as [36:09] leaders and managers, you are promoting [36:11] somebody who is operating at that next [36:13] level already and defining what does [36:16] that next level looks like is going to [36:18] be interesting as we start thinking more [36:20] about the outcomes and uh uh looking at [36:24] that outcome and ownership and um do you [36:26] have the product and customer [36:28] understanding is like what Phil [36:29] mentioned earlier around domain [36:31] expertise [36:33] and as from a junior to a senior person, [36:36] your uh promotion readiness may also be [36:38] dependent on how much expertise do you [36:41] have not only on the technical side but [36:43] also the domain side. Uh and if you're a [36:45] systems engineer, it it's the same [36:47] thing. How much domain expertise you [36:48] have for that system uh on on the [36:51] platform side as well. And and that is [36:53] going to be an additional way. It's not [36:56] like it was not there but this becomes [36:58] more and more important now uh in terms [37:00] of like the outcome ownership the [37:02] technical judgment you have uh do you [37:04] have the systems thinking to think [37:06] beyond the problem that you're solving [37:08] and actually helping beyond the team [37:10] that you're working on as you're moving [37:12] to the next level um some of those were [37:15] already part of the uh evaluation [37:18] process but uh I can imagine like going [37:21] from like a very junior person to say [37:23] the next level where you're not senior [37:25] about like um software one to software [37:27] 2. It was more about execution. Now it's [37:30] going to be about execution and [37:32] judgment. [37:34] >> How is that measurable then? How can the [37:37] average engineering manager who has to [37:40] report to HR or advise HR maybe HR is [37:42] doing this measurements [37:45] going to change that? [37:47] uh it has to then tie to your outcomes [37:49] whether it is business or system [37:51] outcomes to a certain extent and and [37:53] talk about it's not just the lines of [37:55] code but the judgment that you have made [37:57] um to ensure uh that the business [38:00] outcome is there [38:02] and that business outcome can be in [38:04] various different facets whether it is [38:06] revenue or engagement or um performance [38:11] uh depending on which lines of uh areas [38:14] that you're working on [38:15] >> could risk experimentalism. It's could [38:18] that risk experimentation because if it [38:21] is a hypothesis that fails like AI is [38:24] supposed to help us prototype and make [38:28] >> experiments more but if that's not [38:30] driving a business outcome is that still [38:32] success if you learn it didn't [38:33] >> totally totally I think and that's where [38:35] the secondary metrics comes along and [38:37] would love to hear from Phil and Jeremy [38:38] too is like how many times were you able [38:41] to experiment hypothesis is like instead [38:44] of one were you able to do five more um [38:47] or whatever that X number could be. Uh [38:49] so that yes maybe the business outcome [38:52] is not there but were there enough [38:53] hypothesis that were tested in the [38:55] ecosystem for you to move forward [38:58] because yes maybe quarter over just [39:01] looking at one quarter maybe it's not [39:02] enough but you've had enough hypothesis [39:04] invalidated maybe the following quarter [39:06] you will find that uh impact that you [39:09] were looking to do. [39:10] >> Okay. [39:11] >> I I think there's there's two components [39:13] to it as well. I think Shelony already [39:15] hit on it pretty well, but I think the [39:17] other one is worth saying like do you [39:19] make other people better around you. I [39:20] think it's one of the things that I [39:22] think is really important when you [39:23] evaluate an engineer and this can be [39:25] like it's different for each role, [39:27] right? Like a senior engineer obviously [39:28] has the ability to mentor individually [39:30] the juniors, but there's also just a did [39:34] you clean this up? Did you make this [39:35] process better documented? Did you leave [39:38] it better than when you found it type of [39:40] thing? And I think that that's also a [39:42] piece where the experimentation is [39:46] partly a risk on your own part. Like how [39:48] much experimentation and new things are [39:50] you going to try? Like yes, if you're [39:52] going to take that into your performance [39:54] cycle, you you might hit, you might not. [39:55] Like that's a risk you have to take. But [39:58] being known as someone who takes [40:00] consider like well balanced and [40:03] wellthoughtout risks in that sense, [40:05] right? tries new things, sees that [40:08] that's happening. I it in and of itself [40:11] is valuable. Um it's also incredibly [40:13] valuable if you make that something that [40:15] turns into or institutional knowledge, [40:17] right? Like there's a section of the [40:20] backlog that we've explored but we've [40:22] never really tried against. Well, if you [40:23] create a hypothesis and invalidate it [40:26] because that's not something you guys [40:28] can do as an organization, that's [40:30] incredibly valuable because now that's [40:32] one less thing that everybody needs to [40:34] consider on a quarterly basis. So [40:36] there's there's a way to get value from [40:39] a negative result in that sense. And I [40:42] think that's also where you have to like [40:43] make sure that you own it and understand [40:45] like why am I doing this? Am I learning [40:47] something? Is the organization trying to [40:50] determine something? Um, not all [40:53] experiments have a positive result in [40:56] the form of new product slash new [40:58] revenue, right? Like some of it can just [41:00] be as simple as, hey, I created a [41:03] Bootstrap version or a pre-built GitLab [41:05] or GitHub repository to make it just [41:08] that little bit easier for people to [41:11] spin up a microservices that adheres to [41:13] our standards or whatnot, right? [41:15] There's so many different ways you can [41:16] do this that I think it's hard to [41:21] list them all out, but under the heading [41:24] of like have you made everybody else's [41:25] life just a little bit easier is just an [41:27] easier way to think about it. And like [41:28] that's how you get promoted because you [41:31] are a asset to the team and the company [41:34] in a way that people want to be around [41:37] you. But you have to learn to be able to [41:39] speak about that glue work people [41:42] because specifically women and people [41:44] from minoritized groups have always been [41:46] doing that glue work and not getting [41:48] promoted because that wasn't part of [41:50] their job description famously. [41:54] >> Yeah, that that's part of it. You have [41:55] to be your own cheerleader. I think it's [41:57] important that I think one of the best [41:58] management principles ever is like both [42:01] the direct report and their manager has [42:03] to have a different version of the brag [42:05] book for that person. Right. Write down [42:07] all their accomplishments, keep track, [42:10] and then when you get to your quarterly [42:12] or yearly reviews, you both have a [42:14] version of it, and you want to check and [42:16] sync it with each other, obviously. But [42:17] don't make that a like surprise to [42:19] everybody like, "Hey, I did these 18 [42:21] things this year." Like, everybody [42:23] should have heard of it. And then, [42:25] right, and I think that's also part of [42:27] the culture thing, right? You have to [42:28] celebrate your engineers. Not all of [42:30] it's going to be here's a pay raise [42:32] celebration. Some of it's also just a [42:34] this person did something really [42:35] incredible. Let's showcase them. That [42:37] that's valuable enough because it's a [42:39] good way to reinforce that lifting each [42:42] other up. [42:43] >> Celebrate learning, not necessarily [42:45] success and amplifying learning. Jeremy, [42:48] >> yeah, I like what you said also about [42:50] the this like achievement document. I [42:52] actually encourage even like everybody [42:53] in my team to actually build also their [42:55] own version because I'm I'm I'm I'm sure [42:57] I'm always missing something. And I [42:59] really like what you both said about [43:01] let's say like getting this like let's [43:03] say this promotion like or like the path [43:06] to promotion or the path to to to to [43:08] let's say show like seniority. I think [43:11] the last angle that I think I really [43:12] also think is very important and I think [43:14] that's where also managers can really [43:16] see it is also how you you've been [43:18] basically like building this outcomes or [43:21] how you using these technologies right [43:23] so have you shipped like small iterable [43:25] changes safe to production like have you [43:28] have like made a plan like a rollout [43:30] plan I mean all these things like kind [43:32] of like the best practices of [43:34] engineering is it like something that [43:35] you do on a regular basis and then that [43:38] like that's really like is your work [43:40] like really let's say smooth even as you [43:42] said like I like what you said Phil feel [43:43] about enabling others but it's also [43:45] about making sure that it's easy for [43:47] others to basically work with you right [43:49] like if there are like this small [43:50] targeted change that people are able to [43:52] give you ship fast everybody understands [43:54] what you do I think that also makes you [43:56] much more efficient and much more likely [43:59] to be promoted if if you're like an [44:01] engine for for the company as well right [44:03] like somebody that also maybe even [44:04] defines new processes or like finds way [44:07] oh the way we've been doing this is like [44:09] really inefficient what about this and [44:11] then you get time to drive it and to [44:12] change it. And this is where like really [44:14] like a lot of people especially now with [44:17] all these new tools can really show a [44:19] lot of of impact in in organizations [44:23] >> and talking to customers or other [44:26] departments I think more than ever [44:29] bridging those gaps but finding a way to [44:32] spend time with customers or customer [44:34] support or anybody that's a domain [44:36] expert [44:38] is very valuable as well. I mean, we're [44:40] just touching like breaking the very [44:43] surface of this topic and I think we've [44:46] got several conversations to go and we [44:50] need people to go deep in depth and [44:53] really think about how you are [44:56] psychologically safety because we didn't [44:58] mention that but all these things we [44:59] talked about today are only possible if [45:01] you have a psychologically safe uh [45:05] iterative environment that encourages [45:07] learning. So, I wish that for everyone. [45:10] As we're winding down, I did just see [45:12] Margarita shared a question in Slack, I [45:14] mean, or in the chat here. So, I'm just [45:16] going to tease it now. So, hopefully [45:18] people will go to the Slack, whether [45:20] they're joining now or viewing. And the [45:23] the question is or the discussion today [45:25] leans toward engineers becoming more of [45:28] product engineers, evaluated not just on [45:30] technical skills, but also on domain [45:32] knowledge and customer problem [45:34] understanding. It's what they always [45:35] should have done. and that's how they [45:36] get promoted. Uh why do you think we see [45:39] a lot of movement in the opposite [45:41] direction where companies are shifting [45:42] coding with AI to PMs not engineers [45:47] responsibilities and laying off [45:48] engineers because AI can now assist with [45:51] writing code and making system [45:54] decisions? Are they just confused and [45:56] lost between vibe coding and [45:57] engineering? So I will check y'all on [46:01] the slack and we will continue the [46:05] conversation there. Thank you so much [46:07] everyone. [46:08] >> Thank you. [46:09] >> Thank you. [46:10] >> Thank you. [46:11] >> Have a great day and good luck all.  ## Highlights - Even in the past when you hire a software engineer and they grow they're not growing because they are faster in coding they're growing because they can translate the problem that need to be solved and break it down and really do that problem solving and critical thinking - Note: 📚 Engineers grow through problem translation not coding speed · - Core argument from Shalini about what drives engineering career advancement - Challenges misconception that AI threatens core engineering value proposition · #atom/literature/h1 - We always needed to be co-owners and co-builders with our product managers with the business problem statement so that we could actually build the right solution. And it just became more and more transparent. - Note: 📚 AI removes barriers preventing engineers from hiding behind coding tasks · - Shalini explaining how AI forces visibility of what engineers should already be doing - Supports thesis that role evolution is correction, not disruption · #atom/literature/h2 - One of the biggest strengths for engineers right now is the ability to say no. Like no, we don't build this. No, this isn't how we should go about it. - Note: 📚 Engineering's biggest current strength is the ability to say no · - Phil's insight on value creation through constraint and judgment - Differentiates engineers from pure order-taking programmers · #atom/literature/h3 - Engineering value creation transcends code production - Note: [[Technical leadership principles]] — because extends beyond individual contributor work · - [[Technical leadership principles]] — because extends beyond individual contributor work · #atom/zettel/z1 - AI adoption success correlates with existing engineering fundamentals strength — investigate measurement approaches #fleeting #articleseed - Note: ✏️ Fleeting capture #atom/fleeting/f1 - Junior engineer onboarding evolution in AI era — interview hiring managers across tech companies #fleeting #xref - Note: ✏️ Fleeting capture #atom/fleeting/f2 - Glue work visibility and promotion equity — research gender/diversity impacts #fleeting #addendum - Note: ✏️ Fleeting capture #atom/fleeting/f3 - Heavy reliance on panelist experience without broader data validation - Note: 🔍 Fallacy: Appeal to Authority #fallacy/appeal-to-authority