Growing from one-person-team to multiple people

Question

At my workplace, I used to work alone for quite some time on some projects. Fortunately, now there is money and (hopefully suitable) people to take some from that work off me.

I will still be around and do some specific tasks in those projects. The daily routine business and some time-consuming tasks are taken by someone else, so that I can concentrate on development.

Now I am thinking about how to manage that transformation from a one-person-team to a two-, three- or maybe four-person-workforce. So far, I have come up with the following steps and strategies:

• allow enough time for training of the newbies, do a workflow simulation so that they can learn, try and break everything before it is for real
• transfer responsibilities one-at-a-time and check back to see whether things go well before adding new items to the pile
• after the training and transfer period, discuss and define key resposibilities for every member while emphasizing that everyone must have an idea what the others are doing, i.e. to carry on their tasks smoothly if someone is sick for some time

While I am not formally a manager, I understand that my managers trust in me to sort of coordinate what is going on in my area. So I am not trying to become a sub-manager, but rather support my colleagues in working in the project and creating their niches each, while I still want to "keep my foot in the doorstep" for my development-oriented niche.

How to support the change process from an one-person-team to an actual working group with distributed responsibilities?

Answer 1

Before you think about how to train and manage them, you need to think about the job itself.

When I was a one-person team I developed processes that worked well for me. I could also afford to be a little casual about some things, because I was the only person affected. When I was given a team the challenge wasn't just to teach them but to figure out if changes were now needed.

So take stock. Are you using some sort of task-tracking system or just keeping things in your head? Are you isolating individual changes so they don't conflict with each other? Are you maintaining any internal documentation? If not, maybe you need to change some of that before you start training people. Because while "read my mind" has worked well for you so far, it's going to be really hard to teach.

What worked for me was to teach my new team what I wanted them to do while also engaging them in evaluating and improving processes. I didn't have any super-junior people, which helped -- for them I'd probably give well-defined tasks to ramp up on and defer plunging them into the deep just yet. I encouraged a collaborative attitude and frequent conversations about what was working well, what was confusing, what was really hard... and over time we experimented and made improvements. Everybody was, and felt, part of it, and we converged on something that worked well for a growing team.

Answer 2

Most of the results will depend on who you are hiring.

Joel Spolsky tells it better than I could : The importance of Quality recruits

“I guess not. Oh, wait. You said I have a staff of two programmers?”

Right.

“Who are they?”

Does that matter?

“Sure! If the team doesn’t get along, we’ll never be able to work together. And I know a few superstar programmers who could crank out a Fortran compiler by themselves in one week, and lots of programmers who couldn’t write the code to print the startup banner if they had six months.”

Now we’re on to something!

In other words, depending on wether people arriving to help will be mediocre or superstars, the appropriate answer is completely different.

Often(but not always, it's also personality-dependent), a mediocre coworker needs to be pushed in the back to advance. A superstar coworker will advance alone by himself, but not always on the most important direction - those people tend to be more independant-minded.

TL;DR : learn to know those people, and learn how to help them being helpful.

Answer 3

When I did this I tried and failed a couple of ways, especially trying to go cheap and training someone.

My experience is that firstly you need someone who will hit the ground running, costs a bit extra but you get off to a good start. Trainees are too much headaches, you don't know how quickly they learn, how committed they are, and you have to train them AND do all the work at the same time. Very stressful while you're also doing all the extra paperwork (and there is a LOT) that comes with employing people.

Answer 4

Depends entirely on who you're comfortable hiring.

1. Do you need an underling who will follow you and who you need to train and teach?
2. Do you want a teammate with equal responsibilities?
3. Are you fine with hiring someone completely new to the project who will become your mentor?

Depending on how invested you are in the project and how much time you've had for personal growth, option 2 and 3 are not always realistic, but if you can make it work they are preferable. If you go for option 3, the mentor will help you setting up the process.