Passing the Baton
Succession planning for FOSS
leadership
PyCon AU 2017@vmbrasseur@vmbrasseur, CC BY-SA

START YOUR TIMER

1

VM (Vicky) Brasseur@vmbrasseur
vmbrasseur
pyconau@vmbrasseur.com@vmbrasseur, CC BY-SA

Freelance open source business strategy
consultant
Author & community moderator for
opensource.com
Here's my contact information2

Slides:
https://archive.org/details/
pyconau2017-successionplanning@vmbrasseur, CC BY-SA

3

YMMV

@vmbrasseur, CC BY-SA
4

Succession planning can be a complicated thing at times.
I will be presenting general tips for how to approach thisprocess.
Not all of the recommendations will necessarily apply toyour specific situation.
Some of the recommendations may apply better to large
projects, others to small projects. It all depends on the
project's requirements.
Take from the presentation what you need. Don't feel
obligated to follow every suggestion to the letter.

Please save questions forthe end@vmbrasseur, CC BY-SA
5

Brief history of FOSS

@vmbrasseur, CC BY-SA
6

Let's set some context.
^ We've been sharing software for as long as there's
BEEN software^ But free/open software as a recognizable
movement only started 40 years ago.
^ Let's quickly look at some of the many highlightsof our history.

1970s & 1980s— 1976: emacs— 1983: GNU— 1984: X— 1985: FSF— 1987: Perl@vmbrasseur, CC BY-SA

7

emacs: Moon & Steele > RMS > GNU > FSF
Perl: Created by Larry Wall
Note: Perl is 30 years old this year!
Congratulations!

1990s— 1991: Linux, Python— 1993: NetBSD, FreeBSD— 1995: PHP, GIMP, Ruby
— 1996: Apache, KDE— 1997: GNOME— 1998: "open source" coined, OSI formed— 1999: OpenOffice, Apache Software Foundation@vmbrasseur, CC BY-SA

8

Things started getting really exciting in the
1990s.
1998, "open source" becomes a thing

2000s— 2003: Mozilla, Wikimedia— 2004: Ubuntu— 2005: git— 2006: Software Freedom Conservancy— 2007: OpenJDK— 2008: Chromium, Android— oh so many more things@vmbrasseur, CC BY-SA

9

A new century brought an explosion of free andopen source software and organisations.
Things have really escalated in the past 10 years.
FOSS components have become the default
selection for many companies

We've come of age@vmbrasseur, CC BY-SA
10Mark Cuban: "Software has eaten the world."
Every tech journalist ever: "…and open source has
eaten software."
There's no denying that the free and open source
software movements have changed the face oftechnology & are here to stay.
…and we're starting to reach the scale and age
where oral history doesn't cut it anymore.
40 years. 40. And we still have the founders of our
movement in our midst. But for how long?

There are now millions of free
and open source projects
currently in existence…

@vmbrasseur, CC BY-SA
11

According to the 2016 Octoverse, there are over 19.4
million publicly available repos on Github ALONE

…we rely on them every day…

@vmbrasseur, CC BY-SA
12

Many of us could not do our jobs without these projects. We
couldn't run our companies. We couldn't serve our customers.

…so what happens when theirleaders need to move on?

@vmbrasseur, CC BY-SA
13

But now, 40 years on, we're overdue to be thinking about how wein FOSS will get by when our founders, our leaders, move on.
These aren't necessarily the bit RMSs and Benevolent Dictators
For Life of the world.
Every project has people in important roles. Every project needs toconsider a backup plan for when those people leave the projectfor some reason.

Succession
Planning@vmbrasseur, CC BY-SA

And that brings us to succession planning.
I've done a lot of research into this in a FOSS context,
including surveying and interviewing leaders andcommunity members of open source projects andcommunities.
First I'd like to define Succession Planning for y'all so
we're all on the same page.
XXX 7E50 mark here14

Defined"Succession planning is a process for identifying anddeveloping new leaders who can replace old leaders when
they leave, retire or die." Wikipedia@vmbrasseur, CC BY-SA

15

This is pretty standard for what you find in the literature
about this subject.
I'm not a big fan of this definition. It's rather limiting. It implies
only "leaders" are the ones who need backup & successors.
What is a "leader" for FOSS, anyway? When you stop to
think about it, it gets complicated pretty quickly.

Leadership Skills Pipeline
Training and mentoring people in the skills required tostep into important roles.

@vmbrasseur, CC BY-SA

16

Literature focuses on high level leadership things like CEO,Founder, etc.
This is FOSS. There are other important roles beyond project
founder, Benevolent Dictator for Life.
Any project role which is measured by bus factor is a role
which can benefit from succession planning.
Important to note here that these are Skills, and as Skills they
can be learned.
"A projectʼs bus factor is a number equal to the number ofteam members who, if run over by a bus, would put the
project in jeopardy."

Why does it matter?

@vmbrasseur, CC BY-SA
17

When I talk about this, some people say, "Meh, we've neverdone this in the past. Why should we think about it now?"
Well, for starters, "we've always done it this way" is a very
dangerous statement. But there are some other reasons
why you should think about succession planning…
XXX 10E25 markContinuity@vmbrasseur, CC BY-SA

18

The most obvious reason. When someone leaves, what
happens to the tasks they were performing?
They were keeping some plates spinning. When theyleave, do those plates fall and break?
Succession planning helps ensure tasks continue to be
performed and no one is left hanging.

Avoid a power vacuum@vmbrasseur, CC BY-SA

19

If a person leaves a role without a replacement, it can lead to a
lot of confusion, delays, and possible political woes for the
project.
Those political woes can be the most damaging to a group.
Delays are more easily fixable than hurt feelings.
Creating a succession plan can help alleviate the very insecureand unstable time when someone in a vital role moves on.
Everyone knows who's next in line and why.

Project/organisation longevity@vmbrasseur, CC BY-SA20

The thinking required for succession planning is the sort of
thinking which contributes to project longevity.
The entire point of succession planning is that the group is taking
the long view.
Ensuring continuity in leadership, culture, productivity also helps
to ensure that the project will continue. It will evolve, but it willsurvive.

Reduce load/pressure on current leaders@vmbrasseur, CC BY-SA

21

Successor becomes backup^ Leaders are more free to take vacations, etc.
^ Reduces burnout of project leaders & thosein important roles

Talent development@vmbrasseur, CC BY-SA

22

We talk a lot about mentoring people to contribute code, but wealso can mentor people to become successors for critical roles
This helps everyone: leaders get successors, project/organisation
gets continuity, successors get career development and experience.

Inspiration/motivation for new members@vmbrasseur, CC BY-SA

23

It can be very motivational for new community members
to see a succession plan in action.
"There is a path to and plan for leadership positions here.
That could be me some day. I would like to stick around."Also instills confidence that the project has its shit
together.

Diversity of thoughts/Get out of a rut@vmbrasseur, CC BY-SA

24

Succession plans are a great opportunity to bring new
people, new ideas into the leadership roles of a project.
Studies show that diverse leadership teams are more
effective and the projects they lead are more innovative.
Use your succession planning as an opportunity to open
the door to diversity.

Truly meritocratic@vmbrasseur, CC BY-SA

25

Disclosure: I have a problem with this whole "meritocracy" bullshit.
Many projects in FOSS are proud of their "meritocracy." Conceptually, it'sa good idea.
^ Unfortunately what passes for meritocracy typically translates tohostility toward new contributors and echo chambers.
If you can't express what "merit" is beyond "I'll know it when I see it" thenyou have not thought things through very well.
A meritocracy without a mentoring program and healthy goverance
structure is just an excuse to practice subjective discrimination. It's a way
for bullies to hide behind unexpressed biases.
IMO, you cannot claim to value "merit" if you do not take the time to train
people to earn that merit or even teach them what it is that earns themthat merit.
A well-executed succession plan can help with this.
A well-executed succession plan is open, honest, documented. There areSummary of Benefits of Succession Planning— Continuity— Avoid a power vacuum— Project/organisation longevity— Reduce pressure/load on current leaders— Talent development— Inspiration/motivation for new members— Diversity of thoughts/Get out of a rut— Truly meritocratic@vmbrasseur, CC BY-SA26

As you can see, there are a lot of really great things
which can come from having a succession plan.
It's not a panacea. There will still be problems. But
there are a lot of really worthwhile benefits here.
Despite that, very few FOSS projects ororganisations put much thought into it.
Why?
XXX Around 17H00 markWhy it doesn't happen@vmbrasseur, CC BY-SA
27

From my research, I've found the following reasons for why
projects don't engage in succession planning:Too busy@vmbrasseur, CC BY-SA

28

