An alternate title for this post: “How A Working Content Meeting Saved Me from Broken Toes and Smashed Fingers.”
I used to throw a lot of temper tantrums at work. About ten years ago I kicked my desk so hard my foot started bleeding right through my shoe. I also punched a palm tree, and my fingers swelled up like little sausages (separate and COMPLETELY justified incident).
Since then, I’ve become quite a bit more Zen. One thing still turns me purple and makes that blood vessel in my forehead pop out: The Black Hole of Process.
Everyone’s been there: You set up a project e-mail list, chat room, video channel, Trello Board, BaseCamp site, wiki, weekly phone call, Slack channel, Zapier integrations, shared calendar and Google Drive folder. The team busily creates the stuff. Everyone throws their work into the stew. The process starts.
Fancy video collaboration tools are great. But have you ever, once, used one of those tools without a technical glitch or time wasted figuring something out? Why does every professional say, “Hey, it worked!!!” every damned time they conference someone in on a call? Yeah.
Then comes the question. The death knell. It starts as:
“I thought we were…”
“Can I get back to you next”
“Let me run this by”
“What if we add…”
Anything but “Good to go!” kills all progress. You edit. You resubmit. There are more questions. Again. And again. And again. Eventually, Hell freezes over, or you all start crying, or your boss starts crying, or you all quit.
Why does it fail? Because any distributed, asynchronous process delivers incomplete information. Everyone has to interpret everyone else. Sometimes that’s OK. Sometimes it’s not, because the process grinds to a halt when people are forced to draw conclusions. So snowballs in Hell, crying people, and quitting.
We’ve cured the problem with the Working Content Meeting. This is what you do when you don’t have a writing team at your beck and call. It’s for the 99% of us who rely on domain experts to produce the bulk of our content.
The Working Content Meeting
I’m sure a lot of you already do something like this, but if you don’t, try it:
Get Together
Put everyone in one room. The phone doesn’t cut it. Nor does Slack. You need the face-to-face.
I’m all about using electronic communications. But we’d been passing documents around for weeks. Only when we were all in one room did we get the job done. We could all talk to each other, in person. We could scribble notes and get a real idea of how someone felt about a particular edit or choice.
Set the Goal
Everyone in the working meeting should take one piece of content from draft to final. Keep that in mind as you divide up the work.
Best case, you complete the entire project in one working session.
Worst case, everyone sees completed work. They have a guide for the rest of the work. And they get a full round of instant feedback. Things move forward.
Divide Content into Chunks
Divide your content into chunks. In our case, each chunk was a case study.
But you can break up a single piece of content, too. This process is all about total project size, not number of pieces. If it’s significant enough to warrant a team, go for it.
Examples:
- Any project that requires a writer and a designer. You can get together and hammer out the finished product
- Any content that has many chapters or sections, like an ebook or longform piece
- A long script or presentation
- Multiple-blog-post projects
- A blog post plus social media posts to promote it
Set Up the Status Board
Set up a status board. It’s important that the board is visible to everyone in the room. So it can’t be a spreadsheet on a screen. If you’re a smartypants, use a projector. But that’s a lot of work for something you’ll use once and erase.
On the board, write these columns:
- Name of content chunk
- Assigned person
- Writing
- Editing
- Stakeholder review
- Formatting
- Complete
List every chunk. You’ll track them all here.
The working content session whiteboard
Determine the Stakeholder
Determine a single stakeholder. A single one. For this meeting, they’re in charge of what’s good and what’s not.
The stakeholder should have the best general knowledge of the tasks and subject matter. In the case study session, I was the stakeholder. I understood what I wanted, and leaving other people to guess was how we’d ended up going in circles.
The stakeholder gives both instant feedback and the final review. They’re also there to answer questions as they come up. During our session, someone could just say “Ian? Can you come look at this?” and get instant feedback.
Pick a Formatter
The formatter ensures all edited content has a consistent look and feel. In our case, that meant one person laying everything out in the same Google Doc template.
I can hear you from here: “Pshaw, Ian. The writers can do the formatting.”
They can, but they should focus on writing, not formatting. Make it a separate task assigned to another person.
Assign Each Chunk an Owner
Assign each piece of content (I get tired of typing “chunk”) to one person. Their job is to create the first draft and shepherd everything through the process.
Each piece should be small enough to ensure at least one per writer can move through the entire workflow. Everyone must complete at least one chunk in the session.
That way, even if you don’t finish the entire project, everyone has a completed example. With that, the team can continue on their own or schedule another working session.
Assign Each Chunk Two Editors
Each chunk then gets two editors. Every writer is also an editor. That distributes editing. Some people are better at editing than others. If you have a team with one or two rock-star editors, dedicate them to that job and don’t have them write.
But mixing writing and editing keeps everyone mentally fresh.
Get To Work
Time to get to work. Here’s how the process looked:
Owners started writing. As they finished, we marked progress on the board. It was a nice burst of dopamine. It also ensured everyone knew when each chunk was ready for editing.
Both editors reviewed a chunk at the same time, looking over each other’s shoulders. I’ve seen programmers try to write code that way, and it’s a nightmare. But for editing, it worked pretty well. With the non-linear approach, they weren’t editing over each other or undoing the other’s work. And there were no round trips between editors. It was all done in one go.
We passed documents around via Slack. They were Google Docs, so the work-in-progress also “lived” on Google Drive. That let the whole team look at each document at the same time.
Editors passed the edited work back to the owners, who signed off on the edits. The stakeholder gave a final review, and then it went to formatting.
The Outcome
In four hours, we wrapped up ten case studies and started three more. The completed pieces were ready for use.
Why It Worked
Another meeting seems like it would kill efficiency. It didn’t. The working content session got us over three frustrating speed bumps:
- It pooled team skill sets. Little questions and tasks ended up in front of the person who could best handle them.
- No question got asked twice. The whole group heard the answer.
- The entire team got immediate answers to blocking questions and stayed in flow.
Warnings
Here’s a tricky part: Everyone can interrupt everyone else. If I was writing and someone had a question, they could stop me. If I had a question about Google Docs, I could interrupt our expert-in-residence, even if he was writing. It wasn’t chaos. We were all mindful of each other’s workload. But there were a lot of interruptions.
Also: Don’t make this a single-issue session. I am Conan the Grammarian, so I dove right into grammatical correctness. I drove everyone crazy with that and, for a while, ignored everything else. I didn’t get shoved out a window, but I’m pretty sure the team considered it.
You have to let the writers and editors do their work.
The Result
This is all about Lean. By getting a team working as a team, you pick up speed. A lot of speed. You find where the process was breaking down (because every process does). You pause your normal process and crush ambiguity. Content gets done, and you can jump to the next step: Publishing.
Try it. If you have a workflow like this, let me know in the comments. I’m curious to see how other teams do it.
The post Working Content Meetings May Just Save Your Toes appeared first on Portent.
// // from The Portent Blog: Internet Marketing with a Twist of Lemon https://www.portent.com/blog/content-strategy/working-content-meetings.htm
0 comments:
Post a Comment