How to gloriously waste three days of a 10-person development team? Send them to a wrong training led by a wrong person. As a team leader I made this mistake twice. There will be no third time.

One training was about microservices and the second one about refactoring and design patterns. We observed some really annoying anti-patterns of a technical training:

  1. Lack of preparation for practical exercises. You could say, “slides are cheap – show me the code”. And the code was bad. Our coaches had problems with IDE and dependencies. Their development environment differed from ours. We all strugged with proper configuration, wasting hours sitting on StackOverflow. It destroyed students’ motivation and coaches’ authority. We could avoid these problems if we earlier agreed to use the same environment and if the coach would check his scripts the day before.

    The exercises were chaotic also because both coaches did not really have an idea what exactly they want to do. First we created a class, then removed it and created another one without a clear purpose. Then we set up a whole different project from scratch. We wrote a lot of “example” code which eventually was moved to trash anyway. It could not serve as any aid or template during our work.

    I think we should have had a clear plan for the training and work on one codebase during all three days, slowly improving it. A clear goal should have been set.

  2. A coach does not allow discussion. This is bad because you can develop stuff in many different ways. A coach should not talk from a “guru” position. Maybe still he could learn something from his (her) students? A coach should not cling on to the agenda if he sees that students have other ideas and needs. He should not treat students’ feedback as an attempt to underestimate his authority.

  3. A coach demands 100% focus all the time, from everyone. I saw a coach who loudly reprimanded a girl who was handling company texts during training. She politely explained that it was an emergency. You can always have an emergency if you leave your company for a couple of days. The second thing is that every human has different hours in which he or she has most attention.

    As a coach, you should recognise symptoms of fatigue or lack of interest. Maybe your students need a coffee break? Maybe they disagree with you, but you speak so loud and fast they are afraid to interrupt you? Ask the group if everyone is okay and if anyone needs a break.

  4. A training company hires a coach who uses certain technology only from time to time. The company promised us they would craft a special training for our custom needs. But we had no idea that they would force a JavaScript coach who had “some previous” experience in PHP to conduct our PHP design patterns training. It turned out that we were the ones who taught our coach, not the other way around.

  5. A coach does not admit mistakes. If students tell you that you are wasting time, trying to configure some tool by copying and pasting from StackOverflow for two hours – maybe they are right? Maybe you should let go? You didn’t prepare, you’re not handling it – it’s okay, we’re humans. Just apologize and admit you made a mistake, try to move on, adapt.

  6. A coach makes an unnecessary barrier between him (her) and the students. He is too formal. Come on, developers are cool guys, don’t call them “mister” and “miss”! Let’s treat a training like a place to share knowledge and have a discussion like colleagues do, not in a “master-student” relation. So as a coach, don’t run away during a break. Have a chat with students, be available, share some funny stories.

    However, don’t try to be too cool, too “homie”. Be yourself, be authentic. You won’t build trust and authority by trying to be someone else. Also, don’t try cheap motivational talks, be specific.

My last advice for anyone who tries to train people: show yourself at conferences. Build your own brand, practise your talks, prepare for the hardest questions from the audience. Build your authority by showing your skills and openness.