5 ms·

I don't know if you're right or not, but I do think your hesitancy mirrors why a lot of organizations are unable to adopt DevOps fully: many people don't want t

I don't know if you're right or not, but I do think your hesitancy mirrors why a lot of organizations are unable to adopt DevOps fully: many people don't want to wear a bunch of hats. They just want to do their one thing, and I can't really blame them.

tremon 4y ago
But I don't think the original DevOps (TM) specified that every person was required to work on every part of the stack? Just that you need to have full-stack skills and responsibilities within the same team? That said, I probably wouldn't want to hire someone with just one hat. It's ok to have a preferential hat, it's not ok to refuse to wear any other.
- BlargMcLarg 4y ago
  This sounds like a manager's ideal. It's a luxury to demand people wear multiple hats up to the point the market allows you to turn the luxury into a commonality. If it was up to bosses, they'd rather have jokers ready to switch from customer support, to development, to sales, and back. It's ok until the market decide it is no longer ok. So far, it looks like all these "hats" are complicated enough for the average to make the market think twice about demanding that combination of breadth and depth of skills.
- 0x457 4y ago
  > But I don't think the original DevOps (TM) specified that every person was required to work on every part of the stack? Just that you need to have full-stack skills and responsibilities within the same team? Then you have Ops person integrated in every dev team/squad, then those Ops people have their own meetings to talk about Ops things. Then there aren't enough Ops people to staff every dev team (maybe they are on vacation, perhaps just not enough in general), so they start sharing them. Next they need to work on some special Ops tasks, so they want to have their own board. Oops, now you have Ops team. The point of DevOps is that the team is responsible for code being shipped, and after they shipped it, so everyone needs to know how to work in the stack that runs your app (Kubernetes, Nomad, AWS Beanstalk, bare-metal with Ansible or whatever it is you use). That means devs don't go to some other team to fix their CI or CD pipeline. I worked in a company that was doing DevOps, we had no Ops team, we had a few people who only worked on infra, but they were part of our team. We didn't call it anything, it was just how to work, about 3/4 of the team was capable of setting up infrastructure and working on Jenkins. I also worked in the company that "did DevOps" had a "DevOps team" and devs knew absolutely nothing about what happens to their code after they did `git push` (that if they knew how to do `git push` without asking "DevOps team"). Another company "for sure did DevOps right", they didn't have "DevOps team" instead they had "Infra team" and infra team was responsible for bare metal provisioning. Devs could write CI pipelines and stuff. However, devs had zero responsibility for code after they shipped it - it was infra team that would be woken up by nightly Pager Duty alert.

tremon 4y ago

But I don't think the original DevOps (TM) specified that every person was required to work on every part of the stack? Just that you need to have full-stack skills and responsibilities within the same team? That said, I probably wouldn't want to hire someone with just one hat. It's ok to have a preferential hat, it's not ok to refuse to wear any other.

BlargMcLarg 4y ago
This sounds like a manager's ideal. It's a luxury to demand people wear multiple hats up to the point the market allows you to turn the luxury into a commonality. If it was up to bosses, they'd rather have jokers ready to switch from customer support, to development, to sales, and back. It's ok until the market decide it is no longer ok. So far, it looks like all these "hats" are complicated enough for the average to make the market think twice about demanding that combination of breadth and depth of skills.
0x457 4y ago
> But I don't think the original DevOps (TM) specified that every person was required to work on every part of the stack? Just that you need to have full-stack skills and responsibilities within the same team? Then you have Ops person integrated in every dev team/squad, then those Ops people have their own meetings to talk about Ops things. Then there aren't enough Ops people to staff every dev team (maybe they are on vacation, perhaps just not enough in general), so they start sharing them. Next they need to work on some special Ops tasks, so they want to have their own board. Oops, now you have Ops team. The point of DevOps is that the team is responsible for code being shipped, and after they shipped it, so everyone needs to know how to work in the stack that runs your app (Kubernetes, Nomad, AWS Beanstalk, bare-metal with Ansible or whatever it is you use). That means devs don't go to some other team to fix their CI or CD pipeline. I worked in a company that was doing DevOps, we had no Ops team, we had a few people who only worked on infra, but they were part of our team. We didn't call it anything, it was just how to work, about 3/4 of the team was capable of setting up infrastructure and working on Jenkins. I also worked in the company that "did DevOps" had a "DevOps team" and devs knew absolutely nothing about what happens to their code after they did `git push` (that if they knew how to do `git push` without asking "DevOps team"). Another company "for sure did DevOps right", they didn't have "DevOps team" instead they had "Infra team" and infra team was responsible for bare metal provisioning. Devs could write CI pipelines and stuff. However, devs had zero responsibility for code after they shipped it - it was infra team that would be woken up by nightly Pager Duty alert.