Managers and Management

My thanks to Marc Burgauer for spotting the discrepancy between my meaning of the words manager/leader and the common understanding. A true act of management. This blog is a pretty much straight up copy of the presentation I gave at the APLN in Autumn 2009. IT is based on this article published on InfoQ.

I have a problem with Leaders and Managers. I have a problem with the idea of anointed / appointed individuals being in control just because they were trusted rather than competent. I own it as my own problem as others do not have this problem.

To me, A leader is someone who engages in acts of leadership. A manager is someone who engages in acts of management. Leader is not a role or job title. Manager is not a role or job title.

  • Leaders are the guardians of the future.
  • Managers are guardian of the present (or rather the current processes).

So what does a Leader do? What are the Leadership tasks that are needed for a healthy organisation?

  1. They are responsible for the visionsssss. <– Note plural. Leaders ensure an organisation has options. Unlike leadership at Nokia that killed options for the future and left the company unprepared for failure.
  2. They prepare the organisation for the unknown. The classic tool here is scenario planning. Talking through scenarios so that the organisation can react when faced with unexpected events.
  3. They look for new risk and opportunities. They are scanning the environment for options.
  4. They give us time to react. By making us aware of these options, we have time to prepare.

So what does a manager do? What are the management tasks that are needed for a healthy organisation?

  1. They facilitate the creation of the process. They don’t own the process. They own the responsibility for the process. To ensure that it is healthy.
  2. They watch out for broken processes. They look for risk in the process that is unmanaged.
  3. They look out for gaming. Those that cheat in a transparent way so that the weaknesses of the process can be managed.
  4. They monitor and manage the known risks and opportunities.

The punch line of the presentation is…

We need fewer leaders.

Screen Shot 2015-02-22 at 10.29.25Screen Shot 2015-02-22 at 10.29.43Thats why I love the work Dan Mezick has been doing using Open Space as a tool to create communities of Leaders and Managers within organisations that want to change.

Risk Averse & Risk Managed

In Seeing Culture, I introduced the idea that a culture is “Risk Averse” or “Risk Managed”. It has been pointed out to me that I did not explain what I meant by these terms. I come from an investment banking background and that’s where my understanding comes from. Please shout out if the terms I use are unclear, it’s probably because of the finance language and that I never went to a public school to learn the propa meanin of werds.

Risk exists. Regardless of whether we are risk averse or risk managing, the risk is there. The difference is our approach to risk.

Risk Averse means that we attempt to ignore risk or get someone else to own it for us. Often risk averse individuals will feel powerless about risk and will attempt to hide it or deny that it exists. Risk Averse refers to our intent rather than our behaviour. The irony is that people who intend to be risk averse engage in very risk behaviour. When risk averse individuals take risks, they gamble. They make big bets and they take a punt. They ignore the risk and hope that everything will turn out OK. Sometimes it does, often it doesn’t. Managers get promoted because they are lucky. In fact, in a risk averse culture, the way to get ahead is do nothing and wait for those who do try something special to fail.

Risk Managed means that we manage the risks around us. There are many strategies we can adopt to manage our risk, which include:

  1. Do nothing.
  2. Monitor the risk.
  3. Make the risk transparent.
  4. Hedge the risk.
  5. Get an expert to manage the risk.
  6. Sell the risk.
  7. Buy insurance.

The point is that a risk managed culture attempts to make risk transparent and visible so that it is managed, whereas a risk averse culture will attempt to hide risk, ignore risk, or off lay it on someone else. Risk managed cultures attempt to understand risk so that they can manage it.

I recently ran a session on the role of the IT Project Manager (They are there to manage risk funnily enough). We ran an exercise where each group would pick a process point, and identify the risk it was meant to mitigate. Then they could suggest an alternative process to manage the risk. One group picked “Production Sign-off”. This was where the team got senior management to sign off that the software was fit to go into production. When we discussed what risk it mitigated, the answer was “The manager will get sacked instead of us in the event of a serious fail in production” The reality is that the manager would still sack you and is unlikely to be sacked themselves. The risk they are trying to address is a complex one “Failure in Production” and they are trying to address it with a Complicated Strategy, by going to an “Expert”, “Hippo” or “Authority” to cover themselves in the case of failure. They are NOT mitigating the risk of failure, only the impact on them…. And it does not do a good job of that either. The real risk was “How do we handle a production fail after release?” This is an outside context problem as we do not know what might cause the failure. We were then able to start developing options to manage the risk. A “Roll back strategy”, “Monitoring and failure detection”, “Phased roll out”. In effect, we need to develop systems that are resilient and robust. Sign offs are a sure sign that people are being risk averse.

