Archive

Leadership

The Marshall Plan

I guess most people, when they start a new job or client engagement, have in mind the things they want to do and see happen. Most likely, things they’ve seen or made happen in previous jobs or engagements. Along with, maybe, some things they’ve read or heard about and are minded to try out, given the opportunity. (And what better opportunity than the honeymoon period of a new job or client?)

We might choose to call this an agenda.

My Agenda

I’m no different, excepting perhaps the items that feature on my agenda:

  • Invite participation in discussing “who matters?” (with respect to i.e. the work and the way it works)
  • Empathise with the emergent community of “folks that matter” (not exclusively, but as a priority)
  • Invite folks to listen to each other’s volunteered observations, hear each other’s feelings, and explore each other’s needs.
  • Invite folks to solicit and then begin attending to each other’s requests (explicit and implicit)
  • Offer and provide support to folks and communities in their journeys

Note: I’ve not included on my agenda anything about specific actions that I myself might want to do and see happen, beyond the items listed. Specifically, although I’ve written often about strategies such as Flowchain, Prod•gnosis, Rightshifting, the Marshall Model, self-organising/managing teams, the quality of interpersonal relationships and interactions, etc., I don’t bring these into my agenda. If folks discover these strategies for themselves, they’re much more likely to understand their fundamentals, and maybe come up with even more effective strategies.

The Antimatter Principle is the only strategy I’ve regularly written about that recognisably features on my prospective agenda, and then only by extending invitations to participate in that strategy. (Note: Attentive readers may just notice the tip of the Organisational Psychotherapy iceberg peeking out from the above agenda).

I’ve reached a point in my journey where, keen as my ego is to see all my ideas (strategies) made manifest, my experience tells me that’s not the way to go for the best outcomes for the community as a whole.

As for the Marshall Plan, I believe it’s best, in the longer run, to have the folks involved (in particular, the people that matter) do their own discovery and learning. Discovering for themselves, over time – through means they also discover for themselves – effective strategies for attending to folks’ needs (often including the principles underlying those strategies). I see my role in this Plan as supporting – in whichever ways folks request, or say they need – this collective endeavour. Such support quite possibly to include actively helping the discovery and learning, whenever there’s an explicit (albeit refusable) request for me to do so.

– Bob

Further Reading

The Benefits of Self-directed Learning

Wants, Needs

My previous post seems to have struck a chord, judging by the number of retweets on Twitter. It also presents an opportunity to explore a perennial challenge of building things for other people: teasing out real needs from expressed wants.

Have you ever worked with business folks who articulate their wants in the form of solutions, rather than as solution-free “requirements”? As means rather than ends?

Let’s take another look at the list of desired outcomes (wants) appearing in the aforementioned post:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement

Business Analysis for the Way the Work Works

From my days as a Business Analyst, I’ve learned that uncovering needs means having an ongoing dialogue with the people that matter. A dialogue in which we dig down, together, into the things they say they want, so as to uncover their real needs. Once we’ve teased apart the wants from the needs, we’re in a better place to choose effective strategies (solutions) for addressing those needs. Going with the superficial wants tends to box us in to the strategies (means) they provide. Strategies which often fall short of being effective.

I suspect what I’m talking about will become clearer as we examine in turn each item from the above list…

Item: A more coherent, disciplined approach to software development

This looks to me like a solution masquerading as a need. That’s to say “a more coherent, disciplined approach” seems like more like means to other ends, than and end in itself. What might those ends be? What might be the underlying needs driving this proposed solution? A dialogue with the people that matter seems in order here. A dialogue that could prove challenging, absent a degree of trust and willing collaboration. And even assuming we are all able to dig down towards the underlying needs, just as in building software there’s no guarantee we’ve identified those needs accurately, until we’ve built and delivered something and seen it “in production” long enough to gather some feedback. Active feedback, which also implies iteration and evolution: “Is this really meeting the needs of everyone that matters? Is it good enough yet? What else do we need to do to improve it further?” etc..

For illustration, I’ll take a stab at the needs which might underlie this want. Maybe some folks suppose that “a more coherent, disciplined approach” will bring order to the present chaos (a need for order). Maybe some folks suppose that “a more coherent, disciplined approach” will make delivery of e.g. features or product increments more predictable (a need for predictability).

Maybe productive and effective dialogue will uncover other latent needs implicit in this want.

Item: Improved governance and oversight

This also looks to me like a solution masquerading as a need.

Maybe some folks choose “Improved governance and oversight” as their automatic, default solution (strategy) for bring order to the present chaos (a need for order).

Item: Improved estimates

This again looks to me like a solution masquerading as a need.The No Estimates movement and debate has just about done this one to death. What might the supposed need for “improved estimates” imply. What’s really need here?

Item: Better due-date performance (reliable on-time delivery)

Whilst we could imagine this as yet another solution masquerading as a need, in this case I find this want more interesting, maybe closer to a real need than the previous two items.

I suspect some folks that matter may suppose that “better due date performance” is the obvious means to improve (external) customer satisfaction, and thereby revenue, repeat business, profit, market demand, market share, and other business metrics. Maybe those involved in the way the work works, armed with an explicit, agreed need to satisfy one or more specific business metrics, would be able to come up with ways of working which effectively address those metrics. In other words, valuable innovations.

Item: More visibility into project roadmaps

This again looks to me like a solution masquerading as a need. What might be the underlying need here? Maybe it’s something born of a feeling of powerlessness in the absence of information about what’s happening. Maybe it comes from a sense of frustration or embarrassment when having to face customers and investors expecting information about product release schedules, feature sets, and road maps. Whatever the case, an effective, productive dialogue may flush out some of those underlying feelings, and thereby lead to a better understanding of the needs we’re all trying to address.

Item: Common standards

Yet again this looks to me like a solution masquerading as a need. I’ve heard this want many times in numerous companies. This looks to me like an implicit solution to the question “how do we become more flexible, how can we cost-effectively deploy and redeploy our developers between projects and project teams as business priorities change?” I guess the people that matter suppose that “common standards” is the obvious answer. But it’s our job to understand the underlying need and come up with the most effective solution (strategy) for addressing it, not just the most common solution.

But I could be barking up the wrong tree about the presumed underlying need here, so I’d want to have conversations with the people that matter so as to really understand what they might be trying to achieve through addressing this want.

Item: Better project organisation

Another solution masquerading as a need. What might “better project organisation” bring us? Better due date performance? More visibility into project roadmaps and current status? See explanations, above, for the needs which might underlie *those* wants.

Item: People working “in sync”

Solution masquerading as a need. What might “people working in sync” bring us? Reduction in friction and waste? Improved flow (of products and features into the market)? Better due date performance? By digging down, though dialogue, we may uncover candidates for the underlying needs, which we can proceed to validate through delivering a way the work works, and getting feedback on the degree to which that way of working effectively addresses folks’ real needs.

Item: Senior management confidence (in e.g. the teams’ ability to deliver)

This is probably the one item in our list of sought outcomes that’s closest to a real need. We can intuit the scale of the problem (shortfall in senior management confidence) by looking at all the solutions they’re helpfully trying to provide us with, via the other items here. Solutions (masquerading as needs) that they believe will improve things and thereby deliver the boost in confidence they seek (and need). Ironically, the solutions they provide – being very much less effective solutions than those we can come up with for them, as experts – often undermine the very outcomes they seek.

Item: Higher staff motivation and engagement

Very laudable. But let’s not let the humanity of this want blind us to its nature as (yet another) solution masquerading as a need. What’s the end in mind? Why might the people that matter seek “higher staff motivation and engagement”?

So they can feel better about the culture for which they they feel responsible? As a means to increased throughput and thus improved revenues and profits? Again, until we know what they really need, any solutions we provide will likely fall well short of the mark. In other words, wasted effort.

Summary

So, we can see that taking “sought outcomes” at face value can lead us into sleepwalking into addressing superficial wants, and adopting other people’s (non-expert, relatively ineffective) solutions. Solutions which rate poorly on the effectiveness scale, and which in any case may well be addreessin the wrong needs. I find it ironic just how much non-expert interference and micromanagement goes unnoticed, unchallenged and unlamented. Plenty of time for lamentation a year or two later.

Bottom line: When building software, the biggest risk lies in building the wrong thing (getting the requirements wrong), and it’s not any less of a risk when “building” – we might choose to call it “evolving” or even “engineering” – the way the work works.

– Bob

A Hiding To Nothing

Most large companies are on a hiding to nothing if and when they decide they’re “going Agile” for software development. “Going Agile” can only ever deliver the outcomes these companies seek if the whole organisation is prepared to change some of its fundamental beliefs about how organisations should be run.

