3 ms·

This is a crappy situation to be in for sure, the company definitely let this linger for far too long. I'd do the following: 1. Make sure you have complete ad

This is a crappy situation to be in for sure, the company definitely let this linger for far too long. I'd do the following: 1. Make sure you have complete admin control over the git repos. 2. Clearly communicate that pushing to master/main branches will no longer be allowed, all changes need to go through the PR review process. Document this process in the same place you'd like to see the developers start documenting their work too, make sure they're aware, and ask if anyone doesn't understand how it works (branching, etc.) Also test this process yourself and make sure it works as expected. 3. After everyone has had time to review the doc and no questions have been brought up about how it works flip the switch and prevent any merges directly into master/main on all repos (in Github you can do this with branch protections.) Once the initial shock of (gasp) having to review code changes wears off, you can start adding other processes as needed, CODEOWNERS, consolidating CI/CD, etc in a similar manner. Worth noting: If this troublesome developer leaves in frustration, they're going to experience the processes you're describing pretty much anywhere else (save for a similarly dysfunctional shop) they may or may not know that too. If they're resistant to process change, perhaps they'll be resistant to job change too.

ano-ther 3y ago
Good approach. I would add to keep your manager apprised of the findings, plans for improvement, and risk mitigation should the team member decide to leave. You should also make your mind up how much disalignment the team can stomach and when you draw the line in working with that person. And talk to HR. The good ones have tools & coaching for how to handle such cases. The mediocre can at least advise on what to document in case you later decide to dismiss the person.
mindcrime 3y ago
I agree with this in principle, BUT... be reasonable, and don't go in thinking you have to "show this guy" or communicate to the team what a hardass you are. There are, in my experience, always exceptions to pretty much any policy. If you say "all commits need the PR workflow" I'd posit that that really means "for actual application code that ultimately winds up released" and nothing more. If you now try to apply that policy to every random repo with some POC, demo, experiment, or throwaway code of some sort, you're just going to piss people off needlessly. So work with the team to figure out what repos actually need this policy applied, don't just apply it blindly. Similar reasoning could be applied to most other things. Don't just go issuing wide-ranging edicts because you can, without understanding the actual downstream impact.

ano-ther 3y ago

Good approach. I would add to keep your manager apprised of the findings, plans for improvement, and risk mitigation should the team member decide to leave. You should also make your mind up how much disalignment the team can stomach and when you draw the line in working with that person. And talk to HR. The good ones have tools & coaching for how to handle such cases. The mediocre can at least advise on what to document in case you later decide to dismiss the person.

mindcrime 3y ago

I agree with this in principle, BUT... be reasonable, and don't go in thinking you have to "show this guy" or communicate to the team what a hardass you are. There are, in my experience, always exceptions to pretty much any policy. If you say "all commits need the PR workflow" I'd posit that that really means "for actual application code that ultimately winds up released" and nothing more. If you now try to apply that policy to every random repo with some POC, demo, experiment, or throwaway code of some sort, you're just going to piss people off needlessly. So work with the team to figure out what repos actually need this policy applied, don't just apply it blindly. Similar reasoning could be applied to most other things. Don't just go issuing wide-ranging edicts because you can, without understanding the actual downstream impact.