focus for this week: Why don't birds fly backwards ?
>1.1 mio views (popular pages, total: 2,030)
Open Advice/Big Plans Do not Work
Big Plans Don’t Work
- by Jos Poortvliet
- in: Open Advice
This text is available under the CC-BY-SA license. (see also: Open Advice/Info)
Contents |
- “It is better to take many small steps in the right direction than to make a great leap forward only to stumble backward.” – Old Chinese proverb
A great idea...
Once upon a time in the marketing team of a Free Software project, someone came up with a great idea to grow the project. A program would be set up to get IT students to learn about the project and join in. Universities would be contacted and someone would talk to them to get them interested. Ambassadors would then go to those universities and give a course there, coaching students in their first step into the world of Free Software. Once they joined online, they would be mentored on simple tasks and finally become full-fledged contributors! Of course, universities would love the program, and with some luck start to participate more actively, giving their students assignments which result in code being written for the project, and much more.
...which didn’t work...
I have seen the idea from the fictitious story above in many forms in many different communities and projects. It is a great idea and could be very powerful! We all know you have to start early – our proprietary competition is pretty darn good at this. We also know we have arguments enough to convince universities and students to participate – FOSS is the future, it provides great skill development opportunities, skills in Linux programming or administration are in higher demand than another Java or .NET developer or Windows sysadmin and most importantly: it is more fun. Somehow, however, if you go to universities, you do not see many posters inviting you to join Free Software projects. Most professors have never heard of it. What went wrong? Let me continue the story.
...not because lack of effort...
The team had a long discussion about it. First brainstorm style – many ideas on how to realize the idea came in. The team leader collected the work and put it on the wiki. A plan was made with a time line and the team leader appointed people responsible for certain parts. Some started writing course materials, others looked up university contact information and put it in a list. They asked frequently for input and ideas on the mailing list and got plenty of responses for further course material, which the leader added to the list of things to write. It all had to be done in the free time of the volunteers, but you could always count on the leader to remind volunteers of the schedule.
After a few months a structure was visible and many pages in the wiki were created. Meanwhile, however, the number of people involved decreased from the initial discussion with over 30 to about 5 still soldiering on. The leader decided to revise the road map with proposed deadlines and after a few calls on the mailing list 10 new volunteers committed to a variety of tasks. The pace picked up a bit again. Quite a bit of what had been done before had to be updated and there were other adjustments needed. Unfortunately, things kept slipping and the number of people doing things kept decreasing. Monthly sprints were introduced which did indeed result in some more work being finished. But there was simply too much to do. After about a year, the last people gave up. A stale wiki page and some outdated materials are all that is left...
...but because it was too ambitious.
So why did it not work? They team did everything according to the best project management practices you will find on the web... brainstorming, then creating a plan, time lines, clear goals and responsibilities... They did the right volunteer things: ask people, engage them, give everyone an opportunity to voice his/her opinion. It should have worked!
It did not, because of a simple reason: it was too ambitious. It is a trend. Amazing ideas receive lots of comments, get written down in great plans which result in incomplete wiki pages leading to too little implementation finally fading into nothingness.
Leaders have to recognize that how a team works in FOSS is not the same as in a structured, managed environment like a company. People tend to be around when there is something exciting, like a big release, and then disappear until the next exciting thing. Creating a community team should never assume that the people will stay fully committed the entire length of time. You have to factor in that they will be in for a while and then disappear for longer periods and then come back. The leaving and joining creates a lot of overhead so that little gets done. Yes, we can lead people, but we cannot manage people, and once you learn to give up the management aspect, you can focus more on things you need to do in the immediate short term.
So instead of planning big things, find something small, doable and useful in itself. Not a wiki page with a plan, but the first step of what you aim for. And then, lead by doing. Make a rough first draft of an article. Make a first version of a folder. Copy-paste from whatever exists, or improve something which was already available. Then present the result, drafty as it is, to the team and ask if someone wants to make it better. Do something small and it will work.
Don’t plan, just do...
So how do you do something as big as the university student plan? You don’t! At least, not directly. Discussing this with the whole team, planning – it will surely make for a fun discussion which can last weeks. But it will not get you far. Instead, keep the plan to yourself. Seriously.
I am not saying that you should not talk about it – you can. Share the ambition with whoever is interested. And it is OK if they give suggestions. But do not rely on it, do not make plans which go much further than the first 1-2 steps. Instead, execute. Build on what is there. Send a draft of a new or improved flyer to the mailing list. Ask someone who gave a course on your project to share the material and improve it a bit. Those whose work you build on might help you out! The people you spoke with about the plan who share your vision might help you too. This way, you will frequently finish something – a flyer, an improved website, a presentation to be used. And people can, slowly, start using it. Ambassadors can go to their local universities, using a few of the things you have already created. To do what they do, they surely have to create some missing materials – which can go on the wiki as well. And you make progress.
...and get your pie in the sky!
In community marketing, strategy is not on the wiki. It is not in a plan nor a time line. Neither is it discussed every week with the whole team. It is part of a vision which has grown over time. It is carried by a few central people and inspires the short-term plans and objectives. And it is shared by the team. But it has no time line and it can not fail. It is flexible and does not depend on anything or anyone in particular. And it will always be a pie in the sky...
So if you want to lead in a Free Software community marketing effort, keep that big picture a big picture. Do not plan too much, but get things done!
about the author
Jos Poortvliet works as openSUSE community manager for SUSE Linux. Before that he was active in the international KDE community as team lead for the marketing team. In his “offline life” he has had jobs at a variety of companies as Business Consultant. His favorite pastime is experimenting in the kitchen, trying to come up with something edible.
