More than five years ago I wrote on my .NET blog a little sad story about how I got fired from my job as a developer. You can read the full story here.

Here is my summary in the context of five or so years ago:

“As developers, we all make mistakes. It's the natural and human thing you can always count on. As a developer, it is your responsibility to make sure that at any given time, your team lead knows what you are facing and if you're having any problems. If you don't communicate this well using scheduled short meetings or even hall small talk, you're not giving your team lead a chance to help you. You're also setting yourself up to be the scapegoat if anything goes wrong since you are the only person that could have known and fixed any problems you are encountering.

As a team lead it is your responsibility to make sure that at any given time you know what every person on your team is working on ,if they are having any problems doing it and how long it is supposed to take. You should do at least a daily morning meeting with your team to review today's objective for each person, to leverage any problems anyone might have and to basically make sure that everyone is on the same page. Forget to do this basic thing and you're setting yourself up for big surprises down the line. Doing code reviews is also a great way to keep tabs on what's going and the quality of it. Harder to do, this should be done on weekly basis, or milestone basis (some even do it before any code check-in of any developer). forget to do this and you could wind up with code who's quality you are unsure of.”

Wow.

Re-reading this, I still like all the advice I’ve given. and these words were written with a lot of pain behind them, so this was a lesson that was really hard to learn.

I’ll reiterate the final situation that happened:

• I ended up with a team lead who didn’t trust me, and actually went (almost) behind my back to solve a problem I’ve been working on for a long time.
• I was afraid to go to work because I couldn’t face not accomplishing my work anymore
• I was afraid to talk to my team lead
• I was working hard and overtime
• I was feeling lonely because I had too much ego to share anyone with my problems
• My work was crappy. Never finished.
• I was eventually fired.

What can I do to find this early?

As a team lead you can easily prevent such a severe case of mistrust and anxiety by following a few simple practices (which I will blog about in the days to come)

• Have daily standup meetings
• Do a code review
• If you team writes tests, review them
• Don’t be afraid to “ping” people or to pair with them on tasks

 

Daily standup meetings will find the problem of non-progress very early on. within a day or two any lack of progress will surface like a smelly apple in a bunch, but the point is that you found it early and you can take care of it. During standup meetings, when finding lack of progress for more than 1 or 2 days (you set the max limit but I don’t recommend any more than 2 days) – it’s a definite sign of “stuck”.

Code reviews are there to make sure the code quality passes your quality bar – you should only pass code you can stand behind.

Reviewing tests will reveal the intent behind the code people write and let you find problems with people’s understanding of requirements much faster than a regular code review.

“Pinging” people is alert you to any bottlenecks you can help solve during the work day.

The point of all these practices is that you are fully engaged with your team members, and gain their trust. By being there with them through think and thin, they will also feel better about telling about about things that aren’t working that great, since at the point you find them they are still really really small.

 

What should I do once I find a stuck team member?

Make sure a person will pair on that task with a peer or with you for at least one day, or hopefully until the end of the task. Pair programming actually works, but if you’re not ready for that yet, just make sure that stuck team member will have at least 8 hours of thought sharing and coding with someone else. it does a world of good to both of them.

Whatever you do do not let the situation continue. Team members are often silent but they expect you to help them, even without realizing it. It is your job to make sure that person is productive again. Pairing ont he task with someone else will unblock some brain waves, and creative thought can then resume.

What not to do

Don’t try to solve the problem yourself – at least, try to resist the urge. As a team lead, it is your job to empower the people in the team – to help them learn and get better. Solving their problems for them will not get them better, instead it will only get them more dependent on you. Instead, try to ask them for several possible options of how to continue from here, and then you can choose one, or let them choose one that you have no problem with. YOu can give them hints, clues, or you can leave them alone and just say “there is a solution – take X hours and find it with one of your peers”.

But this is a subject of a future blog post as well.