Sought Outcomes

What outcomes do larger compares typically seek from “going Agile” in their software development teams? Here’s a partial list:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement

Why These Outcomes Are Unrealisable

What’s not to like in the outcomes these companies seek by “going Agile”? Although maybe not comprehensive – they lack, for example, outcomes like “joy in work”, “folks getting their needs met”, “improved flow” and “customer delight” – there’s a bunch of stuff here I could get behind.

Setting aside the observation that some of the above “outcomes” – such as “common standards” and “people working in sync” – are more solutions than needs, “going Agile”, per se, is not the answer for delivering these outcomes. At least, not within the Analytic mindset world view.

Why the Analytic Mindset is the Blocker

With an implicit Theory-X, local optima (manage the parts separately) perspective, any and all solutions attempting to deiver these outcomes through “going Agile” are doomed to undermine the very outcomes sought.

It’s likely to start well, with much interest and hope expressed by the staff. After all, who wouldn’t want more autonomy, more mastery, more purpose in their work? But as things progress, existing company policies, rules, attitudes, etc. will begin to assert themselves. To the detriment of staff morale, motivation and engagement. Pretty soon, staff will begin to question the sincerity of the management in their support for “going Agile”. Pretty soon, it will start to become apparent to anyone who’s paying attention that existing policies, rules, etc., have to change fundamentally to see the outcomes sought begin to happen.

And with declining staff engagement in “going Agile”, and reducing enthusiasm for understanding the principles necessary for making Agile successful, progress will slow to a crawl. At this point, middle-management, who have to carry the burden of making “going Agile” happen will also begin, quietly, to question the wisdom of the senior management direction. This will lead to their more often reverting to orthodox, “tried and tested” (and less personally burdensome) ways of working. And more often baulking at the effort needed to push through adoption of more Agile practices.

What To Do?

So, what’s a company to do? Most companies will not realise, or want to hear, that the Analytic mindset is fundamentally incompatible with successfully “going Agile”. So, another Agile adoption failure is in the making.

Personally, having helped various companies face up to this challenge, I’d say:

“It’s extremely unlikely that you’ll want – or even be able – to give up your existing world view. At least in the short term. So something’s got to give. And it’s probably better that you give up on “going Agile”. But DON’T give up on wanting things to be better. Park your Agile aspirations, and try another path, another solution. After all, it’s the OUTCOMES you seek that matter, not some specific – and cargo-culted – solution.”

So what might that alternative solution look like? What can an unrepentantly Analytic-minded organisation do to improve its software development outcomes?

My recommendation would be to focus on the interpersonal relationships within and between departments. Help developers understand and relate to customers (both internal and external) better. Help other folks within the organisation better understand and relate to developers.

Leveraging these improving relationships, encourage multi-party, cross-function dialogue about the outcomes sought, and what folks of every stripe can do, every day, to begin to shift the organisation’s rules, policies, structures and assumptions.

In a nutshell, be less autocratic, directive and strategic, and more democratic, collegiate and opportunistic.

And remember, I’m here to help.

– Bob

World Class? Really?

Some six years ago now, I wrote a post describing what might characterise a world class software / product development / collaborative knowledge work business.

In the interim, I’ve had some opportunities to work on these ideas for various clients. My consequent experiences, whilst in no way invalidating that post, have thrown up different perspectives on the question of “world class”.

Firstly, do you want it? Moving towards becoming a world class business involves a shed load of work, over many years. Do you want to commit to that effort? Even though the goal sounds noble, ambitious, attractive, does your business have what it takes to even begin the journey in earnest, let alone stick at it.

Then, do you need it? Absent powerful drivers spurring you on towards the goal, will you have the grit necessary to keep at it? Or will the initiative flounder and drown in the minutiae of daily exigencies, such as the constant pressure to get product and features out the door, to keep investors satisfied with (short term) results, etc.? And is the ROI there, in your context? If you do keep on the sometime joyful, sometimes wearysome path, and attain “world class” status, will the effort pay back in terms of e.g. the bottom line?

If your answers to the preceding two questions are yes, then we can get down to considering the characteristics of a world class collaborative knowledge-work business. What might it look like, that goal state?

Here’s my current take.

Context

