The system architecture contains traces of your organizational structure

And knowing this helps you avoid common pitfalls and hidden costs

Photo by Dan Burton on Unsplash

Segregating component’s responsibilities

Photo by Mourizal Zativa on Unsplash

Splitting teams will break components apart

Photo by Vlad Hilitanu on Unsplash

A team with too many domains to manage tends to build more coupled components

Photo by Edgar Chaparro on Unsplash

What’s the takeaway?

  • If you have one or few teams managing multiple domains
    Make sure the team(s) are breaking apart the dependencies properly. Especially if you have a growth plan with your next organizational structure already designed. It will also help them document and test the system and onboard new members.
  • If you have multiple teams and are planning on restructuring
    Work with them to identify the domains for each team and where there’s refactoring and redesigning will be needed. Consider the investment (effort) in making these changes before or after the transition. Most organizations ignore this hidden cost and let it happen after reorganizing teams. However, doing it before the restructuring ensures that the current SMEs will be able to do it, reducing the costs and risks, and making knowledge transitions easier.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Peter P. Lupo

Many management blogs focus on soft skills. This blog is about hard skills! Measurement, indicators, approaches, etc., for Software Engineering Management.