Archive

Lemons

Your Consultant’s Dirty Secret: They Decided What You Need Before You Said a Word

Every business owner has been there. You hire a consultant or coach or expert to solve a specific problem, clearly articulate your needs, and then watch in bewilderment as they deliver something entirely different. Despite their impressive credentials and hefty fees, they’ve somehow missed the mark completely. The root cause isn’t incompetence—it’s something far more insidious: the inability to truly listen. And here’s the kicker—most consultants don’t even realise they’re doing it.

A Different Kind of Expert Problem

This isn’t the well-known “curse of knowledge”—where experts struggle to communicate because they can’t remember what it’s like not to know something. That problem makes experts bad teachers due to poor information transfer.

What we’re dealing with here is almost the opposite: consultants who think they understand the client’s situation better than the client does, leading them to ignore or selectively reinterpret what they’re actually being told. This makes them bad problem-solvers due to poor information reception. The troubling reality is that most of these consultants genuinely believe they’re listening intently. Chris Argyris touched on this dynamic in his work on organisational learning, noting how smart people often struggle when their expertise becomes a barrier to genuine inquiry—often without recognising the barrier exists.

I’ve personally had this experience multiple times with e.g. various Agile coaches and consultants.

The Solution-First Mindset

Many consultants arrive with their answers already prepared, rendering the discovery phase a mere formality—though they’d be shocked to hear it described this way. They’ve developed a methodology, framework, or system that – allegedly – worked brilliantly for previous clients, and they become convinced it’s the universal solution. This leads to what I call “solution-first consulting”—where the expert’s job becomes selling the client on why their predetermined approach is exactly what they need.

Here’s the uncomfortable truth: for most consultants, their primary goal is to sell you something, not to fix your problems. That “something” might be a methodology, a software implementation, a training programme, or an extended engagement. The more complex and expensive, the better. Your actual problem is secondary to their sales objective. I’ve done this myself often, in an earlier CMMI life, for example.

When a client says, “We need help streamlining our inventory management,” the consultant hears, “We need a complete digital transformation.” When a small business owner explains, “Our team struggles with communication during busy periods,” the expert translates this as, “They need enterprise-level project management software.”

The consultant isn’t consciously twisting the client’s words. In their mind, they’re demonstrating insight by understanding what the client “really” needs. They genuinely believe they’re providing value by seeing beyond the surface problem to the deeper issue—which coincidentally happens to align perfectly with what they’re selling. The client’s unique context, constraints, culture, and resources become secondary considerations to be worked around rather than primary factors that should shape the solution.

The Selective Hearing Problem

Effective listening in consulting requires more than just hearing words. It demands understanding the subtext, the constraints that clients might not even articulate, and the political dynamics at play. But consultants with solution bias engage in selective hearing—they tune in to information that supports their preferred approach and tune out details that complicate it. The scary part? They’re completely unaware this filtering is happening.

They hear “budget constraints” as an objection to overcome rather than a design parameter. They interpret “our team is already overwhelmed” as resistance to change rather than a critical factor that constrains implementation timing and complexity. They treat “we tried something similar before and it didn’t work” as ancient history rather than valuable data about what conditions led to failure.

This selective hearing isn’t malicious—it’s cognitive and largely unconscious. When you have a hammer you’re proud of, everything starts to sound like a nail, even when the client is clearly describing a screw. The consultant walks away from client meetings convinced they’ve gathered comprehensive requirements, oblivious to the crucial information they’ve mentally discarded.

The Expertise Trap

The more successful a consultant becomes with their particular approach, the more confident they grow that they can diagnose problems quickly and accurately. This confidence becomes dangerous when it places the solution cart before the discovery horse. They begin to mistake pattern recognition for deep understanding—and they’re genuinely convinced their quick assessment is thorough analysis. And analysis is such a bore, anyways, ain’t it?

A consultant who has successfully implemented lean manufacturing processes at a dozen companies might assume they understand the thirteenth company’s needs after a brief plant tour. But perhaps this company’s real issue isn’t operational efficiency—maybe it’s inconsistent supplier quality, or seasonal demand fluctuations, or a skilled labour shortage. The lean expert, however, is already mentally mapping out value streams and identifying waste, completely convinced they’re conducting proper discovery.

The consultant isn’t deliberately cutting corners. They sincerely believe their experience gives them superior insight into what the client needs. They see themselves as efficient and perceptive, not hasty and arrogantly presumptuous..

The Real-World Disconnect

The most frustrating aspect of consultants who don’t listen is their tendency to propose solutions that look impressive on paper but fall apart in practice. They recommend systems that require more training than the team has time for, processes that don’t account for seasonal fluctuations in the business, or strategies that ignore the company’s risk tolerance.

These consultants often mistake complexity for sophistication—or more cynically, recognise that complexity sells better than simplicity. They present elaborate frameworks with multiple phases, detailed matrices, and extensive documentation. Meanwhile, what the client actually needed was a simple process adjustment that could be implemented immediately with existing resources. But simple solutions don’t generate large consulting fees.

A manufacturing client might need help reducing setup times on a particular machine, but the consultant delivers a comprehensive lean transformation roadmap spanning 18 months. A retail client asks for help with inventory turnover, but gets a complete supply chain optimisation strategy requiring new software and vendor relationships. In both cases, the consultant has found a way to transform a specific, limited problem into a major project that justifies excruciating fees.

What’s particularly maddening is that the consultant genuinely believes they’re adding tremendous value. They’re not cynically overselling, oh no sir!—they’re convinced that their comprehensive approach is exactly what the client needs, even when the client explicitly said otherwise. The sales incentive and the unconscious bias reinforce each other perfectly.

The Cost of Poor Listening

When consultants fail to listen, the consequences extend far beyond wasted money. The original problem remains unsolved whilst resources are diverted towards solving problems the client didn’t actually have. Trust erodes not just with the specific consultant, but with the entire concept of outside expertise.

Internal stakeholders who were initially supportive of bringing in help become sceptical of all consultants. Teams become resistant to future change initiatives, having experienced the frustration of being told their view of day-to-day reality was wrong. Companies develop “consultant fatigue”—a cynical expectation that outside experts will over-promise and under-deliver.

Perhaps most damaging, organisations begin to lose confidence in their own ability to articulate their needs. When experts consistently tell them they don’t understand their own problems, they start to doubt their internal knowledge and instincts.

Meanwhile, the consultant often remains blissfully unaware of this damage. When implementations fail or results disappoint, they attribute it to “client resistance to change” or “poor execution” rather than questioning whether they solved the right problem in the first place.

What Good Listening Actually Looks Like

Effective consultants approach each engagement with genuine curiosity rather than predetermined answers—and they’re conscious about maintaining this mindset. They spend significantly more time in early meetings asking questions than presenting credentials or case studies. They seek to understand not just what the client thinks they need, but why they think they need it, what they’ve already tried, and what success would actually look like in their specific context.

They pay careful attention to resource constraints, timeline pressures, organisational culture, and political dynamics. They understand that the theoretically perfect solution that can’t be implemented is worthless, whilst an imperfect solution that gets adopted and creates measurable improvement is invaluable.

These consultants also know when to push back—not because they have a better mousetrap to sell, but because they’ve listened carefully enough to spot genuine blind spots or unrealistic expectations. Their challenges come from understanding, not ego. They might say, “Based on what you’ve told me about your team’s bandwidth, I think you’re trying to accomplish too much too quickly,” rather than, “Here’s why you need my comprehensive approach.”

Most importantly, these consultants regularly check their own assumptions. They actively look for evidence that contradicts their initial assessment and deliberately seek out perspectives that challenge their preferred solutions.

AND IF THEY FIND THEY CAN’T HELP with the actual problem, THEY BOW OUT GRACEFULLY.

Protecting Yourself as a Client

For clients hiring consultants, the reality is that you need to protect yourself from an industry where sales incentives always trump problem-solving. Here’s how to maintain control:

Start with a detailed written brief: Before engaging any consultant, develop a comprehensive written brief that clearly articulates your specific problem, constraints, desired outcomes, and what success looks like. Make this brief part of the contract. If they can’t deliver to your written specifications, make it clear they won’t get paid a penny. This isn’t harsh—it’s basic accountability.

Insist on discovery: Require consultants to run discovery at least in parallel with implementing solutions.

Demand proof of listening: Ask consultants to summarise back to you in writing and verbally what they’ve heard, including the constraints and complications you’ve mentioned. An effective consultant will be able to articulate not just your stated problem, but the underlying factors that make your situation unique.

Build in checkpoint reviews: Structure the engagement with regular review points where you assess whether the consultant is addressing your actual brief or has wandered off into their standard approach. Make it clear that you reserve the right to redirect or terminate without payment if they’re not solving the problem you’ve hired them to solve.

Get a money-back guarantee of complete satisfaction, in writing, up front.

