Mike MacDonagh's Blog

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

Tag Archives: cognitive science

What is “good” software architecture or design?

Architecture is a fine balance between a subtle science and exact art that combines cognitive problem solving, technical direction and expressing abstract views to aid common understanding. Design is similarly an inexact science which is inextricably linked to Architecture. As a result it’s quite hard to define what makes a “good” architecture or design.

There are high numbers of design and architecture practices ranging from the purely transformational to the evolutionary and emergent (both manual and automated) but there seems to be some heuristic consistency between these various practices and the approaches of the traditional, agile and post-agile movements.

Initially I saw the simple descriptions of that makes for “good” design from from Ron Jeffries and Kent Beck in Xtreme Programming. I like the style and direction of this kind of description so here’s my take on the characteristics that make for “good” design or architecture:

  • Intentional structure and behaviour
  • Highly modular: consisting of separate services, components, classes, objects or modules
    • Elements are highly cohesive
    • Elements are loosely coupled
    • Elements have low algorithmic complexity
  • Avoids duplication
  • Well described elements: modular elements have simple expressive meaningful name enabling readers to quickly understand their purpose, similar to code cleanliness we should strive for design cleanliness
  • Runs and passes all defined tests or acceptance criteria
  • Lightweight documentation

Zen and the art of Enlightened Software Development

When I started doing software I was a simple developer interested in elegant code and shiny things. I worked in a small software house that taught me many bad practices in terms of configuration management, change control, estimation, management etc. It was an incredibly valuable experience for me in learning how not to do things and led me to strive for something better even though at the time I didn’t really know what it might be.

That led me through a path of process definition and documentation (RUP) and a rather limited following of an iterative lifecycle. I remember a conversation I once had with one of my project managers (when I was an architect) asking if we were going to do “Use Case Analysis” on a particular project or just skip straight into “Use Case Design”. The question puzzled me then because it felt like a trap and I didn’t really understand what I was being asked.

It puzzles me even more now as I know understand “analysis” to be a stop-and-think-for-a-moment activity and I’d always do a bit of analysis of my requirements, however these days it’s extremely unlikely that it’d be an analysis UML model, instead it might be a sketch, a conversation and a bit of thinking before another conversation.

So I moved from process prescription to process understanding, applying the spirit of doing things well rather than the letter of whatever current process law was in fashion. Following on from that I’m not really interested now in the details of what a book says someone’s role should be or how people should interact instead I think the real challenges in software development are social, not collections of technical practices (although there is  value in evolving better practices and tooling).

A colleague of mine commented recently that 20 years ago when he was doing software it was possible to understand everything from the metal all the way to the blinking lights on his bit of hardware. Software development in just 20 years has progressed incredibly and it’s just not that simple any more. We can understand the basics all the way through the stack but not all of the details. There are so many bits interacting that it’s just too complex. As a result the problems, technology and team working are all abstracting away from the tangible mechanistic past.

Developers are on a path from technical skill to mastery, as they begin to understand the kung fu of software engineering they can apply experience and deep understanding to solving the technical problems, doing away with formal process and just using the practices that they intuitively need, happily breaking the “rules” to get the job done in an efficient high quality way. I’m not entirely sure where brogrammers are on this evolutionary path, I’ll leave that up to you.

The problem, if it even is a problem, is that each person in an organisation is somewhere different along this path and even if they’re at the same point in the same dimension they might not be aligned in their interests and motivations. This makes team working amongst inherently complex social creatures a tricky proposition. The sweet spot is a team of fully enlightened software kung fu masters but that’s a really hard target to meet for a number of reasons. Consider the flower of team working evolution weirdness, which area is your team in?

One reason that this sweet spot is difficult to hit is because in any organisation half of the developers are below average in technical and social skills. Sounds horrible but is obviously true and the larger the organisation the more likely it is to be the industry average, not the organisational average.

This means that the centre of skill gravity for any team is unlikely to be on the w00t side of the scale.

