Notifications
Clear all
Topic starter
08/06/2026 4:16 pm
TL;DR: Software engineer burnout is driven in part by workload pressure, poor communication, and repeated access friction, with Haystack analytics finding 81% of developers suffer from burnout and 53% considering quitting in 2022. The access layer is not separate from productivity: when authentication, approvals, and credential handling interrupt flow, governance becomes an operational drag, not a background control.
NHIMG editorial — based on content published by StrongDM: 10 Tips to Prevent Software Engineer Burnout
By the numbers:
- 81% of developers suffer from burnout.
- 53% of developers are considering quitting their jobs.
- 52% of development teams miss deadlines due to issues with accessing infrastructure.
Questions worth separating out
Q: How should security teams reduce access friction for software engineers?
A: Start by removing avoidable approval steps from routine development access, then centralise authentication and entitlement visibility so engineers are not forced to manage multiple credentials across databases, clusters, and internal tools.
Q: Why does access governance affect software engineer burnout?
A: Because every extra login, request, or entitlement delay interrupts concentration and increases cognitive load.
Q: What breaks when access is managed through too many manual steps?
A: Flow breaks first, then output quality and morale.
Practitioner guidance
- Map the access friction points in developer workflows Identify where repeated logins, manual approvals, and resource delays interrupt engineering tasks, then rank those steps by frequency and time lost.
- Rationalise approval paths for common engineering access Separate routine access from high-risk access so standard database, cluster, and platform requests do not move through the same slow path as privileged changes.
- Centralise visibility into who can reach critical systems Use a unified access layer that records who has access, who used it, and when it was revoked so support teams spend less time hunting for entitlement drift.
What's in the full article
StrongDM's full blog post covers the practical detail this post intentionally leaves for the source:
- Examples of team-level communication habits that reduce burnout in distributed engineering groups
- Specific access workflow changes StrongDM describes for reducing login friction and wait states
- The article's broader productivity and morale framing across onboarding, training, and recognition
- Customer-style examples showing how access control is positioned as a developer enablement layer
👉 Read StrongDM's full post on preventing software engineer burnout →
Software engineer burnout and access friction: what teams miss?
Explore further
08/06/2026 5:49 pm
Access friction is an identity governance problem before it is a productivity problem. This article makes clear that repeated logins, bottlenecked approvals, and fragmented access paths wear down engineering teams long before they appear in formal security metrics. In practice, the identity layer is shaping whether engineers can sustain focus, not just whether systems remain protected. That makes access design a workforce issue as much as a control issue.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: How do organisations know whether access friction is becoming a retention risk?
A: Watch for repeated delays in requesting access, growing support tickets around permissions, missed deadlines tied to infrastructure access, and higher disengagement in engineering teams. Those are operational symptoms that the identity layer is making work harder than it should be, and they often appear before turnover does.
👉 Read our full editorial: Software engineer burnout exposes the access-productivity gap
