Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
A few years back, I wrote here that specialists—particularly infrastructure specialists—were not going anywhere.
I think it is worth updating that prediction and reminding you all that specialists across the bulk of DevOps subdomains are still necessary—even if you have broken down their silos.
Spend time in any of the variety of places that DevOps folks hang out and listen to/read what they actually say. When they express their sentiments as a real-time activity, the idea that we made one team responsible for most, if not all, of an application’s life cycle seems rather brutal.
In most industries, we have increasing specialization as complexity increases. Even if it was allowed, most carpenters are not qualified to do plumbing or electrical work. Oh, most know the basics and could do it in a pinch, but they aren’t the expert that the plumber or electrician is. IT, for the last many years, has tried to do the opposite, with a decent rate of success. But practicality wins out over rigidity to make that success.
We still have specialists. And you should ignore people that suggest they need to go away. The situation is already bad enough without having a person you can turn to for help with a harsh issue in this language, or on that piece of networking gear. While some of this—language specialists are the easy example—is merged into a DevOps team, some of them—network admins, for instance—only partially are. The networking within/between containers is often handled by the DevOps team (using one set of specialties), while the networking that allows all of the organization to run is still handled by operations. But I can’t think of an org I deal with regularly that doesn’t house these specializations somewhere.
This is one of the things that has traditionally held back low-code/no-code solutions—they assume these specializations and will require specialists in whatever the underlying technologies are when things inevitably go wrong. The same is true (to a lesser extent) of DevOps, AI and automation. Someone has to know what is going on underneath—they must have specialized knowledge—in order to fix it when things go wrong.
Remember, you are asking your DevOps teams to be both Jack of all trades and master of some. That is a recipe for failure, but DevOps is designed to withstand or overcome failure in short order, so I only mention this so you understand why new hires seem wild-eyed at times and old hands seem jaded—there is a lot going on that they’re mastering and remastering.
So, stand up if you’re one of the “sailing against the wind” crowd. Be proud you’ve managed to thrive in an environment with a ton of specialist parts and make sure you know who to ask for help when something goes wrong and you end up out of your depth. Even if the answer to “Who can I ask for help?” ends up being “Learn it for yourself and then be prepared to help others,” you’ll rock it either way and the rest of us who have struggled through it feel your pain and respect your work. So, thanks—for those who’ve never experienced it, but rely upon your work.
