The Tech Blog is Dead. Long Live the Tech Blog

5 min Read Time

The HBC Tech Blog: “You will never find a more wretched hive of tech and miscellany.”

There’s an urban legend that maintains that your body replaces its cells every seven years. It turns out that’s not quite true; yet, the sentiment is inspiring, and matches some advice my college professor once offered: every seven years or so, reinvent yourself. We’re excited today to announce that, after seven years of tech.gilt.com, we’re reinventing the Gilt Tech Blog: welcome, friends, to the HBC Tech Blog.

You can continue to expect the same mix of insight, fun and tech miscellany since our first post on tips of optimising iPhone applications back in 2011. Since then, we’ve enjoyed insights like the rule of four; contrite apologies on unintended outages; notes on how to make the perfect overnight cold-brew; the art of delivering the weekly tech update via Haiku; and, the infamous infographic of US stiletto heel-size preference by-state.

We hope you like the new look and new layout; big thanks to our in-house design team! Now, if we still have your attention, read on to learn why we bother writing a tech blog at all, and how we go about about it.

What makes a good tech blog? Freedom, gateway drugs, and raw desire.

While our organisation’s cell structure has changed over time, our core DNA remains the same: we’ve always taken joy in contributing to the wider tech community, be it through speaking, writing or coding in an open and transparent way. That said, it’s good to take this opportunity to perform a retrospective and ask some key questions: why bother writing a tech blog? How do we know it’s working? And, if you’re a tech team considering creating your own blog, how should you go about doing it?

The Gilt Tech Blog started as an experiment in freedom of expression: we granted everyone in Gilt Tech access to publish to the blog (then hosted in Tumblr), without any need for permission or review. The bet was simple: we’d make it easy for the team to publish their thoughts, and trust them to write content that was worthwhile and interesting. The public nature of the blog would ensure that contributions were accurate, fair, and high-quality. Our engineers had already noted that when writing code for open-source projects, the quality of the code was always higher than internal code; we figured the same dynamic would apply to our writing. That bet paid off: we’ve had many contributions from across our engineering, product, data, UX and product teams of very high quality.

When we moved the blog to Github Pages, our publication process matured to a ‘pull request’ model. Authors write articles using Markdown, and can commit ‘gh-pages’ branch to publish immediately, or, seek critical review first through Github’s review mechanism. Generally, our approach to reviewing either code or content is to give transparent and constructive feedback, that the author can choose to ignore or take on board. More often than not, the author takes any critique on board, and the quality of the final article is better than what one mind alone could produce.

The combination of distributed editorial freedom and Github Pages makes the mechanics of publishing easy. The next challenge is: how do you generate the content? Looking back there were a couple of things we did to build blogging into the tech culture.

Encourage: most likely, if you’re still reading, you’ve already got an interest in setting up your own blog. That means you have a few ideas for your first articles, and an initial seed-group of authors. Get stuck in and get your first articles out there.

Celebrate; as articles get shared, posted and liked, share that feedback with your wider tech team. Nothing breeds success like success.

Nudge: We found that, while a core crew were prolific in their contributions, we had a wider group of people in the organisation who had stories to tell but couldn’t get over the hurdle of writing that first article. At the time, we had a dedicated Tech Evangelist, and one of the great things she did was nudge people. She’d watch out for features releases, new technologies we were dabbling in, cultural stories, and off-the-wall observations. Our ‘5@4’ meetings and all-hands presentations turned out to be one of the ‘gateway drugs’ to blogging: anyone who presented at these meetings had already done the legwork to create a narrative around something interesting they were working on. We found that all we needed was a little nudge, and a couple of hours work, to turn that gem into a blog post.

In the early days, we used to track the blog using KPIs like number of views, number of likes, number of articles per month, etc. We don’t tend to do that anymore; still, we do get excited when we see a post getting lots of likes! At this stage, the blog runs itself. That’s a great result. Think about it: in January of 2018 we had four articles posted without asking, nudging, pestering, or cajoling anyone. It’s pretty much down now to the team’s raw desire to share what they’re learning. The blog has become the ultimate, authentic, organisational expression of “this is who we are, this is what we do.”

To our authors, thank you. To our readers, thanks for hanging with us, and, we hope you continue to enjoy the ride. And, to anyone out there setting up your own tech blog, we hope the advice above is helpful in getting started.

Adrian Trenaman, SVP Engineering

As SVP Engineering, HBC Digital, Ade leads the engineering and infrastructure teams for Gilt in New York and Dublin.