Victory! The smell of skunkworks in your office in the morning While it’s easy to start up a few, flashy new DevOps teams, releasing to production each week and flaunting the ball-and-chain of enterprise governance, scaling that change to your organisation will always be challenging, if not crushingly impossible. When it comes to scaling the skunk-works, I’m reminded of a conversation …
As a newby PM in the midst of "managing" a development project I was informed by the finance director that the engineering overhead had increased by 0.8% and so I needed to adjust my estimate to complete accordingly. I told him that it was pointless because the ETC accuracy was nowhere near 0.8% and the genuine look of astonishment on his face made me realize that me and the company weren't made to be.
Skunkworks? There was a group of 3 guys who spent most of their time inventing new ways to use conditional formatting on project reports; does that count?
Management always does their job.
It's only that, in some cases, sometimes, that job is not managing but back-stabbing, under-the-rug sweeping, and whatever else comes to their enlightened mind. Until they get fired for it, of course, which doesn't happen often enough in some cases (Uber, looking squarely at you).
"Until they get fired for it, [..]"
If by then they have been promoted several times above their level of incompetence. Then they get a "golden handshake" and just enter the rotating pool of management that flows continuously between companies.
"Often, senior developers are threatened by the prospect of sitting at a desk with “junior” developers."
In my experience it was the "junior" people who didn't want to be paired. They saw the techie greybeard as someone who had failed to get promoted to the more lucrative management roles. Instead of learning how the techie's evolved "skunk" tools worked, and why - they just wanted the latest "expert" products from the market place. Their perception was that their easy successes would then be a fast track to management jobs.
The fact was that the problems they "solved" often came back to bite us because they had failed to understand the root cause. Not that it mattered - by then they had burnished their laurels for career advancement.
It was the techie greybeard who then had to take apart their festering "solution" and solve the original problem. Senior management merely saw this as the greybeard taking a long time to solve a "new" problem.
After a few years I left them to it - allowing them to sideline me into an enjoyable retirement where any project can be done with appropriate care and consideration.
In the USofA it's called Sarbanes-Oxley and covers all material portions of a public corporation. Specifically, changes to applications that could be material to a company's financial reporting (any application of major significance) needs to go through formal testing and have formal business owner sign-off to proceed to the next step. If someone wants to fire up DevOps for immaterial applications, go for it. But if you want to make a real impact on the business as a going concern, what's the point? We're not working under Uber's "disregard all the rules and laws" playbook.
I did some work for a UK-based company which was owned by a US company. The high-paid help were briefed on Sarbanes Oxley. Briefing message: "You are responsible for what happens here and if you sign off stuff which isn't fit for purpose then you'll be in the US, wearing orange and using hairy soap."
HPH response? They pushed down acceptance/approval to the lowest level possible, including just-graduated engineers, and instigated a process that resulted in it taking weeks to get anything signed off. None of the directors would approve anything without evidence to "prove" it was someone else's fault.
I often use the company’s mobile app and it’s updated frequently,
That leads to the question 'what is wrong with it?' that it needs to be updated frequently.
One can only assume that said app is either so bug ridden to be almost unusable and/or unfinished and should never have been allowed to the wide world.
The only other possible reason is that the developers are so insecure that they have to 'fiddle' with it to make it 'better'. If it works as intended it doesn't need 'fiddling' with except to fix bugs.
Sure that's an anti-pattern, but not because you want to spread their success through the larger organisation. As if that would ever happen! The real reason is to smother the skunk-works with the corporate bureaucracy to stop them making everyone else look bad.
The most successful method of encouraging successful skunk works is to turn a blind eye to them. They are born out of the necessity of invention and lateral thinking plus experience.
Some people are natural innovators because they like solving practical problems. You can't teach that aptitude.
IIRC Tom Peters in one of his books describes that GE made many of the components for railway locomotives. A skunk works built a complete locomotive on the quiet - and GE then entered that market.
Several times in my career there have been occasions when something was suddenly needed - and a skunk works said "here's one I made earlier".
Has "skunk works" now lost the meaning popularized by Lockheed, or has Mr. C. consumed too much Kickapoo Joy Juice (q.v.) in those meetings with executives?
" sweep its arm across a messy governance table of half drank ticket queues and droning CABs, starting with a tabula rasa."
"Tabula rasa" used to be generally rendered "clean slate", but perhaps that's another of the many things that DevOps has changed. See http://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext%3A1999.04.0059%3Aalphabetic+letter%3DT%3Aentry+group%3D1%3Aentry%3Dtabula, I.II.
The mobile app, like the website doesn't actually DO anything. The mobile app (whichever one of the 14 near-duplicates it is) is the stick of lipstick organisations slather on their ERP, EDRMS and CRM pigs. It doesn't ensure a value-chain gets completed from start to finish. It doesn't take into consideration the thousands of ossified internal-policy and regulatory rules. It doesn't secure the myriad of interactions between the organisation and it's suppliers systems. Your spotty team may well have automated the build and deployment cycle of a tiny, pointless codebase, and you have therefore proven you can CTRL+C, CTRL+V tutorials and code you found on the web, but that's about it. The EA is trying to ensure your code is less crap and more corporate (thereby slowing you down) and at the same time trying to speed up the COBOL-crowd who remember all too vividly, the 600 bollockings and near-sackings over the years that they've survived because a percentage was calculated without the right number of decimal places or obscure rounding convention. They do this for the unique privilege of being criticised by everyone for everything all at the same time. Should they miraculously succeed, the "yoofs" will say they slowed them down, the old coots will say they've endangered the business operations and management won't have any idea what they've done at all.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
