The Elastic Leadership Book



        RSS Feed

Latest Entries

First time here?


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.


If you don’t own your team, Someone else will

One of the first steps I suggest new team leads do is to take ownership of their team and territory. There were a couple of comments,  both on the blog and on twitter that questioned whether this was the right thing to do. More specifically, Lior mentioned in the comments that

“It's the job of the team to define its boundaries its the job of the team to resist outside interference.
You as the team leader is just the tool for achieving this.”

as I replied to lior that most teams don’t have people willing to start doing something like this, Lior said

“I would say in this case, that this is exactly your first responsibility as the lead. To teach the team how to do that.
Which starts by saying to the team, I expect YOU to do that. (of course in the meantime if its a big issue you should help)

I just really dont like the tilte of the post. "own the team" is such a bad term for me.”


So let me be clear:

As a team lead, “owning the team” means that you are fully responsible for the actions and outpus of the team members inside it, and that includes giving the the freedom to work in an environment where they are not constantly hassled from out side interference. It is your job to make sure they know that they have your back to tell someone to talk to you whenever someone approaches them, and it’s your job to make it clear to other people in the company that you’ve defined the boundaries in which the team operates.

Agile development books will tell you that the team needs to set its own course, and that they need to make their own decisions, and I fully sipport that, but chances are, most teams are far from this situation. To even get to the beginning of a world what that is possible, a team lead needs to take charge and be assertive and demand those rights. Otherwise no one will bestow them on the team.

Team leadership is taken and when there is none, the company feels free to interfere  with a team’s work habits to the point of no real work getting done, or work slowing to a halt due to constant interruption and direction changes.

For a team to be self-directing, there needs to be a leader that gives it the higher-up support it needs  - the autonomy to make those decisions.

That’s your job.


Call for content – what do new team leads need to know on the first day?

About 5 minutes after I posted about eh existence of this blog on twitter, I’ve gotten lots of great feedback (and various little nitpickings) about the content, what I shoudl talk about and things that I might cover.

This is your chance to influence the topics this blog covers : What topics do you think are essential for new team leads to learn if they’ve never done it before?

What tips or tricks would you give them?

What topics would you make sure they learn?

What topics have you learned about leading teams that are not covered in *any* book?


Don’t despair in the face of nitpickers

as you start up your quest to get better, you’ll find lots of gentle souls who want to help you on your journey to become better. They wil try to help you by trying to point out all the places where you haven’t been 100% accurate, or the things that you forgot, or the fact that you said “9 AM” but the daily meeting started at 9.45 AM or the fact that your cool whiteboard  is not really what Scrum, or XP or Kanban boards are like, or many other things that just stand there and look you in the face every time to raise your head in pride over the things you’re trying to accomplish or what you’ve already accomplished.

Don’t despair in the face of nitpickers!

I’m here to tell you that there will always be nitpickers. It is absolutely necessary that you:

  1. stay away from any kind of confrontation with them – it will only frustrate you.
  2. suck it up and write down what they said and learn it. But do it later, when you have time, and are not busy driving home your original task.

The point is this:

There are two kinds of people in this world at any one point: Talkers and doers.

You are now a doer you are actually doing things which change the environment in which you work, change the behavior of people around you, change your own approach to things, and sticking your neck out to take risks. All the talkers int he company will have much to say about what you did – but just take it as a compliment. there is always something to talk about, but how often to they talk about something you did?

People nitpick because they either really care about the subject (so you need to learn from them) or they really wish they would have been involved with it in the first place (maybe you can find a way to involve them?)

but don’t let that distract you from your main task. whatever it is – getting a new task board up and running, or getting a daily meeting together  - keep focused on the task.

it’s OK if it’s not right on the money. You get better by trying, and repeatedly trying again.


Step #2 – Use a big visible board with post it notes 

Most team leads really have no idea how many things their developers are doing at the same time.

There is a very simple tools that you can use starting today. Take a white board and place it in an area where your whole team can take a look at it. It's not supposed to be in a computer so don't try to use software for this.

It's supposed to be a big visible board.

Give it columns for pending tasks, tasks in progress, tasks done (waiting for approval) and tasks approved as done. In the case down below “Accepted” means that a customer has seen a demo of this functionality and said it’s OK.




Next, you can start out by placing post it notes or index cards with small tasks. you fill the left most side with tasks that you are planning for this week. This is not an “iteration”. it’s just the amount you think you can make in a week. Any tasks that don’t fit in this board belong on an excel document



Once you’ve done this, ask team members to put on the “in progress” column any tasks they are currently doing, or to add any cards which do not exist that represent work they are currently doing. Ask them to put names on cards they are working on, or, assign the in progress part in the groups by the team names:

what ends up happening in a lot of teams is something like this:


this board represents the fact that you have people working on multiple things at the same time. That’s not a great thing.

the good thing is that at least you’ve found out about this and can do something about it!

you an also use this board to show management just  how busy your team really is.

Try to have no more than one concurrent task for developers on your team, as a thumb rule.