Training methods in small team

Question

I'm working for a startup company where there are only a few employees (5 programmers). I'm senior in terms of my time with the company and experience even though I'm only 23 years old. I have no experience in leading a team other than the college project groups.

Since I'm most experienced, I was told to train the newcomers and one of them was assigned to my team for a project.

Can any one tell me how can I train them while handling project pressure myself? I want to share my knowledge with them but at the same time I want to avoid spoon feeding them or let them go astray in programming (became weak or clueless). What is the best approach to interact with them?

1. Boss them
2. Treat them as peers
3. Something else

I expect to manage more than a single person soon so I look for methods which would work in the long run and not only in this specific situation.

Answer 1

First of all, I'd like to congratulate you for being worried about the quality of your relationship with the newbies. It makes me assume (and believe) you're on the path to be a good lead on the long term.

Things I believe you must have clear in your mind:

- You cannot do two things at once: as @JonnyBoats stated, you must not expect to be a dev leader plus coacher at once with the same quality as if you were doing any of them separately. Take this lesson as a bottomline (and honestly discuss about it with your managers), otherwise you'll get very frustrated quite soon.

- You will fail: Calm down, I don't mean the project will fail; I mean that eventually something will go beyond your hands. Get prepared for it... specially because when acting as a leader, you'll be the focal point (i.e. the person to be blamed) from both managers and developers.

- Training takes time: Again, have on your mind that any learning curve starts on debt, and can easily take months to go for a 'credit' state.

- Training needs patience, persistence: Don't get frustrated or upset because someone doesn't understand your explanation; remember that making someone understand some concepts depends on both sides.

Having these items fresh on your mind, I'd go for this approach:

- Know and assess your peer's knowledge: That's the first thing you will need to do to make a plan of how much training someone needs / how detailed this training needs to be.

- Make a plan: It might take some time, but try avoiding have someone 'studying'. You can even take a book and have some exercises about specific chapters, but having someone only reading (without discussing about what was read) will add less value / knowledge on the long term.

- Keep an open communication channel: Talk openly to your peers; Don't be shy in case you don't know something or in case someone knows more than you about something. There's a reason for having you leading the team that might be beyond your understanding.

- Give feedback: Whenever is possible, congratulate your peers as well as correct them when required. You need to find the mid term between being too soft and too hard (a tip: congratulate publicly, correct privately).

- Treat them as people, not resource: Be a leader, basically. THIS question might give you some hints.

And one last thing: when you're not sure about something, there will be always PMSE here to help, as well as for having you sharing your experiences with us.

I believe that the above is a good start for the oncoming questions.

Success!

Answer 2

Since you are under the gun, and an answer like "take time off and go study project management" make no sense. There is one thing I would recommend you do however, and that is read The Mythical Man-Month by Fredrick Brooks. It is a classic written in the late 1960s and is a short, easy read describing all the pitfalls of project management for software development.

In particular it describes how when you add people to a project the rate of output for the project slows down rather than increasing because senior people need to stop programming in order to train the new people.

but can any one tell me how can i train them while handling project pressure myself

The short answer is you can't, no one can. There are no free lunches, it takes time to properly train new people. The key is for you, and your management, to understand the issues involved.

PS: This is the source of Brook's Law:

which says that "adding manpower to a late software project makes it later".1 It was coined by Fred Brooks in his 1975 book The Mythical Man-Month. The corollary of Brooks's Law is that there is an incremental person who, when added to a project, makes it take more, not less time. Brooks adds that "Nine women can't make a baby in one month".

Answer 3

Possibly unlike many other PMs who only swear by methods they've learned (PMI, IPMA, etc...), and considering your structure, I'd advise you to stick with the basics.

If you try to learn how to coach people, how to drive a project, while doing all this at the same time, you will drown.

