How to Build Teams That Ship

Ten minutes in and the speaker was still discussing a product that he had built. I was hoping for more about building the team, not the product. It wasn't until 40 minutes in until the discussion changed to building teams. The first thing said about teams was "I am not going to talk about people, you guys know that already." That's why the audience came!

Audience interaction stuff is nice, but it works best when the audience is really engaged. Also, it is hard to hear audience members because they don't have microphones. Always repeat what the audience says so the rest of the group can hear it.

Good présentation, good speaker.

good talk, very informative and practical. audience wasn't participative enough to make it work.

Clear presentation and opened to discussion.

It was an interesting introductory level talk, but I was hoping for something a bit more about encouraging team members and tactics for motivating good software development in an agile group. Felt like a lot of time was spent talking about the processes they follow to do their job and not as much on the tips side.

The audience participation was interesting, but it tended to drag on a bit too long a few times and stall out the momentum of the session.

Decent presentation. I liked the way he engagged the audience for discussion and I enjoyed the topic

Having the talk rely on audience interaction is always a double edged sword. Because if you don't get good participation it can drag on.

I did like other commenters expect more good tips versus the processes that speaker followed. A little more content and not relying on the audience would make thing sing.

I got a good amount of info from this talk, and it spurred some interesting ideas. The audience participation parts didn't work as well as they could have.