RFC: Organizational Changes – Engineering Service

[Paul W. Frields]

On Fri, Feb 05, 2010 at 12:21:38PM -0900, Jeff Spaleta wrote:
> On Fri, Feb 5, 2010 at 9:07 AM, Mike McGrath <mmcgrath at redhat.com> wrote:
> > The obvious flaw here is “will people volunteer?” I think they would.  I
> > know I will.
> 
> This is very good...and its straight out of the volunteer coordination
> handbook I was pimping a few FPL's back.
> 
> A few comments.
> 
> When people sign up... don't just ask for hours a week.. ask for a
> specific long term time commitment...like a 6 month tour of duty.
> Make a huge deal out of new people signing up for their first tour of
> duty. Make a huger deal of team veterans reaffirming their role as
> engineering task monkey for additional tours.  Since this team is a
> service team and won't be as self-directed..its important to shift the
> reward balance to overt recognition.  We tend to reward our current
> volunteers groups with self-directed control of their area of work and
> we can't do that effectively for a service team that reports to fesco.
> 
> Also...try to communicate the initial skillset needed in the team. If
> fesco could sort of roadmap what they think they'd like to see built
> in say the next 6 months...break that down into anticipated skills and
> manhours.. you can try to recruit for that anticipated need to fill in
> the skill gaps for a new project.  You can't anticipate all desirable
> skills and experience ahead of all possible tasking of course. But you
> want to recruit a certain baseline of experience and keep the tasking
> inside that skillset pool as much as you can. Big new tasks with
> unanticipated skill needs can be pushed back into the next tour of
> duty and highlighted in a recruitment call-to-arms.
> 
> And...along the way create some opportunities to broaden the skillset
> of team members. A service team like this could be the perfect target
> for specialized team members only classroom skills training.

The crux of the biscuit[1] is breaking down a task in a way that lets
a volunteer know whether they have the skills needed to work on that
task.  That's not impossible or even that difficult, but it does
require some work -- which is why having someone managing that
process, i.e. responsible for the breakdown -- is important.  Saying
"I need help accomplishing this large task" is not as helpful as
saying, "I need help accomplishing this large task, which consists of
the following four procedures, listed below with the knowledge,
skills, and abilities you'll need to have to do them."  The investment
of time to list those elements out is worthwhile if the task is
honestly something that really needs to be managed over a period of
time.

I like the idea, Mike; does this thinking jibe with what you had in
mind?

* * *
[1] sorry, Zappa ref

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
          Where open source multiplies: http://opensource.com