Just in case a little context might help, here’s a variant of the Rightshifting chart which illustrates world class in terms of relative effectiveness (i.e. how effective are world class organisations relative to their peers?) The yellow area highlights those organisations (those at least circa 2.5 times more effective than the median) we might consider world class:

WorldClass

Fields of Competency

Any world class collaborative knowledge-work business must have mastered a bunch of different fields of knowledge. That’s not to say everyone in the organisation needs to have reached mastery (Level 5 – see below) in every one of the follow fields. But there must be a widespread acquaintance with all these fields, and some level of individual competent in each.

I suggest the following Dreyfus-inspired model for characterising an individual’s (practitioner’s) level of competency (or action-oriented knowledge) in any given field:

Level One (Novice)

The Novice level in each Field invites practitioners to acquire the basic vocabulary and core concepts of the Field. Attainment criteria will specify the expected vocabulary and core concepts. The Novice level also invites practitioners to acquire and demonstrate the ability to read and understand materials (books, articles, papers, videos, podcasts, etc.) related to the vocabulary and core concepts of the Field.

Level Two (Advanced Beginner)

The Advanced Beginner level in each Field invites practitioners to acquire the ability to critique key artefacts commonly found in the given Field. The Advanced Beginner level also invites practitioners to read more widely, and understand different perspectives or more nuanced aspects of, and peripheral or advanced elements within the Field.

Level Three (Competent)

The Competent level in each Field invites practitioners to acquire and demonstrate a practical competency in the core concepts in the Field, for example through the ability to apply the concepts, or create key artefacts, unaided.
The Competent level also invites practitioners to acquire and demonstrate the ability to collaborate with others in exploring and applying the abilities acquired in the Novice and Advanced Beginner levels.

Level Four (Proficient)

The Proficient level in each Field invites practitioners to acquire and demonstrate the ability to prepare and present examples and other educational materials appropriate to the given Field. The Proficient level also invites practitioners to acquire and demonstrate the ability to coach or otherwise guide others in applying the abilities acquired in the Novice, Advanced Beginner and Competent levels.

Level Five (Master)

The Master level in each Field invites practitioners to acquire and demonstrate national or international thought leadership in the Field. This can include: making significant public contributions or extensions to the Field; becoming a publicly recognised expert in the Field; publishing books, papers and/or articles relevant to the Field; etc.

The Fields

Any business that aspires to world class status must attain effective competencies in a wide range of different fields. The following list suggests the fields I have found most relevant to collaborative knowledge-work business in general, and software / product tech businesses in particular:

Flow

  • Flow (product development) (n): the movement of the designs, etc., for a product or service through the steps of the design processes which create them.
  • Continuous Flow (n): The progressive movement of units of design through value-adding steps within a design process such that a product design or service design proceeds from conception into production without stoppages, delays, or back flows.
  • See also: Optimised Flow Demonstration (video)

Deming

  • * Many in Japan credit Bill Deming for what has become known as the Japanese post-war economic miracle of 1950 to 1960.
  • William Edwards Deming (October 14, 1900 – December 20, 1993) was an American engineer, statistician, professor, author, lecturer, and management consultant. Deming is best known for his work in Japan after WWII, particularly his work with the leaders of Japanese industry.

Risk Management

  • Risk management is the discipline and practice of explicitly identifying and managing key risks.

    “Risk Management is Project Management for grown-ups.”
    ~ DeMarco & Lister

  • Potential benefits include:
    • makes aggressive risk-taking possible
    • protects us from getting blindsided
    • provides minimum-cost downside protection
    • reveals invisible transfers of responsibility
    • isolates the failure of a subproject
  • Note; Many Agile practices are, at their heart, about risk management.

Mindset

  • Mindset a.k.a. collective (organisational) memeplex (n): A set of memes (ideas, assumptions, beliefs, heuristics, etc.) which interact to reinforce each other.

“A memeplex is a set of memes which, while not necessarily being good survivors on their own, are good survivors in the presence of other members of the memeplex.”
~ Richard Dawkins in The God Delusion

  • The “organisational mindset” is a set of beliefs about the world and the world of work which act to reinforce each other.
  • These interlocking beliefs tightly bind organisations into a straight-jacket of thought patterns which many find inescapable. Without coordinated interventions at multiple points in the memeplex simultaneously, these interactions will prevail, as will the status quo.

