Do I hear a deafening chorus?
Has anyone here not been in similar a situation?
The US Air Force's first ever chief software officer has quit the job after branding it "probably the most challenging and infuriating of my entire career" in a remarkably candid blog post. Nicolas Chaillan's impressively blunt leaving note, which he posted to his LinkedIn profile, castigated USAF senior hierarchy for failing …
This post has been deleted by its author
The BOFH in me would tell them that its a means of charging or being charged for each sucessful SYN/ACK sent by TCP....
I have prior form in getting a technical director (technically he directed any responsibility or accountability for his ill informed decisions away from himself, for example he hired a C and a Java developer to fill two c# roles, because its all the same and uses { }, signed off on an outsourced development project because THEY would project manage it, i left 9 years ago and that 18month project still isnt testable...) to believe that ARSE*, BUM** and VDWARTS*** were widely used acronyms, and proceeded to wax lyrical about his cutting edge arse and bum stack with vdwarts to the bemused heads of IT of a well known British high street bank when he wanted to bluff his way through a risk assessment/DR meeting
*Automated Recovery System Environment
**BackUp Machine
***Virtual Desktop With Advanced RealTime Snapshots
This post has been deleted by its author
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 :-( )
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.)
Managing is an organizing and administrative role -- essentially it's secretarial. Project management shares the 'management' tittle but is a completely different type of role, one that either has deep knowledge of the work or knows how to delegate to and communicate with those that do. Management problems stem from people misunderstanding the roles, they think that being the 'boss' automatically qualifies them as an expert in anything and everything (and what technical input they do receive is invariably from people more interested in their advancement than the success of the project who know how to play him/her like a fiddle.)
So, yes, a smoothly working group should have the manager' doing minimal work, its just a bit of admin and looking for problems and fixing them before they're a crisis (having reliable team members that know what they're doing moves this along). But in real technical life a manager is also organizing and monitoring (and probably working on) one or more projects.
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…
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
Published as the Peter Principle back in 1969. People are promoted to their level of incompetence.
I think the author of the original article would differ. This is not promotion to a *level* of incompetence, but rather putting someone in charge of work in a *field* they don't know. If they're put back in charge of a similar size/budget project in their field, they'd probably do fine.
I'd like to offer a different example.
My understanding of the history is that the mastermind of Gallipoli, Churchill, was so demoralized that he resigned his commission to join the infantry and pay the price for his mistake. It doesn't seem like Churchill, the Australians, or the Turks would have ever forgotten. On the other hand, the war of 1812 was white-washed in the US for something like 150 years.
My father used to say, I do not hire experts to tell them what to do. I hire experts for them to tell me what to do.
But have since run into any number of people who hire experts to tell them what to do, including a former boss who hired me as an expert contractor to write a report on the future of certain technology and then three weeks later said 'OK I think I now know enough to tell if you were right or wrong... of course i was still hired for those 3 weeks doing nothing while he decided whether I was indeed an expert in the field he had hired me in...
It is also the way we appear to keep employing or promoting people who are dangerously incompetent ever higher up the management chain.
This becomes a self-perpetuating fiasco as the incompetent people then recruit more like themselves who can talk all the talk, answer the stupid questions asked by stupid people and so are deemed to be a great fit for the job.
Eventually it will implode but the damage will be immense and the one thing there people are good at is covering their arses. Management failings will become technical failings of the teams struggling to implement management incompetence.....
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.
I was hired to do X because I had enough knowledge / skill to do X, but I was prevented by (corporate) policies generally causes alot of sour grapes.
When you've got organizations this sort of size that has serious systemic issues often the only way to make the organization better is to throw the toys out of the pram. When you're too far down the food chain it's either don't care and walk away or make this sort of noise.
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.
Yep. It's the best way to proceed. And it's amazing how much time you can save. I've been involved in all sorts of projects, and the best ICD I've ever created was a half hour phone call with their engineer describing what was needed. Six months later integration took another half an hour. We avoided about 4 weeks of documentation.
Depends on the documentation. Lots of companies/government departments require you to create reams of documentation for each release that is completely useless as soon as it is written but which fulfills a box ticking exercise.
I think it comes from a time when releases required hundreds of manual interventions. If a system is properly architected and the release process is properly automated then there is very little which can go wrong and a lot less which needs to be documented.
This post has been deleted by its author
In a multi-faceted project, it's unlikely that the boss will know every area. I've been in charge of projects like that, where I knew one area of the project but not all. I'd like to think I managed them well, but of course you'd have to ask the people who worked for me.
To be fair ?
Let's make one thing clear : bosses are not techies.
There may be a one-in-a-million people who rise to management after having lived in helldesk, but this is more than an exception ; it's a miracle.
The rest are all manglement material who have flunked Board-level entry and haven't the faintest idea of what an IP address is, much less how to manage a firewall.
Let me give an example. I was once part of a vast administrative entity with an IT department and, at its head, an individual who's grasp of IT was the following : one day, I and my colleague were summoned to the official's office to discuss access to the Dev server and how things were not going to standard.
My colleague had access to the Dev server. I had been refused access to the Dev server.
How is it that the fucking head of IT didn't realize that before I put it on the table ?
And you want me to believe that that fucking idiot would be entitled to not appreciate that I know that he should fucking know who he granted access to what ?
Head of IT. You should definitely know who has access to what. That's not rocket science. That is your responsibility.
There may be a one-in-a-million people who rise to management after having lived in helldesk, but this is more than an exception ; it's a miracle.
For helldesk you are completely correct, but I know of enough programmers and analysts that have risen to management and higher. The advantage is that they know IT, the disadvantage is that you can't baffle them with the end product of an uncastrated, adult, male head of cattle (aka rose fertilizer).
In many professional organisations, such as accountancy firms, legal practices, and especially financial organisations such s stockbrokers partnerships, one of the partners will have authority over each of the 'housekeeping' functions, like building maintenance, IT, catering etc. They will not have personal expertise in that area (apart from actually using the results), but they will have the authority to make decisions and fire people (underlings and non-partners) under them who do not perform.
Strangely there is some confusion over 'having authority' and 'having control'. The former indicates that you can make decisions, the latter indicates that you have some actual understanding of the results of the decisions you make in the real world. If only I could think of an example in real life at the moment to sow you what I mean ...
Also, apologies, I missed off the \begin{sarcasm} and \end{sarcasm} from my final paragraph. Sorry.
“Head of IT. You should definitely know who has access to what. That's not rocket science. That is your responsibility.”
I’d truly hope that the head of IT wouldn’t know intricate config details like that, they should have many more other things to be worrying about.
Perhaps they should know that members of the same discipline should have the same access, but I’d not expect them to know individual status.
That’s like saying the ad leader should know what groups every individual is allocated in. Would be impressive when you have 100k staff and 250k domain groups.
With all due respect, a boss doesn't need to have a background in help desk ops. Pardon, how does resolving low tier tech issues help someone develop their SQL skills? Bringing someone a dongle is not a required first step to becoming a full-stack dev.
Why would this manager automatically assume that your access mimics your team member? Why would he care? If you don't have the access necessary for you to do your job, that's on you. You get in touch with someone and you get the correct access. If you are unable to get anyone to grant you that access, then you go to senior leadership, but not until you've exhausted all other options.
And I'm really not trying to beat you up at all come up but we're talking about development operations here, not help desk. Don't worry, I'm not talking shit about help desk. I'm just saying it's irrelevant to this stoyy.
I really hope my underlings know their jobs better than I do - it's why I have underlings (and I hasten to add that anyone who calls people underlings around me in anything other than playful respect is getting a bollocking rapid formal coaching session.
It has been a long time since I have been direct hands-on. I freely admit that some stuff I used to do I have forgotten, a lot has changed and I have no intention of doing a Simon (you know who you are) on a go-live. A big part of my role now is to shape and develop the team so they can not only get on without me, but they are eventually ready to step into my shoes and run a show.
But it's still nice to casually lean over the shoulder of some kid who's been sweating a problem for hours, scroll up a couple of screens and point out that one small thing they've missed.
I'm not so sure of that. It this case it's more like the normal military operational mode. They may have new toys but the mindset of senior officers is almost always "well the last war we fought we did it this way". I heard that one more than few times when I was in Marines in Vietnam.
When I worked in the defense industry after my 4 years in the military
, there was common phrase that we heard from the high ups..."What? We've never done that before!". Followed my much grumbling, refusal to think outside of their little box of experience.
Needless to say, I didn't stay working in defense very long.
Additional note: It was common to say the Marines operated under the rule of "200 years of tradition unhampered by progress". I think that actually applies (change number years as needed) to all branches of the military.
Sounds the like we're actually saying the same thing.
The "normal military mode" you describe is resistant to (or at least, suspicious of change) change. Fear of change is almost always because change is risky. That risk might be organizational (e.g., "we might lose a war if we fight it using unproven methods") or personal (e.g., "I know how to fight the old way, but what if I can't learn this new way?").
How do you fight change without looking like an obstructionist or dinosaur? In most cases, you study it to death. "I'm open to the idea, but we really need to examine how this will affect X, Y, Z etc." Which takes time, which is one reason that bureaucracies are slow.
Eventually, someone has to sign off on a project for it to go forward. For whoever does that, the last thing they see will be a bus undercarriage if said project goes badly. Hence the need to have a committee to "get buy-in from all the stakeholders," which (a) further slows down the process, and (b) provides at least partial ass cover in the event of failure.
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.
"Security NEVER made anything more performant, available, or reliable." Really?
If you can stop those crypto-currency miners running on your network edge boxes, don't you get a performance boost?
If you can stop ransomware slingers encrypting your data, doesn't your platform become more available?
If you can filter out DDoS traffic from real traffic, don't you get more reliability?
“If you can stop those crypto-currency miners running on your network edge boxes, don't you get a performance boost?”
No, if you’ve got crypto miners then you’ve lost performance, you restore performance once they’ve gone, you don’t increase performance over and above what you originally had.
“If you can stop ransomware slingers encrypting your data, doesn't your platform become more available?”
Again no, how is it any more available because you think you’ve stopped something? availability is the ability to keep using something in the event of a problem.
“If you can filter out DDoS traffic from real traffic, don't you get more reliability?”
How is it more reliable? Ddos is typically countered by having enough bandwidth available to soak up and drop the unwanted connections, typically by using services of a 3rd party mitigation service.
heard it many times and never saw it succeed. A good manager can manage anything. Nope. IMHO, based on been there, done that, a good manger may not understand technical intricate details, but does understand the field being worked in. A great manager may see their job as running interference for their staff to stop other manglement from bothering the crew doing the actual work. Had one those and the mutiskilled techs did wonders in problem resolution. Real issues were raised, timewasting was killed before it got in door. This person was an ex-tech who moved in management. I think Ben Richie in book "SkunkWorks" nailed it relating the comment made by an uniformed clerk on the inital build meeting with USAAF for what became the F117. Clerk did not care if it never worked, just wanted his paperwork.
The clever and lazy you make Chief of Staff, because he will not try to do everybody else’s work, and will always have time to think. The clever and industrious you make his deputy. The stupid and lazy you put into a line battalion, and kick him into doing a job of work. The stupid and industrious you must get rid of at once, because he is a national danger.
That is one of the major points made in the excellent (but scary) book "The Blunders of our Governments" by Anthony King and Ivor Crewe (ISBN 978-1-78074-405-6) about failures by UK governments.* Comparing the competence of ministers who move jobs frequently in the UK to ministers who are in post for several years in some European countries (such as Germany).
One comes to the conclusion that, worryingly, no-one is actually running the country, no-one has a general plan, and pretty much everything is done for political expediency rather than long term benefit (because there is always the chance that the next government will get the credit for your hard work).
*Both Conservative and Labour governments are considered, although everything is, of necessity, in hindsight, so there is little consideration of the competing events and decisions calling on ministers' attention.
There were no pros.
When he hired me, I took the job because the job requirements spanned a good page and a half and looked like it would give me great experience. The job was working with mainframes at the time. I ended up splitting and delivering reports.
When I questioned him about it, his reply was "well, I didn't know what the job would cover so I made most of it up".
That experience taught me to ask a few more questions in subsequent interviews!
This seems very common, and not just in the military.
I remember one assignment where I was supposedly in complete charge of information governance, but I had no budget, no recognised authority (even for commissioning) and there were three other people on the staff who thought they could make governance decisions independently and did. When I found I was being left uninvolved in - indeed uninformed about - major business changes affecting information governance I resigned.
My guess is that either they just wanted someone in a hot seat who could be fired when the inevitable accident happened, or, more likely, they were so darned disorganised that the executive hadn't a clue what was going on and multiple minions had taken advantage of this to build themselves little empires.
Ha, those "I could fix this in 6 months if empowered" usually denote an inmense lack of awareness of the environment. In complex environments with multitude of legacy systems 6 months is the time you need to just know what are the impacts of your changes
At least this person had the cahoonas to tell it straight, of course it will fall on deaf ears as no manager can ever be wrong.
Worked with a guy in the UK NHS who quit, he was asked to give an exit interview, it went along these lines.
Speaking to the manager
“It is obvious you have read a book on managing IT written by Steve Jobs, you are ill equipped to run an IT dept and your man management is not even at the basic level.
I have spent the last 3 weeks designing various UI and each time you say it is not good enough, I then presented you with the first one again and you said why could you not have done that in the first place.
You should go back to the accounts department where you came from, making an excel spreadsheet is not IT.”
The colleague told us this over farewell drinks.
Monday morning the manager spoke to staff explaining that out friend had left due to ill health.
The moral of the story is make sure your bosses boss is in the room when you throw the grenade.
.
The moral of the story is make sure your bosses boss is in the room when you throw the grenade.
A friend of mine (not in IT) used the nucleair option. As her final act before logging off and leaving the building for the last time she sent a carefully prepared farewell email to the entire company with all C-levels by name in the To: field. From a colleague, who lasted two weeks longer, she later learned that all managers in line above her for at least three levels were demoted for gross incompetence. A couple of months later the whole department was moved to another country.
All military postings in the UK at least are about two years long (give or take and with some exceptions.)
That's why my childhood involved getting a new friendship group and school every 18 months to two years. Quite often in a different country to the previous one. Loved it!
If a scandal in the 1980's created two year postings then how the hell did that decide my Dad's postings in the 1970s?
I can recall moving to Paderborn around 1977 and moving on to the delights of Andover in 1979. Prior to that I was a bit young to remember but Manchester in 1976/7 (UMIST for Dad) and Soltau with 7th/11th Armoured (Red Rats and Axe head). Yes, we called them Red Rats because the jerboa logo was always red or at least a dodgy pinkish colour as paint or shit quality T shirts faded - Desert Rats is cooler and will always be the official moniker and it was probably the first one.
Postings have always been about that length for probably the reason stated but the actual event(s) that caused it would have been in the 18th or 19th century.
What concerns me is that the implication here is that crucial security measures are not being taken on *military* hardware that almost certainly *will* be connected to the internet because ... well ... I've never understood why people connect the stuff they do to the internet.
All your lightbulb are belong to Chechnyan baddies - inconvenient.
All your aircraft carrier systems are belong to Chechnyan baddies - quite worrying.
DevSecOps: Only works if the devs are given sufficient training to be aware of all the appropriate security aspects to deal with in development, and as there are always new security issues to be aware of, new training regularly needed.
So DevSecOps is a nice idea, but doomed to fail as always running just to stay in the same spot, best a dev can do is follow a mandated set of good practices (good practices regularly updated and reasons why part of traing), but have to be aware its not a "cure all".
My Mom had similar issues working as an RN for the Navy. Every two years the hospital would change commanders. Each time the commander would come in with a new vision of how things should be run and created chaos. By the end of the two years they'd get almost everything back to what worked at which point someone else would come in and screw everything up all over again. Two steps forward, two steps back, it's surprising that the military functions at all.
eAbyss,
Not just the Navy, but also schools follow this process.
The same mess of re-organising how everything works and just as you are reaching some level of stability and control, the next 'Great idea' is issued from on high.
Roughly, schools cycle through the same ideas, arranged in different ways and renamed at random.
Approximately, 3-5 years before the same ideas are 'rediscovered' and reimplemented under a new guise.
Nothing is learnt as the senior politicians who drive the changes are moved from job to job or the party in power changes so change is needed to show the previous govt was 'wrong'.
Sound familiar in any way !!!???
> By the end of the two years they'd get almost everything back to what worked at which point someone else would come in and screw everything up all over again.
Isn't that how most management works? Useful work gets done despite management, not because of it. Management's job is to go to all the meetings, talk the blah, take the glory, and shirk the responsibilities, while production actually do stuff that makes money.
If only the managers would stop interfering, productivity would increase dramatically. I admit this does depend on having a workforce that has not been demoralised to the point of militancy.
The situation in Canada is similar
The combination of generalist project managers and limited duration assignments is a particularly bad one. There is a big incentive to manage for short term goals. A stream of optimistic progress reports convinces the higher ups that everything is going great while problems are papered over. With a little luck, a promotion follows before reality sets in and the next guy is the one left holding the bag.
That is the story everywhere! The posers are winning. They come in say that they can manage a project without IT experience and convince upper management that they can speed up a project. Once it's done on DEVSECOP's side, the PM's get credit, and get to hire more PMs. They're like f'ing Tribbles! They keep multiplying.
There is an idea that there is a kind of experience or training, than makes someone qualified to lead any kind of activity, without having the faintest idea about how that activity is performed. As one might imagine, this can lead to some practical difficulties, such as the manager ordering you to do something that defies the laws of physics. A great deal depends on the basis of the manager's authority. A good manager has authority because he knows what he is talking about. A bad manager threatens all sort of sanctions for disobedience.
such as the manager ordering you to do something that defies the laws of physics
------------------------
Hey stop talking about Malcolm Turnbull former PM of Australia (and reputedly the smartest man in the room, any room - just ask him)... Anybody remember "The laws of Australia overrule the laws of mathematics"
In fairness to the UK MOD, the lead on most operational requirements is in the hands of military officers, usually with a technical background commensurate with the field they are working in, because they represent the user on the ground, be it a soldier, sailor or airman. They are termed "Project sponsors'. Project management lies entirely within the Defence Procurement Agency - professional civil servants, almost entirely devout of military. The sponsor holds the purse-strings, subject to the whims of the MOD's tri-service Office of Management and Budget (or whatever it is known as these days, I've been away from that world for rather a long time). Steering a project through tends to be a triangular process between the sponsor (confirming the operational requirement still exists and is being met by the project), the project manager and whatever outside agency / cormpany is dealing the practical side, such as Qinetiq. BAE Systems etc. A lack of technical knowhow at the management level is rarely the problem, I suggest. Political judgement? maybe not so much.