Can we learn from 'Radical Management'?

What Agile stylised leadership can say about a security function.

Introduction

Agile was all the rage a few years ago. It seems like the sheen is starting to wear off and people are looking for something new to play with. DevOps perhaps, OKRs (Objectives and Key Results) seems to be having a renaissance of sorts, maybe even emotional intelligence (EI) now that everyone has discovered that asking more than a few people to follow a defined process is an exercise in futility.

But back when Agile was kinda new and shiny people tried it on everything. A gold rush of new jargon emerged, “fail fast”, “test and learn”, “positive disruptor”. Every cock up could be hidden with a platitude it seemed (minimum viable product anyone?!). One of the things that received the Agile treatment was leadership.

Look, it’s not that I dislike Agile per se, rather I have a distaste for the emergent zealotry that came with it. It was a form of jingoism that sought to become supreme over everything else. For a time, it was almost like a methodology nationalism with state sanctioned asymmetric hair cuts akin to an episode of late 90s Hollyoaks.

What can we learn from Agile Leadership in a security context? Let’s find out!

Agile Leadership

Stephen Denning outlined a leadership style in his book “The Leaders Guide to Radical Management” drawing heavily from Agile. Denning positions his ideas a being a radical change from current management methods however they aren’t quite as radical as is claimed. Although he eludes to this point himself when he says ‘there is nothing new here rather it is the combination of these elements that is new’. We are a couple of decades into Agile software development at this stage and what Denning might have considered radical has now been subsumed into the mainstream. Many of the terms like ‘self-organising team’, ’client driven iterations’, or ‘delivering value’ invoke a Picardian facepalm as they are pre-cursors to the deluge of corporate bullshit coming your way. Unfortunately, Denning’s intention and the real-world implementation of these ideas aren’t one and the same and the use of terms like Denning’s can be considered fuck-wit red flags in today’s world.

Denning makes the observation that Agile software development has been at the forefront of implementing the ideas he outlines for some time. Having worked in an ‘Agile adjacent’ environment for many years, and even spent a brief time as a Scrum Master (perhaps the most scathing of the methodology you have encountered) this is familiar territory for me. Denning’s whole section on iterative development is a cut and shut from scrum Agile with some of the ceremonies rebadged to generic wording. Denning is clearly an Agile evangelist in the truest sense of the word and lost my attention to a degree. What he advocates and what Agile advocates can barely be separated by a gnat’s cock. I’ll come back to the legitimate critiques of Agile which also apply to Denning’s Radical Management shortly.

But Denning’s linchpin principle is that of delighting clients’ which riffs on the beat that many others talk about. The thread that binds a lot of these concepts together is investment of interest, time, attention, into others to optimise the relationship. When Ryan Holliday talks about suspending Ego, the Adlerian philosopher talks about how all problems are those of interpersonal relationships, John Maxwell on how leading is serving, Robert Greene in the laws of power on working the hearts and minds of others, Jordan Peterson on assuming the person you are listening to might know something you don’t. These all have the same thematic undertones, but the unique point Denning brings is the concept of delighting customers.

There are many notable conceptual shifts which must be achieved to successfully deliver against this type of approach. I would assert that the following of most consequence.

1. The move from a task based to knowledge based must be understood by senior management. This includes the implications that work is not transactional and cannot be measured on units produced.

2. The implications of a move from a production to a knowledge environment must be understood by the employee regarding their responsibility and how they orient themselves within this type of environment.

Both are not easy to achieve.

The Black Pill

Denning references the red pill / blue pill as analogues for radical and traditional management. This is fine but there are some strong critiques that need to be levelled at Denning. I’m here to put some black pills in his Kool Aid!

When Agile is initially embedded within an organisation it is typically the most talented developers work on it, so it usually goes quite well. It is not the case that this will become the pattern when applied more broadly. The same results are not manifest when we ‘shift left’ down the bell curve if you’ll excuse my co-opting of vogue terms. As Agile scales then it falls under the closer scrutiny of senior management who require all the same metrics it did before. The quality of the available practitioners also degrades and those available will be encountering the Peter Principle.

