While the Holacracy constitution gives you guidance on roles, circles, and accountabilities, it’s less clear when it comes to coordinating and completing project work. This is intentional because the constitution can’t prescribe how this should be done in every organization.
Yet, this is understandably confusing for new practitioners because while they are learning about specific constructs like accountabilities and domains to capture how work gets done, the constitution doesn’t say much about projects explicitly (other than calling it an “outcome”).
And understanding how projects work in real-life Holacracy practice relies on interpreting two sections of the constitution: 1) Responsibilities of Role-Filling; and 2) Duties of Circle Members; and even then the assumptions behind these rules are not obvious.
To simplify this whole thing, here are five distinctions about projects you need to understand.
- A Project is ANY Outcome
- No Such Thing as a Group Project
- Public Projects are Different from Private Projects
- A Project is Always YOUR Project
- Tracking is Different from Doing
Note: Unfortunately, these distinctions can only be described one at a time, but only make sense when taken together. So, if any particular explanation doesn’t make sense, hold on. It should be by the end.
A project is ANY outcome
In Holacracy, a project is an outcome. The point isn’t philosophical — it’s simple. We can call any goal a “project.” But don’t overthink it. The constitution proudly borrows this definition from David Allen (read a summary of David’s perspective on projects here), which is both simple and elegant. Since accountabilities define ongoing actions, projects allow us to get more granular and concrete on tasks with definite endpoints.
This is why we phrase a project as if it was complete. We say, “New Product Launched” rather than “New Product,” to force our thinking to choose one of two options. Either that outcome has been achieved or it hasn’t; and we need to stay grounded in the overall goal. The binary nature of a project opens up our creativity and orients our action. And since self-organization allows us to make project requests of each other, we need more clarity than phrasing like “New Product” provides.
Another common misconception is that “a project” should have some sort of objective level of granularity. It doesn’t. There is no objective standard of what a project means other than “an outcome.” So, it can be anything from a big project like “New Business Launched,” to something small like, “Empty office trash can.” The goal is to track whatever project-specificity makes sense to the one single person who owns it. Which leads us to…
No such thing as a group project (or at least there should always be one clear owner of the whole thing)
There is no “I” in team, but there is a “T” “E” “A” and “M.” Meaning, while we need to look at the parts as a whole, we also need to look at the individual parts (even if that phrase is less catchy). So, everyone contributes to a project, sure. That’s not under debate. But it helps to know in what specific ways each individual is contributing to making sure nothing is falling through the cracks. So, when we distinguish individual parts, we aren’t saying the parts aren’t related. No. They very much impact each other — but if we only think of it as one big blob of stuff, then we often can’t move forward effectively. Everyone on a sports team contributes to a team outcome (i.e. project = win the game), yet each individual role also has individual outcomes to achieve (e.g. goalie = stop the other team from scoring, striker = score points, etc.). They aren’t mutually exclusive.
So, one person has the project, “New Product Launched,” with five other people having subprojects — all contributing to that overall outcome. The goal is to have each outcome owned by one person. Meaning there is at least one person who is expected to look at the overall outcome as a whole. So, while anyone can contribute to the effort beyond their defined expectations (which we don’t want to limit), we don’t want that volunteer spirit to induce diffusion of responsibility. By having one clear owner we know at least someone is picking up anything that falls through the cracks, or addressing any process issues any single role might not notice. So, if you’re not sure what projects to capture, capture as many as needed. Which brings us to…
Public projects are different from private projects
GlassFrog® is critical for successful Holacracy practice, but as a software tool it isn’t designed to handle all of your possible project management needs* (just as it doesn’t handle calendars or video conferencing). The only projects you need to record in GlassFrog are those others have asked you to track. If you want to add projects beyond that the motivation should be, “I want to share updates with the group on this particular project.” Don’t do it because you think all your projects need to be on the project board.
*Note: As of Jan. 31st 2018, the only way to sort projects in GlassFrog are by person or by role. Neither allows a circle to cluster related projects together, which contributes to the confusion of how you’re supposed to organize projects in Holacracy. With that said, expect that functionality soon. Until then, use brackets like, “[Project X]” or “[Project Y]” in the project title to make related projects more recognizable.
In any role, you’ll be working towards a lot of different outcomes, but those should be tracked in your own personal “trusted list” (Section 1.2.4), which can be recorded anywhere (e.g. spreadsheet, notepad, napkin…). And if you want to use GlassFrog to keep track of outcomes you alone care about, then just put “[Private]” in the project name so the tactical meeting facilitator knows to skip it.
Now, a quick point on why people might use GlassFrog to track their own stuff (even when no one has asked them to). There is tremendous security in knowing people will hold you accountable — so it’s fine to stick a project on the board for that purpose. Just remember why you did it, so you don’t unintentionally bloat the tactical meeting’s project updates.
You should be comfortable adding and removing projects as you see fit because…
A project is always YOUR project
You aren’t assigned projects. You must make the decision on behalf of your roles. So, if someone asks your Recruiting role to take the project, “Three college graduates hired,” you have to ask yourself, “Does working toward that outcome make sense to me?” Maybe it doesn’t. Maybe you’ll only need to hire one person. Or maybe 5. Maybe you shouldn’t restrict it to only college graduates. But none of that should concern the person requesting the project. It’s not their job to figure out what makes the most sense to you. They’re just trying to solve their tension (which should be applauded). They just asked.
In the conventional management hierarchy, you are assigned work. But with Holacracy’s rules in place, you aren’t assigned projects. Technically, you don’t really even accept projects (that implies a kind of passive acquiescing to the requester). You simply add projects to your project board if they make sense to you.
Think of it like this. Your projects should be based on your tensions. And while someone else may feel a similar tension (and bring data to your awareness), your tension needs to be based on your understanding, needs, and vision. In this way, you don’t inherit someone else’s tension, you get infected by it. It’s like catching a cold from a friend. The illness is the same — but also different. Your cold can go away while your friend remains sick. Meaning, your tension is always your tension (even if others feel something similar). Read, Understanding Tensions for more on this point.
So, people may request things from your roles, but you shouldn’t ever accept a project just because someone else thinks it’s important (no matter how important that person may be).
Tracking is different from doing
Finally, we have tracking versus doing. On the surface, it’s deceptively obvious. Writing the words, “Do laundry” isn’t the same as the physical act of washing your clothes. But when others request projects at work, these two things often get confused. For example, have you ever declined a project because you don’t have time? Or because you have more important stuff to do?
Why? Just because you track a project doesn’t mean you’ll do it. Of course, it doesn’t mean you won’t either — it just means it’s one of the many things you have to choose from. But if you never wrote it down, how can it get prioritized relative to everything else?
And this is a big shift. Because in normal day-to-day life, you make to-do lists. They help you keep track of the important stuff. And figuring out; 1) what’s important, and 2) how to do it, is all pretty intuitive. Naturally it should be because you’re the only customer.
But since self-organization requires the individual roles to coordinate their project work amongst themselves, tracking projects is no longer a solo venture. And transparency is one of the concessions we must make to our coworkers because now we have duties to each other to make our lists shareable. The other concession is we aren’t the only ones who can prioritize our work. Since our roles exist within a defined circle, the Lead Link can also prioritize projects. Which means the normally solo and intuitive practice of simply writing down your own to-dos, gets differentiated into two separate questions:
- First: “In my interpretation, would working toward that outcome help me fulfill the purpose of this role?”
- Second: “Of all the purpose-fulfilling outcomes I’m tracking for my roles, which ones are the highest priority?”
Admittedly, these questions don’t exactly roll off the tongue, but they are worth asking individually and as-is because the usual suspects; “Do I want to do it?” “Do I have time to do it?” and “Is it important to do it?” don’t work when your project list has outside customers.
Closing
The rules of Holacracy don’t tell you how to manage projects, just as they don’t tell you how to hire, fire, or compensate people. The rules just give you a guaranteed way to figure those things out for yourself. But the rules alone are not enough. You also need to understand where the rules are coming from. The mental models and assumptions that inform them. Hopefully, this article made some of those more clear.
Read “Introducing the Holacracy Practitioner Guide” to find more articles.
