Does “everyone mess around everywhere” in our project/do we have an organisational deficiency?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







1















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)?










share|improve this question


















  • 5





    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
    Apr 2 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.

    – O. R. Mapper
    Apr 2 at 15:45











  • @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
    Apr 2 at 16:04


















1















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)?










share|improve this question


















  • 5





    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
    Apr 2 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.

    – O. R. Mapper
    Apr 2 at 15:45











  • @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
    Apr 2 at 16:04














1












1








1








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)?










share|improve this question














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)?







team project-management






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Apr 2 at 6:58









O. R. MapperO. R. Mapper

17828




17828








  • 5





    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
    Apr 2 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.

    – O. R. Mapper
    Apr 2 at 15:45











  • @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
    Apr 2 at 16:04














  • 5





    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
    Apr 2 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.

    – O. R. Mapper
    Apr 2 at 15:45











  • @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
    Apr 2 at 16:04








5




5





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
Apr 2 at 11:12





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
Apr 2 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.

– O. R. Mapper
Apr 2 at 15:45





@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.

– O. R. Mapper
Apr 2 at 15:45













@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
Apr 2 at 16:04





@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
Apr 2 at 16:04










2 Answers
2






active

oldest

votes


















3














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.






share|improve this answer































    2














    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?






    share|improve this answer
























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "423"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      noCode: true, onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f133081%2fdoes-everyone-mess-around-everywhere-in-our-project-do-we-have-an-organisation%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      3














      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.






      share|improve this answer




























        3














        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.






        share|improve this answer


























          3












          3








          3







          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.






          share|improve this answer













          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Apr 2 at 8:43









          virolinovirolino

          3,6861533




          3,6861533

























              2














              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?






              share|improve this answer




























                2














                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?






                share|improve this answer


























                  2












                  2








                  2







                  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?






                  share|improve this answer













                  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?







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Apr 2 at 10:49









                  JoeJoe

                  1,352211




                  1,352211






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to The Workplace Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f133081%2fdoes-everyone-mess-around-everywhere-in-our-project-do-we-have-an-organisation%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown