I recently started working at 18F as their first “comms person” which in a startup environment means you’re the person who does everything, just like everyone else, but you focus on writing blogs, publishing the website, and pitching new ideas for how we might communicate about what we do. Most of my work has been on the
website and a dashboard of all the work we do which has taught me a really important lesson: your website and how it is made, is just as much a communications artifact as anything else your comms team produces.
Despite being on a communications team, I still write a lot of code. Writing code, or being able to jump in and learn some, is increasingly important in all kinds of jobs where people never used to have to write any code, and
communications is no different if only for the simple fact that communications teams often end up owning most of the content and design of their organization’s website and if that website can’t meet their needs it causes rifts of trust between throughout the organization. Be they operational, managerial, or customer facing, a breakdown in trust is toxic and results in the web seeming useless to everyone.
Often this happens because the website was designed and developed to spec by a freelancer or consultant on a one-time contract. An “expert” stands up a shiny looking website that does everything the organization wants it to do, trains a few people how to use it and leaves. Months (days?) later when somebody wants to put more than one photo on a page, they contact the IT
department and are told “pages may only have one picture and it cannot be larger or smaller than x by y dimensions.” (True story.) Software is not static, as people use it, they discover how it can do more for them. Imagine if Microsoft stopped developing Word after it’s initial release. Nobody would use it because it would no longer be valuable.
What an organization can do with its website is mission critical, not just for the communications team. Having a developer available who can make it possible to have more than one photo on your page is as important as having someone who can shoot and edit the photos.
Communications teams should have developers baked in from the start, and not just for adding new features to the website. Having a developer on your communications team means you have someone who an think about and build other artifacts to augment your message. A developer might think to host your website’s code on GitHub, allowing other developers to learn from it and offer feedback, or build an app to go along with a new initiative the team is rolling out, or identify and fix usability problems with some existing piece of the site.
What your website is made of and how it works speaks volumes about your organization, both internally and externally. Internally, it makes your communications team a “yes first” team, or at least one where the reason for saying no to, say, putting more than one image on a page, is a communications one, not a technical limitation. And when there is a technical limitation, you can realistically evaluate whether it’s possible to overcome it.
This doesn’t mean fire your entire comms team or only hire developers, nor does it mean hiring one developer will be your silver bullet. Instead, focus on fostering your team as one that is equal parts traditional communications and software development. Build a team ready to say yes to what your organization needs and not dependent on some piece of technology nobody understands.