One of the key concepts discussed in Team Topologies is the need to develop a sensing organization that grants you the flexibility necessary to evolve team composition and purpose over time to meet changing business demands. This is largely discussed in Chapter 8: Evolve Team Structures With Organizational Sensing.
In that chapter, Matthew and Manuel focus mostly on the heuristics used for determining when changes should be made, but something that's equally valuable - albeit out of scope for the book - was what capabilities make an organization "sensing" and how you go about developing them.
I'm not an expert, but that hasn't stopped me from giving advice before, so here are my pseudo-expert opinions.
Creating a sensing organization requires a means for that organization to gather feedback about changes that affect its teams.
Feedback in this context refers not to customer feedback about our products but to the info we're receiving from our teams about their daily work, and I would argue that this entire convo would be about the improvement of daily work.
Here are the best ways I've learned to garner said feedback.
Two practices from the SCRUM methodology that I think are essential even if you aren't practicing SCRUM are daily standups and retrospectives.
Daily standups are a daily meeting usually held for thirty minutes at the beginning of a work day where team members discuss what they did yesterday, what they plan on doing today, and what blockers they might have to their work.
Retrospectives are generally held at the end of a sprint and are a time set aside specifically to bring up and address concerns with how the team felt the sprint went.
Both of these tools provide on opportunity for team members to address aspects of their daily work to the entire team and are therefore an excellent time to gather feedback about concepts such as collaboration with other teams, cognitive load, etc. discussed in Team Topologies.
However, because this is a usually a conversation with several people, sometimes team members require prodding in order to participate. Also, sometimes there are things that are best not brought up in front of a group, which is a problem that one-on-ones can address.
I'm a huge fan of the Manager Tools podcast. It's hands-down the best advice I've found for managers, largely because it can be boiled down to four simple principles: get to know your folks, talk about performance, ask for more, and push work down.
The key tool to the Manager Tools Trinity model is one-on-ones. They're a thirty minute meeting you have once a week with each of your direct reports where you practice the above principles.
I could write more than a few articles on one-on-ones alone (and probably will at some point), but to stay on topic I'm going to explain why they're by far the most important tool you have for gaining insight directly from individuals about their daily work.
Something that inevitably comes up in one-on-ones is a reaction to changes that were made by management or agreed upon by a team which can sometimes be inappropriate for a whole-team setting. That means that folks will often not bring that kind of feedback up in those settings... but they generally will in a one-on-one. That alone is worth practicing them.
But confidentiality is by no means the only reason. Often it can just be how comfortable a person speaking to a group. Sometimes people just don't want to share things with a group that they'd rather share in a one-on-one, and I've found that it's generally the best setting to get the most honest feedback about how things are going from the perspective of your team members regardless of where they fall on the extrovert/introvert scale.
This is one of those that seems like a no-brainer, but if you want honest feedback about daily work then you should talk about it in a way in which anyone on your team can provide immediate feedback.
If you use a chat app like Slack, this could be as simple as having a convo in a public channel instead of in a direct message, thus creating the conversation more visible to your team or your organization as a whole. This gives you the added benefit of people outside your team being able to read and give their perspective as well.
Also, it's important to invite folks to provide feedback in these conversations in one-on-ones if you're not seeing it happen organically.
Even more so than retrospectives, communities of practice give folks in your organization an avenue for discussing the improvement of daily work in a way they can own. Conversations are less about the work of a specific team in a specific sprint and more about a type of work as a whole.
A community of practice is a group within an organization that is built around the improvement of a particular craft - like quality assurance, CI/CD, or user experience design that can (and should) be composed of members from disparate teams in your organization.
In my opinion, these should be owned and ran by folks who aren't in management. This creates a set of conditions that allow members to discuss things that they believe are important without introducing the bias of what management thinks is important. You can setup your own discussions for that separately or talk about that in one-on-ones.
This is by no means an exhaustive list of ways to gather feedback about your teams and their work, but they're the simplest ones I know of that can have a big impact on your capabilities as a sensing organization.
Let me know if any of this advice helps or hurts, and of course, I'd love to hear your thoughts as well.