|
Great question! I'll try my best to explain, though it's late and I may ramble – apologies in advance. (You said you understand this bit but I'll put it here too just incase someone else could benefit). By modelling "the architecture", I'm referring to the architecture or the design of the system where work is happening. Think, for example, whether it's a system composed of many small components (modules, micro-services, micro-frontends, mono-repo), or a single large application (more traditional monolith). By modelling "work" I mean: how do you distribute the work and the ownership of that work to teams. You can't easily have teams that share ownership, because if everyone is responsible then no one is. And you need to ensure responsibility for work is clear. For example, what are the outcomes you need from the other team building out that new API? Does your team also integrate code into those services that the other team are building? Probably not, but for some it isn't always clear. And if it's fundamentally required, how can you have many teams effectively contributing code to a single service without stepping on each other's toes and dilluting the concept of ownership? By "communications of the team(s)" I mean to say that you need to influence how teams communicate. In a perfect world, all teams would be perfectly autonomous and never need to have the overhead of talking to or depending on another team to deliver work. In reality, teams need to communicate but there are different models to facilitate this (self service systems, service oriented software design, documentation, etc.). Organic collaboration can be harmful as companies grow beyond certain limits if not kept in check. The book Team Topologies by Matthew Skelton is a deep dive on this topic if you find that interesting. I hope that answers your question. |