The role
I'm the operational bridge between KDCI and Turnitin's in-house creative team, the one point of contact translating whatever a stakeholder actually needs into scoped, sequenced work for the three designers I manage. Output spans event assets like rollup banners, social tiles, and email signatures, campaign ad design, video editing, and whitepaper layout, a wide enough range that consistency doesn't happen by accident.
The problem
That kind of role breaks in two places: briefs that don't survive translation into real production tasks, and output that goes out the door without anyone consistently checking it against brand and technical spec before the client sees it.
What I found
Neither of those problems gets solved by working harder on any single asset. They get solved by building the gate the work has to pass through before anyone else does. Without one, quality depends on whoever happened to be paying closest attention that day, which isn't a system, it's luck. So I built a QA gateway every asset passes through before delivery: brand consistency, technical spec, versioning, no exceptions. Performance management runs against documented SOPs instead of gut feel, so people know exactly what the bar is before they're being measured against it.
What I did about it
The gate only means something if it actually holds when someone tries to skip it. One of my designers started sending work directly to the client without routing it through me first, cutting the QA step out entirely. The errors that QA existed to catch started reaching the client instead. I made the call to let him go. Then I sourced, vetted, and onboarded a replacement inside two weeks, and the client never saw a gap in delivery.
What happened
The QA gateway is still the standard every asset runs through, and it held under the actual test of someone trying to route around it. The two-week rebuild after letting the designer go kept the pipeline intact without the client noticing anything had changed on our end, which is the real measure of whether a system works: not whether it looks good when nothing's going wrong, but whether it holds when someone tries to break it.
This is the clearest proof I have that I don't just design good process, I enforce it, even when enforcing it costs me a team member I now have to replace under pressure. Anyone can write an SOP. What actually matters is being willing to act when someone ignores it, and having a plan ready so that decision doesn't become the client's problem too.