Not herding cats: job design for teams

3 September 2008 by Jennifer

This is by way of a sequel (as promised) to my last post, getting into more detail about my thoughts on constructing a workable team of lots of people, with particular reference to BiCon.

I’ve been thinking about this since last year when I first ran into the “Children at BiCon” question, and I wrote much of this article back in May… but it seems like an especially timely subject at the moment, because of the number of people thinking and talking about aspects of volunteering for bi community stuff.

E.g. at the little bit of BiCon 2008 I was there for, and in the blog comments since, there’s been a striking amount of talk about how “BiCon is made of people”, and celebration of how many people had contributed. BiCon 2008 had the most encouraging page for volunteering at BiCon I’ve ever seen. And I’ve already talked over some of the stuff in this article (a few months ago) with Martin who’s head of the 2009 team (who should get some credit for encouraging me to post this, though no blame for any ideas which fall with a dull thud :-) ).

That’s not to imply that 2009 will be following these suggestions, but it did seem about time to stick my blueprints and thought-experiments out there for general debate and grabbing if wanted.

Basically I’m going to talk about some ideas for event organisation, which I think would make event teams a more nurturing environment for new talent (and indeed for everyone).

I don’t mean to say that they’re all my own ideas – some of them have been discussed numerous times in the past in connection with BiCon, and some have already been done. But there are some new ones, as well as some which haven’t yet been fully implemented. And even if they were all old ideas, it can still be useful sometimes to sketch out how lots of different things could potentially go together.

the words "not herding cats", illustrated with cartoon cats in various colours.

Background

For the non-BiCon-goers, I should explain that BiCon is run by a different team every year. Twenty years ago, the teams were usually drawn from within or near the same town that the event would be held in, but nowadays that’s not necessarily the case. And, more likely than not, nowadays, the nucleus of a BiCon team will include some people who have been on a BiCon team before – though still not always.

Team size and structure

A major factor in the workability of a team is the structure set up for managing remits and lines of communication. By that, I mean both the theoretical model and the software support. I agree that if we just suddenly had a 30-person team and tried to manage it via one LiveJournal plus email, no-one would ever want to do it again :-)

But I don’t necessarily agree (with what seems to be a common view around BiCon over recent years) that having more than 6 to 12 people on a team is inevitably going to resemble the proverbial “herding cats”.

What I want to try to describe is a model whereby i.m.o. a team could have 20 to 40+ members and not resemble “herding cats”.

I can imagine some people reading the description of it and saying things like “That’ll never work – it’s much too complicated”. But its (relative) complexity only needs to be evident to the person or people setting up the structure, and to a lesser degree managing it. The people claiming a role have a different experience. If it’s done right, their experience is of walking into a clearly defined space and being able to play within it. They don’t have to worry about how that was accomplished or is being maintained.

With regard to that initial setup, there’s an element of “it’s easy for me to say”, me being a process geek and happy with complexity :-) But I’m sure I’m not the only person around with these skills and tendencies. And, as I say, they’re not needed from everyone on the team.

So, having said that, here are some thoughts I have about how I would operate if I had the necessary influence over a (BiCon or similar) team of volunteers.

Jigsaw

One of the metaphors I’m thinking of is of creating a kind of slightly unconventional jigsaw puzzle.

All the pieces fit together to make a whole, without anyone having a jigsaw piece that’s uncongenial to them or bigger than they want. There’s no presupposition that all the pieces must be the same size. The divisions between pieces might or might not follow past tradition.

There would be a place in this team for almost anyone who wanted to play, using a partly-hierarchical structure to divide the jigsaw into different areas of responsibility and different degrees of importance.

All the main roles would have apprentice roles alongside, to help develop the “next generation” of activists.

If I were constructing a BiCon team, I wouldn’t take on other ongoing roles such as venue-hunting or setting prices. I would choose team-mates in the first place whom I could trust to do a good job on those. My role would be something like “People and process manager”.

Initially, my intention would be on matching roles to people, including a degree of designing roles to suit particular people more exactly.

As the team got going, my attention would be on whether everyone was fulfilled and happy and had what they needed in terms of resources and cooperation in order to keep up with their timeline.

Not reinventing the wheel

Part of the jigsaw would be to develop as much as possible the idea (which has already been discussed a few times) of multi-year ongoing role allocations, i.e. those which continue from one event to the next.

I gather that one of the most-debated-in-the-past ongoing plans is now about to go ahead – a legal entity to hold BiCon money from year to year. I’ll leave that idea to one side here, although it is related.

Some other areas which could well be owned by an ongoing team or teams include:

  • Web site content management system.

  • Web site back end database for bookings, and front end interface.

  • Financial spreadsheets which could be emptied and re-used for the following year, designed to be either integrated with the bookings system or as compatible as possible with it.

  • Web site back end database for workshop session offers, interface (possibly similar to this), and mail-merge-esque ability to extract and print out workshop info in different formats (such as David M did for BiCon 2003 – also described briefly on that link).

  • Database for publicity avenues (I say database rather than just “list” for mail-merge ease).

  • Web site back end database for offers of help with publicity, and front end interface.

  • Communication software of some kind for the team – more on this below.

The people taking ownership of these areas would ideally commit to some years of that role, and would pace themselves (taking small enough chunks of commitment) not to burn out before that time was up.

This structure would not only save significant time and energy for incoming teams, but would increase the chances of learning from anything that didn’t work one year and building in improvements before the next.

Some BiCon teams might want to do things differently, and there wouldn’t be a rule that they had to take advantage of the available resources – but over time, if most teams did use and develop the passed-on software, info and expertise, I’d expect the inherited software collection gradually to reach a level of usefulness hard to equal “off the shelf”.

As yet, I haven’t noticed any disadvantages of this idea, and in fact there have been some rather more concrete discussions about some of the angles over this past year, so I get the impression it is beginning to happen.

I suspect that the main reason it hasn’t been developed more for BiCon already is “not being in the habit” from the days before the Net – when BiCon teams were much more likely to be based on geography and were much more isolated from the rest of the community during the year.

It does require some investment of time up front, as well, though. Let’s face it, the “quick and dirty” solution is often to “reinvent the wheel”, using whichever bit of software is most familiar and most handy at the time.

Categories of people and their roles

On the one-event team, my team-mates would not be limited to my friends or even to people I know, but there would be a sort of sliding scale of task importance matched to people’s experience and track record.

(There would also be a requirement to have internet access for the main roles.)

I’ll talk here about the categories I have in mind.

Primary team / key accountable people

First we have what I’ll call the primary team, or key accountable people.

(The term “core team” would also have made literal sense, but that’s already in use around BiCon, meaning something like “People who get to see behind the scenes on the team’s online journal etc”. That isn’t the meaning I intend here.)

These are people with past experience of the event and demonstrable competence, who will take on key roles.

It’s likely that most of the people in this category would be on the team by invitation.

My rule-of-thumb definition of the primary team is that if everyone else dropped out, this subset could in theory run a decent event by themselves.

(Of course, that would be a waste of the opportunity for other people to work alongside them and learn from them, so I would have no intention of it ever happening.)

Apprentices

Ideally, each primary team person would have an apprentice working alongside them. In order to be given the job, the apprentice would likely have past experience demonstrating reliability and some kind of competence. (Plus, in the special case of roles that involve handling money, we’d want them to have been around the community for a while and have “something to lose” here if they used it to go to the Bahamas.) But they probably wouldn’t ever have done this particular job around this particular event before.

An important part of the job of the primary team person would be to develop as far as possible the degree to which the apprentice knows the territory.

For some roles (such as BiCon’s bookings manager or session coordinator), where there’s quite a lot of routine work, a rule of thumb would be that the apprentice handles all the routine aspects of the role, while the accountable person deals with problems and tricky cases. (I’m using the term “accountable person” for someone responsible for the outcome of a particular area.)

For other roles, there are significant parts of the job which would be hard to share (e.g. liaising with the venue, if the venue people prefer to have only one contact), and the apprentice would be more likely simply to shadow the accountable person closely. E.g. they would go to the same meetings (if any), be copied in to emails, and (if not using conference calling) be sent notes of what was agreed on phone calls.

All the apprentices would take part in the online discussion area for the main team.

