Mike MacDonagh's Blog

Somewhere in the overlap between software development, process improvement and psychology

Category Archives: holistic communication

The Hybrid Dynamic Model

The Hybrid Dynamic Model is a modern approach to structuring an organisation’s portfolio that allows for multiple ways of working to co-exist from innovation to utility work and for that work to change which processes, cultures and practices it uses over time.

An “Operating Model” describes how an organisation does its business in terms of both its structure and its behaviour – it is the business architecture. An “Operating Model” exists in every organisation, whether it is explicitly written down or simply a collection of processes and practices. The Operating Model includes how strategy flows through planning and delivery, how money is spent and controlled, how governance works, how people are organised, how quality is assured etc. If the Operating Model is inefficient or unable to react well to change, everything else suffers.

Many organisations evolve an Operating Model that fits their stable way of working, allowing for a focus on efficiency and improvement, driving out variation. This approach can work well in periods of stability but makes organisations brittle and unable to react well to change because the only way the organisation knows how to deal with things is to apply its tried and tested approaches. When the environment is less stable, or the variety of work types increases a Hyrbid Dynamic Model is more appropriate.

A useful mechanism for understanding different types of work, and the different approaches that may be applicable to delivering them within a portfolio is the “Commoditization Scale”. The Commoditization Scale describes a range of types of work from innovation (undefined, rare, speculative and high risk) to more commodity/utility (well defined, ubiquitous, and less differentiated with lower risk).

These different types of work require different ways of working, contractual models, technologies, supply chains, cultures, processes etc. More well understood work is more predictable and manageable by its nature, whereas the opposite is true for less well-understood work.

Commoditization scale Commoditization scale inspired by Simon Wardley – CSC Leading Edge Forum

As organisations begin to understand their work in terms of a hybrid model they can then look to actively apply a commoditization pressure where possible moving work across this scale. Because commodity solutions (often bought in) are typically cheaper than in-house development, maintenance and hosting commoditizing work earns a “Commoditization Dividend” which can then be used to reinvest into the Innovation parts of a business.

As mentioned in Build or Buy we generally recommend against building utility or commodity components, systems or product (unless disrupting a service industry) – these kind of products are best bought or provided by open source alternatives (COTS). However in terms of inventing/innovating and specialist products different processes, working practices, teams and cultures may be necessary. Innovation work is typically riskier and speculative than more mainstream specialist products and so will be less tolerant of up front planning. “Failing fast” is particularly important in innovative/inventive work and this type of work is typically very unpredictable. As a result building significant structure (in terms of project, programme and Solution Architecture) around innovation work is unlikely to be productive – this work may also be unconstrained by Enterprise Architecture (and indeed “standard” ways of working).

Unless explicitly necessary we recommend that innovative work is treated as self-organized Product Delivery teams that are directly part of the Portfolio, with no programme structure. This (Small Picture) model is preferred for small, simple projects or organizations generally. Small organizations can often outperform large monolithic organizations due to their lack of process, management and architectural inertia – they are free to innovate. Since the relentless commoditization of technology forces all organizations to innovate to survive we strongly recommend freeing people to innovate in whatever manner they need.

There’s nothing worse for innovation than an ideas process

Similarly, and perhaps counter intuitively, there is also less structure required in the Utility and Commodity areas of the commoditisation scale (because the products built are often well-understood, predictable, related to system integration and frequently COTS). This type of very predictable work often benefits from workflow management techniques such as Lean, Kanban or service management processes.processes and commoditisation

Products that are more Specialist may need a “bigger engineering” approach depending on their scale or risk factors. Many large organizations will adopt more formal processes in this area as they seek to find economies of scale, especially around reuse. However over time reusable platforms and architectures can become a hindrance rather than a help. Technically skilled people will notice this point and are encouraged to Bubble Up their concerns. Organizations with significant effort in more than one of these areas of the scale above tend to gravitate towards a hybrid model with a structure embedded in the Specialist, Commodity or Utility part of the business. Applying the same structures, architectures, processes and working practices across all of these work types can cause problems so a hybrid model is likely to be required for large/complex organizations.

