Organizational Politics & The Security Program

I first wrote the original of this post over 4 years ago. Having seen a new spurt of discussion about organization politics in various on-line and in-person forums I thought it was time for an update. 

At every stage in your career and in every part of your role you are going to have to deal with organizational politics. People often construe such politics as inherently negative. Yes, there are some organizations that have toxic cultures where organizational politics looks more like chicanery and dishonest manipulation. If you are in one of those places, and can’t change it, then get out as quickly as possible. 

Most places, though, simply have the day to day routine politics of striving for outcomes. This is using influence to work the organization’s “machinery” however that might be structured. Many people who have not taken the time to learn how to do this label the need to do it as an organizational failure. It’s not, it’s a natural outcome of any human structure and the sooner you learn to work within such environments the more successful (and happy) you will be. 

What are Organization Politics

Politics is a rich term, as you can see in the full Merriam-Webster definition below.

In this context we should focus on the definition that is: “the total complex of relations between people living in society”, and here think of society as the organization and its wider ecosystem. This wider ecosystem includes customers, suppliers, and external stakeholders like regulators, policy-makers, and auditors. The lessons we will now discuss apply to them as much, perhaps more so, as they do for your own organization.  

So, if you think all organizational politics are bad, pointless or that you have decided to simply opt out of any of it then I’m sorry to say you’ll find that rather limiting. 

Any time there are 2 or more people involved in something you have to think about the application of influence, power and persuasion to achieve your intended outcome. This might be for something small, like a particular component design choice or the selection of a vendor, all the way up to the massive multi-year transformational bets that are the essence of very successful security programs.

In any organization there are finite resources and many competing factions seeking to apply those resources to their objectives. Getting what you need in the face of this is the stuff of organizational politics.

The Unfunded Mandate - A Case Study of Getting It Wrong and Recovering

I first became a CISO in my mid 20's without much prior management experience, having spent my time up until then developing software and doing systems integration across a range of industries.

I spent my first few years learning by trial and error what was necessary to establish, build and operate complex security programs. At the time, in the mid to late 1990’s, there really wasn’t much of a body of knowledge of how to do this. Even the more experienced leaders at the time were still making it up as they went along.  

My first lesson in organizational politics was immensely formative. This was a long time ago and I won’t name the particular company. In any case, this isn’t a dig at them, it’s a dig at my naïveté. 

I had inherited a flawed security program whose main approach was to essentially issue aspirational policies and hope for the best. I was asked by executive management and the Board to put together a more comprehensive security program which I dutifully did and it carried a pretty impressive price tag. This was presented to the Board and they liked and approved it. I was very happy and pretty pleased with myself, this was how things were supposed to go I thought. 

Then reality kicked in. It turned out the way this particular organization worked was that the Board approved things “in principle” but the actual funding to carry out their wishes needed to be provided directly by the business Divisions of the company. Ok, no problem, so I then went to each Division (10 of them) quite sure that I could just turn up with my “Board approved” mandate and the money would be showered upon me. You all know what happened next. Pretty much each Division essentially went: "Your Board mandate is very nice but we’ve got multiple objectives, cost constraints and other issues that mean we can’t fund this". So, I went back to the Board Chair and they basically said, “But we’ve sanctioned you to do this, so get on with it.” 

Now to my credit, I suppose, I then proceeded to do the work I should have done in the first place by going to each Division and making a case on its own merit for the context of their risk reduction priorities. This grind of several months ended up getting a workable operating budget and plan to execute on the most important parts of the Board endorsed program, albeit over a longer, and actually more practical, time frame.

All was good, I learnt the lesson of how to appropriately get buy-in, help the line of business executives, build influence and manage the overall business and Board political climate. In other words, I was actually figuring out what I probably should have known by asking more questions in the first place about those Board / Executive mechanics.

But, there was one final sting in the tail lesson, and that was a peer organization (in another related risk area) seeing the success we were having in working with the Divisions to secure funding, decided to go to the Board without my involvement and have them endorse some additional priorities on top of the original program I’d proposed. These were mostly unnecessary and in some cases counterproductive requirements. Unfortunately, the Board approved it and it landed on me to execute and, again, go get the funding for it. This time I couldn’t sell it, I didn’t even believe in it myself, and so I was in an intractable position of having a Board directive and no ability to execute on it - and for various reasons no immediate political will to amend the Board decision. This took a long time to unwind and was a drag on the overall program. 

This final lesson illustrates the need to build and maintain a solid relationship with the power structures (Board or otherwise) that mandate outcomes so you are flagged when things are approaching them, before it gets there, that are related to any of your work. You might say that in reality organizations should do this better and more openly. Yes, I agree, and most times they do but sometimes they don’t and you need to be on your guard for that.

This began the next decades of CISO, Chief Risk Officer and Board work and many other lessons in organizational politics and influence. Here are some of those major lessons:

1.Decisions are Not Made in Committees

Most formal meetings, committees, councils or otherwise are ostensibly convened to make decisions. But in most cases they are  ceremonial - to simply confirm a decision that has already been made by a consensus of members. This might be explicit, like a ratification process. More often it is implicit and the approval in the meeting is pre-ordained (or not) by the work done in advance to influence the outcome, get people on side, confirm support and ensure the resources to support the decision are in place. 

If you’re going into a meeting or committee and you don’t already feel confident on the outcome then you’ve missed the point and will have likely not done the work to line up support for the outcome you want. Remember, committees are the roots of power structures not the structure themselves. Use the existence of committees and the fact a decision is being brought to, or potentially brought to, such a group as a means of working that decision outside that committee. The committee is a tool to use.

For example, let’s say you need a business unit to upgrade some parts of their security. They assert that they can't prioritize this for various reasons. You work with them and still fail to get to the right outcome. So, politely, you assert that such risk needs to be officially endorsed by the organization’s risk committee (made up of a number of company executives) and this requires you to both jointly present this issue and explain why security isn’t a priority related to their other priorities. You do this in a spirit of partnership even if you don’t agree with their stance. In my experience, and from what I’ve seen in many other places, most of the time that business unit leader decides they don’t want to defend their initial decision in that committee and so decide to do the work. When they do decide they need to get the approval to defer the work then taking it to the risk committee gets you all endorsement (or not) that provides some shared accountability. Eventually, word spreads that this is the process and people generally decide (except for the truly intractable) that they may as well buckle down and do the work. 

My favorite illustration of the committee process is from the TV show, The West Wing.

2.Map and Partake in Decision Making Flows

Organizations have a myriad of management and operational processes to decide on things. Embedding your organization's processes and objectives into these is important. This can be challenging as often there are multiple overlapping and ambiguous processes across budgeting, business operations, product development, sales, marketing, people development, resource allocation, bug fix prioritization and so on. 

It is important to be aligned with the natural cadence of those processes and not miss the boat to get your needs into them. If you’re not ready to introduce your fully formed idea into, say, a business product development agenda then you might want to introduce some minimum viable idea or placeholder to get something into the process which you can then build from. Otherwise you have to wait until the next cycle which might be the following year.

3.Slip Stream Constantly

Look for ways to integrate your objectives into existing practices, processes, budget priorities, business products, and projects. This has the benefit of not only having significant leverage for your objectives but is generally the right thing to do anyway: secure products not security products. The additional 5-10% cost and effort to do a particular product well from a security, controls, resilience and compliance perspective is easier to justify than the +1000% needed to get that resource at an enterprise level and then allocate it across all the products and projects that need it. Again, it can feel a bit messy, but you can retain an overall set of strategic goals while being mercilessly tactical in execution. In doing this, your team will be more deeply connected to the work of the organization and will also be able to observe and counter any potential drift of existing controls and security practices.

4.Don’t Let a Crisis Go to Waste

