The Dark Matter of small teams in healthcare

Chapter 3. Dark Matter: vital, invisible, management skills

Photo by Randy Fath on Unsplash

Chapter 3 of a series of posts from Dark Matter.

The short read:

• Teams are a specialised area.

• They have to be built with insight and attention to the task they are to fulfil.

• Teams take time to reach a level of effective performance.

• With care and patience, the right team can create rewarding experiences and make its mark.

A few years into my career as a research manager, I remember stepping out of my office to see what the fight was all about. It wasn’t a case of fisticuffs or even elevated voices, but there was a disagreement and a sense of tension. A manager was quizzing someone who worked in my team about the allocations on his timesheet. The company had a system of weekly records, in which every job had a number in a system that also accounted for leave, training, and illness. Whoever designed the form had decided that it was possible to allocate time spent on any activity to 2 decimal places (a resolution of 36 seconds) and many people seemed to believe that this necessary but crude means of collecting costs, connected easily to reality.

It turned out the argument was not over 36 seconds, but perhaps an hour of allocated time. The manager felt he was being overcharged and the chap from my team was clearly under pressure to re-allocate his record. Half of me was surprised, because the timesheet-completer was a conscientious man. Half of me was unsurprised because the manager in question was a stickler for detail. What left me annoyed was the manager’s willingness to spend 20 minutes of his own time and 20 minutes of this other chap’s time arguing the toss. By the time I had pitched in, the hour lost was probably about the same as the hour it cost to argue about it. Why would a manager do a thing like that?

Incidents like this began to alert me to the fact that the business of running teams was more subtle than I had imagined. This other manager and I rarely hit it off and if pushed, I would probably have blamed his approach as being restrictive and narrow. I had no idea that he probably saw me as wild, unpredictable, and unreasonably committed to my cause. We could get on socially – as, indeed we did, when we were sent off on an outward bounds course – but we were usually on our guard at work. I might also have acknowledged that the system had something to do with it, since there were two of us reporting to a single boss, and so a competitive edge was likely.

What I didn’t realise until I started to teach Project Management to Final Year Computer Science and Business Computing students was that the system pitched us against one another in a more subtle way. This twist that I came across recently was that he was caught in a sandwich, because he ran elements of fabrication – we were all building photonic switches and filters for optical communications – but people in my team did the design work beforehand and then tested the devices afterwards. Systemically, my team could blame his team for poor workmanship if a device failed to work as planned, while his staff could blame those working for me for a bad design. This double-blame route, especially in research labs, virtually guaranteed a degree of tension, absent-mindedly created by the structure of the Division.

And the question of structure would not go away. Why couldn’t you just put people together, give them a brief, and then watch them get on with it? I must have been making a real mess of it, because a year or two later, when I was running several teams, one of the leaders popped in and asked me if I had seen this.

‘This’ turned out to be a wedge of a book called Rapid Development by Steve McConnell, now a recommended text for my final years. It’s grounded in the software development industry but has something useful to say on most aspects of management, with short case studies and attractive tables for easy reading and assimilation. And the bit I was being guided towards was all about teams. I especially remember reading the book because I had one of those bizarre airport experiences where it took my hand luggage over the limit (I said it was thick), but they were happy for me to walk away from the check-in carrying the book, so that the book and hand luggage were demonstrably separated. The fact that I was on crutches only added to the odd approach to regulation and check-in.

The message was that team structure mattered – but you couldn’t just impose it. The best structure to go for depended upon what sort of tasks the team had to do, and indeed, upon the culture of activity within the company, as well as the skills-mix and personalities making up the team. Here are some of the teams types I learnt about from McConnell:

Business Team

General purpose, versatile team with a flat structure, generally led by a peer

Surgical Team

Team configured around one highly productive member (in a software team, this is usually a super-coder)

SWAT Team

Special Weapons and Tactics teams are used by police and special forces: they are teams with deep specialisms designed to get a specific job done quickly.

Skunk Works^® Team

Named after an experiment by Lockheed (see below), this term define a creative, chaotic group of bright people with a broad goal.

Theatre Team

Team of talented people where roles and performance require careful negotiation to deliver a superb performance.

• Business teams are essentially groups of peers, led by a peer whose main task is to represent the team to the wider world and streamline the interactions with it. The versatility of such teams is also their weakness, in that extreme drive and focus are usually beyond them.

• Surgical teams emerged from the realisation that excellent programmers are many times more productive than average programmers, so where such a superstar exists it makes sense to use other team members to funnel and process work through that person. The superstar will not be the leader (since leadership would, by definition, take that person away from programming), but there is a clear clinical analogy with the operating theatre. Such teams can be highly productive but require careful managing.

