A blog post has cropped up on a couple of my feeds recently, so I suspect it’s getting some coverage. It has the attention-grabbing (and perhaps click-baiting) headline “Agile Negates the Most Important Benefits of Switching to Functional Programming”. And while I don’t think there’s value in debating the headline there is something interesting under the surface.

The story in short, and extracting only the elements that interest me here, is: “I wrote something wonderful for my company and potentially for many others; some other developers in the company messed it up so that it didn’t achieve what I wanted it to achieve; they were able to do that because of my company’s value system.” The original has much more to it, but that’s what I want to extract for the purposes of this post.

As I say, I don’t want to debate the headline, but it does raise an issue that underlies the story and thesis—the balance between professional pride and practicality. In this case the author intended to create something with lasting impact, but it didn’t happen. At some point between the author, the company’s value system, and the way that value system was implemented, the author’s intentions failed to materialise.

We seek professional pride, and usually (whether it is conscious or not) this means doing work that is admired by our peers. Software developers, for example, want to write code that is elegant and efficient, and which uses techniques that stimulate them, and reflect current thinking. Similarly HR professionals, say, want to use well-recognised and rigorous practices to ensure workplace harmony and maximise the potential of all their staff.

But when we do this for a living we are working for another cause at the same time—because we also need to do work that helps our organisation progress. After all, that’s one of the reasons we’re being paid. Unfortunately sometimes that professional pride can clash with progressing the organisation. I’ve known many well-intentioned HR people who want to foist onto staff processes which both distract them from their main job and (worst case) unintentionally subvert them from achieving the organisation’s main goals. I’ve seen software developers spend so much time on perfecting some beautiful thing that they forget the work which means most to the organisation’s health.

In the end we need to manage the balance between professional pride and practicality. Going too far in either direction will mean one kind of trouble or another. How we do this, of course, is the tricky bit, and in general the more we can demonstrably do it the more valued we are.

Any time spent working on something that does not obviously have a direct impact on the organisation’s goals therefore needs to be accompanied by some strong internal sales—and careful listening.

In other words, we need to be able to sell what we’re doing internally, and people have to buy into it. If they don’t buy into it then it’s tempting to blame their lack of vision, but we might equally question either our own ability to communicate our ideas, or the worth of what we’re trying to do. That’s especially important when we want to show that some new thing we want to do fits with the organisation’s goals, because the organisation’s goals—and all the juggling that goes with it—usually cannot be understood by one person. It requires discussion, understanding, and adjustment.

Photo by JD Lasica