Agile retains its vestigial components of a managerial, corporatised environment. Granted, some terminology has been exchanged more trendy words, but we are still dealing with management KPIs. Be it burndown, velocity, cumulative flow, story points or whatever, the point of fact is that there is a product being delivered, a process being followed. The proclamations of heterodoxy fall flat in the face of rigid adherence to ceremonies and expected ways of working and thinking. It’s not a tenable proposition to assert that you value diversity of thought when you have outlined what people should value.

The problem is that with this structure of empowerment and giving the team the responsibility of deciding how much work it can do also gives them a structure to create barriers. There is an irony that the conceptual stance of Agile being to value individuals and interactions over processes and tools, yet when applied, some individuals use the processes to obstruct others. An example would be Denning’s practice of not interrupting a team in the course of an iteration. How would the customers of a security function react if we determined that their request would have to wait until an iteration was complete? Or we decided that it was not a priority for the next iteration? Yes, prioritisation calls have to be made but we are dealing with the actual in the here and now, not the next thing that won’t be here for six months so we cannot afford to prioritise in the same way that iterative development in radical management requires.

The method creates an artificial barrier to having any interaction with the team and makes a mockery of responding to change over following a plan. This is how Agile pisses all over Denning’s chips. He might be well served to re-read the Agile manifesto as so much of what he advocates is orthodoxy yet contradicts the very principles of what he is advocating. In some sense I’d wish he’d maximised the amount of work not done when writing this.

Denning makes the point about traditional project management not delivering on time and attributes this traditional management style. I suggest that traditional (waterfall) project management failed for three reasons.

1. It wasn’t implemented correctly.

2. The quality of the practitioners was weak.

3. Shoehorning everything into the methodology (JFDIs became projects).

Agile will fall on the same sword as waterfall. It is not the panacea Denning thinks it is, but there are some useful lessons to be learned for a security function. Agile or radical management has been extended beyond it’s reasonable and appropriate boundaries. It has been applied where it shouldn’t be. I have seen security teams and support teams work in a scrum format. It’s a disaster. There are functions that it works well for but the application for functions that surround those is lunacy.

A security cannot function as an iterative team as Denning advocates due to the nature of the barriers it creates. It is hard to justify maintaining a backlog in the way iterative development requires.

But it’s not the whole tip that is on fire, just some of the bins.

The White Pill

All hope is not lost. There are some useful concepts posed by Denning. The principles and values on which he based his views are sound. The conceptual basis of Agile has great utility insofar that it does promote frequent conversations with the customer, the whole ‘frequent feedback’ schtick. This can be used by a security function to create and enhance relationships. Combined with the concept of radical transparency, this can be used to great effect to generate trust between the security function and its customers. The flexibility advocated by Denning and Agile is one that aligns to security as knowledge work.

One point Denning needs to be praised on is how he discusses diverse teams. He states that this is cognitive diversity and rejects diversity through identity measures. This probably hasn’t aged well for him but it’s a really important distinction to make. Additionally, he also highlights how too much difference in opinion then becomes counter-productive. For a security function that needs to solve complex problems, there can be an application here within the team composition on how other experts are engaged to work with the security function to solve problems.

How can security hope to delight anyone?

Security is not an area in which ‘delight’ is typically associated yet this is the foundational concept proposed by Denning. Delight, like security is an abstract concept that is intangible and grounded in the subjective interpretation of its recipient. As Denning articulates the following,

“Delighting customers is not only a requirement of business survival; it also offers a solution to the dilemma of how to articulate a morally worthwhile and inspiring goal that is closely related to what the organization does.”

Denning does make a point that it is mathematically not possible to maximise shareholder value and delight customers. There might be some legal sticking points here to consider in terms of how success for the benefit of its members (shareholders) should be interpreted if there is to be a sacrifice to shareholder value.

But it’s not obvious how the security work can elicit delight however we might hope to elicit that reaction through interpersonal relationships. What is clear is that delight is an emotional response, as is security. Adlerian psychology tells us that all problems are ones of interpersonal relationships. So perhaps then it is our interactions with our customers can gives them both delight and a feeling of security.

It’s a shame that security practitioners are perceived as an obstinate group within organisations given that the primary cause of security problems involves some form of social engineering. That is if you take industry reports i.e Verizon DBIR, UK Government Data Breaches at face value. But you will be hard pressed to find security practitioners who understand social engineering or psychology in any depth outside of ‘phishing is a form of social engineering’ found in the main certification texts. There are no widespread certifications with designations after your name to attain by learning this. It is not something that can be tested using multiple choice, it’s not something HR can screen for in a CV. Maybe the first improvement then is to readjust our recruitment methods within security functions to deprioritise knowledge of ‘iT SoFtWarEz’ and refocus on the actual skills required to address the problem of organisational security. If we grant that security and delight are emotional responses, what is our customers response to vulnerability scanners telling them that the world is burning? Do they feel delighted, or secure? No. The problems we solve are done so with knowledge, not with the creation or implementation of products.

If we look to Chris Hadnagy who has collated a social engineering framework from many prior sources, he repeatedly uses that motto “Leave others feeling better for having met you”. This implies a component of intention on the part of the security practitioner and frames a mindset for out interactions. But this collection of methods then, that we understand from the perspective of an attacker can be used to enhance our interactions with our customers. Whilst the social engineering framework is surface level in depth it does try to do something useful and that is articulate that there is a human element that relates to emotion and eliciting hormonal responses (oxytocin, serotonin etc) to elicit those emotions and build trust and rapport. That is a powerful insight that we can take the tools of the attackers and use them for something positive, although if we are being honest, humans have been good at these things forever but we have chosen to mostly ignore this in the security industry and debase ourselves with blinking lights. But this does reaffirm the need to be principled in how we apply ourselves as practitioners.

The Goal

The first thing that needs to be defined is the goal, what you want to achieve. As Denning notes many companies are oriented around selling products, maximising profit, or a public relations goal as reflected in their mission statement. Few, if any tend to want to delight customers. As Denning observes, the focus towards making the products and services orients the organisation towards the traditional mode of management that implies task or procedural based measures of success.

Given there is an implied relationship between the mission statement or goal and the emergent behaviours within the organisation it’s reasonable to assume that the initial positioning of the stated goals has a fundamental importance. This carries for a security practitioner as their principles and values are critical to their moral and ethical stance. It is unlikely that the security function would be in a position to define the mission statement of the organisation however they could define their functions mission statement or goals to support the organisation allowing the reframing towards delight. In this sense the security function can set the expectation as to how the practitioners delight their customers, who would typically be internal to the organisation.

Conclusion

Denning is a mixed bag. It’s frustrating how derivative Radical Management is from Agile, so much so that ‘this is not a management book’ rather, it is a replay of an existing methodology which holds a number of impediments when implemented. But there are some useful lessons here.

We start with the goal or mission statement for the team. Appropriate definition can drive the behaviours required to improve the functions interactions with the customers. This would need to be aligned to principles and values that are defined within the function which need to be established by consensus.

We follow then to recruitment and changing how this is done. The composition of our team is important in terms of cognitive diversity to create an environment that allows for high performing teams. The skills of the practitioner and how they are recruited into the function and trained whist in role is also important. This can no longer be ‘do this tech accreditation’ or that bullshit ‘security certification’. We need to dig more deeply and improve the quality of the practitioners we hire and cultivate. Our endeavour succeeds or fails on the strength of our practitioners.

How we construct and implement aspects of radical management has to be cognisant of the wider organisational context. What types of methodology will work with the IT functions, with the senior management, with the business to optimise their function and harmonise our interactions with them. There is no clear-cut answer here but what I can say is that the answer is not ham fistedly pushing iterative ways of working onto everything.

What Agile and Denning do well is articulate the mindset that is required even though the implementation outlined is wanting. By getting the fundamentals in place then a self-organising team will be able to surface the structures needed for a security function to succeed, have the appropriate level of customer communication, and the right checks and balances to review and improve the function. But this can only occur once the practitioners are trusted and responsible for improving the security function.