Archive

Monthly Archives: February 2013

Manage As If You Meant It

(With thanks to Keith Braithwaite for inspiring the title of this post)

Wouldn’t it be great if you had a specification describing the “API to your manager”? I mean, think of all the things a useful manager can do for her people, and how many of these things never happen – or at best, happen haphazardly – because no one knows they’re there, how to invoke them or how to track things?

Aside: At this point, you may just be reminded of Robert K. Greenleaf’s idea of Servant Leadership. If we have to have leadership at all, then maybe servant leadership is a fair kind of leadership to hope for. Or perhaps Host Leadership.

As well as providing generally improved clarity regarding what a manager can and will do, a well-defined API might – as Roger Martin writes in The Responsibility Virus –  “help people avoid the natural predisposition to screw up the handling of responsibility in ways that undermine their goals and well-being,”

If a manager embraced the idea of an API, and, more specifically, wanted to develop one, how might that happen?

Aside: I’ve been musing on the idea recently, as an offshoot of some work I’ve been doing on Product-Development-as-a-service. This latter may likely be the topic of a future post.

The Manager API

So, the thought occurred to me, could we use something like BDD to facilitate a conversation between a manager and the folks to whom she’s providing services – not least the folks she’s “managing”? In other words, what benefits might accrue from having clarity on what the manager can (and can’t) do for her people, and for others who might, from time to time, also ask her to do things for them?

Here’s a couple of examples of stories that might be relevant for this “Manager API”:

Story: Developer Needs a New Piece of Kit
In order to work more productively
As a Developer
I need to have a way to obtain the necessary kit (computers, peripherals, software tools, etc). for the job at hand.

Scenario 1: I have a sudden need for a piece of kit
Given I have a sudden need for a new piece of kit

When I request that new piece of kit
Then...

Story: Development Team Needs a New Team Member
In order to continue meeting commitments to our stakeholders
As a Development Team
We need to find and enrol a new team member

Scenario 1: We know of someone who could fill the role
Given some folks already know someone who would be a good fit
When we need to make them a job offer
Then...

The TDD Connection

OK, so let’s assume that our manager has been having conversations with her stakeholders, and has identified some (early) versions of some stories worthy of implementation. How to approach such implementation?

Here, might Test Driven Development be helpful? Using TDD, the service implementation can emerge and evolve without much (hard) thinking. Here’s the vanilla TDD four-step red-green-refactor process:

  1. Add a test – the simplest possible
  2. See it fail (red)
  3. Make all tests (to date) pass, using the minimum amount of instructions (green)
  4. Refactor

Using this approach, the manager can – incrementally – implement some part – or all – of each “service” story, in turn. Of course, the “instructions” will not be coded in a programming language, for execution by a computer, but in human-readable e.g. pseudo-code or work instructions, for herself, and for others helping her deliver the service.

Your thoughts?

– Bob

Further Reading

Servant Leadership ~ Greenleaf
The Responsibility Virus ~ Roger L Martin

Intervention on People Issues is a Red Herring

Photo of some herring

Photo Credit: StuartWebster

In his typically assertive (cough) style, John Seddon in this video clip hits a particular nail on the head.

“Intervention on people issues is a red herring; but a popular red herring amongst Western management thinkers.”

~ John Seddon

It’s not that people don’t matter, it’s that there’s a paradox here: change the system and behaviour change comes for free. Also known as “don’t work on the 5%“.

Managers As Coaches

I’m writing this post because the implication for the trendy “managers as coaches” idea seems clear. If a manager is trying to coach a member of their staff, they’re not only “working on the 5%”, they’re also likely distracting themselves from their real job by spending less time working on the system.

“The productivity of work is not the responsibility of the worker but of the manager.”

~ Peter F. Drucker

How likely is it that coaching, whoever is doing it, is merely helping people cope better with the dysfunctions of the systems they find themselves working within? Not that an improved ability to cope with feelings of e.g. frustration, disempowerment and disengagement is without merit. But maybe that’s not what folks are looking to coaching to deliver?

