I manage 20 software engineers divided into 4 sub teams. Every team has good work standards and a high-level of ownership except one. That team has one senior guy and three juniors. Every time there is a critical bug (impacting the business), this senior guy always pushes the work to the next day by saying things like "I can't finish it today," "I will look into it tomorrow," "Do we really need it today?," or "How are we going to test that tonight?" Even when I told him I needed it now, he said he had something else to do and sneaked off when I was not there. He also told these juniors to push back their work as well.
Last week, I told them in a team meeting that I expect a higher level of ownership. If they promise something, they should do it. If there is a critical bug, they must fix it even if they have to stay late.
Today, there was a critical bug and this senior guy said the same thing again - "I can't finish it today. I have a meeting with friends and I have to go." then he sneaked out while I was talking to my manager.
This is not the mentality I want my team to have. I plan to tell him that he has to change his work style or find a new job, and waited for the answer. Is it too direct to do that? Is there an alternative way to deal with issues like this?
In this particular example, the bug prevents 90+% of users from logging into the system. On average, this happens once a month this year while it happened twice last year. Critical bugs are well defined bugs which: 1) prevent users from logging into the system and 2) prevent users from purchasing products — only these two type of bugs.
What we did to prepare every release:
- We had thorough plans where everyone understand the requirements. We actually plan about field name and functions. I implemented for all teams the rule that requirements can't change after sprint start. We also have test cases ready before sprint start.
- We add buffer to all tasks, let's say if we think we can finish something in 1 day, we put 1.5 days. We found that some people always underestimate tasks.
- First deadline was end of Jan - it is when they think they can get it done with tests. This is another rule I implemented in all teams. POs tell us what they want and we tell them how long it will take. So, I told other teams that everything would be ready by 3rd week of Feb.
- By the end of Jan they said all features are done with tests in test cases. We deployed them to our test environment and found a bug where user can't login. It turned out that they did not write all the tests. I asked them how long it would take to fix the bugs and write the tests, they said two weeks.
- First two weeks of Feb, I told everyone that we would only test and fix critical bugs in these two weeks. Again, critical bugs are either 1. users can't login or 2. users can't purchase products in app. Everything else will be in our backlog.
- Week 3-4 of Feb after we released it to customers. We spent this two weeks fixing non-critical bugs (that we log from #4) which are reproducible crashes and other less important bugs like layout and etc. Again, all these fixes have tests.
- We released it to customers with all tests green. After deployment, we found that some numbers are off so we retested everything and found the same issue coming back - users can't login.
- Last time they stayed late at night, I gave them extra 2 days off.