I owe you an apology for skipping last Tuesday. Time was tight, and rather than forcing out something rushed, I chose to wait until I could sit down, think clearly, and write something that actually adds value.

It’s that time of year when we make time for the people who matter most. We schedule dinners with family we haven’t seen in months, we catch up with old friends over drinks, we actually show up to those holiday parties. There’s something about December that makes us pause the usual grind and invest in relationships.

So here’s a question: when was the last time you sat down with your developers, not for a sprint review, not for a stand-up, but to actually understand how they work?

If you’re like most engineering leaders, the answer is probably uncomfortable. Research from Atlassian shows that 63% of developers now say their leaders don’t understand their pain points, up sharply from 44% just a year ago. That’s not a marginal drift, that’s a crisis of disconnection happening in real time.

And the cost? Developers are losing an entire day each week to inefficiencies that most leaders don’t even know exist.

Why the listening tour beats another AI tool

The irony is rich. While leaders are betting big on AI to boost productivity, they’re missing the fundamental step of understanding where the actual friction lives. Developers aren’t asking for more tools, they’re asking to be heard.

Nicole Forsgren and Abi Noda make this clear in their new book Frictionless: the best way to find developer friction is by asking developers. Not surveying them. Not tracking their metrics. Actually sitting down and listening.

Start with a listening tour. Your goal is to understand your developers software development experience, or as Courtney Kissler, SVP and CIO at Expeditors, says, “Honor their reality.”

Listen without defensiveness or explanations, and remember it’s not your role to judge their reality. Stay curious, asking for details when needed. Note helpful practices, but avoid soliciting solutions, neither you nor they have the full picture yet, and they aren’t thinking like strategic product owners.

This isn’t about being nice. This is about seeing what’s actually broken before you waste another quarter implementing solutions to problems you’ve imagined rather than verified.

The 12-15 developer rule

Here’s where most organizations go wrong: they either talk to too few developers (missing critical perspectives) or approach it haphazardly (getting skewed data).

Forsgren and Noda are specific about this. To be most effective, you’ll want to talk to 12-15 developers. And to ensure you have a representative sample, plan strategically — consider factors such as years of experience, product area, type of development (like legacy, mobile, cloud, data science).

Think about that number for a second. Twelve to fifteen conversations. That’s maybe six hours of your time spread across a few weeks. Six hours to understand where millions of dollars in productivity are leaking out of your organization.

You need two planning lists:

1. Demographics that matter. For example, work location (onsite, remote, hybrid) and experience level (junior or senior devs).

2. Work types and organizational areas where devs work.

These lists help you map out your interview coverage and track who you’ve spoken with. You’ll quickly see if you’re relatively balanced between new hires and long-time employees, but don’t have interviews scheduled with junior devs in platform and legacy teams. That may be intentional, or it might be a simple oversight. Having this visualization helps you spot those gaps and correct them before you make decisions based on incomplete data.

The structure matters. You’re not trying to be exhaustive, you’re trying to be representative. You want to hear from the senior architect who’s been there eight years AND the mid-level engineer who just joined. You want perspectives from the team shipping customer features AND the platform team building internal tools.

What you’ll actually learn

When you actually do this, when you shut up and listen, you discover something uncomfortable: the friction your developers experience often has nothing to do with the problems you thought you were solving.

The research from Atlassian shows the top time-wasters for developers are finding information (services, docs, APIs), adapting new technology, and context switching between tools. Notice what’s not on that list? Coding. Developers only spend 16% of their time actually writing code, and it’s not even registering as a friction point.

So all those coding assistants you’ve invested in? They’re enhancing the experience without actually improving it, because you’ve been optimizing for the wrong 16%.

Meanwhile, the real problems, scattered documentation, unclear service boundaries, constant tool-hopping—go unaddressed. Tech debt, which used to dominate friction surveys, has actually fallen out of the top five issues. Not because it’s solved, but because other problems have gotten worse.

The empathy gap is getting worse

Here’s the part that should worry you: this disconnect between what developers experience and what leaders think they experience is accelerating. Leaders are banking AI-driven time savings while actual friction increases. It’s a false economy where developers are expected to deliver faster while navigating more unaddressed obstacles.

The gap exists because leaders stopped doing the most basic thing: asking. They’re making assumptions based on their own outdated experience of what development felt like when they were writing code, or they’re relying on proxy metrics that tell them everything except what developers actually need.

Let developers know that talking to you is a good use of their time. You can set yourself up for success by sending out short notes introducing yourself and your work and asking for a quick, 30-minute meeting. Depending on the team and organizational culture, these notes will be either well-received or met with skepticism, developers have seen a lot of initiatives come and go.

But here’s what changes the equation: when you actually follow through. When developers see that someone listened, understood, and changed something tangible as a result, the skepticism dissolves. Not because of what you promised, but because of what you delivered.

Your December resolution

This December, while you’re making time for everyone else who matters in your life, make time for the people building your product. Not in a Zoom all-hands. Not through an engagement survey. In actual conversations where you’re there to learn, not to sell them on your roadmap.

Twelve to fifteen conversations. That’s your winter project. Before you plan Q1’s tooling investments, before you finalize next year’s platform roadmap, before you commit to another initiative that developers will silently work around, go understand their reality.

Because the friction you can’t see is costing you more than you think. And the only way to see it is to ask.

Make it count

The best part? You don’t need budget approval for this. You don’t need executive buy-in. You don’t need a consultant. You just need to block time on your calendar and send some emails.

Start with your own team if you’re nervous. Pick three people from different parts of your organization. Ask them what slows them down. Ask them where the process breaks. Ask them what they’d fix if they could wave a magic wand.

Then actually listen. Take notes. Don’t defend. Don’t explain. Don’t problem-solve in the moment.

Just listen.

The gifts you give your developers this season don’t come wrapped in boxes. They come wrapped in attention, understanding, and the promise that someone actually cares about making their work better.

That’s the kind of gift that keeps giving long after January.

Want to dive deeper into how to structure these conversations? Nicole Forsgren and Abi Noda’s “Frictionless” offers a comprehensive framework for discovering and addressing developer friction at every level of your organization. Also don’t miss to download a free workbook with practical exercises and templates to guide your listening tour.

Taking a Winter Break

This is my last post for 2025. I’ll be taking a break over the holidays and will return with fresh content in January.

But I don’t want the conversation to stop here. What topics would you like me to tackle in 2026? Whether it’s a specific developer experience challenge you’re facing, an organizational pattern you’ve observed, or something you’d like a pragmatic take on — I want to hear from it.

Submit your topic idea here and I might write about it in an upcoming post.

A Thank You to My Readers

To everyone who’s read, subscribed, and engaged with these posts over the past few months, thank you. Your support means a lot to me.

As a year-end thank you, I’m offering 70% off on my monthly and annual subscriptions until December 31st. If you’ve been considering supporting this work, now’s the time: Get 70% off your subscription

See you in 2026. Have a great holiday season, and may your on-call rotations be quiet.

Cheers Marcel

When you submit code changes, you wait. The CI/CD pipeline runs its tests. Sometimes it fails in the final stage after hours of processing. You get a cryptic error log. You debug. You resubmit. You wait again.

This is the expensive reality of modern software development. A 2024 research paper from Chalmers University identified this pattern, noting that “developers often seek expedited results from these pipelines”, but the architecture of most CI/CD systems works against this preference.

Now we have data showing the problem is more complex than anyone predicted.

The Real Cost: Time Saved, Time Lost

Atlassian’s 2025 State of Developer Experience survey found that AI is saving developers approximately 10 hours per week. That sounds like unqualified success, until you see the other half of the equation.

The same survey found that 50% of developers report losing 10+ hours per week to organizational inefficiencies, finding information, adapting new technology, and context switching between tools. Developers are saving 10 hours a week with AI and losing 10 hours a week to organizational friction.

We’re right back where we started, except now there’s an illusion of progress.

Most organizations aren’t using AI to address friction points, they’re using it to speed up the parts that weren’t actually bottlenecks. Developers only spend about 16% of their time coding, and coding isn’t their primary friction point. Yet that’s where most AI investment goes.

The Trust Problem

Developer sentiment tells another part of this story. Positive sentiment for AI tools has decreased in 2025 to just 60%, down from over 70% in both 2023 and 2024. More developers now actively distrust the accuracy of AI tools (46%) than trust it (33%).

Experienced developers are the most cautious, with only 2.6% reporting they “highly trust” AI output and 20% reporting they “highly distrust” it. This widespread understanding that AI outputs require human verification explains why experienced developers often slow down—they’re doing additional verification work.

As Salvatore Sanfilippo observed, while LLMs can write parts of a codebase successfully under strict supervision, “when left alone with nontrivial goals they tend to produce fragile code bases that are larger than needed, complex, full of local minima choices, suboptimal in many ways”.

What Actually Works: CI/CD Integration

Despite the challenges, some applications show genuine promise. The vision of LLMs embedded in CI/CD pipelines has moved from theory to practice.

Tools now embed LLM-powered code reviews into CI/CD workflows, ensuring code quality checks happen automatically with every commit. One finance company reduced build failures by 47% after implementing LLM-based self-healing pipelines, with engineers saving 7.5 hours weekly.

Faire’s implementation of automated code reviews demonstrates how this works in practice. They use LLMs to automate generic review requirements, the checks that don’t require deep project context but do consume reviewer time. This frees human reviewers to focus on architectural decisions and whether code actually meets product requirements.

The difference? Integration into existing workflows rather than standalone tools, focus on organizational friction points rather than individual productivity, and automation of repetitive checks rather than replacement of human judgment.

Log Analysis: Where AI Actually Excels

One area where AI demonstrates clear value is log analysis, exactly what the Chalmers research identified as a key opportunity.

Recent studies show LLMs achieve an F1-score of 0.928 for vulnerability detection in log analysis, significantly outperforming traditional models like XGBoost (0.555) and LightGBM (0.432).

IBM’s production deployment provides real-world validation. By December 2024, their LLM-based log analysis tool had processed 1,376 cases, handling 877 GB of data and 1.04 billion log lines. Among respondents, 53.79% found the tool beneficial, and 60.4% of products reported saving at least 30 minutes per trigger.

Why does log analysis work when other applications struggle? Three factors: defined scope with clear inputs and outputs, natural language advantage since logs are semi-structured text, and straightforward verification paths.

The Learning Curve Nobody Discussed

The METR study found that three-quarters of participants saw reduced performance when using AI tools. However, one of the top performers with AI had the most previous Cursor experience. The paper acknowledges: “it’s plausible that there is a high skill ceiling for using Cursor, such that developers with significant experience see positive speedup”.

Amazon’s experience with their Q coding assistant tells a similar story. After significant improvements in April 2025, about half of developers found it genuinely helpful, but it still has limitations, including understanding only one file at a time. Interestingly, models fine-tuned on Amazon’s own massive codebase “feel only moderately better than non-trained models”.

