How do I politely tell a coworker to only focus on his portion of the work?

Question

I've been working on a software project for a few months now with a very small team (and by small, I mean there was an extended period of time where I was the only developer). Our working dynamic is excellent for the most part, as each developer has a different sector that they work in (frontend, backend, database, etc.) and there's very little overlap, so conflicts are minimal.

Recently we brought another developer in to do work in another area on the project, and thus far their work has been great. However, they are starting to reach out and alter code in other people's spaces, including my own. While the code they're writing isn't broken, it introduces some clashes, such as when they started rewriting some of the frontend/backend architecture without consulting anyone.

The biggest benefits of having each person "own" a certain portion of the code is that 1) everything in that portion of the code has a similar logic and style to it, making it more easy to understand, and 2) the person working in that area can be sure they have absolute understanding of all the moving pieces in that section. That's something that is starting to change with this new development.

While I am not the manager or owner of the project, I am the team lead, so I think this falls into my area of responsibility. So my questions are:

1. Am I overreacting to something that is not really a major issue?
2. If I am not overreacting, what is the best way to correct this person without discouraging them? Again, they do fine work and I don't want to create any hostility.

EDIT: the wording of my question has led several people to believe that we are intentionally obscuring how parts of the code work so that only one person understands it. This is not at all the case. We have learned the hard way the importance of spreading knowledge around. We have daily stand ups and source control. What I mean is that we have one person working on particular sections of the code, because 1) it is easier to create consistent code that all operates in a similar manner, and 2) again, we are a very small team with a not-small task on our hands, and a harsh deadline. Specialization, combined with regular communication, breeds efficiency.

FURTHER EDIT: I suppose a better phrasing would be "how do I politely tell a coworker to only focus on his assigned tasks?"

Answer 1

I think this could become a major issue if you let it. It also could be a major opportunity if you handle it correctly. If your team continues to grow, you're not going to be able to maintain the clean separation you have had up till now, so you should probably try to figure out how to deal with this issue now, while it's small.

I think the issue is mainly one of communication. It's fantastic that your new team member has a lot of initiative to solve her own problems. But as you pointed out, the changes she is making are disrupting other peoples' work. So you need to develop a way to communicate about changes, before, during, and after.

I'm assuming you have regular standups or similar. This can be a great way to discuss proposed changes to make sure they're needed and in-line with the team's method of doing business.

After changes are made, they should be reviewed before being incorporated into the main codebase. At this point, they should be reviewed by the person who has "ownership," though that line will get fuzzier as more people touch the code. This will allow for needed edits to be made and for the "owner" to still stay in touch with all the parts of the code.

One thing that you'll need to realize is if your team needs to grow, it needs to grow. And that's going to introduce some inefficiencies due to having some parts of the code that some people are less familiar with than if they wrote it, and it will also mean that some of the lines between different pieces of functionality won't be drawn exactly where you would. In cases of adverse impact, that may mean going back and redrawing those lines. But that's just what happens once a team gets larger than a certain point.

Answer 2

Only having 1 person understand/develop be responsible for a system is a major failing in a team. This will lead to large disruptions if people leave are sick etc. So you actually want everybody working in all parts of the system all the time.

Yes having somebody changes code in systems without review is not acceptable (even if all your test pass). At least one other person should review any change and preferably more with the owner having the final say if the change is acceptable.

Answer 3

You do not own any part of the code. It is acceptable for anyone on the team to make any changes they feel necessary. Let's start with that. You NEVER OWN any part of the code. It is not your private domain. It is counterproductive for only one person to understand a part of the code. This is an attitude that you personally must adjust. What he is doing is not wrong. What you expect is.

Now that you have more devs you need more formal processes in place to make sure that changes are appropriate. You want to make sure that changes in any part of the code don't break the build. You want to make sure that QA is done before changes are pushed to prod and you want to make sure that devs no longer can push anything to production without going through the appropriate processes( usually by removing dev rights to prod and giving them only to a build team or a manager). You should also have code review of 100% of code written by any team member. You should be requiring unit test of all code so that you can test when changes are made. All code should be in source control so it can be reverted if necessary. This is where it is appropriate to bring up any concerns about the changes affecting other things.

What your team and managers need to do is sit down and determine the processes you need as the team grows and how you are going to enforce those processes. You also need to sit down and do knowledge transfer training so that more than one person can safely touch any part of the code.