Return to Answer

I think the first flaw is in this sentence:

He reports to the Development Manager, but works more closely with the Infrastructure Manager.

Devops is a culture aiming at removing silos, if there's actual silos then he's whatever you want to name him, an engineer doing operational development, an automation expert, a developer automating infrastructure, but that's not a DevOps engineer.
In fact, Devops Engineer is not a real role, it's more a 'chapeau' as it can encompass developer, sysadmins, testers or architect working in a common team.

The main problem I see behind it is people falling in the buzzword usage of DevOps as a job title, by doing so they usually blame being alone in their field.
As you put it he's the only one doing ops in a dev team, that's not he's a DevOps engineer (whatever that could mean for his case), that's he's working in isolation because the job is presented as DevOps something or plain operational thing the other people in his team doesn't wish to work on.

Let's be honest, there will always be ops and dev, the main idea behind devops is sharing the responsibilities as such that there's no hand over of a product from dev to ops or just supply of platforms from ops to dev. The primary goal is bringing more collaboration in a team, starting to name self Devops Engineer is breaking this idea by putting in the name you can do both at the same level of expertise which is rarely true.

The first thing to do in my opinion would be to present the tools to the team, give everyone a basic knowledge on the tools and transfer the responsibility to configure/code the tools to the whole team.
The main idea behind this is moving from "the one doing the things" to "the one which support and give references implementations".

This complement the other answers by something actionnable in an easier way as a first step than a management reorganization.

I think the first flaw is in this sentence:

He reports to the Development Manager, but works more closely with the Infrastructure Manager.

DevOps is a cultural shift aiming at removing silos. If silos remain, then this engineer is whatever you want to name call him; an engineer doing operational development, an automation expert, a developer automating infrastructure - but this engineer is not a DevOps engineer.
In fact, "DevOps Engineer" is not a real role, it's more a 'chapeau' as it can encompass developers, system administrators, QA testers and architects working in a common team.

A problem I often see is that people fall into the buzzword usage of DevOps, seeing it as a job title, but they don't really understand what DevOps is. By viewing DevOps this way, they often end up isolated and feel alone, blaming failures and shortcomings on being a "lone wolf" without managerial and organizational buy-in.

As you describe it this engineer is the only one doing Ops in a Dev team. That doesn't make him a "DevOps engineer". (Whatever that means in his organization) He's working in isolation because the job is presented as "DevOps Engineer" but it seems tha other people in his team doesn't wish to work on operations.

Let's be honest, there will always be ops and dev, the main idea behind devops is sharing the responsibilities such that there's no handoff of a product from dev to ops or just supplying a platforms by ops for dev. The primary goal is bringing more collaboration into a team. Calling this role a "DevOps Engineer" is breaking this idea by suggesting in the name you can do both at the same level of expertise - which is rarely true.

The first thing to do in my opinion would be to present the operational tools to the team and give everyone a basic knowledge on the tools, then transfer the responsibility of configure/code the operational tools to the whole team. The main idea behind this is moving from "the one doing all the ops things" to "the one which supports and give references implementations to the team".

This complements the other answers by providing something actionable in an simpler way as a first step than a management reorganization.

I think the first flaw is in this sentence:

He reports to the Development Manager, but works more closely with the Infrastructure Manager.

Devops is a culture aiming at removing silos, if there's actual silos then he's whatever you want to name him, an engineer doing operational development, an automation expert, a developer automating infrastructure, but that's not a DevOps engineer.
In fact, Devops Engineer is not a real role, it's more a 'chapeau' as it can encompass developer, sysadmins, testers or architect working in a common team.

The main problem I see behind it is people falling in the buzzword usage of DevOps as a job title, by doing so they usually blame being alone in their field.
As you put it he's the only one doing ops in a dev team, that's not he's a DevOps engineer (whatever that could mean for his case), that's he's working in isolation because the job is presented as DevOps something or plain operational thing the other people in his team doesn't wish to work on.

Let's be honest, there will always be ops and dev, the main idea behind devops is sharing the responsibilities as such that there's no hand over of a product from dev to ops or just supply of platforms from ops to dev. The primary goal is bringing more collaboration in a team, starting to name self Devops Engineer is breaking this idea by putting in the name you can do both at the same level of expertise which is rarely true.

