Scaling Operations Through Knowledge Systems
Centralizing fragmented knowledge to improve consistency and autonomy across NY and LA workshops.
Design Operations • Knowledge Management • Process Standardization • Enablement
Role: Initiative Lead / Design Operations
Scope: Knowledge management, process standardization, team enablement
Teams: New York & Los Angeles Workshops
Timeline: July 2023 - Present
Confidentiality note: Due to confidentiality obligations, proprietary processes, technical documentation, and internal materials have been omitted or abstracted. This case study focuses on my approach, system design, implementation, and organizational impact.
Overview
As our U.S. workshops grew, the amount of knowledge required to operate effectively grew with them. Critical information existed across documentation, previous training, individual experience, and the knowledge of more experienced team members.
The challenge wasn't a lack of knowledge. It was that access to that knowledge didn't scale.
I created a centralized knowledge system which is internally referred to as the Marquage* Bible to transform fragmented information into an accessible, evolving resource that painters could use independently.
Initially developed for the New York workshop, the system was later adopted by the Los Angeles workshop, creating a shared operational resource across both U.S. locations.
*Marquage is a French noun that translates into “marking” or “branding”. This term is used within Goyard to refer to the custom personalizations/paintings of client products.
My Role
Initiative Owner • System Designer • Content Strategist
I was responsible for:
Identifying recurring knowledge gaps and dependencies
Defining the structure and organization of the knowledge system
Consolidating fragmented information into a shared resource
Standardizing how recurring information was documented
Introducing the system into the team's existing workflow
Continuously expanding the resource as new needs emerged
Recommending and supporting adoption across a second workshop
The Challenge
As the team grew, knowledge became an operational dependency.
In a specialized creative environment, experience naturally becomes valuable institutional knowledge.
But as the workshop expanded, I noticed a pattern: the same questions were being answered repeatedly.
Painters often needed to interrupt an experienced team member to locate information, confirm a process, or resolve a question, even when the issue had already been encountered before.
That created several problems:
Knowledge was distributed across people and resources
Recurring questions created unnecessary interruptions
Less-experienced team members relied heavily on subject-matter experts
Information could be communicated differently depending on who was asked
Training required people to retain a large amount of information at once
Knowledge became increasingly difficult to scale as the team grew
The more experienced the team became, the more valuable its collective knowledge became.
But much of that knowledge remained individual rather than organizational.
The Insight
Repeated questions were a systems problem.
Initially, recurring questions could be interpreted as a training issue.
But I began noticing that many weren't new questions at all.
We were repeatedly solving problems the organization had already solved.
That shifted how I thought about the problem.
Instead of asking:
How do we make people remember more?
I started asking:
How do we make what the organization already knows easier to access?
That became the principle behind the system:
If we solve the same problem twice, there is probably an opportunity to improve the process rather than continue relying on individual knowledge.
The Strategy
I designed the knowledge system around three principles.
01 . Centralize
Create one dependable place for frequently needed operational knowledge instead of requiring people to search across resources or locate someone who knew the answer.
02. Standardize
Turn recurring answers into shared guidance so established information could be communicated more consistently.
03. Enable
Give team members the resources to resolve known questions independently while preserving escalation for situations that genuinely required advanced expertise.
The goal wasn't to eliminate communication.
It was to change what required communication.
Experienced team members should spend their time helping solve complex problems not repeatedly retrieving information that the organization already possessed.
Building the System
Rather than treating the Marquage Bible as a static manual, I designed it as an evolving operational resource.
Information was organized around how the team actually needed to retrieve and use it.
Because the underlying content is confidential, the simplified architecture below illustrates the approach rather than the proprietary structure itself.
Conceptual Knowledge Architecture
Shared Knowledge Hub
→ Standards & Guidelines
→ Processes & Procedures
→ Training Resources
→ Troubleshooting & FAQs
→ Reference Materials
Conceptual representation. Categories and content have been generalized to protect confidential information.
Designing for use, not just documentation
Simply putting information into one place wouldn't solve the problem.
The resource needed to be:
Easy to navigate
Easy to reference during active work
Clear without requiring additional explanation
Useful across different levels of experience
Maintainable as information changed
Expandable as new questions emerged
This meant thinking about documentation as a product for the team, rather than an archive.
Creating a Knowledge Feedback Loop
One of the most important parts of the system was how it evolved.
Instead of trying to predict every piece of information the team might eventually need, recurring questions became inputs into the system.
Changing the Workflow
The system changed how routine questions moved through the workshop.
The knowledge system changed how routine questions moved through the workshop. Previously, accessing established information often depended on the availability of an experienced team member. By centralizing recurring knowledge, painters could resolve known questions independently and reserve escalation for situations that genuinely required advanced expertise.
This created a clearer distinction between information retrieval and technical escalation, reducing unnecessary dependency while preserving collaboration where it added the most value.
Scaling Beyond the Original Team
The system was initially developed for the New York workshop.
As the Los Angeles workshop grew, many of the same challenges around knowledge access, consistency, and team development became relevant there as well.
I recommended expanding the resource to support LA.
Approximately four months after its initial implementation in New York, the system was adopted by the Los Angeles workshop.
What began as a local solution became shared operational infrastructure across both U.S. workshops.
That expansion also changed how I thought about scalability.
A system that works for one team may rely on assumptions specific to that environment. Scaling required thinking beyond individual habits and focusing on information and standards that could support consistent execution across locations.
Impact
Because the system was not introduced with formal analytics instrumentation, I don't attribute unsupported numerical improvements to it. Instead, I evaluate its impact through observable changes in how the workshops accessed and shared knowledge.
Increased team autonomy
Painters gained a resource they could consult independently rather than relying exclusively on another person's availability.
Reduced dependency on individual expertise
Frequently needed information became part of shared infrastructure, allowing experienced team members to focus more of their attention on genuinely complex issues.
Improved consistency
A common reference reduced the need for information to be repeatedly communicated person-to-person.
Extended the value of training
Training no longer represented the only opportunity to receive information. Team members could return to documented guidance as they encountered situations in practice.
Supported cross-workshop scalability
Adoption across New York and Los Angeles established a shared knowledge resource that could support more consistent ways of working across locations.
What I Learned
This project fundamentally changed how I think about knowledge inside growing teams.
When the same question keeps appearing, the answer isn't necessarily more meetings, more training, or asking people to remember more.
Sometimes the organization needs a better way to retain what it already knows.
I learned to recognize recurring questions, inconsistent information, and dependency on individual expertise as signals of a larger operational problem.
And perhaps most importantly, I learned that becoming the person with all the answers isn't the most scalable form of leadership.
The better system is the one that allows the team to succeed without needing you for every answer.