Requirements a.k.a. Needs Management

  • A more or less formal approach to identifying and communicating needs
  • Any approach that ensures that everyone involved in attending to the identified needs shares a clear understanding of the required outcome(s): “doing the RIGHT thing”.

Fellowship

  • A system of organisational governance based on the precepts of Situational Leadership and with a primary focus on the quality of interpersonal relationships as a means to improved organisational health and effectiveness.
  • More generally, paying attend to the quality and effectiveness of the collaborative relationships across and through the business (and the extended value network of which it is a part).

Cognitive Function

  • Cognitive function (Neurology) (n): Any mental process that involves symbolic operations–e.g. perception, memory, creation of imagery, and thinking; Cognitive Function encompasses awareness and capacity for judgment.
  • Effectiveness of collaborative knowledge work is dictated by both e.g. quality of interpersonal relationships and degree of Cognitive Function.
  • See also: Cognitive Science

PDCA

  • PDCA (plan–do–check–act, or plan–do–check–adjust) is an iterative four-step method used for the control and continuous improvement of processes and products. It is also known as the Deming circle/cycle/wheel, Shewhart cycle, control circle/cycle, or plan–do–study–act (PDSA).
  • Based on the scientific method, (Cf. Francis Bacon) e.g. “hypothesis” – “experiment” – “evaluation”.

Statistical Process Control (SPC)

  • Statistical process control (SPC) is a method of quality control which uses statistical methods. SPC is applied in order to monitor and control a process.
  • Key tools used in SPC include control charts; a focus on continuous improvement; and the design of experiments.
  • See also: The Red Beads and the Red Bead Experiment with Dr. W. Edwards Deming (video)

Lean Product Development

  • Lean Product Development applies ideas from Lean Manufacturing to the design and development of new products (See e.g. books by Allen Ward and Michael Kennedy)
  • Aims to improve the flow of new ideas “from concept to cash”.
  • Can also help raise levels of innovation.
  • Exemplar: TPDS (Toyota Product Development System)

Don Reinertsen’s Work

  • Don Reinertsen is the author of three of the most definitive and best-selling books on product development.
  • His 1991 book, Developing Products in Half the Time is a product development classic.
  • His 1997 book, Managing the Design Factory: A Product Developer’s Toolkit, was the first book to describe how the principles of Just-in-Time manufacturing could be applied to product development. In the past 16 years this approach has become known as Lean Product Development.
  • His latest award-winning book, The Principles of Product Development Flow: Second Generation Lean Product Development, has been praised as, “… quite simply the most advanced product development book you can buy.”

Neuroscience

  • (Cognitive) neuroscience is concerned with the scientific study of the biological processes and aspects that underlie cognition, with a specific focus on the neural connections in the brain which are involved in mental processes.
  • (Cognitive) neuroscience addresses the questions of how psychological/cognitive activities are affected or controlled by neural circuits in the brain. Cognitive neuroscience is a branch of both psychology and neuroscience, overlapping with disciplines such as physiological psychology, cognitive psychology, and neuropsychology.
  • See also: Cognitive Function

Theory of Constraints

  • The Theory of Constraints (TOC) is a management paradigm originated by Eliyahu M. Goldratt.
  • TOC proposes a scientific approach to improvement. It hypothesises that every complex system, including manufacturing processes, consists of multiple linked activities, just one of which acts as a constraint upon the entire system (the “weakest link in the chain”).
  • TOC has a wide range of “thinking tools” which together form a coherent problem-solving and change management system.

Self-organisation

  • Self-organisation (n): Ability of a system to spontaneously arrange its components or elements in a purposeful (non-random) manner. It is as if the system knows how to ‘do its own thing.’ Many natural systems such as cells, chemical compounds, galaxies, organisms and planets show this property. Animal and human communities too display self-organization.

    “An empowered organization is one in which individuals have the knowledge, skill, desire, and opportunity to personally succeed in a way that leads to collective organisational success.”
    ~ Stephen R. Covey

Quantification

  • In mathematics and empirical science, quantification is the act of counting and measuring that maps human sense observations and experiences into members of some set of numbers. Quantification in this sense is fundamental to the scientific method.
  • See also: Tom Gilb

Systems Thinking

  • Systems thinking provides a model of decision-making that helps organisations effectively deal with change and adapt.
  • It is a component of a learning organisation – one that facilitates learning throughout the organisation to transform itself and adapt.
  • See also: Peter Senge, Russell L. Ackoff, Donella Meadows, etc.

