Drupal 8 is the first time we introduced the concept of formal initiatives and initiative leads. Over the course of these Drupal 8 initiatives we learned a lot and people are floating several ideas to increase the initiatives' success and provide Drupal initiative leads with more support. As we grow, it is crucial that we evolve our tools, our processes, and our organizational design based on these learnings. We've done so in the past and we'll continue to do so going forward.

But let's be honest, no matter how much support we provide, leading a Drupal initiative will unquestionably remain difficult and overwhelming. As a Drupal initiative lead, you are asked to push forward some of the most difficult and important parts of Drupal.

You will only succeed if you are able to build a strong team of volunteers that is willing to be led by you. You have to learn how to inspire and motivate by articulating a vision. You establish credibility by setting clear objectives and roadmaps in partnership with others. You have to motivate, guide and empower people to participate. You have to plan and over-communicate.

Not only do you have to worry about building and leading a team, you also have to make sure the rest of the community has shared goals and that everyone impacted has a shared understanding of why those decisions are being made. You use data, ideas and feedback from different sources to inform and convince people of your direction. Your "soft skills" are more important than your "hard skills". Regardless, you will lose many battles. You only "win" when you remain open to feedback and value change and collaboration. To lead a community, you need both a thick skin and a big heart.

Success is never a coincidence. You put in long hours to try and keep your initiative on track. You need relentless focus on doing whatever is necessary to succeed; to be the person who fills all the gaps and helps others to be successful. Instead of just doing the things you love doing most, you find yourself doing mundane tasks like updating spreadsheets or planning a code sprint to help others be successful. In fact, you might need to raise money for your code sprint. And if you succeed, you still don't have enough money to achieve what is possible and you feel the need to raise even more. You'll be brushing aside or knocking down obstacles in your path, and taking on jobs and responsibilities you have never experienced before.

Your objectives will constantly shift as Drupal itself iterates and evolves. You will want to go faster and you will struggle with the community processes. Imagine working on something for a month and then having to throw it out completely because you realize it doesn't pass. Frustration levels will be off the charts. Your overall goal of achieving the perfect implementation might never be achieved and that feeling haunts you for weeks or months. You will feel the need to vent publicly, and you probably will. At the worst moments, you'll think about stepping down. In better times, you realize that if most of your initiative succeeds it could take years of follow-up work. You will learn a lot about yourself; you learn that you are bad at many things and really good at other things.

Leading is incredibly hard and yet, it will be one of the best thing you ever did. You work with some of the finest, brightest, and most passionate people in the world. You will see tangible results of your hard work and you will impact and help hundreds of thousands of people for the next decade. There is no better feeling than when you inspire or when you help others succeed. Leading is hard, but many of you will look back at your time and say this was the most gratifying thing you ever did. You will be incredibly proud of yourself, and the community will be incredibly proud of you. You will become a better leader, and that will serve you for the rest of your life.

Comments

Dries:

That is an unfortunate summary, but a funny cartoon. :) We certainly have to discuss what "snowblowers" (support) we can provide to initiative leads. We provided some support but the more we can provide, the better. As I wrote, it is important that we evolve our tools, our processes, and our organizational design as we grow and learn.

catch (not verified):

I think the snowblowing cartoon is a useful analogy to be honest, both in terms of the 'character building' focus of this post, and the nature of the particular tools requested in other blog posts.

Shoveling snow is an almost endless daily task without any scope in some climates, in others it's something you might do every five years.

Whether additional support/infrastructure is needed comes down to the scope of the project. No point buying a snow blower if you only get 2cm of snow per year, it'll just be a waste of money and take up space in the shed, or if you get lots of snow and don't have your own stretch of sidewalk or a big front path, then the city's snow ploughs will be enough.

So to avoid people being stuck outside shoveling, figuring out requirements up front and publicly before initiatives (and their leads) are put into place might well have reduced some of the difficulty that both the initiative leads and those of us working on core outside of any official initiative ended up dealing with. This would also have helped to gauge interest and possibly led to more teams like VDC and less sole initiative owners earlier on. Boils down to keeping initiatives 'unofficial' until there's a project plan and some indication that multiple people want to work on it.

Nothing in core, even if it's tiny, is sustainable with only one contributor - you need at least two people to cover the peer review requirements of getting something in at all. The only thing that enforces interest of more than one person is the critical status, any other work happening is by definition optional. That makes a team of at least two people essential to maintain momentum, whereas a single lead/owner as such is a role that can (and has during 8.x) be optional or rotate depending on team size, scope, availability and interest. This wasn't factored into the initial model of the initiatives, where the first round all had a single lead. And the first initiatives were announced before the branch maintainer was, so there wasn't a core committer team either, just Dries at that point.

