WAN

If CPU is how you think and decide as a manager, and LAN is how your team works internally, WAN is how you connect that team to everyone else: other teams, leaders, customers, and partners.

The goal of WAN is to reduce politics and surprise work, and to bring real‑world feedback into the team in a healthy way. Keep in mind that this is a practical framework, not a conspiracy theory, so we focus the processes in tangible and frictionless efforts.

“A strong WAN means fewer ‘WTF requests’ and more intentional collaboration.”

Stakeholder Map & Expectations (inside + outside)

Keep in mind that stakeholders are the ultimate reason for what you are bringing to life. No product makes any sense without a request, a need, or a final consumer/provider. With that in mind, you need to have a clear picture of what is needed in reality, and how you can make it possible. It is not about what you like, or how you would have done things if that depended on you, it is about satisfying a need, and that need comes from the stakeholders.

I’ve seen great projects being abandoned because they were not what the stakeholders needed, or believe they needed. And in that second part of the sentence lie a lot of the errors we make. There is a very thin line that separates informing about what is possible and makes sense of what YOU want opposite to what they want. Be very careful on that point, it is OK to tell stakeholders when something does not make sense or is not aligned with the global project, but always do it with objective data, facts, and propositions to cover the need, because in the end, that is the final goal, to fulfil stakeholders expectations.

The purpose of the Stakeholder Map is to know who are those stakeholders and how much power and interest they have. This might seem an obvious question, but you’d be surprised about how many projects doesn’t have this question addressed.

Once you know who is time to know what.

The map should show what is expected from each of the stakeholders in terms of communication, decisions, support, and constraints. Those are the key aspects to clarify how to achieve success or fail, because this is not about making a good job only, it is about making the required work too.

We could stand that:

“If WAN is how you connect with the world, the Stakeholder Map is your routing table: who is on the network, and what traffic they expect from you.”

Stakeholders can be internal or external, it can vary depending on the nature of the project, but one thing in common independently of where they are is that they have the power to make it go or stop it. So the ultimate reason you are doing the job is to keep their expectations satisfied.

The rule of the thumb could be:

• Internal stakeholders (inside): people employed in or directly working with your org who influence or are influenced by your team’s work (EMs, PMs, adjacent teams, execs, etc.).

• External stakeholders (outside): customers, users, partners, vendors, regulators, and broader community that feel the impact of your product but don’t work in your team.

Every project has both types, and ignoring one side creates blind spots.

Cross‑Team Collaboration & Dependencies

As soon as your work crosses the boundaries of your own team, you’re in the world of Cross‑Team Collaboration and Dependencies. This is where your LAN connects to the rest of the organization’s WAN: product working with platform, backend with data, engineering with marketing, and so on. In this space, your progress is no longer just about how well your own team operates, but about how smoothly you can exchange value with others who have different goals, rhythms, and constraints.

Dependencies are the “network links” between teams—places where one group’s work needs something from another before it can move forward. Some of these links are powerful: shared platforms, specialized expertise, and central services that help everyone go faster when used well. Others are painful: hidden blockers, unclear ownership, or decisions that bounce around for weeks before anyone commits. Your ability to navigate these links without constant friction is a big part of your effectiveness at the WAN level.

When cross‑team collaboration works, the org feels like a well‑designed network: teams know who they depend on, why, and how to engage them; work flows across boundaries with predictable hand‑offs and minimal drama. When it doesn’t, you see classic symptoms: duplicated effort, features stuck “waiting on another team,” meetings that only exist to clarify responsibilities, and local optimizations that hurt company outcomes. The difference is rarely about tools alone; it’s about how deliberately you design and maintain the relationships between teams.

In the next section, we’ll break this concept down into practical topics you can work on: how to see and talk about dependencies, how to design better “interfaces” between teams, and how to reduce the overall pain without needing to redraw the org chart overnight.

What We’ll Cover in This Section

• Why dependencies exist and when they’re useful vs harmful.
• How to map and visualize cross‑team dependencies so they stop being “invisible blockers.”
• How to design clear collaboration interfaces between teams (ownership, service boundaries, SLAs, and expectations).
• Lightweight rituals and communication patterns that keep cross‑team work flowing (syncs, boards, shared kickoffs).
• Strategies to reduce or simplify dependencies over time (cross‑functional skills, end‑to‑end slices, decoupling).
• How to operate effectively in a WAN environment even when you don’t control the org structure.

Customers & Users: Bringing the Outside In

If WAN is how you connect your team to the outside world, customers and users are the clearest signal of whether what you’re building actually matters. They are the people who feel your product in their day‑to‑day lives: the ones who struggle with a workflow, celebrate a feature, or quietly churn when you miss the mark. At this layer, your job is not just to “serve the business,” but to translate real‑world problems and behaviors into decisions your team can act on without guesswork.

Most teams think they’re customer‑centric because they occasionally read feedback or look at a dashboard. In practice, many operate with a blurred picture of who their users really are and what they’re trying to get done. That’s how you end up shipping features that are technically correct but emotionally wrong: they work, but they don’t solve a meaningful problem, so usage is low and frustration is high. Bringing the outside in means treating customer understanding as a continuous input into your decisions, not a one‑off research activity.

When this works, your team feels connected to reality: people can link their tasks to concrete user stories, support tickets, usage patterns, and business outcomes. You see more “we built this because…” and fewer “we built this because someone in a meeting said so.” When it doesn’t, you get local optimizations: elegant technical solutions to problems nobody asked you to solve, while the actual painful issues remain untouched.

In the next section, we’ll turn this idea into simple habits and tools that make customer insight part of your everyday WAN work, not something that only happens in big discovery projects.

What We’ll Cover in This Section

• Clarifying who your real customers and users are (and how they differ from internal stakeholders).
• Practical ways to collect ongoing feedback: support channels, interviews, analytics, and usage signals.
• How to translate raw feedback into clear, actionable narratives for your team (problems, contexts, constraints).
• Lightweight rituals to keep customer stories visible in your day‑to‑day work (reviews, demos, story walls).
• Balancing what users ask for with what actually makes sense for the product and company.
• Building a habit of “outside‑in” thinking so your team’s WAN stays grounded in real people, not just internal politics.

External Partners, Vendors & Platforms

Not everything your team needs lives inside your company. At the WAN level, a big part of your job is how you plug into external partners, vendors, and platforms: cloud providers, tool vendors, agencies, consultants, and ecosystem products your team relies on every day. These relationships can feel far away from the code, but they quietly shape reliability, cost, speed, and even what’s possible for your product.

When these external links work well, they behave like solid infrastructure: clear contracts, predictable performance, and responsive support when things go wrong. Your team knows what it can rely on, who to call, and how to escalate without drama. When they don’t, you get surprise outages, license issues, slow integrations, and “we’re blocked because the vendor hasn’t replied in two weeks” moments that drain energy and trust.

Managing external partners isn’t just procurement or legal work; it’s a leadership skill. You’re effectively designing and maintaining the extended network around your team: which platforms you choose, how you evaluate them, how you keep them aligned with your technical and product strategy, and how you protect your team from last‑minute surprises. Done intentionally, this gives your people leverage—access to capabilities they don’t have to build themselves—without turning every vendor relationship into a source of risk.

In the next section, we’ll turn this idea into concrete practices so that external partners, vendors, and platforms feel like stable parts of your WAN, not random variables your team hopes will behave.

What We’ll Cover in This Section

• How to identify which external partners and platforms are truly critical for your team’s work.
• Evaluating vendors and tools beyond features: reliability, support, roadmap fit, and cultural alignment.
• Designing clear working agreements: contracts, SLAs, escalation paths, and shared responsibilities.
• Keeping integrations healthy over time: upgrades, breaking changes, and dependency risk management.
• Practical habits for staying informed about changes in key platforms (roadmaps, deprecations, policy shifts).
• How to protect your team when external partners fail, under‑deliver, or suddenly change direction.

Upward Management, Org Change & Protecting the Team

If CPU is how you think, and LAN is how your team operates, WAN is also how you relate to the layers above you: your manager, senior leadership, and the broader organization that keeps changing around your team. Upward Management and Org Change sit exactly here. This is the part of the job where you translate reality on the ground into clear signals upwards, and translate decisions from above into something your team can actually work with—without burning them out or turning every change into chaos.

Many managers feel caught in the middle: expectations and reorganizations come from the top, while capacity, morale, and technical constraints live in the team. If you just “forward” pressure downwards, your team becomes a shock absorber for every org decision. If you simply shield them from everything, they lose context and end up misaligned with where the company is going. Upward Management is the skill of finding the practical middle ground: being honest about what’s possible, negotiating priorities, and representing your people clearly at the WAN level.

Org Change is inevitable: new strategies, restructures, leadership changes, tool migrations, and shifting roadmaps. You can’t stop these waves, but you can decide how your team experiences them. Protecting the team doesn’t mean saying “no” to everything; it means making sure change comes with clarity, pacing, and support, instead of surprise work and anxiety. Done well, your people feel informed and involved, even when they don’t control the decisions; done badly, they feel like the ground keeps moving under their feet with no explanation.

In the next section, we’ll turn these ideas into concrete behaviors you can practice every week, so that upward management, org change, and protecting the team become part of your normal WAN toolkit, not just something you think about during crises.

What We’ll Cover in This Section

• How to clearly represent your team upwards: capacity, risks, wins, and constraints.
• Practical ways to negotiate priorities and push back on unrealistic expectations without damaging trust.
• Making org changes digestible for the team: context, narrative, and step‑by‑step transitions.
• Protecting the team from “surprise work” and politics while keeping them connected to company goals.
• Building regular communication habits with leadership so issues are raised early, not during fire drills.
• How to stay sane yourself: managing your own WAN load so you don’t become the single point of failure for every change.