We recommend using a hybrid, dynamic model for organising a large/complex portfolio. Large, complex organisations have significant effort and coverage across the commoditisation scale. Implementation of a hybrid model caters for this variance using unstructured and structured models where necessary. Structure is introduced only by exception when explicitly needed to orchestrate effort across divergent teams and portfolio(s) not as the default approach. Importantly as pieces of work become more understood, or product sets evolve they will likely begin to move on the commoditisation scale and so may need to dynamically change their ways of working.

The Hybrid Dynamic Model allows for significantly different ways of working, within the cohesive governance of the H-Model of Holistic Software Development. Using the hybrid dynamic model organisations can have multiple ways if working, cultures and practices co-existing peacefully within a single enterprise portfolio. Using different ways of working, practices and techniques across the portfolio helps bring together the otherwise extremely different extremes of innovation and research work with predictable project delivery. Other business models, such as Incubation, can also be used to help bridge the gaps between areas such as innovation and mainstream engineering practices.

Hybrid Dynamic Model

Many organisations evolve a PortfolioProgrammeProjectTeam model which is then applied to all work in the portfolio due to its past success at delivering large predictable engineering projects. However, this model is wasteful when complexity is low and can actually inhibit communication and feedback cycles in more speculative work.

Programme and project structures cause layers of separation, which result in emergent transactional behaviour, effort duplication and confusion over roles and responsibilities. As a result programmes should only be used when there is a genuine requirement for co-ordinating multiple projects that must be integrated for a cohesive product family or business capability. In other cases programme structures should be condensed – removing programmes that are simply funding lines; Portfolio Management can and should manage funding lines and stand-alone projects can simply be part of the portfolio.

Reduction in structural complexity will reduce costs, increase flexibility and adaptability while simultaneously improving an organisations ability to react in a rapidly changing environment. Additionally, simplifying structure will reduce the sheer numbers of people involved in project management and definition work, removing unnecessary barriers between delivery teams and their customers.

This kind of hybrid structure is similar to using the Small Picture of HSD for the Commodity Portfolio, the Big Picture for the Specialist Portfolio and the Small Picture again for the Research and Innovation portfolio – naturally sharing the same Strategy and Governance layer.

COTS implementation may be a signficant piece of work by itself. The COTS Implementation article describes a variant of the Big Picture for use with COTS.

Advertisements

A man’s perspective on feminism in the technology industry

I normally avoid posting on controversial things but this is a topic that shouldn’t even be controversial.

The world is full of a marvellous variety of people and they come in all shapes and sizes, with a staggering range of ways of thinking. People are different due to things like gender, race, ability, sexual orientation, cognitive difference and all sorts of other things that affect identity. Importantly people are never just one of these things, real people exist at and between all of the intersections.

In the software industry we often rally behind people based statements such as “Individuals and interactions over processes and tools” and yet discrimination and unfairness are rife in the technology industry with “brogrammer culture”, sexist pay situations and the infamous glass ceiling. And yet we talk about being open and inclusive in how we do software in teams? And wonder why there aren’t more women taking technology courses at universities?

Feminism is a collection of movements and ideologies that share a common goal: to define, establish, and achieve equal political, economic, cultural, personal, and social rights for women. This includes seeking to establish equal opportunities for women in education and employment.

Women aren’t less than men. Men aren’t better than women. Instead people are just people, and each individual isn’t just a woman or man, they will be different in many other ways, expressing their identity, individualism and indeed diversity in each of them. There is value in diversity, and as people that can understand recursion we should be able to grasp that concept. The more ways we have of looking at a problem the better our solutions will be.

I believe that everyone should be treated fairly, that equal opportunities should exist for individuals, that if we need to differentiate between people (e.g. in terms of who to hire) that we should do it on merit, on skill, attitude and behaviours not on what makes a person different. I guess that makes me a feminist.

