Team Leadership Skills – The Missing Link
My name is Roy Osherove. I speak about, and also coach and teach software team leaders to be more effective at their job. Having been a a software team lead myself, I've made lots of mistakes that I learned from, and I've had some very good mentors to learn from as well. This blog is the product of frustration from seeing all the mistakes everyone else makes, that I've made as well. We do not learn from the past. From each other.
Team Leadership is the missing link that connects all the buzzwords you hear these days about unit testing, TDD, Continuous Integration, Scrum, XP and others, to the real world where actual people have to learn, implement, and mainly, believe and push for this stuff to happen.
We re missing an overarching goal. A Manifesto can start directing us there.
Many software team leaders today face a weird problem: they believe in a bunch of great things that software developers should be doing but somehow can’t seem to make this work at their own team.
For example they feel that shorter iterations can be good for the team and customer, but no one seems to believe them, or no one cares when they mention it.
They believe that unit testing can save the product from its poor quality, but their team members would rather do anything but write those tests.
Team leaders everywhere seem to be hitting a wall everywhere they try to make a difference – so they give up, or they get things done half-way to the point of failure.
Driving “the new stuff” into the team is usually the least of the worries of today’s software team leaders. Team leads usually have little to no idea how to handle people related issues – issues that affect how the morale, quality of work, and overall performance of the team, and of course impacts how easy or hard it is to implement “the new stuff”.
Most team leaders are clueless as to how to handle their manager giving them an impossible due date, a team member reluctant to try anything new, or another team member teaching all the other members practices from 25 years ago that today only hurt the team.
No one teaches that to software team leads. Team leads today, in the overwhelming majority of places, are just developers who worked hard and stayed with the company long enough to be promoted. But they have no people or management skills - and those are very painfully needed when you are trying to drive the things you believe in inside an organization that has very little interest in changing.
Team leadership is the next big thing that software developers need to conquer, or none of this unit testing, TDD, Agile or Lean thing is going to catch on, except in very small circles, that, by chance, happen to have the right people leading their teams.
That’s why I started this site – a blog for new team leaders, talking about the questions and problems today’s team leaders face – I’d love it if you joined the discussion!
What should you do now?
- Read the team leader manifesto
- If you're a new team lead you should learn about the three team phases your team might be in.
- If your team is in chaos, read about the first steps to take during chaos- a simple list of things every team lead should be looking into and actively doing with their own team.
What things can you learn about in this site?
- Scrum self managing teams
- critical thinking in teams
- A book for software team leader
- Five-minute, standing meetings only
- How to become a team lead
- What should we start doing as a team?
- Excluding team members - yes or no?
- More Leadership books for software
- Proactively contribute to the work of the team as a whole - examples
- Architect as the team leader
- Maturity of Scrum
- The 5 whys
- Antipatterns in teams
- Stand up meeting ideas