3 added detail
source | link

Background: I have 10+ years of experience in management, 19 years working in an IT environment, and my current role of 2 years is part of a development team.

You may be right about how some developers may react to having their work checked, but as you appear to have a technical background and are using technical solutions to implement such checks I think you will probably be fine.

Development is only a part of my job, so I may be way less technical in my answer than some others, but I've seen my own environment change from one where there were almost no controls in place and developers were in pockets around a large organisation, developing with complete autonomy in their own style, to a properly controlled environment using Git repositories, version control etc. These things were quickly embraced by developers, because the one thing you can say about most developers is that they love keeping up to date with the latest tools. Having control measures brings a measure of administrative burden, but also many benefits, and as a technology in itself is pretty "cool" :) The same may well be true of you introducing things like SonarQube, the developers may love it.

My advice would be:

1. Make it all about the code, not about the individuals.
Make it clear from the start and in all you do that your role there is to oversee the quality of the code, not expose underperforming developers.

2. Be technical. But don't bluff
I've seen it dozens of times - people come to work in an IT environment and they are so scared of knowing less than everybody else they try and bluff their way through tech talk. Don't. You only end up looking stupid. Everybody has their strengths and weaknesses, so be assertive about what you do know, but honest about what you don't. Invite people to help you fill in any gaps in your knowledge. Many developers love an opportunity to speak about what they know, and you'll come over more approachable if you're humble enough to admit you don't know something.

3. Turn any new measures or controls you introduce into "personal development opportunities".
Many other organisations already have in place many of the measures that you will introduce. So rather than make them feel like you are introducing administrative burdens on them, "sell" the changes to them as something that will develop them personally. If they go for a new job elsewhere in the future, their experience here will be a big decider. Being able to say they have worked in a properly controlled environment with QA checking in place is a feather in their cap, so to speak.

4. Maintain your authority
Balance all of the above with maintaining the level of authority expected of you within this role. Managers who try to be friends with their staff usually find their authority is undermined. Although you may not be a line manager to the developers, you have a job to do, so make sure they don't prevent you from doing it. Sure, your stated goal is to avoid becoming a "nitpicker" and irritating the people you work with, but career-wise you may want to be more attentive to how you fulfil the expectations of your role and please your bosses rather than being accepted by the developers as "one of them" when actually you have a different and distinct role.

Background: I have 10+ years of experience in management, 19 years working in an IT environment, and my current role of 2 years is part of a development team.

You may be right about how some developers may react to having their work checked, but as you appear to have a technical background and are using technical solutions to implement such checks I think you will probably be fine.

Development is only a part of my job, so I may be way less technical in my answer than some others, but I've seen my own environment change from one where there were almost no controls in place and developers were in pockets around a large organisation, developing with complete autonomy in their own style, to a properly controlled environment using Git repositories, version control etc. These things were quickly embraced by developers, because the one thing you can say about most developers is that they love keeping up to date with the latest tools. Having control measures brings a measure of administrative burden, but also many benefits, and as a technology in itself is pretty "cool" :) The same may well be true of you introducing things like SonarQube.

My advice would be:

1. Make it all about the code, not about the individuals.
Make it clear from the start and in all you do that your role there is to oversee the quality of the code, not expose underperforming developers.

2. Be technical. But don't bluff
I've seen it dozens of times - people come to work in an IT environment and they are so scared of knowing less than everybody else they try and bluff their way through tech talk. Don't. You only end up looking stupid. Everybody has their strengths and weaknesses, so be assertive about what you do know, but honest about what you don't. Invite people to help you fill in any gaps in your knowledge. Many developers love an opportunity to speak about what they know, and you'll come over more approachable if you're humble enough to admit you don't know something.

3. Maintain your authority
Balance all of the above with maintaining the level of authority expected of you within this role. Managers who try to be friends with their staff usually find their authority is undermined. Although you may not be a line manager to the developers, you have a job to do, so make sure they don't prevent you from doing it. Sure, your stated goal is to avoid becoming a "nitpicker" and irritating the people you work with, but career-wise you may want to be more attentive to how you fulfil the expectations of your role and please your bosses rather than being accepted by the developers as "one of them" when actually you have a different and distinct role.

Background: I have 10+ years of experience in management, 19 years working in an IT environment, and my current role of 2 years is part of a development team.

