Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Emergent DevEx: The Good, the Bad, and the Legacy

Emergent DevEx: The Good, the Bad, and the Legacy

Avatar for Makan Sepehrifar

Makan Sepehrifar

October 10, 2026

More Decks by Makan Sepehrifar

Other Decks in Programming

Transcript

  1. Developer Experience (DevEx) ▪ +1000 Talks, Articles and Books ▪

    Countless Buzzwords ▪ Hundred Softwares And Solutions ▪ A lot of conflicting success metrics
  2. Who Are We & Why Are We Here Makan Sepehrifar

    Soroosh Khodami Staff Engineer @ Solution Architect @
  3. The "Two-Pizza Team" Phase "Once upon a time, there was

    a team who turned Pizza and Coffee into Code."
  4. Birth of Domains As a product scales and complexity grows,

    you either intentionally divide your architecture and teams into distinct product domains, or your engineering speed will collapse under the weight of its own cognitive load. "Conway's Law is undefeated: you cannot build a decoupled, scalable product with a coupled, monolithic organization."
  5. FOUNDERS: VAGUE VISIONS & EXCESS SALES: MARKETING: ENGINEERING: SYNERET, OISRUPTION,

    & MEMES CRITICAL BUG FIXES & COMPLAINING SYKEROE LEVERACC OUR CODE IS BEAUTIPUL (10 US) OUR CODE IS BEAUTIFUL HR: "WE'RE A FAMILY" AND COMPLIANCE FORMS PRODUCT: ABSURD QUOTAS & CELEBRATIONS DREAMERS WHO ONLY TALK TUE OUTAS SLEBRATIONS AGEV FOETANOT DESTESSHORIEUS,r PIVOT! LEGAL: "IT DEPENDS" AND DREAMS DIE HERE AL lis n u
  6. The Complexity of Scale Departmental Silos The Result • Isolated

    Requirements and Decisions • Local Optimization to address Business Needs • Communication Gap between Developer • Process Chaos • Top-Down Alignment “Even the most idealistic flat startups eventually grow managers, titles, and reporting lines, not because founders suddenly love bureaucracy, but because informal power structures fill the void if formal ones don’t.”
  7. LOCAL OPTIMIZATION: FOUNDERS / LEADERSHIP Process: YREVEN PRODUCT: 3 100%GO

    UE / SFACTION D ET 100%.GOALACHIEVE GOAL = MAXIMUM ROADMAP COMPLEXITY ET 100% GOAL ACHIEVED ET 100% GOAL ACHIEVED thei Send ENGINEERING PURITY & REFACTORE: ING GOAL=100% COD COMPAN CUYTOMERSATI ARD DASHALBO ACHIEVED 9 100S GOALACHIEVED 11 GANTT Signups 47 code reviews required before MARKETING: shipping SALES: GOAL = HIT QUARTERLY BONUS AT ANY COST Process: Say "Yes' to cilent, ask auestions GOAL = VIRAL MPRESSIONS & HYPE mpressions PLETION Signups never sr:ees s e c e i Proerevfor e 4q7cuoirdepdpbing re shi HR&LEG GOAL=ZEROL AL: &FORMCOMIABILITY MT AN RD CHEAINAINTGORY CKLI STS
  8. Platform Engineering Team Arises "Platform engineering emerges to bring visibility

    into Silos and transform organization friction and complex dependencies into streamlined self-service."
  9. Platform Engineering Promises Bring visibility into the Department Silos while

    Lowering the Cost through Technology Standardization and Process Unification. Increase (or Maintain) Delivery Speed through Streamlining Unified Processes. Built-In Compliance Saving Hours Less Friction Secure by Design The State of Flow
  10. The Platform Paradox “There is always a well-known solution to

    every human problem : neat, plausible, and wrong.” – H.L. Mencken, Prejudices
  11. The Myth of 1:1 Model Migration “Organizations are hardly carbon

    copies of one another,so their strategies also shouldn’t be. ……... This typically happens when a strategy is adopted from another organization or a success story that worked off different preconditions. Needless to say, a path starting from somewhere else isn’t a very useful option.” – Gregor Hohpe, Platform Strategy
  12. Platform Teams Reality “Despite their names, Platform Teams are not

    created from Ground UP, They are created in later stages of organization, trying to find a place and gain control in the middle of pulling forces.”
  13. Countless initiative who promise Reducing Cost, Saving Hours, Focus on

    Delivering Value and Less compliance work Resists structural changes and relinquishing control over local platform practices in Silos. Look for Predictability, Autonomy and Innovation and is expected to maintain delivery speed while growing bureaucracy slows them down.
  14. Shape your own Path “From the ashes a fire shall

    be woken,A light from the shadows shall spring; Renewed shall be blade that was broken, The crownless again shall be the king.” – J.R.R Tolkien, The Lord of the Rings
  15. TECHNICAL DICTATORSHIP Variation is non-compliant. Use ours. ADMIN ADMIN ADMIN

    KEY KEY KEY ORG STATUS QUO THE APPROVED STACK - MORE SPEED S S E L D R REGA D E V O R P AP S) - MORE CHAOS? (BYU AOMIN RIGHTS NO SHORTCUTS ข า วา PLATFORM CHECKPOINT ช researc ALL INNOVATION MUST PASS NOPNL-IANT NOPOTRTEDSUPP COMPLIANCE CONTROL T PRODUC ENGINEER COM SUP h NOTORTED - MORE TOOLS - MORE CHOICES SECURITY ADMIN RIGHTS solution: PAPIRESRTWORK Only the one we REJECTED F prop osed . TOOCREAT IV TOOR They gained control, Everyone else lost the right. ISKY E
  16. D E T A C E EPR CS WRAPPER GRIM

    D APIDO ( ow fl h t u a d l -o(removed) cs -legoancoydtuose) you from lock-in! BOTTLENECK ints -vlreentdirpeod) This will save don't Our Unified Cloud Abstraction (d touch /hotfix YAML ICG R A SHEINWY E T M S A N TURE FFERENCE AU-STCOALER IN FEA AUTO • layer: auth - layer: compute - layer: storage - layer: ??? MY APP Gregor Hohpe - profit? aws MRARGLES breeking change Built to avoid lock-in, Now the lock-in has also a blade. Se
  17. PLATFORM ENFORCEMENT 2. FORCE THE MIGRATION 1. BLOCK NEW ONBOARDING

    THE OLD WAY Developer experience that works ADMIN KEYS LIGHTINSG DIMM NONAEMWS TE TO BUILD. PLATFOR TEAR RECVCOEKSESD A PO UPDLAICTY E THIS ISN'T ION PTET ADTAORG PUGRATION... IT'S EVICTION. TEAM IDEAS INSIDE First they closed the door. Then they turned off the lights. MY APP THEPLATFORM ACCOEKSESD DEPENBEN CY REV BLOCKED. Migration REVEOEKWEEDS TO R ACECVEOSYED is the only door left. FLATFORM I LEAD S NEW MARKET SHARE ADMIN RIGHTS BUT... WE JUST WANT Ship it! SUCCES METRICS LEGACY APP (IT WORKS) TOOLING I LOVE ONEWAY IN
  18. PORTAL-DRIVEN EXPERIENCE PLATFORM PORTAL workfloewd requir ENDLESS FORM V2.1 Name

    * Email * no CLI WIZARD STEP 3 OF 47 SECTION 7: DEPENDENCIES Select Capability * Does this depend on other services? Employee ID * Department * Justification * -- Choose wisely -- Next > (min 150 chars) PLATFORM ENGINEER ENVIRONMENT & COMPLIANCE Just fill out the form. Prod Non-Prod • DR • PCI • SOC2 • GPPR • Other (explain) • Yes (please explein) • No (prove it) *sigh* STEP 14 OF 47... RISK ASSESSMENT (REQUIRED) Potential Impact? Low / Med / High / Catastrophic • Next › Next > WIZARD STEP 14 OF 47 APPROVAL WORKFLOW Business Value (select ene) Anticipated approvers • FUEL • Cost Stratsgic • Strategic • Other (attach PPT) Next › The platform is a form. hides the service designed no API for the portal service designed for the portal NEXT > service designed for the portal OUTOFE SERVIC AL) (SEEPORT ONLY ONE WAY IN (auto-assigned) Next > REAL API complexity - Routing in progress - (MANDATORY) The portal delivers everything. (SPAGHETTI CODE EDITION) Next > ploed evidence (odf, docs, sis solg) • Revenue LOGIC-HEAVY FRONTEND BRAIN Start with backend + API
  19. Abstraction Dilemma "The hardest part of platform engineering is balancing

    the exact right level of standardization against developer preference and organizational legacy" Too much and nobody learns, Too little and nobody adopts
  20. The Narrow Corridor “The conflict between state [centralized standardization force]

    and society (developer communities) …. , creates a narrow corridor in which liberty (innovation) flourishes” – Daron Acemoglu and James A. Robinson, The Narrow Corridor
  21. If You Are Part of Platform Engineering Teams... Key architectural

    principles to balance standardization, developer autonomy, and co-creation.
  22. The Silent Customer It is impossible to make everybody happy,

    But it is possible to answer everyone’s needs.
  23. Golden Paths, not Golden Cages PRINCIPLE 01 PRINCIPLE 02 PRINCIPLE

    03 Build for Composition & Extension Co-Creation as a Primary Goal Enable, Don’t Enforce
  24. Developer Empathy Let go of your Admin Rights. Look for

    Friction Points not Market Share. Do not Reinvent the Wheels. Meet developers, where they are.
  25. Package Capabilities as Reusable Components Reusable Packaging Wrap custom workflows

    and automation into standardized and ready to be used components so other teams can discover and compose them. • Standardized Modules: Package workflows into modular, discoverable units for the whole organization. • Composable Architecture: Enable teams to effortlessly discover and integrate existing capabilities.
  26. Elevate Collective DevEx Community-Driven Standards Golden Rule: Anything that makes

    your life easier, can also be of value to somebody else. Active Advocacy Build the Standard: Strong community adoption makes it much harder for the Platform Engineering team to arbitrarily change or disrupt the established process, effectively cementing bottom-up standards across the organization.
  27. Share Beyond Code Transparent Knowledge Sharing True community sharing goes

    beyond raw code and polished success stories. Share practical "How-To" guides, operational runbooks, and honest post-mortems of your failures and anti-patterns. • Practical How-To: From very basic to advanced topics • Runbooks: Document practical workflows, edge cases, and operational guides. • Failure Stories: Share honest post-mortems and anti-patterns to prevent duplicate failures.
  28. Innersource: The Culture of Shared Responsibility “Every good work of

    software starts by scratching a developer’s personal itch.”
  29. Innersource: The Culture of Shared Responsibility True DevEx can be

    achieved only when it is truly built by developers, for developers.
  30. Agentic Engineering & Developer Experience Agentic AI alters how platform

    capabilities are discovered and how coding conventions spread across teams. On PLATFORM SIDE On DEVELOPER SIDE Service API Exposure Convention Replication AI solves service discovery but relies heavily on API exposure. AI coding assistants excel at finding and replicating patterns. Platform engineering teams must invest in high-quality Service APIs to enable seamless autonomous capability consumption. Developers must document conventions and invest in high quality code within repositories to guide agentic behaviors.
  31. Stop Settling. Let’s Build What’s Next • • • •

    One Size Fits None Composable Architecture InnerSource Ecosystems Proactive Standardization • • • • Early Advocacy Bottom-Up Standards Friction vs. Satisfaction Continuous Improvement