I am working in a large-ish software project with several dozen developers.

Our internal guidelines have it such that responsibilities for aspects of the application are clearly assigned. For instance, individual parts of the business logic are maintained by different, specialized teams, parts such as the GUI, web APIs, or the DB schema are watched over by different teams each. (That doesn't have to mean these teams do all the work; just that they have the final word in their respective realm of responsibility and may make some amendments.

The benefit is that the respective parts are kept consistent across the application, even in new situations that are not yet covered by any styleguide. Likewise, parallel development of almost the same functionality in different parts of the application is avoided. The only downside I see is that often, no team can work on a task totally independently, because most tasks include some (w.l.o.g.) GUI or DB topics at some point.

In all, clearly assigning responsibilities like this seems beneficial to me, though, as it makes clear exactly who will do what. While I do not claim we are well organized in all aspects, my impression was that these clear-cut responsibilities do actually work well.

Now, I recently outlined the above to a (software developer) friend, with roughly the same words as here. His only remark was: "Oh my, sounds really chaotic. Everyone's messing around everywhere!"

This got me worried, or at least wondering: Is the way we assign responsibilities an organisational problem rather than a success (one that I might not notice due to being too immersed within the project)?

  • 6
    This actually sounds like the reverse of "everyone messes around everywhere". You have clearly defined teams operating in clearly defined areas. Why did your friend consider this chaotic?
    – DaveG
    Commented Apr 2, 2019 at 11:12
  • @DaveG: Apparently due to the downside I mentioned here: For a task that could, seen on its own, be done by a single person, several people from different teams have to participate. Commented Apr 2, 2019 at 15:45
  • 1
    @O.R.Mapper but again, the way you have it organized, each team only works in the area they are expert in. If one person was changing the UI, backend service, DB, etc, then that would be everybody messing around everywhere.
    – DaveG
    Commented Apr 2, 2019 at 16:04

2 Answers 2


Your question can be asked shortly: "Is it a strength or a weakness?" And I think it is both a strength and a weakness.

The entire discussion starts at how is the WBS done. Once the WBS is done, people can be assigned to tasks.

However, as simple as it may sound, doing a proper WBS comes with its own challenges. Sometimes, elements of the structure are too small to assign one person 100% to them. Other times (quite often), there are several ways to do the same WBS. Some elements are also often responsible for more than 1 task, and therefore compromises have to happen.

The assignment of people to working to the different parts of the WBS is usually as good as the WBS itself.

As you described the situation, your company made a pretty good job at doing a WBS. And inevitably, it also has to deal with some sharp edges.

Of course, somebody with a different WBS in mind, for the same problem, may say that the current organization is very improper.

But what counts in the end? It counts if the work is actually getting done, and if people actually cooperate to rounding the sharp edges.


You Tell Us

The way to judge whether a team is organized correctly is whether or not it executes well on its business objectives. Although you describe the team organization in detail, nowhere in your question is there any indication that this is a problem.

It's possible that you could be organized better. It's also possible that how you are organized works well for you now, but it might not work well later as conditions change. It's possible that it is "chaotic", for some definition of "chaotic". But, if you are executing well, and nothing indicates that you will not continue to do so, then none of those things actually matter.

I know my company has organizational problems, because those problems get in the way of us getting work done. Team B gets dragged away from its work to help Team A, because 60% of Team A is doing the software equivalent of digging ditches and filling them back in again, because work in Team A effectively takes place in silos based on who the customer is that wants it. This silo approach was OK before when customer projects and the team were small, but now that both have gotten big it's clear that it's really not working very efficiently because work is slipping all over the place.

That's an example of the kind of story you might be able to tell if you have an organizational problem: work isn't getting done that should be because we're organized in a way that doesn't help us execute on our objectives.

So, you tell us, do you think your team has an organizational problem?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .