Whenever I see these google SRE articles, I kinda reduce the message to "don't be a hero in a cost center in an org with nearly unlimited resources."<p>If you're in a profit center, you might get rewarded for your risk.
I imagine a conversation with this individual as team lead would go something like this:<p>"So, you worked overtime to save systems across the planet from crashing due to a botched update?"<p>"Yes, sir. We're 'Site Reliability Engineering', after all."<p>"And people in airports don't have to sleep on the floors because airlines can actually schedule flights?"<p>"Yes, sir. Site Reliability Engineering, at its finest, sir!"<p>"No, you played the hero. That's bad for the team and normally for you, really. You should have let it break."<p>"But our team...is 'Site Reliability Engineering'?"<p>"You should have let it break."<p>"But, Site...Reliability?"<p>"You're fired."
There are people so addicted to this that they will <i>literally create problems out of nowhere</i> so they can pull some heroics and save the day, always with high visibility from management. Seen a person advance pretty far in their career this way. Until management stops incentivizing this behavior, it won't stop. This is a management issue - which seems weird because this writing seems targeted towards IC's.
You don't want heroes at large companies with top down product management. You need heroes at small innovative startups. This write up is more of a documentation on the stagnant culture inside google
"No matter how many hours they need to work."<p>"No matter that they need to work evenings and weekends."<p>I don't call these people heroes, I call them idiots.<p>Also, not being able to copy/paste text from text slides is a pretty terrible design choice, but we shouldn't be surprised knowing what the source is.
In my experience being the hero is fantastic … until you want to go on vacation, have a sick day, change teams, or get promoted. Hard to promote someone irreplaceable.<p>Always code (or mentor) yourself out of the job and let others play with your legos. Even if they do it wrong.
The last slide says "let the system break".<p>I strongly suggest that after that slide, there needs to be a whole series of slides about how to make it so that it's ok to let the system break. If you haven't already done the hard work to make your stuff resilient, "let the system break" is a recipe for blowing up customers, damaging reputations, and hurting people.
Heroism is what you do until you manage to secure the headcount and hire the team that lets you run things smoothly.<p>In the real world, getting approval for headcount can take 6 months, hiring 3, training another 3.<p>So you need to sustain heroism for a year without burning out.
I really dislike the way this slide deck is written. It's rewriting a failure of management (bad project planning, too few people for the workload) and presenting it a failure by all the team members.<p>"The Hero decides that, despite this, ..."<p>"No matter what they're told about not doing this."<p>"The team doesn't realize..."<p>"Heroism is low risk, and easy to do."<p>"Help the Hero figure out what they should do instead."<p>"But the Hero won't let it go."<p>I suspect the likely scenario that prompted this document to be written was something like a manager facing low morale from his team, and has just been asked to explain why there was a catastrophic failure that he hadn't communicated upwards. Likely, he hadn't been doing his job properly, had no idea how much work his team was actually doing, the team was massively overloaded and worried about the job culls in other departments, worried because their boss kept saying things like "this was due yesterday", and so had been doing everything possible to stop the proverbial hitting the fan... and one day it reached bursting point, and they simply couldn't cope with all the work, despite already being forced to do overtime. Maybe some of them had even quit as a result, and complained to HR about the work-life balance in the team.<p>But the team leader can't possibly be at fault. This is the management spin on it: it's all the team member's fault, and the poor manager had no idea what was going on, not because he was a terrible manager, but because the team had been deliberately hiding all the work they were doing from him, they didn't want to go home to their wives and kids, but were choosing to spend their evenings working on secret projects to stoke their own egos or deal with their own insecurities, and concealing all the extra work from their managers.
This article highlights many pitfalls but fails to explain "how to practice heroism effectively".<p>For instance, a team member might notice a recurring pattern and repeatedly save the SLA by addressing it immediately. While this quick fix is heroic, it should also be escalated for a long-term solution. This way, the hero tackles the immediate issue, and the team ensures that such heroism isn't needed in the future, and so on.
What a bombastic title—heroism is bad.<p>I’m thinking this whole piece is slanted to correct some other toxic or difficult to manage culture issue.<p>Getting to examples quickly saves the piece. Sounds like there are some gung-ho youths happy to be working at Google and they need some mentoring.
Heroism is a good thing I believe, as long as it is not applied systematically.<p>Example 1: A client has a deadline and a malfunction or unpredictable limitation of our product is in their critical path. A few people put in collaborate effort, meaning working extra hours a few days, to help them out. Later the customer is happy and the boss throws a celebration drink.<p>Example 2 : an ICT member got a message that could indicate a security breach over the weekend. He logs in and sees more suspicious activity. He takes first actions (disable all logins/access of certain criteria) and calls head of ICT.
Did any of the commenters read the slideshow? Heroism is bad when it covers systemic problems.<p>Heroes are great -- SREs who rise to the occasion to prevent horrors are appropriately rewarded and congratulated for their work.<p>But when a product relies upon heroes to continue operating, you are in a dangerous situation. That's how major outages occur; the hero goes on vacation or decides to let it break this time and the cascade of failures causes huge amounts of damage, where letting the system break much earlier would have made it clear to the development team that there is a major gap in the intrinsic reliability of the system.
could Google stop the "heroism syndrome" and give us the source-code for their deactivated services? even if they aren't parsed to their heroic servers and it's about being self-host-able by non-heroes
Not sure if heroism is bad.<p>[1] All teams should have a Jordan, a kobe, a shaquille or a combi. One needs A players and supporting cast. It is not the culture or the org who decides upon the evolution of the heroism. It is the hero who builds a team around him/her.
[2] the scrum or agile saga that promotes that all team members should be able to do what all team members do is just excel-minded-nonesense. Cant win championships with only goalkeepers, or only midfielders. Cant prep one to be good in both either during a lifetime.<p>Probably google wants weat crops that always look alike and are predictable?
Total junk. Don't blame the "hero" for their behavior, blame the management for not thinking ahead and making sure the problems didn't fester, blister, boil over to the point in which babysitting the systems over the weekend became necessary.<p>No "hero" ever does this work without trying to plan for it ahead of time. "Heroics" are necessary when the system let them down and stop letting long term thinking and planning account for problems.