Hello, I'm Nicholas. Most of you know me as the author of popular components like Akeeba Backup and Admin Tools. Some of you know me as a frequent code contributor to Joomla!. I'm very outspoken to the point that people think I'm an asshole. Most likely I am. I was working as a business consultant long before I turned to full time software development and, as you know, business consultants are always seen as assholes, usually ranking lower in being well-liked than accounting and legal departments. But you know what else business consultants do besides being assholes? They know how to make an organisation do more with the same people (or even less, which is why people think we are assholes). So there you have it, I was refactoring businesses before I got to refactoring code. This is my take on refactoring Joomla!'s organisation structure. It's a long read, ideal for a Sunday morning.

Crash course on business consultancy

Before getting into specifics, we first need to have a generic idea of how work is done in an ideal organisation. It's four words: Planning, Execution, Reporting, Reflection. They are not just four words, they are a positive feedback loop: Planning leads to Execution leads to Reporting leads to Reflection leads to Planning and all over again. Planning: people have to know what to do. Execution: people do what they do and produce some output (product of their work) and a log. Reporting: the individual logs are summed up in KPIs (Key Performance Indicators) which can give people up the ladder what's going on. Reflection: compare the reports to the plan, integrate feedback from your clients and reflect on whether things work. OK, spoiler alert, nothing ever goes according to plan. This calls for a plan revision and the loop closes. Take away number one: there is a better way for organisations to work.

As I said, this is how an ideal organisation work. You know, one where everybody understands the gravitas of their position and performs their best. Such an organisation has never existed or, if it has, it must have been ran by saints. My job was to go into dysfunctional organisations, observe how they work and introduce changes. Nobody likes changes. The people who bring changes are assholes because "that's how we do things here". Ergo, being the consultant who brought in changes, I was a de facto asshole until proven otherwise. This why a thing called "change management" is awfully important. It's how you help people understand why their organisation is dysfunctional, help them to realise that their daily grind has very specific root causes and aid them in refactoring their organisation to be functional. When these people feel they are part of the wind of change they will change. If you try to sell them into a change they don't understand and fully believe in you'll end up with a more dysfunctional organisation. Take away number two: you need change management.

So, is the Joomla! organisation dysfunctional?

Let's start from this. Is Joomla! organisation dysfunctional? We can answer that by taking a look at its business process. There is currently no real planning. No, having a mission statement as broad as the Pacific Ocean doesn't count as planning any more than "I see a big door opening sometime in your future" is a valid and specific prediction of your future by a fortune teller. Having a release schedule which was overly optimistic and already blown away is also not adequate planning. A good planning would be taking into account what is needed, why it is needed and what resources we have available. You may want to build a rocket to go the moon, but if nobody wants it, nobody knows how to do it and you don't have the faintest clue what you're going to do up there your planning sucks. Unfortunately, Joomla! is in this "sucks big time" category with regards to planning, not due to lack of effort. Planning requires both leadership and information and Joomla! is shorthanded on the former and completely in the dark on the latter.

The execution is always a problem area in a volunteer organisation. In a traditional business setting you have the carrot of the pay check at the end of the month and the stick of the pink slip. But when you work with volunteers you only have a carrot: people enjoying what they do. This is a problem area for Joomla! because people might really, honestly, full-heartedly enjoy what they're doing be it writing code, translating, answering questions on the forum, documenting, marketing and so on and so forth but it all comes crashing down in flames when they don't get any gratification. It's not because of ill will. There's plenty of good will. The problem is that people don't know who to contact to get something done, they have to undergo double guessing for everything they do and to cut a long story short there's too much bureaucracy involved which strangles all enjoyment out of the creative process.

Let's go to reporting. My, oh my... Reporting presumes that there's at least a log of who's doing what, what challenges they are facing and what their prediction is for the completion of any given work item (keeping in mind the volatile nature of volunteer availability). In Joomla! nobody knows who is working on what, or even if they are still working on it. I'm not saying that there are any perverted cookie lickers among us. I'm just saying that people tend to pick up something that sounds fun to them but then life kicks in, they are out of time and nobody is none the wiser. There's no way to track this information down (no reporting), hence a communication break down which leads to organisational dysfunction.

Finally, let's tackle reflection. By this point you'll have probably figured out that since the former three steps of the process are in dire disrepair the "reflection" part is a short joke. You would be wrong. There's a lot of reflection. It happens in every other JoomlaDay. It happens in J and Beyond and JWC. It happens on Working Group meetings, forums, mailing lists, Twitter, Facebook, even blog posts. However! Our reflection sucks big time because it's based on intuition rather than evidence. I plea guilty to having done the same. Our problem is that we don't actually know what is being done in our gigantic organisation and we have no idea what our customers think of us. We are trying to flight a plane in the dark, blindfolded, with our hands behind our backs, high on the drug of "we power 4% of the Internet".

