How I got a PR agency to the top of Google’s search results

In January 2014 I started work at the financial and corporate PR agency, Hudson Sandler, as head of digital. One of the projects I worked on there was revamping the agency’s website, which was sorely out of date and failing to generate any inbound sales enquiries because it was not appearing in search engine results for any relevant terms.

I started work on this project in autumn of 2014 and by the time I left the agency in summer 2015, the website was on the front page of Google for many relevant search terms, and right at the top of the results for key terms such as ‘financial PR agency’ and ‘corporate PR agency’. During that period the monthly traffic increased exponentially and the site began generating lucrative sales leads for the agency.

My budget for this project was £0, and there are dozens of much larger UK agencies competing for those search terms.

So how did I do it?

The first step was to move the site from static HTML pages to a content management system that would make it easy for us to add and edit content, so we migrated the old site to WordPress with a modified off-the-peg template to match the agency’s branding. I also installed an SEO plugin which automatically generated sitemaps and allowed me to manually edit page titles and meta-descriptions.

Next I overhauled the site’s static content. PR agencies tend to favour fluffy, strategic sounding language which is absolutely no use for SEO purposes – search engine algorithms aren’t good at deciphering marketing doublespeak. So I rewrote as much of the content as possible with clear, descriptive copy about the agency and the services it offered. I also made sure that the site had plenty of internal links with descriptive anchor text.

In addition to the static content I introduced a blog to the site so we could regularly post updates about the agency and thought leadership pieces, this was central to the whole approach. Over several months we wrote a lot of blog posts that were tightly focused on our key subject areas of financial and corporate PR. This doesn’t mean churning out copy stuffed with keywords, but simply that the articles were all specifically about different aspects of the topic at hand.

This meant that when Google’s algorithm looked at our site, it would find lots of content and language that is highly relevant to that topic. It was also important that the blog posts were genuinely useful and interesting for the target audience for a couple of reasons:

  1. This would increase the chances of them being shared on social media and linked to from other sites, which is good for SEO
  2. If the articles are of poor quality visitors will not spend very long on the page, and this can have a damaging effect on the site’s performance in search engines

I also made a point of writing lengthy blog posts of around 1,000 words or more where possible, because most SEO experts believe that longer articles are better than 400/500 word blogspam. Writing a lot of good quality, on-topic, long-form blog posts is hard work, but there are no shortcuts here, your site’s search engine rankings depend on great content, so you need to put the effort in. The results we achieved prove the value of that.

Having fixed the site’s structure and greatly improved the quality of content, there was one final piece of the puzzle to solve; backlinks. Your site’s SEO is highly dependent on both the number and quality of links pointing to it from third party sites. In short, you need as many links as possible from high authority sites (i.e. websites belonging to established media, big corporations, government, academia and other respected sources) and this is very hard to achieve.

This is where we relied on good old fashioned PR skills to charm and persuade people to link to our site. We asked clients to link to us from their online press centres, we created stories which gave the trade media good reasons to write about us, and we came up with a few other creative ways of getting links from authoritative third party sites. As with the content, there are no shortcuts here any more; if you want good quality links to your site, doing the legwork is the only way to make it happen.

And that’s pretty much the long and short of it. Using Google Search Console we were able to track how our site was appearing in search results and we noticed an almost immediate improvement, but it took a couple of months before we started to see our site at the top of the results for relevant search terms. Over time, as we added more content and secured more links, the results got better and we began to inch out major competitors for our most important search terms.

If you take away anything from this story it should be this – everything I did was relatively simple. Sure, it’s hard work to create a pipeline of good content and to get lots of quality backlinks but there’s no dark art to any of it, you just have to put the hours in.

How I built Conway’s Game of Life in JavaScript

EDIT (MAY 2016): Since writing this post in July 2015 I noticed it’s started to get a bit of traffic from Google. If you’re just interested in the end result, here’s a JSFiddle of my final version of Conway’s Life.  That version has cleaner and more slightly more optimised code than shown here. Original post below:


