Talk:Maximum Free Geek - Revision history

Rfs at 16:16, 10 June 2006

2006-06-10T16:16:47Z

Rfs: /* Thoughts on administrative staff */

2005-01-20T17:25:29Z

Thoughts on administrative staff

Rfs: /* It's bad enough that we'd change something somehow */

2005-01-20T17:23:25Z

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

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

2005-01-20T03:29:03Z

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

Shawn at 00:16, 13 January 2005

2005-01-13T00:16:16Z

New page

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.

[[User:Shawn|Shawn]] 16:16, 12 Jan 2005 (PST)

@@ Line 29: / Line 29: @@
 == Thoughts on administrative staff ==
-One other thing: 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.
+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.

@@ Line 25: / Line 25: @@
 Maybe we should take a short cut and adopt some of those systems even if we don't get too big.
-One other thing: When I mentioned the growth issues we were going through to my dad the other night, he mentioned "more clerical staff". (He's started a couple of businesses in his time and worked for IBM for years.) I guess that means more people at the front desk that keep track of what's going on for the rest of us.
+[[User:Rfs|rfs]] 19:29, 19 Jan 2005 (PST)
-[[User:Rfs|rfs]] 19:29, 19 Jan 2005 (PST)
+One other thing: 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.

← Older revision		Revision as of 03:29, 20 January 2005
Line 12:		Line 12:

	[[User:Shawn\|Shawn]] 16:16, 12 Jan 2005 (PST)		[[User:Shawn\|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.
		+
		+	One other thing: When I mentioned the growth issues we were going through to my dad the other night, he mentioned "more clerical staff". (He's started a couple of businesses in his time and worked for IBM for years.) I guess that means more people at the front desk that keep track of what's going on for the rest of us.
		+
		+
		+	[[User:Rfs\|rfs]] 19:29, 19 Jan 2005 (PST)

@@ Line 1: / Line 1: @@
 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?
+: [[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.