Effective AI-assisted development requires significant practice with specific tools, understanding of tool limitations, workflow integration rather than skill replacement, and context management most developers haven’t mastered.

The Empathy Gap

Perhaps most concerning: 63% of developers now say leaders don’t understand their pain points, up sharply from 44% in 2024.

This widening empathy gap explains why AI deployment often misses the mark. Leaders see developers using AI and assume productivity is improving. Developers experience the slowdown, the verification work, the context-switching overhead—but their perception doesn’t match reality.

The JetBrains 2025 Developer Ecosystem survey found that 66% of developers don’t believe current metrics reflect their true contributions. While tech decision-makers dream of reducing technical debt, developers want transparency, constructive feedback, and clarity of goals.

Internal collaboration, communication, and clarity are now just as important as faster CI pipelines or better IDEs. Yet organizations continue to invest primarily in the latter.

What This Means for Engineering Leaders

Measure what matters: If developers take longer with AI but believe they’re faster, your productivity metrics aren’t capturing reality. Time-to-completion matters, but so do code quality, maintainability, and developer confidence.

Focus on friction, not features: Developers lose time to finding information, adapting new technology, and context switching, none of which AI coding assistants address. The time saved writing code gets consumed by organizational inefficiency.

Integration over innovation: The most successful AI deployments integrate into existing workflows. Faire’s automated code reviews work because they happen within the pull request process developers already use.

The learning curve is real: Don’t expect immediate productivity gains. Developers need significant experience with specific AI tools before seeing benefits. Budget for training time.

Trust the skeptics: Experienced developers are the most cautious about AI tools—and they’re often right to be. Their skepticism reflects understanding of where AI helps and where it introduces problems.

The Path That Actually Works

Read more

This isn’t another article explaining the interruption problem, this is the playbook for what to do when you’re surrounded by people who genuinely believe their requests justify breaking your focus. What follows are the specific tactics, scripts, and systems that work when good intentions collide with the need for uninterrupted thinking time.

The central challenge isn’t technical. Everyone interrupting you thinks they’re the exception. Your stakeholder’s deadline is real. Your manager’s question seems time-sensitive. Your colleague’s blocker feels urgent. They’re not being unreasonable, they’re operating in an environment that’s trained them to treat immediacy as importance.

The Three-Layer Defense System

Protecting focus time requires defense in depth. One-off tactics fail because your environment constantly pressure-tests your boundaries. You need three layers: structural defenses that prevent most interruptions, communication protocols that route the rest appropriately, and tactical responses for exceptions.

Most focus time advice stops at the tactical layer - giving you scripts without the infrastructure to make them work. That’s why you feel like you’re constantly negotiating instead of doing your job. The real leverage is in the first two layers.

Layer One: The Calendar Architecture That Actively Defends

Your calendar should be an active defense system, not a passive record of how your time gets stolen.

The Focus Block Template

Create recurring blocks with these specific properties:

• Title: “Deep Work: [Specific Task]” not “Focus Time” or “Busy” - specificity creates accountability

• Visibility: Public so people see what you’re working on, but “Show as Busy” to discourage invites

• Auto-decline: If supported (Google Workspace and Outlook both do), enable automatic meeting decline

• Duration: Minimum 90 minutes - shorter blocks are optimistic theater given it takes 30-60 minutes to enter flow state

The Two-Block Daily Minimum

Schedule blocks during your biological peak hours. For most developers: one morning block (9-11 AM) and one afternoon block (2-4 PM). University of Calgary research found that developers who face frequent interruptions show signs of mental fatigue much earlier, leading to more afternoon errors. Your afternoon focus block isn’t just about productivity - it’s about code quality.

The Office Hours Buffer

Here’s the piece most advice misses: schedule 30-minute “office hours” blocks immediately after each focus block. This gives you designated time to handle queued questions and gives others a specific answer (”I’m checking messages at 11:30 and 4:30, can it wait until then?”).

Post these everywhere: Slack status, email signature, team wiki, team calendar as public events. Make them impossible to claim you didn’t communicate.

The Meeting Firewall

Configure your calendar tool aggressively:

• Set working hours that match actual availability for meetings (10 AM-12 PM, 1 PM-4 PM)

• Enable 15-minute buffers before and after meetings

• Mark focus blocks as “Private” or “Out of Office” depending on auto-decline capabilities

Result: people scheduling meetings see limited availability, naturally pushing routine conversations async or to office hours.

Layer Two: The Communication Routing That Encodes Urgency

Development teams have created informal hierarchies of communication tools, chat for immediate needs, ticketing for structured work, email for non-urgent items. Make this explicit and non-negotiable.

The Channel Protocol

Define and publish to your entire team:

• Production alerts/PagerDuty: Immediate response required

• Direct phone call: True emergency blocking work right now

• Slack @mention with “URGENT”: Response within 2 hours (usable once per week maximum)

• Slack @mention (no URGENT): Response by end of business day, triaged during office hours

• Slack without @mention: Response when convenient, typically next business day

• Team ticket/PM tool: Triaged during sprint planning or standups

• Email: 24-48 hour response time

The Team Agreement

This only works with explicit commitment. Call a team meeting and get agreement on:

1. The channel hierarchy

2. What constitutes “urgent” (production down, security issue, blocker for today’s ship date - that’s it)

3. Consequences for misusing urgent channels

Document in your team handbook. Reference every time someone violates the protocol.

The Async-First Default

Before any synchronous communication, ask: “Could this be a doc comment, PR comment, or ticket update?” Create templates for common patterns:

• Estimate requests → Standard form with context, constraints, timeline

• Design feedback → Shared doc with comment threads

• Status updates → Automated from PM tool

Make async easier than sync for routine requests.

Layer Three: Tactical Scripts for When People Bypass Your System

Even with strong defenses, you’ll face situations where someone goes around the system. You need responses that protect focus while preserving relationships.

These scripts work because they do three things: acknowledge the request, propose an alternative, create an emergency escalation path.

For Slack Interruptions During Focus

“I’m in a focus block for the next 90 minutes on [specific task]. If production-critical, call my phone. Otherwise, picking this up at [specific time].”

Variation for managers: “Want to give this proper attention rather than rushed response. Deep in [task] until 2:30 - can I get back by 3:00 with complete answer?”

For In-Person “Got a Minute?” Interruptions

“I’m mid-task and will lose context if I stop. Drop it in Slack with details? Checking there at [time].”

If they press: “What’s the blocker if this waits 90 minutes? If it’s blocking deploy or production, let’s tackle now. Otherwise, I’ll lose an hour on [task] if I context-switch.”

For Meeting Requests During Protected Time

“Have this blocked for deep work on [task]. Can we solve async first via [doc/Slack thread]? If we need sync after, I’m open from [alternatives].”

If they insist: “To be transparent, moving this delays [deliverable] by [timeframe]. If [their topic] is more urgent than [your deliverable], I can shift - want to make that trade-off consciously.”

For “Quick Estimate” Requests

“Quick estimates tend to be wildly inaccurate. Can give you a range now with low confidence, or proper estimate in [timeframe] after thinking through dependencies. Which helps your planning more?”

For Colleagues Claiming Blocked Status

“Walk me through what you’ve tried and the specific error. Share in Slack with screenshots and I’ll troubleshoot at [time].”

If they’ve tried nothing: “Start with [documentation/runbook]. Most issues are covered there. Still stuck after checking? Ping me with what you tried and where it failed.”

For Leadership “Quick Feedback” Requests

“Can give gut reaction now or considered analysis after this focus block at [time]. Difference is probably 60% confidence versus 90%. Which do you need?”

For Product Prioritizing Their Feature

“Currently on [task] shipping [date]. If [their feature] is higher priority, I can switch, but [current task] slips to [new date]. Want to confirm that trade-off with [stakeholder] before switching?”

The Four-Step Implementation Playbook

Read more

Stop right there.

Subscribe now

I get it. The temptation is real. You’re this close to shipping, and suddenly everyone has brilliant ideas about what would make the product truly shine. Your CEO wants one more integration. Your lead engineer sees an opportunity to refactor “while we’re in there anyway”. Your product manager discovered a competitor feature you “absolutely must have”.

This is how launches die. Not with a bang, but with a whimper of “just one more thing”.

The Math Nobody Wants to Do

Let’s talk numbers, because feelings lie but data doesn’t.

Sonar’s research examining over 200 projects found that technical debt costs $306’000 annually for every million lines of code, which equals 5’500 developer hours spent on remediation instead of innovation.

Every “quick feature” you jam in before launch isn’t free. It’s a loan you’re taking out against your team’s future productivity, and the interest compounds faster than you think.

Only 55% of product launches happen on schedule, and delayed products miss their internal targets 20% of the time. Even worse? A six-month launch delay costs companies 33% of expected revenue.

That “must-have” feature isn’t just delaying your launch. It’s actively destroying value.

Scope Creep Is the Silent Killer of Product Launches

Here’s what actually happens when you add “just one more feature”:

You think you’re adding a week of work. But feature creep in complex technical projects can trigger 18-month delays and 40% budget overruns. The infamous Denver International Airport baggage system suffered over 2’000 design changes that turned the project into a cautionary tale.

This isn’t about perfectionism versus pragmatism. It’s about understanding that nearly 50% of projects now experience scope creep, and that percentage is climbing, not falling.

Every addition triggers a chain reaction. Your “simple” feature needs integration testing with existing systems. It needs documentation updates. It needs QA cycles for edge cases. It needs deployment procedures. It needs support team training.

What looked like a three-day task becomes a three-week nightmare. Your launch date evaporates. Team morale craters. And your competitors ship while you’re still arguing about implementation details.

Why “Just Ship It” Also Backfires

Now, some of you are thinking: “Fine, I’ll just ship whatever we have and fix it later”.

Also wrong.

The “ship it and iterate” gospel has created its own problems. Yes, Reid Hoffman famously said you should be embarrassed by your first version. But that advice gets weaponized into shipping genuinely broken products that damage your reputation before you’ve built one.

There’s a spectrum here. On one end, you’ve got perfectionist paralysis that prevents you from ever launching. On the other, you’ve got reckless shipping that burns through user goodwill faster than you can acquire users.

The sweet spot? Ship something focused that actually works.

Organizations with high technical debt spend 40% more on maintenance and deliver features 25-50% slower than competitors. That “move fast” culture becomes “move slow and break things” real quick.

The Holiday Crunch Amplifies Everything

Right now, as you read this, you’re probably in the worst possible position to make good decisions about scope.

End-of-year targets. Holiday parties. People taking time off. The pressure to “finish strong” and prove the year wasn’t wasted. Everyone’s tired, burned out, and desperate to show progress.

This is exactly when teams make catastrophic calls. You add features to justify the timeline slip. You skip proper testing because “we’ll catch it in January”. You compromise on architecture because “we just need to get this out”