Why is the Joomla! organisation so dysfunctional?

When Joomla! forked off Mambo nearly a decade ago it was a small project, kept together by a motley crew of a handful of core developers and some crazy volunteers. The number of personal interconnections was small enough to sustain a functional organisation without much structure. The project exploded in popularity and layers upon layers of organisational structure were added haphazardly to cope with it. With them a great deal of bureaucratic complexity arose which eroded the ability of volunteers to, well, volunteer. The project grew from a humble shed to the Tower of Babel. Suddenly nobody speaks the same language and we're all frustrated that the other guy or gal seems to be oblivious to our subjective truth.

While we're at it, let's talk about structure. When the project was founded OpenSourceMatters Incorporated (henceforth shortened as OSM) was conceived as the bare legal minimum to have a copyright and trademark holder. The actual project was supposed to be managed by a leadership team. Both OSM and the leadership were supposed to be overseen by a third team, with members coming directly from the community. That was a great plan. It would have worked great if a. OSM did remain the bare legal minimum as originally conceived b. a small leadership team was miraculously capable of coping with everything and c. the community oversight members were barred from being elected in the OSM board or the leadership. Sadly, all three conditions are false. OSM got more power, losing trust in the community. The leadership team splintered into ever so many more teams, to the point that we don't know exactly how many there are (in theory I am probably leading the Joomla! Rapid Application Development Working Group which may or may not have officially existed and may or may not have been disbanded – I don't even know myself). Finally, members of the community oversight were then elected to the leadership team and then in the OSM board or vice versa. Does it sound right that the audited was an auditor or vice versa? Caesar's wife must be above suspicion after all.

There is currently a proposal on the table to restructure Joomla!. It's pitched as more democratic, more accountable and more of just about everything but it still doesn't address any of the prevalent dysfunctions in the Joomla! organisation. Even though it is pitched as having a flatter structure it doesn't do away with the bureaucracy and potential cronyism, it simply enhances it. It doesn't address the communication breakdown. It doesn't inspire trust. On top of that, it gives way too many responsibilities to too few people, without taking into account that they are volunteers who actually have a life outside Joomla!. Instead of decentralising the structure it centralises it even more. Unfortunately its authors are so lost in defining all the small details to the extreme that they missed the big picture: Joomla! will still be a dysfunctional organisation.

So what's your take?