Run toward problems. Not just because they need to be fixed but because the closer you are to them then the more opportunities you have to shape the resolution. You can drive the lessons learned and future mitigating actions in more strategic ways that align to the objectives of the security program. Such problems don’t need to be security problems. For example, I've seen some transformational upgrades to software security processes as an additional improvement layered on top of work to reduce the risk of recurrent critical bugs or capacity issues. If you’re constraining yourself to only work upgrades from security events then you’re likely missing 10X of other opportunities.

5.Build a Base of Support

The security role is tough. You’re constantly being called upon to walk the tightrope between too much and too little security. You shouldn’t do this on your own. Asking others for advice, getting input on risk appetite and being engaged is key. This is one way to build support among peers, business unit leaders and other key stakeholders. The other way is to be extraordinarily helpful and thus be perceived as valuable beyond the immediate parameters of the security role.

Being helpful takes work. It means fighting the feeling of “this is not my job” and being helpful anyway. This builds up your credibility and political capital over time. One day you’ll need to spend that capital either by calling in support explicitly or, as is sometimes the case, by having supporters in the room that you are not in when a key decision is being made that affects your security program. Many of the security programs I’ve run also drove improvements in reliability, development agility, product features, and more. These came from observations of issues in the security processes that we could have ignored as being outside of our lane, but we decided to press and got support in doing so. Taking that initiative, irrespective of the outcome, boosted the perception that we were helpful and commercial which in turn made people more receptive to supporting our core security objectives. 

A corollary of all of this is to not depend on your immediate boss too much. I’ve seen this happen to other people and organizations so much it’s almost a cliche. That is, you only get things done because of your own positional role power (not other influence) or the role power of your boss (this is why I’m often so perturbed when people talk about CISO reporting lines as the key to getting things done - it helps in the short term but is toxic in the long term). It’s obvious why you shouldn’t be dependent on your immediate boss too much. They have a habit of leaving or moving and the new boss might want to make changes - perhaps some negative ones. If you have a broad base of wider leadership support it’s much easier for the new leadership to want to leverage you as they settle into their new role. This base of support helps assure the tenure you will need to make a long term difference. And, in the unfortunate case your new boss is not a fan of what you are doing then your broader base of support constrains their actions until they see the light. For example, if you have built great CEO and Board relationships it’s unlikely a new leader at some other level is going to haphazardly impact you or your program. 

As an aside, if you are developing your career and working your way up the organization don’t overly fixate on only building relationships with executives or other senior leadership. By the time you get to be more senior they’ll likely be gone. Rather, work with the people in business units who are also rising up the ranks in their world, and be amazingly useful and helpful to them. One day you will all be senior executives together as a tight cadre driving the right outcomes. 

6.Leverage Others

The key to much of the success of the security program is, of course, the ability to leverage the work of everyone in the organization. Align with their objectives, be collaborative and, well, be nice. Or if you can’t be nice then at least don’t be an a-hole. 

Even if your organization needs significant security improvements it is likely that it is in that state for a variety of complex reasons, and it likely drifted into that state through no fault of one person or even group of people. It will likely not be the fault of the people you most need help from to turn the situation around. So getting on your high horse and pontificating that people don’t care about security and being judgmental about the causes is not going to get you any ability to work with people to improve the situation. Show some empathy and put yourself in other people’s shoes.

7.Find Natural Supporters

A major part of a security program’s success is finding and getting support from one or more of the dominant factions in your organization. In other words, what is the group of people who are inherently highly regarded, like the heart of the organization. 

If you get these people on side then they’re going to lead the way with you, or maybe even for you. This is different in every organization. In a product company it might be the core cadre of lead engineers or product managers, in a bank it could be the bankers and/or traders, doctors and scientists in pharmaceuticals, geologists in oil companies, and so on. Once you have one or more of these groups behind you then you get other management onside as a result. 

You get this support by being useful to them and aligning the importance of security with the core of their mission - in their words. For example, showing them what you do liberates their work, opens new markets, and is supporting them behind the scenes without unnecessarily impacting their work. It might also be connecting organization dots where one area is doing something that could benefit them, or coming up with ideas for their business or customers. These might not be awe inspiring ideas, but often the simple act of trying builds powerful connections. 

