≡ Menu
Pawel Brodzinski on Software Project Management

Tough Times (Can) Kill Great Teams

I once wrote a piece titled tough times forge great teams. This was a couple of stories showing how great teams were built over crisis-like situation. While I don’t change my mind on that one I have a supplement.

The other side of the coin is that depending of level of pressure around team or seriousness of crisis great teams can be killed instead of forged. Consider all people in the team as empty pages, which will never happen in the real life. If you put them in tough situations they’ll probably self-organize, become stronger. Weak individuals will go away but the rest will grow.

Now if you push more and more you’ll finally crush this construction. People are not machines. Sure, each of us can stand a different level of shit but that’s a job, not a besieged stronghold. You can always walk away to find a better work. If a current job is crappy you’ll find a better one much easier.

In small teams it’s often enough to see the first person leaving to disintegrate a group. In bigger ones it’s more blurred. Some people walk away, the rest have to share the shit among them. Survivors are pressed more and more people leave. Then you look for a manager, tell him a bunch of lies, hire him and since then it’s his problem to clean up the mess.

One thing is common for both forging and killing great teams. It happens silently and it takes time. You can’t just see an instant change and say “hey, we now have a great team here… somehow.” If you’re not aware you won’t see teams dying either.

By the way, if you’re about to hire a manager ask candidates a question how many of their teams were great.

in: team management

5 comments… add one

  • josé luis November 27, 2008, 8:26 pm

    I’ve been throught this situation many times, I know it good enough to recognize myself now the patterns of a doomed project (or little software company), some teams are not build to succeed, but it is true, it takes time, money (and patience) to realize it.

  • Customer Relationship Management November 27, 2008, 11:54 pm

    Yes i have faced these type of situations so many times.But we have to recognize the level of work pressure in the team build.

  • Pawel Brodzinski November 28, 2008, 1:59 am

    Jose, the most visible pattern of dying project (or small company) is when people in the team don’t care any more. Sure, you can always find those who never cared, but when the rest starts changing their approach to “I don’t give a damn” mode, well, the team is dying.

  • josé luis November 29, 2008, 2:58 pm

    Specially when those people who don’t care anymore are the key people.

    Having being thrown into Project Management from a technical role (programmer-analyst), which is pretty common I think (then I discovered it wasn’t my cup of tea), I could summarize in some thoughts what I’ve learned about failure (or how to kill a team without failure):

    – Product owners and stakeholders not paying enough attention to how (or which) products are being developed. Sometimes they may tend to think that things are coming along fine while the team might be struggling to deliver something that will, hopefully, meet the business needs. Most of the times they will not, and this is where the morale of the team beggins to be affected (I think having enough quality input to do your work is also a motivation). I consider this to be a difficult situation since it could be just a reflection of deeper organizational issues.

    – Poor communication, lack of agreement and lack of feedback among the team members with regard to the project. In other words, in my point of view, not having a stablished shared vision of the project from the very beginning is a sign of failure.

    – Not giving enough importance to the people’s strengths and weaknesses. I mean, programmers
    acting up as project managers without proper training or couching, having unexperienced team members design critical architectures, programmers trying to do business analysis, project
    managers being absorbed by coding activities, just to give some visible examples. According to agile methods We can be generalists at some point but that doesn’t mean every member of the team can do so properly (let’s face it). Depending on the level of tolerance and motivation, I see this situation usually ends up frustrating people.

    – And finally, paying more attention to tools and processes over people. Or the contrary, not giving them any importance at all. A project without an appropiate work context is very often disrupted by distracting the team members from the real problem.

    Not surprisingly, I think
    the smaller a company is the more visible these problems become.

  • Pawel Brodzinski November 30, 2008, 1:22 pm

    Jose,

    That’s a great list o paths which lead to death of a team. I think each of them can be a pain in the ass, yet as far as they’re isolated thing should go fine. However the more of that you see in your team the higher are chances of failure.

    I would definitely add office politics and permanent emergencies as other factors which lead to the same (sad) end.

Leave a Comment