When working on a programming team, you need to make sure everyone on the team is aware of the changes you make. This is to ensure that everyone knows what task they're doing, what feature the rest of the team might not have to worry about, or any potential conflicts - among other reasons.

Once those changes are made, you want them reviewed. Perhaps one other developer does it, perhaps a group, or perhaps the whole team. Once approved, the changes get applied to the live application.

Adam's team has their process and it's not too different from most other software companies. Team-member Ted, however, decided that he can make changes over and over again, without telling anyone.

There were three main reasons Ted wasn't reprimanded in the beginning - the first is Ted is a talented programmer, and on a team with only a handful of programmers, that's valuable. The second reason and probably more important is Ted was programming for this company since the beginning; meaning Ted knows the inside and outside of the app. And finally Ted was the only remote employee – meaning it's harder to be direct when Ted isn't even in the building.

Ted thought he was doing the company a favor by improving the software to meet his needs. In practice, it meant the entire development team would have to fix, correct, or flat out remove everything Ted did. But since Ted didn't tell anyone, didn't correlate changes with any tickets, or even include clear commit comments, it was often difficult to know what exactly were his "just because" changes, and which were "real" features.

During their virtual standups, Ted described himself as "a teacher," showing the younger developers the way, and preparing them for their careers. He was like a teacher, but instead of following the approved curriculum, he taught what he felt best, standards be damned. He might have the best intentions, but Ted wasn't preparing them for anything but frustration.

With Ted being the only remote employee, this meant it was easy for Adam, the team-lead, to meet without Ted, and discuss what to do with Ted's constant changes. Ted couldn't simply be fired- the office politics didn't permit it. But Adam could cut his hours, and put him on tasks that didn't matter if Ted tampered with the requirements and did his own thing.

Even though Ted was warned a number of times, in terms ranging from "gentle" to "this is serious, Ted", he still didn't stop making his own changes. He still let his work interfere with other developers.

The reprimands got to the point where even Ted realized that his job was jeopardy. Still, he insisted on doing things his own way. Adam and the team tried to talk to him about it, tried to offer suggestions, but Ted was too stubborn to take his team's advice.

Adam and the team worked on an e-commerce portal, and Ted was performing these changes on the live site; bypassing all protocol. This means that customers could actually view the changes that Ted made, in real time.

Adam tried giving Ted less work, so the team wouldn't have to worry about his meddling behind the scenes as much, but Ted couldn't be stopped. The breaking point was when Ted made a change, directly merged it into master, and then published it to the live site. The change ruined mobile formatting for the features the other programmers were working on, which was annoying. But it also broke the customer's ability to purchase from the site- customers literally couldn't make purchases because of Ted's "improvements".

The team had to scramble to revert to the previous build, and then unpick Ted's many commits from the history to fully revert that feature. Adam had to let Ted go – everyone on a team needs to work together.

[Advertisement] Keep the plebs out of prod. Restrict NuGet feed privileges with ProGet. Learn more.