Holacracy Community of Practice Archive, 2015-2019 Community Holacracy Web Site

Project Updates

We have observed what we believe to be a dysfunction in our holacracy regarding Project updates.  The person that owns the Project will ask others for help to report on the Project, or someone besides the Project owner might offer unsolicited additional information on the Project.

It seems to us that this might indicate that the Project is actually assigned to the wrong person.  Therefore, limiting speaking to only the Project owner might surface a tension that owner of the Project should be changed.  Does that sound reasonable to everyone (cutting off help from others during Project updates)?

The process is often criticized by participants as being to rigid, so I don't want to introduce counter-productive rigidity.

5 Replies
Ivan Matosyan

Hello Geoff, 

What we do, and I think it works for us. 

Project update have to be given by project owner, even in situations where majority of tasks are performed by others. If owner of the project thinks that it is not one of his roles accountability to work on the project he can ask appropriate role to take over the project.

What we have sometimes, that the outcome/project has more sub-projects, which are taken by different roles. Than there might be several updates from more people.

About rigidity, we have same critics, but in my opinion it is ok, people are people, we do not like to go out of our comfort zone. It is important that facilitator take into account holacracy maturity of the team and adjust his facilitation to it. 



It is very possible that the projects are not assigned to the right people but I would sense into your tension about the project updates portion of the meeting. Use coaching and facilitation to frame the projects section better and dig into the tension by questioning, to learn with your colleagues how to make changes.

Most people have been in a (non-Holacracy) meeting where project updates go on and on, the person talking seems unaware of others disinterest, information is repeated, unnecessary information is shared, and everyone tunes out. Most people don't like those meetings and don't want their meetings to be like that. It is however hard to see that when you're the one talking. 

I would start with getting information about how others feel the project round is going. You may surface information that enlightens you to the fact that it's not dysfunctional colleagues but learning that is needed. Responding by tightening the rules to say only the project holder can speak would likely feel too rigid not because it's a bad strategy but because you don't have all the information. You can add an item to the agenda and say, "In my role of X I'm feeling tension about our project updates section. I'd like to request information. Do you feel there is anything we could do to make that section work better for you?" You may find that others have a similar tension or surface information about why it's going the way it is. If you're the lead link they may be trying to report to you, to please you. In our organization, we found that people felt pressure to have something to say so we had to do specific practice in training to make it safe to say, "no updates". People in our organization wouldn't record projects because they didn't want to see them and be asked for updates so they avoided recording. I thought it was resistance to the software but it was discomfort with being asked for updates each meeting. 

Once you have a deeper sense of what is going on you can see how you can coach in and outside of meetings to move toward more efficient project updates section.

The facilitator can frame in the moment, "We are going to keep our project updates brief share just what is new since last meeting. Feel free to say no updates if you feel the group is sufficiently in the know." 

Other framing:

- Just share what you think your colleagues need to know for their purpose.

- Just share what others have requested to keep updated on.

- Try to avoid sharing things we may have heard before unless specifically asked.

It is highly unlikely your team wants to sit through a long unproductive project update section but it is possible that this practice of multiple people speaking to give updates help some people see a picture of what work is happening where. You won't know until you ask. 

If you have a tension about where a project lies, add it to the agenda, "I'm looking to get clarity into x project, it is held by y role and I heard a lot of updates from z role. I'm wondering if there are two projects? X that was waiting for some project held by z? Or I wonder if maybe it is recorded inaccurately? Does anyone have any clarity into this?"

This is a learning process and I encourage you to lean into it, try to support others with coaching, training, and facilitation rather than controlling with rigidity. Look for learning from struggles.


Keith Jarvis

If I have a pressing need to comment or inquire about your project, I have a Tension.

It's okay for a circle member to ask a brief question about a project update for clarity, but if it's a deeper inquiry about the how or why of the project, I suggest that Facilitator should ask it to be captured as Tension to address during Triage.

Also I like Jenn's suggestions re: coaching circle members on updates, especially if/when a lack of understanding is demonstrated through over-sharing or under-sharing.

A process time-out is great, or contextual reminder heading into the project update section 'what might be useful for other circle members to know regarding what is different about your project since your last update?'


Jeff Kreh

The phrase "we're rigidly flexible" comes to mind (Sam Carpenter, if memory serves); meaning, "We do things THIS way and the instant we discover a better way, we will update the way of doing things." The combination of rigidity and flexibility makes us agile, not fragile.



Chris Cowan

[@mention:549059653907130620] this may be duplicating what others have shared, but my guess is that the "problem projects" are high-level ones and even though they have one overall owner, there are tons of sub-projects for other roles within that, which others feel are relevant to share in that space (especially if they don't have their specific sub-project already on the board). 

If that's the case, then I can see the project updates get a little messy. In fact, I wrote a blog post about this issue and how GlassFrog isn't helping us here because currently, the only way to sort projects in GlassFrog are by person or by role. Neither of which allows a circle to cluster related projects together, which contributes to the confusion of how you’re supposed to provide updates on projects.

With that said, my recommendation would be 1) share the blog post because I think it provides some important context; and 2) until tagging projects is allowed in GlassFrog, use brackets like, “[Project X]” or “[Project Y]” in the project title to make related projects more recognizable.

Afterall, if I'm an "umbrella project owner" (for lack of a better term), then the other sub-project updates related to that project are in some ways most interesting for me. And it would seem kinda silly to try and provide some generic or general overview of progress myself on the overall project, when in reality the actual progress is being made by the sub-project owners. 

Now, of course you don't want the updates to just be a free-for-all discussion, because that isn't what that space is for, so I've found it helpful to remind people that the project updates space is NOT for: Discussion, requests for actions, making decisions, or sharing opinions. That seems to help keep it disciplined even while it's not as simple or direct as the other updates. 

I hope that helps.