I stopped reading the moment I reached the D word
Another DevOps article. Can we have something more interesting with a more substantial IT angle please?
Nudge theory – brainchild of Richard Thaler, a professor of behavioural science and economics at the University of Chicago – uses positive reinforcement and indirect suggestion to influence behaviour. For example, in a supermarket or canteen placing healthy food on display at eye level rather than banning sales of junk food. …
"Free lunch!"
"Game room!"
"Pizza Fridays!"
"Onsite haircuts!"
etc.
All to attract youth, who don't know this means they're making minor concessions to accommodate keeping people there night and day.
The article is attempting to fix one of the inherent flaws in their youth only hiring, their subservience to their learning curve. They don't have space to innovate, when they're on slow path discovering basics of collaboration, robust design, etc. And, nobody makes good decisions when overtired, particularly chronically overtired.
Management manufactures business buzzwords EXPERIENCED tech professionals knew years ago. Then business spins certification factories around them. You too can be a Scrum Master! Project Manager! etc. etc. And then the truly clueless hire the latest fade certified.
"I don't know what a Data Analyst is, but I'm sure we need one!"
Well that's not going to happen in vast swathes of the UK IT Industry. The PHB's are too busy getting rid of people and sending their jobs to S. Asia.
Then there is HMG itself telling the contractors based here that they are really shadow employees and IR35 is coming to get you.
Who needs this DevOps snake oil anyway? This time next year there won't be much industry left to employ it. Better start learning German I think as my Russian won't be of any use as long as Putin is in power.
"wherever possible we want our teams at the FT to migrate to Amazon Linux, because it saves us money – and we have a website that shows each team how much they would save"
Aha. So instead of telling the team to migrate to AWS - which would be old-fashioned top-down management - you drop not-so-subtle hints that they should do so. Also include implied threats if they don't - in this case, budget problems.
Let's have a new buzzword for this: Passive-Aggressive Management, or PAM for short.
Make Things Easy / Politicians
The antithesis to this is if you don't want someone to do something, e.g. claim a tax refund, you make it as discouraging as possible.
Web forms that show you the new question only after you have answered the previous one, so you have to keep bothering the same person over and over again for the next answer.
Confusing instructions on web forms.
Long phone calls on hold with irritating music.
Being referred from one phone number to another.
That was my morning just wasted, and I'm sure that the Sir Humphreys of this world have big smug grins on their faces.
well, a positive example of this 'make it easy' etc. principle is how the city of San Diego handles its recycling program, which effectively pays for itself (as I understand it) with items tossed in the blue cans.
All they did was give EVERYONE a blue trash can to put out every other week with recyclable materials.
Now I find I'm filling the blue can, and rarely put out the black one [normal trash] by comparison.
So recycling gets done on a massive scale, it benefits the city, trash doesn't fill up the landfills so much any more, and it is SO easy to do as a citizen, because you just toss the recyclable thing into the blue can instead of the black one. [they also give you a pretty long list of things you can recycle, and a trash calendar indicating which weeks to put the blue can out on the curb].
Anyway, I think this is a good example of the principles discussed in the article being applied. OK it's not IT, thus icon, but I thought it was worth "sharing". heh.
Positive reinforcement is much older than 10 years. Some guy named Pavlov who liked dogs or some such.
Back in the mid 90's my supervisor decreed all user documentation would be rewritten "in the positive". No more "no" or "do not". Instead of saying "do not use weak passwords" you say "only use strong passwords".
The end result is a much stricter set of rules. The docs become "everything restricted, but here's what you may do" vs "nothing is restricted, but don't do these specific actions". The positive docs inherently define allowed system operations.
Actually worked too. Fewer calls to the helpdesk. Fewer instances of updating the docs because a user found a new "do not". Users bent on circumventing the rules could no longer hide behind the docs. Them saying "the docs didn't say I couldn't" became us saying "the docs didn't say you could".
When we did update the docs it was usually to add a new feature or empower users with a new privilege as opposed to applying new restrictions. It's still a philosophy I follow today. Document in the positive.
It's very hard to generalise about this, because every software package is different, but if you document it as "do this", then effectively your software now does only that. Easier to support? - sure, because 80% of people stop trying to use it, because what they want to do is something slightly different.
I've been in the same position - for years I was the documentation guy at a small software company. My bosses were forever telling me to write the process to be followed. But what that left out was, basically, all the options. I'd end up documenting one very specific workflow, out of several hundred such options that the software would support. There were fewer questions of the form "how do we do this?", but many more of "what does this button do?"
Hah, we have these. In our US office, they have a party on the first Friday of every month, everyone knocks off at 3pm, there is some booze and nibbles and often a theme or gimmick, karaoke one month, hot dog stand the next month etc etc.
In the London office, we started doing the same. After 9 months, it changed from monthly to quarterly. The budget got reduced to the point we couldn't even afford proper food, just crisps. Our last "quarterly" party was over 8 months ago because they defined the end of financial year company drinks as one, and the Christmas party as another.
Our HR manager in London was one of those delightful old dinosaurs who believed that fun was something that can be ordained. If you chose not to partake in the festivities, you couldn't go home early, even to work from home. Nope, you had to sit there, 20m from the party, unable to work because of the noise. She would be on the door making sure you didn't leave early...
"We also encourage people to talk about things that have worked for them, in lightning talks or blog posts. When we share information we can show how easy it is to do something and show what people can gain from it."
Until you're flooded with notifications saying that XYZ has responded to ABC's post - and promptly tune them all out... even the useful ones
"We started asking developers to think about things like monitoring and resilience. It's hard to tell a team that they may be woken up at 2am if it breaks. You have to give your teams a level of power to take decisions."
How about the business - not the developers - deciding what level of resilience they want and are willing to pay for... and specifying it in the requirements? You do have requirements? Ohhh....
"Sarah Wells, principal engineer and platform tech lead at the Financial Times, is a passionate advocate and has been banging the drum for Nudge at various DevOps-themed events."
Let us now marvel at the new wisdom presented to us humble servants by this noble sage.....
"We started asking developers to think about things like monitoring and resilience"
Yep, devs are idiots and never think about such things.
"It's hard to tell a team that they may be woken up at 2am if it breaks."
Well, nobody in IT has ever expected that this might happen.
"You have to give your teams a level of power to take decisions"
The power of being able to decide to get the work done well without listening to the unnecessary distraction of the bullshit you spout would be welcome.
""It's about saying to people if you choose this database, we've made it easy for you to use".
What, you mean like employing an experienced database team, and developers who understand databases? Which is what you have to do if you need to use databases. Hmm. starting to see someone who's not too experienced in IT learning a bit about things and believing that she's made a whole load of original gosh wow new insights that she just HAS to share with the world.
"And be customer focused – make sure people know who to contact, she adds."
Shit, our organisation needs to be somehow organised?
"together with granular insights into which application and infrastructure changes are causing problems."
Thank you for inventing incident / change management systems and processes just now. By yourself. Nobody could ever have thought of THIS before ould they?
"developer tools startup Paddle, dashboards of "contextually relevant" information help focus minds on key metrics before they become a problem."
Oh great, a load of useless metrics to distrract me from development work. At least his company's name implies that it will be sold to customers whose poor IT management has led to them finding themselves up Shit Creek and desperately looking for a means of escape. And again, the idea seems to be that of relying on a product or snake oil philosophy to solve problems rather than using experienced people who ignore all this sort of bullshit and just succeed in delivering good quality work because they really know what they're doing.
"gamifying development can help inject a sense of competition into processes and nudge engineers to achieve higher "scores" across important metrics"
Attention nudge evangelists : any talented developers you have will leave the moment you try to foist bullshit such as this on them.
"firstly, attract people's attention so they know what you are asking them to do. Then you need to explain why they should want to do this".
How about you tell me what needs doing, and I do it because it's my job to?
"we want our teams at the FT to migrate to Amazon Linux, because it saves us money – and we have a website that shows each team how much they would save," Wells says."
Well if you'd just migrated them to Linux and told them to use it, you would have saved even more money.
I can't go on any further with this nonsense, IT at the FT was obviously expensive and disorganised, they improved things a little and now they think they've miraculously\ discovered the "secret" of effective IT and wish to share it with the world, but have, in fact, publicly embarassed themselves with this buzzwordy restating of the trivially obvious.
"principal engineer and platform tech lead"
It's the "engineer" and "tech lead" bit that's puzzling. People without any tech background coming into IT in management roles and spouting this stuff is nothing new but the titles suggest someone who actually does have that background. Or is it just how they label managers over there?
"It's the "engineer" and "tech lead" bit that's puzzling."
One insane company/department I worked for declared one of their two interns "tech lead", and left it in that state after hiring a bank of experienced engineers, to work for this lead. The task, WAY out of his depth.
"It's hard to tell a team that they may be woken up at 2am if it breaks."
Well, nobody in IT has ever expected that this might happen.
I *hope* your response is sarcasm. Not my current job, but the one before it, I had several calls from the data centre in their late evening, which of course was about three am British time since the data centre was in New York, and the possibility of such calls was part of the package. (Of course my response was normally "back it out and I'll work on a fix once I'm in the office" and it was often times not actually my fault it broke.)
I was once called up at 4am by someone in our China office telling me that something was broken. I was not best pleased, my role does not include out of hours support, and I spent about 5 minutes just shouting down the phone at her "Do you know what time it is in London?" over and over again.
Nowadays, they call someone else, who then decides if its worth waking me :)
"gamifying development can help inject a sense of competition into processes and nudge engineers to achieve higher "scores" across important metrics"
I dunno, the level of interest our proposed move to github corporate is generating because people will be able to put badges on their repos is scaring me slightly. Like, seriously, this is why you want to do all this work? For BADGES?
We don't need no steenkin badges
> "We started asking developers to think about things like monitoring and resilience"
> Yep, devs are idiots and never think about such things.
Actually, asking developers to think about such things is a very smart thing to do. Not because devs are idiots. But because devs take the requests from the requestors, e.g. The Business, whom are not always cognizant about putting in requests about monitoring, resilience or security.
By explicitly telling the devs to think about such things, you put those on the requirements lists, and the devs can now work their magic to flash out what exactly is needed to be implemented.
When requirements are not specificified, that's when things go bad: requestors will assume that those are "built in" by default and they don't have to bother mentioning them; devs will assume that if something was not mentioned, then it's not needed. Assumptions all around, which we all know how well they work out...
The dictionary at my desk derives it "< Yidd nudyen, to be tedious, bore < Russ nudnii, tedious" and defines it as "to keep urging, asking, etc. in an annoying way; nag."
Now, I had understood it as a noun, one who noodges. But either way, it's as good a theory as any for IT consulting.
Seneca or was it Marcus Aurelius remarked that good laws should be easy to follow. Laws to do the right should be easy and to do wrong made hard. Seems the bureaucrats making taxation laws have it backwards. So user documentation and application design guidelines have old precedent
the whole thing falls on its arse when you have incompetent staff. In the rarefied Mgmt world they don't have to deal with the dickheads they've hired that have to be carried by the rest. This leaves precious little time to do the real work because you're hand holding, teaching fundamentals and fire fighting the fuckups they make. Most of the time you want them to do nothing as it's less painful. Oh yes, and I know, 'you should spend time training them and building systems that caters for the lowest common denominator so they can't makes mistakes'. Well FO, most leave quickly once they're rumbled, to be replaced by someone of equal or worse incompetence (but cheap) and the cycle starts again. In between you're having this DevPlops and all the other jizz thrown at you like it's gong to be a panacea for the stupid Mgmt decisions that created the problems in the first place, such as siloing everyone, not investing in training, constantly ratcheting down the budget