So I have this report who’s extremely hardworking, highly technical and very collaborative. However he/she has a very peculiar habit of working on things no one else knows about. He sees a problem or a personal need and starts spending 30-40% of his time on things which weren’t assigned on the Sprint. Gets all his committed work done by working additional hours, so that isn’t a problem. However I’m concerned that he ends up overworked and loses visibility for things he did. I’ve given this feedback in 1:1s and reviews asking him to bring things to the Sprint board, but he somehow “misses” that repeatedly. Things got heated a couple of weeks ago when he did something and made a “small change” in production without informing anyone. Unfortunately that change broke our core service and everyone went up in arms asking for him to be fired. I somehow managed to get him out of this, but it’s getting difficult to cover up every time. How do you deal with this situation in the best interests of the team and employee?
Pretty crazy to me that everyone was after his head after releasing a bug, that seems like a failure of process. You need to be honest and let them know how their performance is being evaluated, and the steps they must take if they want to grow. If they keep fucking that up, you need to communicate why this is a problem for you, for the company, and for the IC themself, and what consequences may be down that path if unchanged.
Well the core service was down for 20 minutes, which resulted in significant revenue loss. Plus on call wasn’t aware of the change, so blamed it on some other team.
Still sounds like process failure. Why wasn’t on call aware of change? Process failure. Why was eng able to push a change that broke the core service without catching this in a different environment or in reviews? Process failure.
How is his code escaping peer reviews
Peer said they missed it since they weren’t aware of the change. He pushed the changes with some other planned changes. He obviously thought that the changes were too small to make any impact.
Unreviewed code will break no matter who writes it. Ask your team to pull up their socks
Sounds like a person that is operating at a higher level than you are compensating them for. They need more scope.
Unfortunately there have been more than a few issues that they’ve caused in the past (even before I took this job), which has detailed their promotion and growth.
How is it possible for the guy to merge his PR without approval?
He added it along with some other changes and it got missed during reviews. His peer who reviewed said he wasn’t aware of this change, so missed that during merge.
So how is that his fault entirely? At the very least, reviewer should share some responsibility for breaking prod. Also, if your process doesn't have the right gates setup that are automated and rely on quality of manual inspection then that's not the desired pipeline setup. You need to ensure that breaking prod is not this easy. Moreover, this guy exposed how fragile your codebase is and why its so easy to break prod.
Fix your production deploy checks. And enough with that sprint. Do you create a ticket in the sprint if you have to go out and get a coffee too? That takes time.
I did blame it on the production checks and lack of code quality checks to save the situation. However you can’t make a significant change to a system without having a ticket or providing visibility to the team. You don’t need a ticket to get coffee, but you’ll need to provide some visibility if you’re bringing in a new coffee machine, which could plug in and burn the building down. Couldn’t find a better way to work with your analogy.
I agree with lacework. It's always the men in the trenches who get the boot. The higher-ups never do any such production mistakes for obvious reasons. Though OP did a great thing by shielding his report. But the blame lies with the management with not having a production deployment script or process in place. The management should also know whom to give access to production and whom not.
If they’re finishing all the work you’re assigning AND doing extra, what’s the issue? You just want him to create tickets for it instead? I think if you want that you should just ask him what else he’s working on and create the tickets yourself. In terms of making production changes without notifying people, that’s a problem and that needs to be made clear that it’s not okay.
It is about making changes without notifying anyone. It’s like how you made tiny changes in school without worrying about consequences. If not tickets, I’ve asked him to communicate on slack, but that isn’t happened either.
It's a process problem, not person's problem! Anyone can make a mistake. The reason prod was down is because you don't do your work
You need to do your most important duty as a manager and defend this person.
I know. However how do I build a habit of improving his communication? I don’t want to add more processes at an individual level, especially for a senior engineer.
Sounds like a communication problem for the guy, quick slack message and consensus with the team "I'm going to blah blah, any concerns?" Once that's in place now it's everyone's problem. Remember an attack on your guy is an attack on you and on the team. Defend yourself.
I’ve given that feedback too. He’s very active answering other people on Slack, but never discusses his issues. I thought it was a way to reduce insecurity, but he’s too respected on the team to feel that way. I’m a new manager to the company, so I can only try my best without having tons of credibility myself.
Yea if they aren't doing the bare minimum (and fairly low effort) communication then that is an issue. I will say as someone who is kinda this guy, my main reason is company culture is seen as hostile and a strong bias toward the "ask forgiveness rather than permission" approach. It was only until the manager created a safe space (private channel with individuals who can work together instead of against each other) was when I started communicating more. Introspectively, it comes from the mindset of assuming your own solution is better than anyone else's. It wasn't until mutual respect was established that I was able to start to see other people's solutions also work.
OP, Guy is an asset. Channelize his energy.
Tech Industry
13h
1824
How can my idiot brother who does real estate afford this
Tech Industry
Yesterday
9193
China CYBERATTACK on UK ? WTF
Health & Wellness
Yesterday
3054
I hate my f***** life
India
Yesterday
771
Who would win in a war? India vs USA?
Tech Industry
14h
2459
Are tech workers as rich as they think we are?
Why don't you delegate large chunks of autonomous work and stop caring about the board? Putting stuff on the board takes almost as much mental energy as doing the task. There is already 500 aspects to a coding task and the human working memory fits like 5. Now you want to put sprint label, estimate size, pending or backlog status, T-shirt size, preferred toothbrush hardness, .. all of this stuff is ridiculous. You should discuss hiring some Jr ppl and allowing the overworked engineer to delegate work. Also anyone who does anything will break production. Probably the rest of people never change anything? Production is guarded by existing tools and tests, if the person didn't use manual overrides for safety measures, they are not at fault
Do you work on a 1 person team? Planning Sprints are more than putting labels and estimating size
Most software estimation and sprint planning is a waste of cognitive energy. unless you only ever build crud micro services, you can't really predict this stuff so everyone ends up padding things 3x. Cognitive energy and focus are scarce resources and everything that's a distraction is just that.