As part of my mentoring activity I am often being asked questions regarding software development, talent growth, team management and more.

I would like to share my thoughts on some of the questions I was confronted with. It may help some of the followers of my writing.

  • Should you train the best developers to get better or should you train the mediocre to get better?
    • “A team is only as strong as its weakest link” – Mark Grey
    • If you can afford to train both the best and the weakest - train both
    • You could train the best to get even better and let them train the weak ones to get into their best shape
    • Not every good developer is a good trainer/coach/mentor
    • If you don’t train the weak links, they will fall behind even more and since A-Players want to work with A-Players, you will have hard time to grow talent internally
  • Why do you put the best developers as team leads and lose them where they are most valuable? Who could do the lead work instead?
    • Let’s get it out of the way: Not every good developer is a good team leadi
    • Who should lead your team depends on what “leading” exactly means in your team/company
      • Leading the team technically
        • By teaching the team members about the technical quirks of the product?
        • By teaching the team the best practices of software development and helping them grow professionally (growing talent)?
        • All of the above and more…
      • Leading the team generally
        • By shielding the team from the board/VPs/C-Level to let them work on the product improvements?
        • By leading talks about team setup, team empowerment, team growth?
        • By conducting interviews, finding and hiring new team members etc.?
        • All of the above and more…
    • So, depending on what “leading” means in your setup, you could designate different people for the team lead role
      • If you look for someone who should spread the knowledge about your architecture, you may choose the first person in the team
      • If you look for someone who should spread the knowledge about software architecture and design patterns in general, you may choose the best software developer on the team
      • If you look for someone who should help growing the talent on your team, you may choose someone who’s the best in identifying weak spots of a person and target them so that they can improve
    • I guess you promote the best developers to the team lead positions because it’s an obvious choice. You don’t have to think about the exact problem you’re trying to solve.
  • Estimations are a huge topic in software development, what is your estimations strategy? Which techniques work best in your setup?
    • There should be NO ESTIMATIONS in man-hours - that’s just ridiculous 🙂
    • Story points may work for a newly assembled team that doesn’t know its velocity yet
    • Story points are not for the management but for the team. Once management starts converting them into man-hours - you can STOP using them
    • What worked best for us is - not doing any story points based estimations. When the team works long enough together - they can pick up the work for the next sprint without putting any points on a story