The Elastic Leadership Book



        RSS Feed

Latest Entries


4 ways to discover a stuck team member, and what you can do about it

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.”


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.

« Daily Standup Meetings - Introduction and 5 useful tips | Main | If you don’t own your team, Someone else will »

Reader Comments (4)

Interesting. I'm currently both a team lead and active developer, working with a team member who is certainly 'stuck'. He's competent with some technology (Webforms with a total lack of good programming practices), but struggling with our current approach (MVC with good separation of concerns, DI, O/RMs, etc), and I've had a really hard time figuring out how to help him move forward.

He certainly suffers from working alone and not wanting to appear incompetent, but doesn't appear able to improve his skill set. Basically, what has happened is that his existing skill set doesn't lend itself to the new approach, and his ability to learn seems like it's near the end. It seems that no amount of pair programming or one on one instruction can get the concepts to stick--he seems to 'get it' during a pairing session, but shortly after that ends, he's back to thrashing.

I've always thought that one of the tasks of a team lead (or just good team member) was to improve the sills of my coworkers in whatever way I can--but in this situation, I'm really unsure as to what's left for me to do.


September 7, 2009 | Unregistered CommenterJim M.

Jim - that is a tough one. I'll give it some though before I answer.

September 7, 2009 | Registered CommenterRoy Osherove


I have tried to address your question. You can find my comments at the link below.

let me know if this works:

Aman Garg

September 7, 2009 | Unregistered CommenterAman Garg

@ Roy
I completly agree with you Roy on you last section where you have mentioned "What not to do". Going deep into the technical issues of the developer makes them dependent on you and takes off your focus from 'n' number of other important things/tasks to be completed. You might be successfull in delievering that one task but will definetly fail on others.
Giving clues, hints is the best option to get the best out of your developers.

Aman Garg

September 7, 2009 | Unregistered CommenterAman Garg

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>