Years ago I worked for a large multi-national. It came up that they did not insure employee’s laptops. “Why not I asked?” “It cost more to insure them than it does to replace the ones that are lost/stolen/broken” The risk was not ignored, it was quantified and the company decided it was cheapest to do nothing. This is why “Catastrophe Insure” exists. Some companies find it cheaper to not insure business as usual risk, but they do insure against existential risks. This was a sign that the organisation was risk managed.

The interesting thing about risk is that we can have a different risk preference for different types of risk. A company may be amazing at managing its business risk but then have a “Vendor assumes the risk” attitude to IT investments. They are blind to the fact that the vendor does not assume all the risk, and they are ignoring significant risk. Risk aversion often has to do with our understanding of a subject and the risk associated.

Most people are risk averse when it comes to their financial investments related to their retirement. They consider finance to be a scary and risky world. As such they will tell their financial adviser to invest in the safest or least risky investments. They will then gamble or have a flutter with some small proportion of their investments. So most of their pension goes into investments (Government Bonds) that will provide a return just above or just below inflation. A small proportion will then be invested in a start up. A more balanced approach might see someone investing in an equity pension. The great thing about equity pensions is that they go up when the market goes up, and they go down when the market goes down. People check their pension performance once a year when they get their statement. Most people investing in a pension do not know the track record of their financial adviser, and they do not know the name of the person managing their pension fund.

Risk takers invest in hedge funds. They know the name of the trader running the hedge fund. They probably know the trader personally. In fact, they were probably the trader’s manager when the trader worked for an investment bank learning their trade. Each day they will check the price and risk profile of the fund. The hedge fund will be expected to make money when the market goes up AND when the market goes down. The investor will expect an appropriate level of return for the level of risk they are taking. They do not ignore risk, they learn about it.

So here is the punch line. ALL cultures should be risk managed. There is no excuse for being risk averse. As companies, the risk most people are concerned with is “Will I be fired?” as they think the company is big enough to survive on its own. Most employees do not think “Will the company go bankrupt?”. The reality is that large companies now go bankrupt. Fifteen years ago investment bank made money out of “over-supply” in a market through juicy merger and acquisitions fees. Companies did not go bankrupt because banks did not make money out of bankruptcy. The problem with M&A revenues was that they were lumpy and were not predictable. Fifteen years ago an innovation called Credit Derivatives came into being. Investors pay Investment Banks an insurance premium to protect them when companies go bankrupt. Now investment banks can make money out of bankruptcy. Not only that, but is a steady predictable income stream. A few bankruptcies now and then are good for business.

It also explains why smaller companies tend to have a culture that manages risk. The biggest threat to your salary is that the company goes bankrupt.

Sorry its a long blog post, I did not have the time to write a short one.

Culture and Needs

Thank you to Bob Marshall for inspiring me to write about needs with his work on the Anti-Matter principle. I feel a sense of sorrow when I read the anti-matter posts as I get a strong sense that Bobs needs have not been met. Also, that he may not have met the needs of others and that satisfying the needs of others might be a bit of a revelation to him. Its a hypothesis and I would be delighted if someone could show I was wrong.

When we go to work I feel that there are several different groups who’s needs need to be met. In no particular order, those groups are:

  • Employees (my colleagues) from the CEO all the way down
  • Employee’s family and friends.
  • Customers.
  • Providers and Suppliers.
  • Investors in the organisation.
  • The community in which the organisation exists.
  • The environment.

In order for an organisation to have a long term healthy and viable future, all of these needs have to be in balance.

For customers, the focus is on user experience, but sadly that is often only the case in situations where users have choice. In user experience, we talk about “user needs”, “jobs to be done” and “job stories” to reflect needs. Some much loved companies focus on their customers at the expense of other groups. For example Apple is famous for being focused on the needs of its customers but not the needs of its employees (especially those working for suppliers in China).