Stick with your mission : a project is getting something done. Given a scope, you have to achieve a certain level of quality, under a certain cost, with a given time (all this is sometimes summurized as QDC : quality-delay-cost ==> focus on managing these 4 items : your scope (clarify what needs and does not need to be done), the quality that is expected, the budget you have (budget can be a number of many days you have, it's not always money) and the time you have (when should it be finished ?)

Regarding training your team : do you mean programming training, ie technical training, or training for working in a project way ?

If it's project training, in your situation I'd also recommand to stick with the basics : your team members work to achieve completion of the project. As a result drive them with deliverables : a deliverable is a preferably small measurable amount of work delivered within a given timeframe. Eg : develop feature X for Friday. Teach them to respect deadlines, and associate them with progress made on the project.

You'll find that it works best when you associate people in estimations. A good way of doing this for programmers is card estimation : whenever you need to estimate the time to deliver something, break it in smaller chunks, then organize a meeting with all programmers. Explain each chunk, and have each dev "vote" for the amount of days they think it would take to do it (vote is made using cards from 1 to 20 usually, you may use chalk boards, postits, whatever works for you). After votes are revealed, you take the lowest one, the highest one, and you ask these 2 voters to explain the rationale of their vote, then you make a second vote. A consensus should emerge from the second vote (you may average the second vote scores). This way people feel they will have a say in how the work is assigned to them

If I may risk one remark, you've been put under quite some pressure considering your relatively low experience. Point this fact out to your boss, and require some coaching from them as well.

By all means focus on deliverables, especially on a startup

Answer 4

If I'd in you I would start to define team ground rules. For examples: where documents are stored (wiki?), how manage source code (git, svn, ...), how to perform tests (xunit,...) and so on.

After that I would give a pace to the team work: periodical meetings (time boxed, once a day and one retrospective each week?) and periodical releases (jenkins?).

Third step should be to introduce a visual task management like a Kanban board - http://en.wikipedia.org/wiki/Kanban_(development) adapted to your process.

In that way all team members are aware of the projects objectives and each other commitments. This creates an environment of trusting and transparency.

Your are the facilitator and coach of this process giving the freedom of the auto-organization and helping to correct the direction when is needed.

In that way you can share your knowledge without imposing activities like a boss.

Answer 5

In addition to what the others have suggested (especially Tiago's list), if the team is more than just you and the newcomer, then have someone else on the team be responsible for training the newcomer. By this I mean the day-to-day training, not necessarily training on a specific topic.

Over the past several years I've had at least a dozen cases of bringing new people onto a long term project (usually summer interns, but new hires as well). Looking at the successes and failures, one of the common threads I've seen is that the most successful experiences have been those where someone with about a year of experience has been the trainer for the newcomer. There are several aspects that I've seen play into this:

1. Unless you are really good at teaching, it is often difficult to bridge the knowledge gap between your experience and the newcomers. You'll usually start talking at a certain knowledge level, and it can be easy to miss the clues that there is something basic that you need to cover first. This can lead to frustration on your side (having to repeat yourself because "they just don't get it") as well as frustration on their side ("he makes it sound like it should be so simple, why don't I understand?"). With a newer member of the team, they are likely talking closer to the same level as your newcomer.
2. it helps reinforce knowledge in your trainer - if they are being asked questions, they are getting reinforcement on the same knowledge. And if there is something that the trainer can't answer and has to come to you for, you wind up answering the same question for two people at once.
3. it helps your trainer see some of what you have to deal with on a larger scale, helps build a trust between you and the trainer, helps the trainer work on some skills that will help them in the future, and based on the questions they bring to you may help you understand where the team as a whole could use some training
4. it helps free up your time taking care of the other things already on your plate (let's be honest, this really should be considered. If you are the senior member of the team, you likely have a dozen other things that "only you can do" - though those also ought to be looked at to see what can )

Please note that I'm not saying that the need for you to train others goes away, it just changes who it is that you are training. You should be training your most experienced people and help them bringing up those on the path behind them.