In the theoretical best case, the apprentice structure would mean that every year, a complete new set of people emerged ready to do the key jobs. In practice, that wouldn’t happen – e.g. some apprentices would probably decide afterwards that they didn’t fancy repeating the job, or didn’t fancy taking on the responsibility of being the accountable person. But even just a small percentage of apprentices emerging ready to do the accountable job in future would make a big difference year on year.

Aside from the benefits in building capacity, this structure would also mean that if an accountable person needed to drop out – e.g. through illness – someone else would already know most of what had gone on so far. (I wouldn’t necessarily assume that the apprentice would step up to take control in that case. That would depend on various factors, starting with whether they actually wanted to at all. But at least they could help the new person to get up to speed.)

There might be cases in which two equally experienced people preferred to job-share – either with equal responsibility, or one the accountable person and the other a deputy. But I’d still aim to have an apprentice as well, to maximise the handing-on of knowledge.

Advisors

Thirdly we have advisors.

These would be people invited onto the team because of knowledge they have, but who aren’t accountable for particular things being done. E.g.

  • someone with a disability not already represented on the team

  • a single parent

  • people from diverse cultural/ethnic backgrounds

  • someone over 60, or over 70.

Again, these people would be included in the core team’s online discussions. Their only job would be to keep an eye on the rest of us and head us off from bloopers made through obliviousness.

(For BiCon, we would also call at times upon the biconorganisers group, i.e. past BiCon organisers, another group with particular experience and wisdom.)

Special mission people

Then we have what I might call “special mission people“.

The beauty of this category is that it allows for some of the most experienced people to contribute small amounts of time.

What most of the “missions” would have in common would be to develop things which don’t exist yet.

For instance, I might invite someone to develop one particular piece of writing or artwork, or to get in touch with one particular organisation to build links with them. Anyone who came along with a new idea like “I was thinking this year I might… ?” could go into this category too (if their idea didn’t already fit into existing structures – e.g. as a workshop session).

Everyone with this kind of remit would count as “accountable people”, but they wouldn’t be part of the primary team (inasmuch as the event could still survive without their work), and they might choose not to have an apprentice either (especially if their job had a creative, make-it-up-as-you-go-along nature).

Depending on what their special mission was, they might or might not need to be closely networked in to the rest of the team. But the team would at least know of their existence and their mission.

Contributors

Contributors form the category most expandable as more people come along. They needn’t be part of the team’s main communication structure; their main relationships would be with the accountable person and apprentice for the area in which they were contributing.

One existing example of the “contributors” model in use at BiCon is workshop sessions. Someone who offers to run a session doesn’t need to keep track of other developments; they just need to be in touch with the sessions coordinator (and/or apprentice).

Another example is the reception team and “gophers” during the event. Those jobs are among the ones easiest to manage when the contributors don’t have internet access.

Almost infinite numbers of people could make a tiny contribution in terms of distributing flyers, with the coordinator of that area keeping track of who’s covering what, and hence minimising duplication of effort.

Sub-leaders

We can introduce other layers of hierarchical/delegation structure if we like, for areas which seem to warrant it.

Some conferences have had separate organisers for different themes/strands of their workshop programme; I wouldn’t be averse to that idea. The key accountable person would then manage each of the strand coordinators. There might be a “miscellaneous themes” organiser too, to be the equivalent of “strand organiser” for offers not fitting a particular strand. Or the key accountable person could choose to delegate just one or two strands while keeping the rest themself.

Another example would be to divide up the entertainments remit so that the ents coordinator (who’s a key accountable person and part of the primary team) delegates to three or four different accountable people the three or four different nights of BiCon.

This has the happy effect that during BiCon, the person with most to manage on each night’s ents has the other nights off.

The ents coordinator’s job would be to ensure that the different nights were varied and compatible, and to organise obtaining shared resources such as a PA system.

The ents coordinator would certainly have an apprentice (shadowing, and e.g. perhaps taking on liaison with the PA hire company); the one-night organisers could well also each have an apprentice or second-in-command.

A similar kind of structure could be mapped onto publicity. There’s room for a huge number of people to take on a small share of that work.

The first delegation-split could be e.g. to a radio outreach person, one or more printed-media outreach people, a postering/flyers coordinator and an interviews coordinator. Then the interviews coordinator would manage a team of willing interviewees available for either radio or magazines, and the postering/flyers coordinator would coordinate the distribution of our publicity materials all over the country.

