What to do When Your Web Team is at Risk…

Kevin Mears from the University of Glamorgan Web team has attended IWMW before, but this year can’t make it due to some restructuring that has been taking place in his department. It’s clear that a lot of people have been through this process and many more will do during the forthcoming year. Kevin has written a blog post on his thoughts on being at risk and how lesson’s learnt at last year’s IWMW helped him get through. He has managed to attend this year’s IWMW as a remote attendee and once again enjoyed Ranjit Sidhu’s talk.

About the Process

A little over two months ago nine senior developers in the development division were identified as at risk of redundancy due to the need within the department to make cost savings. A painful process for those concerned, no doubt happening in universities across the UK. I was one of those developers and now that thankfully the process has ended and I am still gainfully employed, I thought it might be a useful to share my experience and some of what I learnt.

At IWMW 2010, there were generous helpings of pessimism about the imminent choppy financial waters, but also some great tips on how to go about navigating through. Particularly pertinent was Ranjit Sidhu of Statistics into Decisions (SiD). His talk suggested a series of approaches that web teams can use to demonstrate the measurable benefits to our organisations of the sites that we develop.

Despite the fact that we haven’t wholly implemented the advice and provided ROI information to those who matter, (in part due to the nature of how our webteam is structured) it was the emphasis on demonstrable benefits and activity that struck a chord with me. Allied with the shock to the system of a letter telling me I might be out of a job, I was galvanised into digging into what the team does and presenting that so that people making decisions about our futures were fully aware of what we do and the implications of us leaving the University.

What we Did

As a group we decided that presenting a series of information rich slides would be the most digestible and relevant format. We figured that during the process the decision makers would be seeing lots of lengthy reports and proposals and that we should make use of our ability to digest and present well structured, relevant information possibly with the added benefit that we would potentially have something at the end of the process that would be like a team CV. (As an aside it occurred to me that the logical next step would to create a site where this could become an ongoing resource. Just need to find the time.)

We began collecting data on the sites that we run. Nothing too difficult, but numbers that would offer some kind of perspective. One example was categorising the sites we run by department to make it clear that we provide a service for the whole organisation. I suspect that we aren’t the only web team that has marketing has it’s major stakeholder, and it’s easy to forget how many people that we cater for. That was a nice reminder for us.

We thought of other measures that might be relevant and help people judge – Number of Pages, yearly Pageviews, Number of Databases, Number of documents, Users trained, Number of feeds – all of which provided people not intimately acquainted with our activity an overview. It also surprised me. I was amazed by the thousands of documents that we host and it was also good to be reminded how many people rely on the platforms we provide. I’m sure that a detailed examination of the stats could find problems with our methodology, but the point was to present our activity in the context of a conversation about value and effectiveness.

In our other slides, we talked about Ruby on Rails and Django, which we use to power the majority of our sites. We mentioned our ongoing efforts at going Agile, including some stats from the Pivotal Tracker system we use. We also included some testimonials from stakeholders, rough estimates of costs to replicate what we do, some things about the experience and commitment of the team, screenshots of sites and other areas that we have worked in.

These were to try to give a picture of how we’ve developed a way of working over the years, and that it would pretty difficult to recreate that once it’d been dismantled in a round of cuts. A particularly useful slide was the one showing how we worked on a particular project. Github provides some nice charts and the impact one shows commit activity.It showed all of the team committing code throughout the project in parallel. Not remarkable maybe, but so much nicer when displayed.

What I Learnt

Surprise, surprise it feels bad to be given a letter labelling you as ‘at risk’. The real revelation for me was, once I had recovered from the inevitable dent to one’s confidence and realisation of the gravity of the situation then I felt galvanised by the process of pulling together all the relevant information. Having a focus made me feel like I was back in control of my destiny. As a web team we work intensively on sites, release them and then move on to the next one,only revisiting the site when it becomes ‘tired’. It struck me that better and more proactive measurement is possibly a way to stay more in touch with one’s sites whilst simultaneously broadcasting the good work we do. Maybe everyone else already does this?

When we have so many things that we would like to develop; Social media, personalised content, responsive design, open data and many more that it’s all too easy to neglet the presentation of what we do. By doing that I think that we not only do oursselves a disservice by being taken for granted, but also the organisation’s that we are in, because they need to know that by investing in commited , skilled and passionate developers they get very real tangible benefits.