I’m a feminist because I believe in equality. Gender is one axis of difference that is used to discriminate against people and women are generally treated less fairly in the tech industry than men and so that’s why I’m a feminist not an “equallist”. I realise that this is an unpopular stance to take amongst some groups, especially those who are uncomfortable with a man using the word “feminist” but I think those people should take a good long hard look a themselves. If you’re not a feminist, you should probably go and explain why to your mother rather than argue with me about it.

Men, and women, and in-betweens and neithers, all need to stand up for equality, need to challenge unfairness when it raises it’s ugly guise. The amount of times I’ve seen sexist treatment, casual racist and homophobic language in the tech and gaming industry is shocking and it needs to change. Otherwise we can hardly call ourselves civilised. Of course, there are always weird situations where it’s not clear whether something is discriminatory or friendly banter – exploring those situations in an open and honest way, discovering if behaviour, language or tone has crossed a line helps us all understand each other better. Conflict is best avoided through clarity of understanding between people. Ultimately though the meaning of any communication is that which is received, regardless of the intentions. If you accidentally offend someone it’s still you who are offensive, not the victim who needs to grow thicker skin.

As men, we are morally bankrupt if we leave standing up for equality to those who are marginalised and discriminated against. Equality requires us to collectively act.

 

HSD Introduction SlideShare

Resonating social patterns with project processes

People are social complex agents, organising people is a bit like herding cats, however when people are working together collaborating in teams they can achieve amazing things. So why is it that some approaches and teams structures work and others seem to cause problems?

I’ve been thinking about things like nudge theory, servant-leadership, agility in software development, lean business, social business, serious gaming and agile at scale. Most people tend to think that these are all (or mostly) good things, they’re often desired bottom-up in businesses and support “faster, cheaper, better, happier” agendas. All good things that tend to be desirable at every level of a business and yet a lot of my work is about helping individuals, teams and businesses towards this simple agenda using these kind of things because although the goal is simple and the change is desirable, actually doing the change isn’t easy.

All of these things seem to “feel right” to people and are generally desirable and yet they are often at odds with traditional management techniques which tend to compartmentalise people and decompose everything into linear hierarchies.

So why is it that treating people like complex social creatures works better than treating them as simple functional unit? Er… because that’s what they are, people. I’d love to know why people think the opposite can ever work?

I think that the reason that the list of things up there is generally so successful at working towards faster, cheaper, better, happier business is that they are socially resonant. That is, ways of thinking about work such as agile software development are congruent with normal human social behaviour, that’s why they work.

Nudge theory acknowledges that people are lazy and don’t do what you tell them to. Delayed gratification doesn’t motivate most people so put things you want people to do in their way and gently nag them about it. Make it easier to do the right thing, make the wrong thing harder and more formal. The rise of the adult playground is a great example of this. People don’t want to be told what to do, they want their ability and contribution to be valued. Servant-leaders are ideally placed to nudge people, which they can do based on their personal social relationships.

One of the reasons that the agile movement has taken off as well as it has is because it treats people like people, in fact that’s in the agile manifesto! By aligning ways of working to normal human behaviour you are enabling your team to get on and do things intuitively, normally and comfortably.

Photo of east gate of Roman Forum

Photo by Mykola Swarnyk

I’ve been applying this kind of thinking to large scale project structures and that’s led to the Project Forum practice (think Roman Forum rather than phpBB!) which I’ve described as a “middle-out” management structure as it’s not bottom-up or top-down. Instead it’s more like a tribal council bringing together the leaders of other groups to an area where they can all have their voices heard. It’s democratic and social, it doesn’t pretend there isn’t any conflict instead it provides a vehicle to resolve that conflict. This structure resonates with democratic political structures from the tribal council all the way to parliamentary democracy.

In this model, the Project Manager has a pressure from the business to deliver and he gets to impress this upon the other members. Customers with a pressure for quality or short-term goals get to understand why their concerns need balancing with scope and resources. Contributing teams get to have their agendas and issues collaborated on by the wider group and can manage supply and demand of their resources. Wherever there is conflict the way to resolve it is through open honest communication, the Project Forum is that vehicle, providing a sort of open parliament. Yeah, I know it’s not a great name but I’m not good at naming things.

