tossMay 22, 2026

Tips for Growing the Skills to Solve Cross-Functional Technical Problems (opens in new tab)

As organizations grow, their hardest technical problems increasingly arise between teams rather than within them. These cross-functional, cross-domain problems cannot be solved through more meetings, status updates, or risk tracking alone; they require redefining the problem, structuring it, and creating an execution model that moves people to action. The post presents Toss’s Technical Program Manager (TPM) role as an example of this approach. ## Why Cross-Functional Problems Persist - Individual teams may perform well while the organization still fails to optimize as a whole. - Technical issues often span product, infrastructure, data, security, operations, strategy, and organizational design. - Common symptoms include: - Unclear ownership - Missing decision-makers - Conflicting priorities - Dependencies across multiple teams - Important “gray areas” with no formal owner - As organizations mature, these boundary problems become more common because team responsibilities become clearer while cross-team gaps remain. ## The Core Principle: Redefine the Problem - Cross-functional technical problems are not solved by increasing management activity. - More frequent meetings, status reports, risk registers, and stakeholder alignment may be useful but often address symptoms. - The real bottleneck may be: - An absent decision structure - Ambiguous ownership - Conflicting priorities - A system that does not connect individual team efforts - Effective problem-solving starts by identifying the underlying issue rather than merely describing delays or communication problems. ## Capabilities Required to Solve These Problems ### Reframing the Problem - Identify why schedules slip or decisions stall. - Determine which responsibilities or decisions are missing. - Find the structural conditions that repeatedly create the same gap. - Without accurate problem definition, organizations continue managing symptoms. ### Turning Ambiguity into Structure - Make decisions, options, responsibilities, dependencies, and sequencing explicit. - Break complex issues into manageable units. - Replace vague discussion with concrete decision points and ownership. ### Exercising Strategic Judgment - Distinguish temporary incidents from recurring structural problems. - Decide whether the issue can be solved within one team or requires broader intervention. - Assess whether immediate action is necessary. - Prioritize problems that improve the organization’s overall execution capability. ### Converting Plans into Execution - Identify who must act and which decisions must happen first. - Remove blockers and turn unclear discussions into explicit decisions. - Secure agreement on action plans and ensure those actions actually occur. - The goal is not merely to monitor execution, but to make execution possible. ### Influencing Without Formal Authority - Cross-functional work rarely succeeds through hierarchy alone. - TPMs need trust, sound judgment, and the ability to translate between teams with different goals and constraints. - Their influence should come from credibility and problem-solving results rather than title. ### Seeing People and Structure Together - Many technical problems are also caused by unclear roles, unsuitable team structures, or outdated operating mechanisms. - Effective intervention may require changing processes, redistributing responsibilities, or involving leadership—not just modifying technology. ## A Practical Starting Point for Less Autonomous Organizations - **Solve a small, concrete bottleneck first:** Demonstrate that involvement makes work clearer and faster. - **Add structure within existing coordination duties:** Use meetings and schedule management to expose decisions, dependencies, and blockers. - **Clarify ownership in a limited scope:** Define the real owner, decision rights, and completion criteria for a small initiative. - **Build evidence through successful cases:** Organizations often recognize new roles through demonstrated results rather than role descriptions. ## Important Cautions - Coordination remains valuable, but it should serve problem-solving rather than become the goal. - Lack of formal authority does not mean lack of influence; trust, structure, and results can be more powerful. - Introducing an idealized role too quickly may trigger resistance. It is better to make the approach work within the organization’s current environment and expand from proven examples. The central recommendation is to stop treating cross-functional technical problems as coordination exercises. First ask what the real bottleneck is, who is missing, and what execution structure would enable progress; then use that understanding to drive concrete organizational change.

technical-program-managementcross-functional-collaborationproblem-solvingorganizational-design+2

tossMay 14, 2026

Why High-Performing Organizations Need Toss-Style TPMs in the AI Era (opens in new tab)

TPM roles are often associated with coordinating schedules, dependencies, risks, and stakeholders. Toss argues that this is no longer enough: as organizations grow and AI increases cross-team complexity, the most important problems often fall into gray areas with no clear owner. Its TPM is therefore redefined as a strategic execution problem-solver who structures ambiguous problems and drives them to measurable resolution. ## Why TPM Needs to Be Redefined - Traditional TPMs typically deliver already-defined technical programs by managing: - Schedules - Risks - Dependencies - Cross-functional communication - At Toss, many difficult problems do not begin as clearly named programs. - Common examples include: - Problems spanning multiple teams with no accountable owner - Strategies without an execution model - Issues recognized as important but lacking priority or authority - Frequent status updates without meaningful change - These problems may involve product, technology strategy, organization design, and operations simultaneously. - AI adoption is accelerating this trend by increasing dependencies across data, security, quality, productivity, and organizational practices. ## How Toss’s TPM Differs from Related Roles - **Product Owner:** Defines what to build, product priorities, and customer or business value. - **Engineering Manager or SDM:** Builds the conditions for a team to execute consistently, including people, quality, and team health. - **Traditional TPM or Technical Project Manager:** Manages delivery of an already-defined initiative. - **Toss TPM:** Addresses the structural problems left between or outside these roles. - Finds important but undefined problems - Establishes ownership and decision rights - Creates an executable structure - Drives the work through to completion - The role is not primarily a project scheduler or people manager; it is a problem solver for organizational gray areas. ## Why Cross-Team Problems Matter in Strong Organizations - In less mature organizations, bottlenecks such as unclear responsibility or poor prioritization are usually visible within teams. - In high-performing organizations, individual teams may operate effectively while problems remain between teams. - Organizational structures clarify accountability and speed decisions, but they can also leave boundary-spanning issues without an owner. - These issues include: - Company-wide problems that local optimization cannot solve - Important long-term work that is not urgent - Responsibilities shared by several teams but owned by none - AI makes these boundary problems more frequent because technical, operational, and organizational concerns increasingly overlap. ## What a Toss TPM Does - **Finds problems proactively** - Identifies recurring gaps, structural bottlenecks, and unnamed problems rather than waiting for assigned work. - **Turns strategy into execution** - Determines which teams must act, in what order, who should be the DRI, and what must be deprioritized. - **Creates value between teams** - Designs solutions where different goals, constraints, and working speeds collide. - **Removes blockers** - Goes beyond reporting risks by changing decision structures, assembling the right people, resetting priorities, or redesigning collaboration. - **Considers people and systems together** - Examines leadership, team composition, authority, and operating mechanisms—not just timelines. - **Measures success through real change** - Success means execution resumes, direction improves, recurring bottlenecks decrease, and future solutions become easier. - Coordination is a useful skill, but problem-solving is the role’s core identity. ## Capabilities Needed to Become This Kind of TPM - **Problem structuring:** Separating symptoms from root problems, identifying stakeholders, and locating decision bottlenecks. - **Execution design:** Translating strategic direction into concrete workflows, sequencing, and ownership. - **Influence and mobilization:** Moving teams without relying solely on formal authority, including handling difficult conversations. - **Systems thinking:** Addressing repeated problems by changing mechanisms rather than relying on individual heroics. - **Follow-through:** Carrying work from discovery and alignment through execution, measurable results, and prevention of recurrence. Toss’s recommendation is to look for important problems that everyone recognizes but no one owns. People who cannot ignore those gaps can begin acting as informal TPMs in their current organizations—turning ambiguous, cross-functional problems into executable solutions and driving them to completion.

technical-program-managementaidata-governancecross-functional-collaboration+3