Question their assumptions: When consultants present their recommendations, ask them to explain how they’ve accounted for the specific constraints and requirements you outlined. If they can’t clearly connect their solution to your brief, they haven’t been listening.

Set payment milestones tied to deliverables: Don’t pay large sums upfront. Structure payments around specific deliverables that directly address your written brief. This creates real consequences for consultants who drift into solution-first mode.

Request references for similar situations: Ask for references from clients who had problems similar to yours—not just satisfied clients in general. Speak to these references about whether the consultant delivered what was actually needed or imposed their standard solution.

Remember the sales imperative: Never forget that most consultants make money by selling you their solution, not by solving your problem. The bigger and more complex their recommendation, the more they earn. A consultant who suggests a simple, low-cost fix is either exceptional or hasn’t figured out how to monetise your situation yet. Be especially wary if their solution happens to require exactly the services they specialise in—what are the odds?

Ask the crucial question: Before engaging any consultant, ask them directly: “Can you give me an example of when you’ve told a potential client that they would not benefit from your services?” If they can’t provide a genuine example, you’re dealing with someone whose primary function is sales, not problem-solving.

Test their flexibility: During initial conversations, present a constraint or requirement that would make their standard approach difficult. Watch how they respond. Do they immediately start explaining why you should change your constraint, or do they begin adapting their approach to work within it?

Beware the comprehensive audit: Be deeply suspicious of consultants who insist on conducting a “comprehensive organisational assessment” before addressing your specific problem. This is often a way to expand the scope and find additional problems to solve.Most times you really do just need help with that one thing you asked about.

Get multiple perspectives: Don’t rely on a single consultant’s diagnosis. If the problem is significant enough to warrant outside help, it’s significant enough to warrant multiple opinions. You’ll quickly spot consultants who are genuinely listening versus those pushing their standard solutions.

The Listening Advantage

In a world full of solution-first consultants, you might be forgiven for thinking that the ones who listen first have an enormous competitive advantage. They solve the right problems, create solutions that actually get implemented, and build long-term relationships based on trust rather than just expertise. Most clients are not this savvy.

The most successful consulting engagements happen when deep expertise meets genuine curiosity, when knowledge serves understanding rather than replacing it. The client’s voice should be the loudest one in the room, even when—or especially when—the consultant is the supposed expert.

The goal isn’t to eliminate expertise from consulting—it’s to ensure that expertise enhances rather than replaces the fundamental skill of listening to what the client actually needs. But first, consultants must acknowledge that their expertise might be getting in the way of their hearing—even when they’re convinced they’re listening perfectly well.

Further Reading

Argyris, C. (1991). Teaching smart people how to learn. Harvard Business Review, 69(3), 99-109.

Block, P. (2011). Flawless consulting: A guide to getting your expertise used (3rd ed.). Pfeiffer.

Kahneman, D. (2011). Thinking, fast and slow. Farrar, Straus and Giroux.

Maister, D. H., Green, C. H., & Galford, R. M. (2000). The trusted advisor. Free Press.

Schein, E. H. (1999). Process consultation revisited: Building the helping relationship. Addison-Wesley.

Schein, E. H., & Schein, P. (2021). Humble inquiry: The gentle art of asking instead of telling (2nd ed.). Berrett-Koehler Publishers.

Weiss, A. (2019). Getting started in consulting (4th ed.). Wiley.

There is helpful and useful content out there. But finding it amongst all the dross is a massive challenge.

I despair of the boatloads of naive advice, misinformation, and just pure tosh that so-called “Agile” people spout on a daily basis. (Not limited to just “Agile” people, of course.)

Caveat lector!

And just in case you’d like a sanity check on anything suspect or dubious, I’m always happy to support your natural scepticism. Just get in touch for non-partisan help.

More Employable

Ineffectiveness is the norm (in particular in the software and collaborative knowledge work fields).

Therefore the less effective someone appears to e.g. hiring managers, the more employable they are. The ineffective fit right in, don’t challenge norms or ruffle feathers, and appear a competent “good hire” even as they join in with sustaining and compounding the organisation’s prevailing ineffectiveness.

Simple Truth

This simple truth explains why some many organisations are so poor at developing tech products, and software more generally. They unwittingly hire “good fits’ i.e. the profoundly ineffective. And never realise the productivity improvments, etc., that they’re leaving on the table.

The (modified) Marshall Model chart (below) illustrates the situation:

How might we help these organisations appreciate their dire situation? Is that even possible?

– Bob

Further Reading