Most cultures have evolved away from autocratic dictators towards representative democracy in one form or another because that’s the way people want to collaborate socially. So why not apply the same model to large projects? Thousands of years of history already tells us it works.


This blog is part of a series on Holistic Communication: The linguistics of business change. Introduction, ethics and table of contents is all in the first post.

Scaled Agility: The Project Forum

This blog is an extract from the Project Forum practice: Holistic Software EngineeringThe Project Forum

When it might be appropriate

  • In situations where multiple competing stakeholder groups with different agendas are required to work together
  • In situations where multiple product groups need to collaborate on a bigger outcome
  • Where there is a conflict in direction, resource management/ownership or scope between collaborating groups
  • System of systems development

What is it?

The Project Forum is an application of agile philosophy to large project structures. Rather than impose a hierarchy of decision making from the Project Manager downwards the Project Forum is a virtual team in the middle of all stakeholders.

The Project Forum is a self-organising democratic group that balances competing voices and concerns, owns high level scope and architecture, runs the high level release train and performs integration activities for the product.

Use of the Project Forum practice does not prevent any communication directly between contributing groups it only provides a vehicle for that conversation when it’s relevant for the wider project.

From Traditional to Agile at ScaleThe Project Forum practice is an example of Agile at Scale combining social business practices, technical software practices and ways of working to make a simple way of doing big complicated bits of work.

Read more of this post

Social Business: Because people do the work

People, working together achieve business goals. Processes, plans and organisation charts don’t.

A group of people forming human relationships and interacting is often called a “team” but another equally applicable term is a “social network”. Add a common goal to do some work as opposed to sharing pictures of their latest cooking/pet/kid and you’ve got a bit of social business going on whether it’s recognised or not.

To get work done effectively you need teams to work together effectively and that means enabling the team to form relationships and collaborate together as a social network.  So how do you create an environment that fosters social networks focussed on achieving their goals and interacting with the wider organisation?

The answer to that question is variously termed “Enterprise 2.0” (which I hate), “Social Enterprise” and “Social Business” which is a little ambiguous as it could relate to a business incorporating internal social awareness into it’s ways of working but it also refers to businesses who are aware of their interaction with their external community. Both of these meanings are based on the same awareness, only the direction of attention is different.

Any business can be enhanced by enabling people to work well together through cultural changes, process (ways of working) changes and supporting tooling. Image a world where:

  • You have an idea to improve your business capability, talk to your work mates who are sitting near you about it who help you refine the idea a little
  • You post the idea on a general ideas list within your organisation adding some tags to relate it to general topics
  • Other people in the organisation react to your idea based on finding from a tag feed, an activity stream, their relationship (work or social) with you etc.
  • They comment on your idea adding relevant experience and knowledge
  • Someone else IMs (Instant Messages) you about the idea and adds some useful thoughts
  • The idea has formed into something that sounds like it might be worth the company investing some time in, you promote the idea to a company backlog.

So far none of this feels like “work” and yet a network of people are forming around an idea that improves the business adding their expertise and opinions, collaborating on and for the business.

  • The idea gets given some time to investigate so you create an online project area, inviting the previous contacts to have a look and interact
  • You decide to have a meeting to look at the various ways forward for the idea, two team members are remote so they video conference in
  • You blog the meeting minutes to the project area so other interested people can add useful insights
  • During the lifetime of the project various team members post status updates and blogs about the progress, customers and users interact directly through face to face discussion, virtual discussion threads, vote on requirements etc. while the team continuously radiates progress and quality information in an open transparent fashion.

This part was definitely work but socially aware collaboratively work making use of a range of technologies to enhance the team’s way of working.

This is an example of social business, and one which I’ve had for real with one of my clients. You might already have things like wikis, a blogging platform, micro-blogging, social group areas, project areas etc. in which case integrating them and driving cultural change through soft practices to “allow” individuals to interact in a trusted collaborative environment might be necessary.