The first thing to do in my opinion would be to present the tools to the team, give everyone a basic knowledge on the tools and transfer the responsibility to configure/code the tools to the whole team.
The main idea behind this is moving from "the one doing the things" to "the one which support and give references implementations".

I think the first flaw is in this sentence:

He reports to the Development Manager, but works more closely with the Infrastructure Manager.

Devops is a culture aiming at removing silos, if there's actual silos then he's whatever you want to name him, an engineer doing operational development, an automation expert, a developer automating infrastructure, but that's not a DevOps engineer.
In fact, Devops Engineer is not a real role, it's more a 'chapeau' as it can encompass developer, sysadmins, testers or architect working in a common team.

The main problem I see behind it is people falling in the buzzword usage of DevOps as a job title, by doing so they usually blame being alone in their field.
As you put it he's the only one doing ops in a dev team, that's not he's a DevOps engineer (whatever that could mean for his case), that's he's working in isolation because the job is presented as DevOps something or plain operational thing the other people in his team doesn't wish to work on.

Let's be honest, there will always be ops and dev, the main idea behind devops is sharing the responsibilities as such that there's no hand over of a product from dev to ops or just supply of platforms from ops to dev. The primary goal is bringing more collaboration in a team, starting to name self Devops Engineer is breaking this idea by putting in the name you can do both at the same level of expertise which is rarely true.

The first thing to do in my opinion would be to present the tools to the team, give everyone a basic knowledge on the tools and transfer the responsibility to configure/code the tools to the whole team.
The main idea behind this is moving from "the one doing the things" to "the one which support and give references implementations".

This complement the other answers by something actionnable in an easier way as a first step than a management reorganization.

I think the first flaw is in this sentence:

He reports to the Development Manager, but works more closely with the Infrastructure Manager.

Devops is a culture aiming at removing silos, if there's actual silos then he's whatever you want to name him, an engineer doing operational development, an automation expert, a developer automating infrastructure, but that's not a DevOps engineer.
In fact, Devops Engineer is not a real role, it's more a 'chapeau' as it can encompass developer, sysadmins, testers or architect working in a common team.

The main problem I see behind it is people falling in the buzzword usage of DevOps as a job title, by doing so they usually blame being alone in their field.
As you put it he's the only one doing ops in a dev team, that's not he's a DevOps engineer (whatever that could mean for his case), that's he's working in isolation because the job is presented as DevOps something or plain operational thing the other people in his team doesn't wish to work on.

Let's be honest, there will always be ops and dev, the main idea behind devops is sharing the responsibilities as such that there's no hand over of a product from dev to ops or just supply of platforms from ops to dev. The primary goal is bringing more collaboration in a team, starting to name self Devops Engineer is breaking this idea by putting in the name you can do both at the same level of expertise which is rarely true.

The first thing to do in my opinion would be to present the tools to the team, give everyone a basic knowledge on the tools and transfer the responsibility to configure/code the tools to the whole team.
The main idea behind this is moving from "the one doing the things" to "the one which support and give references implementations".

I think the first flaw is in this sentence:

He reports to the Development Manager, but works more closely with the Infrastructure Manager.

Devops is a culture aiming at removing silos, if there's actual silos then he's whatever you want to name him, an engineer doing operational development, an automation expert, a developer automating infrastructure, but that's not a DevOps engineer.
In fact, Devops Engineer is not a real role, it's more a 'chapeau' as it can encompass developer, sysadmins, testers or architect working in a common team.

The main problem I see behind it is people falling in the buzzword usage of DevOps as a job title, by doing so they usually blame being alone in their field.
As you put it he's the only one doing ops in a dev team, that's not he's a DevOps engineer (whatever that could mean for his case), that's he's working in isolation because the job is presented as DevOps something or plain operational thing the other people in his team doesn't wish to work on.

Let's be honest, there will always be ops and dev, the main idea behind devops is sharing the responsibilities as such that there's no hand over of a product from dev to ops or just supply of platforms from ops to dev. The primary goal is bringing more collaboration in a team, starting to name self Devops Engineer is breaking this idea by putting in the name you can do both at the same level of expertise which is rarely true.

The first thing to do in my opinion would be to present the tools to the team, give everyone a basic knowledge on the tools and transfer the responsibility to configure/code the tools to the whole team.
The main idea behind this is moving from "the one doing the things" to "the one which support and give references implementations".