Can we improve Open Oakland's project capabilities with a bit of organization?

[tbarreca]

There will always be many more ideas for projects than we'll have resources to do, and as I've pondered this problem, it has occurred to me that with a bit more organization, we could increase our efficiency enough so that our capabilities would actually be increased, and maybe by quite a bit.

The ideas are pretty simple:

1) We create a Skills Bank of our members, and 2) We create some standing committees (or something less bureaucratic sounding) that are organized around function. A lot to discuss here, but some functional areas might include: Press and Public Relations; Technical Documentation and Support; Product Management (the team that would be responsible for helping various projects with, for example, requirements specifications); User Experience/Interface; and Legal.

Then, each of these groups can work with each of the project teams to provide support in their area of expertise.

I am hoping that were we to adopt something like this, we would enhance our effective bandwidth and provide additional opportunities for those who are not especially technical to contribute.

I have no idea if this proposal makes sense, or whether it would work, in the Open Oakland context.

[tbarreca]

From: Jeff French jfrench@ixley.com via googlegroups.com I like this concept, but my bias is that this type of organization seems like it would be more useful when allocation of skills to projects is more of an issue than actually having enough of those resources to dedicate to different projects. The appeal is that this structure implies more buffering for different needs, but again, it seems like we need higher throughput first.

[tbarreca]

From: Tony Barreca tony.barreca@gmail.com Thanks for the reply, Jeff.

I think you implicitly point to an issue I had as I was thinking about it. The structure might be too heavy-weight, and from a process point of view, I have always been a shrink-to-fit sort of guy. If we decide to try anything like this, at its inception it should be as minimalist as possible. I'm not sure exactly what that means or how to do it, but that's for a later discussion.

Wrt your larger point, it was my hope that a bit more structure than we currently have would help in attaining a higher throughput. One hopes that we could create a virtuous cycle:

Higher bandwidth->more projects->even higher bandwidth->even more projects, etc.

Where we enhance org structure at points deemed appropriate in this process.

Again, this is all theoretical, but as I said, I approached this as a resource allocation problem while wearing my manager hat. ;-)

[tbarreca]

From: Phil Wolff pwolff@gmail.com

OK, so we're talking organization design.

We have one structure: the project team. Informally assembled, no formal milestones or processes, few have identified leaders, and their membership drifts in and out.

Conditions are changing:

• We are facing challenges of scale. More volunteers (perhaps 200 active by year end), more City partners, more events and projects each year.
• We are resource limited: Funds not committed for next year; not at levels permitting growth
• We are undertaking more difficult projects, requiring longer learning curves, higher risks.

Effects:

• Management span of control becomes too wide. Brigade captains, for example, can't know everyone's names or who is active.
• Project continuity is a bigger problem
• Retention is a bigger problem
• Team talent imbalance is a bigger problem (missing key skills)
• Unable to serve "i want to learn" volunteer goals

We can brainstorm strategies. Two I like.

Teams for the business of the brigade: finance, IT/ops, product management, fundraising, etc. If the brigade had an office, these would be the staff.

Cadres or guilds organized around skills/professions/practices. Design/Experience, DevOps, Communication and Outreach, Growth Hacking, BizDev/Liaisons/Relationships. They recruit colleagues, orient newbies, build skill, choose standards, select tools, and staff projects. These would keep volunteers connected between projects, serve as a resource during projects.

With staff, cadre, and project groups, we'll need a bit more process; perhaps matrix management.

[daguar]

I've been thinking about this issue in related terms.

I think a key driver of team success is having what I'd call a "technical product manager" role. I think the two main responsibilities of this person are:

1. Suss out, defend, and communicate the user and impact goals (consistently)
2. The ability to break a project out into compact, independent technical components, where someone can contribute towards some impact in 2-4 hours of work

In my humble opinion, I don't think organizational structure achieves this as much as empowering people with the intrinsic motivation on a project with a toolkit and framework to implement these two broad tasks. I've been talking with Andrew Hyder (@ondrae) about just this framework at the all-Brigade level.

Anyway, just just my 2 cents.

[tbarreca]

Certainly toolkits and frameworks are necessary. On the other hand, I'd argue that we have already begun to prove that they are not sufficient.

Doesn't much matter. Tools and frameworks and a little more org structure are not mutually exclusive. I'd bet that they are complementary.