Then offer him $1,000,000 for each non-working hours emergency you need him to handle? No? Gosh, we have an executive here who doesn't want to fairly pay his people. What should we do about him?
If you have frequent enough emergencies that this is an issue then you have far deeper problems than your most skilled asset not coming in nights/weekends. Fix those.
If you only have one (or a small few) person that can handle your emergencies then you need to hire more (and better) staff or get a contract set up for people to handle putting out your fires.
You also need to specify the nature of your emergency. Is this a true customer facing liveops situation where the company is losing money? Yeah? And you are on Quora trying to figure out how to deal with your lead? You need to reevaluate your situation.
Is this only a devops or internal situation. Maybe its impacting remote offices on different time zones. Then it isn't an emergency. Its a clear lack of coding standards, test automation and likely horrible or non-existent checkin standards.
If so, I'll take a wild stab and figure it's because leadership is making unrealistic demands on how much crap needs to be developed and by when with no thought to quality or maintainability. So your systems are blowing out. Most of your code base is prototype level not shipping level. People don't write tests or even disable tests that fail so then it eventually all passes.
And the solution to the problem of not going fast enough is to slow down. Slow down and get things done right the first time. Slow down and rebuild your foundation so you can iterate and achieve actual velocity instead of just burn down chart magic fairy dust velocity.
I play a fun game when I get tossed into situations like this. I make every engineer send me an email saying what % of the code base and what % of their code is final shipping quality. Then I sit down with the people that wrote high %s and do a line by line paired programming code review of their last few checkins. Turns out we have very different ideas of "done" and "quality" and that needs to be hammered out before you can fix a team.
If you have frequent enough emergencies that this is an issue then you have far deeper problems than your most skilled asset not coming in nights/weekends. Fix those.
If you only have one (or a small few) person that can handle your emergencies then you need to hire more (and better) staff or get a contract set up for people to handle putting out your fires.
You also need to specify the nature of your emergency. Is this a true customer facing liveops situation where the company is losing money? Yeah? And you are on Quora trying to figure out how to deal with your lead? You need to reevaluate your situation.
Is this only a devops or internal situation. Maybe its impacting remote offices on different time zones. Then it isn't an emergency. Its a clear lack of coding standards, test automation and likely horrible or non-existent checkin standards.
If so, I'll take a wild stab and figure it's because leadership is making unrealistic demands on how much crap needs to be developed and by when with no thought to quality or maintainability. So your systems are blowing out. Most of your code base is prototype level not shipping level. People don't write tests or even disable tests that fail so then it eventually all passes.
And the solution to the problem of not going fast enough is to slow down. Slow down and get things done right the first time. Slow down and rebuild your foundation so you can iterate and achieve actual velocity instead of just burn down chart magic fairy dust velocity.
I play a fun game when I get tossed into situations like this. I make every engineer send me an email saying what % of the code base and what % of their code is final shipping quality. Then I sit down with the people that wrote high %s and do a line by line paired programming code review of their last few checkins. Turns out we have very different ideas of "done" and "quality" and that needs to be hammered out before you can fix a team.
No comments:
Post a Comment