Coffee Driven Development

In my previous post The three team phases – from Notes to a Software Team Leader: Growing Self Organizing Teams by Roy Osherove  I was looking at team phases. Now lets check what types of leaders we can become according to Roy Osherove.

Command and control

We’ve all seen or have been this type of leader at some point. You tell people what to do. You are the “decider.” You take one for the team, but you also have the team in your pocket in terms of hierarchy, decision making, and control over everyone’s actions.

The command and control leader might also solve everyone’s problem for them. I once had a team leader who, on the first day that I joined the team, set up my laptop while typing blazingly fast on the keyboard and not sharing with me anything he was doing. When I asked questions, he muttered something along the lines of “Don’t concern yourself with this now. You have more important things to do.” (read that sentence with a heavy russian accent for better effect.)

With a controlling leader, there is little room for people to learn, take sole ownership of anything, or take initiative that might go against the rules. And that’s just the way things are.

This approach won’t work if your team already knows what they’re doing or if they expect to learn new things and be challenged to become better.

Coach

The coach is also known as “the teacher” and is great at teaching new things to others. The opposite of the controlling leader, the coach is great at teaching others to make decisions while letting them make the wrong decisions as long as there is an important lesson to be learned.

Time is not an issue for a coach because time is meant for learning. It’s like teaching your kid to put on their shoes and tie their shoelaces—it takes time, but it’s an important skill, so you’d be making a mistake not taking the time to let your kid to go through this exercise on their own, cheering them from the sidelines.

This approach won’t work if you and your team don’t have enough free time to actually practice and do any learning. So if you’re busy putting out fires all day, and you’re already behind schedule anyway, you won’t have time to also learn or try new things like refactoring or test-driven development.

Facilitator

The facilitator stays out of everyone’s way. Whereas the coach challenges people to stop and learn something, the facilitator simply makes sure that the current environment, conditions, goals, and constraints are such that they will drive the team to get things done. The facilitator doesn’t solve the team’s problems but instead relies on the team’s existing skills to solve their own problems.

This whole approach won’t work if the team does not have sufficient skills to solve their own problems (such as slow machines, talking to customers, and so on).

That was one of many great thoughts from Roy Osherove book. I will post some more soon. If you would like to read this book, please follow this link: