they knew how
to build it.*
*i wanted them to see everything around the build.
development was familiar.
everything around it was fuzzier.
I partnered with a development team that already knew how to build content in the CMS. What they had less visibility into was everything happening before and after that build.
Instead of dropping another process document into their inbox, I designed an ongoing learning initiative around the full content lifecycle — and started by asking the team what they actually wanted to understand.
how do you teach
the whole system
without teaching
everything at once?
request + planning
scope the request, timeline, impacted content + support.
content creation
write, update, consolidate or archive.
reviews + approvals
coordinate the people who need to weigh in.
development
translate approved content into the CMS experience.
CMS review
check structure, formatting + quality.
publish + document
close the loop instead of just pressing publish.
the gaps became the curriculum.
instead of guessing what the team needed, their questions shaped what came next.
context first
The first session stayed intentionally high-level so the team could see how their work connected to the larger system.
listen before building
Half of the kickoff was dedicated to understanding existing knowledge, friction points and learning priorities.
practice > presentation
Future sessions expanded toward walkthroughs, examples, hands-on practice and real content scenarios.
build for scale
The initiative created a repeatable way to transfer content knowledge beyond the writing team.
sometimes the best way to teach a process is to start by asking what people don't know yet.