But where would we get all these people?

I’ve named a lot of roles there, so I can imagine people reading this and thinking “But where would we get all these people?”

If you’re thinking that, you’re missing one of my main points – arguably the main point. The point of creating this more complex structure is to make available smaller roles, which are more accessible to people who don’t have the time / energy / inclination for BiCon to eat their life. The idea is to bring enough new people into action for the “energy shortage” concern to disappear.

For example, you don’t have to have different people doing each night of the ents, and an apprentice talking to the PA company. You can have one person doing all of it if you like.

But is it going to be easier to find one person who can afford to give that much time, or the four or five who could give a smaller amount?

My thesis is the latter will be easier to find. If I’m wrong about that, well then, “as you were” :-)

(My list of suggested roles for the BiCon children strand should be seen in this light too. I did say that it was possible for one person to do them all, but some people seem to have missed that point, hence comments about “doubling team size”. Obviously, under this model I don’t think it would be a bad thing to double the team size! But the children strand would still only be a small proportion of the overall workload. How many people it’s divided among is a matter of team organising style.)

People not to have on the team

The only people I’d turn down completely and not have on the team would be those who were unwilling or unable to align with the organisation of the team.

E.g. obviously I don’t want someone who’s so oblivious to the general consensus that they’d go shopping on the event’s behalf and buy a load of stuff which no-one else had agreed. (Not that I could stop people doing that by not having them on the team, actually. But at least it would be a bit clearer to them that it was un-called-for.)

Including people of no track record

People with no track record wouldn’t be picked for the main roles, but I’d be unlikely to turn them away either. There’s plenty of room for them all within the “contributors” category.

Flyering in one’s local area is one place where we can safely offer a job to more or less anyone. There’s always more room for work on spreading the word; and as we shan’t manage to cover everywhere anyway, there will be venues where it’s arguably not that significant if someone doesn’t do what they said they would.

In the case of BiCon, there are also jobs which can be scheduled far enough in advance that if one person doesn’t deliver, there’s time to take the job back and give it to someone else – a low-risk gamble. One example would be the early creation of new artwork.

Necessary skills: Creative slicing

One of the key skills in creating a jigsaw like this is deciding where to cut around the pieces (or, to put it another way, working out which tasks can reasonably be stuck together to create one person’s role).

This is partly about discerning the logical divisions and connections among tasks.

For instance, the people doing the budget are connected to the ents coordinator – but only in that they need to agree an overall budget for ents. Otherwise, those are readily separable jobs.

Before even beginning to look for people to be on the team, I would put time into developing a catalogue of ingredients, identifying all the job components which have previously been done by anyone in any role, and how they interlink. I wouldn’t attempt to do this alone, but would run it past people who’d actually done various BiCon roles in the past, asking them “Tell me everything you actually did”, and then “Was there anything more you would have done if you’d had time?”

Another underlying skill is of eliciting from people what they really enjoy doing. This would probably be quite easy if so many of us hadn’t been socialised to think it was our duty to “take the rough with the smooth” in these matters. “You mean I could have a job consisting only of the bits I enjoy? Surely some mistake?”

All these tiny job components would be described by outcome, time commitment and relevant skills, and people would be invited to express interest in them.

I could imagine a workshop at a BiCon, where all the jobs would be on paper stuck round the room, and people could go round putting their names on any they’d be up for doing, with a star for any they specially wanted.

This would be reviewed after BiCon with the key accountable people, to customise their own roles and to share out the rest of the jobs. It would remain as a directory of people who were interested in contributing to that BiCon.

A similar list could appear on the web site during the year or more running up to BiCon, along with forms for expressing interest.

The final ingredient is to set up communications between people in connected roles.

Intra-team communication software

For the team’s internal communications, the software I’m imagining is a bulletin board/forum such as vBulletin or the forum component of Drupal. I haven’t gone into detail on which specific package would be best, but ideally, this – like the main BiCon site – would fall within the remit of a multi-year not-reinventing-the-wheel team. So we’d want to pick a package with a long term future, ideally fairly widely used.