I’ve recently been focusing on strengthening my JavaScript skills. I used a few JS snippets when I built Influential Blogs a couple of years ago, but it was mostly code I cut and paste from the web to solve specific challenges – the bulk of the site was built on PHP.

The best way to learn a language is to build stuff, so the first challenge I set myself was to build a version of Conway’s Game of Life. It’s a simple concept; the game consists of a grid of cells, each of which can be alive or dead. For every cycle of the game, the cells can be turned on or off based on the following rules:

  • If a dead cell has exactly three live neighbours, it comes to life
  • If a live cell has less than two live neighbours, it dies
  • If a live cell has more than three live neighbours, it dies
  • If a live cell has two or three live neighbours, it continues living

By repeating the cycle over and over, these simple rules create interesting, often unpredictable patterns. I was fascinated by the idea as a kid and wrote a few versions of it in Basic on my ZX Spectrum, so it seemed like a good place to start with JavaScript.

Step 1 – Creating the grid

The grid of cells needs to be stored somewhere, so my first job was to create a two dimensional array. This was an instant stumbling block because I learned JavaSript does not support multi-dimensional arrays. However, I learned I could solve the problem easily because each element of an array can be any type of variable, including an array so, for example, I could create an array of 100 elements, and each of those would contain another 100 element array, which would give us a 100 by 100 cell grid to work with.

function createArray(rows) { //creates a 2 dimensional array of required height

var arr = [];

for (var i = 0; i < rows; i++) {

arr[i] = [];

}

return arr;

}

This function returns an array with n elements and places an empty array in each of them using a FOR loop. We don’t need to worry about specifying the number of elements in those sub-arrays, because JavaScript lets you dynamically add new elements to an array. This means we can simply add as many variables as we need when we populate the grid.

We can now create our grid by calling this function and assigning its output to a variable:

var theGrid = createArray(gridWidth);

gridWidth is a variable defined earlier in the code simply stating how big we want our grid to be – I wanted this to be easy to change because I didn’t know at this stage how quickly the game would run with large grids.

Step 2 – Populating the grid

For the sake of simplicity I wanted the starting game state to be random. So I wrote this function to randomly populate the grid array with ones and zeros, live or dead cells. Since the theGrid is a global variable (more on this decision late), we don’t need to pass anything to this function or return anything from it, we just call it directly after we have created the array.

To make this work, I had to learn how to do random numbers in JavaScript. Math.random() returns a floating point number between 0 and 1, so I poked around on StackExchange to learn how to convert that into the nice clean 1 or 0 that I wanted to fill each cell with.

function fillRandom() { //fill the grid randomly

for (var j = 0; j < gridHeight; j++) { //iterate through rows

for (var k = 0; k < gridWidth; k++) { //iterate through columns

var rawRandom = Math.random(); //get a raw random number

var improvedNum = (rawRandom * 2); //convert it to an int

var randomBinary = Math.floor(improvedNum);

if (randomBinary === 1) {

theGrid[j][k] = 1;

} else {

theGrid[j][k] = 0;

}

}

}

}

Step 3 – Drawing the grid on screen

At this stage I had only really learned core JavaScript and didn’t know anything about Canvas, other than I should probably use it for any kind of graphical output. I needed to write a function to draw each grid cell in the array as a pixel on a Canvas, so I asked the internet how to draw a single pixel on a Canvas, and then cannibalised that code to work with my drawGrid function. I hard-coded the Canvas size to 400 by 400, because I didn’t envisage using a grid larger than that and I could use a smaller grid without changing the Canvas dimensions.

function drawGrid() { //draw the contents of the grid onto a canvas

var c = document.getElementById(“myCanvas”);

var ctx = c.getContext(“2d”);

ctx.clearRect(0, 0, 400, 400); //this should clear the canvas ahead of each redraw

for (var j = 1; j < gridHeight; j++) { //iterate through rows

for (var k = 1; k < gridWidth; k++) { //iterate through columns

if (theGrid[j][k] === 1) {

ctx.fillStyle = “#FF0000”;

ctx.fillRect(j, k, 1, 1);

}

}

}

}

