Manuel and I are keen to extract some of the questions and discussions and turn them into blog posts or articles. We're working with the IT Rev folks to see how that might work :thumbsup:

Chapter 6 observation: I like the variety, but I think that some of the typology of monolithicism might be less of a stretch if one portrayed it as "closeness of coupling" because that can illustrate islands of tighter than desirable coupling without turning everything into the rock of Gibraltar 🥌

Chapter 6 observation: I like the variety, but I think that some of the typology of monolithicism might be less of a stretch if one portrayed it as "closeness of coupling" because that can illustrate islands of tighter than desirable coupling without turning everything into the rock of Gibraltar 🥌

Yes, "close coupling" might be a phrase we use if there is a Second Edition, @kka42 - the monolith terminology is useful and quite apt but we stretched it a bit thin 🙂

<!here> AMA has started in #ama_team_topologies

I’m behind on reading so this might be answered in the later chapters. I was wondering how to improve the team structure and handle this situation. We have an individual who has been in the same org for 30 years. They are a great individual and helps out so much, but they are also a bottleneck I believe. They handle the business side of IT and help align all the teams to use the same technology or meet the same standards that need to be met by a dead line. They are one of the people who directs the “train” (a group of teams on the same alignment under the safe framework) and decides what the teams works on and the business value that is assigned to each feature being delivered. They hold a lot of responsibility and knows who to contact to help move things along and remove roadblocks. However they have so much on their plate that things fall to the side of the road and takes a while to get back around to them. Also information that needs to come down doesn’t seem to come down in a timely manner instead makes it down when their is an urgency to get things done. They are close to retirement also and have started to train a replacement. It’s still too soon to tell if the replacement is up to the challenge. I feel like this is a bad thing to do. Have one person responsible for everything, making decisions for all, all that knowledge only in one person. What are your thoughts/suggestions on fixing this?

I’m behind on reading so this might be answered in the later chapters. I was wondering how to improve the team structure and handle this situation. We have an individual who has been in the same org for 30 years. They are a great individual and helps out so much, but they are also a bottleneck I believe. They handle the business side of IT and help align all the teams to use the same technology or meet the same standards that need to be met by a dead line. They are one of the people who directs the “train” (a group of teams on the same alignment under the safe framework) and decides what the teams works on and the business value that is assigned to each feature being delivered. They hold a lot of responsibility and knows who to contact to help move things along and remove roadblocks. However they have so much on their plate that things fall to the side of the road and takes a while to get back around to them. Also information that needs to come down doesn’t seem to come down in a timely manner instead makes it down when their is an urgency to get things done. They are close to retirement also and have started to train a replacement. It’s still too soon to tell if the replacement is up to the challenge. I feel like this is a bad thing to do. Have one person responsible for everything, making decisions for all, all that knowledge only in one person. What are your thoughts/suggestions on fixing this?

A common situation, @jdmmis - almost the situation in The Phoenix Project! That person has a lot of valuable domain knowledge which is probably obvious to them but far from obvious to other people. You should find ways to get them to articulate how and why they make decisions. Somehow map out their decision making process - all the factors they take into account when making decisions. This could be using whiteboards, flowcharts, spreadsheets, or even LEGO. Whatever the person is most comfortable using. You could even say you're going to turn it into a book if that gets the results. Put yourself in their shoes and try to work out what they would like to produce as a way to explore and define their decision making. 👍

For everyone reading the ebook, this is the section "Software Boundaries of 'Fracture Planes'" to "FINDING GOOD SOFTWARE BOUNDARIES AT POPPULO"

For everyone reading the ebook, this is the section "Software Boundaries of 'Fracture Planes'" to "FINDING GOOD SOFTWARE BOUNDARIES AT POPPULO"

@matthew yes I completely agree they have a lot of valuable domain knowledge. Thank you for the suggestions.

While oir organization has a variety of approaches being used, I’m lucky enough to be working on a very stream-aligned team. BUT as a small team, I can see ways we could split some of these with natural fractures - there are three applications that all talk together - we handle QA and support as well. My concern is that while we can see a natural way to split this, it’s difficult to bring in/split out the team without having to get other parts of the organization on board. This creates a training gap for mew people and while others may agree on the approach of splitting, changing priorities for the organization means no movement on this. Instead what we are doing is scheduling our iterations and releases around the natural fractures. Does this sound familiar and any ideas to make this better?

While oir organization has a variety of approaches being used, I’m lucky enough to be working on a very stream-aligned team. BUT as a small team, I can see ways we could split some of these with natural fractures - there are three applications that all talk together - we handle QA and support as well. My concern is that while we can see a natural way to split this, it’s difficult to bring in/split out the team without having to get other parts of the organization on board. This creates a training gap for mew people and while others may agree on the approach of splitting, changing priorities for the organization means no movement on this. Instead what we are doing is scheduling our iterations and releases around the natural fractures. Does this sound familiar and any ideas to make this better?