At least the execrable, and totally misinformed, recent McKinsey article “Yes, you can measure software developer productivity” has us all talking about “developer productivity”. Not that that’s a useful topic for discussion, btw – see “The Systemic Nature of Productivity”, below. Even talking about “development productivity” i.e., of the whole development department would have systems thinkers like Goldratt spinning in his grave.

The Systemic Nature of Productivity

Productivity doesn’t exist in a vacuum; it’s a manifestation of the system in which work occurs. This perspective aligns with W. Edwards Deming’s principle that 95% of the performance of an organisation is attributable to the system, and only 5% to the individual. McKinsey’s article, advocating for specific metrics to measure software developer productivity, overlooks this critical context, invalidating its recommendations from the outset.

Why McKinsey’s Metrics Miss the Mark

Quantitative Tunnel Vision

McKinsey’s emphasis on metrics ignores the complex web of factors that actually contribute to productivity. This narrow focus can lead to counterproductive behaviours.

The Dangers of Misalignment

Metrics should align with what truly matters in software development. By prioritising the wrong metrics, McKinsey’s approach risks incentivising behaviours that don’t necessarily add value to the project or align with organisational goals.

Predicated on Fallacies

McKinsey’s suggestions are riddled with fallacious assumptions, including:

• Benchmarking – long discredited.
• Contribution Analysis – focused on individuals. Music to the ears of traditional management but oh so wrong-headed.
• Talent – See, for example,  Demings 95/5 for the whole fallacious belief in “talent” as a concept.
• Measuring productivity (measure it, and productivity will go down).

The Real Measure: Needs Attended To and Needs Met

The Essence of Software Development

The core purpose of business – and thus of software development – is to meet stakeholders’ needs. Therefore, have the most relevant metrics centre on these factors: How many stakeholders’ needs have been identified? How many have been and are being attended-to? How many have been successfully met? These metrics encapsulate the real value generated by a development team – as an integrated part of the business as a whole. (See also: The Needsscape).

Beyond the Code

Evaluating how well needs are attended to and met requires a focused approach. It includes understanding stakeholders’ requirements, effective collaboration within and across teams and departments, and the delivery of functional, useful solutions. (Maybe not even software – see: #NoSoftware).

Deming’s 95/5 Principle: The Elephant in the Room

The System Sets the Stage

Ignoring the role of the system in productivity is like discussing climate change without mentioning the Sun. Deming’s 95/5 principle suggests that if you want to change productivity, you need to focus on improving the system, not measuring individuals, or even teams, within it.

The Limitations of Non-Systemic Metrics

Individual metrics are the 5% of the iceberg above the water; the system—the culture, processes, and tools that comprise the working environment—is the 95% below. To truly understand productivity, we need metrics that evaluate the system as a whole, not just the tip of the iceberg. And the impact of the work (needs met), not the inputs, outputs or even outcomes.

The Overlooked Contrast: Collaborative Knowledge Work vs Traditional Work

McKinsey’s article advocates for yet more Management Monstrosities, where the category error of seeing CKW – collaborative knowledge work – as indistinct from traditional models of work, persists.

The Nature of the Work

Traditional work often involves repetitive, clearly defined tasks that lend themselves to straightforward metrics and assessments. Think of manufacturing jobs, where the number of units produced per time period or per resources committed can be a direct measure of productivity. Collaborative knowledge work, prevalent in fields like software development, is fundamentally different. It involves complex problem-solving, creativity, and the generation of new ideas, often requiring deep collaboration among team members.

Metrics Fall Short

The metrics that work well for traditional jobs are ill-suited for collaborative knowledge work. In software development, such metrics can be misleading. The real value lies in innovation, problem-solving, and above all meeting stakeholders’ needs.

The Role of Team Dynamics

In traditional work settings, an individual often has a clear, isolated set of responsibilities. In contrast, collaborative knowledge work is highly interdependent. This complexity makes individual performance metrics not just inadequate but potentially damaging, as they can undermine the collaborative ethos needed for the team to succeed.

The Importance of Systemic Factors

The system in which work takes place plays a more significant role in collaborative knowledge work than in traditional roles. Factors like communication channels, decision-making processes, and company culture (shared assumptions and beliefs) can profoundly impact productivity. This aligns with Deming’s 95/5 principle, reinforcing the need for a systemic view of productivity.

Beyond Output: The Value of Intellectual Contributions

Collaborative knowledge work often results in intangible assets like intellectual property, improved ways of working, or enhanced team capabilities. These don’t lend themselves to simple metrics like ‘units produced’ but are critical for long-term success. Ignoring these factors, as traditional productivity metrics tend to do, gives an incomplete and potentially misleading picture of productivity.

A Paradigm Shift is Needed

The nature of collaborative knowledge work demands a different lens through which to evaluate productivity. A shift away from traditional metrics towards more needs-based measures is necessary to accurately capture productivity in modern work environments.

Quality and Productivity: Two Sides of the Same Coin

The Inextricable Link

Discussing productivity in isolation misses a crucial aspect of software development: quality. Quality doesn’t just co-exist with productivity; it fundamentally informs it. High-quality work means less rework, fewer bugs, and, ultimately, a quicker and more effective delivery-to-market approach.

Misguided Metrics Undermine Quality

When metrics focus solely on outputs they can inadvertently undermine quality. For example, rushing to complete tasks can lead to poor design choices, technical debt, and an increase in bugs, which will require more time to fix later on. This creates a false sense of productivity while compromising quality.

Quality as a Measure of User Needs Met

If we accept that the ultimate metric for productivity is “needs met,” then quality becomes a key component of that equation. Meeting a user’s needs doesn’t just mean delivering a feature quickly; it means delivering a feature that works reliably, is easy to use, and solves the user’s problem effectively. In other words, quality is a precondition for truly meeting needs.

A Systemic Approach to Quality and Productivity

Returning to Deming’s 95/5 principle, both quality and productivity are largely influenced by the system in which developers work. A system that prioritises quality will naturally lead to higher productivity, as fewer resources are wasted on fixing errors or making revisions. By the same token, systemic issues that hinder quality will have a deleterious effect on productivity.

Summary: A Call for Better Metrics

Metrics aren’t the problem; it’s the choice of metrics that McKinsey advocates that demands reconsideration. By focusing on “needs attended to” and “needs met,” and by acknowledging the vital role of the system, organisations can develop a more accurate, meaningful understanding of holistic productivity, and the role of software development therein.Let’s avoid the honey trap of measuring what’s easy to measure, rather than what matters.

Afterword

As with so much of McKinsey’s tripe, the headline contains a grain of truth – “Yes, you can measure software developer productivity”. But the nitty-gritty of the article is just so much toxic misinformation. Many managers will seize on it anyway. Caveat emptor!

In today’s fast-paced world, accountability and genuineness often play second fiddle to public image and PR maneuverings. The digital age, with its instant feedback mechanisms, has also ushered in an era where complaints are louder, more frequent, and far-reaching. In this atmosphere, a curious phenomenon has been on the rise: meeting complaints with “bollocks” – essentially, responses that seem plausible, peppered with promises for action which the complainee has no genuine intent of fulfilling. Let’s delve into this concerning trend.

Why “Bollocks”?

The term “bollocks” is colloquial British slang, originally referring to testicles but later evolving to mean “nonsense” or “rubbish.” In the context of complaints, it has come to encapsulate responses that are essentially ‘hot air’. These responses give the impression of sincere concern and promise to make amends but are merely a façade.

Why Do People or Organisations Resort to This?

1. Instant Damage Control: In the age of social media, complaints can go viral quickly. Giving an immediate response, even if it’s just bollocks, can provide a temporary shield against further negative publicity.
2. To Buy Time: Sometimes, organizations aren’t immediately sure how to deal with a particular complaint. Offering a seemingly meaningful response allows them to buy time while figuring out the next steps, or even waiting for the complaint to fade into obscurity.
3. Avoidance of Genuine Accountability: Genuine problem-solving can be time-consuming and expensive. In contrast, offering empty words costs nothing.

The Danger of Empty Promises

1. Erosion of Trust: When the public or customers realize that promises aren’t being kept, it erodes trust. Over time, this can lead to a significant loss in reputation and loyalty.
2. Potential for Escalation: Ignoring or deflecting genuine issues can lead to bigger problems down the line. What might have been a minor grievance can escalate into a major PR crisis if left unattended.
3. A Vicious Cycle: When bollocks become the norm, people and organizations may get caught in a cycle of defensiveness and avoidance. This makes genuine problem-solving even more challenging, as issues keep piling up.

Spotting and Countering Bollocks

1. Look for Specificity: Vague promises are a hallmark of bollocks. Genuine responses will usually offer specific solutions or a clear timeline for action.
2. Follow-Up: If you’ve lodged a complaint and received a response, always follow up. It’s a way of holding the complainee accountable.
3. Demand Transparency: More and more organizations are finding that transparency isn’t just good ethics – it’s good business. Support businesses and individuals who prioritize open communication and clear actions.

Conclusion

Ah, the age of bollocks – where surface-level pacification is often deemed more critical than genuine problem-solving. It seems we’ve traded genuine accountability for a masterclass in PR smoke and mirrors. In this digital age, many find it easier to offer a well-worded tweet than a well-thought-out solution. But hey, as long as the masses are momentarily appeased and the issue gets buried in tomorrow’s news cycle, that’s all that matters, right? Here’s a thought: perhaps, just perhaps, we’re becoming too adept at discerning the difference between the sincere and the insincere. Or maybe, we’re just becoming more comfortable with the theater of it all. Either way, welcome to the age of eloquent vacuity.

And the more senior you are, the less you understand. Even if you were once a developer, given that most developers don’t understand software development / software delivery, a developer background is not going to help you much.

Who does understand software delivery? Folks who have studied it as a discipline. And that’s precious few indeed. Of all the “development” folks I’ve met over the years – and that’s thousands – wayyy less than one percent actually have an effective understanding of the field.

Yes, there’s thousands upon thousands of folks who understand coding (programming). But that’s not much help at all in forming a broader and effective understanding of the wider software delivery discipline.

The upshot? The software industry is stacked to the gills with folks who have no clue what they’re doing, except in the narrowest of specialism. And worse, no ability to recognise the one percent. Result? The blind leading the blind. And the hegemony of the one-eyed man.

– Bob

It’s all talk. And no substance.

As they say, “Actions speak louder than words.” In my book, anyways.

Attachment

I have found that some folks are so attached to their thoughts, and their self-image as rational animals, that they fulminate greatly when their thoughts are discounted or dismissed. As if their thoughts were superior to any other’s.

I’m not a great fan of science neither. Cf. Feyerabend (2010). But I’ll take experimental evidence over opinion EVERY day of the week. Cf. Rother (2010)

So, please don’t EVER tell me what you think. It’s only ever pompous windbaggery.

I am however ALWAYS interested in how you’re feeling (and your needs, what’s alive in you).

– Bob

Further Reading

Rother, M. (2010). Toyota Kata: Managing People* for Continuous Improvement and Superior Results. Mcgraw-Hill.

http://www.youtube.com. (2020.). How to say BS in giraffe | Nonviolent Communication explained by Marshall Rosenberg. [online] Available at: https://www.youtube.com/watch?v=wtXogwq80vI [Accessed 24 Nov. 2021].

Feyerabend, P. (2010). Against Method. Verso.

* “You manage things, you lead people.” ~ Grace Hopper

17 Ways To Piss Off New Hires Before They Even Start

At least with in-person meet-ups (COVID restrictions permitting) one gets to bypass the presentations and chat with fellows.

Never again.  #NoOnlineMeetups

I hate it when I hear (or see on Twitter) somebody referring to new software makers as “juniors.” Seems both demeaning and dumb. Hierarchy at its worst. Those “juniors” can often contribute more than the arrogant clowns looking down their noses at them.

— Allen Holub (@allenholub) September 20, 2021

“Back at the start of the personal computer revolution in the 1970s, entrepreneurs were motivated by making great products, and money was a side benefit. Today, startups are all about the money, and great products are a side benefit, and not really necessary for success at all.”

~ Alan Cooper

For books, it’s the number of toshes* per page.

For articles, it’s the number of toshes* per paragraph.

*Here, “one tosh” is any one time I’m moved to protest “what a load of tosh”.

Intelligence has long ceased to be an evolutionary advantage. If it ever was.

Trawling the seas of knowledge

Note: This is one of those rare posts (for me) where I have few to no suggestions as to how to proceed.

Islands of Ignorance

In my travels, I have seen many organisations from the inside, and many more from the outside. 

In almost all cases, these organisations strike me as like little islands of ignorance in a huge sea of knowledge. As a mariner myself, I’m well aware of the bounty of these seas. So, maybe better placed than most to see the shortfalls in our organisations’ uptake of this bounty.

Seas of Knowledge

It’s never been easier to keep up with developments (sic) in praxis – in whatever fields of human endeavour interest us. And that’s probably even more true for the fields of collaborative knowledge work, software development and product development than for any other.

And yet, almost every organisation I see operates on principles – from the executive management suite to the workers at the coal face – utterly disconnected from the seas of knowledge surrounding them. Principles grown stale and musty with the dust of ages past.

Some organisations, having an inkling of their disconnection, make token efforts to bring outside knowledge in – with brown bag sessions, encouraging folks to attend meet-ups and conferences, hiring consultants from time to time, and so on. But like fishermen on the shore with fishing poles and spears hooking the occasional fish, this ain’t so effective. Few indeed are the organisations that build trawlers and send them out with nets, sonar, radar and the like to harvest the plenty of the seas.

Why is This?

What makes organisations so inept at finding and using the huge repositories of knowledge out there – in books, on the internet, in people’s heads, and so on?

Beats me. 

I have some suspicions that the education system is partly to blame. I’ve seen many graduates who, upon doing the workforce, act as if their learning days are behind them. 

And short-termism, the bane of UK industry in particular, contributes. With the implicit idea that learning, being more valuable in the longer term, has little or no value in meeting next week’s delivery schedules, or this month’s financial targets.

I guess, too, that like navigating our planet’s vast oceans, the seas of knowledge are so vast now that special navigation equipment is necessary to tackle the challenge. And whilst a fish is a fish, a idea or item of know-how is a much more slippery thing. How to sort the wheat from the chaff? Maybe systematic experimentation can help (see e.g. Toyota Kata, or Popcorn Flow from Claudio Perrone)

Appeal

So. There you have it. No elegant ideas for addressing the situation. Just an appeal to you, dear readers, to share your experiences, perspectives, and maybe a hint or tip or two for the rest of us.

– Bob

Further Reading

The Fifth Discipline ~ Peter M. Senge
Peter Senge and the Learning Organization ~ Infed article
On Dialogue ~ David Bohm

I love Twitter for its ability to facilitate conversations over time and space. Recently, I have found myself feeling irked by a style of conversation which I could describe – and have described – as “cargo-culted argument”. In other words, arguments attempting to promote a position based on widely-held existing beliefs and ideas (and where the arguer appears have not thought through that belief).

“A great many people think they are thinking when they are merely rearranging their prejudices.”

~ William James

Socratic Questions

I find Socratic questioning to be useful when mutually exploring a topic or question (my preferred mode of conversation). In using Socratic questioning I seek to invite parties to the conversation to reflect on and think about the issue afresh. Occasionally, however, one party will choose to repeat “conventional wisdom” on the topic, without, seemingly, pausing for said reflection. I say “choose”, but I wonder how much of a conscious choice it is. We humans are creatures of habit, not least when it comes to thinking.

I feel saddened on such occasions, when we miss the opportunity for deeper mutual exploration of a topic (and thereby a deepening of our relationship or Twitter connection).

“No problem can withstand the assault of sustained thinking.”

~ Voltaire

Fast Arguments – or Slow?

Kahneman writes about this phenomenon in his book “Thinking, Fast and Slow”. He describes Slow (system 2) thinking as the kind of reflective, conscious, consider-things-afresh thinking Socratic questions invite, whereas we all prefer to default to what he labels as Fast (system 1) thinking, which so often, in this context, leads to a simple regurgitation of conventional wisdom.

Would you be willing to set aside your Fast arguments in favour of a more Slow exploration of topics of conversation?

– Bob

Further Reading

Thinking, Fast and Slow ~ Daniel Kahneman

One of the (three) reasons we chose the name “Familiar” for Europe’s first 100% agile software house (1996-2000) was because of the very UN-familiarity of how we did things. Our (highly effective) approach to delivering quality software systems seemed very alien to the customers with whom we worked.

Our approach, our demeanour, our vocabulary, our assumptions and beliefs. These all appeared very alien to folks who had spent maybe their whole careers in much more familiar (sic) business, IT and software development environments. Indeed, they came to us often as almost a last resort – because those familiar approaches just weren’t working.

That Was Then

That was, then. And this is now. My journey has continued, and my approach has become ever more effective, and ever more alien. I find myself now at the point where folks are unlikely ever to be able to implement any of my approaches within their organisations, simply because those approaches are just too alien to seem rational, or plausible, or comprehensible to their peers.

Carry On Regardless

Honestly, it’s not my fault the whole world of software and product development, and tech (a.k.a. knowledge work) business in general, is totally borked. I’ve done my share of selling orthodoxies, and thereby making matters worse, to be sure. But I’m mostly over that now. And I’m not prepared to conspire in deluding folks about the effectiveness of those orthodoxies, just to make a buck. I sincerely feel for those folks who are still wedded to those orthodoxies, whether through choice, ignorance, or expediency. But I’m not prepared to play that game. I’ll continue to be the alien, thanks.

Not Around Here

The most common response I get these days is, “your approaches are great, but that’s never going to be the way things are done around here”. Which I translate as “we have no ability to evaluate let alone implement alien ideas, no matter how much more effective they might be.”

I’m minded of Gerry Weinberg’s caution in The Secrets of Consulting:

“Never promise more than a 10% improvement. Promise more and your customer won’t believe that it’s possible; deliver more and you make your customer look stupid. If you happen to achieve more than 10% improvement, make sure it isn’t noticed.”

~ Gerald M. Weinberg, The Secrets of Consulting

One more reason for folks to regard highly effective approaches as alien.

– Bob

Why not? Well, at the very root is the the Myth of Redemptive Violence, which gives power to both the Domination System within which we as humans are for the most part emprisoned, and to the Analytic Mindset with its anachronistic and oppressive (Theory-X) view of human beings as e.g. cogs in a machine. More specifically, there’s a whole passle of “failure modes” which I’ve seen in numerous self-styled Agile Consultancies:

The Path Of Mammon

• Consulting teams in name only. Consultancies like to supply teams. Many times, these teams are selected by managers, and run by Project Managers or Account Managers. And from there, it’s managers all the way up (down). Even whilst espousing the benefits of Agile, these consultancies fail to walk the talk.
• Analytic Mindset. Consultancies, not wishing to look too alien to their largely Analytic-minded client base, and perhaps lacking the imagination to see beyond conventional management models, most often adhere to the hierarchical management models now beginning to look very dated.
• Theory-X. At the beating heart of Agile lies the Theory-Y disposition. How many Agile consultancies have Theory-Y type relationships with their staffers, as opposed to the more traditional Theory-X stance?
• Play. Innovation. Creativity. All espoused values of Agile, and all conspicuous by the absence in many consulting engagements, where margins, revenues and milking the client for as much money as possible seem to take precedence. And where things have to be done “by the book”, both by the consultants and the client’s staff they’re supposedly “helping”?
• Delivering value. This. How many consultancies do you know that offer an unequivocal value-for-money guarantee?
• Incremental delivery. Another core value of the Agile approach. How often do contracts with clients reflect this? How often do contracts (do you remember “Customer collaboration over contract negotiation?) stipulate fixed terms for the consulting engagement?
• Agility. How many consultancies do you know that start an engagement with a plan of campaign, or agenda, vs sensing the clients evolving needs and responding to those changing needs as they flex and unfurl?
• Agile is about human relationships. How many Agile Consultancies do you know that major on that? On building long-term relationships between their company and their clients’ companies? (Much more that just relationships between individual consultants and individuals in the client company). On becoming a trusted parter at the heart of clients’ businesses?

I could go on, but I think I’ve listed the main points of my argument.

Two-Way Street

It’s a two-way street, of course. Agile Consultancies follow the Path of Mammon mostly because that’s what their clients expect, or demand. That’s what many imagine it takes to survive and thrive in a Market for Lemons. It looks risky to buck that demand in favour of another way. But another way there is.

Another Way

There is another way. A way which eschews short-term revenues, and skipping from one unsatisfactory engagement to the next, in favour of helping clients in the longer-term. With non-dogmatic advice and help that attends to the needs of everyone involved, not just the consulting company’s big-wigs. This Other Way is the path I myself have chosen to follow. It’s not as easy nor well-travelled a path as the Path of Mammon. But I find it immeasurably more satisfying, all-in-all.

“Two roads diverged in a wood, and I, I took the one less traveled by, And that has made all the difference.“

~ Robert Frost, The Road Not Taken

– Bob

Further Reading

Joy, Inc. ~ Richard Sheridan Why Familiar Was Europe’s First 100% Agile Software House ~ FlowChainSensei

I’ve hired a lot of folks in my time, and been through quite a few hiring experiences too. I’m always amazed that hiring organisations seem utterly oblivious to the tone they set for their relationship with new employees – even before they make the job offer.

Here’s a list of some seventeen ways I’ve seen organisations piss off their new hires even before those folks turn up for their first day:

17. Give the impression that mistakes are not tolerated in your organisation.

In particular, make it clear to candidates that hiring mistakes are career-limiting, and you and your organisation take great pains to avoid such mistakes. From this, candidates can easily infer what to expect when they actually start work.

What to do instead: Convey your willingness to take risks, and attribute that to encouragement from the organisation, rather than to any personal heroism. In particular, express the organisation’s willingness to stick it’s neck out for what it believes might be good hires, even when not at all obvious.
See also : Make Bad Hires

16. Make sure your communications are garbled through one or more intermediaries.

When little hiccups happen, make sure the explanation is garbled to the extent that any fair-minded person might interpret it as ineptitude, or even better, mendacity. This can go a long way to setting the tenor of all subsequent interactions with a candidate.

What to do instead: Communicate clearly to intermediaries that they are NOT expected to sugar-coat or otherwise alter the messages they relay from either party. Ensure all communications are available for inspection by all parties. In particular, don’t communicate by phone, and follow up face-to-face conversations with a written summary of what was said.

15. Talk exclusively about the current situation.

Assess candidates on the present needs of the organisation – after all, things aren’t going to change at all, are they?

“A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.”

~ Wayne Gretzky

What to do instead: Focus on the future. Any useful candidate will be looking to build a future with your organisation. Talk about how things are likely to evolve, and the challenges everyone will face coping with that. Explore how the candidate’s mindset, talents, skills and abilities will be useful in that possible future.

14. Appear uncertain as to why you’re hiring for this position.

If you know the value-add of the position, refrain from mentioning it. Better yet, talk with candidate from a position of genuine ignorance.

What to do instead: Realise that candidates would prefer being given “a good job to do” – i.e. one where the value-add of the position is clear and achievable. Go out of your way to gain an understanding of how filling this opening contributes to the goals of the organisation. And then communicate that. Better still, explore the value-adding possibilities jointly with the candidate.

13. Give candidates cause to believe you and/or your organisation are not serious players.

Don’t make any mention of established know-how, or initiatives to make things better. Skip over topics such as personal development, morale, continuous improvement, and such like. Never mention the “giants” in your industry (e.g. in software don’t mention folks like Deming, Ackoff, Seddon, et al.) and feign ignorance of bodies of knowledge relevant to your industry (e.g. Coaching, Team-building, Scrum, Kanban, Lean, TPDS, etc.). Gain bonus points by appearing oblivious to management-related bodies of knowledge too (cf. Buckingham/Gallup, Drucker, Deming (again), Hamel, Google, etc.)

What to do instead. Briefly touch on the bodies of knowledge the organisation has taken on board, and make a few mentions of specific cases of how the way the work works has been influenced by these bodies of knowledge.

12. Imply candidates will stand a better chance of getting the job if they lie.

Candidates who want the job will says what they think you want to hear. They will “creatively” tailor their CV or resume to the job specification if they believe that will improve their chances of getting hired. Never make this implication explicit! It, like so many of the assumptions and unwritten laws governing hiring, are undiscussable.

What to do instead: Act with integrity. Folks can recognise that, as they can a lack of integrity, dishonesty, and dissembling.

11. Keep asking them to come back time and again.

Make it seem like you couldn’t organise a piss-up in a brewery. Fail to line up in one session all the folks who the candidate will need to meet. Have them come back three, four, five times just to see another face who, most often, will make it clear through their demeanour and body-language that they were not so interested in meeting the candidate anyway.

What to do instead: Arrange all meetings, conversations, etc. for the same visit. Realise that more meetings and conversations add little to the validity of hiring decisions, and can give candidates the impression the organisation is risk-averse (see point 17. above).

10. Make the hiring decision appear arbitrary.

Make it clear to the candidate that it’s your decision who gets hired, and you have certain opinions which any candidate must match up to. After all, you’re in charge of your little piece of the organisation, and hiring folks on the basis of what’s good for the organisation just wouldn’t do at all.

What to do instead: Explain the criteria the whole organisation uses to assess candidates, and the special exceptions you (or the hiring manager or group) make to those general criteria.

9. Use formal interviews.

Don’t fall for all that scientific malarkey which shows how fallible humans are at e.g. making hiring decisions, and the research which highlights the universally poor results obtained through any formal interview process.

What to do instead: Skip directly to having likely candidates come in and do real work with real people, to gauge their fit. Pay them for this – and pay them to leave if they feel they don’t fit in.

8. Have an insane amount of paperwork.

Make sure that there’s a mountain of paperwork for each candidate to fill in. Make sure as much of it as possible is obviously unnecessary. After all, candidates would like to realise that 80% of their time is being wasted even before they start the job – just as it will be after – wouldn’t they? And stress them out even before the job starts with worries about their references, etc. being good enough.

What to do instead: Work with e.g. HR to ruthlessly prune the prerequisites for candidates down to a bare minimum. Provide them with a third-party service, similar to a concierge or such, to do the lion’s share of that bare minimum. Make it policy that no candidate may start before these prerequisites are completed. Place a time limit on how long such work can take – with a “free pass” after the cutoff.

7. Appear inept.

Look as if you’ve never interviewed before. Have a list of “typical interview questions” that sound like you found them online. Give the impression that you and your organisation are doing the candidate a great favour by even deigning to speak with them.

What to do instead: If you really have never interviewed before, admit to it. See if the candidate can help. If you do have some prior experience, appear to have learned from it.

6. Fail to understand or explore the candidate’s value-add.

Candidates are ten-a-penny these days. You’ve got a slot to fill, and you need a warm brain to fill it. Simples. No one is going to criticise you for not getting the best out of the folks you hire – at least, not if you appear to drive them hard.

What to do instead: Just about everybody wants to do a good job. Which means just about every candidate has put a deal of effort into developing their skills, learning things, and making the most of their talents. And they’d really, really like to apply as much of that as possible to the benefit of your organisation. So explore what they can do, and more importantly what they could do, given sufficient support and encouragement.

5. Don’t prep. Don’t help the candidate to prep.

If your interactions with a few of the candidates go awry through your being unprepared, well, who’s ever going to find out?  And if a candidate objects, well they’re obviously not of the right stuff, are they? And hiring is a bit like school, isn’t it? “Sit still. Don’t talk. Do you own work. Don’t copy.” So don’t help them to be best prepared, either. After all, if they’re really interested they’ll spend days of their own time doing their own preparation, won’t they? Besides, it’s a good introduction to what working here is really like. Best be honest, eh?

What to do instead: Show that you and your organisation respect people by being obviously prepared for each candidate. Not just having a prepared list of questions or check-list, but being prepared for each individual candidate, like they were a human being or something. And help each candidate present themselves in the best possible light by helping them prepare, even before meeting you and others.

4. Exclude the CEO.

God forbid your higher-ups taking any kind of interest in who you hire. That could be career-threatening. Better by far to keep all hiring activity to yourself. What possible benefits could there be to either the candidates or the organisation in being open about these things?

What to do instead: Invite your CEO to spend a couple of minutes, one-to-one and in private, with each near-hire candidate. See “The Four Obsession Of An Extraordinary Executive” for a passle of reasons why this might be a good idea.

3. Involve HR.

You’ll need someone to blame if things don’t work out. HR makes the perfect patsy, so get them involved as early as possible, and make sure they have a real say in the hiring decision – and not just as administrative support.

What to do instead: Make use of HR as administrative support, to ensure all the ‘I’s are dotted and ‘T’s crossed, but for God’s sake keep them away from hiring decisions, and from the candidates.

2. Don’t involve others such as potential colleagues and peers.

Show your cojones by appearing to take all the risks of the hiring decision upon yourself (but see also point 3.) Real managers don’t work via consensus, in any case. And the successful candidate is going to be your boy (or girl), aren’t they? Why would they need or want to meet anyone else before joining?

What to do instead: Solicit the opinions of some or all of the other folks involved. Have them meet the candidates for a chinwag over a beer or a pizza.

1. Ignore the candidate’s blog, twitter feed, LinkedIn profile, etc.

Social media? Pah! What possible use could that be? Besides, you’re busy – too busy to read all the lame stuff that candidates have been writing. Much better to ignore their paltry attempts to present themselves, their value-adds, their ideas and their personalities. Your innate talent to gauge an individual’s merit needs no supporting information. Besides, the best candidates are insular, uninformed, anti-social, inarticulate, unopinionated and easily influenced, aren’t they?

What to do instead: See if each candidate has a blog. Read a few posts which catch your interest and discuss them during your face to face conversation(s). Dip into their Twitter stream, if they have one, to get a feel for their personality, sociability and standing in their professional communities. Check out their LinkedIn and GitHub profiles and community contributions. And invite others in your organisation, that may also meet candidates, to do the same.

Of course, there are dozens more ways you can piss off folks once they have joined, but here we’re just talking about before that first fateful day. Why not use some or all of the above tricks to sour the budding relationship and set folks up to fail from the very outset? Millions of companies can’t be wrong!

“Most of what we call management consists of making it difficult for people to get their work done.”

~ Peter Drucker

Did I miss any ways that have pissed you off?

– Bob

Afterword [8 Oct 2021]: The most significant point, and not listed above, may be to share with the candidate that their contribution, however awesome, will only account for some five percent of their productivity.

0. Ignore the role of the system (the way the work works)

Make it plain to the candidate that result are entirely on them. Their commitment, passion, skills and effort is what really matters, and will be the basis upon which they’ll be judged.

What to do instead. Explain you view – and the organisation’s view – on Deming’s 95:5. Elaborate on the system in place, the way the work works in the team or department they’ll be joining, and who owns the several aspects of the way the work works. Make It plain as to the basis upon which their personal contribution will be judged.

Further Reading

Eight Hiring Mistakes Employers Make: From Application to Interview ~ Susan M. Heathfield

After a protracted series of interviews and aborted interviews, I was recently offered a three month contract in London with an organisation professing much in the way of becoming Agile. Despite some number of reservations, I had decided to give it a go. Imagine my reaction, then, when this email turned up…

———————————————————————————-

[Preamble – redacted]

Here are the documents we need returned. The ID and Proof of Address must be verified by a professional (preferably your solicitor) who has known you for more than 2 years with their full name, occupation, dated and signed.

· Verified copy of ID (passport, photo driving licence etc) Please have the front cover, first page and photo page verified – each with a statement saying ‘Certified to be a true copy of the original seen by me’. If you choose the driving licence we need both the photo card and counterpart verified.

· Verified copy of Proof of Address – Issued within the last 3 months (1 of the following: Utility bill, bank statement or similar from home address) – Please state ‘Certified to be a true copy of the original seen by me’.

· Criminal Declaration Form (Signed)

· Confidentiality and conflict of interest form (Signed)

· Declaration of Interest Form (Signed)

· Basic Disclosure Scotland Check – http://www.disclosurescotland.co.uk/disclosureinformation/basicdisclosure.htm – Please apply ASAP and let me know the reference number

· References- A full 3 years work references are required. If only one role has been worked over the 3 year period then a personal reference will be required also. If a limited company has worked many assignments then an accountant’s reference specifying that between two dates work was solidly carried out on various assignments would be acceptable but as that would only count as one reference, a personal reference would be required as well.

· Gaps in work- Any gaps of more than 28 days in the last 10 years need explaining by evidencing what happened during that time. A personal reference specifying the dates is required, if this is not possible then other evidence would be considered i.e. receipts etc.

· CV containing previous 10 years employment/education history with no gaps

· Tax Assurance Forms (Signed)

Ltd Company documents – if you don’t have them: http://www.hiscox.co.uk/business-insurance/insurance-products/
Certificate of Incorporation
VAT Registration Certificate
Professional Indemnity Insurance – Minimum of £1m
Public Liability Insurance – Minimum of £1m
Employers Liability Insurance – Minimum of £5m

Government guidelines on Certifying documents:

https://www.gov.uk/certifying-a-document

To certify documents, ask a professional person or someone well-respected in your community (‘of good standing’) like a:
· bank or building society official
· councillor
· dentist
· police officer
· solicitor
· teacher or lecturer
The person you ask shouldn’t be:

· related to you
· living at the same address
· in a relationship with you
Check with the organisation that needs the certified copy – they may have specific rules for who can certify a document.
How to certify a document
Take the photocopied document and the original and ask the person to certify the copy by:

· writing ‘Certified to be a true copy of the original seen by me’ on the document
· signing and dating it
· printing their name under the signature
· adding their occupation, address and telephone number
The person certifying the document may charge you a fee.

[Post-amble – redacted]

———————————————————————————-

This was, of course, the straw that broke the proverbial camel’s back. Needless to say, I have declined to be a party to this madness.

“If the company looks inept to you, you might assume everything else they do is inept.”

~ Daniel Kahneman

I have a forlorn hope that my “protest” might provide someone with some argument to oppose the policy.

Never mind. Onward and upward!

“There’s no shortage of talent – only a shortage of organisations that talent wants to work for.”

– Bob

Further Reading

No More Stupid Punts ~ FlowchainSensei

I like the UK Government Digital Service Design Principles. For a government organisation, GDS show some progressive thinking and their design principles come close to principles to which I could subscribe. Close, but no cigar.

Here’s my suggestions for principles which I could wholeheartedly embrace:

1. Attend to folks’ needs.
   This improvement seems close to “start with needs”. But why just start? Sounds a bit waterfall-ish to me.

   “Before we begin any project we spend a long time working out what the user needs are.”

   Do people have needs just at the outset of an endeavour? Maybe they mean “Always give priority to (users’) needs.” If so, why not make it clear?

   Why only users’ needs? That seems like missing the fundamental opportunity to build an environment in which (GDS) folks can choose to give of their best.

   And “start with needs” seems to imply design is a linear process, rather than – as I see it – one of evolution, emergence, and continual learning/discovery.

2. Do what’s needed – more more, no less.
   Sometimes, less is more. Sometimes it’s not. If we do what’s needed, and no more, then we’ve done the minimum. Focussing on “doing what’s needed” – taking into account all constituencies and needs – seems better than “doing the most good” (whose good?). And let’s not get hung up on the minutiae of “minimal” page design (see their example) when “minimal” effective services are the aim?
3. Continually Evolve The Service with Quick Feedback and Iterations.
   OK with this one – excepting the wording “Design with Data” which may only serve to confuse, and to cut folks off from relevant pools of existing know-how, such as Lean Startup. See also my (additional) principle 11.
4. Make It Optional.
   One of the things that really gets my goat with “Digital by Default” is that it so often means “Digital only”. I won’t go into the folly of believing that digital aka online Government Services are cheaper to provide or meet folks’ needs better, by default. Better, I suggest, to make the digital option truly optional, and follow the data to learn if the digital option is the most popular option. Let folks vote with their feet!
5. Flow.
   “Iterate” is a bit of a duplicate of 3. This principle seems more about highlighting the idea of continual flow of value. I.E. No service has a beginning or end, but just a continual flow of ever-improving delivery of “meeting people’s needs”. “Launch” happens every day. Maybe dozens of times per day.
6. Build for Inclusion.
   Great principle. Hard to do when Digital By Default – “The people who most need our services are often the people who find them hardest to use” (and those who least want to use a computer to access them?). Is this issue even discussable?
7. Understand Context.
   Ditto with 6.
8. Build Services, not Digital Services.
   Granted this is not within the purview of the Digital Teams themselves, whose raison d’etre is to build Digital Services. But I believe this can change, given the will.
9. Derive Consistency From Needs.
   If needs are understood, and the trade-offs of consistency also understood, than it’s possible to decide when consistency is beneficial, and when it’s a drag.
10. Make Things Open.
    Including dissent, discussion and debate – and those topics that remain undiscussable.
11. Build Improvement Into the Way the Work Works.
    Some of the original list of UK Government Digital Service Design Principles speak to improving government (digital) services as experienced by users. But I see no explicit mention of improving the way the work works. I’m sure all the smart folks in GDS are pursuing improvements to how they work, so why not recognise and honour that with its own principle? Moreover, make explicit the principle of in-band continuous improvement – to help avoid the dysfunctional anathema of e.g. change programmes, improvement teams, and so on.

– Bob

Further Reading

Sketching User Experiences: Getting the Design Right and the Right Design ~ Bill Buxton

Is your business going to fail because your product development (engineering) capability is in the toilet? Probably not. Are you leaving much success (value) on the table? Definitely.

Maybe you don’t really want or need awesome “success” – however you define that. Growth, profits, fun, kudos, whatever. In which case no worries. Move along. Nothing to see here.

Maybe you’re satisfied – or simply resigned – to being a one-product company, with no real plans for developing any more products in the future. That can work. Even in the long term.

And there are other paths to a “successful” business than engineering excellence. You probably work in such a business, even now. One that has chosen another path, that is. How’s that working out for you? I mean, how’s it meeting your needs?

“People simply feel better about themselves when they’re good at something.”

~ Stephen R. Covey,The 8th Habit: From Effectiveness to Greatness

Even if your business (more specifically, the folks in charge) wanted to take the engineering excellence path, it’s just so damned hard, isn’t it? Easier by far to pay lip service to the idea, delude yourselves and others – like customers and investors – that you’re serious, while actually just futzing around making it look like some progress is being made.

And let’s not forget, engineering excellence doesn’t just apply to your business’ products and services. It’s arguably even more relevant to the way you run your business (the way the work works).

Do I have any advice for those very few folks with the horn for actually doing something about engineering excellence in their knowledge-work business? Yes. It’s spread across the nearly three hundred blog posts I’ve written here over the past five years. Not that anyone’s listening. Which kinda demonstrates my point.

– Bob