Step 4 – Update the grid

Now I’ve created a grid, randomly populated with living and dead cells, and drawn that grid to the screen. The next thing I need to do is apply the game rules to the current grid state, switching the cells on or off as required to create the subsequent state. This is the main chunk of game-logic.

It was easy enough in theory: we simply look at each element in theGrid array, count up the number of live cells around it (each cell has a total of eight neighbours which could be dead or alive) and then use that total to decide whether the current cell lives or dies.

The problem this creates is that you cannot update theGrid array as you’re doing this, because if you change the state of a cell that means the you’ve changed the state of the grid before you’ve finished updating all of the other cells.

The way I tried to get around this was by reading the current state of the grid from the Canvas, so I could update theGrid array whilst referencing the as-yet unchanged game-grid on the screen. Simple, update the entire array, redraw the Canvas, repeat.

I learned that the Canvas method, getImageData(), would allow me to get the current state of each pixel in the grid, so I used that to calculate the total number of live neighbours for each cell. I thought I was being clever and efficient by using this approach – I was wrong. It turns out that reading from and writing to the Canvas is relatively slow, and even using this approach for a small 100×100 grid was clunky, with maybe one or two updates per second.

So I switched to the obvious alternative – using two arrays: theGrid holds the current state of the game board, and a second array mirrorGrid is used in the update function to store the new state of the board. Once the board has been completely updated, the contents of mirrorGrid are copied to theGrid ahead of the screen being updated. The performance was instantly and significantly improved – even on a much larger grid the update cycle ran at least ten times faster.

Here’s the function which performs this:

function updateGrid() { //perform one iteration of grid update

for (var j = 1; j < gridHeight – 1; j++) { //iterate through rows

for (var k = 1; k < gridWidth – 1; k++) { //iterate through columns

var totalCells = 0;

//add up the total values for the surrounding cells

totalCells += theGrid[j – 1][k – 1]; //top left

totalCells += theGrid[j – 1][k]; //top center

totalCells += theGrid[j – 1][k + 1]; //top right

totalCells += theGrid[j][k – 1]; //middle left

totalCells += theGrid[j][k + 1]; //middle right

totalCells += theGrid[j + 1][k – 1]; //bottom left

totalCells += theGrid[j + 1][k]; //bottom center

totalCells += theGrid[j + 1][k + 1]; //bottom right

//apply the rules to each cell

if (theGrid[j][k] === 0) {

switch (totalCells) {

case 3:

mirrorGrid[j][k] = 1; //if cell is dead and has 3 neighbours, switch it on

break;

default:

mirrorGrid[j][k] = 0; //otherwise leave it dead

}

} else if (theGrid[j][k] === 1) { //apply rules to living cell

switch (totalCells) {

case 0:

case 1:

mirrorGrid[j][k] = 0; //die of lonelines

break;

case 2:

case 3:

mirrorGrid[j][k] = 1; //carry on living

break;

case 4:

case 5:

case 6:

case 7:

case 8:

mirrorGrid[j][k] = 0; //die of overcrowding

break;

default:

mirrorGrid[j][k] = 0; //

}

}

}

}

//copy mirrorGrid to theGrid

for (var j = 0; j < gridHeight; j++) { //iterate through rows

for (var k = 0; k < gridWidth; k++) { //iterate through columns

theGrid[j][k] = mirrorGrid[j][k];

}

}

}
Step 5 – Creating the game loop

Now I’d written all of the main components of the game: create a grid, randomly populate it, draw the current grid state on the screen, update the grid by applying the rules to each cell. What I wanted to do next is run the updateGrid() and drawGrid() functions in some kind of loop so the board would keep updating for as long as I wanted.