Back to snow, gritting the roads should also be done before the snow hits the ground enough to need blowing around. That means we need to make sure the transition from minor 8.x.x releases to opening the 9.x branch has well defined criteria. That's a much broader discussion than the role of initiatives/initiative leads.

For example, a major barrier to the early development of 8.x was the branch being opened prematurely. It felt about 6 months too early at the time, feels about a year too early in hindsight. This was both due to a massive amount of critical technical debt still to resolve in 7.x, and a lack of clear tasks for 8.x at the time.

The new release cycle helps with this, but there's still plenty to flesh out once we get into the monthly release stage.

If something is a finite task, sometimes it's more efficient (and fun) to grab the neighbours and shovel the street together (or at least co-ordinate who's going to do it when and figure out who might need extra help in advance), rather than have each neighbour blow the snow up and down the street into each other's bits of the sidewalk with their own machines.

Figuring out how to balance tasks which must be done in 9.0.x vs. things which could be deferred to 9.1.x (or should just be punted since there's no justification for doing it) is something we should be aiming to figure out before the branch is even opened - that only needs to happen when there's something significant ready to commit. A focused and significantly shorter 9.0.x development period with a 9.1.x release following six months later feels like it should get us out of the very long and taxing core development cycle which has been the pattern since 6.x-ish.

Gábor Hojtsy (not verified):

@catch wrote: Boils down to keeping initiatives 'unofficial' until there's a project plan and some indication that multiple people want to work on it.

I think this is a brilliant idea. I've been struggling with the thought before that we should encourage teams and yet its so hard to tell up front if a team will work / last. Also as @Dries points out below, "handing teams to leads" may not be smart, it may just come down as yet another forced-on thing. But having teams is crucial for sustainability and scalability.

So to soft-launch initiatives and then make them official once they work as a team sounds great. We need to make sure to have some criteria so it does not end up like another "I worked on this patch so much yet it was never committed" problem for soft-launched initiatives not becoming official.

benjy (not verified):

The best summary i've read of what it means to be an initiative lead.

You will only succeed if you are able to build a strong team of volunteers that is willing to be led by you. You have to learn how to inspire and motivate by articulating a vision.

This was exactly why I got involved in Migrate. After working with chx, it made me want to spend every weekend working on core.

Donna (kattekrab) (not verified):

catch wrote:

Shoveling snow is an almost endless daily task without any scope in some climates, in others it's something you might do every five years.

and in other climates... "what's snow? omg let's make snowmen"

:-)

I wonder also if the age old debate about the difference between management and leadership is relevant here. I feel it might be. Much of the task oriented work around getting stuff done may not feel like "leadership". Perhaps it's not. But managing is prioritising, assigning, delegating. It's important to have both these facets shine.

Should we be exploring a team approach to key initiatives that bring people with diverse skills and perspectives together to achieve a common goal, rather than appointing a single "lead" ?

Thank you Dries and Catch - great food for thought.

Dries:

As I wrote in the blog post, and as we learned during the Drupal 8 development cycle, the key to a successful initiative isn’t a good technical vision, but rather it is having a good team.

Keep in mind that nothing prevented initiative leads from building a team during the Drupal 8 development cycle.

If I were to be an initiative lead, I'd strongly prefer to recruit my own team rather than having a team handed to me. While I'm happy to help build teams, I do believe that it is the responsibility of the initiative to recruit, motivate, guide and empower its own team.

catch (not verified):

If I were to be an initiative lead, I'd strongly prefer to recruit my own team rather than having a team handed to me.

As I thought when the initiatives were announced, and still do, I think this has it backwards.

Who was the lead of VDC - was it Tim Plunkett? Daniel Wehner? xjm? Damian Lee? Earl Miles was announced as the 'chief architect' of VDC in https://dri.es/views-in-drupal-8 which is probably the closest position to a 'lead' but ended up not really working on VDC at all.

Who was the lead of entity/field API? Was it yched? swentel? fago? plach? berdir? Different people have taken on major parts of that work at different times.

Twig similarly never had a single official lead, although various people have taken on leadership roles for different aspects of that.

The idea of a single person 'recruiting' people (with no budget...) just doesn't fit with my experience of working on Drupal core. In Drupal 7 and previously, people worked on various informal 'initiatives' without the formal structure but were still self-organised into some kind of team via things like irc channels, issue tags etc. If you look at the names listed above, while those people were central figures in those initiatives, they've also moved around different parts of core over the release cycle.

If official initiatives are going to mean anything, it has to add something uniquely helpful to what is already there, and the 'single lead' structure detracted rather than helped in most cases.