Organizational Design

3 posts

toss4 min readCurated summary

Tips for Growing the Skills to Solve Cross-Functional Technical Problems

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.

Read original(opens in new tab)
toss4 min readCurated summary

Why High-Performing Organizations Need Toss-Style TPMs in the AI Era

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.

Read original(opens in new tab)
woowahanOriginal article

We refactor culture just like code. (opens in new tab)

The Commerce Web Frontend Development team at Woowa Brothers recently underwent a significant organizational "refactoring" to manage the increasing complexity of their expanding commerce platform. By moving away from rigid, siloed roles and adopting a flexible "boundary-less" part system, the team successfully synchronized disparate services like B Mart and Baemin Store. This cultural shift demonstrates that treating organizational structure with the same iterative mindset as code can eliminate operational bottlenecks and foster a more resilient engineering environment. ### Transitioning to Boundary-less Parts * The team abandoned traditional division methods—such as project-based, funnel-based, or service-vs-backoffice splits—because they created resource imbalances and restricted developers' understanding of the overall service flow. * Traditional project-based splits often led to specific teams being overwhelmed during peak periods while others remained underutilized, creating significant delivery bottlenecks. * To solve these inefficiencies, the team introduced "boundary-less parts," where developers are not strictly tied to a single domain but are encouraged to work across the entire commerce ecosystem. * This structure allows the organization to remain agile, moving resources fluidly to address high-priority business needs without being hindered by departmental "walls." ### From R&R to Responsibility and Expandability (R&E) * The team replaced the traditional R&R (Role & Responsibility) model with "R&E" (Responsibility & Expandability), focusing on the core principle of "owning" a problem until it is fully resolved. * This shift encourages developers to expand their expertise beyond their immediate tasks, fostering a culture where helping colleagues and understanding neighboring domains is the standard. * Work is distributed through a strategic sync between team and part leaders, but team members maintain the flexibility to jump into different domains as project requirements evolve. * Regular "part shuffling" is utilized to ensure that domain knowledge is distributed across the entire 20-person frontend team, preventing the formation of information silos. ### Impact on Technical Integration and Team Resilience * The flexible structure was instrumental in the "ONE COMMERCE" initiative, which required integrating the technical stacks and user experiences of B Mart and Baemin Store. * Because developers had broad domain context, they were able to identify redundant logic across different services and abstract them into shared, common modules, ensuring architectural consistency. * The organization significantly improved its "Bus Factor"—the number of people who can leave before a project stalls—by ensuring multiple engineers understand the context of any given system. * Developers evolved into "domain-wide engineers" who understand the full lifecycle of a transaction, from the customer-facing UI to the backend administrative and logistics data flows. To prevent today's organizational solutions from becoming tomorrow's cultural legacy debt, engineering teams should proactively refactor their workflows. Moving from rigid role definitions to a model based on shared responsibility and cross-domain mobility is essential for maintaining velocity and technical excellence in large-scale platform environments.