Last time I laid out my eight or so idealized classifications for staff positions, describing what sorts of work they needed to do before a visual novel translation project can finish. Now, I’m going to turn my attention to the actual staff makeup.
In the first introductory part of this series, I argued for the existence of a “core team” with minimal fluff and dead weight. I had argued that small groups are more flexible, can be less bureaucratic, and in general easier to manage. This article here will try to tie that philosophy with the issue of dealing with the number of roles we have to deal fill.
Now, just as there’s no one way to manage a team, there’s no one way to think of building one, but this is all what goes through my own head when I’m thinking about putting something together.
Specialization is your enemy, not your friend.
This single rule, is probably the overarching theme to this entire piece. Specialization is not your friend. It is something you have to work to fight against whenever possible.
But what? But specialization of labor is one of the great advances of society, one of the hallmarks of civilization since history began! Without specialization, we’d never have technology and society to begin with!
This is most likely true. But I’m speaking about a very specific kind of specialization that must be avoided. It’s the kind of specialization that probably came fully into the cultural consciousness starting at the Industrial Revolution, with it’s cog-like factory of semi-skilled workers. It’s the kind of corporate climate that can dominate HR departments to this day, where you are your job title, and little more or less. Everywhere I go, I find the assumptions associated with this mentality at work. “I have my job, he has his, and that’s that”, “your job is X”, “I’m just good at this one thing, you can use me right?” All this gets in the way of getting things done.
I’m pointing my finger at the “not my department, not my mess” mentality bad obsession with specialization breeds. This is exactly the sort of situation that people create that spawns unneeded bureaucracy in small groups. There’s no room for that in a small core team where every last member of the team is important.
Instead, everyone involved should have a hand in everything as much as they possibly can. We’re talking small businesses here, not large mega-corps. In a small business, everyone has one (or more) specialties, but everyone pulls their weight where it’s needed, even if they’re not an expert in an area.
Everyone can do more than one thing – plan accordingly
It’s a sad reality in the world that our first contact with people usually involves the question “What do you do?”, as if that one single answer defines that person to any major extent. Just because I spend my days analyzing data, designing models and coding them, doesn’t mean I can’t be a translator, or musician, or artist off of work.
The same principle goes for staffing, a number of roles require very specialized talents: translator, programmer, reverse and release engineers, editing to a degree. Even then, I know of a number of members of the community that do all of them at once, and do them very well. Just as I know people who can only seem to do one.
Then there are somewhat more accessible roles, such as graphics, proofing, testing. While not just anyone can take on those roles, everyone is likely to have some ability to help out in those areas. You don’t need a degree in English to know that I’m writing gibberish, or if my: punctuation and usage —- totally somewhat off base it is.
I argue that for the core team, there are never people with single tasks. Sure, they probably have one or more primary tasks —- you’re not going to make your translator spend days on a graphic while there’s still script left to translate, but if someone has their hands free, there is usually something that needs to be done. Sitting idle is usually a sign that there’s either two many people on the project, or you’re not looking hard enough to find things to do.
Everyone can test, every can proofread to some degree or other, everyone can test for bugs, or read things. So, why is it that we need so many dedicated testers and proofreaders and such in the core team where managing them takes effort? Every last member can fill that position when the time comes, dedicated testers can wait until the final beta testing phase right before the release.
Just about all the very intelligent and hard working people I know can do multiple things well, they’re not just 1 specialty and that’s it. Heck, look at yourself, can you put your own talents into a single box? I’m confident you can’t.
The whole point is to find good people who have many useful talents, and then bring out as many of those talents to make the project work. If you do that, then you really don’t need 20 people to do something. I’ve seen core teams that were a single person, and teams that had more than 5, but what they all shared in was that they handled huge overlapping chunks of the project that couldn’t be classified by a simple title.
Only when you’ve tapped all the available talent in your team, do you look outside
No matter how multi-talented your team is, sometimes you just need something done that no one can handle. Then that’s the time you look outside for extra talent. However, when you reach out to them, you have to ask yourself whether they should be included into the core team, or whether they just help out with that task, and that’s it.
The decision isn’t much of an easy one, but it mostly rests on one thing. Adding a person (as is losing a person) to a team can change things, sometimes in dramatic ways. So be careful about adding or removing members.
But since recruiting and all that is a big topic, I’ll save it for next time. (Here)