Talk:Maximum Free Geek

Some thoughts to kick off the discussion

Since it's time to get ideas out there, I thought I'd start by identifying some of the issues I see involved with growing larger. The maximum Free Geek idea is obviously an extreme, which the other options like 'Sister Free Geek', etc. are as well. I don't think that any extreme will work that well, but they're good to examine.

Communication/cross-fertilization

Communication is important. It's part of how we get things done and think of new things. It's also how people in one area of free geek find out about other areas and can then adjust how they do things to make free geek more integrated.

Maximum Free Geek: this model would make it much more difficult to communicate, as staff and core wouldn't see as much of each other. Documentation and methods of communication would need to be quite straightforward and efficient. We could do that. Max Free Geek would probably also require a doubling up of coordinators, which might make things a little messier (it always takes up a little bit of time to get onto the same page with your co- every week). Dave, who's currently sitting beside me, says that it's much harder if you have 2 co-coordinators doing the same thing at different times of the week. The better deal is if co-cos can specialize, and then they're not really co-coordinators, right?

Cross-training/cross-fertilization

This does the same as communication, in a way, but keeps staff and core feeling up on new knowledge. Face it, it's fun to learn new stuff. Bottom line, it's important that staff has BBB, PBBBBB, recycling, build, teaching, admin, or whatever they're interested in, shifts besides their regular jobs.

Max number for comfortable decision-making

Consensus is harder to reach as the group gets larger, and needs to get more formalized, too. Richard suggests not more than 24 people for a comfortable-ish process on bigger issues. I'd almost like a couple less.

Quality of life

A 32-hour work week is great. Especially at Free Geek, where practically every one of those hours is full of mayhem and endless todo lists. The Max Free Geek model keeps this intact. Cool.

Shawn 16:16, 12 Jan 2005 (PST)

It's bad enough that we'd change something somehow

Oso points out that some things aren't quite taken into account.

For instance, there would obviously have to be multiple coordinators for each area (e.g. Three Recycling Coordinators). This simplifies certain things. For example the scheduling of recycling could be handled by those three coordinators. It would still be necessary for that group to register who's on duty so the front desk would know who to poiont folks to, but they could pretty much set their own schedule.

Only those programs with few enough coordinators would tend to leave holes in the schedule, so we'd still need some sort of master schedule, but that job might actually be easier than it is now.

Point being that the stresses of getting too big would lead us, quite naturally, to adopt systems that make things more sane.

Maybe we should take a short cut and adopt some of those systems even if we don't get too big.

rfs 19:29, 19 Jan 2005 (PST)

Thoughts on administrative staff

When I mentioned the growth issues we were going through to my dad the other night, he mentioned "more clerical staff" as a solution. (He's started a couple of businesses in his time and worked for IBM for years, so he's coming from a fairly mainstream background.) I guess that means (in his mind) more people ("secretaries" or "administrative assistants") at the front desk that keep track of what's going on for the rest of us. I started thinking about how this might work at Free Geek.

People have started using the word 'department' or 'program' to describe some part of Free Geek, for instance Build or Recycling. Let's say that we could decentralize some of the administrative tasks that the front desk and other staff are currently doing. As an experiment, let's just look at build -- but this could apply to other departments/programs.

Right now volunteer scheduling, tracking a build volunteer through pre-build, and recording hours happens at the front desk. Scheduling of staff time goes through the staff scheduler. What if we moved that job back to the build area and added a staff person or volunteer intern to take on those responsibilities? So for instance already established build (and pre-build) volunteers would go to the build area to get their hours recorded and sign up for their next shift? The staff build team would be responsible for making sure that the build shifts are covered by a staff person. Ideally, they could register who's covering which shift with some (yet to be completed) scheduling software, so there would still be one schedule the front desk could use to point confused build volunteers to.

To do this, we'd need someone to take up the responsibilities -- and that could be a dedicated volunteer intern, a staff intern, and/or shared by the current build coordinators, but we wouldn't want to overburden the current build staff with too much of that work. Assuming an intern of some sort, this person's job would be to maintain, use, and provide all the howtos, procedures, and paperwork for the build and prebuild programs, offloading that from the front desk.

Reception, then, would find itself referring more situations back to the build area, which means the phone systems would have to work better and such. The scratchpad feature of the database, a wiki page, or the mailing lists might also help.

In the Maximum Free Geek scenario (or some scenarios between present day Free Geek and that) each department or program could be set up like this. I could imagine a tech support crew doing something similar. The volunteer end of adoption might have to be a single unit, but Receiving/Testing and Recycling might coordinate staff scheduling.

Just an idea. Maybe there's something useful there. I dunno.

rfs 09:23, 20 Jan 2005 (PST)