Psychology

  • Psychology (n): the study of behaviour and mind, embracing all aspects of conscious and unconscious experience as well as thought. It is an academic discipline and an applied science which seeks to understand individuals and groups.

Argyris

  • An American business theorist, Professor Emeritus at Harvard Business School, and known for his work on interpersonal communication, organisational effectiveness, double-loop learning and learning organisations.
  • See also: Action Science.

Psychotherapy

  • Psychotherapy (n): interventions which facilitate the shifting of perspectives and attitudes, and thus, human behaviours.
  • See also: Organisational Psychotherapy

To the above list of Fields, I invite you to add any which may have specific resonance or relevance to your own business.

And then there are the lists of technical capabilities you need to be present in your various business functions, too.

Aside – CMMI

As an aside, CMMI also provides an extensive list of “capability areas” ( circa 128 different areas, last time I looked) focussed on engineering capabilities. Note: I find the CMMI list useful, but only as a primer, not as a full-blown recipe for success.

Summary

All the above begs the question: how to get there? And, how close are you to world class, so far?

– Bob

The Advice Process – Flaws and Fixes

“The advice process is a tool that helps decision-making via collective intelligence. Much depends on the spirit in which people approach it. When the advice process is introduced, it might be worthwhile to train colleagues not only in the mechanics but also on the mindset underlying effective use.”

We’ve been using the Advice Process for several months now. Whilst we’re still very much committed to its use, and wish to see the changes it promotes, all has not been going smoothly with its uptake.

Potential

We chose the Advice process as a means to devolving and distributing decision-making. We like its potential for quicker – and more impactful – decisions, raised levels of trust, improved communication, and higher levels of involvement and engagement. This list describes this potential, as described by its early promoter, Dennis Bakke of AES, in more detail:

  • Community: it draws people, whose advice is sought into the question at hand. They learn about the issue. The sharing of information reinforces the feeling of community. The person whose advice is sought feels honored and needed
  • Humility: asking for advice is an act of humility, which is one of the most important characteristics of a fun workplace. The act alone says, “I need you“. The decision maker and the adviser are pushed into a closer relationship. This makes it nearly impossible for the decision-maker to ignore the advice.
  • Learning: making decisions is on-the-job education. Advice comes from people who have an understanding of the situation and care about the outcome. No other form of education or training can match this real-time experience.
  • Better decisions: chances of reaching the best decision are greater than under conventional top-down approaches. The decision maker has the advantage of being closer to the issue and has to live with responsibility for the consequences of the decision. Advice provides diverse input, uncovering important issues and new perspectives.
  • Fun: the process is just plain fun for the decision-maker, because it mirrors the joy found in playing team sports. The advice process stimulates initiative and creativity, which are enhanced by the wisdom from knowledgeable people elsewhere in the organization.

Practice

In practice, we have not yet seen full realisation of this potential. Overall, we attribute this to poor implementation of the Advice Process, which we’re now intent (sic) on fixing – whilst not undermining its original intent (see above).

Flaws

Some of the implementation flaws we have experienced include:

  • Permission-seeking. Some folks have not yet overcome their established reflex of seeking permission. The Advice Process as conceived rejects permission-seeking, placing implicit responsibility for outcomes on the individual or team with the intent, not on the permission-giver. This shift (i.e. from authoritarianism to co-creation) requires a degree of courage from all parties.
  • Trust. Some advisors have found it challenging to trust the intentions or competence of those seeking advice.
  • Belief. Some with intentions have found it challenging to believe that they now have the power/authority to make key decisions.
  • Misunderstanding/clashing frames of reference. Sometimes, advice sought and then given has been received/interpreted as denial of permission.
  • Impatience. The delay between announcing intent and receiving advice has proved a source of friction, leading on occasions to proceeding without waiting to receive considered advice from advisors who may hold key pieces of the puzzle (often, these are the busiest of people).
  • Criticality. Some people have voiced concerns that key business decisions with serious negative commercial or reputational risks could proceed to action, even when some key risks go unappreciated or unaddressed (due to advice being sought from the wrong quarters, ignored, or not understood).

Fixes

