Security Marketing and Sales 2: Baggage
Last week, I explained how customer dissatisfaction can hinder progress in an overall approach to a successful security program. Today, we’ll talk through deeper organizational barriers in that strategy and what you can do.
Cultural barriers to change
If your organization prefers capitalizing spend, you may be vulnerable to stagnating capabilities.
Continual improvement (or its close relatives Agile and devops) usually starts with a consistent effort or spend and delivers a steady stream of improvements within that commitment.
Capitalizing spend is the opposite: leaders jockey for transformational jumps with one-time, upfront costs, then amortize that spend over the next 5–7 years.
One of the dangers of favoring capital spend is a high barrier to continual improvements: once you get approval to build your system, you may go 10 years before getting significant budget again to make changes. As the organization evolves, the processes and capabilities as originally built may become cumbersome or even more trouble than they’re worth. In extreme cases, this culture can even yield deferred maintenance, which in the IT world produces substantial security risk.
In any organization, it requires extra effort to stay on top of the performance of your managed capabilities. It’s easier to make something good than to keep it good. A culture of continuous improvement is the only consistent way I know to prevent stagnation and backsliding.
Technical barriers to change
Higher cost or risk to change a system exponentially discourages improvements. This is a huge hidden cost of static, heavy designs; avoiding it is a driving pillar of devops.
Consider: if it takes 5 minutes to adjust the wording on a landing page and you have high confidence that your change will not break anything else, you won’t think twice. You don’t need change tickets, you don’t need outage windows, you don’t need reversion plans or hypercare or communication or even testing. You just do it.
Think of the further savings if little skill is needed: the person who wants the change can do it themselves. They don’t need to find someone to build it, they don’t need to propose funding for paying that person, they don’t need to submit their proposal to a queue and wait for their ticket, their builder doesn’t need to write functional and technical specs, and nobody needs UAT. You get to skip arguments about where blame should fall if the requester isn’t happy with the deliverables. Everybody avoids the risk that the requester forgot what they wanted by the time it was delivered.
Some rigor may still be wise if the changes are complicated enough, but you do get to skip all the steps that catch gaps between the vision and deliverables. Worst case, if they fail it’s another opportunity for them to appreciate how hard building is and how easy delivery teams make it look.
Low barriers to change encourages creativity and problem-solving at lower organizational levels, letting more people make more improvements faster. When selecting platforms and tools, prioritize those that require little effort to change workflows, dataflows, and UIs.
No-code, Low-code, and RPA platforms promise to deliver on this vision, but the same principles of user experience design apply: if they’re buggy, slow, or hard-to-use, you’re just moving the high barrier to change and you may not get the magical awesomeness you hoped for.
Overall Approach
As you listen carefully to your customers and market your capabilities within the context of their goals, consider the boring ways you may be frustrating them daily. Do their interactions with your teams and platforms damage your credibility? Do people complain about or resist you because of unrelated pain they blame you for? How much goodwill and influence can you gain by reducing that frustration?
Next week, we’ll start to explore some concrete lessons from the world of UI/UX design that can help reduce frustration, pain, and avoidance with your services and platforms, allowing you to change hearts and minds. Woo.
Originally published at saltyonsecurity.net on March 1, 2022.