Geir Hedemarks blog

I am getting old, I know. Old enough that I have allowed myself to slow down a bit and actually ponder what people around me say – and how they try to get their points across. It is an experience which sometimes ends up with strange insights.

I have just been at home a couple of days celebrating christmas, and got to thinking about people in power (architects, project managers, choose your own fancy name) who have turned out to be a bit off the mark.

These are the most memorable opinions I have heard the last couple of years:

• “We don´t do it like that here”. This statement is wrong because it doesn´t actually address whatever caused a suggestion of whatever is “not done”. I am sure most developers have come across this one. It even has its own name: “Not invented here syndrome”. This is first since I come across it so often.
• “I am here to create a counterpoint to your opinions”. This statement is wrong because it doesn´t take into account who is wrong. Taking the opposite viewpoint is never a good strategy – one opinion has to be wrong.
• “We follow best practices”. The practices in question were out of date, and from the pre-EJB 1.0 time. This statement is wrong because it assumes that whoever has created the best practices have created something that is applicable to all situations. In this case, common opinion was that the pattern never was a best practice at all. This is a variation on invoking God – in this case, the deity in question was one of the original Sun blueprints.

All of these examples have thing in common. Whatever was being said was not backed by an argument based in long- or short-term gains for the project or the organization.

I know I have done this myself in the past. My resolution for the next year – to become a better professional – is to never, ever do this again.

What is your resolution for the new year?

I have had a search going the last decade or so at the biggest job posting site in Norway. I like knowing which companies are hiring, and what kind of people they are looking for.

The last year or so, I have seen more and more job postings with variations of “you need to have worked in  very expensive projects”. It usually isn’t worded exactly like this, though. The usual phrase is based on looking for  some kind of leadership role, but only if you have experience with major projects – and here major projects are measured in money. “Need to have been a <something> on projects which cost more than <some nine-digit sum in NOK>”. So far, we haven’t been able to run projects into ten digits here in Norway, and I really hope it isn’t just a question of time.

This mystifies me.

IT projects are – at least not after the .COM frenzy, where a bunch of moneypushers tried to tell us the usual rules were suspended – not supposed to burn off the maximum amount of money possible. You are not supposed to build the biggest empire you can. You are supposed to use the minimal amount of IT needed to increase your earnings. Every extra coin spent needlessly on IT eats into the earnings.

Very few companies consistently manage to hit the sweet spot. Some underspend on IT, and increase their costs or fail to get hold of the possibilities that are enabled by IT. People tell me a lot of companies who have tried to offshore development have learnt this the hard way. Others overspend on IT, and reduce their earnings through direct IT spending.

Going far enough in a job ad to say right out that employees are measured by the amount of money they have managed to spend it totally beyond me.

Why would anyone actively communicate that they want the biggest spenders in the class? Even if they are vetting the applicants during the interview process to sieve out the big spenders, the job posting itself sets an unacceptable standard for whoever is already employed, and this mindset is going to take a major amount of leadership to correct. “We have big balls because we are rolling in other people’s money”? In the future of these companies I see people delivering stuff that doesn’t work. The work ethic and the craftsmanship will have gone from the workplace. This can happen all too easily to a development team. When standards slip, they slip fast.

Fixing a culture that has has been degraded in this way reduces the efficiency of whichever leader was just hired, and increases the costs of the project because the other problems – the problems that presumably were there before the job was posted, and is the reason for the role being created – are going to get less attention.

I hope this kind of wording is a kind of slang – a slang created, probably unconsciously, by groups who have worked together in the past. I hope these groups learn to reassess their value in terms of worth. The alternatives are all far worse.