The features you’re considering adding right now, in November, under deadline pressure, with half your team already mentally checked out for the holidays, are the technical debt you’ll be paying off all of next year.

What Actually Works

Here’s the contrarian take: the best thing you can do before launch is cut scope, not add to it.

Read more

The concept is simple yet profound: when best practices become the path of least resistance, teams naturally “fall into” success. Spotify doubled deployment frequency. Netflix reduced test cycles from 62 minutes to under 5 minutes. Atlassian achieved 100% security scanning coverage while reducing critical vulnerabilities by 39%. These examples show what’s possible when teams align their systems with developer needs, evidence that when best practices are frictionless, measurable improvement tends to follow.

This article covers proven strategies from Google, Netflix, Stripe, Spotify, and other leading companies, examining the specific tools, tactics, and design principles that reduce friction while elevating quality. The findings reveal a consistent pattern: organizations that invest heavily in developer productivity don’t just move faster, they build better software with happier teams.

Designing for the Pit of Success

Rico Mariani, a performance architect at Microsoft, coined the term “Pit of Success” around 2003 to describe a radical design philosophy: build platforms where developers simply fall into winning practices. As he wrote, “We want our customers to simply fall into winning practices by using our platform and frameworks. To the extent that we make it easy to get into trouble we fail”.

This inverts the traditional approach to software quality. Instead of requiring heroic effort to write good code, the system makes it nearly impossible to write bad code. The pattern extends far beyond language design—Netflix’s Wall-E platform makes security and compliance part of the default service setup, automating practices that once required manual checks.

Alan, a French digital health-insurance platform, embedded “Falling into the pit of success” as a core engineering principle, even creating a Slack emoji to keep the concept culturally present. The philosophy spreads beyond just tooling to influence hiring, architecture decisions, and process design.

The contrast illuminates the power of this approach. In a “Pit of Despair”, developers constantly risk falling into traps, manual configuration errors, security vulnerabilities from using default settings, or performance issues from following standard patterns. Teams spend enormous energy climbing out of holes. But in a Pit of Success, gravity works in your favor.

New developers make fewer mistakes. Senior developers move faster. Quality improves not because people try harder, but because the system guides them.

Golden Paths and Paved Roads to Effortless Best Practices

Spotify and Netflix independently arrived at the same insight, though they use different names for it. Spotify calls it the “Golden Path”, an opinionated, well-documented, supported way to build software. Netflix calls it the “Paved Road” a formalized set of commitments between platform teams and engineering teams. Both describe the same fundamental concept: create workflows so polished and efficient that deviation becomes unappealing.

The implementation details matter enormously. Back in 2017 Netflix built a complete Platform-as-a-Service with standardized components: RPC, service discovery, monitoring, logging, all pre-assembled and version-compatible. Their tool bootstraped projects with relevant hooks, CI integration, and desktop setup.

Spotify’s approach centered on Backstage, an open-source developer portal that houses their Golden Paths. The platform provides software templates for creating new services with best practices pre-configured, a software catalog tracking all components with metadata, and integrated documentation following a docs-as-code approach.

Red Hat’s definition captures the essential characteristics of effective Golden Paths: they must be optional (not mandatory), transparent (developers understand what happens under the hood), extensible (adaptable when needed), and minimal in cognitive load. The critical success factor is treating Golden Paths as products, not mandates. When platform teams use product thinking—user research, roadmaps, feedback loops, internal marketing—adoption mostly follows naturally.

The approach works when workflows are repetitive and high-frequency, best practices are well-established, and the majority of teams share similar needs. It fails when implemented as “Golden Cages”, rigid, one-size-fits-all solutions with no escape hatches.

Real-world impact through measurable returns from reduced friction

The business case for making the easy path the right path rests on hard numbers, not aspirations. A Forrester Total Economic Impact study commissioned by Cortex reported a composite organization achieving 224% ROI over three years, with a six-month payback period. While vendor-commissioned, the study’s methodology was based on interviews with four organizations and provides insight into the scale of potential returns.

Etsy’s transformation from weekly deployments (often with downtime) to continuous deployment tells a compelling story about cultural and technical change. In 2012, they executed 6,419 production deployments—averaging 25 per workday and 535 per month—with 196 different people deploying to production. They run 14,000 tests daily. The journey took two years and required comprehensive monitoring with Graphite and StatsD, feature flags for safer deployments, automated CI/CD pipelines, and a blameless postmortem culture. The key insight: small, frequent changes reduce risk more than large, infrequent ones.

Netflix achieved a 92% reduction in test cycle time through Test Distribution and Developer Productivity Engineering (DPE) techniques. Tests that took 62 minutes now complete in under 5 minutes by parallelizing execution across scalable cloud pools and automating feedback cycles. The analysis revealed that 90% of build time was spent in tests, making this the highest-impact optimization area. The ROI proved immediate because commoditized cloud compute costs far less than expensive engineering time.

Salesforce tackled a different problem at massive scale with their TF Triage Agent, an AI-powered system for automated test failure analysis. Processing 6 million tests daily with 78 billion combinations, handling 150,000 test failures per month and 27,000 changelists per day, the system provides developers with concrete recommendations within seconds about which code changes likely caused failures. The phased rollout from a 20-person team to 500+ engineers delivered a 30% reduction in test failure resolution bottlenecks. The key to success: concrete recommendations beat speculative AI outputs, and integration with Salesforce-specific data improved accuracy.

Toyota Motor North America’s Backstage implementation generated $10 million in savings in 2022 through standardization at enterprise scale. A financial services company with over $1.71 Trillion in assets headquartered in San Francisco, California using ACCELQ for Microsoft Dynamics 365 test automation reduced regression script generation time by 75% (from 16 hours to 4 hours) while achieving 80%+ test reuse through modularity.

Rapid feedback loops turn testing into the faster option

The mathematics of developer productivity center on feedback loops.

Claroty Engineering’s journey from 20+ minute pipelines to under 10 minutes offers a blueprint for optimization. They profiled bottlenecks using cProfile and SQLTap, ran faster static tests (linters, type checks) before expensive integration tests, implemented fail-fast with pytest -x to stop at first failure, used RAMFS to run databases in memory (doubling test speed), split jobs across isolated AWS environments using GitLab’s parallel feature, and optimized database operations—truncating tables instead of dropping/recreating achieved an 82% speed improvement.

CircleCI’s performance benchmarks against GitHub Actions reveal the impact of infrastructure choices. CircleCI executes pipelines 40.29% faster at median compared to GitHub Actions default runners, and 2.09% faster even against GitHub’s larger runners despite using less RAM. More dramatically, CircleCI shows 90.13% less queuing than GitHub Actions default and 99.12% less than larger runners, with consistent sub-30-second queue times under load versus 22+ minute waits on GitHub Actions.

The pattern across successful implementations is consistent: caching dependencies saves 5-10 minutes per build, parallel execution splits test suites to run simultaneously, Claroty’s smart test selection runs only affected tests, and cloud-based platforms like BrowserStack and LambdaTest provide 3500+ real browsers and devices for parallel cross-browser testing. Patrick Koss documented reducing CI time from 15-20 minutes to 3-4 minutes through caching (Golangci-Lint, dependencies, Docker layers), parallel execution, and optimized resource allocation.

Shift-left done right so security never slows teams down

Security traditionally operated as a gate at the end of development, creating adversarial relationships between security teams and developers. Modern approaches shift security left into the development process itself, but success requires making security scanning faster and more helpful than skipping it.

Snyk’s integration with Atlassian demonstrates the power of this approach. Atlassian reached 100% container scanning coverage across the organization while reducing high-severity vulnerabilities by 65% and critical-severity vulnerabilities by 39%, all within a few months. The implementation automated scanning during deployment events and created tickets with metadata on severity and priority scores. Atlassian chose Snyk specifically because it proved “easier for developers to integrate into their pipelines”.

The shift-left philosophy succeeds when it follows five principles: integrate at code time (scan before commit/push), use native environments (results in IDE or PR, not separate portals), provide actionable feedback (tell developers what to fix and how), automate policy (policy-as-code sets guardrails without manual gates), and deliver fast feedback (sub-second to seconds, not minutes).

Real implementations follow a common pattern. IDE integration catches issues as code is written through plugins. Pre-commit hooks run quick checks before code leaves the developer’s machine. PR automation runs full scans on pull requests with findings in comments. Policy gates block merges on critical/high issues only, not all findings. Scheduled deep scans run full DAST and penetration tests regularly. Production monitoring provides runtime protection through RASP and IAST.

The cultural transformation proves as important as the technical implementation. Breaking down silos between security and development teams, making security enable rather than block innovation, building “security fluency” for developers without making them experts, adopting shared responsibility models, and maintaining observability for continuous improvement, these organizational changes determine whether tools actually reduce friction or simply create new bottlenecks.

Platform engineering means treating internal tools as products

The most profound shift in modern developer experience comes from treating internal platforms not as cost centers or IT infrastructure, but as products with developers as customers. This mental model transformation changes everything about how platforms are built, measured, and evolved.

Read more

Read more

Take lines of code. Easy to measure, feels important, every platform provides data. So teams track it religiously. The problem? LOC tells you nothing about value delivered. You can optimize LOC by writing verbose, repetitive code, but you haven’t improved developer experience. You’ve just gamed a metric.

Developer experience is multidimensional. As researchers Nicole Forsgren and colleagues discovered developing the SPACE framework, productivity encompasses satisfaction and well-being, performance outcomes, activity levels, communication patterns, and flow states. Tr…

Read more

Here’s what I’ve learned: code review problems are rarely about the review process itself. They’re symptoms of deeper issues in how your team works.

What Actually Happens When a PR Lands

Let’s be honest about the reality. You open a PR and see 47 files changed, 1,200 lines added. The description says “fixes issue #347” with no context. You don’t know what issue #347 is without opening three other tabs. The code touches a part of the system you’ve never worked on. There are no tests, or the tests exist but you can’t tell what they’re validating.

Now multiply this by five other PRs in your queue, your own feature branch getting stale, and the production incident from this morning that needs a postmortem.

The problem isn’t that you’re slow at reviewing code. The problem is that reviewing this code properly would take longer than writing it from scratch, and everyone knows it. So the PR sits there radiating guilt while you both pretend you’ll get to it “tomorrow”.

Why Standard Solutions Don’t Work

The common code review practices aren’t inherently bad, they’re just incomplete. They treat symptoms without addressing root causes.

Smaller PRs are genuinely helpful when your architecture supports incremental delivery. But if your monolith has tight coupling everywhere, breaking work into smaller chunks becomes artificial. Developers either create PRs that can’t be understood without the next three in the sequence, or they give up and submit large PRs anyway.

Review SLAs can work when paired with quality metrics. The dysfunction happens when you measure speed without measuring depth. Teams start optimizing for “time to approval” and reviews become perfunctory rubber stamps. You’ve created an incentive for fast, shallow reviews instead of thorough ones.

