Coaching

Behavioural Economics: Lessons in Leadership

Richard Thaler, a recent Nobel prize winner in Economics from the University of Chicago has changed the way many economists think about their economic models by including elements of psychology.  This is known as Behavioural Economics.  Rather than assuming that the entities involved in the models make rational decisions for their well being, Thaler has popularized the idea that those entities should reflect the reality that people make decisions that undermine their overall long-term being. 

Last month I had the good fortune to listen to the Oct 25 episode of the Freakonomics podcast entitled “How to  Launch a Behaviour-Change Revolution”.  During this 45 min podcast, the hosts explore the genesis of Behavioural Economics and a research project called “Behaviour Change for Good”; a play on words for positive, long lasting change.  This research by Angela Duckworth and Katherine Milkman had the goal of helping people make truly lasting behaviour change by helping them make better decisions for their overall long-term being.

THE EQUILIBRIUM OF CHANGE

As a kickoff to their research project, Duckworth and Milkman hosted a two day summit attended by luminaries from the field of psychology, including another Nobel prize winner Daniel Kahneman.  You may know Kahneman from his work on cognitive biases as discussed in his book “Thinking Fast and Slow”.  During the 2nd day of the summit (30 mins into the podcast) Kahneman comments on ‘the best idea I ever heard in psychology’.  The idea he refers to is from Kurt Lewin, a German-American psychologist from the early 20th century.  Lewin’s idea was that in thinking about behaviour, we should consider that there are always two opposing external forces; driving forces and restraining forces.  His novel insight was that behaviour is really the equilibrium between those forces.

Therefore, when trying to induce change in behaviour, one can choose to either reduce the restraining forces or increase the driving forces.  Our natural predisposition when changing anything is to increase driving forces.  When we want to move an object, we move it.  When we want to change a person, we try to cajole and incent in order to change that person.  Kahneman argues that we need to change our perspective and instead of asking ‘How can we get this person to do X?’, instead ask ‘What is preventing this person from already doing X?’  Lewin asserted that reducing the restraining forces is usually much more effective than increasing the driving forces.  Those restraining forces are likely reflective of the system within which the person is working.  Changing behaviour involves changing the constraints within the system.

Consider the significant implications this has for leadership.  Rather than trying to directly change a person’s behaviour, leaders need to be asking what they can do to make it easier for the person to change their behaviour; to reduce the restraining forces.  Kahneman states that the way to make things easier is almost always controlling the person’s environment.  Whether it’s changing counterproductive incentives, social pressure, or any other organizational impediment, the premise is that if A is a restraining force on B then let’s work on reducing A not driving B.

OVERPROMISING

Later in the podcast Kahneman is challenged on his assertion that “you have to overpromise to get ANYTHING done”.  After all, he has done the seminal work on cognitive biases that lead us, as a psychological mistake, to be overly optimistic.  Kahneman maintains that making practical incremental improvements in results may be useful but to really make a difference, to create ‘big successes’, likely requires being unreasonably optimistic at the outset.

This concept also has implications for leadership.  My experience applying Scrum values and principles to the execution of large oil and gas construction projects mirrors these assertions.  The EPCM team’s success on a $2.4 billion program of three natural gas processing plants was in part due to the team’s commitment to goals that seemed entirely unreasonable at the time.  According to McKinsey, the global normal performance for mega-projects (>$1B) in this domain is a cost overrun of 30-40% and a schedule overrun of 40-50%.  The EPCM leadership team and the execution team collaboratively set their sights on being 10% under budget and months ahead of schedule.  Our approach to achieving these results was to acknowledge that we didn’t know HOW we were going to solve the problems in front of us but that we were going to  commit to regularly understanding our current priorities, and then tackling each seemingly unsolvable problem one at a  time as a multi-discipline team.  We didn’t solve all of them, but we solved most of them.  The EPCM leadership also focused on reducing restraining forces by removing impediments preventing team members from working collaboratively.  Namely, co-locating the team, implementing cross-discipline team composition, and promoting the idea that the identification of upcoming problems was a vital and important activity. The results were that the first plant was in service 38 days early, the second was in service 86 days early, and the third was in service 167 days early; the plants were delivered 10% under budget.  This had immense implications for the economics of the projects as revenue was generated early.

“If you solve one problem, and the next one … if you solve enough problems you get to come home.” - Mark Watney, The Martian

As always, we prosper from conversations with our colleagues outside of our immediate domain.

