Separation of responsibilities in different project areas

Question

When I'm saying "area" I usually mean some relatively large unit or service, which is a part of a whole product, i.e. API service, location service, warehouse service, etc.

Context: a project with 20+ separate services that has been in development for 7 years. It has been rewritten from scratch, so if it counts, its over 25 years of history. A new team was hired a year ago or so to continue development and maintenance. We have 10 dev guys right now.

The usual workflow is when a new item arrives, it will be assigned to some dev, no matter what project area it is, and then the dev guy is responsible for its resolution.

It was a bit chaotic for us to develop in such a manner for the last year, because the code base is large from my perspective, and no one can know every corner of our app, especially when tasks randomly put you in different areas.

Question: is it a reasonable idea to assign a dev to be responsible for some areas(services), so he can focus on learning 1-2 services in details, and then maintain better knowledge of it? For example, we can maintain the same development process, but there will be a person who can perform a quality code review when someone creates a pull request to their area, or give some advice when it is needed.

We're about to discuss this internally in nearest future. I personally don't see any drawbacks and want to hear if someone had experience with such approach, its pros and cons, or maybe even other ideas on how current workflow can be improved.

Answer 1

For very complex product, it makes sense to have some kind of specialisation per “area”.

As you rightly pointed out: nobody can know it all. Therefore, keeping everyone responsible for everything might therefore result in vanishing (superficial) component knowledge, suboptimal or overlapping changes, regressions, and ultimately an unmaintainable product.

On the other extreme, organising teams exclusively by “area” might create a world of silos, where specialised knowledge booms, but mutual understanding might decrease over time, thus rigidifying the overall system and potentially a suboptimal use of resources.

So the key is to find the balance between these two extremes. For example:

• Having one or two “component-owner” for each “area” would have the benefit of maintaining a high component knowledge and promoting design consistency within each area.
• Two “co-owners” facilitate business continuity. The pair has nevertheless to self-organize to avoid doing twice the work.
• The component owners may decide collectively on assignment of new incoming changes. This would help to keep the big picture in mind and ensure mutual understanding.
• The execution of the change by one or several developers would be performed in liaise with the component owners: change implementers will benefit from owner’s knowledge, while owner would understand what is changed in the component.

Change executor and owner are two roles that could in some cases be performed by the sam individuals.

This organisation is balanced. There is a little more overhead than the model of the lonesome developper getting the things done. But the results on quality, maintainability, and teamwork is really worth the extra dialogues !

Answer 2

I do not know the exact details at your company, but a smarter way of doing things would be like this.

1. There is a top-level project manager over everything; or a team of project managers. They will analyze and assign the new project properly - to the right project manager.

2. The project manager will analyze the requirements and perform the top-down work breakdown structure (WBS).

3. The team manager will assign each slice of the WBS to the appropriate project managers, one for each area / service.

Without a clear project structure and without clear WBSs, there is no way of improvement.

What I described is just the "A" in the "ABC" of project management.

Although the fixing of the problem in your company might be an "easy" task, it requires extensive knowledge of project management and experience, to be done properly.