Peters, T.J. and Waterman, R.H. (1982). In Search of Excellence: Lessons from America’s Best-run Companies.  Profile Books.

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub).

In case you missed it:

Agile Development Doesn’t Work

Agilists: They Just Want Your Money

And they’re not concerned with providing you with value for your money. If they WERE so concerned, they wouldn’t be Agilists. After twenty years of dicking about with Agile, we can safely say that Agile per se provides ZERO value. 

Oh, some folks and teams that say they’re Agile may achieve results greater than the norm (although the norm is itself so woefully inadequate that claiming results greater than the norm is saying very little). The Rightshifting chart (below) illustrates this point.

But the fact is, that the success of folks and teams that achieve and deliver up to and beyond expectations is not down to Agile. It’s down to other factors that people often mistakenly attribute to Agile.

Things like:

  • thriving and joyful humane relationships
  • attending to folks’ needs
  • treating they way the work works – across the whole organisation – as a system
  • collective assumptions and beliefs – across the whole organisation
  • and yes, even, sometimes, to effective engineering practices. 

Agilists will claim that they are doing these things, because they’re “core agile themes”. And yet, they’re paying lip-service to these themes, not actually doing them. 

So, if you need predictable, on-time deliveries of solutions to support your business objectives, don’t be taken in by all the Agile bollocks. It’s all snake oil. Place your money wisely, find people who really know how to provide value (hint: not “Agilists”) – and caveat emptor!

– Bob

Further Reading

The Complete Rook ~ Two Ronnies sketch

Agile Competency Is A Crock

LearBookOfNonsense

Part 1 – The Lede

The Agile Manifesto set out to make developers’ (and others’) live richer, saner and more fulfilling.

A true irony of the legacy of that Manifesto is that finding a fulfilling job or role “in Agile” is nowadays next to impossible.

Competency is not something valued by hirers and their gatekeepers. Being a “safe hire” is all.

Part 2 – The Background Story

My dear friend, the late Grant Rule, had many compelling stories to tell.

One of these concerned a large insurance company in the home counties. Let’s call them InsCo. For some reason, the powers that be became interested in the reasons why they were not doing as well as they thought they should be, business-wise.

Some number of investigations were commissioned. One concerned the type of people they were hiring, versus the type of people needed for business success.

To cut a long story short, it became revealed to them that not only were they hiring people with little to contribute in the way of the organisation’s business goals, they were actually hiring people whose general style actively undermined those goals.

In other words, their hiring practices were expressly filtering out those people best suited to make a positive contribution inside the business. And this had been going on for years, if not decades.

I always found the story fascinating, not least for its compelling ring of truth.

In todays’s business world, I see many of the organisation I visit or work with making exactly the same error.

Organisations whose hiring practices filter OUT exactly those candidates who would best contribute to the espoused goals of the organisation.

Guided by the heuristic of POSIWID, I assume that organisations – or more exactly the core group within an organisation – are not much interested in the organisation’s espoused goals. Deming said as much fifty years ago, with his First Theorem:

“Nobody gives a hoot about profit”

~ W Edwards Deming

I find this particularly noticeable in hiring for so-calle Agile positions and roles. […]

Now, I’m not about to criticise folks – senior executives and middle managers in this case – for acting in their own individual and collective (core group) best interests.

It’s what humans do – acting to get needs met.

I’m just inviting you, like the executives at InsCo did, to take a look at the consequences of your current hiring and staffing policies and processes.

And consider how those staffing policies and processes play against the things that matter to you.

Oh, and maybe consider what those things that matter to you are, too.

Part 3 – The Dilemma

For me, struggling as I am to find gainful and meaningful employment, the questions aired in part 2 raise an interesting question for all of us in the Agile field:

Do we concentrate on appearing competent, and on our abilities to help the organisation achieve its espoused goals? Or do we focus on getting a well-paid job – which demands a very different strategy and “personal brand image”?

The former strategy suggests we list our experience, results and contributions to the success of the organisations we have worked with. That we take hiring organisations’ espoused goals at face value and play to those declared goals.

The latter strategy suggests we present ourselves in terms that appeal to the needs we imagine the hirers – and their gatekeepers – have.

Needs rarely articulated and only determinable through observation of these folks’ actions. Needs which in most cases means portraying ourselves as conventional, conservative, and status-quo loving. As “safe hires”.

I’ve discovered – unsurprisingly, to me – that I just CAN’T bring myself to do the latter.

I’m NOT a safe hire, not do I ever wish to be. My value proposition is other.

