Archive

Antimatter principle

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

Difficult Conversations

Before this turns into a mini-series, I’d just like to add one observation to my previous two posts.

Setting aside the outcomes sought by the people that matter, outcomes related to the business and its needs, there’s the not inconsequential matter of the unexpressed outcomes sought by these folks with respect to their own personal needs. Often, these needs are not discussed, shared or even registered at a conscious level by the individuals concerned. And often, then, explicit outcomes have yet to be identified – both by them and by us.

There’s not much point addressing the needs of the organisation (see my previous post) without also attempting, at least, to address the needs of the individual people that matter. This asks of us more effort, because we’re likely to be starting “further back”, before these folks have even expressed their personal sought outcomes. And because they may be reluctant to get into these kinds of conversations, being unusual in a workplace context. And then there’s the difficulty involved in “speaking to power” or at least empathising with people in positions of power.

Examples

Some examples may help clarify this observation.

Senior managers and executives, in articulating the sought outcomes listed previously, may also want to control the solutions chosen, hence their providing solutions in the form of wants. Often there’s an underlying need to feel “in control”, driven by some need, such as their need for order, or personal safety, or kudos.

Similarly, articulating their sought outcomes may, in part, derive from their need for tangible progress, or a need to be seen as the driver of that progress.

Summary

Entering into, and sharing the exploration of these often intensely personal topics is certainly difficult. But that difficulty can ease when we have the right conditions – such as trust, friendship, skill, and safety. And without such conversations, we’re that much more likely to spend much time and effort on delivering outcomes that no one really needs, or worse – that actively work against folks’ needs.

– Bob

Further Reading

Crucial Conversations ~ Patterson & Grenny
Difficult Conversations: How to Discuss What Matters Most ~ Patton, Stone, Heen & Fisher
Discussing the Undiscussable ~ Bill Noonan
Feelings Inventory ~ List at the Centre For Nonviolent Communication
Needs Inventory ~ List at the Centre For Nonviolent Communication

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

Means and Ends

How often do we try to “improve” our product and services, and the revenue and profit therefrom (i.e. the ends), and how often do we try to improve the way the work works, the way we develop those products and services (i.e. the means)?

Folks have needs related to the way the work works, in many ways just as profound as the needs they have of the products and services (features) resulting from that work.

To illustrate what I’m talking about, here’s a short list of some of the needs folks can have related to the way the (product development) work works:

  • Ongoing information (development schedules, quality levels, costs, plans, etc.)
  • Confidence (e.g. that milestones and Due Dates will be hit)
  • Growth
  • Learning
  • A sense of purpose (are we spending our time on stuff that matters?)
  • Integrity
  • Connection (e.g. human connections, relationships between people)
  • Appreciation
  • Harmony
  • Achievement
  • Etc. (and lots more possibilities in e.g. this Needs Inventory)

This post is an invitation to apply the same considerations to the explicit and intentional design of the way the work works, as we do to the way our products or services under development work.

In my previous post, “Antimatter Evo”, I explored the twelve principles associated with the Agile Manifesto, and proposed a way to radically simplify those twelve principle down to, essentially, one (“Attend to folks’ needs”).

May I invite you to consider the impact on your development efforts of applying the same principle – the Antimatter Principle?

Does your current approach – to defining and improving the way the work works – attend to the needs of the people that matter?

Blind Spot

In the typical product development situation, each new product (or service) that enters development is handled much like all those which have gone before. Outwith major revisions to the way the work works (say, adopting a revolutionary new approach such as Agile), incremental improvements to the means of development can occur, and occasionally do. Yet with both Kaikaku (revolutionary change) and Kaizen (incremental change), change is rarely connected to better serving the needs of the “folks that matter”. Put another way, change most often serves the product and its users, and rarely the folks impacted by the way the work works.

How blind is your organisation, presently, to the ability of its development efforts to meet the relevant needs of the people involved in those efforts?

What if we applied ourselves to understanding the needs of the people that matter, as they pertain to the way the work works? What effect might that have on the social dynamic, the relationships between different people and groups, on productivity, and on the general success of our development efforts?

– Bob

Antimatter Evo

Tom Gilb has long been known for his “Evo”(evolutionary) approach to software engineering, and more recently for his sharp criticisms of the Agile Manifesto (99% of which I agree with).

In a recent (February 2018) PPI Systems Engineering Newsletter, he authors the feature article “How Well Does the Agile Manifesto Align with Principles that Lead to Success in Product Development?”, describing in some depth his issues with the Agile Manifesto, its Four Values and Twelve Principles.

Apropos the latter, Tom comments at length on each, providing for each a “reformulation”. I repeat each of these twelve reformulations here, along with a translation to the vocabulary (and frame) of the Antimatter Principle:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Tom’s reformulation: Development efforts should attempt to deliver, measurably and cost-effectively, a well-defined set of prioritized stakeholder value-levels, as early as possible.

Antimatter translation: As early and frequently as possible, in the course of developing e.g. a new product or service, we (the development team) will identify, quantify, and subsequently measure, a well-defined set of the needs of all the people that matter, and deliver, as early and frequently as possible, stuff that we believe meets those needs.

Antimatter simplification: Our highest priority is to continually attend to the needs of everyone that matters.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Tom’s reformulation: Development processes must be able to discover and incorporate changes in stakeholder requirements, as soon as possible, and to understand their priority, their consequences to other stakeholders, to system architecture plans, to project plans, and contracts.

Antimatter translation: Our approach to developing new products or services enables the development team to discover and incorporate changes in the needs of anyone that matters, and the members of the community of “everyone that matters”, as soon as possible. The development team has means to quantify, share and compare priorities, and means to both understand and communicate the impact of such changes to the community of “everyone that matters”.

Antimatter simplification: Handle changing needs, and changing membership of the “everyone that matters” community, in ways that meet the needs of the people that matter.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Tom’s reformulation: Plan to deliver some measurable degree of improvement, to planned and prioritized stakeholder value requirements, as soon, and as frequently, as resources permit.

Antimatter translation: Plan to deliver some measurable degree of improvement to the planned and prioritised set of needs (of the people that matter) as soon, and as frequently, as needed.

Antimatter simplification: Deliver stuff as often as, and by means that, meets the needs of everyone that matters.

4. Business people and developers must work together daily throughout the project

Tom’s reformulation: All parties to a development effort (stakeholders), need to have a relevant voice for their interests (requirements), and an insight into the parts of the effort that they will potentially impact, or which can impact them, on a continuous basis, including into operations and decommissioning of a system.

Antimatter translation: Have established means through which we continually solicits the needs of the people that matter, means that are well-defined and well-understood by everyone that matters. These means provide: an ear for the feelings and needs of the people that matter, and feedback on the consequences (impact) of attending to those needs.

Antimatter simplification: Share needs and solutions as often as, and by means that, meets the needs of everyone that matters.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Tom’s reformulation: Motivate stakeholders and developers, by agreeing on their high-level priority objectives, and give them freedom to find the most cost-effective solutions.

Antimatter translation: Motivate everyone that matters by agreeing on everyone’s needs, and give everyone, as a group, the freedom to collaborate in negotiating the trade-offs, priorities, and most cost-effective solutions.

Antimatter simplification: Motivate people to the degree that, and by means that, meets the needs of everyone that matters.

6. Enable face-to-face interactions.

Tom’s reformulation: Enable clear communication, in writing, in a common project database. Enable collection and prioritization, and continuous updates, of all considerations about requirements, designs, economics, constraints, risks, issues, dependencies, and prioritization.

Antimatter translation: Provide communications that meet the needs of everyone that matters. Manage these needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Facilitate sharing of information, feelings, needs, etc. to the degree that, and by means that, meets the needs of everyone that matters.

7. Working software is the primary measure of progress.

Tom’s reformulation: The primary measure of development progress is the ‘degree of actual stakeholder-delivered planned value levels’ with respect to planned resources, such as budgets and deadlines.

Antimatter translation: The primary measure of development progress is the ‘degree of actual needs met’ with respect to the planned, prioritised and quantified set of needs of everyone the matters. Note: Assuming end-users or customers are amongst the set of people that matter, this demands the product or service in question is in active service with those people, such that we can measure how well (the degree to which) their needs are actually being met. And don’t forget the needs pertaining to how the endeavour is being conducted!

Antimatter simplification: Choose a primary measure of progress that meets the needs of everyone that matters.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Tom’s reformulation: We believe that a wide variety of strategies, adapted to current local cultures, can be used to maintain a reasonable workload for developers, and other stakeholders; so that stress and pressures, which result in failed systems, need not occur.

Antimatter translation: Proceed at a pace that meets the needs of everyone that matters. Manage these (dynamic and potentially conflicting) needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Choose a pace that meets the needs of everyone that matters.

9. Continuous attention to technical excellence and good design enhances agility.

Tom’s reformulation: Technical excellence in products, services, systems and organizations, can and should be quantified, for any serious discussion or application. The suggested strategies or architectures, for reaching these ‘quantified excellence requirements’, should be estimated, using Value Decision Tables [45, 1, 2], and then measured in early small incremental delivery steps.

Antimatter translation: Aim for a level of technical excellence and good design – and any other quality-related attributes – that meet the needs of everyone that matters. Manage these (dynamic and potentially conflicting) needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Agree on attributes of quality, and levels of quality, with respect to the means of the endeavour, that meets the needs of everyone that matters.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

Tom’s reformulation: We need to learn and apply methods, of which there are many available, to help us understand complex systems and complex relations. [1, 2, 46, 47, 48, 49] and succeed in meeting our goals in spite of them.

Antimatter translation: Aim for a level of simplicity – and any other quality-related attributes -that meet the needs of everyone that matters. Manage these (dynamic and potentially conflicting) needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Spend effort only where it directly attends to some need of someone that matters.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Tom’s reformulation (A): The most useful value and quality requirements will be quantified, and will use other mechanisms, including careful corresponding stakeholder analysis [1, 51, and 52], to facilitate understanding.

Tom’s reformulation (B): The most cost-effective designs/architecture, with respect to our quantified value and resource requirements, will be estimated and progress tracked, utilizing a Value Decision Table with its evidence, sources, and uncertainty. They will be prioritized by values/resources with respect to risks [45].

Tom’s reformulation (Simplified, combined): We will use engineering quantification for all variable requirements, and for all architecture.

Antimatter translation: Choose organisational structures and methods (teams, heroes, feature teams, self-organisation, quantification, etc.) for the endeavour that meet the needs of everyone that matters. Manage these (dynamic and potentially conflicting) needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Agree on attributes of quality, and levels of quality, with respect to the organisation of the endeavour, that meets the needs of everyone that matters.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Tom’s reformulation: A process like the Defect Prevention Process (DPP), or another more-suitable for current culture, which delegates power to analyze and cure organizational weaknesses, will be applied: using participation from small self-organized teams to define and prove more cost-effective work environments, tools, methods, and processes.

Antimatter translation: Aim to learn as much from our work as meets the needs of everyone that matters. Manage these needs, including negotiated solutions, just as all the other needs in the endeavour. 

Antimatter simplification: Pursue improvement, with respect to the means and organisation of the endeavour, that meets the needs of everyone that matters.

Summary

The key insight that emerges from this exercise in translation is this:

Once we have a more-or-less formal and established approach for identifying who matters and their needs, with respect to the endeavour at hand – and then tracking, negotiating and managing the evolving community of “everyone that matters” and their needs – much of the minutiae of the Twelve Principles, and debates thereon, evaporates.

In a nutshell: we must attend not only to the needs in the context of the particular product or service under development, but also to the needs of everyone that matters in the context of the means (conduct, organisation) of that development effort.

– Bob

Six FAQs – X or Y?

One of my most popular posts is “Six FAQs” – six questions I’m frequently asked about software and product development organisations. Let’s take a look at these six FAQs from the perspective of both Theory X and Theory Y, so as to illuminate how fundamentally different these two perspectives are on these topics.

Q1: How can we motivate our workers?

AX1: Use carrots and sticks. Incentives and punishments. Offer people money (raises and bonuses) and other financial rewards, and freebies (such as free lunches, foosball, sofas, working from home, and 20% time) for doing a good job. Bare-faced threats often undermine morale, but implicit threats, such as assignment to unattractive tasks or teams, lack of promotion, withheld raises, etc., can help keep people in line and focussed. We cannot just sit back and let idle people slack on the job.