Alternatively you might have none of these things, but don’t worry you can get them for close to nothing as there are several excellent open source solutions for each of the technology features mentioned, in fact some open source packages (Social Business Software or SBS) can do most if not all of the above!

What does a self-organising team really mean? Organisation!

The idea of a self-organising team is pretty established in agile software development, as a (post-)agile coach/mentor I sometimes find myself working with teams who are trying to self-organise. Here’s my approach for transitioning a team from being externally organised to becoming autonomous and self-organising.

The first thing to point out is that I believe that the result of a self-organising team practice is an organisation. I don’t know what the the organisation will be ahead of time, that’s what the team work out. What I do (and I think others should do) as an agile mentor/coach is:

  • Bring to the team methods and techniques they can use to self-organise
  • Information of self-organising and how to interact with other teams in an organisation
  • Experience of different structures and behaviours
  • Facilitation and support of the organisation

It’s not my job to organise a team, it’s my job to help them organise themselves.

Being an architect/designer at heart I take a simple approach to this kind of thing and think about it in terms of mission, structure and behaviour.

Mission

Team’s need to have a purpose. I believe in team’s seizing autonomy and declaring their purpose, even in a complex bureaucratic organisation. So long as senior management are willing to let people they employ to do a complex technical job actually do a complex technical job then there tends not to be a problem. Unfortunately it sometimes takes enlightened leaders to do this but I’ve seen more and more of them in both the private and public sector. A team needs to know it’s purpose and agree on it.

Structure

Structurally there are some nice ways of working out who should be in a team and what their role is. I recommend using competencies rather than roles. Competencies are a description of the skills required to deliver the mission of the team and come in levels ranging from the most basic to the most advanced form of e.g. Tester. Either grab some from a suitable process.

Get the team together and get them to score themselves on the range of competencies required. This achieves a couple of things:

  • Builds mutual understanding between team members of where the various skills lie and what level they’re at leading to mutual respect and avoiding misunderstandings around what people are “meant” to do
  • Establishes whether the team has enough coverage of the required skills for the job, without this knowledge how can a team commit to anything?
Competencies don’t need to be met my an individual, a combination of the individuals involved might meet the required competencies overall and that’s great when they, and the rest of the team, understand how they fit together.
An externally imposed organisation chart does not meet these goals.

Behaviour

Team’s need to know how they’re going to work so they need to understand their functions. As a starter I’d suggest that software development teams have the following functions:

  • Production (delivery of working product)
  • Communication (both internally with customers and with external stakeholders)
  • Decision making
    • Way of Working
    • Buy-in to the mission and direction
    • High level scope
    • Changes to agreed scope

A true agile team does all of these things as it includes all of the people and skills necessary (from devs, testers, users, customers, ops people etc.) to achieve them. The team is the vehicle for doing these things.

Each of these things is the tip of a fairly large iceberg. But the team need to work on understanding their Way of Working to do the production job. The team need to agree how they’ll communicate with each other and externally. Both of these are Ways of Working decisions. All function in a team comes down to decision making. Ways of working, communication techniques, scope management etc. need to be constantly refined which means you need constant decision making within a team.

Even buy-in to the team mission and direction (planning and/or technical) is a decision making process. It often happens implicitly with someone charismatic selling a vision and everyone kind-of nodding but that’s not the only way of doing it.

Different decision types deserve different methods

Just because a team is groovy and agile doesn’t mean that every decision should be fully democratic. For example when doing a customer demo to see if the product is on track it’s not normally open to a general vote on whether the product meets the customer’s needs or not. Usually the customer tells you and you have to put up with it.

I’ve written some blogs before on methods of decision making, methods for selecting a decision making model and some case studies applying all of this. The basic process is:

– identify the different categories of decisions the team needs to make
– identify (using a variation of the Vroom-Jago model) the mechanisms the team will use to make each decision type
– facilitate the decison making process reminding the team of their chosen mechanisms

Output

The output of a self-organising practice is an organisation. Since I believe in honesty and transparency I think that the best way to define and communicate this stuff is in a Team Charter. A Team Charter can simply be:

