As a people manager, I’ve always seen the value in collaboration.

I can almost judge the maturity of a team by what that collaboration looks like. Honestly, I can probably judge an entire company by it as well. Maybe not entirely, but it’s at least one of the factors.

I first really saw it at a company called Intelex/Commworks.

The work was project managing subcontractors pulling cabling in new and remodeled retail stores across the country. Twenty or more twenty-somethings crammed into a small strip-mall office filled with cubes. Hundreds of calls a day. Everyone sharing the same database of cablers. Everyone trying to get their own projects completed while negotiating with subcontractors trying to make a little more profit, while we were trying to squeak out enough margin ourselves to look good and maybe get promoted.

It’s probably the closest I’ll ever get to working on a stock market trading floor as far as managing chaos.

And it went on all day and, sometimes, all night.

But that wasn’t the remarkable part.

The remarkable part was the collaboration.

It created a community and, in some ways, something close to a family. You called coworkers at all hours. You ate breakfast, lunch, and dinner with them. You went out for drinks and celebrated wins, both business and personal because you wanted to.

Eventually they knew what you were thinking before you knew what you were thinking.

The first 90 days of a new hire for example wasn’t really about whether you could learn the job. You could learn the difference between CAT5 and fiber. The real test was whether you fit into the fabric of the team. Personality tests were important, understanding what reaches you mattered.

Because not fitting with the personalities and the people could be far more damaging than not knowing the technical details.

When I moved to my next company, I went to a good place.

But the collaboration wasn’t nearly as strong, and I noticed the effect almost immediately.

There wasn’t the same connection. People did their jobs. Projects got completed. The company was successful and remains successful.

But you could see the gap between what the organization was accomplishing and what it potentially could have accomplished.

After about a year, I started intentionally trying to build more collaboration between my development teams and the teams around us.

It worked.

Slowly.

And only when I kept pushing it.

That experience changed the way I looked at future opportunities. When I started considering another career move years later, the level of collaboration inside a company became part of my decision process.

Then I went to Angie’s List.

Angie’s List had what I experienced at Intelex/Commworks, except somehow they had managed to scale it from a couple dozen people to hundred or more developers, account managers, and sales across multiple departments.

There was a certain magic in watching a hundred people gather for a weekly stand-up and actually care about what the other departments were doing.

A 30-minute stand-up could turn into conversations between teams about how they could improve each other’s work. Decisions could change within hours across a dozen teams because people trusted each other enough to talk, challenge assumptions, and adjust. Again, you wanted to stick around after the 9-5 was done to talk about what’s next over dinner or drinks.

Admit-tingly I was only there a little over a year. They got purchased and caused me to move on. Anyone who’s worked in Project Management knows this reality.

That said the fact that I’m still talking about it eight years later probably tells you how much of an impact it had on me.

It also reinforced something I’ve carried into my leadership style and IAM leadership.

Collaboration isn’t something that just happens because people report into the same organization.

You can have incredibly talented people sitting right next to each other who still operate almost completely independently.

I’m surrounded today by some world-class security minds. For years I’ve tried to show the value of getting those people and teams working more closely together.

Sometimes it works.

Sometimes it doesn’t.

What I’ve learned is that getting departments to become a larger collaborative force takes more than scheduling another meeting or creating another Teams channel.

It takes trust.

It takes time.

And, frankly, it takes a little faith from the people involved that working together is going to make their lives better rather than simply create more work.

That last part matters.

Daily operational work wears people down. Tickets, incidents, audits, projects, deadlines, regulatory commitments, vulnerabilities, access reviews, production issues — the list never really gets shorter.

Eventually collaboration can start feeling like one more thing someone is asking you to do instead of what happens organically.

Which brings me to today. I’ve recently been tasked with helping build more collaboration, and even with how strongly I believe in it, I can look at the hill in front of me and recognize that it’s a tall one.

Because from everything I’ve experienced, you don’t climb that hill alone.

If nobody else is climbing with you, eventually it starts feeling like you’ve been sent on a snipe hunt looking for something everyone claims exists but nobody can actually find.

I think that’s also part of why I enjoy conferences so much.

For a few days, I get to watch collaboration work again.

Everyone arrives with their own agenda. Vendors want customers. Practitioners want answers. Speakers want people in the room. Attendees want something useful to take home.

But everyone also understands that the window is short.

So people adapt.

They talk.

They share.

They compare problems.

Someone explains how they solved something. Someone else explains why that solution would never work in their environment. A third person combines pieces of both approaches and comes away with something better.

That’s collaboration.

And it helps explain why companies spend so much time and money trying to create it through tools, processes, reorganizations, culture programs, offsites, and transformation initiatives.

I just don’t think you can buy it.

And once a company reaches a certain size, I don’t think you can declare it into existence at the company level either.

You build it smaller.

Inside a team.

Then between teams.

Then across a department.

Then between departments.

Eventually, if enough of those connections exist, the organization starts behaving differently.

That matters especially in IAM.

Identity touches almost everything.

Security. Infrastructure. HR. Application teams. Cloud. Service management. Compliance. Audit. Development. The business.

IAM cannot operate effectively as an island, no matter how good its technology is.

You can buy better IGA.

You can improve PAM.

You can implement better identity analytics.

You can build great automation.

But eventually almost every meaningful identity problem crosses a boundary that IAM doesn’t control.

And when it does, the strength of the relationships between the people on each side of that boundary suddenly matters just as much as the technology.

Maybe more.

Which brings me back to where I started.

If you want to understand how mature an IAM program is, don’t just look at its tools, policies, controls, or architecture.

Watch what happens when IAM needs something from another team.

That will probably tell you more than the architecture diagram ever will.

• WordPress