Some organisations focus on the needs of the “shiny” employees. Classic examples include Hollywood Studios, Premier League Football and Investment Banking. This is at the expense of the Customer, other Employees, Investors and the Community.

The needs of the organisation (investors) are often expressed in the form of business value.

My point is that needs are quite well understood. Its just we don’t just always call them needs.

Quite often, when we talk about needs, the group we feel gets ignored is the employee. And normally we mean ourselves.

In a risk averse culture, the organisation and its management/leadership will quite happily ignore risk. This is often evidenced because they ignore the needs of one or more groups. In a risk managed culture, the organisation and its management/leadership will always be on the look out for new risks. It will then ensure that those risks are managed in the most appropriate manner (including monitoring them but not acting). In a risk managed culture, you make sure that the needs of the different groups are balanced according to the context.

As an IT Risk Manager you know that the most significant source of risk arising out of your teams come from the individuals, relationships and groups. As an IT Risk Manager you understand that the best way to manage those risks is ensure the individuals, relationships and groups under your care are as healthy as possible. It is important to know the people you work with well enough to know that their needs are met, otherwise there is a risk that they will be become ill, or their relationships will suffer. You have to care about your colleagues. Personally, I find the best way to care is to first get people out of the office, and then share with them as they share with me. In other words, put them in an environment where they feel human and then treat them like a human rather than a colleague, or an employee, or a boss, or a subordinate. For this, I am eternally grateful for the numerous coffee and tea houses around London.As for my needs… I write this blog to share my experiences and ideas. My needs are met when people show appreciation, or challenge me with feedback that is useful to help me learn and evolve my thinking so that I can better meet my own and other’s needs. My needs are not met when I receive negative feedback that provides no guidance or insight to help me improve. I consider those that judge harshly or make cruel comments without providing useful feedback to be Internet Trolls. After a pattern of behaviour I tend to ignore those individuals. Does this post meet your needs?

Changing Culture

Seeing Culture touched on the phenomenological* aspects of Culture. This post offers a hypothesis on an epistemological* approach to changing culture. For now, I intend to ignore the ontological aspects, or rather “What Culture really is”.

Sense maker is a tool for understanding culture, and identifying weak signals. When it comes to culture there are weak signals, but they are often strong signals according to other cultures as well. This post is based on Dave Snowden’s idea that the way we change culture is create more cultural agents (stories) like “this” and less like that. So how do we create stories like the ones we want? When we talk about cultural change we mean moving the culture in a particular direction. It might mean moving a traditional (or risk averse) culture to an innovation (or risk managed) culture**. I hypothesise that the cultures of organisations naturally tend to move towards risk averse as they scale and the challenge is to move towards risk managed (innovation). We could use Sensemaker to find the stories but I propose a hypothesis that we can create stories based on our ability to see the different cultures. This is a complimentary approach to Sensemaker rather than a competitor. As the opportunity presents itself I will test this hypothesis and it would be great if you could as well (and feed back your results). It will form part of the Cukeup session I will be running in March.

The approach is quite simple.

1. Help managers / leaders to see culture using the behaviours in Seeing Culture. Get the managers to practice and reflect on seeing culture.

2. Once the managers / leaders can see culture, get them to agree on how to address each behaviour. In Cynefin terms, where to add or remove energy. This is to ensure consistency. e.g. When to praise someone privately / publicly. When to rebuke someone privately / publicly. When to coach someone privately / publicly etc.

3. Get the managers / leaders to mine and share the right kind of stories. The difference between this approach and Sensemaker is that we generate lots of options and let the fitness landscape choose which stories propagate. Sense maker is more precise approach to identify the stories with the most agency and impact. The difference is that between a shot gun and a sniper’s rifle… complimentary rather than competing. And to be effective, both should be used. ( I am keen for feedback from experts on Cynefin on this point )

4. Use Sensemaker to scan the culture for impact.

This is a hypothesis I will be testing. Please join me and share results.

More importantly, please tell me where this hypothesis is flawed. I would prefer to fail it early so that I can find and develop another hypothesis.

* – For Dave Snowden’s benefit so that he can see I have actually been listening.

** – People take risks in a risk averse culture. Its called gambling. Individuals and groups in a risk averse culture have an aversion to risk and tries to ignore it or transfers it others.

