Recently I got myself into an unhelpfully stressful situation at work. My team was doing really well, but the larger project was hitting some snags. I was approached by one of the people from the business side to see if my team could help out with a small website as well as our current workload. This extra work was estimated to be a couple of weeks work for one person, and it could be done on the back burner. I asked the team how they felt about it, and as it seemed fairly straight forward they said yes.
I rearranged my plan a bit to free up one developer once their current task was done (in a day or two) and, I was going to get a new front-end developer as well, so everything was going fine and we felt great to be helping out, going the extra mile! We only needed to recieve the designs, which was a “simple” landing page and a form page.
A day later (Thursday) I get called in to an “Emergency meeting” – and I was told that I had to be there, so before I get to the meeting I gather that there is a problem! The designs have not been approved and the project manager wanted them delivered by the design team no later than tomorrow, otherwise the development team (i.e my team) wouldn’t have a full week to complete the work and get the site in production by next Friday. Whoooooa! – What happened to the “two weeks on the back burner”? This is where I made my first mistake – I said nothing! I still felt that the team could easily complete the task (after all, it was a simple website) and, if we were getting the designs the next day we would still have a couple of days to deliver. So I started lining up all the stuff we needed. Arranging a meeting to set up content, quickly getting the front end developer on board and telling the other developer to drop what he was doing and prioritise this task. It was now Friday, and as we had to start first thing on Monday morning, I was running around like a blue arsed fly sorting everything out. I asked the infrastructure team for help to get this to production. The answer “That’s impossible! It takes a week to get the public facing urls.” The content guy came back to say “Translations can take a week to get back.” CRAP! My first feeling, naturally, was I had been let down by everybody, and no one is as dedicated as my team! My second mistake
After stressing about it I escalated it during the weekend, a meeting was set up to see what could be done (the following Monday) and if the delivery date could possibly be pushed back. After the weekend, spent agonising about the whole mess, Monday arrived and the project manager is contacted to see if there is any possibility of pushing the delivery back a couple of days to get everything ready. The answer: “Oh yes, no problem! The original date was something I set as I wanted the designs done quickly.” First reaction – anger! Then I started to think what my part in this whole mess had been, and I came to an ugly truth. It was my own fault! I had made two big mistakes – Firstly by not saying anything when the delivery date was suddenly changed I had committed to something that I did not have full control over. What I should have done was to say: “Okay that’s not the time line I have been given, and as it has dependencies outside my team I will need to check when these teams can deliver. Can I get back to you with an estimate? ” This would have eliminated my second mistake, which was to not account for the things outwith my control. Naturally all the other teams were really busy and I should not have made the assumption that they could help me out without checking first.
This whole episode made me think of something I read a couple of years ago in The clean coder by Robert C Martin. “The cost of saying yes”
“Most of the time we want to say yes. Indeed, healthy teams strive to find a way to say yes. Manager and developers in well-run teams will negotiate with each other until they come to a mutually agreed upon plan of action. But, as we’ve seen, sometimes the only way to get to the right yes is to be unafraid to say no”
As developers we have this inability to say no, it is seen as a failure or being negative. but sometimes saying no is the correct decision.
Luckily this turned out to not be as big of an issue that it was in my head, and I will now go and re-read the clean coder again.
Until next time, be a clean coder and don’t say yes if you cant commit to it. I highly recommend giving the clean coder a read, it is as an important book as Robert C Martin’s legendary clean code
Recent Comments