Clash of Cultures

     I’ve had the opportunity to work in some interesting business environments in the last couple of years. What made them interesting was the partnerships of multiple organizations with different cultures striving towards common goals.  As an Enterprise Coach, it is part of my role to help these organizations navigate these cultural differences. These differences often exhibit themselves in obvious and sometimes mundane ways.

     In one instance, where Company A had hired Contractor B to deliver a program of projects, Company A was interested in transparency and the use of Big Visible Charts.  They believed that broadcasting the true state of affairs was a valuable communication mechanism and helped everyone understand not only our successes but where problems existed and thus where priorities could be found.  Management of Contractor B on the other hand was very concerned about displaying any information that could be construed as negative.  They were only interested in broadcasting positive news.  They feared that the broadcast of problems or perceived failures would be a drag on morale.

     Interestingly (and possibly related), these same organizations also had vastly different meeting cultures.  Company A was protective of their peoples’ time.  Meetings were scheduled only when required participants were available and there was rigour around responding to meeting invites in order to make the best use of everyone’s time.  Company B had a culture where meetings were scheduled regardless of whether required participants were already booked.  Further, people who were double or triple booked then selected the meeting they would attend in real-time.  This resulted in the meeting organizer never really knowing who would show up for the meeting until it occurred.

     These cultural difference have a marked effect on the ability of the companies to work together effectively.  So what to do?  Well, the first step is to identify the differences; accept that these differences are likely ingrained.  The second step is to refrain from trying to shift one company to the other’s culture; instead start the process of creating a new culture for the combined team.  The third step is to engage the team in a discussion of how best to address these differences for the good of the projects.  The fourth step is to establish working agreements in these areas, explicitly agreeing to review and adjust those working agreements as the team discovers new situations.  As with every working agreement, it’s important that everyone model the agreed upon behaviors and be willing to hold each other accountable to these agreements.

     While these kinds of cultural differences often occur between organizations, they also occur between different departments, groups, and teams within a single organization.  Can you recognize those differences within your organization?

Scrum Alliance - Progress on Transforming the World of Work

I’m a Scrum coach.  I like to think that I help people, teams, and organizations change the way they connect with their work, think about their work, and function.  I have chosen to do this under the auspices of the Scrum Alliance as a Certified Enterprise Coach.  One of the things that drove me to do this was the mission of the Scrum Alliance - Transforming the World of Work.  I am passionate about this mission and have dedicated my career to this endeavour.  I believe that many people toil in disengagement and dissatisfaction within their work environment.  I believe this harms both the individuals and the organizations for whom they work.  I believe there is a better way.  I believe we are uncovering better ways of working.  I believe Scrum is a framework that fosters that discovery. 

I assume that in order to really transform the world of work on a significant scale, we will need a critical mass of people with enough understanding and experience demonstrating and living the values of Scrum  The relatively low number of Certified Scrum Professionals and Certified Team Coaches could indicate that we are failing to reach this critical mass.  Anecdotally we see and hear that there are not nearly enough people in the world who understand and execute the values and principles within the Scrum framework.  So our anecdotal evidence appears to match the data.

I suspect that not enough people are interested in CSP certification and beyond because they don’t see a compelling reason for it.  If there was value, people would seek it out.  So how could it be more valuable? 

One approach might be to think about certifying organizations in Scrum.  That organizational certification might include some critical mass of CSP’s and/or CTC’s.  Customers of those organizations would have some assurances that their vendors were actually proficient in the use of Scrum.  The organizations themselves would then need to have CSPs and beyond as part of their organization which would lead to individuals seeking out CSP certification.  This would provide some impetus for individuals to continue their learning and it could provide some organizations with a competitive advantage.

I believe we are missing something in not helping address the needs of these organizations’ customers.  Isn’t this all supposed to be about delighting the customer?   I believe we should direct our Scrum awareness marketing activities in a much broader context.  We need the customers of the organizations that use Scrum to see the value of Scrum and WANT their products developed using Scrum because they value their involvement and the inherent innovation.  It is through the awareness of the customers that we’ll see acceleration in the adoption of Scrum.

Catalytic Poisoning; Coaches and Chemicals

As an agile coach, my purpose is to help people, teams, and organizations transform the way they think about their work and how they function as an organization. My role serves as a catalyst in these transformations, asking questions and inspiring clients to create their own new thinking. As with any change involving people, this does not happen overnight. These transitions can take several months to several years, and I’ve been considering how my coaching perspective is affected in these long term engagements. 

In considering this, I was reminded of another type of “catalyst” I learned about in school. In the world of chemical transformations, tiny amounts of a substance can be introduced to a reaction to increase the speed of a transformation and decrease the amount of energy required for the transformation to take place. These substances are called catalysts and they are usually unaffected by the chemical reaction taking place around them.

If you are a regular reader, you know I am a big fan of analogies from other aspects of life. This one was pretty clear to me when I happened upon it. When added to a new or already existing agile transformation, a coach’s mission is to increase the speed of a transformation and decrease the amount of overall energy required for the transformation.

However, catalysts (whether chemicals or coaches) can occasionally be inhibited, deactivated, or destroyed by secondary reactions.  Some secondary processes cover a catalyst in bi-products (see my previous post on Scaling) and inhibit the effect of the catalyst.  If that inhibiting effect is permanent, it is known as ‘poisoning’. It is important that coaches remain vigilant to recognize the risk of this, and prevent it.