A lot of people recognized succession planning as a problem in theirproject but just "hadn't gotten around to it" because there's "always
something more important to work on."While I can understand this, I really can, I personally think this is more aproblem with prioritization than with time availability.
It's likely these people may not yet realise how bad it can be not to have a
succession plan when you need one. And that's why I'm talking to you
today.

Don't think of it@vmbrasseur, CC BY-SA

29

Some are just so busy & preoccupied that they haven't even thought about, "Hey, what
would happen if Sarah left the project?" It just never occurs to them. I mean, Sarah's
always there when we need her, right? Always.

Don't want to think of it@vmbrasseur, CC BY-SA

30

Succession planning is often, like estate planning, associated with negative feelings likeloss and can make people address their own mortality. Some people aren't comfortablewith this and avoid it.

Attitude of current leaders@vmbrasseur, CC BY-SA

31

Current leaders don't want to recognize that they're replaceable
or to consider that they might give up their power and influence.
Failure to recognise or admit this can set the project up for
failure in the long run.
This doesn't happen often but it does happen and is worth
mentioning.

Don't know where to start@vmbrasseur, CC BY-SA

32

Some know it should happen,
are willing to carve out the time,
but don't know how to do it.

How to develop FOSS
leaders of the future@vmbrasseur, CC BY-SA
33

OK, so how do you do this? How do youeven get started?
XXX 19942 mark

DON'T PANIC@vmbrasseur, CC BY-SA
34

I'm about to throw a lot at you.
DO NOT feel you have to do it all or do it immediately.
This is a process. Again, the thing about succession
planning is you're taking the long view. That means it
can & should take time.
So don't worry if you don't feel you're making progress.
If you're working on it at all, you ARE making progress.
Congratulations.
Also, I'll give suggestions not just for current leaders, butalso for those who would like to move into critical roles.

Current leaders@vmbrasseur, CC BY-SA
35

So, if you're currently in a critical role in a project, what can you doto help cultivate people to take your position when you move on?

Don't work in isolation; work on this together &publicly@vmbrasseur, CC BY-SA
36

Before you start, remember that you're in an open
community and do all of your work in the open
Solicit feedback from the community and keepthem posted on what's happening and why
XXX Around 21?30

Identify critical roles@vmbrasseur, CC BY-SA
37

Step one is to identify those roles in your project which
are fairly critical.
Only you & your project can define what qualifies as"critical" to you.

Role != Person@vmbrasseur, CC BY-SA

38

Note: While it helps to start by looking at the people on the team, it's
not always to correct that each person is performing only one role

Identify role duties & responsibilities@vmbrasseur, CC BY-SA
39

Now, once you've identified those roles, be very honestwith yourself and your community about the duties ofeach role.
List what you think the role should do
but also list those duties it ACTUALLY performs. The
second list will probably be longer.
Be honest about the duties a person is performing andhow they might belong to multiple roles

Refactor large roles@vmbrasseur, CC BY-SA
40

If a role does a LOT, then you should break it up into
multiple smaller roles
Refactor: redistribute roles amongst other people ->Reduce bus factor right there
Refactoring also makes it much less intimidating forsomeone new to take on the role. The new role will besmaller and easier to step into.
XXX 24D00

Consider limiting tenure for a role@vmbrasseur, CC BY-SA
41

Ensure that it will be handed off
Give current role-holder a light at the end of thetunnelEnsure there will be a body of people familiar
with the role (past role holders)Knowledge transfer@vmbrasseur, CC BY-SA
42

Once you've identified & refactored the roles, a lot of thework consists of knowledge transfer
While this should be an on-going process, but you'll
probabsly need a big initial brain dump
once you've collected the initial information it should justbe a matter of sharing it and maintaining incremental
updates.
So what knowledge should you be sharing?

Procedures & processes@vmbrasseur, CC BY-SA

43

All those duties don't occur in a vacuum. How
does one perform them?
Some may be self-evident. Others may not.
But remember: you have a different perspective.
Self-evident to you isn't to others.
So please be explicit and transfer all knowledge
about all procedures & processes.

Resources@vmbrasseur, CC BY-SA

44

List of accounts: What accounts exist out there? Travis?
Twitter?
List of contacts: Do you have meetups? Who are the people
who usually help you with meeting space, sponsorship?

Credentials@vmbrasseur, CC BY-SA

45