Mission

Some blurb about what the team does – Mission statement

Assertion of rights the team assumes – Autonomy

Who the team is

Who’s in the team, what’s their ability, how do they contribute to the required competencies – Structure

How the team works

A little bit about the practices the team uses. Such as using a continuous flow model, an iterative approach etc. Including the decisions the team makes and how they make them – Decision Making

If you’d like me to help your team self-organise get in touch. Do you have any other ideas on self-organising? Do you use a different approach?

Get your point across using positive statements

This is a simple one but amazingly important: use positive statements.

A positive statement is something like “to sprint you must run fast”. Conversely a negative statement is something like “to sprint you must not run slowly”. The problem with using negative statements is that for them to be processed by the listener the concept being negated (in this case running slowly) has to be represented first by the listener before being negated. Here’s two examples, one about software and the other about addiction. Then I’ll cover the more devious application of the technique before finishing with the positive application.

If you tell someone not to do something first they have to think about doing it, a bit like my purple penguin example in the introduction to this blog series.

Software

Here’s an example from software process training I used to hear regarding RUP phases: “The RUP phases Inception, Elaboration, Construction and Transition are not requirements, design, implementation and deployment…” This was a well intentioned phrase aiming to dispel a common misconception when risk-value lifecycles were first being introduced to classic waterfall minded managers. Unfortunately this sentence actually reinforces the misconception one and maybe two reasons, firstly it’s a negative statement meaning the listener has to make that link in their mind between these phases and the waterfall stages and then negate it. The second reason is that it’s too easy for a tired person on a training course to miss that key “not” word and totally misunderstand the trainer’s intention.

This happened to a colleague of mine who used this sentence and the client’s training manager sitting on the course mis-heard (swore they didn’t when challenged) and never used my colleague’s training services again.

Addiction

Imagine someone who’s going to give up smoking. Friends with decent intentions may say “Just don’t think about smoking” and yet the end result is that the listener has to think about smoking (linking in all of their anchored states).  In fact there’s a whole industry of negative statements around giving up smoking that are designed to make people think it isn’t an easy thing to do.

My first sentence might sound a little odd. Normally the phrase is “trying to give up smoking” but that’s because the word “try” presupposes failure which is why marketing folks have done their best to ensure it’s the normal way of talking about giving up. Just think of all of those adverts for giving up aids that tell smokers how hard it is. Sneaky.

The Sneaky Side

The problem is that a negative statement sneaks in a sliver of representation that counters the stated meaning. There’s a really insidious side to this when considering negative questions. Negative questions are any question including the word “not” (even in the form of a contraction when it’s even more sneaky) and they are a clever way of embedding pre-suppositions. Here’s an example:

“Don’t you think using positive statements is a good idea?”

Expand it out and it becomes:

“Do not you think using positive statements is a good idea?”

The second form of the question sounds very odd and unnatural. In fact it’ll confuse many people for a moment (excellent pattern interrupt) and yet the first form doesn’t sound so strange, and yet rather oddly people will almost always agree to a statement using a negative contraction. Magicians and mentalists use this trick a lot “Couldn’t you have changed your mind at any point?”, “Haven’t I been reasonably honest about …?”. And of course if the entertainers are doing it you can be sure the sneaky salespeople, callous cold-readers and other such charlatans are doing the same. In fact this particular construct is used especially heavily by cold readers, the effect is multiplied based on the level of rapport at one far end of the see-saw even slight nudge is enough to direct a listener.

If you consider the basic form of the question “Do you think using positive statements is a good idea?” you’ll notice that’s it’s neutral, it doesn’t presuppose an answer in any direction. That’s the difference.

The Positive Side

I’ve written a lot on the ethics of using somewhat sneaky linguistics before so I’ll leave out that discussion again. But there are some great positive ways to use this knowledge. Here’s an example from this very post (+10 internet points if you noticed it earlier)