Seeing Culture

I have never been that interested in Culture. Like the law, politics and economics, culture was something I never needed to learn about. My roles were delivery focused which is a short term activity. As an Agile Coach, my goal is also the long term improvement of the organisation within my scope.

Culture is important to the long term health of an organisation. Peter Drucker said “Culture eats strategy for breakfast”. It also eats any attempt to improve an organisation. Some aspects of a change initiative will align with the culture and will take root. Aspects of the change initiative that do not align with the culture will be chewed up and spat out.

The problem with Culture is that it is invisible. Whenever you join a group you might notice that some of their behaviour is weird or strange. If you do not adapt to the culture, you will be rejected and it will spit you out. In order to survive in the group you start copying the behaviour. Your accent changes so that you say certain words in the way that dominant individuals in the group say them. After a while you don’t notice the differences anymore because you have been assimilated into the culture. This is where ethnography and anthropology comes into play, professionals skilled at such matters can “see” the culture without becoming assimilated into it, and record it in ways that others can see it. Unfortunately I’m not a professional ethnographer or anthropologist. Most of us do not record our initial observations. Inspired by the work of Dave Snowden, I’ve been applying a variant of Cynefin/sense maker/distributed ethnography whereby I record the things that other people and myself note as “weird or strange” behaviour. Each “weird” example has a corresponding normal behaviour. (If you have other examples, please leave them as comments.)

To help me structure my thoughts, I adopted Hofstede’s Cultural Dimensions as a model (Olaf) to classify the observations. I used “break the model”, from Feature Injection, to apply the behaviour examples to the Hofstede’s model. So far there are a few hypotheses. These are:

1. Most important. Uncertainty avoidance is better understood as “Personal risk appetite” with “risk aversion” and one end of the scale and “risk managed” at the other. “Risk averse” means that individuals ignore risk or attempt to put it on others. “Risk managed” means that individuals seek to place risk in the best place for it to managed for the sake of the organisation.

2. “Risk Appetite” and “Power distance index” are heavily correlated, quite probably causally linked. Many of the examples could easily have fit in both dimensions. They seem to be the most important dimensions.

3. Most risk averse organisations have no mechanism to manage risk. Their culture prevents it.

4. Organisations need a healthy balance of culture, with the ability to manage risk. Risk managed cultures can adopt a risk averse approach. Risk Averse cultures will probably need an exogenous event to shock them into risk managed. It is likely that the shock will result in a dangerous “gambling” culture rather than a risk managed one.

I am now using the examples in the Hoftstede model form hypotheses about cultures. In other words, it helps me to see culture.

The next step is to help managers and leaders to see using the model so that they can act on the culture.

Below is the model (Olaf)…

Behaviour, Symbols and Process

<This is a horrible table. I will fix it when I do not have to do my chores>

Dimension Traditional Legacy Innovation Org
Power distance index Managers have offices. Managers sit with the team.
Introductions are managed through the hierarchy. Employees talk to whoever they need to do a job. Management is kept informed.
Frequent reference to grade levels during conversations. Frequent reference to capability and experience.
Deference to power. Deference to experience.
Decisions pushed up the hierarchy.(Inward looking approach) Decisions pushed to those closest to the customer.(Outward looking approach)
GeneralistsAs people without detail are making decisions, Phrases such as “Use Smaller Words” or “That’s sounds academic” are used. Generalising ExpertsTendency to inadvertently use technical terms that reflect their expertise

( Pivot, Hypothesis )

Bigger slower teams. Smaller faster teams.
Maintain status quo. Challenge status quo.
Titles reflect status. Titles reflect skill sets.
Manager review 360 reviews
“Because I say so” “Lets discuss that”
Individualism ( vs Collectivism ) N/A N/A
Uncertainty Avoidance Uncertainty resolved by deferring to expert (higher authority). Uncertainty resolved through hypothesis testing.
Slow build of “Robust” Solutions.(Plan Driven) Fast build of Resilient Solutions.(Responsive)
Outcomes are knowablee.g. Feature XYZ Outcomes are emergente.g. Reduce Churn.
Outcomes are binary (Success/Fail)e.g. Build Feature XYZ Outcomes are analogue(Scale)

e.g. Reduce Churn

