How Resolving Organizational Friction Helps Turn Security Pilots Into Lasting Adoption

Organizational friction can sink a security rollout before the technology gets a fair chance. A successful proof of concept means little if competing incentives and internal politics stall adoption. CIOs and CISOs give capable tools a better chance to deliver by resolving those tensions early, aligning teams around clear outcomes and making evaluation a shared effort.

Bradley Schagrin is North America Lead at CTO Craft, the executive community for CTOs and engineering leaders. He spent years running partner programs at HP, Micro Focus and OpenText, and he told The Security Digest last year that boards must own cyber risk. That time selling security into large organizations gave him a close view of how companies buy and where buying goes wrong.

"Friction, I really believe, starts at the top. At the very top. Even at the board level," says Schagrin. Boards usually respond to a missed P&L by replacing the executive, he says, and he thinks they should look harder at how management actually works. That view shapes the advice he gives buyers, from the KPIs a board sets to the way a team tests a vendor.

Friction wears the system down

Schagrin compares organizational friction to pistons. "What happens when you have friction with pistons? It starts to rub off and you start to get shavings," he says. Over time the shavings damage the engine, and in a technology organization he says the damage shows up as a dysfunctional team, the wrong technology bought and projects that run late.

Politics drive much of it. A skeptic resists the project while a champion works to win him over, and Schagrin asks whether the CIO or CTO even knows, or cares, because the friction arrives either way. He puts the shelf life of a CIO or CTO at about 18 to 24 months, by his own estimate. The argument echoes a case other security leaders make, that culture comes before another tool.

KPIs should cascade from the board

Boards don't drive the KPIs, Schagrin says, but they need to understand them, and the measures should break down level by level. A company-level view covers revenue and renewal rate, a technology-level view covers what the tool does, and the analysts' own evaluations come next, with one KPI showing the team is learning the product. He caps the list. "You want to probably have no more than six," he says, and each one needs an explanation of why it sits where it does.

He wants the 30-60-90-day plan treated as a live document. The first version is aspirational because little data exists yet, and by day 60 real numbers show which expectations are realistic. Leaders revise as results come in, and the updated plan goes to the board with the KPIs behind it. The measures have to track the outcome, since closed-ticket counts can fill a SOC dashboard without showing that risk fell.

Vendors reveal themselves beyond the product

Schagrin thinks CIOs and CTOs spend their evaluation time on what a product does and too little on the company selling it. He wants them to learn how the vendor sells software, how its organization handles a POC, and what its customer success and renewal rates look like.

"The salesperson could very well know more about that organization internally than the CIO or CTO," he says. A seller who is doing the job right has identified the coach and the champion and knows where the politics come from. Other security leaders make a similar case for tracking vendor performance over several months, so a buyer walks into the budget conversation with a record.

Run the POC as a collaboration

Schagrin has watched vendors treat a POC as the answer key to a test, so they focus on whatever the buyer says it will check. His advice to buyers is to keep some obvious checks to themselves and raise any the product misses.

Inside the buying organization, he wants a different posture. A CIO who hunts for something the evaluator hadn't thought of turns the POC into a pop quiz, he says, and it works better as mentorship, buy-in and collaboration. He also wants fewer meetings about meetings, with the CIO or CTO engaging a small group that's comfortable with the tool. "You want to do everything that you can to reduce friction and conflict," Schagrin says.