At first I tried simply setting up a FOR loop and calling the two functions within it for a hundred or so iterations, but this didn’t work. The code would either hang completely or take a really long time to draw just one frame before hanging. I didn’t understand why the drawGrid() function wasn’t working every time I called it in the loop.

The internet rescued be again and I learned about requestAnimationFrame(), which is ideal for this kind of problem because it makes the browser update the screen whenever it’s called. So, the function to run the game loop infinitely is like so:

function tick() { //main loop

drawGrid();

updateGrid();

requestAnimationFrame(tick);

}

When function tick() is called, it first draws the current state of the grid, then updates the grid, then tells the browser to update the screen and calls itself again to repeat the loop. So the flow of the code goes like this:

  1. Create an array to store the grid
  2. Create a mirror array to use when updating the grid
  3. Fill the grid with random cells
  4. Draw the current grid state to the screen
  5. Apply the rules to each cell and update the grid
  6. Keep repeating the last two steps

You can see the complete code in action here: http://jsfiddle.net/xcs1y127/10/

Obviously there are lots of refinements that could be added, such as allowing the user to pause the game, reset the grid, draw their own patterns on the grid, etc, but at this stage all I really wanted to do is get a functioning version of Life up and running. I’ll add in all the window dressing as my next project.

Performance improvements

The first thing I was keen to do is find out if there were any ways in which I could make the code run faster, so I could use larger grids without sacrificing update speed. Switching to the two-array update approach I mentioned in step 4 really made a huge difference to performance, but I thought I could learn a few things about code optimisation by trying to squeeze any additional performance from my code.

The first thing I learned was that you can use console.time() and console.timeEnd() to find out how much time different parts of your code take to execute, so I tried using it on my functions while I experimented with potential optimisations.

I read that using locally scoped variables in functions is faster than global variables, so I tried making local copies of theGrid array in both the updateGrid() and drawGrid() functions, but this didn’t seem to make any discernible difference to the execution time of either.

I’ve also read an article about pre-rendering to an off-screen Canvas before writing to the on-screen one, as this apparently improves performance, although I haven’t yet tried it as my Canvas knowledge is still shaky.

I was hoping that there would be some easy performance tweaks I could make to the updateGrid() function, as this is clearly where most of the work is taking place, but I’ve not learned anything yet that will help with that.

(EDIT MAY 2016: I tried this off screen rendering method eventually, but it made almost no different to performance. At this stage, the only way I can think of to make a JS version of this game to show significant performance is to use a better algorithm for updating the grid. I recently read about the “List Life” approach, which speeds things up by only updating the parts of the grid which feature live cells, instead of checking every single cell on each iteration. It sounds interesting, but i haven’t had time to give it a try yet. Please let me know if you produce a JS version of this, I’d love to see it. )

The real difference between working in PR and journalism

I’ve been in PR for nearly ten years and was lucky enough to join the industry just as it started to become entangled with digital and social media, which enabled me to carve out a little niche for myself as a digital specialist since I happen to have a bit of experience in the online world.

Before PR I was a tech journalist for 13 years and, to be honest, it still sometimes feels strange not turning up to an editorial office every day.

When people ask me why I made the leap, I usually tell them that it seemed like the most logical progression, but the truth is that PR is a very different world to the kind of tech-magazine journalism I spent much of my life doing. I don’t feel like I made any sort of logical, smooth progression, I feel like I jumped right into the deep end of a completely new career.

The most noticeable change in your day to day life is that people stop treating you like you’re important, but I think all but the most deluded of journos would expect that, so it’s not worth dwelling on. There are other changes that I was less prepared for.

When I was a hack I lived in a little bubble that was protected from any kind of commercial reality, all I had to worry about was producing great articles and meeting deadlines (or at least, not missing them by too much). Most of the tech magazines I worked on had an atmosphere that was somewhere between a playground and a laboratory – lots of smart people in a room together, having fun and challenging each other. The suits always took care of the business side of things for us.

In a PR agency, you’re acutely aware from day one that you need to earn your keep: all that really matters is getting good results for the client and winning new business for the agency. This may seem perfectly obvious, but it can be a serious culture shock for somebody who’s only ever been judged on something as subjective as how well they can write.

When I was a journalist I was largely free to manage my own time as I pleased, so long as I showed up to the office occasionally and the work got done on time. PR agencies require their staff to fill in timesheets to account for every minute of their day because their staff’s time is, essentially, their chief commodity and they need to keep track of it closely. In all honesty, this is the one part of the PR industry I have always struggled to adjust to. I completely understand the need for it, I just hate having to do it.

Journos going into PR at a junior level are probably better equipped for the move, because they are most likely to be focusing on getting coverage and if they’ve got good contacts in their industry they’ll probably do quite well. At the more senior levels, it’s a different game entirely.

Firstly, you have to deal with clients, who can sometimes be difficult and demanding – they’ve invested significant budget in your agency, and they’re depending on you to do a good job, so they’re understandably going to want to make sure you’re doing your best to deliver on your promises, so that they can deliver on the promises they’ve made to their boss.

Secondly, you need to learn a lot more about budgeting and project management. Putting a magazine together has its own challenges, but running PR activities for major corporations requires a completely new skill set.

Finally, you have to learn to pitch and win new business – it’s a steep learning curve, and often requires the same kind of all-hands-to-the-pump attitude that magazines go through on deadline week. It’s good fun though, and the buzz you get from working on a winning pitch is one of my favourite things about the job.

One of the most interesting differences between journalism and PR is the attitude to creativity. All PR agencies strive for creativity, they hold brainstorms and run training sessions and hire consultants to help their teams be more creative, while on all of the magazines I’ve worked for, creativity just happens by itself.

I think the reasons for this are pretty much everything I’ve outlined above – it’s easier to be creative when there’s a distinct lack of pressure in your working environment. Obviously, PR agencies need that pressure, they need to get results for clients, win new business, track their staff’s time and all the rest of it, but ultimately that makes it so much harder for people to be as creative as they could be in a more relaxed atmosphere.

(Image credit: Ritesh Nayak)

Who is Britain’s greatest tech hero?

I recently ran a survey for a client to find out who people think Britain’s greatest technology pioneer is – and since the idea never got used, I thought I’d share the results here. We used Google Consumer Surveys to ask 1,000 UK internet users who Britain’s greatest tech hero is and gave them a list of some of the most obvious contenders, as well as leaving an open option for them to suggest other pioneers.

It’s completely unscientific and just for fun, but I don’t think people would disagree with the findings too much.

Greatest Tech Hero - Overall

It’s hard to argue with Alan Turing taking the top spot, although some might wonder whether Clive Sinclair deserves more votes than Tim Berners-Lee. That said, we shouldn’t underestimate the impact that the ZX Spectrum had on an entire generation of techies, inspiring millions to experiment with their first computers and learn about coding.

What surprised me was that there was such a slim margin between the top four – even today it still seems that people value the early contributions to computing made by Charles Babbage and, to a lesser extent, Ada Lovelace.

The results become a little more interesting when we look at the difference between male and female votes. First, if we focus on the results from the 320 women who participated in the poll we see very different rankings – women really seem to rate Sir Clive.

UK Tech Hero - Women

Male voters, on the other hand, were more likely to rate Alan Turing as our greatest technology hero.

UK Tech Hero - Men

How I learned the importance of backup, the hard way

When I left school my first job in 1991 was a Production Runner for a TV gameshow being filmed in northwest England. This role is TV’s equivalent of an office gopher, and you’re expected to help with whatever jobs the production team needs a spare pair of hands with.

Part of the job was to keep a file of all of the hundreds of people who’d applied to be contestants on the show, and my boss made me painstakingly fill in a paper form for each person and store it in a lever-arch file. This was far too laborious and old school for my 17 year old tastes, so I convinced the grizzled old producer that we should create a database on the office’s solitary PC, which would streamline the entire process.

He agreed, but insisted that I continue with filing the paper forms, which left me tearing my hair out. The stupid old duffer clearly didn’t understand the point of technology was to reduce work, and now I’d ended up adding extra work to an already painful job.

Nevertheless I pushed forward and created the database to demonstrate that it would be more efficient and useful than the paper system, and pretty soon we had a database of hundreds of applicants. The team were impressed to find that it was suddenly much easier to search through the applicants to find the ones with the attributes they were looking for – I took this as a small victory but was still pissed off that I had to keep doing the hand-written forms.

I sulked and complained and repeatedly told my boss it was a complete waste of time writing out the forms by hand when I was already entering them into the database much more quickly. But he was from a different generation and while he admitted that the database was useful, he’d feel more comfortable if we had paper copies of everything.

And then, one day, disaster struck. The team wanted me to help them search for some new contestants through the database of applicants, but somehow the 5.25inch floppy disk which stored the data had got corrupted and everything was lost. I was 17 and this was my first job, I’d never suffered a catastrophic loss of data before, so it had never occurred to me to create a backup. The disk worked and I had no reason to believe it would ever stop working. Nobody had taught me about the importance of backup, so I’d had to learn the hard way.

I felt utterly humiliated. I spent a whole week working late to re-enter the data, and sulkily admitted that my boss had been proved right all along – without the paper copies we would have been screwed. Could have saved myself a lot of trouble by spending ten minutes making a couple of copies of the database.

How to write brilliant long-form blog posts

Image credit: JM3/Flickr
Image credit: JM3/Flickr

If you work in PR or any kind of social media marketing, you probably need to write a lot of blog posts and I’ll bet that most of them are no longer than about 400-500 words. Conventional wisdom is that people don’t read long articles online and this kind of length is ideal for SEO purposes.

That’s not really true anymore. SEO experts largely agree that long-form articles perform better in search engines and, while there are no hard and fast rules, broadly speaking you should be writing at least 1,000 words per blog post to get better results. For more serious, in depth reports, you should be thinking about word counts closer to the order of 3,000.

The idea that people don’t read long-form articles online is also outdated. This thinking harks back to a time long before smartphones and tablets, when people only accessed the web on their PCs. It made sense that nobody wanted to read long articles on their PC screen, but these days people are much more likely to read a long article on a tablet or phone, away from their desk.

The truth is that any idiot can churn out 400 words on almost any topic (although plenty of people still do a terrible job of it). That’s why the internet is full of low-value, spammy content, and the public relations industry is especially guilty of this. We charge by the hour, and good quality content takes time. We give junior execs tight deadlines to write about complex topics which they don’t understand in order to meet targets, and the end results are flimsy blog posts that nobody wants to read.

Writing good quality articles of any reasonable length is a lot harder, you’ll need to go into a lot more detail about the topic and any gaps in your knowledge will become painfully obvious. And that’s really the point here; long form articles tend to be higher quality, not just because they have more words, but by virtue of the fact that in order to write those extra words the author has probably had to do a lot more research, has a better knowledge of the topic, and is most likely simply a better writer.

How PR people get long form articles wrong

Most public relations people approach blog posts in the same way as press releases, which follow the time honoured ‘news pyramid’ format. This starts with a concise, pithy headline, then all of the most important facts about the story in the first paragraph or two, followed by an increasing amount of supporting information, quotes and extra context as we get further into the article.

The problem with this style of writing is that while it works well for news stories, it’s not so good for long form articles. When you get most of the ‘story’ across in the first few lines, it’s easy to run out of things to say and you’ll find yourself padding out the article with pointless filler, desperately trying to hit the wordcount.

A good way to approach long form articles is to turn the news pyramid on its head. Start by outlining the topic, what are the major issues, what’s the background, who does it impact, how is it likely to be relevant to the reader? Flesh out your main points with plenty of context – is there any independent research with statistics and facts you can cite to support your arguments? What have other people said about the same issue? Add in relevant quotes from prominent commentators, experts, and journalists, and consider how their viewpoints could be used to add additional detail to your article. Alternative, conflicting opinions are great sources of additional material and will add balance to your article.