Experts decide. Multiple Hypotheses tested in the market.
Risk Aversion to change. Rapid change.
Cost reduction. Customer value creation.
Powerpoint presentations. White board discussions.
Project Plan. Stickies on the wall.
Reliable with basics. Learning junkies
Architecture / Business Centric. Customer Centric.
Assumption. A classic risk avoidance mechanism. Hypothesis. A risk engagement mechanism.
“Vendor assumes risk” Risk managed by most appropriate resource.
Solution Focus Problem and Market Focus.
Managers regarded as controllers and masters Managers regarded as resources by their teams.
Opaque process. Only understood by the initiated. Transparency
Do the right thing for yourself regardless of cost to company. Do the right thing for company regardless of cost to self.
Internal Reputation. External Reputation. “Portfolio”
Punishment for Failure ·      Forgiveness for non negligent failure·      Learning expected from Failure (Retrospective culture)

·      Punishment for negligent failure

Get your boss to sign off and absolve you of blame. Taking responsibility and ownership of your actions.
“None of your business” “We need everyone to identify risks.”
Hate not knowing a valuable tool so devalue the tool. Delight in finding new tools and knowing you have a set of tools to learn. (Like the anticipation associated with Christmas).
Cannot delay gratification of resolving uncertainty. Understand value of delaying gratification of resolving uncertainty.
“Nothing to learn”. Huge backlog of things to learn.
Work is Perfect Work is good enough
People are good enough People aspire to perfection
Follow a script. Self Determination
Low cognitive load High cognitive load
Theory lead Praxis based
We can’t do that How can we do that?
Statement Discussion
Masculinity ( vs Feminimity ) ** Aggressive Passive
Safe Innovative
Control Responsibility
Long Term Orientation ( vs Short Term ) N/A N/A
Indulgence Versus Restraint Cost focus Value focus


Managing Conscious Incompetence – Looking for experience reports.

If you ever go to the Extreme Tuesday Club you are bound to hear the following conversation…

“I have a huge backlog of books to read”… “Yeah, I know. I’ve had to move my backlog to Kindle as I was running out of space”.

This conversation reflects the delight that the people at XTC take delight in their ignorance. When someone discovers a new idea, its added to the backlog of everyone at XTC. I’m thinking that XTC might be the only true learning community that I’m a member of.

As a coach, I find the Conscious Competence model to one of the most useful tools in my toolkit. It is also one of the most misunderstood. Conscious Incompetence means that someone is aware of an idea, AND that they value the idea. In other words, they understand “Whats in it for me?”. That backlog of books is a public indication of your ignorance. Its a public statement that there are ideas that you value but you do not know. I believe it was Plato who said our knowledge is a circle, and the circumference of the circle represents the things we do not know. The more we know, the more we realise we do not know.

In risk averse cultures I’ve observed that people do not want to admit ignorance. They tend to want to learn privately. This may be because there seems to be a correlation between risk averse cultures and those with a high power distance culture. In high power distance cultures, official status is about perception. If you admit that you do not know about something that it is valuable to know, and that someone else knows that, you are lowering your status. As such you will state publicly that the thing has no value, or that you already know it… until such time as you have developed the skill

So here is the hypothesis (theory). Could a community where people have a public backlog of the things they do not know but that they value be an indicator of a learning community. Another hypothesis. Could a public backlog of things to learn be used to tip a community’s culture from risk version to risk management?

One of the challenges of creating an Agile community is shifting the culture from risk averse to risk management. Is the creation of public learning backlog something that coaches and leaders can do to help this shift? I have been part of sessions where attendees create a skill market. Where they publish the things they want to learn, and the things they can help others learn. These have tended to be one off events. Does anyone know of a group that has published their learning backlogs?… and was there any impact on culture? I’m also interested in stories of failure, where the publishing the learning backlog has lead to more risk aversion.


I am a slow learner. My learning style is very slow and experiential. The most valuable things that I do not know are:

  • User Experience ( Looking for a good map of this rather large subject )
  • Culture ( Looking for a good practical guide )
  • Ethnography ( I’m still looking for a good introductory text for the practitioner )
  • Anthropology ( I’m still looking for a good introductory text for the practitioner )
  • Cynefin ( I’m attending the Sense Maker training course in January )
  • Complexity
  • Sense Making

