9

How do you handle yourself in a new team where you are the senior most developer and most others in the team are junior to you by several years. The task ahead of the team is something nobody else including you has accomplished in their career before.

Management insists on higher productivity of the whole team, and as senior developer you are responsible.

Any tips for coming out trumps in a situation like this? Clearly, the entire team needs time to learn and let's not forget the team's new. However, deadlines are up ahead as well...

| improve this question | |
  • Should be on pm.stackexchange.com – JBRWilkinson Mar 4 '12 at 13:12
  • 5
    @JBRWilkinson I disagree. This is about being a tech lead of junior developers with a tight deadline. I would agree if it is about how to manage a project of junior developers, however being a tech lead is different than being a PM. – maple_shaft♦ Mar 4 '12 at 13:23
13

Don't let a tight deadline or the novelty of the project interfere with good engineering practice. Set-up a software repository, agree to a coding style, come-up with a test suite, etc. The newness of the task shouldn't be that big of a deal as long as you have quality people under you that are willing to work hard and learn the task ahead of them.

Or to put it another way: you were put in charge because the management believes that your background and experience has given you the tools needed to build quality software. Don't suddenly forget your skills just because this task seems daunting now.

| improve this answer | |
  • Make sure that everyone in the team has the opportunity to estimate all the tasks that they're going to be assigned, so they have some buy-in to the deadlines. Since your team are still learning the ropes, don't commit anyone for more than five hours per day, when you turn the estimates into an elapsed time. And if the deadlines can't be met, make sure Management know about it ASAP. – Dawood ibn Kareem Mar 4 '12 at 7:51
  • 1
    @David - How did you work out 5 hours (It's actually not a bad figure to use, but how do we know it)? Just admit estimating such a project is a crap shoot and tell management. – mattnz Mar 4 '12 at 7:55
  • 3
    I figure that most people are productive for about 6 to 6.5 hours per day. A few manage more than this, but I think this is a good average. But since the team is new, at least one hour a day is going to be spent learning. And I do believe in estimation - although not everyone is good at it, it's got to be better than just jumping in and programming without knowing how long a task will take. – Dawood ibn Kareem Mar 4 '12 at 7:59
  • It helps get buy in if you get the team members to develop their estimates before seeing the planned time and they don't significantly exceed the plan. Having them estimate before seeing other estimates will also avoid biasing the estimate. – BillThor Mar 4 '12 at 16:13
  • @BillThor : Surely you get the guy doing to the work to estimate it, and use his figures as the starting point. I have just estimated a job and got told "We though it would be 1/3 of that". Why did they even bother asking me if the knew how long it would take? – mattnz Mar 5 '12 at 2:34
7

First things first, start using a source code control system from the very first line of code. Get in the habit of checking code in early and often.

Second, decide on a testing strategy. Of course that should mean unit tests, but you should also consider how to automate acceptance tests.

Third, establish a continuous integration server so that your code is built regularly and tested regularly.

Once you have that, as a team establish some simple coding standards. You want your code to be easily readable by everyone. It doesn't really matter what the standards are. Indent with tabs, indent with spaces, curly-brace on the same line, whatever. It doesn't matter what they are, only that everyone consistently applies them.

Since the team is mostly junior developers, plan on reviewing code often to make sure they aren't adding too much technical debt to your system.

Finally, consider using SCRUM. If you do, hire a coach or go to some training. Since you are all doing something you've never done before, establishing realistic deadlines is simply impossible. With SCRUM, your management will have visibility into what you do on a daily basis so they can see what progress is (or isn't) being made. And, since your deadlines were apparently given to you, SCRUM at least guarantees that if you can't meet the deadline, at least you're delivering completed stories on an incremental basis, which arguably is better than coming to the end with a giant system that doesn't work at all.

