In the previous post in this two-part series, I talked about there are different types of teams that are out there and that work together on certain types of projects despite the fact that most of the material that we read is oriented around teams that make up a startup, a business, or a company.
Specifically, I talked about how I used a team to help test my WordPress theme prior to releasing it for sale, and how each person on the list was vetted and provided invaluable information, we didn’t have any type of strict hierarchy.
Instead, it was basically everyone person working together to make sure the product was as solid as possible. But there are more reasons on why you need a team.
As I’ve continued work on the next iteration of the WordPress Plugin Bolerplate, I’ve been working with a very small, focused team of developers all of whom are doing a stellar job helping to bring this project to fruition.
Wait, What? You Need a Team?
As most of the more popular wisdom shares, we often need teams to help us make better progress, faster, and to make sure that we’re covering all aspects of a given project such that were I may have one opinion on how to do things, another person may have a valuable opinion on how to do things.
Obviously, there are other reasons, but the entire point of these two articles to to share why I think that we all need a team even if it’s for a temporary project or for a temporary need as opposed to a more long-term need such as building a company.
In the context of the WordPress Plugin Boilerplate, I found that I needed a team for the following reasons:
- The amount of issues and pull requests – although absolutely welcome – were becoming more than I could handle on my own.
- Other people had shown interest and passion for this project and want to introduce some very cool features into it and I value their input.
- There are other people who are far more experienced with certain aspects of WordPress development, such as internationalization, than I am and we can create something more useful when we’re working together.
Naturally, there are more reasons than just those listed above, but you get the idea.
To elaborate just a little bit more, there are times were certain projects can outgrow the initial team (especially if it’s a team of one) and it benefits all parties involved – both contributors and users – to have a larger team around the project.
When it comes to the WordPress Plugin Boilerplate, I decided that I needed a team when I noticed the backlog of issues, the various questions, and the sheer number of ideas that people had in terms of the direction that it could go.
Of course, I have my own vision and mission for what I want to achieve for the project, but I also value the input of the open source community. Valuing input doesn’t mean that you accept everything that everyone offers; however, it does mean that you read and weight their opinions to see if it contributes to the bottom line.
In the context of this project, I began to notice a core group of people who were relatively active in terms of supplying pull requests, answering questions, or contacting me directly about certain aspects of the project.
I also noticed that there were a number of people who had some great ideas as to how to take the the project to the next level.
Finding the Team
Specifically, the WordPress Plugin Boilerplate is growing to a point where we want to have an entire website dedicated to the project – not just a GitHub repository – and we want to make it much more accessible to those who are amateur developers.
By that, I mean no one should have to learn GitHub in order to get started with the Boilerplate.
Furthermore, there’s no reason why we shouldn’t have more complete documentation not only at the code-level, but at the user level that explains how to achieve common tasks with the Boilerplate itself.
It’s a lot of work for one person, right? And one person’s ideas can’t all be good. This is where a team comes in.
But how do you go about finding them?
As I mentioned above, normally, the people who can be most valuable to a core team around a project like this are those are most active on the project on GitHub. That is, they are answering questions, providing rationale for why something is the way it is (or isn’t), and are willing to field questions, comments, and even issue pull requests.
After all, wouldn’t you want the same people who are actively contributing to the project to continue, y’know, actively contributing the project?
To that end, I’ve got a team that’s working hard on the rewrite, the landing page, the documentation, and even some who are helping with the design aspects.
But just as I said with the Mayer Beta Testers, this team isn’t a traditional hierarchy team. Instead, it’s one in which we all speak candidly about certain decisions that are being made around the project, and it’s one in which we are all invested in seeing succeed for the WordPress development community.
There Is More Than One Type of Team
Just as I said in the previous article, this is just another example of a type of team that can exist, that can work together, and than can do good things without a lot of the overhead that comes with teams that make up a company, small startup, or something similar.
This isn’t to say one is better than the other – it’s impossible to state that because it’s comparing apples to oranges – but it’s to say that there are other types of teams that are out there that still have common goals, that work together, but do so with a slightly different form of organization than what we’re used to reading about.
To that end, if you’re involved in build a product or working on an open source project, I encourage you – and anyone else – to explore various avenues for building a team to help make the project that much better.
With all of that said, I’m interested in your feedback (be it questions or comments) – if any – on all of this because this is something that’s simply based on my experience. I’m interested in others thoughts on it, as well.