During a long term engagement with a client, it is inevitable that relationships form, biases shift, and as a result, dysfunctional patterns can emerge.  As coaches we are trained to avoid these pitfalls, yet we are human. While my objectivity is often desired, it is my subjectivity that is often required in order to be an effective coach. I need to connect with people.  I need to understand them--- their fears, their motivations, their relationships with their teammates.  As time marches on, making these connections can occasionally draw me into situations where I risk losing my coaching stance and perspective.  Occasionally, my investment in the outcome of the work can become more important to me than the means to accomplish it.

In a recent example involving multiple teams, multiple companies, and multiple cultures over an 18 month period, my catalytic effect had deteriorated immensely to the risk of being poisoned.  My ability to affect the teams and organization through coaching was handicapped.  After recognizing this, I introduced a person to the transformation with different experience, different perspective, different history, and different relationships.  This had the two-fold effect of re-energizing the transformation---and opening space for another catalyst leader.  People and teams were able to better learn for themselves by being involved in new and meaningful conversations, and I too was encouraged by this new energy.  I’ve had some limited experience with paired coaching and this example has led me to believe there is likely tremendous value in utilizing that concept in large transformations.

Knowing when you, as a catalyst, have been inhibited is one of the many coaching skills necessary to ensure that your clients’ transformations continue to evolve.  I suspect the risks increase more for in-house coaches rather than consultants, but I'd like to hear what you think.

An-Isotropic Scaling

In the vernacular of my former career as a metallurgist, 'scaling' is defined as 'the accumulation of unwanted material on solid surfaces to the detriment of function'.  Over the last year or two, I've been amused by the discussions around scaling in agile environments and the applicability of that definition.  There are many, although not all,  in the agile community who might define scaling as 'the accumulation of unwanted process and overhead on solid teams to the detriment of their function'.

In metallurgy, there is the notion of isotropic vs an-isotropic scaling.  That is, the difference between uniform scaling and non-uniform scaling.  It is natural to visualize scaling anything uniformly along all axes.  When we look at a picture, we think in terms of increasing or decreasing it uniformly in all directions, resulting in a larger (or smaller) version of itself.  Sometimes we use uniform scaling and fix the ratio of expansion or contraction along the axes to match the original and maintain a shape.  However, there are situations where the reason for scaling actually dictate non-uniform scaling; the bigger picture isn't the goal, rather increased utility or performance at a different size is the goal.  I believe that to be the case with scaling an agile organization.

Isotropic scaling of an existing system can very often lead to expansion (or contraction) in unnecessary areas and not enough expansion (or contraction) in others for the desired effect. 

Very often, expansion within an organization requires growth at different rates-- and in different directions.  This is precisely the definition of an-isotropic scaling. Further, it’s quite possible that the expansion in one area actually requires a contraction in others for the system to be effective.  Rather than focusing on keeping the shape of the organization intact through uniform scaling, it might be helpful to recognize that  non-uniform scaling, by definition, changes the shape of an organization.

Too often, expansion is seen as the solution to problems- problems that would actually benefit from contraction. A classic example is the notion that we need to increase the number of support teams to handle increasing numbers of customer support issues.  Using a systems thinking approach, the real solution to this problem is to uncover the cause of growth in customer support issues and address that, rather than expanding to handle the symptoms.

When we are scaling an organization, we need to identify what problem we are trying to solve.  Are we trying to coordinate existing and additional teams for some form of consistency (perhaps architectural or technological)?  Are we trying to increase the throughput of the organization in terms of different products/services delivered?  The specific solutions to those scaling issues may depend on the maturity of leadership, teams, products or portfolio management, and will likely require growth at different rates in each of those.  With mature products and teams, perhaps it is simply the portfolio management system that needs to scale up.  With mature leadership and products and services, perhaps it is only the teams that need to multiply.  Without taking into consideration the people and their relationships, it is very possible that process and overhead will be added to the detriment of an already well functioning part of the whole.  As many organizations consider people simply ‘human resources’ within a process, it is too easy for those organizations to ignore the human part of growth or contraction.

There are, of course, instances where isotopic growth is required.  When we are considering the increase in capacity for software delivery, there is often a desire to ‘hire developers’ to accomplish this.  In this case, the increase in capacity usually needs to be isotropic (perhaps with fixed axes); adding developers, testers, Scrum Master, Product Owner. Adding developers alone doesn’t increase capacity, adding multi-discipline teams increases capacity.

An agile mindset keeps us focused on inspecting and adapting based on a clear understanding of what problem we are trying to solve.  Scaling an agile organization is no different; we need to keep focused on the problem we are trying to solve, rather than simply uniformly scaling a system that works in its current situation.