Posts that normally talk about teams usually discuss the importance of going further, faster, team dynamics, people leading in their core areas of competence, and often come back to some form of leadership.
I think that all of that is right and all of that is good and valuable, but when it comes to talking about a team when building some type of software project, I think that the articles and conversations are usually oriented around the ideas and challenges of building a company, or to help build something for the long term.
But there are other types of teams, and they are just as valuable as those that help make up a development team, testing team, a startup team, or so on, they just don’t necessarily fit the traditional mold.
And because of that, these are the types of teams that are normally talked about. As such, I thought it might be worth sharing a few thoughts on why you need a team especially in a non-standard context through my own personal experience.
Why Do You Need a Team, Anyway?
When I moved to self-employment, I was part of a team – 8BIT – that focused on building products (both analog and digital) for WordPress. We had four core partners and then an extended team of stellar guys where all us were responsible for areas that were related to our primary area of strengths.
This is more of the traditional team model that I was referencing before, and this is not the type of team that I’m talking about.
When I first began working on Mayer, I knew – especially from experience – that anyone who has actually built a product is the worst person to actually test it. You’re too close to project – you know how it works, you inherently know how it’s supposed to function, and you therefore know how not to break it.
To combat that, you need to get it into the hands of a vetted team of people who are going to hammer on it from all areas in order to expose all of the bugs, the flaws, and the problems.
I put out a call for beta testers and was fortunate enough to have 20-some odd testers all of whom did a terrific job helping me to shake out the bugs so I could release the theme with a strong 1.0.
Finding the Team
The thing is, I didn’t go into this simply asking for anyone and everyone to test it. I did some light interviewing in where I asked those who were interested to contact me via email.
From there, I provided them a list of questions that I wanted them to answer. These were primarily to get an idea as to the type of person they were as it relates to blogging, technology, development, and so on. I wanted to make sure that I had a diverse group.
I then selected the 20-some-odd people I wanted testing the theme. This doesn’t mean that I rejected people who weren’t qualified. I mean, I think you can make a case that many people are qualified, but I forced myself to narrow down to a smaller, diverse group in order to make sure that dealing with all of the feedback was manageable and didn’t delay the release date of the theme.
But how does a team setup like this actually function?
- I setup a backchannel for myself and all of the testers so that we could communicate.
- They each received a copy of the theme as well as any basic instructions on how to get started with it, and then I told them to have at it. The last thing I wanted to do was to give them directions on how to use it – after all, that’d undermine the entire point of the testing process, right?
- From there, I then asked each tester to provide any bugs or issues they found, screenshots, reproducible steps, and so on, and then I iterated on the beta until the feedback became more and more along the lines of “works fine for me.”
In this case, each person’s responsibility was to test it to the best of their ability. That’s it. I gave no other direction that than that. I can definitively say that doing this helped me release a version of the theme that has had very few bug-related support tickets.
I’m not saying it was perfect. It wasn’t. I don’t even think it’s possible for humans to produce perfect software (let alone anything else), but I digress. The point is that having a team of 20-something people hammering on the product from all sides helps to make a stronger product.
There Is More Than One Type of Team
No, there’s no organization or hierarchy and there’s no relationship between the people who were helping out other than they were gracious enough to volunteer their time, and to share their candid thoughts in how the product performed.
In order to create a team to help with this single purpose, it included two things:
- A little bit of their time
- A free copy of the theme once 1.0 was released
And it worked out great. This is something that I highly recommend anyone and everyone do whenever they’re getting ready to release a product – be it a plugin, an add-on, a mobile app, a theme, or whatever.
Have someone hammer on it from the user’s perspective. The amount of information you’ll get is invaluable.
In the next article, I talk about another type of team that I’ve been working with on a separate project that also helps to show yet-another-type-of-team and how it proves useful in preparing a project that’s going to be released to the open source community, but has nothing to do with a startup, company, or organization.