You may be right about how some developers may react to having their work checked, but as you appear to have a technical background and are using technical solutions to implement such checks I think you will probably be fine.

Development is only a part of my job, so I may be way less technical in my answer than some others, but I've seen my own environment change from one where there were almost no controls in place and developers were in pockets around a large organisation, developing with complete autonomy in their own style, to a properly controlled environment using Git repositories, version control etc. These things were quickly embraced by developers, because the one thing you can say about most developers is that they love keeping up to date with the latest tools. Having control measures brings a measure of administrative burden, but also many benefits, and as a technology in itself is pretty "cool" :) The same may well be true of you introducing things like SonarQube, the developers may love it.

My advice would be:

1. Make it all about the code, not about the individuals.
Make it clear from the start and in all you do that your role there is to oversee the quality of the code, not expose underperforming developers.

2. Be technical. But don't bluff
I've seen it dozens of times - people come to work in an IT environment and they are so scared of knowing less than everybody else they try and bluff their way through tech talk. Don't. You only end up looking stupid. Everybody has their strengths and weaknesses, so be assertive about what you do know, but honest about what you don't. Invite people to help you fill in any gaps in your knowledge. Many developers love an opportunity to speak about what they know, and you'll come over more approachable if you're humble enough to admit you don't know something.

3. Turn any new measures or controls you introduce into "personal development opportunities".
Many other organisations already have in place many of the measures that you will introduce. So rather than make them feel like you are introducing administrative burdens on them, "sell" the changes to them as something that will develop them personally. If they go for a new job elsewhere in the future, their experience here will be a big decider. Being able to say they have worked in a properly controlled environment with QA checking in place is a feather in their cap, so to speak.

4. Maintain your authority
Balance all of the above with maintaining the level of authority expected of you within this role. Managers who try to be friends with their staff usually find their authority is undermined. Although you may not be a line manager to the developers, you have a job to do, so make sure they don't prevent you from doing it. Sure, your stated goal is to avoid becoming a "nitpicker" and irritating the people you work with, but career-wise you may want to be more attentive to how you fulfil the expectations of your role and please your bosses rather than being accepted by the developers as "one of them" when actually you have a different and distinct role.

2 grammar
source | link

Background: I have 10+ years of experience in management, 19 years working in an IT environment, and my current role of 2 years is part of a development team.

You may be right about how some developers may react to having their work checked, but as you appear to have a technical background and are using technical solutions to implement such checks I think you will probably be fine.

Development is only a part of my job, so I may be way less technical in my answer than some others, but I've seen my own environment change from one where there were almost no controls in place and developers were in pockets around a large organisation, developing with complete autonomy in their own style, to a properly controlled environment using Git repositories, version control etc. These things were quickly embraced by developers, because the one thing you can say about most developers is that they love keeping up to date with the latest tools. Having control measures brings a measure of administrative burden, but also many benefits, and as a technology in itself is pretty "cool" :) The same may well be true of you introducing things like SonarQube.

My advice would be:

1. Make it all about the code, not about the individuals.

Make
Make it clear from the start and in all that you do that your role there is to oversee the quality of the code, not expose underperforming developers.

2. Be technical. But don't bluff

I've
I've seen it dozens of times - people come to work in an IT environment and they are so scared of knowing less than everybody else they try and bluff their way through tech talk. Don't. You only end up looking stupid. Everybody has their strengths and weaknesses, so be assertive about what you do know, but honest about what you don't. Invite people to help you fill in any gaps in your knowledge. Many developers love an opportunity to speak about what they know, and you'll come over more approachable if you're humble enough to admit you don't know something.

3. Maintain your authority
Balance all of the above with maintaining the level of authority expected of you within this role. Managers who try to be friends with their staff usually find their authority is undermined. Although you may not be a line manager to the developers, you have a job to do, so make sure they don't prevent you from doing it. Sure, your stated goal is to avoid becoming a "nitpicker" and irritating the people you work with, but career-wise you may want to be more attentive to how you fulfil the expectations of your role and please your bosses rather than being accepted by the developers as "one of them" when actually you have a different and distinct role.

Background: I have 10+ years of experience in management, 19 years working in an IT environment, and my current role of 2 years is part of a development team.

You may be right about how some developers may react to having their work checked, but as you appear to have a technical background and are using technical solutions to implement such checks I think you will probably be fine.

