Has anyone here not been in similar a situation?

Sadly, I have encountered this issue SO MANY times (in the UK)...putting unsuitable (but highly thought of), people into jobs, where they have control over projects that they know absolutely nothing about....even if previously, they had done well in their specific original role (for which they might have been trained).

But that doesn't help, if they switch roles into a different sector, where they have no experience. (I think this is also known as "jobs for the boys" or "cronyism").

And it doesn't just happen in the public sector...it happens in the private sector too - as I know 2 experienced people who were overlooked for roles in companies, as the boss wanted to "reward" a "personal friend" in one job and a "relative" in another. (And both of them screwed up big-time...but kept their jobs :-( )

It's one thing to know all about DevSecOps. But what if your speciality is SecDevOps or DevOpsSec. It's all OpsSecDevSec to me.

I was once in the opposite position - along with my normal technical job I was put in charge of the group of contractors running an ICL mainframe. This mainframe was being wound down as its workload was transferred to a group of Unix systems.

As my knowledge of the mainframe and its software was minimal and had no chance of getting up to a competent level in any reasonable time, I took the decision to leave all the technical matters to the contractors and told them to see me if they needed administrative cover beyond their own authority level. This arrangement worked well until the company finally disposed of the ICL mainframe. (If I remember correctly it took me about 10 minutes a month to approve timesheets and that was about it.)

Yes, compounded by the fact that said officer has to get something into his OJAR (yearly report) and just running something competently doesn’t cut it, so cue the ‘identification of things that are wrong and must be changed’ and then you run straight into project variation and increased costs… I could be wrong of course but MoD procurement history would suggest not…

Good boss > skilled or informed boss any day because a good boss knows when to lead and when to defer to the expertise of their subordinates. Skilled bad boss is worse.

I mean that's not the only two choices, I was just saying that a good, but clueless boss isn't an automatic fail. There are worse combinations.

This article comes off as sour grapes to me, regardless of whether it has merit because it basically reads "I know best, and they didn't listen to me, so of course their decisions must be faulty, and I'm going to shame them because I'm mad."

I'm not sure about that. Sour grapes to me would be if he was fired and sent this, but he was unhappy enough to quit of his own accord. That implies that, whatever the reasons, it's not something done to fire back at the person who took his job.

As for a good boss or an informed one, a bad informed boss is certainly a problem, but in many ways an uninformed good boss is too. A good boss who doesn't know how things work might, in good faith, make promises about things that can't get done. They might pass every decision down to someone who knows what they're doing and harm organization. While a somewhat informed good boss will definitely beat a bad one, good management requires some basic level of knowledge of what the people below you are doing. Someone who lacks that knowledge is likely to be ineffective or problematic without needing managerial incompetence as well.

Seems like he speaks for most people involved in large government IT procurements. The bosses seem to think that actually understanding the nature of IT and procurement is almost a disqualification for the job.

To be fair, how would you like it if your underlings understood their jobs better than you did and you had to let them get on with it? I mean they might actually get stuff done for which you could not claim the credit.

My last boss (before retiring) was quite comfortable knowing that most of the engineers knew more about their specialty, and would let us do whatever was needed to get the job done. He trusted us, and we never let him down.

I'll never forget one meeting with a company were were doing a major refit for, where our boss took their boss to one side and let us techies thrash it out between us - one of the smoothest installs we ever did.

Oops. double post - sorry

To be fair, how would you like it if your underlings understood their jobs better than you did and you had to let them get on with it?

The real fun starts when the underlings understand their boss's job better than the boss himself.

"Large bureaucracy is slow, risk-averse, and prioritizes ass-covering over organizational goals."

Also, this comment here makes me think he doesn't really understand balancing security with other operational needs "...potentially preventing capabilities to be made available when needed whenever world events demand, many times overnight."

Security NEVER made anything more performant, available, or reliable. It can at best have no impact, but usually involves a compromise. It makes me think maybe he's the one in the wrong. The military _does_ get security, believe you me. If they were prioritizing something else, despite knowing how critical security is, maybe they're not the ones that are blind?

Or maybe it's one of the 'Agile is the messaiah' types that worship it as the savior of software development, and anyone who says there's a messy corner case (which is common in enterprises that deal with life and death) is a benighted heathen who must be made to see the light.

You don't deliver 3/4ths of a rifle and get to the trigger in the next sprint. Or accept that there will be bugs and maybe 1/1000 rounds will explode in the barrel and that's okay, because they can lodge a Bugzilla ticket if they live and we'll write a user story about it. Agile concepts help nearly every process, but not every process can go full Scrum or some type of crystal.

One of the characteristics of the military has been that it is liable to being physically attacked as it does its job. It needs to be able to defend itself.

Now it's liable to be electronically attacked as well. IT security is a significant part of the defence it needs.

Seems to me this guy has more than made his bones in the industry - someone you listen to whether you agree with everything he says or not, because he's been right more than he has been wrong.

https://enterpriseirregulars.com/69091/pillorying-marklogic-selling-disruptive-technology-government-hard-risky/

Sadly, this isn't new. Do not suffer fools quietly.