Warning: this post has almost nothing to do with testing and it barely has anything to do with software development.  Managers should read it however.

Last night, at the Atlanta Scrum Users Group, I saw Peter Saddington’s talk, “The New Role of Management for High-Performance Teams”.  Peter has three master’s degrees and claims to be Atlanta’s only Certified Scrum Trainer.

Here are some highlights from my notes:

  • Managers should see themselves as “managers of inspiration”. Don’t manage issues.  Instead, manage inspiration.  Help people love what they do first, then you don’t need to manage them.
  • Everyone can improve their job performance by taking time to reflect.  Few bother to, because they think they are too busy.
  • Stop creating processes.  Instead, change the rules as you go.  The problem with process is that some people will thrive under it and others will die.  There are no “best practices”; (Context-driven testers have been saying this for years).
  • The most important question you can ask your directs is “Are you having fun?”.  Happier employees are more productive.
    • Play and fun at work have been declining for 30 years (in the US).
    • Burn-out rate has been increasing for 30 years (in the US).
  • Myth – Agile teams should be self-organizing.  Fact, marriages are about the only true self-organizing teams that exist; only about 50% are successful (in the US).  Instead of hoping your teams self-organize their way to success, get to know your people and put them on teams that make sense for them.  Try re-interviewing everyone.
  • If you learn 3 things about a co-worker’s personal life, trust is increase by 60%.  “How did Becky do at her soccer game yesterday?”
  • Motivate your teams with these three things:
    • Autonomy – People should not have to give it up when they go to work.
    • Mastery – Ability to grow one’s craft.  Help people make this happen.  Put people in places where they can improve their work.
    • Purpose – People do their best work when they know why they are doing it.
  • Any manager who asks their directs to work on multiple projects at once, should be fired.  Study after study shows that multi-tasking and switching contexts burns people out and causes them to work poorly. 

Peter did a fun group exercise to drive home that last point.  He had some of us stand in a circle and take turns saying the alphabet or counting by multiples of 3 or 5.  He began forcing us to switch patterns on the fly, as we worked.  Afterwards, we all hated him and his stupid exercise.  …He was representing a manager.

6 comments:

  1. Brian said...

    Eric, I both totally agree with you and totally disagree with you!

    I think this is one of the best posts I've read in a long while... and I think every person that holds a job should read it :)

    Thanks for posting!

  2. Unknown said...

    Nice post Eric. Thanks.

    I also would not agree that Agile teams should be self organising. In my view, an Agile team should be atleast 70 % self organizing (I am meaning average here). Which means that the rest 30% is upto the Project Manager to get them to a common direction and get them fully efficient. But if they are less, the project manager will have a tough time bringing together the team.

    - Rajaraman R
    Agile Blog

  3. JR said...

    Eric, Wednesday was my daughter's birthday so I was not able to attend. It looks like I missed a good meeting.

  4. Eric Jacobson said...

    Yeah, I missed you there Jimmy. Hope to catch you at the next one!

  5. Mesut Güneş said...

    I am really impressed by this "Managers should see themselves as “managers of inspiration”. Don’t manage issues. Instead, manage inspiration. Help people love what they do first, then you don’t need to manage them."

  6. The Rain Maker said...

    i would love to have a manager like you described in your post.

    thank you Eric!!!



Copyright 2006| Blogger Templates by GeckoandFly modified and converted to Blogger Beta by Blogcrowds.
No part of the content or the blog may be reproduced without prior written permission.