On jargon

Away from the brouhaha of current HE policy developments (TEF, Brexit, Diamond Review, HE and Research Bill …) and back to an initial purpose of this blog – the art and science of management. I caught myself the other day speaking jargon without knowing it. Perhaps a word or two on jargon might be a good idea.

What is jargon anyway? I think there are two distinct uses, one acceptable (and for which we have a different name) and one bad.

The acceptable is when it is genuine technical language, used to denote a concept which is clearly defined and understandable, but which cannot be expressed more simply by other words. So, subject benchmarking is a jargon term within the world of higher education quality assurance: it refers to the use of agreed statements in different disciplines which set out shared expectations about capabilities of graduates in a discipline, expressed in terms of knowledge, skills and attitudes. It’s a lot easier to say subject benchmarking than it is to repeat all of that last clause. So as long as those involved in the conversation understand that this is what subject benchmarking refers to, then all is well. It is helpful jargon, as it enables communication to be shorter and more focused, and therefore potentially, more complex ideas to be expressed and developed. Humanity 1, World 0: well played, everybody.

There also unacceptable jargon, which I think comes in two flavours. The first is where jargon conceals disagreement. Think about hard Brexit and soft Brexit. At the moment these terms have great currency in political and news discourse. But do they have a clear meaning? I’m not sure – it seems more that they are used as continuation of the remain-leave debate, without much reference to the legal, financial or political realities of the UK’s leaving the European Union. Please note that I’m not trying to make a point here about how or whether Brexit should happen, simply that the terminology used in the debate isn’t helping us. (I blame Mrs May for this – if she’d managed a less tautological line than Brexit means Brexit we might be able to engage more seriously with a serious issue).

The other flavour is where the jargon passes the test of meaningfulness, but fails on significance. Either because the material isn’t important (says who!) or because it isn’t about something that you’re personally interested in. Here’s a wonderful example. Jargon here is an interesting expression in the English language – I use technical language, you use jargon, they are unutterably trivial.

Is the use of jargon ok? Well, I think it is, as long as all of those involved in the discussion know what it means. And if it’s useful language to them, then they’re being smart. But often communication goes beyond the immediate audience, and if this might be so, perhaps better to cut down on jargon, or at least define your terms up front.

And what of business speak? On the radio a couple of weeks ago I heard a big data expert talk about drilling down into users of social media. That’s not a good image, and immediately tells you why jargon isn’t always appropriate. And don’t get me started on filler jargon such as ‘on a going forwards basis’ …

Virtuous necessity

I’m currently doing a project at a Big Northern University, and like many universities there’s an atrium created out of the space between buildings by putting a glass roof on it. And like many glass rooves it leaks when it rains. Which it does quite a lot.

A feature roof

I like the way that they has been dealt with – using sheets of polythene, transparent pipes and water butts to make a pretty stylish water collection system; and it looks like this is used to water the plants in the atrium. Thus making a virtue of necessity.

That’s quite a common need in management and in working life generally – you can’t always control the world or what it does to you, but you can choose how to respond to it. So when it rains, don’t be down, take the chance to water the flowers for free.

Room at the top?

