I typically don’t do book reviews, but this book was impressive and it resonated with many information security and risk management topics.
To take a step back, I’ve developed a distaste for business or management books. I used to enjoy various Stephen Covey and Tom Peters works, but the past decade or so has seen many books published that at best would be a Harvard Business Review article or even just a blog post. Some could even be a tweet.
“A New Way to Think” by Roger Martin is a great re-examination of various accepted business principles, like prioritizing shareholder interests vs. the correct approach of focusing on customers and employees and letting the results follow - which will then keep shareholders happy. There is no way this book could be distilled into a Harvard Business Review article mainly because it is actually a collection of such articles. Although, each has been expanded and collected into a consistent narrative. My only criticism is that the author shows a bit too much affinity to the companies he has consulted for. So, many of the examples are about Proctor and Gamble, but it still works.
He examines 14 areas, summarized below with some information security thoughts that I think stem from them.
1. Competition
It happens at the front line, not at the head office.
This chapter focuses on the need to think of competition as being what happens in the field serving customers. Of course, that is an obvious goal but it’s surprising how much of what occurs in many organizations is simply paying lip service to this idea. The main thrust is get out and see customers to figure out what corporate functions should be doing to add value to the field who sell to and support customers. In other words, how do central functions add value to the front line.
There are parallels here to information security, or any central risk function, in terms of thinking who your customers are. Is it the shareholders (and Board as their representatives) to reduce the risk of losses? Is it executive management both for loss reduction as well as enabling and supporting business growth or mission success? Or is it the wider employee base to support their roles? It’s useful to think of employees as customers so they are a natural ally in your security program as opposed to seeing them as an unruly force to subdue through more and more training and stricter policies. But, really, the ultimate focus is that the customers of the information security team are the customers of the organization overall.
2. Stakeholders
To actually create shareholder value, put customers before shareholders.
This is one of the less surprising chapters as I think it is becoming accepted that solely shareholder centric views are often counterproductive in the short and long term. The real oppporunity to is focus on customers and the employees who interact with them - with the right training, investments and team alignment to help employees help customers more.
This means the information security program should talk more about customer needs (internal and external). Some teams in technology or security product and services companies find this instinctively easy given the natural push and pull between them and the customer CISO. But, for many other types of companies this can be more difficult and requires the information security team to go out of their way to do more than customer interaction beyond the usual of responding to customer/vendor questions, audits and perhaps incidents. For all corporate functions, but especially information security, it’s worth visiting the front lines such as a branch/outlet, a warehouse, a manufacturing plant, production facility or research lab. There is always a surprising revelation about what your actions or inaction does to impair the ability of employees to serve customers.
3. Customers
The familiar solution usually trumps the perfect one.
Here the book goes into more depth on the need to support customers with products and services that feel familiar rather than perfect (in the minds of product developers or corporate functions). This could include enhancing familar solutions, using design metaphors from other products and services or adding incremental features to existing products before branching into wholly new products.
The comparisons to information security here are well known, but again, often not always that well implemented. Making the secure path the easier path and embedding controls into processes so they’re an ambient part of customers' or employees' regular workflow. Another security parallel is to keep horizon scanning looking for issues, trends or other matters that it would be good to be early on. For example, at an organization I used to work for, we spotted the emerging risk of portable media (USB drives and such) having already taken steps to mitigate the risk of other portable storage such as CD/DVD drives. We decided to invest in developing our own software to control this well before such policy control was effectively available in the operating system or any third party products. It felt odd to create this familiar control (compared to prior storage controls) when it wasn’t an issue and clearly should have been solved in the technology product space. But, being 18 months ahead of the prevalent use of such drives avoided the enforcement problem of other organizations to adjust newly entrenched employee behavior.
4. Strategy
In strategy, what counts is what would have to be true - not what is true.
This is a great section, focused on the much discussed topic of strategy that is often done in name only, in the form of annual planning. Here, the author steps through a series of case studies on how to generate strategic possibilities, moving from issues to choice and then establishing the conditions for success - coupled with tests on whether those are achievable.
Ultimately, the real measure of strategy is what choices it encodes about where to focus. This is an imperative for the information security team and its programs as, with many risk functions, there are always more areas to focus on than time or resources permit. In these cases, the strategic choices are often about whether to federate or centralize, create pull from business units, or push mandates. It is useful to also decide explicitly on what balance of prevention, detection, response and recovery should exist.
5. Data
Creating great choices requires imagination more than data.
Data is the keystone of many organizations’ strategy, planning and overall decision making. However, an over emphasis on the data can lead to drawing the wrong conclusions. This is either because the data is limited or because the data is used in the restrictive frame of the current environment which blinds people to the wider opportunities. There’s an array of great case studies here from the creation of Lego Friends (from the data that boys use Lego more than girls, to the insight that girls - in general - prefer collaborative play and thus did want to build - but in a different way) to BlackBerry’s first introduction pitched as a two-way pager (which is also a cautionary note about prior successes potentially trapping you in and old context).
I’ve seen many security examples of the use of data to power some insights, but they always required imagination to interpret the data and even more innovative thinking to frame the question. I remember one of the first applications, in one organization, of big data analytics (15+ years ago) on outbound web proxy logs to profile user agent strings. This discovered a significant insight in the proliferation of internal applications starting to make direct web pulls (obvious in hindsight). This led to internal work and work with the proxy vendor to put in place restrictions which ultimately led to a major reduction of potential data exfiltration risk.
Sometimes though, it’s the willingness to see where the data and models are failing that is the real success. For this it’s worth looking at a different area of risk: financial risk. During the 2008 financial crisis the firms that emerged relatively unscathed were the ones that observed a conflict in reality (observed risk profile and losses) with the models and took this as a conclusion that the best place to be was to retreat to safety and go “risk off” until the situation was understood. Other firms decided to stick with their activities and assume reality would ultimately conform to the models. Those firms either don’t exist anymore or have shareholders considerably worse off.
6. Culture
You can only change it by altering how individuals work with one another.
“Culture determines and limits strategy” is the arc of this chapter, in that strategy needs to be in line with a pre-existing culture. Culture is “how things get done around here” and signals who employees pay attention to, what they do by default in familiar or unfamiliar situations and how people and teams work with each other. If any new rules go against the culture then culture usually prevails. So when people say culture eats strategy for breakfast you should remember that is as much a warning as a salutation.
In our security world we are often seeking to change behaviors and so we need to pay particular attention to the prevailing culture so we can use that for amplification, or at least so that it does not inhibit any necessary changes we want to make. But in all cases what we need to do is create personal changes of behavior that are supported at the macro level. Let’s say our culture change goal is to really position the information security team as being a business (or mission) enabler - that is, as opposed to just saying it is and actually not doing what it takes. This involves much personal activity such as:
The CISO and the CISO leadership team having regular personal interaction with Business-unit information security officers (BISOs) and their teams or with other embedded / federated teams. Structuring this interaction as “what help do you need to achieve your business goals?” vs. “what are you going to report to me about how well you’re doing what the CISO team wants?” is a big positive shift.
Saying thank you to all levels of the organization when something worked well and was defended. The most powerful positive culture shaping of the security program I’ve seen is when executives are thanked for their prior funding of controls that prevented incidents when such incidents occurred at competitors. Of course, you likely shaped that and fought for that approval but the act of thanking all involved and connecting the results paves the way for more engagement.
Conducting (truly) blameless post-mortems and constantly seeking opportunities for improvement.
Have business leaders present their area's security at Board or other executive meetings, where they’ve obtained prior help from CISOs/BISOs rather than those people doing the presenting.
And, always seeking to find opportunities to create adjacent benefits as well as reducing secuirty risk e.g. reduced customer friction, increased developer productivity, increased reliability. In fact reframing this as not always necessarily reducing risk, but perhaps keeping risk as is but still refactoring the controls so that they have better adjacent benefits.
7. Knowledge Work
You must organize around projects, not jobs.
Here I depart a bit from my positive view of the rest of the book. I think he makes the mistake of assuming all knowledge work is the same, as opposed to jobs that are processes but for which each activity is uniquely different. Many things need to move from artisanal to industrial, but that doesn’t mean it is no longer knowledge work.
There are clearly many parts of the security (and related risk functions) roles that have a degree of fungibility i.e. people can do a project and move on to the next one. But many of, what he might call “projects” are in fact repeatable process tasks that require per task creativity but which benefit intensely from process engineering to keep transforming that activity. The key here is for security functions to maintain balance of their work across deep specialism, risk management and their ongoing operations. I talk about this “rule of thirds” here.
8. Corporate Functions
Give them their own strategies.
This was a revealing chapter for me. It made me realize a lot of security strategies I’ve seen or developed over the years were a strategy for the whole organization not necessarily a strategy for the security team itself. Many of the corporate functions I’ve interacted with over many organizations have been similar in that they have a strategy for what they aim to achieve or to drive the rest of the organization to but rarely have a strategy for their own team. In this sense it about the need to make strategic choices, but remember choosing not to choose is not a choice. In the chapter he distinguishes between the “servile strategy” where the function tries to be all things to all people. There are many security teams that end up like this simply because they have to take on more and more to cover more risks irrespective of funding levels. This leads to overworked people and underwhelming functions. The other approach is the “imperial strategy” which puts the function itself front and center and pays relatively little attention to how it aligns with the business, mission or overall company strategy. Then, frustrated business unit managers complain how this function consumes too many resources for little return.
So, when developing a strategy, focus on the strategy of the function and of the goal, not just the goal. Ask, what are the strategic priorities of the company and how is the function critical to that? Understand internal customers, determine where to play and think what does success or “winning” look like. Then align around that. Remember, strategy is about choice, or as the book says: “Strategy is what you choose to do and not do in service of a particular goal.”
Some examples in the security space could include whether and what you decide to centralize vs. federate or embed in different units, whether you expect consistency of control implementation or just consistency of risk mitigation levels, and are you going to be a solution provider of tooling and frameworks vs. a definer of polices and measurer / modeler of risk.
9. Planning
Recognize that it is no substitute for strategy.
One of the threads running through this book is getting people to think harder about what strategy development is vs. doing planning and calling it strategy. He makes the correct point that strategy involves hard choices and so is scary. Planning in excruciating detail makes everyone feel better and less scared but doesn’t mean it’s effective: “If you are entirely comfortable with your strategic plan, there’s a strong chance it isn’t very good.”
True strategy is about placing bets and making hard choices. The objective is not to eliminate risk but to increase the odds of success and he maintains this is best achieved by focusing on three rules:
Rule 1: keep the strategy statement simple (which customers to target, how to create a compelling value proposition for those customers)
Rule 2: recognize that strategy is not about perfection
Rule 3: make the logic explicit (what needs to be true, then compare to real events and capabilities)
These rules can be cleanly applied to security on which risks to focus as well as which internal functions, business processes or mission areas to prioritize and how you can be of service to those. This is not just driving risk reduction for the enterprise as a whole, for example, if your goal is to reduce software security risk for, say, a business unit with crucial customer facing digital channels and in doing that your strategy is to improve tooling and developer agility so that it is more easily achieved. Then, you need to define what needs to be true to achieve that. Not just the shared OKRs, for example, but even the willingness of the teams to collaborate, the cultural affinity of the leadership, the day to day interactions between teams, a common work environment, and many other factors.
10. Execution
Accept that it’s the same thing as strategy.
Conventional approaches dictate strategy and execution are separate. If strategy fails blame the execution. If execution fails blame the execution. Strategy never gets the blame. In fact you hear a lot of people talk about a mediocre strategy well executed is better than a great strategy poorly executed. Here, he makes a quite compelling case that there’s not only no way to know that (how do you define mediocre vs. strong strategies) but also that a big part of strategy is to assure the execution. Every part of strategy should drive also the execution approach and, importantly, to get feedback from the front lines to adjust approach.
I must admit, when I think around at all the various strategies I’ve seen (or developed) over the years the method of execution is rarely discussed as part of the strategy. That is usually left for an execution plan which can be quite uncoupled from the strategy itself. That’s not good.
11. Talent
Feeling special is more important than compensation.
The book starts to run out of steam a bit here with the final chapters being more obvious than the earlier chapters, or perhaps these are the ones I’ve seen more natural attention to in our part of the industry. Many organizations have focused more broadly on retaining people by ensuring their alignment to mission and recognizing that managers and their performance can bind or repel people to or from teams more than any single factor like compensation. The book argues, correctly, that a big part of this is to make people feel special. This can include regularly reminding people of their specific contribution to the overall mission through to involving your senior / experienced technical or risk specialist leads in more of the regular management decisions that otherwise might have been confined to the main leadership team.
12. Innovation
The design of the intervention is as critical as the innovation itself.
This is yet another example of where it seems obvious that the application of design thinking and human factors is vital to any part of innovation. But, again, it is surprising just how few organizations generally consider this in their products. It’s good to see security teams, and security products / technology / cloud vendors thinking harder about about user experience and design in what we provide employees and customers. But we have much to do to enshrine this discipline.
13. Capital Investment
Assume that its value is reset as soon as it is embedded.
This is a (financially) technical chapter on how to think about capital investment in terms of not just capital but also its relation to current market capitalization. The theme being that the value of capital is reset as soon as it is embedded.
14. M&A
You need to give value to get value.
This is another one of those chapters turning conventional wisdom on its head. Again as a recurring theme, the explanation makes such sense that it is unsurprising until you look at the litany of failures in M&A. The lesson in particular is that acquisitions should focus less on extracting value from the acquired company. Rather, the acquiring company should add value to the acquired by increasing scale, connecting to new markets, giving access to new technology and lowering costs by the use of shared services.
The main lesson here for security programs, in general, is to take this stance when you think about integrating (or not) the security teams of business units in a push to centralize from a prior period of decentralization or in deciding how to approach the security team of an acquisition.
Bottom line: this book was a timely reminder for us to keep questioning our “standard models” of security and look to new approaches, where they make sense. I’d highly recommend this book to get you thinking about this.