| improve this answer | |
  • 2
    +1 for version control and code reviewing early and often. – jmq Mar 4 '12 at 21:10
  • 2
    I am of the opinion that source control is so necessary a process that it should be done regardless of the team makeup, regardless of anything. – maple_shaft♦ Mar 5 '12 at 3:23
6

In addition tothe answer by @chrisaycock... Do not underestimate the time you will need to allocate for mentoring/training etc. As the lead, you will need to learn to let go of the detail and trust your team. Your job is to become the enabler, road block remover, and run interferance when management poke there heads in. In a "normal" team, at about 7 or 8, the lead no longer programs, In your situation, this drops to 3 or 4 (Maybe even less), You are not a programming resource for the project.

| improve this answer | |
  • +1 on allocating time for mentoring and training. An effective tech lead makes junior developers productive. – maple_shaft♦ Mar 4 '12 at 13:26
  • "You are not a programming resource for the project". I wonder if his management feels the same way, heh. I hope you don't end up as the "hero" programmer for the project. – jmq Mar 4 '12 at 21:08
  • I was under the impression that the OP was simply the most senior developer and had no special title or duties (i.e., he's not a "tech lead" or "architect"). In that case, he most certainly is a development resource, and is probably expected to be the most productive one. – TMN Mar 5 '12 at 15:22
  • @TMN: I was reflecting the reality of what happens in a team with one skilled/experienced guy and all the others significantly less skilled. No doubt the experienced guy, if he codes, will be the most productive, and is expected to code. The TEAM will be most productive if he doesn't. In an unenlightened organization, managers measure the individual performances, so the top guy looks bad doing what is best - making the TEAM perform, and gets little reward for it. He's better to hang the juniors out dry and make himself look great. – mattnz Mar 5 '12 at 20:25
1

Focus on communication in two areas.

1) As you and the team members gain a better understanding of what's involved (nearly always "more than originally thought", it's key to spend a lot of time explaining this to management. There are few real deadlines. I usually say that a NASA probe to an asteroid that will be in a certain orbital position only once every 200 years, now that's a real deadline. Other than that most deadlines are artificial and often not based on the work. They usually sound fixed becuase "we've only got that much money", "programmer bob leaves in 2 weeks", "We have to present to investors next week". However, if the work isn't done, then these deadlines get missed. Then what happens - reevaluate and decide what to do then. In reality management would rather get that "bad news" up front. It isn't easy to do this, and that's one reason this job is hard. If meeting the deadline mean cutting features then go over that. The one thing you're trying to avoid in all this is quick code to make a deadline. That's the beginning of the end of a code base that will not last well and the beginning of technical debt that chokes.

2) Inter-team communication. Set up formal practices like Bryan and others recommend. Make sure that you meet regularly as a team, e.g. once a week in addition to daily scrums. Gain respect and trust by listening, your most important tool. Make sure you focus on helping. Avoid negative criticism at all costs. When necessary use positive criticism and encouragement, e.g. "that is great, once thing you might want consider is X" over "that is not what we need, you need to do X instead"

| improve this answer | |
0

What I have done is identify the capable ones and divide and conquer. I take the top 2 or 3 and make them captains. The others are then evenly split up into teams following the captains to their own little teams.

I give the captains chunks or modules to do of a program.

The captains give the newbies smaller programming or research tasks all the while explaining themselves what they are doing so mentoring happens while doing.

I try to arrange the room so everyone is in the same open space but each team is has their own circle of computers. I like to be in yelling distance to everyone so things move quickly.

This works well for about 10-20 programmers so far. The smaller groups are just better being in one group and I have not worked with anything larger yet.

| improve this answer | |
  • Divide & Conquer has its pitfalls. I have seen this end up as every subteam re-inventing the wheel (badly) for similar problems that the whole team faces. – NWS Mar 5 '12 at 9:20
  • Yes if you are in separate buildings especially so I try to keep everyone in an open space and walk around regularly. What I do is build core API signatures and set the teams out to build them so it all connects. – Jason Sebring Mar 5 '12 at 15:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.