The BBC reports today on NUS Scotland's call for more women on University governing bodies.  That's an important component of decision-making, but another angle is the make up of the executive team in a university.  I've been looking at the gender make-up of university executive teams - a day going through institutional websites.  I'll post more in due course (there's lots of data to look at) but here's a first finding:

For each UK institution, I identified the top team - usually identified as the group which meets weekly/fortnightly and advises the VC; or as the team within the Vice-Chancellor's office - and counted the number of men and women, including the VC/Principal.  I didn't differentiate between academic and professional service (eg Finance Director, Registrar) roles.

I couldn't identify the team for every institution.  There's 131 institutions represented in the data above; for the remaining 30 institutions I couldn't identify the top team from the university website.  The mean proportion of women on executive teams is just short of 1/3; there's not much difference between this and the national averages for English, Scottish, Welsh and Northern Irish universities.

The data doesn't show equality - if there was no gender bias there'd be a normal distribution curve.  But equally it doesn't say anything about any given university, or the intentions of Vice-Chancellors.

Operational effectiveness

Any manager will at some point have worried about achieving reliability and efficiency in delivering a service. There’s a powerful combination of two established management tools which can help you.

The first tool is to use Standard Operating Procedures – SOPs. This isn't (just) an instruction manual for how to do something. It’s also a set of habits which keeps that recipe card current. Here’s how.

Document the procedure – and have it done by those who actually operate it. SOPs are common in laboratories and in manufacturing processes – here's guidance from the US EPA which includes examples – but they also apply to administrative processes, and particularly those which use complex databases or other IT systems. SOPs should articulate the critical steps; and identify any choices that the operator has to make, and the parameters for those choices. They should also not be so long that they become unusable.

Have the procedure reviewed and signed off by a senior member of staff, not involved in its drafting – the head of section or, if it's a small team, their manager. This is so that the process has formal authority as well as the expert authority that comes from the knowledge of its authors. It also means that any organisational or resourcing issues have to be addressed. And finally, it shows that the SOP is serious: make the sign-off process a real hurdle, and people will see that it matters.

Include in the document the reasons for the steps. Tell people why something matters and they are more likely to do it. Robert Cialdini reports a fantastic example of this in his book ‘Influence’, reporting on work done by Ellen Langer of Harvard University. Ellen Langer conducted experiments in which she asked people queuing to use a photocopier if she could push in.

• When the question was Excuse me, I have five pages. May I use the Xerox machine because I'm in a rush? 94% let her go ahead of them
• When the question was Excuse me, I have five pages. May I use the Xerox machine? only 60% let her go ahead of them
• And when the question was Excuse me, I have five pages. May I use the Xerox machine because I have to make some copies? 93% let her go ahead of them

So when you give a reason – because – you get much more agreement. And note that the reason doesn't even have to be a good one – ‘because I'm in a rush’ and ‘because I have to make some copies’ get pretty much the same response, but the second reason adds no extra information. Why stand in a photocopier queue if you don’t want to make copies? So use a because and people will more likely notice.

Train people in using the procedure. It doesn't have to be a full day's training session, but at least talk them through the procedure; let them ask questions; observe and coach if they're unsure.

Set a review date; stick to that date; and involve those who operate the procedure in the review. Keep the procedure current; make sure you take account of any other organisational or priority changes which might impact; and learn from the experience of operating the procedure.  What tips and wrinkles have the operators identified? What would they change to make it better?

So that’s the first tool – standard operating procedures.

The second tool comes from Lean thinking, and is both simple and devastatingly powerful. It’s about identifying the nature of the tasks to be done, and makes the following distinction.

• Runners are tasks that occur on a daily basis, and are of sufficient volume to justify having a specific process to deal with them
• Repeaters are tasks that occur on a regular basis, but not frequently, and are not part of the day-to-day business of the organisation
• Strangers are tasks that occur infrequently

Now apply this distinction to a standard operating procedure. Does a single procedure try to cope with too many different types of event? Are you dealing with repeaters and strangers when you could be focusing only on runners? This can lead to delays where questions get passed around the organisation, and bottlenecks are created in workflow. I've seen this happen in processes around the student journey, where one non-standard case delays processing a whole batch of students, resulting in disproportionate problems.

The trick is to design the bottlenecks out. Make the procedure work for one specific task. If there’s another task which occurs, have another procedure. You can’t make apple pie with a recipe for blancmange. And make sure that you have triage at an early stage: work out if a case has the right features to be dealt with by a given procedure. If it has, then process it. If it doesn't, then refer it elsewhere. Just like a hospital, making sure that the broken bones go to the fracture clinic, and the blocked ears go to ENT.

And there you have it. Think about runners, repeaters and strangers, to make sure that your procedures have the right scope and focus. And then write and use a standard operating procedure to improve quality and reliability.

Good luck!

Eight things that a new line manager should know

A couple of interactions today – an email from a former colleague, and a conversation with a fellow consultant – got me thinking about line management, and what advice I’d give my younger self.

Line management can feel overwhelming, particularly if it’s the first time you’ve taken on that role. It’s also a very important job – we spend so much of our time at work, and often invest in our work so much of our persona and values, that the quality of our management can have a dramatic impact upon our well-being. So, no pressure then.

Here’s eight things I’ve learned which might help.

Be yourself. One of the hardest things to do when managing someone is to get really good and clear communication with the person you are managing. One important thing you can do is remove the layers of artifice that a stilted relationship can bring. You don’t have to be mates with the people you’re managing (and a bit of distance is not a bad idea) but equally you don’t have to be a robot. If you can be authentic in your relationship with your team, there’s a better chance that they’ll hear you, and trust you enough to tell you things. Authenticity doesn’t have to mean baring your soul to the world, but it does mean remembering that you’re a person as well as a role holder.

Set direction. If you don’t get the job done there’s no point in the whole thing. So be clear in your own mind what it is that you’re trying to do, and then make sure that your team know too. And use this as a fixed point to steer by: how are you doing, has the need changed; is there a better way you could do it. But always know what it is you need to achieve. Remember also, if someone hasn’t heard what you’re trying to say, the best thing is not to blame them for not listening, but see if you can explain it some other how.

Remove obstacles. Your team are doing the work, you’re managing them. That means delegate, let them do the work, and focus on removing the barriers that can get in the way. That might mean helping your team develop skills; that might mean holding a mirror up to your team (I probably mean that figuratively); that might mean making sure that they have the tools to do the job; that might mean a pep talk so that they don’t make an impassable mountain in their minds. But look at yourself as the coach, the sweeper, the resource finder and the problem solver, and they’ll be free to do a great job. Which people mostly do want to do.

Listen. Carefully. It’s easy to get wrapped up in your own view of the world and not see other ways of looking at things, and your team can be a great help to you. But you have to have ears to hear, and the listening skills to hear what isn’t being said, or is being said elliptically, as well as what is being said. My experience was that as I got more senior in my career, two things happened. Firstly, my jokes seemed to get funnier, and I’m pretty sure that wasn’t true. And secondly, very few people just chatted with me. And it’s in these conversations that you can find out a lot of useful things. I don’t mean that you should be an eavesdropper: no one will trust you then, which is pretty much fatal to a managerial relationship. But equally don’t think that your words are the only important ones to hear.

Good enough is good enough. This is a tough one. We all want to do things really well, and we all will have personal and professional standards about what we want our work to look like. But if you stop when something is good enough – when it meets the need, when it ticks the boxes – then you’ve got more time to do other things. The quest for perfection will bring you long hours in the office, and you’ll get less done than others. Is this what you set out to do?

Tell the truth. Always. If people know that you’ll be straightforward with them, they’ll by and large do the same for you. And that is a huge blessing. It doesn’t mean be cruel (you should never do this), or be too blunt, or lack tact, but it does mean make sure that what you mean is what you say, and that you say it clearly. It doesn’t always make for comfortable conversations, but it does build respect and trust.

Say 'thank you'. When someone has done a job for you, thank them. When you see something being done well, say so. When someone has gone the extra mile, tell them, thank them, and try and do so in front of their manager. People are predisposed to hear bad things and to be aware of problems - I suspect it's part of our basic survival instincts - which means that you have to say a lot of thank-yous for them to be noticed. But they are one of the most powerful tools that you have, and can help a team achieve the impossible. Don't save 'Thank you' for someone's retirement speech.

You will make mistakes. You will get things wrong. You will feel like you don’t know the first things about people or your job, and that there’s no hope for you as a manager. Don’t worry – everybody does this (and if they say otherwise they are lying, to you and possibly to themselves.) And when you make a mistake, fess up. Say sorry if you’ve wronged someone. Tell your manager, and say what you’re going to do to put it right (managers love it when their team do this bit). Ask for help. But stop beating yourself up about it. There’s plenty who’ll be happy to beat you up, and there’s no need to help them.

This isn’t all the things that you need to know and do – but when I reflect on my experiences, and when I’ve talked to others, these ideas always come up. And remember where we started: you’re doing an important job; it’s hard; but it’s definitely worth the effort.