Recommended resources
The freely available resources this lesson will direct you to.
- Stakeholder Analysis: Power Interest Grid Explained with PMP Exam Tipswww.youtube.com
- Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load - Team Topologieswww.youtube.com
- Team Interaction Modeling with Team Topologiesteamtopologies.com
- Detailed application assessment - AWS Prescriptive Guidancedocs.aws.amazon.com
Hello again. Last lesson, we turned the invoice pilot’s product objective into measurable outcomes: customer-visible report timeliness, reliable intake, tenant isolation, auditability, and cost. One important boundary remained unresolved. The ingestion team can measure when its API accepts an invoice, but it cannot, by itself, guarantee when the customer submits it or when the reporting query returns it.
Today we will map the people, systems, and teams across that journey. By the end, you should be able to identify who has a stake in the initiative, what your team needs from others, and exactly where each team’s ownership begins and ends. This map will make the architecture decisions in the next lessons more realistic: an option that looks sound within one service may fail at a poorly understood handoff.
Begin with the customer journey, not the organization chart
Keep the pilot objective in view: at least 95% of invoices submitted by two pilot customers should be searchable in their reports within 15 minutes. For mapping purposes, assume four existing capabilities: a customer integration, an intake service, a reporting service, and a shared cloud platform. These are working assumptions, not a proposed architecture or a claim about how the teams are currently organized.
Start at the customer’s first observable action and trace the journey through the report they actually use. At each boundary, ask: What crosses it? How can we tell it crossed? Who can change either side? A system-context diagram is useful because it prevents the initiative from shrinking to whichever repository the Tech Lead knows best. This example depicts a different, fictional banking system; use its way of drawing people and external systems, not its banking design.
A context view is a starting point, not an ownership map. A line labeled “sends invoices” does not tell us who maintains the integration, whether submission timestamps are available, or whom to call when transmissions stop. We need to validate both the technical relationship and the people behind it.
AWS Prescriptive Guidance’s Detailed application assessment is written for application assessment and migration, rather than this pilot. Its discovery method transfers well: identify stakeholders, trace from users to infrastructure, then check diagrams against observed interfaces and traffic rather than assuming the first drawing is complete.
Detailed application assessment - AWS Prescriptive Guidance
Read this AWS Prescriptive Guidance assessment selectively for a method of finding stakeholders and dependencies, not as a migration checklist to complete for our pilot.
Near the beginning of the page, just before the paragraph on top-down and bottom-up discovery, read the stakeholder list. Then read the discovery guidance, from its comparison of the two approaches through documenting internal and external services. In the later questionnaire, go to Architecture and read the interface questions, starting at APIs and ending at tolerated latency. Under Operations, read the operating questions, from the operator through the impact of an outage. Finally, under Dependencies, read the dependency questions through the end of that subsection. Focus on which answers a diagram alone cannot supply.
For the pilot, discovery might reveal that “customer submission” occurs in a customer-controlled system hours before our API receives anything. That would change how we interpret the 15-minute goal. It might also reveal a scheduled reporting import rather than immediate indexing. Neither fact can safely be inferred from the intake code. Existing diagrams, API definitions, traces, job schedules, incident records, and conversations with the relevant teams provide different kinds of evidence; reconcile them when they disagree.
Map stakeholders by their stake and their decisions
A stakeholder is not necessarily a service owner. Pilot customers experience the result; support staff hear when it fails; a security specialist may set a mandatory constraint; an Engineering Manager may allocate capacity. A useful stakeholder register records what each party needs to know or decide, rather than merely listing names.
A short power–interest grid can help prioritize engagement, provided it is not mistaken for a decision-rights chart. Watch the definition, the discussion of highly interested people with less formal power, and the reminder to update the map.
Stakeholder Analysis: Power Interest Grid Explained with PMP Exam Tips
Watch “Stakeholder Analysis: Power Interest Grid Explained with PMP Exam Tips” from PM Aspirant for a quick engagement lens. We will use it cautiously: influence determines communication effort, not who owns a technical or product decision.
Watch the grid for its two axes. Skip to interested stakeholders for why people without final authority still provide essential feedback. Finish with revisiting the map for when engagement plans need updating.
Here is a draft stakeholder map for our assumed pilot. Named individuals, actual authority, and contact routes would need confirmation.
| Stakeholder | Stake in the pilot | Decision or input needed |
|---|---|---|
| Product Manager and pilot customers | Customer-visible timeliness and an acceptable pilot experience | Product confirms the meaning of “submitted” and “searchable,” pilot scope, and how customers will validate success. Customers provide integration and reporting feedback through an agreed contact. |
| Intake and reporting teams | Changes to their services and shared timeliness measure | Each team confirms its interface, capacity, release timing, and operational responsibility. Neither can redefine the end-to-end result alone. |
| Customer-integration owner | Submission behavior before API acceptance | Confirms timestamps, retry behavior, invalid submissions, and who can change the customer-facing integration. |
| Security and privacy stakeholders | Tenant isolation, auditability, and data handling | Interpret required controls and review affected trust boundaries under the organization’s actual approval process. |
| Platform and operations stakeholders | Cloud capabilities, deployment, monitoring, and incident response | Confirm available services, platform constraints, support routes, and any capacity or change windows. |
| Engineering Manager and budget owner | Team capacity and spending commitment | Confirm staffing and the cost ceiling respectively; the Tech Lead exposes technical consequences rather than silently committing either resource. |
This is intentionally more precise than assigning everyone a quadrant. A customer support specialist may have little authority over architecture yet be the first to recognize that invoices marked “processed” are missing from reports. Conversely, an executive sponsor may need a concise update on a material budget change, not an invitation to every interface-design meeting.
The Tech Lead maintains the technical map and brings unresolved boundaries to the right people. They do not acquire the Product Manager’s authority over the customer commitment or another team’s authority over its service simply by coordinating the initiative.
Turn system relationships into explicit dependencies
An external dependency is something the delivery team needs but cannot deliver or change on its own. “External” here includes another internal team, a customer-controlled integration, or a cloud provider—not just a third-party API. Dependencies can be technical, operational, or organizational. A working endpoint is little help if no other team can commit to testing it before the pilot.
For each dependency, record the needed result, provider, consumer, evidence of readiness, and date by which uncertainty must be resolved. The following is a compact first pass, not a delivery schedule:
| Dependency outside intake-team control | Provider and needed agreement | Evidence to seek |
|---|---|---|
| Customer submission and timestamps | Customer-integration owner confirms when “submitted” is recorded, supported payloads, retries, and pilot access. | Sample submissions and timestamps correlated with intake records. |
| Report visibility | Reporting team confirms the query that counts as “searchable,” required invoice fields, and how visibility is measured per tenant. | An accepted invoice ID returned through the authorized pilot reporting query, with both timestamps. |
| Identity and tenant controls | Identity/platform and security owners confirm existing authentication, authorization, and audit requirements at the affected boundaries. | Reviewed interface behavior and tests for identified cross-tenant access paths. |
| Cloud capacity and cost information | Platform team and budget owner confirm available capacity, cost accounting, and any service limits relevant to the forecast burst. | Capacity evidence and an agreed cost-measurement boundary. |
| Pilot operations | Operating teams agree how to detect a stuck invoice, who investigates each segment, and how a customer issue reaches them. | A documented support route and a correlated invoice trace across team boundaries. |
The report-visibility row deserves special attention. The intake team may deliver a valid record to an agreed interface, yet the reporting team may reject it, delay it, or display it under an unexpected tenant. Calling this simply “the reporting dependency” conceals several questions: What constitutes successful handoff? How are duplicates and failures surfaced? Which team can replay or repair a missing invoice? What evidence lets the two teams locate it without inspecting one another’s databases?
Those questions describe a boundary contract, not necessarily a particular technology. We have not selected a queue, event stream, or direct call. What we already need is agreement on invoice identity, tenant identity, relevant timestamps, accepted and rejected states, and observable failure handling. Architecture options can then be evaluated against that contract rather than defining success after an option is chosen.
Mark confidence explicitly. For example, “reporting query confirmed by reporting owner” is different from “assumed from an old diagram.” Put an owner and a date on consequential unknowns; otherwise an attractive diagram can create false certainty.
Make team ownership visible at the handoffs
System boundaries and team boundaries do not always coincide. One team might own multiple services; two teams might currently share changes to one component. Team Topologies offers language for describing both the kind of team and how teams interact, without pretending that every existing group fits an ideal type.
Team Interaction Modeling with Team Topologies
Read Team Topologies’ “Team Interaction Modeling” for a vocabulary that makes cross-team working arrangements explicit. Treat the types as diagnostic descriptions, not labels to impose on teams before checking how they actually work.
In Identify your current teams and map them to the fundamental team types, begin at the mapping guidance, then scan the immediately following Stream-aligned teams, Enabling teams, Complicated Subsystem teams, and Platform group descriptions. Notice the warning immediately after the guidance: leave a team unclassified if its current behavior does not fit. In Creating our first Team Interaction Model, read the three short subsections. Start with Collaboration; then X-as-a-Service, continuing to the end of that paragraph; and finally Facilitating. Ask which mode describes each current pilot interaction and which mode would make a settled boundary easier to operate.
Apply the distinction to intake and reporting. If the boundary is not yet understood, time-boxed collaboration may be appropriate: both teams jointly trace invoices, agree what “visible” means, and test a candidate contract. Once the interface and operational responsibilities are stable, they may work more effectively through a documented service relationship: each team owns its side and knows how to request a change or report a failure. A security or platform specialist might facilitate a short review or help the teams establish tracing, without becoming the permanent owner of invoice processing.
For each boundary, make four responsibilities explicit:
- Build and change: Which team owns each interface and its versioning? Who must be consulted before an incompatible change?
- Run and recover: Who sees a failure first, who investigates each segment, and how is it escalated across the boundary?
- Measure: Who supplies timestamps or states, and who assembles the customer-visible measure?
- Decide: Who can accept a change to the contract, and who must approve a changed product promise or mandatory control?
Consider an invoice accepted by intake but absent from reports after 15 minutes. The intake team should be able to establish whether it accepted the invoice and completed its agreed handoff. The reporting team should be able to establish whether it received, indexed, and returned that invoice for the correct tenant. Someone must own coordinating the investigation across that seam—perhaps a designated pilot incident lead—without making that person the owner of both services. Product coordinates the customer-facing implication of a missed promise. The exact assignments must be agreed with the teams, not inferred from titles.
A practical map is therefore more than boxes and lines: pair a context view with a small stakeholder register, dependency list, and boundary agreements. Review it with the providers and consumers, correct assumptions using evidence, and revisit it when the pilot scope or team responsibilities change.
Conclusion
A cross-team initiative becomes manageable when three questions have concrete answers: Who is affected or decides? What must another party provide? Who owns each side of a change, measurement, or incident? For the invoice pilot, the customer-visible clock crosses customer integration, intake, and reporting. Mapping those boundaries protects the 15-minute objective from being reduced to a convenient local metric.
Keep unknown owners and unverified interfaces visible rather than filling gaps with guesses. In the next lesson, we will use this map to frame an architecture decision: its context, constraints, viable options, and evaluation criteria will now include the teams that must build and operate it.