I’ve been leading a team of 5 devs, 1 tester, 2 designers, and 1 customer for the past month or so. During that time, I’ve learned a lot from watching this team grow, in their relationships to each other, and in their ability to work together as a team.

What has struck me about this is that all of this happens best if I keep my nose out of it. And this is the hardest part for me.

My Struggle

I’m an experienced agile coach and team leader as well as a long-time developer. While this would seem to be an advantage, the problem with having all of this experience is that I have all the answers that the team needs — if you don’t believe me, just ask me 🙂 All kidding aside, this is a big part of the problem. I really do have answers for most of their problems, be they technical, teambuilding, or whatever. But to help them grow together as a team, it is really important that I keep my answers to myself.

The idea is that the team must learn to recognize the issues that they have, understand what the effects of the issues are to the team as a whole, and figure out how to solve them on their own. If I  do this for them, then I remove a tremendous opportunity for growth from them.

Examples

Over the past week or so, they’ve really taken another giant leap towards emergent behavior (co-incidentally, this corresponds to me consciously tending to my own knitting.) During that time, they’ve

• Realized that they don’t have a good enough shared understanding of the architecture

  • Accepted that they feel rushed at the end of each iteration

    • Seen that they have some major refactorings to do

    and they’ve also found ways to solve these problems by themselves. Their decisions, which I heartily approve of, include:

  • Switching pairs more often, using an egg timer to tell them when it is time

    • Starting to have chalk-talk sessions where someone explains some architectural concept to the rest of the team, and they discuss it

      • Not putting off refactorings for so long, so as to avoid having them hanging over their head and to let them proceed more predictably

        • Promise a little bit less to give them the space they need to keep the code clean
        I’m thrilled that they’ve seen and solved these problems on their own. As their manager, it is my job to defend their decisions to the rest of the world, a duty which I gladly accept. I did see each of these problems as they were happening, but I tried really hard not to tell them how to solve the problems. I pointed them out a few times, maybe, but perhaps they weren’t at a point where they could hear me yet. I really tried hard not to push, as I wanted them to own and fix the problems, and it actually did happen. And that let them grow together as a team.
        

      Conclusion

      In my mind, this is the hardest part of being an APM. It is not my job to be a problem solver as many PMs feel is their role. It is my job to enable my team to solve problems on their own, and to create an environment where they feel safe to do so. This is much harder than solving the problems themselves, as I (as do most people) have the urge to grab those reins and lead away! I hope I’m up to that challenge, and that I can grow as a manager as the team grows together.

      bab