We’re intending to experiment with addressing the above concerns through a couple of refinements:

  • Shared responsibility. The onus of communication will rest equally with those communicating intent and those from whom for advice is sought. Those announcing an intent are requested to actively pursue advisors to confirm their intent has been heard and understood by all the necessary parties; those from whom advice is sought are requested to respond promptly and with due consideration of the significance of their role and advice.
  • Time-outs. In those cases where someone believes there is a problem – maybe they feel the Advice Process has not been followed correctly or not used when it should have been – that someone may call a Time-out. The intention or action in question – which may already be in train – will then be suspended, pending a go-around (i.e. another taking of soundings, general proposal of intent, seeking of advice, confirmation that the intent has been understood, and consideration of advice received). Note: This does not imply that the intention itself has been denied or overruled. Rather, some party to a particular instance of the Advice Process believes the Advice Process has not been followed or used appropriately, and that the risks implicit in the intention or action are likely not being duly considered or attended-to.
  • Arbitration. We’ll see if we need to introduce some arbitration or conflict-resolution mechanism to handle repeated time-outs being called against a given intention or action, or to handle occasions where parties disagree on whether the Advice Process has indeed been followed correctly or not.

I’ll keep you posted on how our experiment is going.

– Bob

Further Reading

Decision Making ~ ReinventingOrganisations Wiki

The Advice Process – Definition and Usage Tips ~ Daniel Tenner

Advice Process for Effective Organizational Decision-Making ~ Agilitrix

Business Development

The word “development” in the phrase “business development” has always meant something very different than in the phrases “product development” or “software development”. The term “business development” is generally taken to mean finding new customers, building customer relationships, and such like. And thus responsibility primarily resides in the Sales & Marketing silo.

Maybe this is one reason why the idea of “developing” a business, in the same sense as developing a product or a software system, is pretty much unknown to business folks. Many’s the time I have invited business folks to consider the merits of taking a “development”approach to the construction and evolution of their business, only to receive little response other than a sea of blank faces.

Which makes me sad, because there’s an enormous amount of “development” practice, expertise and skills available to apply to the challenges of developing a business or other organisation. I’d say that some 80% of the know-how involved in developing products or software systems is directly applicable to “developing” an organisation.

Have you ever suggested to business folks that “development” know-how could have a massive impact on their bottom line? Or otherwise effectively meet many if not all of their core needs? What kind of reactions have you seen?

– Bob

Further Reading

What, Exactly, Is Business Developoment? ~ Scott Pollack
Prod•gnosis In A Nutshell ~ FlowchainSensei

Dead Wood

Shoots

Much of my work over the past twenty years or so has been informed by the grace and wisdom of Dr. W Edwards Deming, often known as Bill Deming. This post is inspired by the following quote:

“The only reason an organization has dead wood is that management either hired dead wood or it hired live wood and killed it.”

~ Bill Deming

Note: Very similar quotes have been attributed to Peter Scholtes, and indeed the above quote may well be Dr. Deming paraphrasing Peter Scholtes.

Definition

“Dead Wood” here refers to people in a group or organisation who are no longer actively useful – people still drawing salary, etc., but adding little or no value.

Deming’s 95/5

Bill Deming observed that “95% of the performance of an organization is attributable to the system (processes, technology, work design, regulations, etc.) and 5% are attributable to the individual”. If we accept this, then is there even such a thing as dead wood? Maybe there’s just folks trying to do a good job, but frustrated – defeated, even – by the system, the way the work works, and the situations in which they find themselves.

Dead – Or Just Dormant?

I have seen many folks, in various organisations, written-off as “dead wood”. I see this much like “flipping the bozo bit” – many managers seem to believe that “dead wood-edness” is an inherent attribute of individuals. And little or nothing to do with their circumstances or situation. Maybe they have not heard of the Fundamental Attribution Error.

Is dead wood really dead, or are those so labelled just in the wrong jobs, in the wrong teams, in circumstance where they’ve been all but forced to disengage, where they have learned to be helpless?

“There is nothing either good or bad, but thinking makes it so.”

~ William Shakespeare

Maybe you know some “dead wood” in your team, group or organisation. What might it take to bring them back to life, to flourish, to see some green shoots of new growth? Is there anything you could do to help that along?

– Bob

Further Reading

Four Days With Dr Deming ~ William J. Latzko & David M. Saunders
The Leader’s Handbook ~ Dr. Peter R. Scholtes

%d bloggers like this: