Last week we had our first two Governance meetings. These meetings are about how the team is acting as a whole and what can be improved to make things run smoother. Day-to-day work related stuff seem to have no place in these meetings, other than maybe on a meta level. We had a good taste of how these meetings go in Holacracy.
So far I think we are quite happy with the results as the structure leaves no place for people to keep their mouths shut. The basic structure of these meetings consists of a round of questions to fill the agenda to start with (nice and agile, no prepared agenda :)). These points are “tensions” team members feel that should be made into fuel for productivity during these meetings.
Then all these tensions are one by one brought before the team by the facilitator (see the roles descriptions below). Everybody is allowed to come up with a solution for the tension. As soon as someone comes up with a solution, the rest of the team is asked whether they have any objections. Just like with brainstorming sessions in other areas of management, these ideas are not easily put aside. An objection has to be serious (in our case probably: you’d break stuff). If no real objections are brought up, the idea passes and we go on to the next tension. We found that it was easy to keep a relatively fast pace in decision making, even while we are still Holacracy noobs.
The main objective for the first meeting was to get all of our responsibilities and daily tasks listed so we could group them into different roles. Every member of the team was then assigned a bunch of these in the second meeting, ranging from three to maybe even ten different roles. I was curious about this part, because as developers we share a whole lot of responsibilities that are the same for everyone in the team: coding features, fixing bugs, checking other people’s code, etc. are part of all our daily jobs. Holacracy, however, is all about separate responsibilities and making each individual responsible for different things.##The Roles
The idea behind individual responsibilities is clear: having one person responsible for something makes it far more likely that that person will follow through. Because everybody knows it is this person’s responsibilty, his/her ass is on the line. Nobody else will do it because it is simply not their job. If you make more than one team member responsible for a single job you might end up with the bystander effect: a group of people knowing they should take action, but all waiting for another to do it. Anyway, having just one person with the developer role would not do for us, so these are the roles we came up with and what a development team Holacracy style might look like.
- A/B-tester – Responsible for all the A/B-tests that we conduct on the site.
- Bug Hunter – Tracks bugs down and does some digging as to what the problem might be before creating a ticket.
- Data Importer – Responsible for third-party data and consistency
- Developer – There it is :)
- Developer Evangelist – Writes blog posts, promotes OSS development and represents us at meetups etc.
- Developer HR – Recruiting, hiring, and other personel related stuff. DevOp – Servers and infrastructure.
- Exception Duty – Traces our monitoring tools for problems on a daily basis.
- External Suppliers – Contracts and other third party related stuff.
- Frontender – JS, CSS, HTML, Mobile support etc.
- Gatekeeper – Answers non dev colleagues who have questions for developers.
- Inventor – Designs features: MVP’s, UX, etc. Planner – Roadmaps, velocity, shipping on time.
- Researcher – Diggs into new technology.
And the default Holacracy roles that every circle has
- Lead link – Represents the team in the management circle (we call it Alignment Circle).
- Rep link – Backs up the link to management in cases where the team feels misrepresented by the Lead link.
- Facilitator – Facilitates meetings.
- Secretary – Meeting reports.
The lead link is a member of the management circle. The rest of the four Holacracy roles are determined by voting (very democratic) and a round of objections (democracy++), then a re-vote if any real objections are brought up (democracy++++). Fun fact: it took us 6 voting rounds to get the four roles occupied.
We did not manage to achieve total individual liability here, although most of these roles are assigned to one person, Holacracy style. But there are a few exceptions: we all have the Developer role, the Gatekeeper role is filled by both our Product Managers, and the Developer Evangelist role is shared between me and one of our PM’s, Vincent. I guess we should just split the last role into more specific tasks to be able to assign two roles to two individuals, and the Gatekeeper role could be divided into end-user related questions and platform/technical related questions to be able to assign them to two different people. If we would run into trouble with people not taking their responsibilities, we could sort that out easily in our next Governance meeting. However, Holacracy does not seem to have the answer to our Developer-role “liability problem”. I don’t think that will be a real problem though.
Liability in development has always been encapsulated in our development process. Once you pick up a ticket from the Kanban board, it is your responsibilty to get it done. In a way, the ticket defines your temporary individual role I guess. You write tests, code and create a pull requests for team members to review what you have done. Anything that looks less than optimal is addressed by a peer, and you have to fix it before the code is shipped. Complexer stuff might be pushed to a staging server to be reviewed by the Product Owners. This is very clear protocol. Everybody knows what to do, and when and where to address issues in the process.
All in all these Governance meetings have been very insightful into our responsibilities as a team. As we grow into the habbit of having these meetings, the roles will be trimmed, fattened, reassigned, removed and recreated. Right now, I am looking forward to the next meeting, which will be a Tactical meeting and all about addressing issues and assigning next actions. As I gathered from Diederick, the next actions will be assigned to roles. With our current roles assignment, that could work or we might have to fall back to our trusted development process and treat tickets as temporary roles, maybe?
Want to work at the biggest learning source in the world?