In the section about addiction I wrote: ” there’s a whole industry of negative statements around giving up smoking that are designed to make people think it isn’t an easy thing to do”. I deliberately used a contracted negative statement that presupposes that it is an easy thing to do. I used a negative statement to cause a positive representation.

Another simple way to use this knowledge is to simply use positive statements. Tell people what you want them to do and think. Avoid telling people what not to think. (er.. two negatives in one sentence what the…?)

This works especially well with children, instead of telling them not do something (such as “stop being noisy”) tell them what to do positively (such as “be quiet”). The first makes the kid think about being noisy, the second makes them think about being quiet. However it must be said that even the most carefully crafted sentence isn’t going to get a little kid to be quiet, but that’s ok they’re meant to be noisy.

Finally

So, aren’t you glad you read this?


This blog is part of a series on Holistic Communication: The linguistics of business change. Introduction, ethics and table of contents is all in the first post.

Decision making case studies

I’ve previously blogged on a decision making model that involves understanding the decision making process and then the different ways a group can reach agreement and how to choose which method to use in which situation. This post covers some real case studies from my own experience that apply this model and help discuss some the issues involved.

This post won’t make sense without reading How to reach agreement in a group – autocracy vs. democracy as it contains the decision tree and questions this post refers to.

Read more of this post

How to reach agreement in a group – autocracy vs. democracy

In the first part of this blog (A model for making group decisions) I talked about the rational decision making model and how it is the basis of making a decision. Part of that model is gaining agreement amongst a group on an option out of a set of options which becomes the decision. This part is about different ways of gaining agreement and when to use each.

This model is a variant of the Vroom-Jago (1)  contingency model in situational leadership theory first developed in 1973 and then refined in 1988. My take on it changes the language here and there to alter some of the emphasis and changes the decision tree a little.

This model defines a set of decision making models ranging from autocratic to democratic and then helps you choose which is appropriate for different situations.

Decision characteristics

This model applies to decisions involving a group that have an “owner”. The owner is the person who needs the objective decided on. The owner could be the customer, a representative, the group as a whole or the team leader. An important consideration when using this model, as discussed in part 1 is knowing who the owner is and realising that it may well be different for the different decisions the group has to make.

For each type of decision that needs to be made by a group:

  1. Identify the owner
  2. Clarify the objective
  3. Identify the team/group involved

Decision making models

The following decision making models are appropriate for group decisions:

  • Autocratic 1 (A1) – The decision owner makes the decision based on the information available.
  • Autocratic 2 (A2) – The decision owner requests information from the team (not explaining the situation or why they want information) and then makes the decision.
  • Consultative 1 (C1) – The decision owner explains the situation to individual members (socialising and pre-integrating the decision) but does not convene them as a group, then makes the decision.
  • Consultative 2 (C2) – The group discusses the situation and then offers ideas and suggestions. The decision owner then takes the decision.
  • Group 2 (G2) – The whole group makes the decision with the owner acting more as a facilitator. Reaching this discussion can be discussion leading to emergent consensus, planning poker style or explicit voting solutions.

I don’t know why there isn’t a “Group 1″… maybe we should ask Vroom.

Which one to use

These options range from autocratic to democratic. One of the interesting things is that sometimes leaders want to be democratic but don’t really need to be or are not expected to be. This can lead to a conflict in expectation of approach. A leader may wish to be inclusive and democratic but their team may just wish they’d make a decision once in a while!

The alternative also causes conflict where a group expects their opinions to be heard and taken into account but the owner ignores their voices and makes autocratic decisions. This will create distance between the owner/leader and the group/team making the team feel undervalued.

Having understood the decision characteristics and the different decision making models you can then select one by using the following decision tree to identify the most appropriate model.

Each horizontal numerical bar indicates a question for the decision owner. Answer that question as honestly as possible, in terms of how relevant it is to making a good decision then move to the next part of the tree (sometimes skipping a question bar) and see which question you should answer next. Pretty quickly you’ll arrive at a circular blob with the short name of one of the options described above. I’ve written up some case studies to help explain by example.

  1. Are the stakeholders known, available and engaged?
    • Are the people who will be materially affected by the decision identified, are they available to join in the decision making and engaged in the team to assist in making a decision?
  2. Is a high quality decision/solution important?
    • Is this a case where lots of alternate options can be used and it doesn’t really matter which is selected? If so then answer “no”.
  3. As the owner do you have enough information available to make a gooddecision?
    • If the owner is unsure, or wants to involve other opinions then answer “no”
  4. Is the problem well understood and does it have well known standard solutions that apply in this context?
    • Is it’s a standard problem with a standard (or set of standard) solutions that will work in the current context then answer “yes”
  5. Do the members of the team or group have to accept this decision for it to work?
  6. If you (the owner) make the decision yourself will the group accept it?
    • Answer this honestly, being in an organisational structure that means the group should accept it isn’t good enough. This question is about the real, honest dynamic between the owner and the group. This is affected by rapport.
  7. Are the group members aligned with the same motives and goals as you the decision owner?
    • If the other members of the group have a different mission, agenda or motives then answer “no”
  8. Is disagreement likely among group members in reaching a decision?

What if you don’t want to do this model? What if your stakeholders object?

So if you’ve followed the decision tree and it says you should use Autocratic 2 (full autocracy) when you were hoping for Group 2 (full democracy) what should you do? This model is a bit like flipping a coin to decide something. The important thing is not which side of the coin comes up but how that decision makes you feel. If this process highlights to you what you were really hoping for then you’ve learned something. However it’s worth looking at the decision tree and seeing why you ended up where you did, and if other’s in the group would expect the same thing.

To explore this a little I’ve described three real examples here: Decision making case studies – please feel free to add your own. I’ve quickly written:

  • Agile team customer sprint demo and assessment
  • Process Improvement Team way of working decision
  • Process Improvement Team scope agreement

The important part of this process is to make you, your team and your stakeholders consider the types of decisions they need to make, and how they should make different types of decisions. I recommend that as part of a team charter a team describes the types of decision it will make and how it will make them. That gives stakeholders, customers and other teams the opportunity to get involved and question the decision making dynamics if necessary.

Decision making as a team building exercise

During the formation (or reinvention) of a team you can do the following exercise:

  1. Brainstorm the decisions the group makes. Categorise them into a few groups such as:
    • Achieving team buy-in to approach and activities
    • Timebox assessment, regular reflect and adapt
    • Balancing scope, cost, resources, time
  2. For each one establish a good definition of an example decision and it’s owner.
  3. Each team member then puts themselves in the position of the owner (this is even better if the owner is in the room and is included) and privately follows the decision tree answering truly honestly
  4. Each team member then shows the resulting decision making option they’ve chosen
  5. Consensus or conflict is then discussed. Outliers on the scale should be discussed first.

This simple exercise will get the team to understand each others motivations and approaches to problem solving as well as open their eyes to some of this stuff from a different perspective. Finally unknown conflicts in terms of decision making way well emerge where people had different assumptions of group input vs. directive management allowing them to be solved practically before a real personal conflict occurs.

To see how I apply this stuff to self-organising teams see: What does a self-organising team really mean? Organisation!

Finally…

Try applying this approach to personal relationships and decision making, not all of it will apply but it’s interesting to see where you act collaboratively with a partner vs. when you make an autocratic decision (or expect them to) and what the justification is for such a perspective.  A misunderstanding between assumed decision making models is one of the underlying causes of many personal conflict situations, you can avoid these by understanding them.

Spend some time understanding how and why you make decisions both personally and professionally and you’ll reap some great rewards.


This blog is part of a series on Holistic Communication: The linguistics of business change. Introduction, ethics and table of contents is all in the first post.

References

  • Vroom, Victor H.; Yetton, Phillip W. (1973). Leadership and Decision-Making. Pittsburgh: University of Pittsburgh Press.
  • Vroom, Victor H.; Jago, Arthur G. (1988). The New Leadership: Managing Participation in Organizations. Englewood Cliffs, NJ: Prentice-Hall.
%d bloggers like this: