How Not To Lead Into Deadlock

Have you worked in an agile environment?

Adaptable, flexible, and adjectives like that are common when you look for a job or talk to people. Everyone’s got the role and responsibilities defined. However, we do tend to overlook them when needed or to say when we are lazy.

Recently, I came across a situation where the team was behind schedule by a mile and they needed to get the impediments out as quickly as possible. Funny thing is, people may forget about the common goal they’re working towards, they never forget to play the blame game. It’s never easy to work with team across geographies, with varied cultures. So, instead of resolving the issues at hand, the teams involved started this ping pong of passing the work/blame over to other team. And when asked about the status, the teams responded they are analysing the issue and everything is working fine at their end but it’s the other team who needs to fix at their end. So if two systems are working fine individually but not when they are integrated, then whose territory is the integration? Ummm.. Obviously, it’s both the teams’.

It’s like those situations where without the handshake, the meeting never happened! The simplest approach at this time would have been for both the teams coming together and resolving it. But, due to their time differences, approach differences, and failure to identify this need: the meeting never happened. Amidst, all this the team who was responsible for verification was blocked. In spite of checking every possible scenario, working with all the tools at hand, and speaking to different technical teams; it was a deadlock!

After days of waiting, planning and re-planning, the teams were forced to make time for THE call. Didn’t matter if one is on earth and other on moon, if one is sitting in office late at night or coming too early; the meeting was absolutely necessary!

Where’s the wall with “Bang Your Head Here” written all over it?!

Someone, please shoot ’em all!! The call, which went on for around 45 minutes, made it clear that there were certain changes required at both ends to make the code work. And just like that we all had an understanding of what needed to be changed and an agreement, at last!

This situation led me back to three principles which are long forgotten,

  1. You don’t always have to move mountains, you can go around them – every problem doesn’t need a complex solution. A very basic or simple idea can do wonders
  2. Although, he should but it’s not always a project manager’s duty to intervene and resolve issues like these – anyone can take that step and be authoritative. Authority comes by being knowledgeable and analytical, not only with designation or title.
  3. Learn to put your personal agendas aside, there are times when project’s goal/client needs take the pilot seat.

There’s a very deep meaning to it, but if you can decipher it then you may lead a better life than others.

 “You grow together, you lead in a group; alone you can think of being whomsoever, but it will not turn in to reality!” – P.R.


Author speaks: I’m not here to change the world; I intend to make an impact on one soul at a time. If you like my work, please press Like, or better yet put a Comment; perhaps a feedback. However, the best appreciation of my work will be to Share this with your friends and your social circles (FB, Twitter, LinkedIn, G+, and others).

Thanks in advance!