Who We Hire to Lead Identity

A few peers have told me about executives who hired technical people as their direct reports for one reason: that was where the executive's own gap was. It made sense in the moment. Nobody stopped to ask whether that person could ever step into the executive's job.

I see a version of this in identity leadership positions. More and more job descriptions ask mainly for engineering and architecture experience. Governance and analyst experience, if it shows up at all, is near the bottom of the list.

I understand why. Identity is technical, and someone who has built and run the platforms earns trust quickly. Engineers, architects, analysts, governance people, and those who drive change and transformation all bring something an identity program needs. The question is what the person leading it needs.

Most of the problems I see in identity programs are not engineering problems. Nobody owns the groups. Reviewers approve access they cannot explain. Access roles multiply until nobody trusts them. Those get fixed by someone deciding who owns what, what gets reviewed and why, and what the business will accept.

In my book, the operating model rests on five pillars: Governance, Lifecycle, Access, Technology, and People & Change. Technology is one of them. Most of these problems live in the other four.

A leader hired mainly for engineering depth will tend to lead from the how: which platform, which connector, which workflow. Those questions matter. But if nobody owns the what and the why, strategy gets made one technical decision at a time. AI makes that more pressing. As agentic tools make the how faster and cheaper, deciding what to build and why becomes the harder part.

The reverse is a risk too. A leader who only knows governance can set a direction the engineers cannot build.

So when you hire, write the position around the decisions it has to make today and the ones your roadmap will bring, and ask whether this person could someday lead the whole program. If you are an engineer moving into leadership, learn the governance side on purpose. If you come from governance, learn enough architecture to be credible in the room.

In a small organization, the identity team may be one or two people. That makes the question sharper: which parts of the model can they cover, and where will you borrow help for the rest?

I would like to see more identity leadership positions ask for both.

Related

• Series 1 Post 1: LinkedIn post
• Series 3 Post 7, Why RBAC Fails
• Series 3 Post 8, How Ownership Gets Lost