Technical Debt is Risk Management

A few years ago I was lucky enough to work with Steve Freeman. Steve is the Gordon Ramsey of Software Development. If you have a badly formed code base, expect to hear about it. Steve worked with the graduate, Mark, on the team to “refactor”* some code. They created tests that clarified the intent of the code. Most impressive to me was that they reduced the size of the code base by 80%. Imagine you are editing a 200 page book with random duplication. Steve and Mark’s work reduced that to 40 pages and removed the unnecessary duplication. Everything was where it should be, and you only had to find something once rather than find a random number of instances. (Note: Some teams print off the code they delete and put it in a “book of dead code”) This was vital work as we were about to make significant changes to the code. The refactoring they did was pure risk management. It meant the chances of missing a necessary change were reduced as previously the code had been cut, paste and tweaked to death. Delivery risk ( endless looping in the test phase ) was reduced, and the risk of missing something in testing that damaged the production business was also reduced.

In Commitment we use the analogy of a kitchen to describe technical debt. A clean kitchen is one where things are in the place a professional chef (e.g. Gordon Ramsey) would expect them to be and it is stocked and ready to go. A kitchen where things are in the wrong place or the utensils and surfaces have not been cleaned and put away has technical debt as the chef needs to clean up and prepare the kitchen before they can start. The clean up and preparation is normally the first thing Gordon does when he visits a kitchen on one of his shows.

Each team will have a definition for good code. A definition of where things should be. Anything that does not conform to that standard is technical debt. Working on code that contains technical debt introduces significantly more risk than code without technical debt. The risks introduced include:

1. Delivery Risk. Technical Debt tends to blow up in the test phase where it cannot be managed, only responded to. The project Steve and I worked on was plagued by a team that did not have automated tests. The same bug resurfaced several times due to a lack of regression testing.

2. Business Case Risk. If the code contains technical debt, there is more likelihood that it will behave in an unpredictable manner and the changes will not deliver the value expected.

3. Risk to existing Model. If the code contains technical debt, there is more likelihood that it will fail in production in a way that damages the existing production system.

As such, from a risk management perspective it is often prudent to pay down technical debt before making changes. This is where Steve’s suggestion that the team regard the code base as a portfolio of sold call options is really useful. For each component of the system, the team can identify how much technical debt exists. The measure for the technical debt should be how much effort it will take to pay it down. This effort should consider how complex the debt is, and the staff liquidity matrix, namely how many team members can work on the component.

The product owner can then create a “tornado map” where they map out the high level road map for the next six months to a year. The further out, the more uncertainty there is. Using the tornado map, the product owner and team can work out which technical debt should be paid down now and which can be left. In some cases the technical debt may take a long time to fix, or contain too much complexity to estimate effectively. In those cases, it may be necessary to pay down the debt early. In other words, risky option positions should be closed down early.

Technical debt is much to do with the skills and perception of the team. One team may consider their code base to be clean whereas in reality it contains a lot of risk. As such, it is necessary to hire someone experienced at identifying dead code.

Like Gordon Ramsey, good developers don’t create so much technical debt in the first place, so it is cheaper to hire good developers in the first place so you do not need to pay for dead code. So my advice to you is to hire Steve Freeman, the Gordon Ramsey of code bases, for his sixth sense about code, someone who can say “I see dead code”.

* It was not a refactoring as there were no automated tests. Part of the process was putting the tests in place.

As suggested by Steve Smith, here is an example of what a Tornado Map would look like.

Although I apply this thinking, I have not created a map. This is the what the one in my head looks like that I use for this purpose.

Screen Shot 2014-12-31 at 15.53.24

The backlog is down the side with the Epics grouped into those expected to be done in the next month, quarter and year.

Across the top are the components of the system. I would expect them to be similar to those on the skills matrix for the team. The technical debt is displayed below each component. It is expressed in team weeks (i.e. SWAGs).

From the example, you can see the most immediate problems are the loader and especially the build system.

After the build and loader are sorted, the next problem is the blue component which will almost certainly be hit this quarter. The red component has less technical debt and might not even need to be changed.

Even though the yellow component contains a lot of technical debt, it is not going to be touched for over a quarter and is less important than the build system.


Get every new post delivered to your Inbox.

Join 69 other followers