Automated review assignment solves the diffusion of responsibility problem but creates a new one: context mismatch. You’re systematically assigning context-heavy work to people who lack context. This works with strong ownership models where automation routes PRs to the right domain owner, but fails with truly random assignment.

Mandatory approvals from two reviewers adds thoroughness but also coordination overhead. It can create a tragedy of the commons where everyone assumes someone else will do the deep review. This works well for critical paths like security or infrastructure changes, but becomes counterproductive when applied universally.

The pattern is clear: these practices fail when applied as process band-aids over systemic dysfunction. They succeed when they’re part of a broader system that includes clear ownership, shared context, and good architecture.

Code Review as a Diagnostic Tool

Here’s the uncomfortable truth: code review is a stress test for your engineering system. Every slow PR is a signal about deeper problems.

When PRs lack context, it reveals you don’t have a shared understanding of what you’re building or why. The product requirements were vague, the technical approach was never discussed, and now the reviewer is doing archaeology just to understand intent.

When PRs are too large to review, it reveals your architecture doesn’t support incremental delivery. You can’t ship smaller chunks because everything is coupled. The technical debt you’ve been deferring is now review debt.

When no one feels qualified to review, it reveals knowledge silos and single points of failure. You’ve got one person who understands authentication, another who owns the data pipeline, and they’re both overloaded. The review queue is just where this becomes visible.

When reviews turn into architecture debates, it reveals you don’t have clear technical direction. Every PR becomes an opportunity to renegotiate decisions that should have been made months ago, especially when the same patterns get questioned repeatedly.

When reviews focus on style over substance, it reveals that reviewers don’t have enough context to evaluate the actual logic, so they retreat to what they can evaluate: formatting, naming conventions, and other surface-level concerns that a linter should handle.

The Ownership Gap

Teams with clear ownership have faster code reviews. Not because they’ve optimized the review process, but because ownership solves the underlying problems.

When a developer owns a service or domain, they write code differently. They document decisions, maintain architectural consistency, and respond to reviews quickly because it’s their responsibility, not a favor. They review incoming changes thoroughly because they’ll be maintaining this code.

But ownership is tricky. It’s not about assigning people to components on a chart. It’s about giving developers the autonomy to make decisions, the responsibility to maintain their domain, and the accountability for outcomes. That’s a cultural shift, not a process change.

Netflix’s “freedom and responsibility” works because ownership is real. Developers ship changes to production with minimal gates because they own the consequences. Code review becomes about knowledge sharing and catching genuine issues, not permission seeking.

Contrast that with environments where ownership is performative. Someone is “responsible” for a service but needs approval from architecture review boards, security teams, and product managers to make any meaningful change. The code review becomes another checkpoint in a gauntlet of approvals. Of course it’s slow.

The Context Problem

Let me tell you about the most frustrating code review I ever had to do. A PR touched a critical system component. The code looked fine—clean implementation, good tests. But I had no idea if the approach was right because I didn’t know what problem we were solving.

I found the related ticket with a brief description and no context. Nothing about why this mattered, what constraints we were working under, or what trade-offs had been considered. I pinged the author on Teams. They pointed me to a Confluence page from a meeting I wasn’t in that assumed knowledge of a discussion I’d never heard about.

I spent two hours reconstructing context just to give a meaningful review. The author had spent 30 minutes writing the code.

This is the context tax, and it’s killing your review velocity. Every reviewer who lacks context either spends hours on archaeology or does the worse thing: approves without understanding.

The solutions that work aren’t about the review process. They’re about information architecture. Link PRs to rich context, not just ticket numbers. Write PR descriptions that explain the problem, the approach, and the trade-offs. Assume the reviewer knows nothing.

Discuss approaches before implementation. A 15-minute conversation before coding can eliminate hours of review back-and-forth. This is what design docs and RFCs are for, but they only work if they’re lightweight and living documents, not bureaucratic artifacts.

Record decisions where the code lives. Architecture Decision Records aren’t overhead if they prevent you from having the same debate six times across different PRs. Make tribal knowledge discoverable. If understanding this PR requires knowing about the customer escalation from Q3 2024, write that down somewhere that isn’t someone’s head.

The Interrupt-Driven Review Problem

Here’s a pattern I see often: developers treat code review as an interrupt-driven task. A notification comes in, you context-switch from your work, skim the PR for 5 minutes, leave a comment, then try to get back to what you were doing. Your flow state is destroyed, and the review is mediocre because you never built a mental model of what the code is doing.

This is the worst of both worlds. The reviewer loses productivity to context-switching. The author gets superficial feedback that misses real issues but catches nitpicks. Then in production, you discover the actual problem that no one caught because reviews were done in interrupt-driven bursts.

The alternative isn’t to batch reviews once a week—that’s too slow. It’s to treat code review as real work that deserves dedicated time and focus.

Some teams have “review hours” where the expectation is that you’re doing reviews, not writing code. No meetings scheduled, chat on pause, full attention on understanding what someone built. The reviews are higher quality, they happen faster, and developers can actually schedule around them.

Others use pair or mob programming to eliminate the review bottleneck entirely. The review happens continuously as you’re writing the code. This works brilliantly for some teams and feels painfully slow for others. The point isn’t that everyone should pair program. The point is that you need to match your review process to how your team actually works.

When Reviews Become Performance Theater

Let’s talk about what happens when code review becomes about looking busy rather than being useful.

You’ve probably seen PRs with dozens of comments about formatting, naming, and other minutiae, while no one questions whether the approach is sound. Reviews that take days but offer no substantive feedback. Approvals given without actually reading the code because everyone knows the author will clean it up anyway.

This happens when review metrics become targets. When “number of comments” or “time to approval” get tracked, people game them. You get what you measure, and you’ve measured the wrong things.

The better question is: are we catching issues before production? Are developers learning from reviews? Is code quality improving over time? Those are harder to measure, so teams fall back to vanity metrics that drive counterproductive behavior.

I’ve also seen the opposite problem: reviews that become nitpick festivals. Every PR gets 30 comments about variable names and formatting. The author feels demoralized. The reviewer feels righteous. The code barely improves. Everyone is frustrated.

This usually happens when developers don’t feel they have more meaningful ways to contribute. If you can’t influence architecture or push back on product decisions, you can at least enforce the style guide. It’s busywork disguised as quality assurance.

The fix isn’t better tools or stricter guidelines. It’s giving developers real agency over their work and clear standards for what actually matters in a review.

The Async Communication Challenge

Code review is fundamentally async communication, and it exposes a truth most teams don’t want to face: we want the benefits of async—flexibility, time to think, no meeting overhead—without paying the upfront cost of making async work well.

Author submits a PR. Reviewer comments the next day. Author responds, but now the reviewer is in meetings all afternoon. They respond the following morning. Author makes changes, but now the reviewer is working on something else and doesn’t see the update for another day. What should have been a 30-minute conversation stretched over four days with maybe two hours of actual work.

Compare this to a synchronous code review where author and reviewer jump on a call, walk through the changes in 15 minutes, make decisions in real-time, and finish. This is faster, but it doesn’t scale. You can’t interrupt people for synchronous reviews every time.

The teams that do async reviews well have figured out how to front-load context and reduce round-trips. They write detailed PR descriptions. They proactively address obvious questions. They use inline comments to explain non-obvious decisions. They treat the PR description like a mini design doc.

They’ve also figured out when to go synchronous. If a PR has more than two rounds of back-and-forth in comments, jump on a call. That’s the signal that async isn’t working for this particular review.

A Framework for Actually Fixing This

Here’s how to diagnose whether your code review problems are process issues or symptoms of deeper dysfunction.

Read more

That hardcoded configuration value sitting in your codebase? It’s not sending monthly reminders about how much time it costs every deployment. The integration you copied and pasted into three different services? It’s not calculating compound interest on the bugs you’ll need to fix in triplicate when something changes.

Here’s a sobering statistic: research shows that on average, 25% of development effort gets spent dealing with technical debt issues. That’s one out of every four hours your team works. Not building features. Not fixing customer-reported bugs. Just paying interest on past decisions.

When you take on technical debt intentionally (shipping a feature quickly to test market demand, for instance), you’re making a calculated trade. The problem is most technical debt isn’t intentional. It emerges from the gap between what you knew when you wrote the code and what you know now.

The Four Types of Technical Debt

Martin Fowler created a useful framework for thinking about this, called the Technical Debt Quadrant. It categorizes debt along two dimensions: whether it’s deliberate or inadvertent, and whether it’s reckless or prudent.

Reckless and deliberate debt happens when teams knowingly cut corners without considering consequences. “We don’t have time for design” shipped under deadline pressure with no plan to fix it.

Reckless and inadvertent debt comes from lack of knowledge. Junior teams building systems without understanding design patterns, creating problems they don’t even recognize as problems.

Prudent and inadvertent debt is what you learn by doing. You made the best decision you could with the information available, and only now (after building it) do you understand what you should have done differently.

Prudent and deliberate debt is the strategic kind. You know you’re taking shortcuts, you’ve weighed the tradeoffs, and you have a plan to address it. “We need to ship this MVP to validate the market, then we’ll refactor once we have funding”.

The issue is that most organizations treat all debt the same way, when these different types require completely different management approaches.

Consider this scenario: A junior engineer inherits a codebase with a cryptic comment: “DO NOT MODIFY - talks to legacy billing system”. Nobody remembers why. The person who wrote it left two years ago. The billing system was replaced eighteen months ago. But the warning remains, and with it, all the architectural decisions built around a constraint that vanished.

The debt compounds silently. Unlike financial debt, nobody’s tracking the balance until something breaks.

How Organizations Are Designed to Create Debt

Let me show you how this plays out. An engineer proposes refactoring a critical but fragile system. The work will take three weeks and deliver zero new features. Meanwhile, the roadmap has six features stakeholders are waiting for.

What happens next? The engineer who ships those six features gets recognized in the all-hands meeting. The engineer who prevented future incidents through careful refactoring gets nothing. You can’t celebrate disasters that didn’t happen.

Now extend this pattern across quarterly reviews, promotion cycles, and annual planning. What behavior gets rewarded? Shipping visible things. What behavior gets ignored or penalized? Investing time in invisible improvements.

Research confirms this intuition. Studies of technical debt across organizations consistently identify deadline pressure as the single most cited cause. The top three effects? Delivery delays, low maintainability, and constant rework. The very outcomes teams are trying to avoid by taking shortcuts are the outcomes they guarantee by taking them.

This raises an interesting point about job mobility. In a typical two to three year tenure at a company, you can easily ship code in year one and leave before the consequences arrive in year three. You’re incentivized to optimize for the demo, the launch, the promotion case. Not for the developer who’ll curse your name in 2027.

That’s not malice. It’s rational response to incentives.

Why Teams Can’t Talk About Technical Debt

Pay attention to how your team talks about technical debt. The language reveals deeper cultural problems.

In many organizations, acknowledging debt feels like confessing failure. “We need to fix this mess” carries an implicit “we screwed up”. This framing makes honest conversation impossible. The most damaging teams treat technical debt as a moral failing. Code is either “good” or “bad.” Developers who write imperfect code are careless or incompetent.

This creates a culture where everyone pretends their code is perfect, debt accumulates in silence, and nobody asks for time to fix anything because asking feels like admitting you’re not good enough.

Here’s what healthier teams recognize: all code is written under constraints. Time, knowledge, requirements, available tools. The code you wrote last year reflects what you knew last year. It’s not bad code. It’s old code.

That difference is profound. One framing breeds shame and hiding. The other breeds learning and improvement.

But even well-intentioned teams fall into linguistic traps. Calling it “technical debt” at all implies it’s the engineering team’s problem. In reality, it’s an organizational problem. Product managers who insist on impossible timelines create debt. Executives who refuse to invest in infrastructure create debt. Sales teams who promise custom features create debt. Yet the word “technical” assigns ownership to the people with the least power to prevent it.

The Hidden Hierarchy of Software Work

Let me describe a pattern you’ve probably seen. In most organizations, there’s a clear status hierarchy:

• Building new products: prestigious

• Adding features: valuable

• Maintaining existing systems: thankless

• Fixing old code: what you do when you’re not trusted with important work

This hierarchy pervades everything. Job postings celebrate “building from scratch”. Interview questions focus on greenfield design. Promotion packets highlight new systems launched. Meanwhile, the engineer who spent six months making the payment system reliable enough that nobody thinks about it? They get passed over because their work is invisible.

Technical Debt Lives Everywhere, Not Just in Code

Here’s another dimension to this: technical debt doesn’t just live in code. Research has identified at least ten distinct types of debt that accumulate across a system:

Design debt refers to architectural shortcuts and structural compromises. That microservice you made a monolith “just for now” because breaking it apart was too complex.

Code debt is the classic type—duplicated logic, tight coupling, complex functions that nobody wants to touch. The stuff that makes developers groan during code review.

Test debt accumulates when you skip writing tests or let your test suite become outdated and brittle. Every deploy becomes a gamble.

Documentation debt happens when your docs lag behind reality. The onboarding guide that references systems you deprecated six months ago. The API documentation that describes endpoints that don’t exist.

Infrastructure debt builds up when your deployment pipeline, monitoring, or server architecture can’t scale with your business. You’re still manually deploying because automating it keeps getting postponed.

Requirements debt emerges from partially implemented features or requirements that work for some cases but not others. The edge cases you said you’d handle “later.”

Architecture debt (distinct from design debt) involves fundamental technology choices that are now outdated or unsuitable. You’re stuck on an old framework version because upgrading would break everything.

The problem is that teams often only recognize and track code debt, treating it as the only “real” technical debt. Meanwhile, documentation debt makes onboarding take weeks instead of days. Test debt makes every release nerve-wracking. Infrastructure debt means your deploy process takes hours instead of minutes.

All of this debt is interconnected. Poor documentation makes it harder to refactor code. Lack of tests makes architectural changes risky. Infrastructure limitations prevent you from adopting better development practices.

Why Rewrites Almost Always Fail

When debt becomes sufficiently painful, teams reach for the most seductive solution: rewrite everything from scratch.

“This time”, they tell themselves, “we’ll do it right. We’ve learned from our mistakes. We understand the requirements now. The new version will be clean, fast, and maintainable”.

The rewrite almost never delivers on this promise. Joel Spolsky called rewriting from scratch “the single worst strategic mistake that any software company can make”, and yet teams make it constantly.

Want a historical example? The Year 2000 problem, where thousands of systems stored dates as two digits to save memory. What started as a reasonable optimization in the 1960s and 1970s turned into a crisis that cost an estimated $300 billion to fix as the year 2000 approached. That’s technical debt at civilization scale, accumulating over decades because “we’ll fix it later” never happened until it became an emergency.

Why do rewrites fail? Because they let you avoid confronting the hard organizational problems that created the debt in the first place. You don’t have to negotiate for refactoring time. You’ve declared the old system dead. You don’t have to gradually improve code while keeping features working. You’re building fresh. You don’t have to convince stakeholders that maintenance matters. You’ve framed it as innovation.

But here’s what doesn’t change: the organizational dynamics. The pressure to ship features quickly remains. The incentives rewarding visible work over sustainable work remain. The lack of time for documentation, testing, and thoughtful design remains.

So the rewrite proceeds under the same constraints that created the original mess. Worse, you’re now maintaining two systems: the old one that customers rely on and the new one that’s not ready yet.

Three years later, the “new” system is the legacy system. It has its own accumulated debt. And someone is proposing another rewrite.

What Teams Who Break the Cycle Actually Do

Some teams break the cycle. They’re the ones where “we’ll fix it later” sometimes actually means later. What do they do differently?

They Make Maintenance Continuous, Not Special

There are no “tech debt sprints” where refactoring gets quarantined away from real work. Instead, every project includes time for improvement. When you touch a part of the codebase to add a feature, you leave it slightly better than you found it. The boy scout rule isn’t a nice idea. It’s enforced practice.

This requires fighting the instinct to separate “feature work” from “cleanup work”. That separation seems efficient (focus on one thing at a time), but it ensures cleanup never happens. When maintenance is someone else’s job, it becomes nobody’s job. When it’s everyone’s responsibility as part of their normal work, it gets done.

They Build Feedback Loops That Create Accountability

If deployments are slow and error-prone, the team that writes code also handles deployments. If the system is hard to debug, the team that builds features also carries the pager. If technical decisions have consequences, the people making those decisions feel them directly.

This is why the DevOps movement matters beyond just eliminating silos. When developers operate what they build, they can’t externalize the cost of their technical decisions. The quick hack that’s annoying to deploy becomes their own problem. The missing observability that makes debugging hard wakes them up at 3am.

Suddenly, investing in quality becomes rational self-interest.

They Develop a Shared Language for Trade-offs

Successful teams don’t pretend that all technical debt is bad or that all maintenance is urgent. They get specific:

• What breaks if we don’t fix this?

• What becomes easier if we do?

• What’s the time horizon on these consequences?

This specificity enables honest conversations with stakeholders. Instead of “we need tech debt time” you say “this system costs us two engineer-weeks per month in workarounds, and we can fix it in six weeks”.

That’s a trade-off product managers can evaluate. It treats engineering concerns as business concerns, because they are.

The Economics of Sustainability

Let me show you the math that changed how I think about this. The case for maintenance isn’t moral. It’s economic.

Organizations that chronically under-invest in code quality move slower over time, not faster. The quick hacks pile up. The workarounds compound. Eventually, every change requires touching six different systems, coordinating with four teams, and testing a dozen edge cases born from years of patches.

At some point (typically around year three or four of consistent neglect), teams hit a wall. Velocity plummets. Estimates balloon. Simple features take months. Engineers burn out from the constant firefighting. The backlog fills with bugs that can’t be fixed without refactoring, which there’s no time for, because you’re too busy fixing bugs.

This is when executives finally authorize “paying down technical debt” usually by pulling engineers off features for a quarter. It’s too little, too late. The debt wasn’t created in a quarter. It accumulated over years. A three-month sprint barely makes a dent.

Meanwhile, the feature roadmap stalls, pressure builds, and the moment the quarter ends, everyone races back to shipping features. Six months later, you’re back where you started, except with more debt.

The math is straightforward, but it requires believing in a time horizon longer than the next quarter. That’s the real barrier.

What You Can Do (Starting Tomorrow)

Here’s how to start shifting your team’s maintenance culture, even if you’re not in a leadership position:

Read more

What happened?

They spent Monday fighting with laptop setup. Tuesday trying to figure out which Slack or Teams channels actually matter. Wednesday in meetings where everyone used acronyms nobody explained. Thursday attempting to understand a codebase with outdated documentation. Friday realizing they still don’t have the right database permissions to run anything locally.

This isn’t just a bad first week. It’s a pattern that will define their entire tenure at your company. The frustration compounds. The confusion persists. The initial excitement dies.

Why First Impressions Compound

Here’s what most organizations miss: onboarding isn’t just about getting someone productive quickly. It’s about establishing the mental models, work patterns, and confidence that will determine their effectiveness for months or years to come.

Think about learning to play an instrument. If your first week involves fighting with a broken guitar and unclear instructions, you’re not just delayed by a week. You’ve learned that this activity is frustrating and confusing. That belief shapes how you approach every future practice session.

The same thing happens with developer onboarding. A new hire who spends their first two weeks hunting for information, asking basic questions that nobody can answer clearly, and hitting mysterious blockers learns something fundamental about your organization: this place is chaotic, and nobody really knows how things work.

That lesson is hard to unlearn.

Developers who go through this initiation sometimes become strong contributors, but many do not. Many leave within a few months, citing “poor organization” or “lack of clarity”. What they really mean is that their first impression is chaos, and nothing afterward changes their view.

The Overlooked Metric of Time to First Commit

Most companies obsess over hiring metrics. Time to fill a role. Cost per hire. Offer acceptance rates. But almost nobody systematically tracks time to first meaningful commit.

This is strange because it’s one of the most revealing metrics you can measure. It captures:

• How well your documentation reflects reality

• Whether your development environment actually works

• If your architecture is comprehensible to smart people who didn’t build it

• Whether your team has time to help new hires or is too swamped

• How many approval gates block simple changes

A team where new engineers ship something real in their first week is fundamentally different from one where it takes a month. And I’m not talking about trivial changes. I mean actual contributions that required understanding the codebase, making decisions, and getting code reviewed and deployed.

The companies that track this metric take it seriously.

The Documentation Dead Zone

Every company has documentation. Most of it is useless for onboarding.

The problem isn’t that documentation doesn’t exist. The problem is that it was written by people who already understood the system, for people who already understand the system. New hires exist in a dead zone where they don’t know enough to even formulate the right questions.

Consider what actually happens when a new developer tries to set up a development environment. They find a README that says “install dependencies with npm install” but doesn’t mention you need Node 18 specifically, not 20. Or that you need these three environment variables that aren’t in the example file. Or that the database migrations only work if you run them in a specific order.

Each of these is a small thing. Easy to fix once you know about it. But when you’re new, you don’t know whether you’re hitting a known issue with a quick fix or a fundamental problem that requires escalation. So you waste an hour trying different things, then sheepishly message someone to ask for help with what turns out to be a one-line config change.

Now multiply that by dozens of similar paper cuts throughout the first week.

The real insight is that documentation gaps don’t just waste time. They train new hires that the documentation can’t be trusted. So even when good documentation exists, they learn to ask a person instead of checking the docs first. This creates a vicious cycle where the team spends more time answering questions, has less time to update documentation, and the gap widens.

Cognitive Load and the Overwhelm Point

There’s a point in every onboarding process where a new hire goes from engaged learning to overwhelmed survival mode. Once you cross that threshold, learning efficiency drops dramatically.

Think about what a new developer faces in their first week:

• New codebase architecture

• New deployment processes

• New team communication norms

• New business domain knowledge

• New tools and systems

• New organizational structure and politics

Any one of these is manageable. All of them simultaneously? That’s when people start forgetting things they learned two days ago because their mental buffer is completely full.

The best onboarding programs recognize this and sequence learning deliberately. First week: get something running locally and understand one small part of the system deeply. Second week: expand to adjacent systems and make a meaningful change. Third week: start participating in planning and architectural discussions.

But most companies just throw everything at new hires at once and wonder why they seem overwhelmed.

What Actually Works

The companies that do onboarding well share some common patterns.

They assign a dedicated onboarding buddy. Not just someone who’s “available for questions” but a person whose job for the first two weeks includes checking in daily, proactively identifying blockers, and providing context that isn’t written down anywhere.

This isn’t mentorship exactly. It’s more like having a native guide when you’re visiting a foreign country. Someone who can say “oh, when the documentation says X, what they actually mean is Y” or “yeah, that error message is confusing, here’s what’s really happening”.

They have a concrete first project scoped specifically for learning. Something real enough to be meaningful but small enough to complete in a few days. The goal isn’t just to ship something, it’s to touch enough of the system to build a mental model.

One team I worked with had new hires implement a small feature in a deliberately well-architected part of the codebase. Not because that feature was urgently needed, but because completing it required understanding database schemas, API contracts, testing patterns, and deployment processes. By the end of their first week, they’d seen the full development lifecycle.

They keep a living document of “things new hires always ask.” Every time a new person asks a question that isn’t clearly documented, someone updates the onboarding guide. This creates a feedback loop where onboarding continuously improves.

They measure and iterate. They ask new hires what was confusing, what took longer than it should have, what surprised them. Not in a formal survey six months later, but in casual check-ins during week one, week two, week four.

The best approach is a simple weekly form during the first month that asks, “What was your biggest blocker this week?” and “What would have helped you be more effective?” The answers show exactly where onboarding fails.

The Organizational Signal

Your onboarding process sends a signal about how your organization operates. A chaotic, frustrating onboarding experience suggests chaos and frustration ahead. A smooth, thoughtful one suggests that someone cares about systems and processes.

This matters more than most leaders realize. Developers are constantly evaluating whether they made the right choice joining your company. The first few weeks are when they’re most open to that evaluation. Everything they experience gets interpreted as representative of the broader organization.

If setup is broken, they assume other systems are broken. If documentation is outdated, they assume communication is generally poor. If they can’t get questions answered quickly, they assume the team is overwhelmed or disorganized.

These assumptions might not be fair or accurate, but they’re natural. First impressions become the lens through which everything else gets interpreted.

The flip side is also true. A great onboarding experience creates goodwill and benefit of the doubt that carries you through later problems. When something goes wrong after a smooth onboarding, new hires think “that’s unusual” instead of “here we go again”.

Starting From Where You Are

You might be reading this thinking “we’re already overwhelmed, we can’t rebuild our entire onboarding process”. Fair enough. But you can start measuring time to first commit and asking new hires what blocked them.

Pick one thing to fix based on what you learn. Maybe it’s the development setup process. Maybe it’s documentation for a particularly confusing system. Maybe it’s creating clearer ownership so new hires know who to ask about what.

Each improvement compounds. Better documentation reduces questions. Fewer questions means more time to improve systems. Better systems mean easier onboarding. The cycle reinforces itself in a positive direction.

The key is treating onboarding as a product you’re building for your newest customers. Those customers happen to be your own employees, but the mindset is the same. Understand their needs, remove friction, iterate based on feedback.

The Real Investment

Improving onboarding requires time from your most experienced people. The ones who know the systems well enough to document them accurately. Who understand the subtle context that isn’t written down. Who can identify what’s actually important versus what’s just historical accident.

These are also the people who are busiest with “real work”. Spending a day improving onboarding documentation feels like a luxury when there’s a production issue or a tight deadline.

But here’s the math: if better onboarding saves each new hire 40 hours in their first month, and you hire 10 people this year, that’s 400 hours. Plus whatever time existing team members save by not answering the same questions repeatedly.

More importantly, those new hires will be more confident, more effective, and more likely to stay. That’s the real return on investment.

Your next hire starts Monday. They’re excited, nervous, ready to prove themselves. What will their first week teach them about your organization?

Will they learn that this is a place where things work, where documentation can be trusted, where getting help is easy and expected? Or will they learn that they’re on their own to figure things out, that systems are fragile, that asking questions makes them look incompetent?

The answer to that question might determine whether they’re still around this time next year.

The Tooling Obsession

Tools are easy to discuss because they’re concrete. You can benchmark them. GitHub Copilot saves X minutes per day. Switching from Jenkins to GitHub Actions reduces build time by Y percent. These numbers feel solid, measurable, actionable.

But here’s the paradox: research from Gartner shows that teams with high-quality developer experience are 33% more likely to attain their target business outcomes, yet organizations continue investing heavily in tooling without seeing corresponding improvements in satisfaction or retention. The interesting question here is: what are we missing?

What Actually Happens When Developers Work

Let me paint a more realistic picture. A developer doesn’t just open their IDE and start typing. They’re holding a mental model of how three microservices interact. They’re trying to remember why the caching layer was implemented that particular way. They’re context-switching between a vague product requirement, a Teams or Slack thread with seven people offering conflicting opinions, and that one piece of documentation that’s definitely out of date but nobody’s sure by how much.

Now, you could have the fastest build system in the world, but if a developer spends 30 minutes hunting down tribal knowledge or trying to understand why a decision was made six months ago, your tooling investment isn’t moving the needle. As I wrote about interruptions and flow state, real programming happens in long, uninterrupted blocks where you can hold an entire system in your head. But that’s becoming almost countercultural.

This raises an interesting point about cognitive load. It’s not just about the code you’re writing, it’s about everything you need to hold in your head to write it effectively. When developers are fighting just to understand how to do basic tasks, they’re spending cognitive cycles on plumbing instead of problem-solving.

Teams often treat their CI/CD pipeline as critical infrastructure while letting documentation rot and architectural decisions live only in people’s heads. Both are infrastructure, just different kinds.

The Autonomy Problem

Here’s something I’ve noticed: developers can be remarkably tolerant of clunky tools if they feel they have real agency over their work. But give them perfect tooling in an environment where every decision requires three approval meetings? That’s a recipe for quiet quitting.

The trade-off here is tricky. Organizations need some level of governance. You can’t have everyone making architectural decisions in isolation. But there’s a huge difference between “we have clear principles and trust you to apply them” and “you need approval to upgrade a minor dependency version.” Where that line sits depends on your organization’s risk tolerance, team maturity, and frankly, how much you actually trust your engineers.

Netflix’s culture emphasizes “freedom and responsibility” where engineers get information and freedom to make decisions, with managers practicing “context not control. But this works because they’ve invested heavily in incident management processes and monitoring capabilities, plus chaos engineering practices that continuously test system resilience. That’s not a contradiction. It’s a system designed around trust with guardrails, not permission gates.

The Communication Maze

This leads to another consideration I find fascinating: how much of developer experience is actually about information flow? Think about your last frustrating workday. How much of it was fighting your IDE versus fighting to understand requirements, waiting for answers in Slack or Teams, or sitting in meetings that could’ve been async updates?

Stripe was cited extensively about their “writing culture”. Comprehensive RFCs, detailed documentation, thoughtful async communication. That’s developer experience work, even though it has nothing to do with their build system. The interesting thing is that this kind of cultural infrastructure is harder to build than technical infrastructure, but it often has more impact.

But wait, there’s a counterargument here. Some teams thrive on synchronous collaboration. Look at pair programming or mob programming advocates. They’d argue that real-time interaction is essential. So which is right? Honestly, it probably depends on your team composition, the type of work you’re doing, and individual preferences. The gray area here matters more than we admit.

The Invisible Stuff That Actually Matters

Here’s where it gets subtle. Can a developer experiment with a new approach without someone questioning their velocity? Can they admit they’re stuck without it reflecting poorly in performance reviews? Can they push back on a feature request because the technical debt is getting unsustainable?

These questions determine whether your environment enables good work or slowly grinds people down. The research I covered on developer frustration found that flow state, feedback loops, and cognitive load are distinct factors that drive both productivity and retention. But notice what’s missing from that list: tooling specifications.

The challenge is that psychological safety, clear ownership, and reasonable work-life boundaries are harder to measure than build times. You can’t put them in a dashboard. That makes them easy to deprioritize, even though they’re often the actual differentiators between companies that retain talent and those that don’t.

What About Learning?

I often wonder whether we’ve made the learning curve too shallow with modern tooling. Now, hear me out. I’m not advocating for hazing rituals or deliberately obtuse systems. But there’s something interesting happening when tools become so abstracted that developers don’t understand what’s actually happening underneath.

Take Vercel or Netlify. Amazing developer experiences for deploying web apps. But do developers understand what they’re abstracting away? Does it matter? Maybe it doesn’t for application developers, but it might for platform engineers. This raises the question: does good DX mean hiding complexity, or does it mean making complexity manageable and learnable?

The best developer experiences I’ve seen do both. They provide good defaults and abstractions, but they also make it possible to dig deeper when needed. When I wrote about building developer-first APIs, this balance comes up constantly. The goal isn’t just to make things work, it’s to make them understandable.

A Framework for Moving Forward

So what actually works? The evidence points to flow state, feedback loops, cognitive load, and platform quality as key factors. Here’s how to address them:

Read more

The research, based on responses from nearly 5,000 technology professionals worldwide, shows that AI’s impact varies significantly depending on organizational context rather than tool sophistication alone.

Why this matters: Understanding what determines AI success can help organizations make better investment decisions and avoid common implementation pitfalls.

The Trust Gap in AI Usage

The data shows widespread AI adoption alongside measured skepticism. While most developers report productivity improvements from AI tools, 30% express little to no trust in AI-generated output. This suggests a “trust but verify” approach that the researchers interpret as potentially healthy rather than problematic.

During interviews, developers compared this skepticism to how they approach solutions found on Stack Overflow—useful resources that still require validation. The research indicates this cautious approach may be a sign of mature adoption rather than a barrier to it.

However, this trust gap does highlight an important consideration: organizations need to invest in training focused on critical evaluation and validation of AI-generated work, not just tool usage.

Seven Team Performance Profiles

The report identifies seven distinct team archetypes based on performance, stability, and well-being metrics:

• Foundational challenges (10%): Multiple performance gaps

• Legacy bottleneck (11%): Reactive work due to unstable systems

• Constrained by process (17%): Stable systems, inefficient processes

• High impact, low cadence (7%): Strong results, high instability

• Stable and methodical (15%): Quality work at deliberate pace

• Pragmatic performers (20%): Strong delivery with average well-being

• Harmonious high-achievers (20%): High performance with low burnout

Our analysis revealed seven distinct team archetypes, ranging from those excelling in healthy, sustainable environments (Harmonious high-achievers) to those trapped by technical debt (Legacy bottleneck) or inefficient processes (Constrained by process).

This framework suggests that traditional software delivery metrics alone don’t capture the full picture of team health and effectiveness.

The Platform Foundation Effect

One of the clearer findings involves platform engineering. With 90% adoption across organizations, the research shows a strong correlation between platform quality and AI effectiveness. Organizations with higher-quality internal platforms see amplified benefits from AI adoption on organizational performance.

The data suggests that without solid platform foundations, AI benefits tend to remain localized rather than scaling across the organization. This isn’t necessarily about having the latest tools, but about having systems that can effectively distribute and govern AI capabilities.

Value Stream Management as a Multiplier

Teams practicing value stream management—systematic visualization and improvement of work flow—show stronger results from AI investments. The research indicates that VSM helps ensure AI gets applied to actual system constraints rather than just individual tasks.

The mechanism appears to be that VSM provides the systems-level view needed to direct AI toward meaningful bottlenecks rather than optimizing steps that aren’t actually constraining overall performance.

The DORA AI Capabilities Model

The research identifies seven organizational capabilities that correlate with better AI outcomes:

1. Clear and communicated AI policies

   An organization with a clear and communicated AI stance is one that encourages and expects AI use by its developers, supports its developers’ experimentation with AI at work, and makes explicit which AI tools are permitted and the applicability of their AI policy for their staff.

2. Healthy data ecosystems

   When organizations invest in creating and maintaining highquality, accessible, unified data ecosystems, they can yield even higher benefits for their organization’s performance than with AI adoption alone.

3. AI-accessible internal data

   Organizations who invest time in connecting their AI tools to their internal systems may observe better outcomes than organizations who rely on the less specialized knowledge provided by generic foundational models.

4. Strong version control practices

   One of the most tangible examples of this is the reliance on rollback or revert features. The ability to undo changes swiftly and without fuss is not just a convenience; it’s a critical enabler of speed and resilience.

5. Working in small batches

   Working in small batches increases reported product performance, while also decreasing perceived friction for AI-assisted teams.

6. User-centric focus

   Organizations that encourage AI adoption will benefit from incorporating a rich understanding of their end users, their goals, and their feedback into their product roadmaps and strategies.

7. Quality internal platforms

   We believe designing and maintaining quality internal development platforms is an important capability for organizations to successfully develop software in an AI-assisted environment.

Teams with these capabilities show stronger positive effects from AI adoption across multiple performance dimensions.

Persistent Challenges

Despite productivity claims, the research shows AI has minimal impact on developer burnout or workplace friction. The authors suggest these may be systemic issues that technology alone cannot address.

AI adoption continues to correlate with increased software delivery instability, though this year’s data shows improvement in software delivery throughput compared to last year’s findings. This suggests some organizational adaptation is occurring.

Year-over-Year Changes

Comparing 2024 to 2025 results, several relationships have shifted positively:

• AI’s impact on valuable work (negative to positive)

• Software delivery throughput (negative to positive)

• Product performance (neutral to positive)

These changes suggest both tool improvement and organizational learning over the past year.

Practical Implications

The research suggests several practical considerations:

For AI tool selection: Focus on organizational readiness factors rather than just tool capabilities.

For implementation: Invest in supporting systems (platforms, data, processes) alongside AI tool procurement.

For measurement: Consider team health factors beyond just delivery metrics when evaluating AI impact.

For training: Emphasize critical evaluation skills and verification practices, not just tool usage.

The research positions current AI adoption as being in transition—moving from initial experimentation toward more systematic organizational integration. Success appears to depend more on implementation context than on specific AI capabilities.

Get the report

Well, that's the daily reality for software developers, and it's costing companies way more than anyone realized.

Here's the thing: we've all suspected that frustrated developers produce worse work, but until now, nobody had the hard numbers to prove it. A study from researchers at Microsoft Research, GitHub, and DX just changed that. They surveyed 219 developers and found something that should make every CEO pay attention.

The Research That Changes Everything

Now, before you roll your eyes at another "developer happiness" study, let me tell you why this one's different. The researchers didn't just ask developers how they felt. They connected those feelings to measurable business outcomes. Productivity, innovation, retention and profitability.

But here's where it gets interesting. They found that developer experience isn't just one thing you can fix with better coffee or standing desks. It breaks down into three specific areas:

Flow State - Can developers actually get into deep work mode? Think about it: when was the last time you had four uninterrupted hours to tackle something complex? For many developers, that's becoming impossible. Notifications, urgent meetings, production fires. They're constantly context-switching.

Feedback Loops - How fast can developers get answers and approvals? I'm talking about code reviews sitting for days, questions posted in Slack or Teams that never get answered, deployment processes that take hours to give you a simple yes or no.

Cognitive Load - How much mental energy gets wasted on just figuring out how to do basic tasks? When you're using tools like Kubernetes or navigating a massive codebase without proper documentation, you're spending cognitive cycles on plumbing instead of problem-solving.

This raises an interesting point about how we think about developer productivity. Most companies track lines of code or tickets closed—but what if the real bottleneck is developers spending 60% of their time just trying to understand what they're supposed to be doing?

The Numbers Don't Lie (But They're Complicated)

Here's where the study gets compelling, but also where we need to be careful about oversimplifying things.

Developers with dedicated deep work time reported feeling 50% more productive. But that's reported productivity, not measured output. Still, when you think about the nature of software development, this makes sense. Writing code isn't like working on an assembly line where you can measure widgets per hour. It's knowledge work that requires sustained attention.

That leads to another consideration: the study found that developers who understood their codebase well were 42% more productive. Now, this could mean two things. Either clear, well-documented code makes people more productive, or more productive people tend to work at places with better codebases. It's probably both, but the causation gets somewhat murky.

The feedback loop findings are particularly interesting. Teams with fast code review turnaround saw 20% higher innovation rates. This actually aligns with what we know about creative work—momentum matters. When you have an idea and have to wait three days to get feedback, you've often moved on mentally by the time the review comes back.

What the Study Doesn't Tell Us

Here's the thing about research like this—it's incredibly valuable, but it has some blind spots we should acknowledge.

First, all these developers worked at companies that were already customers of DX, the developer experience platform. That's not necessarily a problem, but it does mean we're looking at organizations that were already thinking about developer experience. Would we see the same patterns at a traditional enterprise that's never considered these questions? Hard to say.

Second, the study is cross-sectional—a snapshot in time rather than tracking changes over months or years. We don't know if improving developer experience actually causes better business outcomes, or if successful companies just happen to invest more in developer experience. The researchers acknowledge this limitation, but it's worth keeping in mind when making investment decisions.

There's also the question of survivorship bias. The developers who responded to this survey might be the ones who care most about developer experience. What about the developers who've already burned out and left? Or the ones who've just accepted that work is supposed to be frustrating?

The Real-World Reality Check

Let's talk about what this actually looks like in practice, because it's messier than any research paper can capture.

Take a company like Spotify. They've invested heavily in developer experience with their Backstage platform (now open-sourced), which provides a unified interface for all their internal tools and services. But implementing something like that isn't just a matter of buying software—it requires organizational change, cultural buy-in, and ongoing maintenance. And even Spotify still deals with the fundamental tension between moving fast and maintaining quality.

This raises another interesting point about the study's recommendations. They suggest measuring developer experience every 3-6 months and making iterative improvements. That sounds reasonable, but anyone who's worked at a large company knows how hard it is to get consistent executive attention on something that doesn't directly generate revenue.

The Trade-offs Nobody Talks About

Here's where things get really complex, and where most discussions about developer experience get oversimplified.

Improving developer experience often means accepting trade-offs. Want to reduce cognitive load by standardizing on one programming language across your organization? Great, but you might lose the ability to use the best tool for specific problems. Want to implement comprehensive code review processes to improve feedback loops? Fantastic, but you'll slow down deployment speed.

Consider the current AI coding assistant trend. Tools like GitHub Copilot or Cursor can dramatically improve developer productivity by reducing the time spent on boilerplate code. But they also introduce new forms of cognitive load—developers need to learn to prompt effectively, review AI-generated code carefully, and sometimes fight against suggestions that are subtly wrong.

That leads to another consideration: the developer experience that works for senior engineers might be completely different from what works for junior developers. A powerful, flexible tool might be exactly what an experienced developer needs to get into flow state, but it could overwhelm someone who's still learning the basics.

What This Actually Means for Your Business

Now, if you're a business leader reading this, you're probably wondering: "Okay, but what do I actually do with this information?"

The study provides a roadmap, but let's be honest about what it really entails. They recommend starting by measuring your current developer experience. Sounds simple, right? But think about what that actually means. You need to survey developers in a way that gets honest feedback (not always easy in corporate environments), analyze the results, and then figure out what changes are actually feasible given your budget, timeline, and organizational constraints.

The researchers found that deep work and engaging tasks had the biggest impact on developer outcomes. But creating space for deep work in most organizations means saying no to other things—fewer status meetings, longer deployment cycles, maybe even accepting that some urgent requests will have to wait.

Here's what's particularly tricky: many of the factors that improve developer experience also benefit from economies of scale. It's easier to invest in sophisticated tooling and processes when you have hundreds of developers. If you're a smaller company, you might need to be more strategic about which improvements will give you the biggest bang for your buck.

The Bigger Picture

There's a broader context here that's worth considering. This research comes at a time when the software industry is going through some major shifts.

First, there's the economic climate. With interest rates higher and growth harder to come by, companies are scrutinizing every investment more carefully. That makes the business case for developer experience both more important (you need data to justify spending) and more challenging (there's less room for experimentation).

Second, there's the generative AI revolution. Tools like ChatGPT and Claude are changing how developers work, but they're also changing what kinds of developer experience improvements matter most. If AI can handle more routine coding tasks, does that make deep work time more or less important? If AI can provide instant answers to technical questions, does that change how we think about feedback loops?

Third, there's the remote work reality. The study doesn't specifically address remote vs. in-person developer experience, but anyone managing distributed teams knows it adds complexity. How do you create flow state when developers are juggling home distractions? How do you maintain fast feedback loops across time zones?

Where Do We Go From Here?

The most valuable thing about this research isn't the specific numbers—it's that it gives us a framework for thinking systematically about developer experience. Instead of just throwing money at the problem or hoping that new tools will magically fix everything, we can start measuring and iterating.

But let's be realistic about the challenges ahead. Improving developer experience requires sustained investment and organizational commitment. It means making some teams slower in the short term to make the whole organization faster in the long term. It means accepting that some of your best developers might leave if you don't address these issues, but also recognizing that fixing everything at once isn't possible.

The companies that figure this out—that find the right balance between developer happiness and business constraints—are going to have a real competitive advantage. Not because happy developers automatically write better code, but because organizations that can attract and retain top technical talent while maintaining high productivity are going to win in an increasingly software-driven world.