There are many other natural allies to leverage as well, for example working with (rather than in conflict with) the internal and external auditors is useful, as it is with other risk and compliance functions. The accounting and finance teams are natural allies to embed security into their world-view of key controls and cost allocation.  Customer marketing and even investor relations teams are also worth working with to make security a key part of their message which in turn encourages a wider base of support. For example, if the people of your organization see security being talked about by the whole organization positively and publicly then they'll be more inclined to be supportive.

Finally, one of the best approaches to keep the right relationships is to show people the results of their support. We often forget to do this. For example, if there’s an incident at a competitor that you haven’t been exposed to because of your security controls then send a note of thanks to the relevant leadership in your organization. Don’t say, “my team is great, we avoided this” which looks like you want a pat on the back. Rather, say, “thanks to your foresight and support for our security program we didn’t have this exposure”. It’s also worth doing the same for all constituents - imagine how powerful it would be to go onto the floor of the call center every month and give an award for not just the best customer service but the best response in avoiding fraud or supporting a customer through a fraudulent situation.

8.Deal with Reality

The biggest source of unhappiness and anxiety for any leader or team is to constantly compare the current situation to “how it is supposed to be”. I don't mean the idealized end state of security objectives, you need that as a goal to work toward, but rather how it is supposed to be in terms of implicit support, explicit funding and all the other things you might wish were automatically there. This is a source of unhappiness because “how it is supposed to be” is some fictional construct of the idea based either in your imagination or something fed to you by some research organization or vendor that no-one in reality is achieving perfectly. Remember, when you compare yourself you are comparing your worst to their presented best.

In every situation if you can confront the reality of that situation and then course correct to best handle that then you are likely to be happier as well as more successful in achieving some portion of your intended outcomes. For example, no-one gets all the budget you need or want. When you don’t then you can either think: “the organization doesn’t care, I can’t get anything done, what’s the point”, or you can think: “great I have more than I did before to now get more done and make a difference, I’m going to think of efficiencies, show I am a great custodian of those resources and then later ask for more by showing my team is a place where money is spent wisely to great effect.”

You also have to recognize that in all your internal dealings with people you are also dealing with emotions rather than cold-hard analysis. Despite all our theories for risk management the best equation I’ve ever come across that describes reality is Risk = Hazard + Outrage. This is not only a practical statement of reconciling how people think but it is also useful in purely economic terms as well. For example, according to Hazard you might decide not to mitigate some issue in some product for some period of time because the risk is actually very low. This might be correct, but to the outside world it might seem intuitively wrong and so you then spend large amounts of time and energy explaining this to your customer base, auditors, or other stakeholders. At some threshold, considering all that effort, it might just be easier and cheaper to fix the issue irrespective of the Hazard because the Outrage is driving you there anyway.

9.Align Responsibility and Accountability

You will likely all appreciate the crucial need to align responsibility and accountability - in other words align the ability to drive change with those who will feel the most consequences for not doing that. This isn’t an abstract concept. It’s something you have to enact every day in small moments.

10.Influence the Influencers

Everyone has a network of people they turn to for advice on something. So, when you’re working to influence a decision maker on something it’s not just about them. You are also working, whether you realize it or not, with their network of advisors. 

Sometimes this is very clear. It might be a deputy, their chief architect, a senior technical lead, or their local risk or compliance officer. What can be missed, though, is that it also includes people they used to work with who are now in a distant part of the organization that they still routinely consult with. Understanding this hidden network of influence is vital. 

I remember, a few jobs ago, I was pushing a difficult and expensive implementation of a unified authentication/SSO system for the enterprise. I was trying to get one particular business unit CIO on side. She was uncomfortable with the decision for various reasons, so I knew she was going to seek counsel from her senior team, who we’d already got support from. But, someone had tipped me off that she also always turned for technical advice to a person who was previously in her team who was now chief technical architect in a totally different business unit. We spent some time briefing him ahead of when he was to be engaged on the project anyway. As predicted, she called him, and he was immediately supportive. We even told him to tell her we’d done this as we knew getting such broad scrutiny was useful. She actually gave us even more kudos and support for showing this extra level of commitment to her decision making process.

Remember, published organization charts almost never actually represent the true organization structure in terms of influence. That has to be discovered by you.

11.Use Convening and Connecting Power

If you have some authority either by position, role power, tenure or other built up credibility you have the convening power to call together groups to discuss and work on things, and to generally set an agenda for some goal. Use it well.  

If you’re in such a position you are likely to be part of many distinct groups, committees, programs of work, internal and external associations. This puts you in a position of being able to connect people and activities and these will likely not just be security related - you should embrace that anyway as it will help you build your base of support. There are not many roles in an organization that are as well connected and plugged-in as the security role. It’s a waste not to use it. 

For example, in a prior role, a risk committee meeting I was at for an Asia Pacific business was pushing a particular system. The next week I was in an unrelated project meeting for a US business unit that could use the same new technology. I connected the teams together to realize some significant acceleration of the work that yielded significant market advantage. It was nothing to do with security, but I was the only common connector between those two situations. 

This is why you should pay attention in all meetings on all topics, not just your topics.

12.Knowledge Mastery and Confidence

To be successful in any organization you need to know your stuff and be confident in that. This might not mean, in fact it almost never will, that you are the expert in many things. If you have a reasonable span of control then you likely can no longer be a true expert at a lot of things, but you have the ability to master how to work across your and other team’s experts to get to an outcome. That is another example of the use of leverage. Your unique perspective is valuable. Be a force for optimism and work hard with your team on instilling that the goal is progress not perfection.

13.Develop Influencing Skills

Organizational politics is really just the study and application of influence skills over the peculiar machinery and culture of your organization. So, what are the most essential influencing skills:

• Be very clear on the outcome you want. Write it down in a clear way. If you cannot clearly state what it is you want then you’ve no chance of influencing others - except in a bad way.

• Understand the current situation: data, motivations, people, and environment. Do some research to find out as much as you can about the “system” you’re seeking to change. Often, what you want to do will have been tried before in various ways that you can learn from. Also, remember, some of the most irritating new people in an organization are ones who pronounce everyone is "dumb" because something is broken without finding out people have been working like crazy to fix that issue - but that there is a whole iceberg of issues under the surface that are making the work highly complex and time consuming. 

• Understand the “forces” that keep a situation current. Don't be frustrated at something not changing. Instead, be amazed that in a complex world, a situation is not already changing. Develop a better understanding of the forces and counter-forces that keep it that way. Sometimes, if you want to change something, the best thing is not to add more force, but rather remove a head-wind. There’s a great part of Kurt Lewin’s work in social science called Force Field Analysis that is worth applying.

• Communicate - in person and in various internal media. Appeal to people’s motivation and objectives. Find ways such that what you want will also help provide adjacent benefits or satisfy the commercial goals of the people whose help you need. Incidentally, in my experience, even if your case for adjacent benefits is not totally compelling the other person will still appreciate you trying anyway and be more likely to help. Use behavioral science techniques in how you communicate (e.g. social proof, story telling, branding).

• Present the message clearly and effectively - be precise and capture people’s imagination. Be as simple as possible (but not dumbed down). Be persistent - some problems are not ready to be solved - so be ready to re-present when the time or circumstance is ready. Refine/practice your pitches. There’s nothing so frustrating for a senior decision maker (or anyone for that matter) to see people who have obviously spent zero time preparing.

• Execute on your commitments. Establish credibility that people can trust you to get things done, on time, on budget and with care and attention for being a good team member. This is a force multiplier for you to influence in the future. In other words, you’re a good bet.

Bottom line: every organization has politics. Thankfully, it’s rarely toxic, but people who don’t understand influence have a misguided view that all organization politics, and the need for it, is inherently bad. You need to know how to work this in a positive way for the benefit of your program. This is mostly about influence in the context of your organization's particular culture. Observe others who work it well and learn from them. Put a professional face on your organization.