Outwith the emotional consequences of pretending to be something I’m not, and setting myself up at work to live a life that’s a bald-faced lie, I just don’t want to find myself in any more jobs or roles that, in essence, are just another stupid punt.

How about you?

– Bob

A Foolish Consistency

Many will be familiar with the epithet:

“A foolish consistency is the hobgoblin of little minds.”

~ Ralph Waldo Emerson

Fewer will know that it comes from Emerson’s essay, “Self-Reliance“, first published in 1841. Or that the text continues:

“…adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do. He may as well concern himself with his shadow on the wall. Speak what you think now in hard words, and tomorrow speak what tomorrow thinks in hard words again, though it contradict everything you said today. — ‘Ah, so you shall be sure to be misunderstood.’ — Is it so bad, then, to be misunderstood? Pythagoras was misunderstood, and Socrates, and Jesus, and Luther, and Copernicus, and Galileo, and Newton, and every pure and wise spirit that ever took flesh. To be great is to be misunderstood.”.

In the essay, Emerson is advocating the advantages of thinking for oneself, rather than meekly accepting the ideas of others.

Many other notable figures have railed against the foolishness of consistency. In such august company, i think we can pass on further such railings.

I’d like instead to raise and rail against a related foolishness:

“A foolish craving for certainty is the hobgoblin of the fearful, who when obtaining become the tearful.”

By which I mean those who rush to secure certainty in their world, should they achieve their wish, often end up lamenting the outcome.

“Be careful what you wish for” is another apt proverb that comes to mind.

Recent (neuro) scientific research has illuminated the human brain’s innate hunger for certainty:

“A sense of uncertainty about the future generates a strong threat or ‘alert’ response in your limbic system. Your brain detects something is wrong, and your ability to focus on other issues diminishes. Your brain doesn’t like uncertainty – it’s like a type of pain, something to be avoided. Certainty on the other hand feels rewarding, and we tend to steer toward it, even when it might be better for us to remain uncertain.”

So, just as Emerson noted our “foolish” hunger for consistency, neuroscience notes our “foolish” hunger for certainty.

A Topical Example

We might be forgiven for being surprised that a “progressive software startup” which, presumably, understand the perils of trying to tie down every little detail of requirements before embarking on the development of a product, should fail to grasp the perils of attempting to tie down every little detail of a job specification before embarking on recruiting for that position.

It’s like, the more important the position, the more certainty the hirers seek to assuage their hungry brains’ demand for certainty. Blind to the perilous implications.

Just as with Big Analysis Up Front for software development, BAUF for recruiting can lead to some unfortunate consequences:

  • Exclusion of the best candidates
  • Delays in finding even fairly-suitable candidates
  • Assumption that the eventual new hire is actually fit for the job
  • inclination to pigeon-hole the new hire, thereby demotivating him or her over time.
  • A job (position, role) not well-suited to the actual – as opposed to imagined – needs of the hiring organisation
  • De-emphasis on adaptability and flexibility as desirable new hire characteristics
  • Increased likelihood of hiring a narrow specialist (speciation, decrease in memetic diversity)
  • Unreasonable (stress-inducing) expectations of the new hire (cf Deming’s 95/5)
  • Lost opportunities for building mutual trust
  • Demotivation of the recruiters

Just as the world of software development has adapted to the brain’s cravings by e.g. adopting and evolving agile development principles, a more effective approach to recruitment might be to adapt, again. I’m thinking simple story cards, as placeholders for dialogue; I’m thinking making things visible; I’m thinking a focus on value; I’m thinking tests. Sounds familiar?

I’ve written on a similar theme previously, with the post Make Bad Hires!

This post has been brought to you by Lemons, and the wish to make lemonade.

– Bob

Further Reading

A Hunger for Certainty ~ Dr. David Rock
Thinking, Fast and Slow ~ Daniel Kahneman

Make Bad Hires!

Conventional wisdom, oft repeated on the intarwebs, cautions us to take great care when hiring people. Some folks go to the trouble of quantifying the costs of just one bad hire. But what about the costs of such caution? Here’s a few (sincere) arguments in favour of making bad hires:

  • However much of a misfit someone may seem at the outset, most people have the ability to learn, grow and develop. Recognising this can send a warm, reassuring and respectful message to everyone in the organisation – including the new hire.
  • Sticking with a new hire – even when recognising that the hire was “questionable” – can earn much loyalty and commitment from the person in question.
  • Finding bad hires is a lot quicker and a lot simpler than finding good hires.
  • Who’s to say that someone that looks like a bad hire will in fact turn out to be such? Kahneman cautions against the cognitive biases that makes us think we can predict people’s performance in advance. (This also reminds me of the Zen story “Farmer’s Luck”).
  • If we accept making bad hires as policy, our organisation can gear up for it and streamline the procedures for taking people on and letting people go. Much like the agile policy of “deliver early, deliver often, get feedback.” (See also: Zappos). The increased frequency can help us learn faster.
  • The stigma associated with making ‘bad hires’ decreases or disappears, reducing the delays inherent in people (well, managers, really) avoiding taking “risky” decisions.
  • People other than managers can be “entrusted” with making hiring decisions.
  • If you subscribe to the idea of “Deming’s 95%” – that 95% or the performance of any employee is down to the system (the way the work works), not to their own innate skills, experience or talent, then any gap between “good” and “bad” hires will be minimal (5% of overall performance) in any case.
  • Seemingly “bad hires” will bring diverse perspectives into the organisation, perhaps much more so than “good hires” might.

Note: I would advise retaining one “good hiring” filter: the “No assholes” rule (including filtering-out of folks with sociopathic and/or psychopathic tendencies).

Can you think of any more good reasons for making bad hires?

– Bob

Further Reading

Thinking, Fast and Slow ~ Daniel Kahneman
7 Reasons Why Not Making Mistakes Is The Biggest Mistake ~ Blog post from PurposeFairy
Everyone sucks at Interviewing ~ Blog Post from Jason Freedman
“Why Good People Can’t Get Jobs” ~ Online article by Dr. Peter Cappelli
“Bad Hires Have Cost Zappos Over $100 Million” ~ Tony Hsieh
What’s Wrong with Job Interviews, and How to Fix Them” ~ Adam Grant

Mea Culpa

Marcin (@mfloryan) asked me a while ago if I could ‘balance’ (or complement) my posts about Lemon Agile Consultants and the problems of having managers. He suggested another post exploring how some developers seem unwilling to adopt or engage with Agile development methods, or appear disinterested in the whole idea of improvement – either of themselves or the working practices in which they participate.

The Peg

I’ve since been struggling to find a ‘peg’ upon which to hang this idea, and thus, hopefully, make it interesting and relevant. So here it is: mea culpa, mea maxima culpa. My mistake – it’s all my fault.

Assumptions, Assumptions

It seems to me that implicit in the general question of “why do some developers seem uninterested in Agile – or the wider issues of improvement” lies the assumption that anyone in their right mind should be so interested.

Most of the folks that I know, talk with regularly, identify with are so interested.

Thus a lack of interest seems an aberration, a deviation from the norm. I seem to have succumbed to the fundamental attribution error – attributing the behaviour of others (the disinterested developers) to dispositional factors. Factors such as; they can’t be bothered, they’re unimaginative, they have poor a sense of social responsibility, they lack a sense of teamsmanship, and so on.

Are We Learning Yet?

How about we learn from the fundamental attribution error and admit the possibility of situational factors playing the key role? I’m not trying to deny the widely-reported observation that some developers do behave as if they have little interest in raising their personal skills, or the capabilities of their group, team or organisation. But how about considering why this should appear so?

Awareness

Number one on my list of possible reasons why, is that no one ever told them that it’s even possible to spend time on, invest effort in, self-improvement and/or group improvement. (The A.R.C. coaching mnemonic reminds us that Awareness is at the root of commitment to e.g. action). I mean, it’s not like this possibility is taught in schools or Universities, is it? The capacity for “divergent thinking” is actively degraded by our educational systems, according to @SirKenRobinson. Nor is the possibility for intentional improvement taught or experienced in the workplace, either, by and large.

Absent any such information or awareness, is it reasonable to expect folks to have some kind of natural, inborn predisposition towards self-improvement or group improvement? In the general case, I think not. (I’d be delighted if anyone can share any research or findings on the presence or absence of such a predisposition).

Other Factors

And then there’s a whole bunch of other situational factors which can come into play in any given set of circumstances. Can you think of some that might apply in your context, in your team or organisation? (If yes, might you like to share them, here?) .

So yes, I’ve fallen foul of an unwitting assumption about these developers’ dispositions. But maybe, just maybe you could find it in your heart to pray for me? And maybe have a chat with them about their perspectives – on the issues of both self-improvement, and improvement more generally?

Thanks. :}

– Bob

Further Reading

The Three Ingredients of Commitment (Agile Studio Blog post)
Coaching For Performance ~ Sir John Whitmore

Pearls Before Swine

Good Home Cooking

My maternal Grandmother was a wonderful cook. And when she and my mother were running the family business – a seaside guest house – when I was a wee lad, she used to cook all the meals for the guests (and the family and staff too). She really cared about her cooking, selecting quality ingredients from local fishermen, farmers and grocers, and lovingly crafting the best meals she could – within the budget allowed by the business.

Most of the guests loved the food, many paying compliments and returning year after year. Locals would also dine-in regularly. But there were always some, a very few, for whom the food did not meet their expectations, or more likely, suit their palates. In her consummate, inimitable style, when faced with a particularly unreasonable complaint, she would say “…pearls before swine”. Meaning, she knew her food was excellent, and if some folks didn’t like it, then they probably didn’t know how to appreciate it.

“Give not that which is holy unto the dogs, neither cast ye your pearls before swine, lest they trample them under their feet, and turn again and rend you.”

Matthew 7:6

Software Pearls

Do you believe that great knowledge-work will be recognised by the folks paying for it? Some teams may be lucky and find a good customer that appreciates what they’ve achieved, the quality they’re delivered, the efforts they have made – many times, above and beyond the call of duty (or the terms of the contract). But very often, customers receive excellently-crafted products with absolutely no clue as to the quality of the things they’ve just received. Unlike a great plate of food, they have no means to evaluate what they’ve just been served. The converse is also all-too-frequently true; oftentimes customers get delivered a real dog of a product, and have no clue that they’ve just been completely rooked.

Thankless

Of course, some customers don’t feel that suppliers should be especially thanked, recognised or otherwise noted for simply delivering what was asked-for, regardless of any unforeseen difficulties or outstanding innovations that may have occurred along the way. I would not regard these as desirable customers.

In Japan, for example, in the Keiretsu – the supplier networks of the major manufacturers – suppliers are appreciated, helped and long-term relationships fostered, with the understanding the the supplier-customer relationship thrives with long-term commitment and mutual effort.

Keiretsu member companies own small portions of the shares in each other’s companies…; this system helps insulate each company from stock market fluctuations and takeover attempts, thus enabling long-term planning in innovative projects. It is a key element of the automotive industry in Japan.

Few indeed are the Western companies that see value in this kind of arrangement, and fewer still the companies that act to cement long-term relationships with software suppliers.

Market for Lemons

What this means in practice is that the market for software services (e.g. custom software development) is effectively a Market for Lemons.

And what that means, is that software suppliers will rarely receive a fair price for their labours. Lacking appreciation of quality, buyers will automatically assume that whatever they are buying is a Lemon, and discount the price accordingly.

This is as much true for software supplied in-house by e.g. the IT department to the rest of the organisation as it is for software supplied by external commercial software development services (e.g. software houses)

Finally, the Point

So why am I writing this post? For three main reasons, really:

  • To invite those organisations buying software services, either from external third parties or internal e.g. IT departments, to focus some effort on better understanding good service / quality software from the dross. A Market for Lemons affords benefits to no one.
  • To remind suppliers to choose their customers carefully, and where that is infeasible, to pay some attention to managing customers’ expectations and educating them as to the quality aspects of what they’re receiving.
  • [TBD – Can you guess?]

– Bob

How to Spot a Lemon Consultant

A Lorra, Lorra Lemons

In my time I have seen a lot of lemons. And I have seen a lot of companies hire or engage with lemons – almost always unwittingly. Actually, I can’t believe how ineffective some of these folks and suppliers have been. And let’s face it, there’s a lorra, lorra lemons out there.

Following on from my recent “Better Customers” post, I thought it might offer some value to share some tips on how to spot these lemons.

The Lemon Consultant

Description

The Lemon Consultant is most often a pinstripe- or blue-suited individual – through its colouration and demeanour attempting to appear native amongst the local dominant fauna.

The Lemon Consultant strides purposefully from place to place, exuding faux-charm and confidence in an effort to attract its prey. Juveniles are similar to adults except the suits are cheaper and the veneer of confidence thinner, with a tinge of bluster.

Lemon Consultants prefer to congregate in flocks, for security and mutual support, although solitary individuals are also sometimes seen in the wild.

Range and Habitat

Lemon Consultants prefer surrounding of glass, steel and laminate, and favour smaller, private spaces over the open savannah. They are common in urban and suburban areas especially where large budgets are predominant.

Throughout the summer Lemon Consultants can be found in most of the major conurbations across the Northern Hemisphere. In North America: from southern Canada, down through the United States to the Mexican border. There are small pockets of Lemon Consultants as far west as Washington State. In Europe: preferring temperate climes, they are fewer in Scandinavia and Mediterranean  countries, with a significant population in the British Isles.

They are partially migratory with some migrating and others not. Some Lemon Consultants migrate quarterly, but always preferring to stay in one place for as long as their food source remains plentiful.

Nesting Habits

Like Mourning Doves, Lemon Consultants often take over other’s nests, at least temporarily. Failing that, and like the Black-headed Grosbeak, Lemon Consultants are known to steal parts and pieces of others’ nests to construct their own. In settled (non-migratory) situations, Lemon Consultant prefer a burrow or other cosy corner where they can keep out of sight whilst preening.

Feeding and Watering

Whilst Lemon Consultants are omnivorous, they prefer hard cash up front. When such pickings are scarce, they often settle for an hourly rate. They have been known to travel incredible distances from their breeding grounds to their preferred feeding sites. Avaricious and self-serving, the Lemon Consultant concerns itself predominantly with feeding.

Lemon Consultants do a wonderful job of regurgitating ideas from other sources, although generally poisoning the seeds and causing the resulting crop of ideas to be stunted and malodorous.

Song

The Lemon Consultant is a very vocal bird. It often has a strident, even whining note, although some few have a lilting, musical overtone. They make a number of different calls including its distinctive “deliver-cost-urgency”. It growls when it’s irritated, and chatters when it’s not. The Lemon Consultants has whistles and gurgling sounds in its repertoire as well.

Behaviour

The Lemon Consultant is often both aggressive and territorial. Group of Lemon Consultants will attack intruders and other Consultants that move into their territory, although they take great pains to avoid overt conflicts, preferring stealth and subversion to direct assaults.

If the weather is mild and the food plentiful, Lemon Consultants may winter over in their breeding grounds. But when they do migrate, they form loose flocks of around 3 to 12 traveling only during hours of darkness.

Sub-species

The lesser-known Lemon Agile Consultant can be distinguished from its more common brethren by its naivety, good-naturedness, and a fondness for making grandiose claims about the benefits of Agile software development whilst making no mention of the risks, costs, or the scale of changes required throughout adopting organisations.

The Lemon Agile Consultant is also very fond of Powerpoint presentations featuring cutesy child-like artwork and banal, empty platitudes; specious and tiresome “games”; often carries copious amounts of Lego; and repeats words like “fun”, “fairies” and “the power of stories” ad-nauseam.

Their song varies subtly from their common cousins, their most distinctive calls including “fun-clap-fun”, “more-value-less-waste” and “time-to-market”. Listen to the song of the Lemon Agile Consultant: Sound Bites: Lemon Agile Consultant, National Twat Service

Lemon Agile Consultants frequently borrow ideas from primary sources, but often out of context, and having grasped the wrong end of the stick. Their attribution of sources is rare to non-existant.

The Lemon Agile Consultant enjoys playing, and wants to play in your sandpit, with your money and your resources. Their gregarious nature means they love to rope-in as many of your people as possible, regardless of the distraction and disruption this causes. Outcomes rarely hold their interest for long, if at all.

Recognition

Recognising Lemon Agile Consultants amongst the general fauna is relatively simple. Ask direct questions like:

  • What’s most likely to happen when we roll agile out across the whole development group?
  • How will adopting Agile impact on other groups within the organisation?
  • What will we have to do to realise the promised benefits of Agile over the longer term (i.e. beyond 9-15 months)?
  • What are the key elements for ensuring our investment in Agile is sustainable and does not dissipate when e.g. early sponsors and champions leave the organisation?
  • How have Agile adoptions turned-out in other organisations? Well? Badly? What’s the typical success rate, longer-term? What are the likely pitfalls?
  • Is Agile suited here? Are there approaches other than Agile that can meet our needs as well or better?
Note: The nature of the answers are less important than having answers. The typical Lemon Agile Consultant will struggle, both with understanding the very questions, and in finding convincing answers.

Further Resources

Summary

Avoiding Lemon Consultants may seem like a difficult challenge, and for the uninitiated it can be. But with just a little awareness, a little patience to pass them by, and a few simple rules of thumb, it gets much easier.  And if life throws you one or more of these Lemon Consultants? Don’t bother even trying to made lemonade. Lemon squash, maybe.

– Bob