De Nederlandse versie van dit artikel vind je hier.
I recently received a message in my LinkedIn inbox from a recruiter looking for ‘digital talent’ but who was especially looking for people with a finance, economics or business administration background. The message itself could be considered spam (they even did not mention what kind of work they were offering and I inferred wrongly from the fact that they had targeted me, a ‘Strategic IT’ person), but it did remind me that I had this post lying about, which addresses one very strange aspect of working in ‘Strategic IT’ and Enterprise Architecture: it is quite common for jobs in that field that the requirements focus not on IT itself, but on ‘the business’ to the extreme of even thinking that IT know how is a disadvantage.
The need for strategic IT advice
Some business level executives are aware that they have not enough insight in what makes IT tick, but at the same time they know that in their case, a large part, if not most, of their organisation is in fact IT-based, and their decisions are driving it. Many organisation become more and more ‘digital organisations’ and many executive is aware of the phrase ‘digital transformation’. Being generally risk-averse*) these executives want support. Which is a wise move.
When executives search for specialist executive support, they will generally focus on that specialism. They will absolutely make sure their ‘chief legal counsel’ is an ace in, above all … law. “Duh”, I hear you think, but for IT-related executive support, the main requirement is often not ‘be an ace in IT’ at all, but instead often the candidate above all ‘must understand the business’. Which is, if you think about it, extremely weird. The executive level is already full of people who ‘understand the business’. That is their job. How on earth will adding more of what you already have solve your lack of something you are missing?
What executives really mean is of course: ‘we want someone who understands IT and who is able to understand our perspective and connect the two’. It is a communications requirement. But this is often lost in the process and when that happens organisations end up with (temporary) IT strategists who have only a very shallow understanding of IT, but who (hopefully) understand the business very well. Who are nice to talk to because you understand each other. Feel good artists, sometimes.
Regarding IT, some executives behave like someone with physical complaints, who then looks for a fellow patient who they can talk with about the complaints, instead for a medical doctor who can help them find and deal with the causes (and who sometimes has to do or say something unpleasant).
There are of course reasons why this happens. A few (in no particular order) are:
- Psychological underestimation of IT’s complexity and difficulty: IT is simple. What is there to understand about IT? I have a computer. I understand it well enough. An interesting example was Dutch Prime Minister Mark Rutte who at some point in a debate at the end of 2020 about IT problems regarding ‘Covid crisis related IT’ exclaimed “How hard can it be?”. People with this attitude think IT is essentially simple. They think the problem is that stupid IT people (after all, they can’t get something simple right, so they must be stupid) do not understand business needs and therefore create the wrong IT. They want an IT advisor who is a business type that can steer that stupid IT people in the required direction.
- Unwillingness to engage with IT. I don’t understand/like IT and I’ll leave it to my IT people. They will need to speak ‘business’ to me. The same people will willingly discuss difficult legal issues with their chief legal counsel until they understand enough about it to value the advise and own the decision. They will dig into business-type details with gusto, understanding quite well that people stumble over molehills, not over mountains.
The executives who refuse to truly engage with a key element of the organisation — IT — thus come across as people keeping fingers in their ears while complaining about other people not speaking clearly to them. Not engaging with IT is either a form of abandonment or it has the effect of making uninformed decisions that can have serious negative effects — welcome to IT Disasters Anonymous (“Hello. I am John. I am a serial IT-disaster creator. Hello, John!” — I know, it’s not that bad. Besides, IT disasters are so glacial that cause and effect are seldom understood). Selecting an IT advisor ‘who understands the business’ is a logical choice for those unwilling to engage, because the problem is seen as ‘IT not understanding the business’ while the problem actually might be ‘the business not wanting to understand IT’ **).
For good IT advisors, the kind that actually really understand the technology, the phrase ‘we need an IT advisor who above all understands the business’ is a warning sign that can easily mean an environment where either or both of these reasons apply and where being an IT advisor is like being a farmer sowing seeds on hard rock. The first task of business will be turning rock into fertile ground. And you don’t know if you will get the opportunity to do so.
In other words: if you are really at home in complex IT, watch out for IT strategy/executive level jobs where ‘understanding the business’ is the key requirement***)), the job may be more of a challenge than it seems because it may be that the phrase hides a serious road block.
*) Aside: it is a common misunderstanding to think that entrepreneurs are good at risk-taking and that this is what makes them successful. I’ve read about some research, decades ago (probably in New Scientist), that tested the assumption. The outcome was surprising. Entrepreneurs were in fact less good at spotting risk, which is why they take on more. They also overestimated potential profit more. They tend to be optimists, not realists. Evolutionary processes then play a role in the economy, with some of them failing and some succeeding, the ones succeeding sometimes learning to be realists. We only pay attention to the successful ones, who took (or more to the point: ignored) the risk. [return to text]
**) In my distant past, came across a post-mortem of large failed IT-heavy initiative, where the conclusion of management was that the problem had been that IT was not engaged with the users/business as the users had never accepted the new program. ‘Not engaging the users’, however, turned out to have been a conscious management decision in the first place, as they thought such an engagement was not needed when the first phase of the project was ‘to rebuild existing functionality on a better foundation so that later new functionality could be added’. Any decent IT advisor would have told them that there was technically such a freedom of use in the old system that the formal ‘existing functionality’ was (a) only a subset of the actual functionality provided and (b) rebuilding the existing functionality would necessarily also recreate some of the technical issues that had to be solved. It was impossible to ‘rebuild the existing functionality’ it would always have been ‘ building comparable (different) functionality’, hence requiring early user involvement. The post-mortem conclusion ‘the problem was: we did not engage the users’ was therefore not the true root cause. The true root cause was ‘we did not understand IT enough to understand that we had to engage the users in an early stage’. Of course, when interviewed by consultancies, management in those situations (and there were many in those days) would blame ‘not engaging the users’ and consultancies like Gartner dutifully turned that into ‘lessons learned/best practice’, but nobody dug deep enough to notice the true root cause: a lack of IT insight. People seldom relate failing IT with poor IT knowledge. Which is pretty weird, but another illustration of the problem. [return to text]
Another project I’ve observed in my distance past made a simplistic management decision to ‘reuse’ a technology that was in fact fundamentally in technological contradiction with other technical elements. The result was that it was impossible to get the system robust and stable. After 15 years and spending approximately €150 million the initiative was shelved with nothing to show for it. This was a government project but the failure did not make a serious political ripple as nobody in parliament understood what had been going on (and the communication to parliament was rather creative with regard to the truth).
***) I’ve noticed in my past that the people who understood the most of ‘the business’ were often IT people. I remember a company that at one time did an employee quiz: who knows our business best?. The top participants came from enterprise architecture (mostly IT-related), the winner being their manager. Enterprise and solution architects in particular need to be able to understand the business very well and learn about new business environments quickly to be able to contribute to correct design decisions. If you can’t do that you’re not getting very far in this field anyway. [return to text]
Photo by Markus Spiske on Unsplash and Photo by Hunters Race on Unsplash