Hi Andrew,

If you've already 5 teams clearly separated and largely independant, seems reality gives you a good reason for it may beyou didn't catch clearly already.

• I would have a look at the upper circle. Even if the 5 "line" roles have the same role description, setting a focus to each role holder may give you some more clarity.

• Another way is to modelize reality by setting 5 different roles (line 1, line 2...) in the stucture and let the process do its work.

• You could also have a look at the coupling beetwen the differents lines. Low coupling will tell you if the 5 line are really seperated.

 

Hope that helps.

Hi Andrew - Are those reasonably long-term teams (vs. ones that will disband in a few months), and will each face different circumstances and contexts, such that each may want to adapt to its environment slightly differently?  If yes to both, then you may still want to have one circle per team, even if they start with very similar or identical role descriptions, so that they can then further adapt via governance from there.

 

There are other ways to structure this as well - this isn't necessarily the best option, but thought I'd suggest that it is one option, and I think often a good one.  Consider asking a coach real-time during one of the coach office hours sessions for more options and suggestions.

 

Brian

Thank you for the reply, I'll try to provide a little more context to the question.

The teams are cross-functional but largely undifferentiated with no driver to have them differentiate. As a company we provide software development services to a range of clients and are organised into cross-functional teams of 5 - 9 people for simplicity's sake. The rationale at the time was each team would run a little like a business within the business - each responsible for its own gross profit, resource allocation, forecasting of work, etc. This has worked very well to date but we are starting to see shortcomings when it comes to the need for collaboration between teams and, unfortunately, not all work arrives in perfect team-sized chunks. Sometimes a team may be over capacity and others under capacity. We are looking for  the next step beyond rigid team boundaries but don't want to return to the days of a single large "resource pool". We can see how Holacracy will afford us better self-determination and greater flexibility but are trying to work out how best to map the current model before moving forward. 

Makes sense Andrew; and mapping your current model makes sense to me as a starting point - the structure will evolve over time once you start running Holacracy governance meetings, so the goal at launch is just to map what's actually happening now, not to try to change anything.  If you're running in cross-functional teams now, just map that as-is, one circle per team.  And if people are filling roles in multiple circles upon occasion, that's just fine - people are not assigned to circles in Holacracy, but rather can fill roles in any/many circles...

 

Hope that helps!

- Brian

Hi Andrew! Very interesting question as we are facing the exact same problem...

What did you decide in the end? How did it evolve since then?

Doing a circle for each team seems okish, but then do they all create Product Owner, Scrum Master, Dev.. roles internally? Starts to sound weird. Someone here suggested to create PO, SM, Dev.. roles at GCC level and then Cross-Link them to the different teams (which also sounds weird with so many Cross-Links).

Any feedback appreciated!

Laurent, based on a discussion with Brian we ended up creating separate roles for each team, which worked out very well for us.

As we went through the process of mapping roles it became apparent that each team had different accountabilities for developers and sys admins, etc. Some teams even had roles that others didn't (e.g. Tech Support role vs. accountability for tech support on Developer role).

I was quite surprised as we're a small company (~40 people) doing more or less the same work for each client. That said, the teams have had a about 18 months to differentiate before we adopted Holacracy - it was an interesting exercise to sit down and map this out.

We did discuss creating "template" roles in our Delivery super-circle for use when starting a new team. We decided against this as it turned out to be more simple to start by copying a role from another team and then modifying to suit. I noticed that the feature list for constitution 5.0 has a suggestion for template roles.

Thanks a lot for the feedback Andrew!

Just to make sure i get this right: you then have "Team X Dev" and "Team Y Dev" roles? (respectively in Team X and Y circle)

And both teams are part of the "Delivery" circle which is itself part of GCC?

Sorry to be so specific, but it's really interesting to compare your approach with ours. Thanks again!

Yes, Team P and Team T to be specific. Each team circle belongs to the Delivery circle, which in turn is a part of the GCC. We toyed with no Delivery circle but decided it was necessary for the allocation of work - the Delivery Lead Link is responsible for allocating work to teams (we have an "auto-allocation" policy that expedites this).

Amongst other roles, each team has a role Developer but with slightly different accountabilities, only one team has a Scrum Master, and only one team has a Tech Support role. One team has most roles multi-filled across the team while other teams have chosen to have more specialisation.

As a side note, we are using Attention Points (borrowed from HolacracyOne) to give us a better framework to set and discuss time required for each role within a team. It looks good so far. 

thanks so much Andrew. Really appreciated!

(for the record "Attention Points" is described here: https://glassfrog.holacracy.org/policies/3628)

laurent posted:

thanks so much Andrew. Really appreciated!

(for the record "Attention Points" is described here: https://glassfrog.holacracy.org/policies/3628)

I'm curious how the APs are tracked/exchanged. Is there an internal currency banking system that allows "hiring" others into role fulfillment/assistance or "free-lancing" to help others?

We haven't found a need to track too explicitly as yet. Rather we use APs as a way to have structured conversations about capacity and where effort (attention) needs to go.

I am somewhat against keeping timesheets (for many reasons) so would be cautious about tracking APs as it may lead back to some of the same thinking that the mindset of working for time brings.  

The only step we have taken in this direction is allowing (through a policy) the Delivery circle to self-allocate more APs based on work projected in our pipeline. We have a simple "Hiring Trigger" policy that triggers our hiring process if the allocated APs exceed the circle's actual capacity. At the moment each delivery team simply keeps a spreadsheet of allocated APs for each role and actual by person in role. I am writing a simple app that we will trial to track total APs for a person energising roles across circles (i.e. working outside a Delivery team). 

We just use a Google Sheet to track them; not ideal, but it works enough to get us by (at least until GlassFrog can track them!).

We started by exporting all of our roles from GlassFrog to a spreadsheet via this tool:
https://holacracyone.github.io...s_roles_fillers.html <https://holacracyone.github.io...s_roles_fillers.html>

… then, we imported that into a Google Sheet, added a column for the AP’s, and then a couple of pivotables to automatically sum AP’s per Circle and AP’s per Partner.

- Brian



> On Jan 20, 2016, at 3:35 PM, HolacracyOne <alerts@hoop.la> wrote:
>