• SWAT teams have a special purpose – perhaps in troubleshooting or audit, and members know their roles, have specific expertise, and clear rules of hand-off and demarcation. In a sense, the SWAT team is the inverse of the Business Team and may have strong lines of command-and-control.

• Skunk Works^® teams came out of Lockheed’s success in hiving off a group of bright people into an isolated factory (the Skunk Works^®) and giving them a high-level brief – to invent a jet fighter. The P-80 Shooting Star was completed in 143 days with Kelly Johnson at the helm.This chaotic, nearly ungovernable, creative approach has taken its place as a valid team model.

• Theatre teams are groups of highly talented people with a pecking order that is not always reflected explicitly in the structure. They require sophisticated management but can deliver spectacular results when everyone and everything gels.

And there are others – sports teams, for instance. Each has its own management challenges – to motivate, to direct, to coach, to represent, to inspire, or just to take responsibility for the occasional failure. Each will have a context in which it will be most productive, and understanding, or aligning within, that context will be critical to success.

The tricky piece is that most of us are not part of a single team. Sometimes we are part of a peer group in which we show leadership through influence and giving of our best. Sometimes, those around us are really looking for a lead and expect to be directed; at other times we find ourselves thrown into processes that we cannot control and do not fully understand, and yet we sense that there is an energy for great impact, of only we could tap it fully.

So, for instance, in terms of the planning, proposing and execution of research, I have a small support team of staff, each member with a specialisation, behind me. My function there is largely to listen and lead, and there is no question that I set the agenda – note the return to the context – for what we go after. It is more versatile than a SWAT team, but it has a clear mandate to support the research that I am able to spawn and undertake with others across campus.

On the other hand, within the School, my team-working looks very different: I am a peer with influence, but no formal management role at all. In a couple of weeks time, a bunch of staff from across campus – and all levels – plan to pitch up at a local hotel to do some strategic planning. The context here is more open-ended but we are after new ideas. My role has been to champion the event and pull the group together, but someone else will facilitate, and my value at the event will depend upon what I can contribute as a player in what will probably be closer to a Skunk Works interaction.

And it will be the same for you – a patchwork of teams in which your role will be different and your effectiveness judged by your ability to recognise the type of team you are in and to adapt to the requirements accordingly. You don’t have to be slavish about it, but an awareness of the teaming environment is helpful when you sense things could go better. Sometimes you are sitting around waiting for consensus, when it dawns upon you that the team just wants a decision.

Academic research teams are particularly tricky in this respect. In the teams I have worked in, I am usually about halfway down the list of collaborators in terms of academic stature – and those most recognised will tend to be in different fields to mine. This creates something of a Theatre Team, with a bit of a mission to it. Writing a proposal needs the breadth and depth of lifelong academic skills, but it also needs arbitrary decisions to be made in setting deadlines, and deciding how the pie will be cut fairly. In such circumstances, the team really does look for me to lead and create the framework while it will fit in. Similarly, since we cannot fire on all cylinders on every project all the time, there will be other projects were I just need to know how many words are needed by when, and to trust someone else to assemble the case, or make the strategic call.

One of the most energising aspects of this concept of a role in a small group is that it frees you from all the baggage of status by providing many ways in which to make a contribution. If you need the status (and most of us do), then make sure that at least one role provides you with it – but try to enjoy the other forms of reward that go with the other roles.

When I left industry and pitched up as an academic, I thought I understood collaborative working quite well. I had made a point of working with small groups, especially those where the members knew more about the technicalities of the work than I did.

I particularly enjoyed a strategic planning session with a company in North America that sold supplies to radiologists and radiographers. The big debate at the time was bricks versus clicks – whether having the warehouses and the logistics mattered in a world where everything would shortly be dominated by the web. I arrived with a plan and quite a strong brief from the centre to push an e-business model. However, the team got its act together and decided that, while there could be more ‘e,’ their business could be grown in other ways, too. And they were right.

Such events were fun, not just because you felt you were achieving something, but because you were always surprised by who would pick up a gauntlet, do a piece of background research, and how they would bring it back and use it to drive the decisions of the group.

The big thing I learned in my first 5 years as an academic was the sheer importance of the passage of time. Again, it was through preparation for the Project Management syllabus that I came across the theory behind this. As we noted in Chapter 2, Tuckman’s model of team development (other models are available) uses terms we have all heard of – forming, storming, norming and performing. I am not sure why it takes time, but I know it does.

Particularly, where you are working across disciplinary boundaries, the ideas that others take for granted are often so foreign to your own frame of reference that it just takes time to digest them. I remember early on going over to talk to a sociologist. Almost everything I said was followed by, ‘Well, that depends on what you mean by…’ And yet, eight years later, we can plan research and comment on papers to great mutual satisfaction.

It’s not just the time needed to overcome the ‘lost in translation’ problem, but also the time needed to build the trust to work together. One of the best collaborative managers I have ever met, Andrew Oliphant, worked at the BBC’s Research Centre in the early ‘90s. He was just superb at making teams work – working behind the scenes, smoothing out difficulties, clarifying the elusive and generally keeping a consortium of a dozen partners on the rails. The project involved building a signal distribution system that could be used in a real studio complex, and so there were lots of cross-functional language and communication issues to be solved.

There was also a sort of avuncular senior manager who was attached to the programme to improve communications. He didn’t seem to do much other than chat to you at unexpected times. And then there was a technical specialist who had his own way of doing things, but whom everyone at the BBC trusted. I wish I had paid more attention to what was going on, but the handling was so silky that I sort of assumed all big projects went this well. They don’t. They take time. That particular consortium had worked together for 3-5 years before we joined it and I suspect the team at the centre had known one another for considerably longer.

What if I don’t have the time? Someone recently asked me what management steps the NHS could take to meet its cost-saving targets within two years. When I said that I thought the only way was to cut services in the short term, while many of the management initiatives took root over a longer time span, he replied that he did not think that was acceptable. And yet Henry Ford was wrong – at least in the converse. Time may be money, but money does not buy time. Sometimes, you go a lot further by setting out a 5 or 7 year plan than you do through a series of convulsive 2-year survive-or-die initiatives. Sometimes it really will take as long as it takes.

Two more stories and then I am done – both of which I have had to study as a teacher. When Martin Gorham took over the London Ambulance Service in late 1992, there had been a catalogue of disasters around the introduction a new computer system, culminating an apocalyptic night during which many deaths were initially blamed on the system’s alleged failure to take and allocate emergency calls (for a paper by a colleague, see here). Although he was under enormous pressure to fix such a high-profile problem quickly, he argued strongly and effectively for more time.

And it was as well he did because it took over three years back on manual allocation to develop and put in a new computer system. During that time, he went out with the ambulances to discover the problems. He had to implement significant changes, including the purchase of new vehicles and the development of a new management structure. When everything finally went live, it was a great success. The 3-minute response time which had been 38% beforehand, rose to 60% within 2 hours and reached 80% within weeks.

The most extreme example I have come across by a manager to create time was in the Apollo 13 saga. I remembered it from my childhood when I had been gripped by the emergency and stood breathlessly waiting for news that they were safely down after the radio blackout of re-entry. One thing I could not work out, as a nine-year-old, was why they didn’t just fire up their big rocket and come home. They seemed to spend an inordinate amount of time continuing on to the moon and then making their way back. Not for the first time, I suspected that those in charge were not very good at what they did. But I was wrong on that occasion.

As mentioned in the introduction, I watched Ron Howard’s film and was struck by Ed Harris’ portrayal of Gene Kranz, the Mission Controller in Houston, whose wife gave him a new white waistcoat for each mission, and so I read Kranz’s book Failure is not an option. It turned out that the head-straight-for-home option was considered, but they decided to buy more time by continuing with the mission in order to make better decisions later. The way in which those decisions were managed is inspirational viewing or reading – take your pick, I can recommend both – but the upshot was that as the astronauts made their final manoeuvres prior to re-entry and just after they jettisoned the module in which the fateful explosion had taken place, they saw the extent of the damage and realised that they would not have survived any attempt to light that engine and head straight for home. Sometimes you just have to find a way to create the time that is needed.

For reflection

1. How many teams are you aware that you are a part of? What element of team theory would you like to bring to each?

2. The next time you are asked to attend an away-day for team development, offer to take on a session. Plan a game that helps the team to perform better. What have you learned about yourself as a result?

3. With whom do you get on least well at work? Find time to have a talk with that person and see if there is anything in the structure or the context of your work that is pushing you apart.

4. How will you plan for that encounter?

5. What was your first experience of joining someone else's team? How did the team evolve and over what time scale?

6. What strategies have you used to hurry things along when your deadlines were closer than you had hoped? If you could rerun those situations, what might you change?

7. Choose one team that you are currently involved with. In what ways does it manage to make the most of the people in it and the greatest impact on the task in hand?

8. To what extent do team models help? What are their main limitations?

The story so far

Health Management: is there a problem? [Dark Matter introduction](30 January 2025)

The Dark Matter of saving time in health management [Dark Matter chapter 1] (6 February 2025)

The Dark Matter of creating time in health management [Dark Matter chapter 2] (13 February 2025)

The Dark Matter of small teams in healthcare [Dark Matter chapter 3] (20 February 2025)

The Dark Matter of team players in healthcare [Dark Matter chapter 4] (27 February 2025]

The Dark compulsions of counting in healthcare management [Dark Matter chapter 6] (6 March 2025)

The Dark Matter of simply managing in health [Dark Matter chapter 5] (13 March 2025)