2021 → 2025
Cross-functional management and facilitation: running a global creative flow on data
Bringing teams across three continents around a single workflow. Imposing one qualified point of entry made it possible to put numbers on the department's performance and to change collaboration habits for good.
For my first two years at Bollé Safety, I was the company's only graphic designer, serving three sales regions spread across different time zones and twelve languages. Requests arrived by email or in person. It took me three months to understand that this would not hold, not for lack of individual rigor, but because no amount of effort makes up for the absence of structure.
Director of Operations - Creative Manager
Operational structuring
What one person had to absorb
The volume did not come from one department but from the whole company. Around ten people in global marketing, two in trade marketing relaying requests from distributors and sales, four in digital: sixteen people entitled to raise a request, against one to handle them.
The nature of the business amplified the flow further. Bollé Safety relies heavily on its distributor network, which consumes assets in quantity, and it also offers its key accounts the creation of internal communication material. On top of that sit trade shows, internal communication, product launches and assets for consumer-facing digital.
A graphic designer joined me after two years, doubling a team that remained undersized.
The cost of an incomplete request
The most expensive problem was not the volume, it was the time difference combined with imprecision.
An incomplete request sent overnight by the United States or Asia-Pacific did not get resolved by a quick exchange. It cost several days of production, the time for the question asked in the morning to find its answer the following night. Across a continuous flow, that structural latency becomes the biggest source of loss.
My first attempt was the task tool built into Teams, chosen for a good reason: it was already available to everyone. It turned out to be insufficient for what I was after, with neither genuinely configurable request templates nor attachable workflows. A tool that is accessible but unable to constrain the request solves nothing.
One mandatory field to start with
Moving to JIRA, I did not try to impose a complete form from the outset. I made a single field mandatory: the due date.
That choice was not ergonomic, it was political. Making the deadline mandatory mechanically produced the data I needed to put numbers on two things that had been invisible until then: how often requests were raised at very short notice, and my actual turnaround time.
The context called for it. In the United States in particular, the wish for a local, self-sufficient design function ran strong, and every argument seemed fair game, including questioning the performance of the existing one. Faced with a challenge built on impressions, what was needed was numbers.
What the numbers showed
Six months after the process went in, 95 % of requests were delivered within the agreed deadline.
The second figure is more interesting than the first, because it measures not my performance but the organization's: the average gap between a brief being published and its due date went from seventy-two hours to two weeks. Put another way, it is not that the creative function got faster, it is that the requesters started planning ahead.
That shift is exactly what the method is for. An overloaded department is not cured by going faster, it is cured by making visible what the way people ask costs everyone.
Getting adoption without authority
I had no reporting line over the regional teams. Adoption therefore rested on two distinct levers, applied to two different audiences.
The first came from reporting. Presenting those numbers in reviews with the Vice President earned me her backing to enforce the process and structure the function. Data produced regularly beats a case well argued, because it turns a request for a ruling into a shared observation.
The second was differentiated. On the sales side, those who kept sending direct emails without a brief received a standard reply pointing them back to the trade managers to have their request qualified. On the marketing side the approach was gentler: I trained the teams on my workflow, to the point where they ended up using it for their own project management. The tool won people over because it also served the people it constrained.
Learning without a mentor
This setup was built with no model to follow. I was introducing agile methods into an industrial marketing department, with no prior training and nobody to help me structure my convictions.
The clearest failure concerned mapping complex projects, with their nested tasks and subtasks. I did not find the useful level of granularity first time, and I proceeded by successive attempts, keeping what actually got filled in and dropping what did not.
This kind of tooling is now common in the creative departments of digital service companies, where agile culture is native. It was far less so in an industrial organization, and that gap explains both how hard it was to install and why it was worth doing.
What the framework became
Adoption on the marketing side was total. It then spilled past its initial perimeter: the product teams, geographically close and reporting to the same Vice President, equipped themselves in turn with a Kanban board.
The setup is still in service at Bollé Safety for managing marketing projects, several years after it went in and after I left. That is the only criterion that really counts for a method: outliving the person who introduced it.
The same reflex, different tools
At Préventimark I transposed neither the tool nor the setup, only the reflex. Steering there runs on Trello, on the free tier, with two distinct uses: a dedicated board where I act as product owner on the strategy and development of our software, and project steering for the company, e-commerce site and production application, rounded out by tracking support, quality and distributors.
One point has to be clear, because it would be tempting to imply an integrated architecture: these tools are connected neither to each other nor to GitHub. They are not the building blocks of a system, they are boards that make visible what needs to be, sized for a company of fifteen people.
That is in fact the lesson I take from it. The method does not live in the tool, which gets replaced, but in the constraint you choose to impose at the point of entry. One well-chosen mandatory field changes more behavior than a complete platform nobody adopts.
Related projects
