Engineering Enablement by Abi Noda DX

In this week's episode, we welcome Derek DeBellis, lead researcher on Google's DORA team, for a deep dive into the science and methodology behind DORA's research. We explore Derek's background, his role at Google, and how DORA intersects with other research disciplines. Derek takes us through DORA's research process step by step, from defining outcomes and factors to survey design, analysis, and structural equation modeling.
Discussion points:
(3:00) Derek’s transition from Microsoft to the DORA team at Google(4:28) Derek talks about his connection to surveys(6:16) Derek’s journey to becoming a quantitative user experience researcher(7:48) Derek simplifies DORA(8:19) DORA - Philosophy vs practice(11:09) Understanding desired outcomes(12:45) Self reported outcomes vs objective outcomes(16:16) Derek and Abi discuss the nuances of literature review(19:57) Derek details survey development(27:55) Pretesting issues(29:30) Designing surveys for other companies(35:02) Derek simplifies model analysis and validation techniques(38:48) Benchmarks: Balancing data limitations with method sensitivityMentions and Links:
Derek DeBellis on LinkedInDX’s guide to measuring GenAI adoption and impact2023 Accelerate State of DevOps Report

This week we’re joined by Sean Mcllroy from Slack’s Release Engineering team to learn about how they’ve fully automated their deployment process. This conversation covers Slack’s original release process, key changes Sean’s team has made, and the latest challenges they’re working on today. 
Discussion points:
(1:34): The Release Engineering team(2:13): How the monolith has served Slack (3:24): How the deployment process used to work (6:23): The complexity of the deploy itself(7:39): Early ideas for improving the deployment process(9:07): Why anomaly detection is challenging(10:32): What a Z-score is(13:23): Managing noise with Z-scores(16:49): Presenting this information to people that need it(19:54): Taking humans out of the process(23:13): Handling rollbacks(25:27): Not overloading developers with information(28:26): Handling large deploymentsMentions and links:
Read Sean’s blog post, The Scary Thing About DeploysFollow Sean on LinkedIn

This week’s episode is the recording of a live conversation between Abi and Chris Westerhold (Thoughtworks Head of Developer Experience). This conversation is useful for anyone early in their journey with developer portals or platforms: Abi and Chris discuss common approaches to solving these problems, pitfalls to avoid, building vs. buying, and more.
Discussion points:
(3:09) Why there’s an increased interest in developer portals(5:33) Chris’ background with dev portals(6:37) Homegrown solutions for developer portals(9:22) How developer portal initiatives begin(11:24) Internal developer portal vs service catalogs and IDPs(16:18) Mistakes companies make with developer portals(21:05) Approaches to solving this problem(24:28) How can developer portals drive value(32:07) Common traps to avoidMentions and Links
Follow Chris on LinkedInWatch the recording of this conversation Watch part 2 of this conversation on the market landscapeLearn about PlatformX, DX’s product mentioned in the conversation

On this week's episode, Abi interviews Kent Wills, Director of Engineering Effectiveness at Yelp.  He shares insights into the evolution of their developer productivity efforts over the past decade. From tackling challenges with their monolithic architecture to scaling productivity initiatives for over 1,300 developers. Kent also touches on his experience in building a business case for developer productivity.
Discussion points:
(1:42) Forming the developer productivity team(3:25) Naming the team engineering effectiveness(4:30) Getting leadership buy-in for focusing on this work(7:54) Managing code ownership in Yelp’s monolith(12:23) Supporting the design system(16:00) The business case for forming a dedicated team (19:45) How to standardize (23:50) How their approach to standardization might be different in another company(27:08) Demonstrating the value of their work (32:21) Building an insights platform(38:47) How Yelp is using LLM’sMentions and Links
Connect with Kent Wills on LinkedInWatch Kent’s 2023 talk at ElevateListen to the interview with Peter Seibel (“Let 1,000 flowers bloom”)Download the recently published benchmarks on developer productivity team headcount

This week we’re joined by Gail Carmichael, Principal Instructional Engineer at Splunk. At Splunk, Gail’s team is responsible for improving developer onboarding, which they do through a multi-day learning program. Here, Gail shares how this program works and how they measure developer onboarding. The conversation also covers what instructional engineers are generally, and how Gail demonstrates the impact of her team’s work. 
Discussion points:
(1:16) The Engineering Enablement & Engagement Team at Splunk(8:01) What an Instructional Engineer is(14:36) The developer onboarding program at Splunk(16:05) Components of a good onboarding program(21:11) Why having an onboarding program matters(28:17) Measuring onboarding at Shopify (Gail’s previous company)(31:39) Measuring developer onboarding at SplunkMentions and Links
Connect with Gail on LinkedInDownload the report on Developer productivity metrics at top tech companies

In this episode we’re joined by Adam Rogal, who leads Developer Productivity and Platform at DoorDash. Adam describes DoorDash’s journey with their internal developer portal, and gives advice for  other teams looking to follow a similar path. Adam also describes how his team delivered value quickly and drove adoption for their developer platform.

Discussion points:
(1:47) Why DoorDash explored implementing a developer portal(6:59) The initial vision for the developer portal 12:19 Funding ongoing development 16:01 Deciding what to include in the portal 19:15 Coming up with a name for the portal 20:01 Advice for interested beginners23:55 Putting together a business case32:32 Getting adoption for the portal 37:27 Driving initial awareness 41:29 Getting feedback from developers48:33 What Adam would have done differently
Mentions and links:
Adam Rogal on LinkedInGet started (API)New testing and monitoring tools