Sara Stopford-Pickering

21 May 2015

2 Comments

How we created a functioning PA team at Redgate

What does a successful PA team look like? Are the skills of a PA even compatible with the way an agile software company works? What business value does a high-functioning PA team add? 

These are just some of the questions I was faced with a year ago, when I took on the challenge of turning a group of PAs working for individual managers into a team.

But why did we decide to do this in the first place?

Plenty of software companies have stopped employing PAs altogether. Was there really a need for a team of seven at Redgate? I spoke with Simon Galbraith, our CEO, and found that he really valued the support that PAs offer. He also believed that a functioning PA team, providing great support to the management team, could free up their time and allow them to be more effective leaders.

The bad news? We weren’t that team.

The PAs were demoralised, and weren’t working effectively; we were a weak point within the organisation. Individual strengths weren’t being put to good use –  for instance, one manager’s PA was struggling to support him with a complex legal deal, while other PAs who had legal experience didn’t realise that help was needed.

The team also really struggled to collaborate on a shared project – we were asked to analyse the admin structure across the business, but we weren’t able to work together effectively, and didn’t reach any meaningful conclusions. Work was being duplicated in some areas, and individuals were unaware when other team members were stressed or overloaded. Worst of all, some really good people were thinking about leaving because they saw no future at Redgate.

The Redgate PA team was broken, and we were facing some important questions. Could we fix it? And should we try?

In the summer of 2013, there was a company-wide re-org. The least happy member of the team left the company, and then another person moved to a different department, reducing our numbers to five. Simon decided that a strong PA team would be critical to the success of the newly-reorganised business, and that the best way to strengthen the team would be to appoint a PA functional head (someone whose job is to bring individuals with the same skillset together so that they can support each other, even though they may not work together day to day). I applied for this role and was appointed, and then two interesting things happened.

Firstly, I learnt something during the application process for the functional head role (which involved talking to lots of people across the business): all of the PAs at Redgate really wanted to be part of a great team, they just didn’t know how to make it happen.

Secondly, I was given a mentor to help me in my new role. Brian was the functional head of the Technical Authoring team, and had only ever worked with technical teams in the past. I had lots of vague ideas but no real clue how to put them into practice; Brian knew how to do this kind of work with technical teams but had never worked with PAs. In the absence of any better suggestions, we decided to start treating the PA team like a technical team.

We started with a team retrospective.  These are an entrenched part of Redgate’s culture for development teams. They’re used to review what was successful during the last phase of work and discuss what could be improved in the next sprint. Our retrospective took place over two hours one afternoon, with Brian facilitating the session. Once we had a list of what hadn’t gone well over the previous year, we clustered and categorised these topics and came up with a shortlist of our biggest issues. We then ranked these based on what was important vs. what was achievable, which left us with two top issues to address first:

• Communication failing (not communicating well within the PA team, and not communicating well to the wider company)
• Not making the best use of individuals’ skills and strengths

As a first step to address these issues, we changed our weekly meetings and made them shorter. We also created a fixed agenda that focused on our workload and our respective bosses’ priorities for the week. Talking about these priorities helped us with our communication issue, and talking about our workload made us more aware of who was stretched and who could help. Everyone seemed to enjoy chairing the meeting, so we make an effort to rotate this responsibility each week.

The new team meetings helped improve our communication, but there was more to be done. Next, we set up a whiteboard to track tasks. Whiteboards are an established way of tracking progress in software development, but it wasn’t clear whether this would be a useful tool for the Redgate PAs.

One of our developers spotted me trying to draw up a first draft whiteboard structure and came over to chat. His advice was to start simple – he’d recently set up a fairly basic task board for his team, and suggested that I take a similar approach.

This is what our whiteboard looked like to begin with:

Our prototype whiteboard has a lane for each member of the team and shows what they’re planning to work on, what they’re currently working on and what they’ve done. As soon as we started using the whiteboard, we saw that it was going to be really useful for us as a team.

Within a few weeks, we’d even begun gathering new data about the team. By tracking random tasks assigned by people who weren’t the individual’s manager (see below), we realised that there was a lack of PA support in one part of the company.

This gave me enough evidence to approach Simon and our People Team to request an additional hire. We also found that as a team we were spending an inordinate amount of time on travel requests (for people all across the company, not just our own bosses). Again, we were able to come up with different ways to tackle this issue – such as educating people on how to book their own travel by giving a short internal talk on the subject.

Next, we set up a skills map for the PA function. Skills maps are currently being rolled out across Redgate as a way of identifying both core and specialist skills needed for various roles. This is the PA skills map that we devised as a team:

We built the skills map by brainstorming the skills that PAs at Redgate need to have. We then grouped the core skills for the role in the centre of the skills map. We also found that some Redgate PAs have specialist skills which are only required in their specific roles or departments – these are shown in the map’s outer quadrants.

To further flesh out the skills map, we gathered feedback from our individual managers on the skills they expect PAs working for them to have, and used this input to create a definitive version. The skills map is now being used to identify training needs, and as a guide for training new PAs. It’s also actively used during our recruitment process to remind ourselves of the key skills we’re looking for in new hires.

In short, we’ve done a wide range of things to try and create a functioning PA team at Redgate, and we went about it by applying the exact same principles and practices that Redgate’s software development teams have embraced over the last few years (even though that didn’t necessarily feel intuitive at the time).

So how has it gone?

Since we first began working consciously to build a strong, flexible and resilient team, we’ve made a successful hire, we now hold supportive but focused meetings, and we understand what others are working on (so we can offer support and advice, or step in to help if needed). We recognise our individual strengths, we’re working to compile a visual display of team strengths to share with the rest of the company, and we’ve created an ongoing PA training schedule. Redgate’s travel booking issues have now been addressed, and, best of all, we’re much better at celebrating success!

And we’ve learnt plenty in the meantime – that Redgate cares about what we do and how we work, that our success directly impacts how successful the managers we support can be, and that recognising individuals’ strengths means that we can use those strengths when and where they’re needed, even if that’s in a different part of the company. The benefits of encouraging PAs to develop specialist skills and continue to learn and grow are now much more apparent, and we’ve got a much clearer idea of what a successful PA team looks like (and how we can continue to work towards our vision). We’ve also learnt plenty about the process we’ve been through, particularly that any new process is going to require plenty of iteration while it’s being introduced, and that it’s okay – sensible, even – to borrow process ideas from other functions and teams.

Above all, we’ve learnt that it feels great to celebrate when things go well!