Only when there’s a possibility of changing the system will coaching – specifically, coaching in how to change the system – provide any real value and meaningful change.

How often do coaches have any influence on – or recognised part to play in – such systemic change?

– Bob

Further Reading

Full Lean Iceland Panel Session – Vimeo video

Stakeholder, defined

In my previous post I talk about “stakeholders”. I occurs to me that I have used this term for so long that the definition I have for it may elude some folks, and differ from some other folks’ definitions.

So here’s my definition:

A stakeholder is any person that stands to (possibly) gain or lose something from a specific proposed or actual endeavour.

Or, expressed in terms of needs:

A stakeholder is any person with needs that might be met – or jeopardised – because of a specific proposed or actual endeavour.

Aside: Often, I find it convenient to subdivide the needs of any one individual, according to the various role(s) they may play in an endeavour. For an example of this, see my post entitled “Nonviolent Project management“.

– Bob

Effective Product Development

One question that has been preoccupying me in recent weeks is:

“What makes for effective product development?”

Having pondered on this question for a while, my own answer is presently quite simple:

“Meeting the needs of the stakeholders.”

Note I don’t say “Meeting the needs of the customers“ or “delivering value”. I do not single out any particular constituency of stakeholders, nor any particular kind of need.

So what does this statement mean? Let’s deconstruct it:

“Meeting…”

Not exceeding. Not falling short. Exactly meeting. Not that we’ll ever be able to meet the stakeholders’ needs exactly, for we will never be able to understand them or define them exactly.

“You cannot define being exactly on time.“

~ W. Edwards Deming

But it’s a consummation to which we can aspire, at least. And one to approach asymptotically.

“…the needs..”

Needs. Not wants. Not “requirements”. Not what folks say they need. What they actually need. At a specific point in time. To the extent that we have a product which meets folks’ needs, then we have a successful product. And we might do well to remember that rarely are needs of different stakeholder in harmony, congruent, compatible. We have to balance the various needs as best we can. We have to resolve conflicts. And no, I don’t mean compromise. Sometimes, balancing the various needs is just not going to be possible. So sometimes we’re onto a loser as far as coming up with a completely successful product goes. And needs can change. Over time. In different circumstances and contexts. A man in the desert might need water rather more than a man in a lake. So a successful product today, or in one context, may not be so successful tomorrow, or in another context. So we may have to produce difference variants, and change the product over time, to keep it in the “sweet spot” of the stakeholders’ collective needs.

“…of the stakeholders.”

All the stakeholders. Not just customers. Nor just the producing organisation. Nor just its managers and executives. Nor just the employees – developers and suchlike. Some years ago I coined the term “covalent” to describe this.

Few product development or software development folks seem to make an effort to explicitly list their stakeholders. Whether specific (people) or generic (constituencies). And fewer still seem to attend to understanding their respective needs, in any deliberate or organised way.

“Corporations should be maximizing stakeholder, not shareholder, value to employees, customers, and shareholders.”

~ Russell L. Ackoff

To sum up then. A product development organisation – or a product development effort – is effective to the extent the it meets the needs of its stakeholders. Simple as.

Having happy customers but dispirited employees is not so effective. Having happy employees but disappointed managers and executives is not so effective. Having happy executives but high costs or impacts on society at large is not so effective. You get the picture.

All the multitude of opinions, ideas, methodologies, etc. that speak to how to go about being effective at product development seem incidental compared to this basic definition of effectiveness.

– Bob

Afterword

One thing has been bugging me about this post. My thanks to Sami Honkonen for bringing it up, which in turn has motivated me to pen this afterword.

He tweeted “This is a local optimum. What about the system? Are you trolling?”

And while I was not trolling, I did fail to mention the systems implications of the answer “Meeting the needs of the stakeholders.”

It was not my intention to imply that effective product development is the sole responsibility of some “product development group” or function. In siloed organisations (the norm), there may be a product development silo. Although that in itself is rather unusual – piecemeal product development and product enhancement being much more common, with the work sliced up and stuffed into the existing silos of marketing, sales, IT, finance, etc.

To get to highly effective product development, the whole organisation must be involved. And ultimately, that means breaking down the siloes, liberating the specialists locked inside each, and bringing them together to evolve new “whole products”. C.f. Prod•gnosis.

Meeting the needs of all one’s stakeholders is always a challenge. Doing so effectively within a siloed organisation – focused on local optima – is even more of a challenge. Maybe being highly effective under those conditions is just not possible. I believe that attempting to move to a place of highly effective product development has profound implications for the organisation as a whole. And not least for the mindset that underpins the siloed model – i.e. the Analytic mindset.

Further Reading

Principles of Software Engineering Management ~ Tom Gilb
Competitive Engineering ~ Tom Gilb
Nonviolent Communication ~ Marshall B. Rosenberg

Baggage

Baggage

[Tl;Dr: A list of e.g. Theory-X memes that Analytic-minded organisations will find themselves giving up as they become more synergistic and effective.]

I have recently been giving a series of internal presentations about growing an effective Product Development capability, using ideas from Rightshifting and the Marshall Model as a general framework.

To one slide I talk about the intellectual baggage that any e.g. Analytic-minded organisation will find itself abandoning on its journey to Radicalsville.

Aside: If such baggage is not abandoned, then it’s inevitable that the journey will be.

Another term for “baggage” might be “premises that have become (or always were) invalid”. Here’s a list of such “invalid premises” that I tweeted this morning:

  • Invalid premise: Management is necessary and desirable.
  • Invalid premise: Hierarchy is the best way to e.g. organise, coordinate and align.
  • Invalid premise: People must be told what to do.
  • Invalid premise: Predictability is a function of tight control and e.g. conformance to rules.
  • Invalid premise: Predictability has no downside.
  • Invalid premise: We don’t want any problems.
  • Invalid premise: Coercion through e.g. fear, obligation, shame or guilt does not alter cognitive function (ability to think well).
  • Invalid premise: Jackal culture, jackal language is the best and only way to motivate and direct people.
  • Invalid premise: Feelings and emotions in the workplace are unprofessional and out of place.
  • Invalid premise: Theory X.
  • Invalid premise: Productivity and performance of individuals is down to the individual – their innate talents, skills, experience and attitudes.
  • Invalid premise: Effective knowledge-work is best achieved through factory-like conditions.
  • Invalid premise: Efficiency is King, effectiveness a nice-to-have.
  • Invalid premise: Highly (local) optimised parts of an organisation means an optimised (whole) organisation.
  • Invalid premise: Cost Accounting gives reliable numbers that can be safely used to guide decisions.
  • Invalid premise: Rationality trumps intuition, emotion and humanity.
  • Invalid premise: Conscious thought trumps subconscious thought.
  • Invalid premise: Man is a rational animal.
  • Invalid premise: Organisations as machines.
  • Invalid premise: People are as interchangeable as cogwheels.
  • Invalid premise: Fast is better than slow.
  • Invalid premise: Anyone gives a hoot about profits.
  • Invalid premise: “Telling people things” means they will respond rationally and so come to see things differently, and thereby behave differently.
  • Invalid premise: My organisation works just fine.
  • Invalid premise: Meaningful dialogue is an unnecessary luxury.
  • Invalid premise: Investment in e.g. organisation-wide dialogue skills has a poor or uncertain ROI and is not worthwhile.
  • Invalid premise: Knowledge (grey muscle) work is no different than physical (pink muscle) work.
  • Invalid premise: Extrinsic motivation raises knowledge-workers’ productivity.
  • Invalid premise: Truths are absolute.
  • Invalid premise: Context doesn’t matter.
  • Invalid premise: A comprehensive plan is a necessary prerequisite to any endeavour.

And here’s some contributions from the community:

  • invalid premise: Software development is “engineering”, so it’s not knowledge work.
  • Invalid Premise: Conforming to a standard is all that is required (to produce good work).
  • Invalid Premise: Regular reports tell people all they need to know.
  • Invalid Premise: “Projects” are the one and only way to organise and control work.
  • Invalid premise: Positive feedback – let alone real compliments – are a distraction and will render people complacent.
  • Invalid premise: Highlighting failures will help people improve.
  • Invalid premise: Appearing reluctant to engage in a certain activity is a sign of weakness.
  • (See also the suggestions in the comments section, below).

Have you any invalid premises you feel might be worth adding to this list?

– Bob

Nonviolent Inspiration

My thanks go to Charlie Badenhop at Seishindo.org for an article containing  the following quote:

Do you find yourself avoiding change?

”Change has a considerable psychological effect on the human mind.
To the fearful it is threatening because it means things might get worse.
To the hopeful it is encouraging because things might get better.
To the confident it is inspiring because a challenge exists to make things better.”

~ King Whitney Jr.

So, if our organisations use fear (along with obligation, guilt and shame) in attempts to meet their needs, then the “fearful” will only feel more threatened by the prospect of a bleaker future. How likely is that to bring about positive change – change for the better?

Conversely, if our organisations encourage hopefulness and confidence, then how likely is it that folks will feel encouraged and inspired by the possibilities of a brighter future?

– Bob

Further Reading

The Bene Gesserit Litany Against Fear – Wikipedia
Learning to Communicate Without Fear ~ Matthew Trotter
The Five Dysfunctions of a Team ~ Patrick Lencioni

Ambitions

Not in the sense of being ambitious, but in the sense of having some things in mind that I’d like to see come to pass. You might call that an agenda. Or some needs which, upon being met, might make my life more wonderful…

Whatever you choose to call it, here’s my list:

  • An implementation of FlowChain. I’ve had this model rattling round inside my brain for years now. I see little prospect of someone else taking the necessary leap of faith and implementing it – although the Reaktor folks seem to have evolved something similar, independently –  so it’s down to me.
  • An illustration of just how much like product development is software development. And an illustration of the value – and relevance – of applying decades of well-evolved product development practices to the betterment of software development and a business.
  • A systems thinking approach to a) product development and b) (more ambitious) running a business. I refer to this as “Prod•gnosis“.
  • Learning how practical all the above ideas really are, in the crucible of real life. And how much – and in what regards – they need modifying when they come into contact with the “enemy’s main strength”.

“No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength.”

~ Helmut von Moltke

This is my agenda.

As I explained recently in my post “Introducing Rightshifting“, I have no desire to foist these things upon people. But (in the context of my new job) I HAVE been asked to bring my experience and insights to bear. And to “innovate”. The above list seems to be a start, at least.

And just in case you’re wondering about my motivation, it’s not all selfish. I’ve made no secret over the years about what drives my work: to see an end to the egregious waste of human potential happening in software organisations everywhere, today. I believe the above ideas, implemented, will contribute significantly to this aim.

If someone asked me what needs of theirs their participation might serve, I’d offer the following list of possibilities:

  • The opportunity to learn lots of new things.
  • A chance to master the art of software development (esteem).
  • Making a difference. Advancing the art, illuminating the possible, and inspiring others.
  • The prospect of much fellowship, positive stress, self-actualisation (cf Maslow) and  fun!

Am I an idealist? A dreamer? You may choose to make that judgement. Although such a choice (i.e. to judge) would make me feel sad.

“Observing without evaluating is the highest form of human intelligence.”

~ Jiddu Krishnamurti

So who’d like to join me on this journey? How do you feel about my agenda? What’s your agenda? What needs can we meet, together? What might make your life more wonderful? And how might we help each other?

– Bob

Further Reading

Prod•gnosis in a Nutshell – blog post

%d bloggers like this: