At the time Patricia Mayo worked with NowSourcing, from the end of 2007 into 2008, they were a broad-based (“full stack”) digital media marketing firm, coming up with original creative material, delivering fan bases in social media, and developing web properties.
They were a small team spread out around the world, with an admirable and strict ethos: nobody works on Saturdays, and collaboration is required.
The Problem Looked Like…
There’s a lot of talking about what’s going on, and sometimes details are forgotten until the last minute. Sometimes until after the customer reviews it.
The rework grew into the whole job.
And yes, there were meetings about meetings — because we could never go as a whole company to meet with clients.
Breaking the Bottlenecks
If mistakes are being made, then we need to first reclaim time to really look at the root of those mistakes.
If you worked there, have a guess: What might be the most you would email or message with your higher-ups and colleagues, on a daily basis? Both outbound and inbound?
When I first started, the message stream — at least for my work as a collaborative social media strategist at NowSourcing — counted well into the hundreds every day. Yes, there was ‘training’ involved, primarily through links to all kinds of things, in those messages.
However, the ‘training’ never stopped.
After the very first implementation of OMASSIS, that maximum number, was 60.
And as it happened, the root of those mistakes was not keeping the data in a central but distributed place. Which is exactly what was implemented, but as a time-saving solution!
OMASSIS v1: “The Wiki”
The main thing taking up so much time were all the “quick questions,” because only one person had the data they needed right that moment. So, Patricia proposed a radical thought — writing it all down, in a way you could check regularly but not be interrupted.
And the Wiki, as a Kanban on GTD, was born. It had an inbox first-blush that you just couldn’t ignore, and otherwise, a place for everything, interlinking everywhere by person and status and contexts. In short — it was painfully useful.
You had to double-enter everything, but it was copy and paste once you finished writing it in the first place. And of course, you had to be able to write in Wiki markup.
But we figured out, if we put all the content writing stuff, all the Twitter stuff, all the coding stuff and so on and on all on each their own page — it all gets done very predictably.
And if we have all the client’s stuff linked to one page, Brian Wallace — or anyone they get at the company — can update the client without incident, no matter when.
For sure there are programs that do similar things, but not quite to this level. Because we could put images anywhere we wanted, that meant we could basically keep all the originals in it too. That was tremendous.
Do you remember the big data battles of 2007? Those were still in full swing. Having multiple applications to accomplish work, could get surprisingly expensive. One little wiki that could just back up on Wi-Fi later — that fit the bill for everyone. But only because we were already code-Savvy.
Results
With the messenger load dropped by a full zero, and meetings for the team dropped to zero, and dropped initiatives down to zero — effective output grew 5-fold.
Parricia Mayo went from turning around 2 Twitter accounts per month, to 5 in a week. Articles, 1 a week, to 5 in a week. And working fewer hours. Within 2 weeks of beginning the implementation.
Spreading Thought 