Turning scattered experience into a team's shared language

This page focuses on three layers: how the team operates on its own, how members keep growing, and how cross-functional roles build shared understanding of requirements. What I want to show is not a single management style, but how I turn ambiguous team problems into working systems that can be used, sustained, and scaled.

Core leadership systems

These three systems solve the same problem at different layers: first, make the design team’s daily work searchable and handoff-ready; next, help members accumulate judgment through tasks; finally, extend this clarification method across PM, design, and engineering to reduce cross-functional understanding gaps.

1. Team Operating System: Systematizing daily design-team knowledge

Problem

As the design team grew, the real challenge was not “managing more people,” but enabling everyone to work, learn, and hand off in consistent ways.

In the early team, many things could be handled through verbal sync: how to receive requirements, open tickets, store files, handle marketing or DBC requests, or know whom to confirm with. But as the team grew, collaborating departments increased, and design-request types became more complex, knowledge that lived only in senior members’ or managers’ heads started to block the team.

What I did

I organized Design Workspace as the design team’s operating system, rather than just a document folder. It centralizes information the design team uses daily into several entry points:

• Work entry points: ticket intake, designer capacity, department requests, weekly meetings, quarterly tasks, and work overview
• Processes and SOPs: design workflow, marketing collaboration, DBC collaboration, print-check process, leave and handoff process
• New hire onboarding: new-hire guide, onboarding TODOs, common pages, tool and database instructions
• Resources and assets: asset library, fonts, brand assets, print vendors, accounts, and paid services
• Learning and workshops: Notion, WordPress, time management, visual thinking, product design, AI tools, print file preparation, and other sharing / practice resources

I also broke workflows that had previously depended on tacit understanding into concrete steps, such as:

• How to claim tickets, estimate story points, and report workload before weekly design meetings
• How weekly / biweekly meetings, retros, and workshops should run
• How marketing, DBC, print, and other cross-department requests should be ticketed and scheduled
• How file delivery, archiving, leave, and role handoff should be handled
• How quarterly tasks should be broken into capacity tickets

Cross-functional collaboration also became rule-based rather than relying on ad hoc communication. For example, marketing requests define ticket-opening time, first-version deadlines, finalization deadlines, and revision-response time. When revisions exceed a certain number of rounds, or when the first version differs too much from the requirement, the process moves from comments back to a meeting to realign, preventing designers from falling into endless revisions.

For new hires and consultants, I also split training into “pre-onboarding preparation → same-day practice → post-onboarding follow-up.” Instead of only explaining the process once, they practice opening tickets and using the system, then we follow up on issues that appear during real use.

Change

This approach helped the team stop relying only on verbal sync or senior members. Instead, the team gained a knowledge system that can be searched, trained, and handed off.

• New members onboard faster: They know where to find answers for different work situations without asking from scratch every time.
• Existing members collaborate more consistently: Receiving requests, opening tickets, estimating capacity, delivering files, and archiving all follow shared practices.
• Cross-department collaboration becomes more stable: When requirements are unclear, revisions exceed scope, or timelines are unreasonable, designers have a process basis for communication.
• The team continues learning: Weekly meetings, retros, and workshops turn new tools and methods into a regular team rhythm instead of one-off training.
• The manager is no longer the relay point for every problem: I turn complex work into clear entry points, processes, rules, and learning resources, letting the team find answers and add new experience back into the system.

Once the team had a shared entry point for daily work, I next focused on how members could not only follow processes, but accumulate judgment through each task.

2. Growth Conversation: Turning 1:1s into growth dialogue

Problem

Once the team’s daily operating system was in place, I found another challenge: processes can teach people how to do work, but they do not necessarily help people grow. Members still need opportunities to look back and understand how they make decisions, where they get stuck, and what to practice next.

Designer growth can easily become vague if it depends only on a manager’s impression: “performance has been good,” “maybe be more proactive,” or “some areas need improvement.” These statements may sound reasonable, but they do not always tell members what to do next.

So I wanted 1:1s to be more than status syncs or performance-season feedback. I wanted them to help members break down “I’m stuck” into clearer problems: is it a skill gap, process confusion, unclear communication partner, workload overload, or difficulty judging priorities?

What I did

I established an evaluation framework with five dimensions: task goal achievement, collaboration and communication, professional skill and quality, autonomy and contribution, and learning and growth. But I did not want it to remain only a performance sheet, so I embedded these dimensions into regular 1:1s.

In 1:1s, I first invite members to reflect on their current state:

• Which recent task felt most fulfilling? Was it because the outcome was good, the process was smooth, or they learned something new?
• Which task was completed but could have been better? If they could redo it, what would change?
• Which capability improved recently? How did they notice?
• Is the current blocker about skill, process, communication, or insufficient resources?
• Over the next few months, is there a capability they want to challenge or practice?

I guide members differently depending on their stage:

• New hires: I first check adaptation, tools, and process understanding, such as Notion, ticketing, Design Workspace, and consultant communication. When a new hire is unclear about deadlines or modification tickets, I break the issue into concrete actions: how to open modification tickets, how to fill in capacity, and whom to confirm standards with.
• Interns: I break learning tasks into smaller pieces so they do not stop at “getting familiar with the product.” For example, backend research becomes user stories around clinic front desks, insurance appointments, self-pay booking, and mobile operation, then into tickets that can be completed in half an hour.
• Members already independently owning projects: I guide them to reflect on higher-level capabilities such as process management, cross-functional collaboration, and building stable systems, rather than only completing the tasks in front of them.
• Members under higher pressure: I first clarify workload and sources of stress, then discuss boundaries together. For example, when a member worked until midnight due to revision requests, I guided them to think: which requests need realignment? Which revisions should not be accepted indefinitely? How can discussion move back into group channels instead of private messages?

Change

This turned 1:1s from “manager asks for updates” into growth practice. Members no longer only report what they did; they begin analyzing how they work: what went well, where they got stuck, and how to break things down next time.

To me, management is not directly giving people answers, but helping them build judgment. I break vague feelings into discussable questions, then break complex work into practiceable steps. This is what I value most in leading a team: helping people not only complete tasks, but accumulate new capability through each task.

3. Product Collaboration System: Turning requirements into a product language cross-functional teams can share

Problem

At the time, the company was still in a fast-growing startup stage. Product lines, requirement sources, and cross-functional collaboration models were still taking shape. This allowed fast experimentation, but also made requirement discussions depend heavily on verbal consensus and individual experience.

After the design team’s internal operating model became more stable, I began extending the same method — turning ambiguous experience into shared language — into the collaboration process among PM, design, and engineering. Product development often gets stuck not because one role does poorly, but because PM, design, and engineering do not share the same understanding of the user context, current stage, or definition of done.

If a requirement stays as one functional description, design may jump into solutions too early, and engineering has difficulty judging scope. Late in development, teams often discover they understood the usage scenario, completion criteria, or priority differently.

What I did

I organized and built Product Workspace, centralizing product-development information into one work system so requirements can flow clearly from collection, breakdown, and design to launch. For recruiters, the important point is not that I created more documents, but that I turned the information most likely to lose focus in cross-functional collaboration into a product language the team could share.

Specifically, I consolidated collaboration into several key designs:

1. Build Product Home as the product-team entry point: Centralize Product Board, Request Pool, product-line materials, Roadmap, Release, PM / PD user manuals, and product-development process guides in one place so the team knows where to find product information.
2. Organize the process from requirement to launch: Split the flow into User Requirement → User Story → Backlog → PRD → Product Spec Lockdown → Design Spec Lockdown → Release / Rollout, making each stage’s deliverables, owner, and next step clearer.
3. Use User Story, PRD, and Acceptance Criteria to define shared language: I wanted the team to avoid jumping into feature solutions too early. Instead, we first clarify who needs to accomplish what, in which context, and why it matters. PRDs and Acceptance Criteria define completion conditions so the team does not only finish tasks, but verifies whether the user problem is solved.
4. Create Product Spec / Design Spec lockdown checkpoints: Product Spec lockdown confirms requirements, scope, staging deadlines, and development direction. Design Spec lockdown confirms UI, prototype, interaction states, and engineering boundaries. This means product development no longer depends only on verbal agreement in meetings, but has clear decision checkpoints.

Change

This made product development more than “everyone aligns in meetings.” It created a product language that can be shared, tracked, and handed off.

User Stories help the team confirm the user problem before jumping into solutions. Backlog and PRDs connect requirements, design, and engineering tasks. Product Spec / Design Spec lockdown creates clear decision points for each stage.

To me, the value of product-process design is not adding documents, but reducing cross-functional misunderstanding. When PM, PD, and engineering work within the same information architecture, the team can surface issues earlier, control scope, and push requirements to launch more reliably.

Supporting practices

Beyond the three core systems, I use the same ability — turning experience into method — in different leadership contexts. These are not three separate full cases, but supporting examples of how I continue turning abstract experience into forms that people can participate in, learn from, and transfer.

• Product Culture: Bringing the team closer to users again — Through an “Eat Your Own Dog Food” virtual clinic cross-functional competition, design, engineering, and sales did not only discuss users — they actually played clinic operators and patients. After personally encountering problems, the team formed shared understanding faster and began asking before decisions: “Is this truly helpful for users?”
• AI Enablement: Bringing new work methods into daily team practice — I turned AI adoption into part of the team’s daily learning, not just introducing tools, but using real cases to show how to break down MVPs and validate flows so new working methods could actually be adopted.
• Knowledge Transfer: Translating methods for people with different backgrounds — I also brought internal methods into external teaching and community sharing, practicing how to translate abstract experience into knowledge that people with different backgrounds can understand, learn, and use.

OutcomeFrom individual experience to team systems

Together, these cases point to one kind of leadership: not centralizing all decisions in the manager, and not asking everyone to follow fixed processes blindly, but building a team system that can operate, learn, and collaborate cross-functionally on its own.

I turned the design team’s daily knowledge into a searchable and handoff-ready workspace, turned 1:1s into growth conversations that help members break down blockers and accumulate capability, and turned product requirements into a product language PM, design, and engineering can share.

The result is not a rigid management system, but a work environment that can keep getting stronger: new members understand standards faster, members discuss growth more clearly, cross-functional collaboration becomes more stable, and the team can actively absorb new tools and methods. This is the capability I most want to emphasize as a design manager: not only solving immediate problems, but turning repeated experience into systems the team can continue using.