I just had the time to watch Larry Garfield's DrupalCon Amsterdam core conversation on managing complexity today. I did not have the chance to attend his session live due to other obligations, but it is nonetheless a topic I am very interested in.
The key point of the talk in my understanding is the Drupal community needs to decouple and be component based (evolving around more independent components), so responsibility and authority is distributed and local. Larry specifically calls out that Drupal 8 initiative leads and component maintainers are "glorified secretaries" with responsibility but no explicitly granted authority.
I am not a native speaker and although I had an idea, I wanted to clear up what authority would mean. According to Google the power or right to give orders, make decisions, and enforce obedience. (I'll use hard power as a synonym). Larry alludes to parts of this definition in the talk with examples. While the talk is well worth the hour to get insights form one of the Drupal 8 initiative leads on some of the struggles we had in the Drupal 8 cycle so far, I think there are fundamental issues with the premise. The biggest fallacy is the gross generalisation and picking one facet out of a very multi-faceted situation, so the proposed solutions don't stand deeper scrutiny.
Let's assume that leaving everything else as given, we grant authority (by the above definition) to some selected people in Drupal core. How would they be selected? Probably the same way leads are now, coming up the ranks, showing expertise and availability in a given technical area. It is hard to see that without giving in lots of those 1-hour 1-votes that Larry is concerned about, anyone would grow to be recognised as an authority. What would be other ways?
Let's assume they are there. Now what? Would everyone suddenly agree with their set direction and go and implement them? Why would they? If Dries says Alice and Bob should now have authority in X that does not change the incentives of contributors. Alice and Bob still need to spend all the time architecting solutions, communicating them clearly, rally people around their idea and then being available to gatekeep changes in their area, so to ensure they conform (see enforce obedience). What if contributors don't agree or Bob and Alice are not good communicators to get the word out? If Dries gave them authority, how does that give them the power to give orders? Where are the people waiting to implement Alice and Bob's great ideas? The only way the model proposed by Larry would work in this case is if the component in question is so small that Alice and Bob themselves can move it forward (or if they have or at least also control money to hire people to work on it, despite disagreements with contributors).
So the authority solution would solve Larry's concerns with those winning who have "time they don't know how to spend better" in two scenarios:
- If the components are (a) so decoupled (b) so small and (c) interface with each other so rarely that you can become an authority without needing to put in so much time ahead and then constantly, to exercise your authority
- Or if there is abundant money to pay both authorities for their time and then implementors to abide the authority even if they disagree
Both scenarios are interesting. I don't think the first will happen in several years (way into the middle of Drupal 9 earliest), and I doubt all three subpoints would apply. I really wish the funding situation will improve, there are so many people working on it, but I am not sure paying people to work on things they are not excited about / agree with is the spirit of open source anymore.
In short, hard power and a volunteer based open source community are not compatible on the long run. You either need to lose the volunteerism or gain soft power which authority does not help you with.
And initiatives in Drupal 8 were especially set up to be "soft power centers". Larry says initiative leads are merely "glorified secretaries" which I think is a very unfortunate misunderstanding from an initiative lead. The official definition of initiative leads says they coordinate work on the initiative and communicate the plans, progress, and needs of the initiative to the community and the branch maintainers. While this does not give them authority, as shown above giving authority in itself would not have helped.
Initiatives are the first try to set up bigger areas of work with appointed leaders. By highlighting these topics, end users know some of the major improvements to expect and contributors know where to contribute effectively. An initiative is a self organised unit with meetings, possibly its own website, issue tags, sprints, blog posts, sessions, etc. If a contributor cannot figure out how to get involved that is then a problem with the initiative.
So my understanding of initiative leadership was that I have responsibility to show the community there is a (1) shared goal, that (2) it is an achievable goal, and then (3) help people get there. There are a myriad of ways an initiative lead can do these, I did at least the following in the multilingual initiative:
- I set up a website to promote the goals and progress of the initiative and a twitter account to follow progress
- I held "Multilingual therapy" BoFs at DrupalCons to gather common problems from real scenarios to inform our decisions
- I worked with people experienced in user testing to help us develop a user testing script for key actions and coordinated several user tests; circled back results to improvements
- I distributed power in my initiative to three key areas relying on topic experts Erik Stielstra (Sutharsan), Francesco Placella (plach) and Jose Reyero (in alphabetical order)
- I made a point of not being attached to specific architectures so that I can scale myself (but it also turned out to be great to stay sane)
- I figured out a tagging system for the three areas and adopted one for the current focus issues (thanks Jacine Luisi for the idea)
- I built a custom visualisation tool to help communicate our goals / progress after trying mindmaps and other tools that failed
- I grabbed new people coming to sprints; the most famous example is Cathy Theys (YesCT) at DrupalCon Denver who is a fabulous team player and mentor
- I made an effort to try to make people on my team successful by finding reviewers, pairing people up, etc.
- I organised sprints to get the team together, Denver being the first "extended DrupalCon sprint" but only for multilingual; it grew into a generic extended sprint and transformed some events such as Drupal Dev Days
- I did my best to find funding for these sprints so at least we had a good venue and if possible people got fed
- I wrote a blog post series to communicate changes and point out missing pieces and lingering flaws at the same time, which helped drive some contribution.
- I made effort to find replacement for people when they left (for a while), including myself
- I held a fast paced talk of all the changes and the new multilingual structure in Drupal 8 at DrupalCons and Camps to inform people and recruit new contributors
- I developed a two hour lab with Aimee Degnan and Kristen Pol of Hook42 for DrupalCon Amsterdam which we "open sourced" (slides, handout, demo script, Drupal 8 distribution) to be presented around the world
- I wanted to acknowledge all issue contributors, not just patch contributors, so I created a page to credit all of them (above 1100 people) and bring them to life with photos from events
- I organize weekly IRC meetings (more inclusive for foreign language folks than video meetings) to discuss progress, find people to help each other with issues
- I developed a bad case of RSI two weeks before DrupalCon Amsterdam and was in pain; at the sprints therefore I focused on bringing food/coffee to discussions and clearing out tables of trash instead of typing, so I can help people not spill soda on their laptops
- I read a lot of literature on leadership and suggested my favourite find in practically all related conversations: Switch - how to make change when change is hard (protip: the whole book is about getting your way in things you don't have authority about, which is most things in life)
- I called core maintainer attention to important issues and helped explain decisions when needed (more on this below)
All of these one by one helped immensely to make great progress on the initiative. All of them required time to implement, some more significant than others. None of them would have come any easier if I was given authority. Not a single one of them. (Unless authority comes with a sizeable budget that I can direct so others do these). And all of these are well within the definition of the initiative lead published as coordinate work on the initiative and communicate the plans, progress, and needs of the initiative to the community and the branch maintainers. As for whether initiative leads like myself are glorified secretaries then I leave to the reader to decide.
But what about power then? Are initiative leads powerless people with way more responsibility then they should have? As a matter of fact leaders have unparalleled access to core committers. Leads had a 2 hour phone meeting with Dries every other week and Dries asked leads to attend separate issue review phone calls for high stakes issues. Core committers in general were eager to discuss pressing issues on IRC with leads. Longer sprint events made a point to have core committers sit in person on prescheduled meetings for several days with initiative leads discussing important topics (special thanks to xjm for organizing these!). That is a level of access that is far above what anybody else in the community could attain. (This in itself did not guarantee an initiative lead supported solution would get committed, and I had a major counter-example as well). So while saying an initiative lead has no formally documented power may be true, that it does not actually have power is way too far from the truth.
Several people said the multilingual initiative, that is my experience is a special flower and the same tools or processes would not apply to other topics in Drupal (or even Open Source in general). Let's return to my understanding of initiative leadership that one needs to show the community there is a (1) shared goal, that (2) it is an achievable goal, and then (3) help people get there. I don't think it can be said for any of the initiatives that a huge number of people would not share the goal (even if they disagree on some steps). In my view if a lead looks to defining that shared goal and help drive people there, then they can use all these tools effectively and get to good results regardless of whether they are (also) granted authority or not. Authority is not what gets you there, appreciating leadership to its fullest (not as being a secretary) does.