The forum would be set up beforehand so that each subteam had its own area. This would facilitate keeping the different conversations separate, and not swamping people with things they don’t really need to know about. People could look in areas they weren’t directly concerned with, but they needn’t; and in general it wouldn’t be considered “the done thing” to stick in one’s 2p on other subteams’ threads.

Compared to a blog format such as LiveJournal, a forum/bulletin layout is more suitable both for the separation of subteams and because (unlike blog articles), forum conversations slide away down the main viewing page only when they’ve stopped.

Compared to email, it’s better for later reference, and also takes care of threading (which not everyone’s email software does well). Some forum software also supports sending email copies of messages under certain circumstances.

If the package included calendar facilities (which e.g. vB and Drupal do), we might take advantage of those to display the timelines.

For some people, using it would mean a new learning curve. But that kind of software is pretty common across the Net, so there would be a reasonable number of people reasonably familiar with the idea of it to start with.

Timelines and reporting back

Each key accountable person would customise their own job description and draft a proposed timeline for the run-up to the event.

The timelines would be visible at least to other team members, and we’d probably specially invite the biconorganisers group to cast an eye over them too.

These timelines wouldn’t be set in stone, but would be used as a framework by which to check how we were doing and flag up areas which needed attention.

I’m imagining that every now and again we would have a round of “how’s it going” reports on the online team space.

The deputy or apprentice “People and process manager” would have the job of noticing anyone who seemed to have disappeared, or anything missing from the conversation (such as a forgotten milestone from the timeline).

The process manager (me in my imagination, or whoever else was in that role) would then actively find out what was happening – whether that person needed more help or more resources, or whether in fact they needed to be replaced and gently given the boot, to prevent unnecessary martyrdom :-)

In the cases where a key accountable person was managing a sub-team, they and their deputy or apprentice would also have the job of checking in with their sub-team people about progress. Again, it would probably be the deputy’s job to look out for people “disappearing” or obviously having trouble.

In between “reporting rounds”, it would also be part of my job to provide a listening ear for anyone who was having problems. I.e. they needn’t wait till report time to get in touch individually and say “Here’s a problem I’m having”. And I wouldn’t necessarily wait till report time to check in with people and say “Give me some stories – how are things with you? Is there anything we could invent to make things easier or more enjoyable for you? Is there anything going on at the moment that you’re finding annoying?”

I would probably try to have that kind of conversation at least once with everyone working on the event, or at least with everyone except some of the “contributors”.

Necessary skills: a keen eye for process

The second “necessary skill” that I’d name for the process & people manager is (not surprisingly) a keen eye for process, in particular for communication. You need someone who will take a proactive role in shaping the communications of the team, in particular watching over which people need to be in which conversations and which don’t. Otherwise, the number of people on the online team area could potentially make conversations too slow and/or prone to going off-topic.

It might be necessary sometimes to say something like “OK, we know that not everyone agrees on this, but in order to move on, we’re going to proceed in such-a-way”. I would envisage that most times the accountable person for a particular area would have final say about how things are done.

Similarly, it might be necessary sometimes to rein people in back to their own areas of responsibility, or back on topic.

Necessary skills: compassionate ruthlessness

Part of taking the risk of having less-experienced, less-well-known people on the team is that it probably increases the chances of at some point having to boot someone off. Whoever’s in charge needs to accept that responsibility.

On the other hand, some booting-off is made necessary by people over-extending themselves, and I suspect this is possibly less likely when the jigsaw pieces have been well set up in the first place, and there’s an abundance of people queueing up to be on the team. So maybe it all works out about even in the long run.

A similar kind of ruthlessness may be needed sometimes in managing the process of communication (as described above).

Investment and risks

I’m not denying that in the initial setup, and in many ways during the process too, it would be more work to manage a team in this way than to stick with the smaller team of BiCon tradition. But I also think the added work would be well worthwhile. It would be an investment, and i.m.o. not even a very risky one.

You start with a team that could run the event anyway. So the event isn’t at risk.

Each key accountable person trades off {some time spent explaining} against {some time not having to do routine jobs}. Unless we’ve picked the wrong person to be apprentice, that trade should come out at least even in terms of time and energy.

Picking the wrong person as apprentice is a genuine risk, but the downside is probably only some trouble for the key accountable person. (Compare that to the downside if we’d given that “wrong person” their first chance as key accountable person for the area.) And the upside is potentially substantial.

Having more people potentially makes the conversations harder to manage, but also builds in spare capacity to cushion against unforeseen events and the (predictable) high-demand times just before the event and as it starts.

But in any case, there’s a sense in which it isn’t just about “which way is easier for that particular event”. It’s about each team deciding: is their intention purely to run an event, or is their intention to run the event and nurture the skills and experience which will be needed for future similar events? And if the latter, what are the most effective/efficient ways of accomplishing that aim?

Questions

In terms of responses to this article, what I’m most interested in is

  1. Why would this not work, according to you?

  2. Why would you not want to do it even if it did work?

  3. Related suggestions – what else might go along with all this, &/or complement it, &/or be an even better idea?

Agreement and appreciation are also very welcome of course :-)

Here, have an index:
Not herding cats: big team job design
Background
Team size and structure
Jigsaw
Not reinventing the wheel
Categories of people and their roles
Primary team / key accountable people
Apprentices
Advisors
Special mission people
Contributors
Sub-leaders
But where would we get all these people?
People not to have on the team
Including people of no track record
Necessary skills: Creative slicing
Intra-team communication software
Timelines and reporting back
Necessary skills: a keen eye for process
Necessary skills: compassionate ruthlessness
Investment and risks
Questions

5 thoughts on “Not herding cats: job design for teams”

  1. @ Dave

    Hmm. Perhaps this is just me being cynical, but in the absence of further context I find it impossible to take that question at face value. (It’s the kind of thing people say when they mean “It’s easy to talk, but show me the goods” – a kind of “Justify your right to say that”.) Sorry if I’m misinterpreting you – I don’t know who you are, so it’s nothing personal.

    To respond to the face value anyway, the literal answer is “none” – or elaborating slightly, “none on my own, and contributions to a few”. I’m not sure that really tells you much though, since I’ve organised other things which weren’t conventions. And would it not be more useful to know whether the things I’d invented in the past had turned out any good? ::grins::

    Anyway, I wouldn’t recommend that anyone do anything I’m describing here unless they have their own sense that it would make sense.

  2. I’m glad you finally got around to posting this; it’s been a long time in gestation! I guess I’m privy to a fair bit of the background to these ideas, our having worked together on the BiCon05 team where many of the seeds were undoubtedly sown.

    As a “thought-experiment” to use your term, I like the overall concept. I don’t think that you’re suggesting such a team structure could evolve overnight… For BiCon09, I’m in the process of drawing up a document which I’m calling “Areas of responsibility – team plan” In my ex.perience of running other projects (mainly in engineering) it’s vitally important that everyone is absolutely certain of their particular responsibilities, where these end and how they dovetail with those of others on the team. Likewise, your concept of a “process manager” and their role in defining responsibilties and managing & supporting team members entirely fits my own notion of how this should be done.

    Not re-inventing the wheel? Quite a lot of peopple agree on this and, as you mentioned, some efforts are being made to set up more permanent systems in the areas of finances, website, bookings database, etc.

    As for the role of apprentices, I’m thinking about this. It’s hard enough to find dedicated people to fulfil roles as it is. We’re all volunteers, after all, and have to juggle BiCon planning with other aspects of our lives. Having to keep an apprentice up to speed (as opposed to simply giving another person a small, self-contained chunck of work to do) might well increase the burden beyond that which the key people are prepared to accept. It also requires that the key people themselves are good managers of people.

    There are some excellent points in this, and I’d like to see the concepts discussed further.

  3. @ Martin

    Thanks for those thoughts!

    Very interested to hear about your “Team plan”. That sounds like something that would be valuable in the public domain at some point – not so that people can copy it exactly, but so they can build from it to do their own.

    It also requires that the key people themselves are good managers of people.

    This is a good point, and not one I really went into. I’m going to ponder it some more and maybe sprout another article in the fullness of time :-)

Appreciation, criticism & new ideas all welcome...

Optional HTML tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Comments are moderated. Please no name-calling; please speak for yourself from your own life, or else say where you got the info. Thanks :-) Why these commenting guidelines?