AY1: You can’t. Oh, you can dream up incentive schemes, bonus packages, and so on, but there’s plenty of research – and experience – to show that such attempts at extrinsic motivation of knowledge workers only make folks’ performance on the job worse. On the other hand, intrinsic motivation is very powerful – but that comes from the workers themselves. The only thing you can do is to work on creating an environment where maybe, just maybe, some folks feel a little better about themselves, their colleagues, and the common purpose. And hope – yes hope – that some intrinsic motivation emerges, here and there. You can’t change someone else’s intrinsic motivation – only they can do that.

Q2: How can we change the organisation’s culture?

AX2: Assign a team to the task of changing the culture. Increase the chances of success by hiring change management consultants to direct that team. Task the team with designing the culture you want to see and then run a project to implement that design. Try a pilot project in one area of the business to work out the wrinkles before committing the whole organisation. Offer incentives for folks who get with the programme. Lay heavy hints (sweetened with humour) that laggards and saboteurs will be let go. Make it clear that the status quo is not an option, and that there will be personal, unpleasant consequences for those who can’t or won’t change their behaviours.

AY2: You can’t. Culture is read-only. A manifestation and a reflection of the underlying, collective assumptions and beliefs of all the folks working in the organisation. To see any cultural changes, you have to work on – by which I mean work towards a wholesale replacement of – this underlying collective memeplex. And that involves working with peoples’ heads, and in particular, collective headspaces. You can’t change other people’s assumptions and beliefs – only they can do that.

Q3: How can we change the mindset of managers?

AX3: Your managers are the shock troops for change. Impress upon them their responsibilities in leading change, and in particular the change to their own behaviours and assumptions. Tie these changes into their individual remuneration packages through targets and KPIs. Provide extensive training in the new mindset, first for the managers and then cascading down to the front line employees. By having managers lead the change, they will develop the insights and skills necessary to bring everyone else along.

AY3: You can’t. Managers – anyone, really – will only change their mindset when they see how their present mindset is ineffective at getting their needs – and the needs of others – met. Change (of mindset) is a normative process – it emerges from direct personal experiences of e.g. the way the work works now – and the problems inherent therein. You can’t change someone else’s mindset – only they can do that.

Q4: How can we get teams to take responsibility?

AX4: Lead, manage, threaten, cajole, plead and bribe folks. Appeal to both their self-interest and loyalty to the company. Whatever means you choose, it’s the outcome that’s most important. People need to take responsibility. You can’t make an omelette without breaking some eggs.

AY4: You can’t. You can threaten, cajole, plead, bribe, appeal to folks’ better nature, etc. But again, research and experience both show these only serve to undermine folks’ goodwill and commitment. If you need folks to take more responsibility, maybe the best way is to just be honest about that, explain your need, and make a refusable request? What would you like the reason to be for them doing as you request? You can’t change someone else’s willingness to take responsibility – only they can do that.

Q5: How can we get managers to trust their teams?

AX5: This is a non-issue. Managers don’t need to trust their teams. Managers must issues clear instructions on what needs doing and the best way to do it. Teams that can’t be trusted to carry out those instructions must be sanctioned or restructured to weed out the weak and feckless.We must have compliance.

AY5: You can’t. Managers will only choose to trust their teams – or anyone else – if they find they have a need to do so. And that need only becomes obvious enough to spur action when managers come to understand just how trust helps them get some of their other needs met better. You can’t change someone else’s willingness to trust others – only they can do that.

Q6: How can we develop people’s competencies?

AX6: Firstly, training. Ensure people get regular training in areas of competency important to the business. Secondly, put people into stressful situations where they’ll have to step up and learn new competencies. Sink or swim. Thirdly, motivate them to become more competent (for which, see Q1).

AY6: You can’t. You can, however, create conditions where those folks who want to develop their own competencies can do so more easily. So the question then becomes, how can we get folks to want to develop their own competencies? Which is Q1 (see above). You can’t change someone else’s willingness to learn – only they can do that.

In a nutshell, the direct answer to all the above questions depends directly on the lens through which you see the world of work: the Theory X answers (AX1-6) are poles apart from the Theory-Y lens answers (AY1-6).

Which lens do you typically reach for when considering these questions?

– Bob

Further Reading

The Art And Science of Changing People Who Don’t Want to Change ~ Reut Schwartz-Hebron
Theories of Motivation – Think Different blog post

%d bloggers like this: