Solving the collaboration conundrum between analysts and developers

Posted By Axonn on 19th June 2014

Starting my career as a web developer I quickly got used to being told what to do with a website. Ashamed as I am to admit it now, I thought very little about why I was doing what I was doing and where that instruction had come from, aside from making sure I hit my deadlines.

Everybody had an opinion on how the website should look and what functionality it should have. I never really thought twice about it. I just figured: “Well these people know their business and have been around a lot longer than me therefore they must have experience that I don’t, so I’ll do what I’m told.”

Now, having worked in the industry for over five years, I’ve realised that a lot of people have opinions, but as well-meaning as they may be, these are not necessarily well-informed. What I mean is it’s a common human trait to make judgements based on easy recall of your most recent previous experiences (nod towards Daniel Kahneman’s book Thinking Fast and Slow for my knowledge on that). But these recent previous experiences are not necessarily representative of the real picture. Each decision should be made based on data over a time period that makes sense.

Over the past year I have been working at Axonn Media as director of data insights and implementation. Not the most catchy title, I know, but what it means is that I have been in charge of both the data analysis and customer-facing web development teams. The role has shown me how easy it can be to spend a lot of time implementing a site, but even with the best developers in the world (which we obviously have at Axonn) without making informed decisions using data then the whole thing falls down.

Now I appreciate in the current digital landscape this is not a revolutionary or “thought leader” statement to make. Just look at all the leading people who are talking about big data and agile processes, not to mention companies like Amazon and Google which are renowned for using data at the forefront of every decision they ever make and have been very successful at doing so.

What I do think is often glossed over is how to actually make a team or department data-driven. There are potential pitfalls with the approach and lots of ways to go about making this happen. I must stress that the experiences I describe (as with any good set of processes) are still being built on and are nowhere near perfect. Content marketing changes so quickly, we will constantly be striving to improve the way we work.

Collaboration conundrum

Over the last year at Axonn Media, getting departments to collaborate has been a large focus of ours, as we know that in order to do content marketing well you need to involve numerous skill sets and departments. Scott Brinker talks a lot about the shift from marketing and technology as two different disciplines to the merger towards marketing technology as a discipline, which I totally agree with. I think content marketing and website builds are causing more departments to come together with new disciplines emerging as a result.

From my perspective the merger of data analysts and developers – i.e. the people who inform the implementation and the people who implement it – is starting to take precedence in my day-to-day work.

Typically these two departments are tarred with the same brush: “the techies”, “the geeks”, “the nerds”… I could go on. Therefore because the outside world looks at it like this I think there’s often a fatal misconception that these two disciplines understand each other, but in my experience this can be far from the truth.

After little over a month managing these two teams I was constantly hearing phrases from our content optimisation team like:

“That should be easy to implement”
“Well I recommended that [insert arbitrary time period here] ago but nothing has changed”

The developers were no better…

“I would have done that but it would have meant re-coding everything from scratch”
“Oh I didn’t realise that’s all they wanted! I could’ve make that fix in five minutes”

It quickly became clear that data analysts often get frustrated that their suggestions are not implemented by developers, developers often moan about how data analysts don’t understand how difficult it can be to implement some of these changes. All they needed to do is better understand each other’s roles and be given a platform on which to actually talk to each other.

Sounds simple enough, but when you have two teams stuck in their ways in a company of Axonn Media’s size, changing direction is not always as simple as it may seem.

Process predicament

Having identified the problem and what I wanted the outcome to be, I worked on what needed to be put in place to make it happen. After a couple of workshops with both teams to review where they felt their pain points were and a couple more to come up with ways to tackle the problems, we outlined the following to encourage better collaboration (yes we collaborated in order to solve our collaboration troubles).

Those who sit next to each other work better together…

1. Sit next to each other

It may sound obvious but just having the two teams next to each other instantly encourages them to talk to each other and hear what each other’s day-to-day jobs are like.

2. Use collaboration software

When there is a lot of back and forth between various departments, collaboration software can be a useful tool to make sure nothing gets forgotten and all the information required is stored in one central place.

3. Group training sessions

Between the content optimisation specialists (COS) and the developers, much of the knowledge on what makes a good website is useful for both teams. Usually the only difference is the perspective they have. The COS will look at a website in terms of what Google and ultimately users want; the developer is much more likely to look at the website in terms of what a good code architecture would be and what can they do within the time frame that won’t cause bugs later.

4. Group social events

If you think it sounds like an excuse to have a bit of fun and get drunk you’d be correct! And the results are always going to be equally happy employees.



Revolutionary results

OK so the title is probably a little bit overkill but I had to keep to the alliteration going, here’s what I learnt anyway.

1. Sit next to each other

Out of the four things we have implemented, I’d say the two teams sitting next to each other has had the most impact … to the point where as their manager I’m looking over and thinking stop collaborating and get on with your own work. I see this as a good problem to have; everybody is at a point where they want to share what they are doing and overcome problems together.

2. Group training sessions

The group training sessions are a useful exercise for getting both teams to understand what each other know whilst sharing their common knowledge. We did at least one session a week for three months and in hindsight I think this was a bit too many, to the point where some sessions repeated themselves. I would recommend identifying the key crossover areas and just doing sessions on those. Which for me were…

  • On-page SEO – one session from a developer perspective, another from a COS perspective
  • Structuring and naming HTML for Google tag manager
  • Website implementation
  • CMS limitations to implementing best practice
  • Implementing analytics software

3. Use collaboration software

It can be easy to assume that just by having good collaboration software your teams will start to collaborate, but the opposite is true. From what I’ve seen a couple of things could happen once you get the software.

  • No one uses it
  • Everyone stops having normal conversations because they assume that everyone has read everything through the software
  • Everyone uses the software in a different way and no one knows where the resources are

All three of these things happened to varying degrees and I could write a whole blog post on the solutions. To summarise, I suggest having a clear process and set of rules for people to follow before rolling out the software and for the first months you will need someone to enforce these rules over and over again until it becomes habit.

Overall I think that what we have put in place has worked with relative success. I understand that each organisation and team is different so this is by no means a hard and fast way of doing it. From our point of view the developers and COS teams working together has meant we have been able to improve our content integrations and the service we deliver a lot more rapidly. To the point that I will be expecting the COS to monitor this article’s success then the developer to implement changes in a months time without me or anyone else having to say a word . By the end of July we are likely to have some interesting data on which to modify this page and the article itself and I fully intend to write another post to let you know how that went.