Pragmatic Dictator

One simple management fact: Staff move on. There are many reasons this happens, not least of which is the lack of additional opportunity to progress and learn.

Given this state of affairs, we need to develop means for handling the fact that staff move on. Typically that focuses everyone on recruitment of suitable replacements that:

• Already possess the appropriate technical skills
• Already have the relevant experience
• Already have the relevant mindset

The key word there is already. It presents us with a number of problems:

1. An equivalently skilled individual will almost certainly move on themselves, because they’ll soon figure out there’s no more opportunity.
2. There are only so many suitably skilled people available.
3. Unless we have a bottomless pit of money, we can only access some fraction of the overall pool of available people.
4. Someone who has the mindset may not yet have developed the skills.

All these factors limit our ability to find the perfect replacement. It follows that we should widen the net a little, look for those that could be what we need with a little training. Training is likely to be a mixture of courses and on the job, with the latter dominating as what is learnt in the classroom must be put into real practice to bring progress and value.

Adopting such an approach brings many benefits including a maintained quality of work and a level of loyalty which translates into good staff retention which in turn reduces the amount of recruitment we must do. Cool, huh?

One last fact: Too many organisations make no serious effort at training, expecting the right people to just walk through their doors. They want someone else to take the burden e.g. universities and give nothing back in return. Such selfishness ultimately leaves them short of the skills they desire incurring costs.

Employment is give and take, give some training and development and you’ll take the rewards.

Many in IT would have you believe that they’re progressive, constantly advancing and learning. They will provide examples such as:

• We’re adopting lean (or agile)
• We’re using Scala
• We’re doing large-scale

Dig a little deeper though and you’ll quickly find:

• The agile or lean they’ve adopted and trumpet is merely a fixed set of ceremonies such as time-boxed cycles, limiting in-flight work, pair programming and automated testing.
• The Scala code they’re writing is largely imperative with no use of any of the obvious functional aspects.
• The supposed large-scale is in fact a couple of thousand customers running on a single database with an operation count per minute of no more than 60.

These individuals and companies are paying lip-service, they haven’t learnt anything other than what the latest buzz is and they’re operating some parody of the real thing.

The fundamental problem is, they don’t do their research. They don’t actually examine what has been done previously and understand its fundamentals, apply it and sharpen it. This is the skill that I gained at university, not some set of buzz technologies or processes. This is the fundamental skill that allows us to progress, to learn, adapt and act.

[ There's a supreme irony in an individual or company claiming to be doing agile or lean and not being able to research, learn and adapt because they follow a fixed set of ceremonies. ]

Unfortunately this skill isn’t generally recognised as valuable in the IT industry, it’s rarely taught and not seen in requests for curriculum changes from business to universities. This sort of feedback is more typical:

…startups need graduates who can hit the ground running, who are proficient in PHP, Python and Ruby (among other modern programming languages), and who, ultimately, understand the practical side of software engineering as opposed to just the theoretical side which they learn at university.

Being proficient in a language does not make you good, it just means you can crank (poor) code fast. Further, understanding the practical side of software engineering means learning from what you do, analysing and adjusting. If we’re all so good at that, why do we repeatedly get burnt by the same classic mistakes?

Far too many within IT act on hype or pay lip-service, they don’t do research, they don’t adopt the basic disciplines of learning. Whilst that continues, progress is nothing but a pretence.

As soon as we give something a name, it becomes open to abuse and misuse.

Vendors can claim they are doing it and support it, developers can claim they do it, use it or implement it. There are a bunch of ready examples: Agile, XP, SOA and REST. Naming something makes it easy to ignore or forget its underpinnings, the elements that deliver value.

As a martial artist, I’m familiar with this pattern of behaviour: various people claim to practice and teach authentic Silat, Karate, Kung Fu, Escrima and so on. Inevitably some of them are exposed as pretenders. One of the more notable martial artists, Bruce Lee was sufficiently concerned about this that he gave serious consideration to leaving his approach to martial art (Jeet Kune Do) unnamed^*.

Is it worth naming things? Might we be better served by making our knowledge, approaches and philosophies visible for others without naming them to adopt or not as they see fit? Would it reduce the number of valueless certifications, buzzword cv’s and endless wars over which way is the way and who’s doing it right?

* Jeet Kune Do (1997) ‘Actually, I never wanted to give a name to the kind of Chinese gung fu that I have invented, but for convenience sake, I still call it “Jeet Kune Do”. However, I want to emphasize that there is no distinction between jeet kune do and any other kind of gung fu, for I strongly object to formality, and to the idea of distinction of branches.’