Over a million developers have joined DZone.

Some Things Can Never Be Spoken

Allan Kelly critiques misused and detrimental language in the workplace, with a little help from the author of The Hitchhiker's Guide to the Galaxy.

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

“Some things can never be spoken.

Some things cannot be pronounced.

That word does not exist in any language.

It will never be uttered by a human mouth.”

        Talking Heads, Give me back my name, Little Creates 1985

Some things shouldn’t be spoken. Some things shouldn’t be targeted. Some things should be created as a side effect. In Life, the Universe and Everything, Douglas Adams explains the secret of flying:

“The Guide says there is an art to flying," said Ford, "or rather a knack. The knack lies in learning how to throw yourself at the ground and miss.”

Throwing yourself at the ground and missing.

It's important not to try to try:

“One problem is that you have to miss the ground accidentally. It's no good deliberately intending to miss the ground because you won’t.”

In business, in software development, there are similar problems. There are some things we should try to hard to achieve. There are some things we shouldn’t speak.

We may want to achieve these things but they should be side effects of something else. Usually the thing we want to achieve is important but to set out to achieve it has nasty side effects. The solution is to do something else which has the nice side effect of creating the thing you want.

Got it?

Following me so far?

Think of it as an antidote for Goodhart’s Law: "When a measure becomes a target, it ceases to be a good measure."

Let's try some examples.

Profit is something that shouldn’t be aimed for. It's easy to increase profit, just fiddle the accounting rules. Ask Enron, WorldCom, or Lehman Brothers for details.

It's even easy to reduce costs—just reduce travel allowances, freeze wages.

Another easy way is just to fire people. You will instantly reduce costs—redundancy payments can be made to disappear under “exceptional” items in the accounts—and it will be months if not years before the negative effects cut in.

It's often easy to increase sales: Reduce price.

But all of these things will have a counter effect: Maybe not today, maybe not tomorrow, or next week, but sooner or later. People will become demoralised, people will communicate less, people will leave the company, customers will get dissatisfied, and your auditors might catch you out.

The secret to making lots of profit is to not try. Try instead to make a positive work environment and make your employees happy. Better still, try and make your customers happy; make your customers lives better. Do the right thing by your customers and employees and you should expect profit to follow.

And if delivering profit means doing the wrong thing by your customers and employees then ask yourself: Should we be in this business? Is this business sustainable?

It's not only profit.

Take another one popular with executives: Culture.

Company Culture is most definitely one of these things we shouldn't speak of. Don’t set out to create a culture. Set out to create the kind of company you want and in the process you will create the right culture. But abstract this to a culture and you have failed.

Who gets up in the morning to go and work in a culture?

Who, for that matter, gets up in the morning and says “Gee, today I’m going to make the company another $10,000?" (OK, sales folk do.)

Rather than set out to create a culture, set out to create something else: A passion for delivery, a fervour for innovation, or a zest for pleasing customers.

Don’t call it culture and don’t set out to create a culture which is passionate about delivery. Do the thing itself and the culture will follow.

Communities of Practice, CoPs, is another one.

CoPs periodically become fashionable, I’ve founded and run a few CoPs in my time and I’ve studied them. Heck I think I even wrote about them in Changing Software Development. But whenever I’ve seen someone set out to create a community of practice they fail.

The trick is not to call it a CoP. Call it a group, a study group, a tech group, a community, just about anything but a community of practice. A community of practice is a semi-academic term to describe an observed phenomenon. Decide what you really want, not an abstract idea.

In fact, teamwork is probably another of these things. Don’t set out to create good teamwork. Set out to make your team better at what they do.

Create a purpose to your work—not teamwork, not culture, and not profit.

Servant-Leadership is most definitely another—talk about it in your Manager Anonymous sessions but don’t use it in the office. I know one company where the Project managers got very confused when they were told they were now Servant-Leaders.

Don’t tell people you are now a Servant-Leader. Change your behaviour. Become the servant leader you wish to be. It will take the team time to notice the change but it will take you time to change. Simply announcing that you are now a Servant-Leader will not make it happen; it will only confuse people—and perhaps make you look arrogant.

My own #NoProjects is another. As Joshua Arnold said recently: The first rule of #NoProjects is don’t talk about #NoProjects. The corollary is: Don’t talk about Projects. Don’t talk about them. Talk instead about product, talk about teams, or stream teams, or amoeba teams. Just don’t talk about No Projects.

This isn’t an exhaustive list, these are just things I’ve noticed again and again, I’ve seen others—and I hope you will too.

Think, if you like, of these things as attributes—teamwork, culture, profit, community—or better still qualities, qualities that should remain nameless, since naming them kills them. The trick to all of them is to not try too hard, to focus on something else, to focus on something more concrete, and let the abstract notion follow.

Qualities without a name.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

agile practices,team collaboration,language constructs,productivity,existential questions

Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}