Notifications
Clear all
Topic starter
07/06/2026 8:22 pm
TL;DR: Engineering leadership models where managers own product areas end to end, stay close to customers and code, and guide reliability, security, and architecture decisions as companies scale, according to WorkOS. That kind of operating model matters because identity and access programmes increasingly need engineering-led governance, not handoffs.
NHIMG editorial — based on content published by WorkOS: Engineering leadership at WorkOS: Product, people, and impact
Questions worth separating out
Q: How should security teams handle identity features built inside product engineering teams?
A: Treat the engineering team as part of the control environment, not as a separate delivery function.
Q: Why do developer experience and identity governance need to be designed together?
A: Because developers will choose the fastest workable path, not the most policy-compliant one.
Q: What breaks when access-related decisions are made without explicit review gates?
A: The organisation loses the ability to prove who approved what, why the tradeoff was accepted, and how the change will be supported after launch.
Practitioner guidance
- Map identity feature ownership to governance ownership Identify which engineering leaders own SSO, RBAC, directory sync, secrets handling, and related access surfaces.
- Add explicit architecture review gates for access-related changes For any change that affects authentication, authorisation, or lifecycle behaviour, require a documented review trail that covers threat assumptions, rollback paths, and operational support.
- Test whether developer experience encourages unsafe workarounds Review integration patterns for hardcoded secrets, bypassed approvals, duplicated access logic, or manual provisioning steps.
What's in the full article
WorkOS's full article covers the organisational detail this post intentionally leaves for the source:
- The specific responsibilities WorkOS assigns to engineering managers across product, architecture, and team health
- How the company structures weekly decision-making between managers and the CEO
- The cultural expectations WorkOS uses to evaluate engineering leaders in a product engineering organisation
- How the leadership model is expected to evolve as headcount and AI infrastructure work expand
👉 Read WorkOS's analysis of engineering leadership in a product engineering model →
Engineering leadership at WorkOS: what it means for IAM teams?
Explore further
07/06/2026 10:14 pm
Engineering leadership has become an identity governance function. When the same teams own enterprise identity features, technical quality, product definition, and launch decisions are no longer separable concerns. That structure aligns directly with the way modern IAM and NHI programmes fail in practice: the operational decision maker is also the implementation owner. Practitioners should treat product engineering ownership as part of governance design, not just org design.
A few things that frame the scale:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: When should IAM and security teams push engineering leadership for more formal control ownership?
A: Do it whenever enterprise identity functionality is part of the product surface and the team is making tradeoffs that affect trust, availability, or access scope. The earlier the product team owns the control boundary, the easier it is to keep architecture, support, and lifecycle decisions aligned.
👉 Read our full editorial: Engineering leadership at WorkOS and what it signals for IAM