The important point about all of this is that nothing you add to your article needs to be padding – you can always find something else to add value, a little extra information that helps paint a picture or make a point without resorting to unnecessary verbiage. But think again about that inverted news pyramid. As you construct your article you should be moving down from the broad scene-setting and context-adding towards the fundamental point that you want to make.

Planning is essential

When you’re writing longer articles it’s not enough to simply brain dump your thoughts onto the page and then tidy the copy up afterwards, you need to plan the piece out. People in the PR industry talk a lot about ‘storytelling’ and this is where you really need to put that skill into practice.

To start with write down bullet point versions of all the areas you want to cover, then try to arrange them into a logical structure. Does each point flow naturally onto the next, towards the articles ultimate conclusion? Are there any glaring gaps in the flow? If there are any areas where one part of the discussion does not seem to move seamlessly from one point to the next, this is a good sign that there are some missing pieces in your story which need to be filled in, and this will help you add more to it.

Next take a look at all those bullet points and flesh them out with supporting notes. Think about what you’ll need to cover in each of those sections to tell the full story and explain each point clearly. Again, during this process you’re likely to notice things that are missing or don’t entirely make sense, and this will help you to not only get your word count up, but also write a better blog post.

Now that you’ve done the hard work of thinking out the structure and overall content of your post, actually writing the copy should be relatively straight forward. It’s always harder to start with a blank page, after all.

Once the first draft is complete, hopefully you’ll find that you’ve got both a well written article that flows well, and also a high enough word count without the need for any pointless filler material. Read it through, check again if anything’s missing, fill in the gaps. But it’s equally important to remove any fluff that doesn’t need to be there – you might not want to reduce the word count, but let’s not lose sight of the aim, to produce a great article. A higher word count might help with SEO, but consistent writing great articles that are a pleasure to read will help even more. If you have to choose between quality and quantity, the former should win every time.

How I tried and failed to set up my own PR agency

After three (mostly) happy years as the head of digital at Text 100 UK I was lured away to a competing agency to do a similar job, for similar clients, for a lot more money at the beginning of 2013. For one reason or another things didn’t really work out and after four months I was politely given the boot. They were decent enough about the situation, but it was hard not to be frustrated – I thought I was good at my job, things had gone pretty well at all the other agencies I’d worked for, but this time it just didn’t click.

My confidence took a bit of a kick in the balls and for a while I wasn’t sure about what to do next, but pretty quickly I decided to have a crack at setting up my own digital PR shop:

image

My plan was this: I’d charge low rates and deliver great results, rather than pouring a lot of resources into conventional media relations campaigns, I’d use social media and digital technologies to help my clients make a splash without relying on mainstream media. I’d do bold, edgy work that only required creativity and brave clients to succeed.

So I did a bit of networking and landed a few clients, and that’s where it all started to go wrong. Typically clients would buy into my proposition, but once the work got started they would really just want me to deliver traditional PR activity – which wasn’t really what I wanted my business to be about. Although I will admit to a giddy rush of excitement when I landed one of my clients in the Telegraph.

I had hoped to do alternative, edgy work to get clients noticed, but that’s asking them to take risks they might not be ready for. One of my first clients was a datacentre and cloud services business – we agreed that churning out the same old dry thought leadership pieces wouldn’t be particularly useful, because companies with bigger budgets would win every time. So I agreed with the marketing manager that we’d try a different angle, and I wrote a bunch of articles about how a decent cloud-based backup strategy could have saved the Death Star, or what Breaking Bad can teach you about rolling out new IT infrastructure projects

I felt confident that the IT press would lap this stuff up because it was different and it was funny, and the client told me that it was the first time she’d laughed while reading about enterprise backup – so clearly it was going to be a winner. Only, once the client took this stuff to her boss for approval, it immediately got shot down, because this isn’t the kind of tone that serious IT companies should use.

So it wasn’t as easy to convince clients to take creative risks as I’d hoped. The other big problem was that my plan needed clients to understand that while they paid low rates, they would get a limited amount of my time. That would be fine if I was doing the kind of agile, guerrilla style work that I wanted to deliver – but since I was being forced into doing more conventional comms activity, it was taking up more time than it should.

I was losing motivation, the clients I had were eating up all of my time but barely paying enough to keep the wolf from the door. I couldn’t find time to win any new business, and even if I did, I wouldn’t have the time to service any new clients.

At the same time I got a little distracted by learning how to code so I could build apps myself – I found this much more interesting than my day job, so I’d make excuses to spend more time coding than working on my business. I started building [http://www.influential-blogs.co.uk](http://www.influential-blogs.co.uk/) and convinced myself I could turn it into a profitable service if I spent enough time developing it.

By the end of 2013 I’d all but lost interest in running my own agency, and my bank balance started to look a bit grim, so I decided to throw in the towel and go back to full time employment. Fortunately for me, my old Text 100 colleague, Kirsty Leighton, invited me to join her at Hudson Sandler almost as soon as I put myself back on the market, and four months in that move looks to be working out beautifully, so everything’s turned out fairly well.

While I’m a little embarrassed that I couldn’t make a success of my business, there are a few positives:

  • I got to spend the best part of a year working at home and that meant I was able to see much more of my two young boys during the early part of their lives, which I wouldn’t otherwise have done.
  • I pretty much broke even financially, so I didn’t lose anything.
  • I learned to code, which I’ve wanted to do for years but never found the time.
  • For the first time in my life I felt like a proper grown up every time I wrote an email to my accountant.
  • I’m really enjoying Hudson Sandler, and I wouldn’t have ended up working there if none of this had happened.

So I’m in the process of wrapping up Disruptive Communications, but I’ll keep it as a dormant company, just in case inspiration strikes in the future, and for now I’ll use this domain as my personal blog because I quite like the name.

 

The ultimate B2B social media guide

The case for social media marketing to consumers is relatively easy to make, but B2B marketers still grapple with the problem of how to justify investing resources in these channels. In this article I’ll outline why and how B2B brands should be using social media for marketing, and I promise I’ll avoid techno-babble and agency guff as much as possible to get right to the important points.

That said, this is still quite a lengthy article, because there’s a lot to cover. You can download an easy to print PDF version of this article from here, and if you’d prefer to jump straight to the practical stuff, you should skip to section five using the contents menu below.

Continue reading The ultimate B2B social media guide

Why journalists hate getting press releases as email attachments

I couldn’t help but titter when I saw the following tweet from tech journalist, Mike Butcher, earlier today:

PressReleaseEmailAttachments

The reason I found it funny is that I remember journalists complaining about exactly the same thing when I was a hack as far back as the late nineties. It seems that fifteen years later, some PR people still haven’t learned that journalists hate it when you send your press release as a PDF or Word attachment.

Try to understand things from the journalist’s perspective: every day you’re likely to receive dozens, maybe hundreds of emails begging for your attention. At best you can skim through them all, picking out the ones which might be interesting to you. But if the important detail is hidden in an attachment, you have to interrupt your flow and wait for the document to open, which could take anything from a few seconds to a couple of minutes. Doing this once or twice might seem like a minor inconvenience, but those minor inconveniences pile up pretty quickly when you’re dealing with dozens of them every day.

And imagine if they’re reading emails on a mobile device, do you really think they’re going to open attachments then? Life is simply too short.

When you email your press release to a journalist, you’re asking them to take time out from what they’re doing to pay attention to your pitch. That’s always going to be a hard sell so, if you want to improve your chances of getting through to them, the very least you can do is make life easier for the journalist by including the release as plain text within the email.

A newbie stand-up comedian in London, blogging my progress