That's the real insight from this research. It's not just about making developers happy—it's about creating sustainable competitive advantage through better human capital management.

"Hey, quick question about the login flow."

I tried to ignore it. Kept debugging. Another ping.

"When you get a sec."

Then another. "No rush, but..."

By the time I caved and answered (because apparently "no rush" means "interrupt whatever you're doing right now"), I'd lost everything. That careful mental scaffolding I'd built up over two hours? Gone. It took me another hour just to get back to where I was.

And you know what the "quick question" was? Something they could have found by reading the Documentation.

This is the reality of modern software development. We've created workplaces that are fundamentally hostile to the kind of deep thinking that actually produces good software. Then we wonder why everything feels rushed, why technical debt keeps piling up, and why our best engineers seem frustrated all the time.

The Multitasking Myth

Let me be blunt here: you can't multitask. Neither can I. Nobody can.

What we call multitasking is really just context switching really fast, and every switch has a cost. It's like running too many applications on a computer with insufficient RAM - everything runs slower because the system keeps swapping things in and out of memory.

I learned this the hard way a while ago during a particularly hellish week where I was trying to:

• Fix a critical bug

• Review code for three different features

• Help junior developers work through blockers

• Answer Teams messages as they came in

By the end of the week, I felt like I'd been working constantly, but couldn't point to a single meaningful thing I'd actually finished. Everything was half-done, partially reviewed, or "almost fixed."

That's when it hit me: trying to do everything means accomplishing nothing.

Why Everything Feels Urgent (But Isn't)

We've created this weird culture where everything feels like an emergency. A question about next week's deployment becomes "urgent." A discussion about button colors becomes "blocking." Someone's inability to find documentation becomes your immediate problem.

The thing is, most urgent things aren't actually urgent. They're just loud.

Last month alone, I got these "urgent" interruptions:

• A question about creating users that were literally documented in the command itself

• A request to review a PR for a feature that wasn't needed for another two weeks

• A "quick sync" about a project nobody had touched in a month

None of these were urgent. But in our always-on culture, the squeaky wheel gets the grease, and the person doing focused work gets... interrupted.

What Deep Work Actually Looks Like

Real programming - the kind that actually moves things forward - happens in long, uninterrupted blocks. I'm talking about the kind of flow state where you can hold an entire system in your head and see connections that aren't obvious when you're constantly context-switching.

My best debugging sessions have lasted 3-4 hours straight. Same with designing new features or refactoring legacy code. You simply can't do this work in 15-minute chunks between meetings.

But deep work has become almost countercultural. If you're not immediately responsive, people assume you're not working hard. If you block time on your calendar for focused work, someone will schedule a meeting over it because "it doesn't look like you're busy."

The open office trend made this even worse. A few years back, I worked at a place where you could hear every phone call, every lunch discussion, and every time someone got excited about their Food delivery. The theory was collaboration. The reality was that everyone wore headphones and messaged people sitting ten feet away.

The Worst Offenders

"Got a Minute?" (Spoiler: It's Never a Minute)

This might be my biggest pet peeve. Someone walks up with "got a minute?" but what they really mean is "I need you to drop everything and think about my problem right now."

The polite answer is always "sure," but the honest answer should be "that depends - what do you need, and can it wait until I finish this thought?"

The "Emergency" Meeting Culture

Everything needs a meeting, and every meeting is urgent. I've been in emergency meetings to plan other meetings. I've sat through hour-long discussions that could have been resolved with a 30-second Teams message.

My favorite was an meeting about improving meeting efficiency. The irony was apparently lost on everyone.

What Actually Works

After years of frustration, I've found a few things that genuinely work, the key is communicating these expectations upfront and sticking to them.

Read more

I've spent years on both sides of this equation - building APIs that developers love and wrestling with ones that make me want to throw my laptop out the window. The difference isn't usually in the underlying technology. It's in whether the team building the API actually thought about the poor developer who'd have to use it at two o’clock in the morning trying to meet a deadline.

What Does "Developer-First" Actually Mean?

Here's the thing - most companies say they're developer-first, but then they build APIs like they're checking boxes on a technical specification. Real developer-first thinking means you're designing for the human being who's going to integrate with your API, not just the computer that's going to execute the code.

I remember working with a payments API that had perfect uptime and blazing fast response times, but their webhook system was a nightmare. No retry logic, cryptic error messages, and documentation that hadn't been updated in two years. Technically solid? Sure. Developer-friendly? Absolutely not.

The developer-first approach means asking yourself uncomfortable questions: Would I want to integrate with this API on a Friday afternoon? Can a junior developer figure this out without asking for help? Does this feel like it was built by people who've actually written code that calls APIs?

The Foundation: Design That Makes Sense

Keep It Predictable (Your Future Self Will Thank You)

Consistency isn't just a nice-to-have - it's the difference between a developer confidently using your API and constantly second-guessing every request they make. When I see an API where some endpoints use snake_case and others use camelCase, I immediately know I'm in for a rough time.

Pick your conventions early and stick to them religiously. If you're using REST, actually follow REST principles. Don't create a GET /users/delete/123 endpoint because it's "easier" than implementing proper DELETE handling. That's not easier for anyone except maybe your backend team, and it's definitely not easier for the developers trying to understand your API.

I've seen teams spend weeks debating whether to use user_id or userId in their API. Honestly? Pick one and move on. The consistency matters way more than the specific choice.

Structure Resources Like a Human Would Think

Your API structure should match how people actually think about your domain. If you're building an e-commerce API, developers expect to find products, orders, and customers - not abstract entities with names only your database architect understands.

Here's a real example that drove me crazy: an API where you had to call /entities?type=customer instead of just /customers. Technically it might have made sense from a database perspective, but it made the API harder to discover and use. Don't make developers learn your internal data model just to get basic functionality working.

Nested resources are great when they reflect real relationships. /stores/123/products makes perfect sense. But don't go overboard with nesting - /companies/456/stores/123/departments/789/products/101 is just painful to work with.

Documentation That Doesn't Suck

Let me be blunt: most API documentation is terrible. It's either auto-generated technical specifications that tell you nothing about actual usage, or it's so high-level that you can't figure out how to make a simple request.

Good documentation feels like it was written by someone who's actually used the API. It includes the edge cases, the gotchas, the things that aren't obvious from the endpoint definitions. When Stripe explains their webhook retry logic, they don't just list the technical specifications - they explain why they designed it that way and how to handle the edge cases in your code.

Interactive documentation is huge. Being able to make real API calls right from the docs saves so much time. But make sure your examples are realistic - don't use foo and bar as example values when you could use actual product names or realistic user data.

Error Messages That Help Instead of Confuse

Nothing kills developer productivity like cryptic error messages. "Bad Request" with a 400 status code tells me absolutely nothing useful. What was bad about it? Which field was wrong? How do I fix it?

Compare these two error responses:

{
  "error": "Bad Request"
}

versus:

{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "Email address is required and must be valid",
    "field": "email",
    "provided_value": "not-an-email"
  }
}

The second one tells me exactly what's wrong and how to fix it. That's the difference between a frustrated developer and a happy one.

Security That Works for Humans

Security is non-negotiable, but it doesn't have to be a nightmare to implement. OAuth 2.0 is the standard for a reason - it's well-understood, and there are libraries for every language. Don't roll your own authentication scheme unless you have a really compelling reason.

API keys are fine for server-to-server communication, but make them easy to manage. Developers need to be able to rotate keys, revoke access, and monitor usage. And please, for the love of all that's holy, don't put sensitive operations behind just a simple API key with no additional verification.

Rate limiting is important, but be transparent about it. Include rate limit headers in your responses so developers can build proper backoff logic. And consider different rate limits for different types of operations - reading data and writing data shouldn't have the same limits.

Versioning Without the Headaches

API versioning is one of those topics that starts flame wars in developer communities, but here's what actually matters: predictability and reasonable migration paths.

URL versioning (/v1/users, /v2/users) is the most explicit and makes it clear which version you're calling. Header-based versioning is cleaner but less obvious. Pick one approach and stick with it.

The key is giving developers time to migrate. Don't deprecate v1 the day you release v2. Give at least six months' notice, provide clear migration documentation, and if possible, run both versions simultaneously for a while.

When you do make breaking changes, make them count. Don't release v2 just to change a field name - batch your breaking changes so developers only have to deal with migration headaches occasionally, not constantly.

Performance That Doesn't Surprise Anyone

Fast APIs are great, but predictable performance is more important. If your API usually responds in 100ms but sometimes takes 10 seconds, that's worse than an API that consistently takes 500ms.

Implement proper pagination for any endpoint that could return large datasets. Don't make developers guess whether they need to paginate - if there's any chance a response could be large, paginate it from the start.

Caching headers are your friend. If data doesn't change often, tell clients they can cache it. This reduces load on your servers and makes the developer experience faster.

The Small Details That Matter

Field naming might seem trivial, but it adds up. Use clear, descriptive names. created_at is better than created which is better than ct. Don't make developers guess what your fields contain.

Boolean fields should be obviously boolean. is_active, has_children, can_edit - these names make it clear what type of value to expect.

For timestamps, use ISO 8601 format with timezone information. Yes, it's verbose, but it's unambiguous. 2023-10-15T14:30:00.000Z tells me everything I need to know.

Building Community and Getting Feedback

The best developer-first APIs evolve based on real developer feedback. Set up channels for developers to ask questions, report issues, and suggest improvements. GitHub issues, Discord servers, dedicated forums - pick whatever works for your community.

Pay attention to the questions developers ask. If multiple people are confused about the same thing, that's not a training problem - it's a design problem. Use support questions as product feedback.

Consider creating SDKs for popular languages, but don't let them become a crutch for poor API design. A good API should be usable with just HTTP requests and good documentation.

Testing From the Outside In

Test your API like a developer would use it, not like you built it. Write integration tests that make real HTTP requests. Try to integrate with your own API using different programming languages and frameworks.

Set up monitoring that tracks developer-focused metrics, not just system health. Track error rates by endpoint, measure time-to-first-successful-request for new developers, and monitor documentation page views to understand what developers are struggling with.

The Long Game

Building a developer-first API isn't a one-time effort - it's an ongoing commitment. Technology changes, developer expectations evolve, and your own product grows. The APIs that developers love long-term are the ones that adapt while maintaining their core principles of clarity, consistency, and respect for the developer experience.

Remember, every developer who has a good experience with your API becomes a potential advocate. They'll recommend you in architecture discussions, write blog posts about successful integrations, and contribute to the community around your platform. That organic growth is worth far more than any marketing campaign.

The goal isn't just to build an API that works - it's to build an API that developers actually enjoy working with. When you achieve that, you'll know it. The support tickets decrease, the community grows, and developers start building things with your API that even you didn't expect.

That's when you know you've built something truly developer-first.