I ran today about two issues in my current dev team and want to share what happened and what we discussed…
#1
We’re in a remote setup here and the IT is 2.500km away from sales, mgmt, support etc. Might be bad, sometimes might be good ☺. So we had an urgent request last Friday, a developer got blocked and he started. But in the middle of the communication between the dev and the “requester” communciation stopped on the other side and the developer was lost. Not knowing?: is there an answer coming? is it worth waiting? it was announced to be urgent, but is it still urgent? did things change? can I start something else if the other side is already in the weekend?
Bad situation.
He started to work on something else after checking back with the PM.
Just a small incident? Fridays question got answered Monday, but guess what happend monday after lunch?
…. repeat above …
Hence the PM came to me today asked, what to do? how to react? leave the dev waiting? risk dissapointing the requester of the urgent (!) issue?
We went for:
Send a direct honest feedback and make clear that we have to take actions: a) no urgent requests anymore without managers approval; b) if communication drop happens again work will be stopped and not resumed within 48hrs; c) we will not start working on any request without all questions answered first; d) saying “bye. I’ll be back monday/in 3hrs/at 20.00" takes 5 seconds and does not harm. Never.
And finally we discussed general considerations how to handle similar scenarios. And yes, we all know that IT is not an easy business. Meeting business units expectations is always hard. Esp. when you are into a fast growing startup. And after many years fighting with marketing agencies for projects for Adidas and others, I only found one single approach to be guarantee to be successfull:
Others are allowed to fail — we’re not!
Whenever you work in a way that you depend on others to excel, that you ask for at least “good” specifications, that you ask then to provide good use cases, or to deliver decisions in time, or to recheck the delivery on the next day and not in two weeks. IT NEVER WORKED RELIABLY — and you know what’s the problem? These failures by others, were always perceived as our failure!
So no chance to succeed, except you plan with the failure of all parties you depend on and you ensure, that even if they fail, the results of the dev teams work will still be perceived as excellent.
So far about todays events. #2 coming later…