I'm in favour of a very flat organisation instead of the top-down approach of the current proposal put forward by OSM. The proposal by Brian Teeman and Jean-Marie Simonnet is close enough, but not quite to the point. In any case, OSM should be reduced to the bare legal minimum for having copyright and trademark protection for the project, exactly as originally conceived. The project leadership is something I will expand on further. The third ingredient that's required is an oversight committee which will act as a mediator for disputes (enforcing the project's Code of Conduct equally) and provide guidance in matters of ethics. Ideally this should be consisted of people who do not have a vested interest in the project, meaning that most of you who have read so far are not eligible, just like yours truly.

Which brings us to leadership. The first thing we have to understand is that leadership doesn't mean "those who do" but "those who inspire and facilitate those who do". Having a bunch of coders in a production leadership team is about just as right as pulling a farmer out of their field and making them the Minister of Agricultural Affairs. Just because someone knows how to plow doesn't mean they can be a minister. It's a bad use of their time and leads to bad decisions all the way down. The person you need in a leadership position is someone who is familiar with the work being done in the department they lead, able to inspire those who do the work and extremely familiar with how the customers (the end users using the software we produce) are affected by the work of their department, as well as what they desire from the product. This pretty much means that the bulk of the current leadership is unfit for the job. And to make things clear: I've stated and I do state once more that I would absolutely suck in a leadership position. I am a doer. My time is best spent churning out code. This blog post is one of the rare occasions I slip into my old hat of business consultant, someone who has to be a leader to have any chance of getting things done

This brings us to the question of departments. I dislike the word in connection with a purely volunteer-driven organisation, but we do have to call them something. You only need a handful of departments: production, marketing, infrastructure, documentation, support, connect. Production: the actual code, including translations. Marketing: promoting the product. Infrastructure: those site's are not going to run themselves, plus you have to make sure that software and services provisioning never hits a bump. Documentation: people need to know how to use the software, how to improve the software and so on. Support: anything we do to help people including forums, Facebook, Google+ and even liaising with local communities. Connect: connecting with local communities (JUGs), events organisation (JoomlaDays). Each department should have three representatives in the leadership team, with their responsibilities spread out between them according to their available time. If someone is absent or otherwise unable to fulfil their duties for over a month, replace them. Being a leader is not a badge, it's a high responsibility.

The scope of the project is so large that it makes no sense to have a department of three people trying to run the show. It's physically impossible for paid staff, let alone volunteers. This begs for one –and just one– organisation level down the ladder. Let's call them divisions (we currently call them Working Groups, but that's almost become a joke). Each department can have as many divisions as necessary to perform the work efficiently, but not any more than that. In other words, if three people have a crazy idea that doesn't make them automatically a Working Group like it does today. Divisions can have outside people (community members) and/or persons from their or another division working on a specific idea but let's not call these initiatives anything in particular and we won't get any cookie lickers who linger on for the badge and the self-inflated ego. But how are the leaders chosen? It's up to the divisions. They should choose the people who are better in inspiring and managing than doing. I know this sounds a bit nihilistic, but it's not. It is meritocratic.

But how does this relate to the four parts of the business process we stated earlier? I'll start with the Execution and move forwards as it makes more sense. Each division performs the work which has been decided by means of productive discussions with its department leadership members and probably the other divisions in case their work intersects. At a bare minimum people should file a weekly report of what they're working on, what they've done and note any challenges they face.

Let's go to Reporting. The individual division reports are collated by the department leadership into the department report. Obviously, it's a shortened, less detailed version. The department leadership needs to know what is the department status and whether there are any problems a division itself cannot handle. In their turn, they add the department's report data to the global project report which allows the global leadership have an idea of where we're standing as an organisation.

Hey, what just happened? We suddenly have a good idea of who is doing what, how long it's taking, whether they have any problems and actually be able to solve issues before they become unmanageable. That's the first step to Reflection. We interpret our KPIs (Key Performance Indicators) and have a list of problems and action plans at the division, department and global level. Action plans can be reviewed in very short (less than 30', tops) weekly or biweekly (depending on the nature of the department) meetings and everyone is current on what the heck is going on. Now people trust the leadership because they know what is going on and why. Add to that the feedback from the customers (our community) and we have a very good overview of where the project is standing.

And finally we get our hands on Planning. Armed with the information we have obtained we can revise our planning. Yes, you may have a release plan but if you see that there's actually no resources to implement it, revise it. Revising a bad plan to something more realistic won't get you the ire of your customers than over-promising and under-delivering. The revised plan has emerged organically from what the community customers need and the volunteer workers can, therefore it's far more likely to be respected by all.

If you weren't paying close attention you are probably shouting that we didn't address communication. Well, we did. That's what the Reporting is for. The Joomla! organisation, each department and each division produces a report. Publish it where anywhere can see it and put those links on the front page of all of our sites. As for people knowing who to contact when they want to volunteer, that's what our department leaders are for. Put a link to a page describing in plain English (and Spanish, and German, and French, and...) what each department does and how to contact it. The contact would ideally go to a something like a ticket system where any of the three department leaders would be able to answer and forward to the appropriate division. Then the leader would follow up with the division to see whether it replies to the wannabe volunteers. Heck, you can even get a report of how many volunteers you have recruited.

Will this magically be the end of organisation dysfunction?

I'll be honest: no, it won't magically eradicate it. People are imperfect beings. We all have our personalities. On top of that, life does happen when you least expect it. The organisation structure I propose is an adaptation of a business structure, inverted to work best from the bottom to the top instead of the traditional top-down approach of a business setting. It is unorthodox in the way that it gives divisions a lot of wiggle room to decide their destiny. It's not a democratic voting process (which always leads to the majority feeling ignored), it's a dialectic approach (people discuss ideas and pursue them either with the blessing of the department or at their own risk and peril). The major difference to the current structure is that when you set off to work you know if your work has a fair chance of being integrated or if you're setting off for a moonshot which may ultimately be ignored if it doesn't have spectacular results. Right now any major piece of work is equally likely to be ignored mainly by negligence and never by malice. The difference to the proposed structure is that the proposed structure gives too much faith in a voting system which can easily leave the majority disillusioned with the project, just like the majority is disillusioned with their own country's government.

The business methodology I propose is also not a magic bullet. It's something that has been found over the past three decades and a half to reduce the chronic dysfunctions in organisations of any kind, improving morale and productivity. It's worked with organisations in three continents and a heck of a lot of countries, even those with famously stubborn people. It's never been tried on a purely volunteer organisation like Joomla! (not to mention that we're probably one of a kind) but it has been tested in the public sector which is, interestingly, dysfunctional in pretty much the same ways as Joomla!. And, yes, it worked every single time.

The last word

In conclusion, we have to keep in mind that Joomla! is a unique organisation. It's ran entirely by volunteers, without any single commercial company having a significant impact or influence to its course. Its biggest strength and its biggest weakness is its decentralised organisation. By carefully tuning the structure, removing bureaucratic obstacles, enhancing the accountability and improving the communication on all levels –inwards, outwards and horizontally– we can enable Joomla! to be a leading force in the PHP web development sector for many more years to come. I would really like to see that happening. After all, Joomla! is much more to me than a way to make a living. Joomla! is my way of life.