I'm trying to evaluate whether or not it is a good idea to move away from a devops-style workflow to the traditional dev-then-ops (not sure what you call that).

We are a small 5 person department tucked away within a 4000 employee traditional media (eg non-digital) company. Two years ago we began building software to allow our department to significantly scale up our production. We've been very successful and the greater company is beginning to take notice. To date, we have been solely responsible for the design, development and deployment of what has become a ~10 service AWS microservice platform. Our team doesn't identify as DevOps, but without question we are living the DevOps life, with each developer intimately familiar with both the code and the system it runs on.

One of the upcoming questions we will face shortly is whether the deployment of our system should be handed over to the existing IT department for our parent company. Not surprisingly, they have strong expertise in IT, but are unlikely to become involved in the development. I would say that we have a 70/30% split between coding and infrastructure.

Our project owner (a non-technical individual) is hoping that by handing off as much work as possible to the IT team we will see a ~1:1 boost in productivity for each hour of operations work that we shed. I'm skeptical about this though. Our product is still pre-beta (though it's already a significant business asset) and in our limited experience with the IT department there are usually significant delays for things as simple as filesystem permission changes.

Right now, my ideal solution would be for the IT department to "adopt" us and allow us to continue deploying our own work, while ensuring that we meet the standards & requirements of the IT office. I'm not sure how realistic that is though. Plus it is nearly the opposite approach our project owner is advocating since it would add additional operations work in the short term.

In our situation, what are the likely pros/cons of staying with DevOps approach vs handing off IT?

I'm trying to evaluate whether or not it is a good idea to move away from a devops-style workflow to the traditional dev-then-ops (not sure what you call that).

We are a small 5 person department tucked away within a 4000 employee traditional media (eg non-software) company. Two years ago we began building software to allow our department to significantly scale up our production. We've been pretty successful and the greater company is beginning to take notice. To date, we have been solely responsible for the design, development and deployment of what has become a ~10 service AWS microservice platform. Our team doesn't identify as DevOps, but without question we are living the DevOps life, with each developer intimately familiar with both the code and the system it runs on.

One of the questions we will face shortly is what "efficiencies" are shared between us and the IT department for our parent company. Our project owner usually prefers outsourcing over in-house learning, so in our case these efficiencies probably means getting as much IT work "off our plate" as possible. Currently, I would say our team has a 70/30% split between experience in coding vs infrastructure. The IT department is solidly in the IT realm, with no visible crossover into software development.

Our project owner (a non-technical individual) is hoping that by handing off as much work as possible to the IT team we will see a ~1:1 boost in productivity for each hour of operations work that we shed. I'm skeptical about this though. Our product is still pre-beta (despite already being a significant business asset) and in our limited experience with the IT department there are usually significant delays for things as simple as filesystem permission changes.

Right now, my ideal solution would be for the IT department to "adopt" us and allow us to continue deploying our own work, while ensuring that we meet the standards & requirements of the IT office. I'm not sure how realistic that is though. Plus it is nearly the opposite approach our project owner is advocating since it would add additional operations work in the short term.

In our situation, what are the likely pros/cons of staying with DevOps approach vs handing off IT?

I'm trying to evaluate whether or not it is a good idea to move away from a devops-style workflow to the traditional dev-then-ops (not sure what you call that).

We are a small 5 person department tucked away within a 4000 employee traditional media (eg non-digital) company. Two years ago we began building software to allow our department to significantly scale up our production. We've been very successful and the greater company is beginning to take notice. To date, we have been solely responsible for the design, development and deployment of what has become a ~10 service AWS microservice platform. Our team doesn't identify as devops, but without question we are living the devop life, with each developer intimately familiar with both the code and the system it runs on.

One of the upcoming questions we will face shortly is whether the deployment of our system should be handed over to the existing IT department for our parent company. Not surprisingly, they have strong expertise in IT, but are unlikely to become involved in the development. I would say that we have a 70/30% split between coding and infrastructure.

Our project owner (a non-technical individual) is hoping that by handing off as much work as possible to the IT team we will see a ~1:1 boost in productivity for each hour of ops work that we shed. I'm skeptical about this though. Our product is still pre-beta (though it's already a significant business asset) and in our limited experience with the IT department there are usually significant delays for things as simple as filesystem permission changes.

Right now, my ideal solution would be for the IT department to "adopt" us and allow us to continue deploying our own work, while ensuring that we meet the standards & requirements of the IT office. I'm not sure how realistic that is though. Plus it is nearly the opposite approach our project owner is advocating since it would add additional ops work in the short term.

For a situation like this, what are the likely pros/cons of staying devop vs handing off IT?

I'm trying to evaluate whether or not it is a good idea to move away from a devops-style workflow to the traditional dev-then-ops (not sure what you call that).

We are a small 5 person department tucked away within a 4000 employee traditional media (eg non-digital) company. Two years ago we began building software to allow our department to significantly scale up our production. We've been very successful and the greater company is beginning to take notice. To date, we have been solely responsible for the design, development and deployment of what has become a ~10 service AWS microservice platform. Our team doesn't identify as DevOps, but without question we are living the DevOps life, with each developer intimately familiar with both the code and the system it runs on.

One of the upcoming questions we will face shortly is whether the deployment of our system should be handed over to the existing IT department for our parent company. Not surprisingly, they have strong expertise in IT, but are unlikely to become involved in the development. I would say that we have a 70/30% split between coding and infrastructure.

Our project owner (a non-technical individual) is hoping that by handing off as much work as possible to the IT team we will see a ~1:1 boost in productivity for each hour of operations work that we shed. I'm skeptical about this though. Our product is still pre-beta (though it's already a significant business asset) and in our limited experience with the IT department there are usually significant delays for things as simple as filesystem permission changes.

Right now, my ideal solution would be for the IT department to "adopt" us and allow us to continue deploying our own work, while ensuring that we meet the standards & requirements of the IT office. I'm not sure how realistic that is though. Plus it is nearly the opposite approach our project owner is advocating since it would add additional operations work in the short term.

In our situation, what are the likely pros/cons of staying with DevOps approach vs handing off IT?