Development is only a part of my job, so I may be way less technical in my answer than some others, but I've seen my own environment change from one where there were almost no controls in place and developers were in pockets around a large organisation, developing with complete autonomy in their own style, to a properly controlled environment using Git repositories, version control etc. These things were quickly embraced by developers, because the one thing you can say about most developers is that they love keeping up to date with the latest tools. Having control measures brings a measure of administrative burden, but also many benefits, and as a technology in itself is pretty "cool" :) The same may well be true of you introducing things like SonarQube.

My advice would be:

1. Make it all about the code, not about the individuals.

Make it clear from the start and in all that you do that your role there is oversee the quality of the code, not expose underperforming developers.

2. Be technical. But don't bluff

I've seen it dozens of times - people come to work in an IT environment and they are so scared of knowing less than everybody else they try and bluff their way through tech talk. Don't. You only end up looking stupid. Everybody has their strengths and weaknesses, so be assertive about what you do know, but honest about what you don't. Invite people to help you fill in any gaps in your knowledge. Many developers love an opportunity to speak about what they know, and you'll come over more approachable if you're humble enough to admit you don't know something.

Background: I have 10+ years of experience in management, 19 years working in an IT environment, and my current role of 2 years is part of a development team.

You may be right about how some developers may react to having their work checked, but as you appear to have a technical background and are using technical solutions to implement such checks I think you will probably be fine.

Development is only a part of my job, so I may be way less technical in my answer than some others, but I've seen my own environment change from one where there were almost no controls in place and developers were in pockets around a large organisation, developing with complete autonomy in their own style, to a properly controlled environment using Git repositories, version control etc. These things were quickly embraced by developers, because the one thing you can say about most developers is that they love keeping up to date with the latest tools. Having control measures brings a measure of administrative burden, but also many benefits, and as a technology in itself is pretty "cool" :) The same may well be true of you introducing things like SonarQube.

My advice would be:

1. Make it all about the code, not about the individuals.
Make it clear from the start and in all you do that your role there is to oversee the quality of the code, not expose underperforming developers.

2. Be technical. But don't bluff
I've seen it dozens of times - people come to work in an IT environment and they are so scared of knowing less than everybody else they try and bluff their way through tech talk. Don't. You only end up looking stupid. Everybody has their strengths and weaknesses, so be assertive about what you do know, but honest about what you don't. Invite people to help you fill in any gaps in your knowledge. Many developers love an opportunity to speak about what they know, and you'll come over more approachable if you're humble enough to admit you don't know something.

3. Maintain your authority
Balance all of the above with maintaining the level of authority expected of you within this role. Managers who try to be friends with their staff usually find their authority is undermined. Although you may not be a line manager to the developers, you have a job to do, so make sure they don't prevent you from doing it. Sure, your stated goal is to avoid becoming a "nitpicker" and irritating the people you work with, but career-wise you may want to be more attentive to how you fulfil the expectations of your role and please your bosses rather than being accepted by the developers as "one of them" when actually you have a different and distinct role.

1
source | link

Background: I have 10+ years of experience in management, 19 years working in an IT environment, and my current role of 2 years is part of a development team.

You may be right about how some developers may react to having their work checked, but as you appear to have a technical background and are using technical solutions to implement such checks I think you will probably be fine.

Development is only a part of my job, so I may be way less technical in my answer than some others, but I've seen my own environment change from one where there were almost no controls in place and developers were in pockets around a large organisation, developing with complete autonomy in their own style, to a properly controlled environment using Git repositories, version control etc. These things were quickly embraced by developers, because the one thing you can say about most developers is that they love keeping up to date with the latest tools. Having control measures brings a measure of administrative burden, but also many benefits, and as a technology in itself is pretty "cool" :) The same may well be true of you introducing things like SonarQube.

My advice would be:

1. Make it all about the code, not about the individuals.

Make it clear from the start and in all that you do that your role there is oversee the quality of the code, not expose underperforming developers.

2. Be technical. But don't bluff

I've seen it dozens of times - people come to work in an IT environment and they are so scared of knowing less than everybody else they try and bluff their way through tech talk. Don't. You only end up looking stupid. Everybody has their strengths and weaknesses, so be assertive about what you do know, but honest about what you don't. Invite people to help you fill in any gaps in your knowledge. Many developers love an opportunity to speak about what they know, and you'll come over more approachable if you're humble enough to admit you don't know something.