In most large organisations the teams are more likely to be flattened pancakes across this bell curve taking in a reasonable representation of the organisation as a whole (especially as the highest skilled are often distributed amongst an organisation to attempt to bring up other teams.

This isn’t necessarily a problem though as there is value in diversity and individuals will each have different ways of thinking about things that can bring value to teams and organisations.

I’m beginning to think that the purpose of classic software process, and classic software process improvement is to try and move people along this scale from basic developer to software ninja, helping them to gain mastery through experience and feeding in the experience of others. When a team moves along this scale they begin to not need their process mentors any more and will seize their autonomy.

Technology is increasingly commoditised by innovation, as is software development and software process. I used to spend a lot of time teaching people Object Orientation but these days everyone just seems to know it, it’s nothing special or new, it’s just what people do. Similarly people are increasingly aware of the value of iteration, limiting work in progress, continuous integration and delivery. They need less process and less instruction as this stuff is becoming business as usual at least in more mature organisations.

As these problems are being solved I think that bigger problems are coming to the fore as they’re less hidden by low level development issues. The questions I see a lot of clients wrestling with are things like:

  • How can we foster the right kind of organisational culture?
  • How do we deal with requirements, architecture, releases, resources etc. in a complex system of systems environment?
  • How do we bring together multiple divergent interpretations of “agile”?
  • How do we manage outsourcing contracts in high speed agile projects?
  • How do we motivate and engage the business and technical communities?
  • etc. etc.

For me doing these things in a social collaborative way, that values individuals and teams, is Enlightened Software Engineering and encompasses the buzzphrase of the moment: Agile at Scale.

Solving these problems is less about technical skills and technical process content and more about social skills, psychology and understanding. Both from a coaching and business perspective.

So what’s my point?

My point is that software process improvement needs to focus less on individuals and more on teams, and teams of teams. That we should avoid ideology and take the best bits of knowledge and experience wherever we find them, growing our teams and individuals.

Also that we should apply more psychology to software process and business change finding socially resonant patterns for how we do things. True mastery involves not worrying about “breaking the rules” and from the outside can easily be confused with ineptitude.

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.

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.

A model for making group decisions

I’ve been working with some interesting group structures recently which got me thinking about decision making dynamics. I’ve been using a decision making framework for a while and intend to apply it to some different shaped groups so thought I’d share it.

There are a number of irrational ways of making decisions such as divination, looking at guts or rolling a dice but generally in business we like to make logical rational decisions. However often we don’t really think about how we make decisions, or more importantly how we should make decisions.

The techniques described in this blog are applicable to any situation where a group needs to make a decision, however the language is focussed on business groups/teams.

This blog is in two parts, the first is pretty simple and obvious and covers basic decision making, but it’ll lead on to the more interesting second part about different ways of reaching agreement and when to use each method.

How decisions are made

Rational decisions are made via a fairly simple process, at least in my mind:

Rational Decision Making

1. Objective: We start with an objective or goal, it needs to be clearly understood and have an owner/leader2. Alternative options: we create some alternate solutions.

Idea generation is an interesting topic by itself and lots has been written, but that’s not the topic of this blog.

3. Tentative Solution: We analyse the alternates against some criteria and then choose one to be our tentative solution

Again lots of ways to do this depending on your problem domain

4. Deeper Analysis: We perform deeper analysis on the tentative solution to try and ensure it’ll meet the objective

5. Agreement: We get the group to decide on the solution (see part 2)

6. Communication: We communicate the decision

There’s no point making a decision unless it’s communicated!

Person icon I used in the decision making diagram used as per attributable license from http://www.elegantthemes.com/

Different Types of decisions

The first thing to consider is that different types of decisions may need different types of decision making processes, specifically around gaining agreement and analysing options. This seems obvious to me, and is normally obvious to anyone I talk to about it, however when business change people are talking about creating/redefining a group to make some decisions they usually say how they’ll make decisions without differentiating between the types. Unfortunately common sense is often left out of planning.

A decision can’t be made unless it’s understood. To understand why a decision needs making someone, or the representative of some people, needs to have an objective which requires a decision by the group. Again, this seems rather obvious but if you consider it the other way around it means that a group can’t make a decision unless it know who wants the decision and why they want it. Apply that to many traditional management groups/boards,  CCBs, business change projects, process improvement groups etc. and you’ll find it doesn’t always hold. In these cases groups are being dishonest and self-serving.

I don’t mean that you can’t make a decision without the customer present (models for that follow next) but that you can’t make a good decision if you don’t know who the customer is and what their objective is. In the case of speculative development for a market this might seem impossible but that’s what market research is for. So, given that we know how decisions are made, and that we should consider different ways to achieve agreement for different types of decision how can we actually get agreement?

See part 2 for How to reach agreement in a group – autocracy vs. democracy


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.

Business Change: Rapport, Congruency and hypnosis

What is rapport?

Have you ever been in a situation with someone where you could finish each other’s sentences? Ever had a friend you could communicate with with just a glance and you always seemed to know what each other were thinking? Have you ever felt than in tune with someone? Ever had people follow your reasoning without really questioning it because of the relationship between you at that moment?

The word “rapport” is used to describe this relationship, people in these situations are said to be in rapport with each other (you don’t pronounce the last “t” because it’s based on a French word). Hard to define but everyone’s experienced something along these lines.

Most people have some experience of rapport at least in their personal lives indeed as it serves an important purpose in forming close friendships and intimate relationships. I think of every relationship as being on a big sliding scale from anti-rapport (total conflict) to full rapport (complete hypnotic trance) and putting this scale on a fulcrum to make a see-saw I can push in each direction. I call this the “See-saw of Rapport” because I’m a sucker for a silly rhyme.

Read more of this post

Empowerment vs. Autonomy

A colleague and friend of mine, Caroline Clewlow, recently blogged on “Giving Empowerment or Taking Autonomy” which makes some excellent points. Note sure when the second part will be published, but I’ve already read it and it’s good too (Edit: Part 2 has been posted now). One of the good points contained is

A colleague said that in the simplest terms empowerment is given whereas autonomy is taken

10 internet points if you can guess who the colleague mentioned was, and in terms of the linked vid see here

Anyway, there’s something I thought I’d add to this topic which is some discourse on the element of moral responsibility.

Because an empowered individual or team is given it’s mandate for action from a higher power (i.e. management) the moral responsibility for it’s actions is at best derived from the high power but normally resides with the higher power. An autonomous individual or team however assumes their own moral responsibility. To this is an important distinction that, on top of the points made in Caroline’s blog, makes empowerment and autonomy distinct.

An autonomous team has the right to do what it wants without asking permission, without external limitation to the scope of that right. This is in contrast to an empowered team who are empowered to “do something”  and therefore by implication anything that falls outside of that “something” from the managers interpretation is contentious.

In business change this can be both a good thing and a bad thing. It’s a good thing as means the blinkers are taken off and the change team can do whatever is necessary to achieve the business change goals (within ethical constraints) ignoring and presuppositions about how business change can and should function. That sounds pretty good so what’s the downside?

The downside is acting with autonomy is acting without permission. That means acting without management mandate, and therefore without an “organisational push motivation” for the change in question. That’s not an insurmountable problem, a collaborative supporting statement from management can achieve the same thing in a relevant culture.

The best way to achieve buy in by the relevant stakeholders to the moral responsibility of a team and it’s autonomous actions is to ensure that the team includes those stakeholders. In the business change example, this means an autonomous team must have part of the organisational management as part of it’s membership.

For a software team this means that the autonomous team can decide to take whatever action necessary to achieve it’s goals only when the customer is part of the team making those decisions.

Business change teams acting in isolation, or at arms length from organisational management and the practitioner community they serve have the same problem as agile software teams acting without a customer representative. These teams have assumed moral responsibility but no representative conscience to provide balance to the decisions made by the team. If those teams are “empowered” then they’ll have to keep checking what they’re doing with management/customers to make sure they’re still on the right track decreasing efficiency and increasing rework.  If those teams are “autonomous” then they run the risk of creating an ivory tower of zealous self-perpetuating “moral” correctness.

In both Business Change and Software Development contexts I agree that an empowered team is better than a simple instruction following team. I also agree that an autonomous team is a progression along this path from an empowered team however I believe an autonomous team is operating unethically if it does so without true customer/management/practitioner representation.

Achieving an organisational environment that enables autonomous teams means management taking an open collaborative supportive role.


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.

Professional mindfulness, emotional intelligence, conflict resolution and the ways of the Jedi

Introduction

I’ve been hearing a lot about mindfulness in business change circles recently so thought I’d comment. It started when a fellow mentor came to me and asked if I’d heard of “mindfulness” to which I responded somewhat frivolously “as Jedi we are mindful of our thoughts and feelings”.

“Mindfulness” has roots in Buddhism as one of the seven factors of enlightenment and has was then adopted by clinical psychology, especially in “positive psychology” over the last few decades in the way that good ideas are often recycled by new belief systems ;p Recently people involved in people management, professionalism and business change have started using the term somewhat interchangeably with emotional intelligence. Interestingly, all three uses roughly fit in with the Jedi interpretation. From my perspective the definition is a bit fluffy and the current trend is simply a fad but that doesn’t mean there’s not some value behind the chatter.

Psychology today tells us

Mindfulness is a state of active, open attention on the present. When you’re mindful, you observe your thoughts and feelings from a distance, without judging them good or bad. Instead of letting your life pass you by, mindfulness means living in the moment and awakening to experience.

Value

I think there’s some value in this idea of separation of emotion from logical thinking in a professional context. Emotion tends to complicate things and needs attention otherwise it can override everything else. In any given situation there is always an emotional context, both on the part of yourself and the others you’re interacting. To me, mindfulness is about understanding your emotional context and their emotional context.

“Mindfulness” has a role in conflict resolution as the first part of resolving conflict is to understand each perspective, you can’t do that if you ignore the emotional context. Rapport between individuals is force multiplied by acknowledged sharing (or perception of sharing for the sneaky) of emotional context so being aware of it is a good thing.

In Practice

So how can we achieve “mindfulness”? Various schools of thought have ideas on that from meditation, “consciousness raising” exercises etc. but I prefer a more simplistic approach to achieve awareness of emotional context. At first this is a bit slow and something you’d do retrospectively but with practice you can get quite quick at it and do it in realtime during a session.

Imagine a moment of communication, especially one with emotion. Ideally consider an event where the result wasn’t what you expected or intended or a moment of conflict.

1. First play back the event from your perspective, focussing on your emotional responses during the event and visualising enough detail to consider the opponents emotional state. Hopefully this will give you some insight into your actions.

2. Second play back the event again from the opposing person’s perspective. Put yourself in their place and try to interpret both their emotional intents and responses to your original communication.  Hopefully this will give you some insight into their actions.

3. Finally, play back the event again from the position of an objective observer. You could imagine a fly on the wall or a psychologist studying the event with a bunch of curious students in tow behind a one way mirror. The point is to examine the event, the communications, actions and responses with emotional detachment to again consider the emotional motives behind what happened.

Doing this little exercise will increase your understanding of the emotional context of any event, especially conflict events. You’ll most likely gain significant insights into your own motivations and actions and those of the other parties. I always do. This exercise helps you achieve mindfulness regarding the event.

I always do this following a moment of conflict whether it be professional or personal, as both are things I try to avoid. These days when I’m in a moment of conflict I find I immediately do a quick comparison of the situation from three perspectives, it takes a fraction of a second but enhances my understanding, and therefore response, to conflict situations significantly. This is an example of “anchoring” from NLP.

Of course if there’s a little too much conflict in a situation a different approach might be necessary!

Conclusion

“Be mindful of your feelings, they betray you”

In my opinion there’s little place for negative emotion in a professional setting. However sometimes business change activities may cause negative emotion of conflict, it’s these situations in which an eye on mindfulness or emotional intelligence can help.

There’s nothing new in “mindfulness”, “emotional intelligence” or (my term for it) “emotional awareness” but as with all of these things, to ignore it is to tie one hand and both legs behind your back before going for a game of tennis.

Remember also that Master Yoda said we should “be mindful of the future”… but not at the expense of the moment.


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.

Follow

Get every new post delivered to your Inbox.

Join 383 other followers

%d bloggers like this: