.webp)
The gentle art of management bashing
Andrew Blain, Managing Director
When the authors of the agile manifesto coined the phrase: “Individuals and interactions over processes and tools” in 2001, they probably didn’t foresee it being used as a blunt instrument in the emergent field of management bashing. It’s fairly common to hear phrases like “the frozen middle” and “command and control management” in agile circles.
Leadership is not really a science. We have data that tells us what good leadership looks like and we have tools that tell us whether a leader is exhibiting the right behaviours, but science will never be able to predict whether a leader is the right fit for the individuals that they are leading in the prevailing culture and context. Steve Jobs would likely have been an utter failure if he had to lead the accounts department for a supermarket chain.
In stop calling software development complex I described how software development moves between Cynefin domains over time, usually in the following manner:
- Complex - novel problems without a solution start in the complex domain, the true field of innovation
- Liminally Complex - at some point one or more viable solutions will emerge. We will begin to see the emergence of thought leadership and passionate evangelists
- Complicated - Experts will emerge who can bring those solutions into the mainstream, sharing patterns and tutorials, and exploring synthesis of ideas and integrations with other solutions as the solution becomes part of the broader ecosystem
- Clear - Until finally commodity solutions will be widely available, simple enough for a novice to use without guidance, and easy to integrate with other things that exist.
The complex becomes the obvious with time as people solve problems and share their solutions. Furthermore, things move rapidly.
When people talk about increases in Volatility, Uncertainty, Complexity and Ambiguity (VUCA) faced by leaders, they are in part referring to the increased speed of the transition from complex to obvious that we are seeing due to the speed at which information can propagate in the internet age.
However, there are only patterns here, not rules. To quickly reillustrate that point I’ll give an example:
In my early days as a software developer I worked on a piece of software that gathered and indexed business article abstracts. The software itself was relatively straight forward. We gave our customer what we felt were good estimates and those estimates proved fairly accurate. We deployed the software and successfully on-boarded the initial client set.
Everyone was happy.
That is, until we on-boarded their final, and most important, client…
This was the early days of the internet and unbeknownst to us they had disabled JavaScript in their environment because it had been deemed it a security risk (quite funny in hindsight). In their environment nothing would work. The client blamed the customer. The customer blamed us.
The issue required a significant and costly rebuild of the user interface. My manager at the time had to convince a relative software novice (who is now a television host and sporting club chairman) to pay for the additional work. I don’t envy him for that task.
The example above had all the hallmarks of a complicated problem — we’d seen the problem before, we knew the patterns, we followed a tried and tested approach. The complexity was in the broader environment and it was discovered late.
Given what I know now about agile our approach would have been different. We would have built a minimal viable product and deployed it into the production context as quickly as possible. Our estimates would have been constantly refined based on the information we discovered and we would have had constant dialogue with the customer about how we were actually tracking to plan based on working software delivered into production. We also probably would never have built some features — they seemed like good ideas but had very low usage in production.
However, we still may have hit the same issue. While this seems like a case of a missed non-functional requirement, it is likely we still would only have discovered the problem when the third client was onboarded. I haven’t heard of any other companies that turned JavaScript off — it simply wasn’t a question we would have asked. This was not a lack of expertise problem (a failure mode of the complicated domain), it was a lack of a crystal ball problem (a failure mode of the complex domain, discovered with the benefit of hindsight).
I remember at the time noticing subtle changes in my manager’s leadership style as we went through the process:
When I’d started with the company he had set me what seemed like an impossible problem for someone just out of school. He basically gave me a book and a computer and told me to build and secure a server, install a database, and build a website. I needed a few kicks up the posterior to keep me on track but in time I had built something that kind of worked.
It was at that point that he then started to introduce me to good design principles and patterns and I started working on client pieces. Phil’s approach was pretty hands off from therein — he gave me heaps of rope and lots of interesting new things to learn.
However, when we hit production issues his leadership style changed — he took over the process and worked with me to understand the issue, communicate it to the client and make sure we resolved it. I’ve reacted immaturely to controlling leadership at points of my career but in a scenario where things are broken it works great!
The point I’m trying to illustrate with that story is that the art of management requires an appreciation of context. Your leadership style and your approach to things like planning, estimation, policy and procedure development need to change as you go.
In order to lead effectively, it is crucial to understand the changing nature of problems and make domain appropriate interventions in a timely fashion. That is, leadership should be contextually appropriate to both the perspective of the actors in the system and to the nature of the task at hand. Some contextual leadership heuristics follow.
What leadership style best suits different problem domains?
- Complex - Inspirational leadership, you're asking people to challenge the possible!
- Liminally Complex - Intent based leadership, you're on a journey but the map is missing a lot of information
- Complicated - Collegiate leadership, you want to create a learning environment where experts flourish, share knowledge, and learn from each other
- Clear - Empirical leadership, you want to remove the waste, lower costs, automate, outsource, maximise efficiency
- Chaos - Command and control - authoritarianism is not an anti-pattern in a crisis
There is no ‘right’ way to lead. Management by numbers works great for repetitive work, but it’s utterly demoralising for knowledge workers. There is no ‘wrong’ way to lead. Command and control is great for returning a system to order, it’s just rubbish for product development.
There is no ‘one-size-fits-all’ delivery model or framework. Lean Six Sigma is fine for commodity business processes that are independent from knowledge work value streams, but it won’t build you an amazing new product.
… and this is before you introduce the challenge of understanding the individuals in the system.
Leadership is hard. Really hard.
I have always found it somewhat ironic that some of the most vocal in the community re: preventing management intervention in knowledge work are also the most vocal about the problems with management.
We need to be careful that we at the very least ‘know what we don’t know’ before we start casting aspersions on other fields.
---
Originally published in Elabor8 Insights, November 2018
---
Attributions: I borrowed heavily from the ideas of Dave Snowden (www.cognitive-edge.com) and Simon Wardley (https://blog.gardeviance.org/) in this piece, hope I’ve done them some justice.
