I was Chief Digital Officer at Xynteo. This is the digital strategy I wrote for the organisation and then executed, and the part worth publishing is not the strategy document. It is the spreadsheet underneath it.
It began the slow way: seventeen individual interviews, four team interviews and two rounds of internal feedback, plus two commissioned outside reports that were circulated for comment before anything was drafted. That is a lot of consultation for an organisation of that size, and it was deliberate. A digital strategy imposed on a communications team is a document. One assembled from what they said is a plan they will actually run.
Deciding what not to automate
The first section answered a question most digital strategies skip, because the answer is assumed: what should technology's role be here, and what should it not be?
The position we took was that technology had to enhance human interaction, and that automating or delegating the team's interactions with partners would be a mistake — because those interactions were the organisation's strongest differentiator and the core ingredient of its growth.
That is an unfashionable thing for a digital officer to write down, and I would write it again. Every organisation has some interaction that is the actual product, and the value of naming it early is that it becomes the boundary. Once it is stated, "could we automate this?" has a defensible answer that is not simply "no, we like doing it by hand."
Around that sat five principles: be productive, by recovering staff time from work that faces nobody; be delightful, in the interactions that do face partners; be educated, meaning information stored and retrievable, with knowledge management and training treated as infrastructure; be agile, preferring bought software over custom builds while keeping the ability to glue services together; and test and learn, trialling with the teams most affected rather than announcing.
The fourth is the one that has aged best. Buy rather than build, but retain the capacity to connect what you have bought — which is exactly the position I take now, several technology generations later, on a very different stack.
The stack as a schedule
The strategy's companion was a spreadsheet listing every service the organisation used or intended to use: the core accounts, web services, hosting, the publishing engine, forms, the events app, wireframing and app-building options, analytics.
Two columns on that sheet are the reason I am writing about it.
The first is status — is this thing up, or not. Obvious, and almost never maintained anywhere.
The second is a pair of columns per quarter, across two years, marked learn and deploy — with a link to a learning resource for each tool. Not when the software would be bought. When a named person would learn it, and the quarter after, when they would put it into service.
That is the whole argument of this project in one design decision. A stack is not a set of purchases; it is a set of capabilities in specific people, and those arrive on a schedule that has nothing to do with procurement. Analytics learned this quarter and deployed next. Tag management a year later, because there is no point until the analytics beneath it are being used. A wireframing tool paired with a recommendation to mock up one real project rather than evaluate five platforms in the abstract.
Most technology plans I have seen since are lists of tools with owners and budgets. Almost none of them say when anybody will become competent, which is why so many of them describe software that is running and unused.
The channels, and what they were for
The publishing side was ordinary and deliberately so: owned and curated content flowing out through a website, video, document publishing, the professional and short-form networks, a writing platform, paid placement and email — with the website rebuilt in three phases so that content stayed complete and available throughout rather than waiting on a redesign.
What made it a system rather than a channel list was the sequence it was supposed to drive: reach, then qualified leads, then engagement — with the explicit intention of identifying prospective partners through the content and then meeting them offline. And a measurement layer across all channels, so the organisation could learn which kinds of content actually worked for it rather than which performed on a given platform.
Each work area had a defined page structure, and the comms lead on that project was responsible for filling it. Distributed authorship with a fixed shape, which is the only version of a content operation that survives contact with a small team.
What I would do differently
I would have put a review date on the stack.
The learn-and-deploy schedule was built to run for two years, and a schedule with a start and no scheduled re-examination silently becomes a description of the past. The tools that mattered in the second year were not all the ones chosen in the first, and there was no moment written into the plan where someone was obliged to ask which of these we should stop using. Adding a capability is easy to schedule. Retiring one almost never gets scheduled at all, which is how a stack becomes an accumulation.