No one person should ever have access tocredentials for services used by the project.
This is one of the most common issues faced byprojects when faced with a succession situation
People walk away with the keys and no one else
has copies
I've also seen this power used for evil (shutting folks
out, embezzling, etc)
Always use role email accounts sent to multiple
people, not individual/personal accounts.

Project history@vmbrasseur, CC BY-SA

46

Provides the context necessary to make the best decisions
in the operation of duties.

DOCUMENTALL
THESE
THINGS@vmbrasseur, CC BY-SA

47

Now, you've determined & discussed all these things.
I mean, this has probably taken a LOT of a lot of peoples'
time, amiright?
FOR PETE'S SAKE, WRITE THEM DOWN. Don't lose thisinformation.
The How & Where doesn't matter nearly as much as the
Whether.
Capture this information for posterity. This is a talk on
succession planning. For crying out loud, think of future
generations of project leaders and write this stuff down now.

But consider tl;dr docs

@vmbrasseur, CC BY-SA

48

Can be helpful to provide an overview doc(more bite-sized)
A'la an abstract for a research paper

New leaders@vmbrasseur, CC BY-SA
49

So don't think this only has to be the purview of
those already in critical roles.
Those of you who are interested in contributing
at a higher level can do a lot to help this process.
XXX At 32?11

Look for opportunities to learn & contribute@vmbrasseur, CC BY-SA

50

For starters, look around. Where can you help those incritical roles?
Are there opportunities for you to learn more about theleadership and operation of the project?
Ask to chip in. Volunteer for the small, possibly
annoying, but definitely important tasks.
Volunteering for the grunt work is a great way toapprentice your way into a leadership position.

Shadow those in critical roles@vmbrasseur, CC BY-SA

51

Another way to learn and apprentice your way into
one of these critical roles is to ask whether you mightshadow one of these role-holders.
See how the role is performed. What is the process &procedure?
See what's actually involved with the role.
Confirm whether you actually want to perform the role.

Ask for mentorship@vmbrasseur, CC BY-SA

52

We who mentor…we're human & we're busy. We
don't always have the mental cycles to recognisethat mentoring it needed or wanted.
We're usually happy to provide it, but sometimes
we need a nudge. Please ask!
Related to that, when you see someone performing
critical duties, ask whether they'd be willing/able toteach you about it.
Ask for feedback on tasks you perform.
Ask for tasks you might perform to assist them.

Learn the history of the project/organisation@vmbrasseur, CC BY-SA

53

Sit around the campfire with the project elders & listen tothem spin yarns of the Good Old Days
Extra points: write what you learn and share it for the
benefit of your entire community

Examples of projects
working on this@vmbrasseur, CC BY-SA
54

Was going to give examples of projects doing thisbadly but won't for 2 reasons:
1. I don't believe in naming-shaming for stuff likethis.
^ 2. My research shows I don't need to give
examples of projects handling this badly because
everyone already knows some.
Instead, I'll give you examples of projects doing thiswell.
Please note: This is not an exhaustive list.

Exercism
https://exercism.io"The goal, of course, is to have at least three active
maintainers for every single language track. This way we
could put some procedures into place to mentor new
contributors, nominate new maintainers, and to roll off the
project without any sort of guilt when you no longer wantto maintain a project."Complete exercises to gain fluency inprogramming languages
Over 60 language tracks, 35 active on the site
Rated their tracks by how maintained they were.
Making very active efforts to make sure eachtrack has not one, but multiple maintainers
Succession planning in action: always someone
available to step in when one of the maintainers
isn't available.
Gives maintainers breathing room & a chance totake a break when they need it.
@vmbrasseur, CC BY-SA

55

Vox Pupuli
https://voxpupuli.org"One of the benefits we hope to achieve is that by a sharedownership of modules we no longer end up in situations
where the original maintainer has moved on and a forestof disparate forks try to fill the void."@vmbrasseur, CC BY-SA

Ensure continued development ofPuppet modules
123 repositories of Puppet modules
XXX At 38954

56

Image Credits— Title slide: joohander on Flickr, CC BY-NC.
— Twitter icon: Andrey Vasiliev from the Noun Project— IRC icon: Gregor Črešnar from the Noun Project— Email icon: Mackey Guenther from the Noun Project@vmbrasseur, CC BY-SA

57

Slides:
https://archive.org/details/pyconau2017successionplanning@vmbrasseur, CC BY-SA

Reminder: Slides available now. Screencast
available soon.
Now, any questions but not comments
disguised as questions?
XXX Q&A at 41B45

58