Live data from Hacker News

Lucky Lotto, chaos engineering but for teams

danlebrero.com

21–30 of 38 posts

Re: Lucky Lotto, chaos engineering but for teams

#21

Earlier quoted context omitted.

How are people afterwards. I refuse to use email at work anymore because of the constant phishing tests. Sick of the gotcha mentality.

I am genuinely fascinated how they managed to piss you off so much with phishing tests. (For me email is the backbone of all permanent office communication). Was the frequency too high (reducing the signal to noise ratio too much), or just the fact that they doubt your ability to fall for such a thing?

I was wondering that too. I'm guessing it's frequency. We get them, but they are once every few months. The only annoying thing about them is I have to open outlook to actually report them as I normally use Airmail.

Re: Lucky Lotto, chaos engineering but for teams

#22

I like this - we’ve had “reduce our bus factor” on the to-do list for a while, but not found a way to do it yet.

I don't think this is a mechanism to reduce the bus factor, to me it seems like a mechanism to make people realize what the bus factor is for the team. The actual solutions were not described in the article but I guess that is very team specific.

Maybe you didn't read the whole article then. It totally describes how to do it. The bottom has a nice summary but I'll quote the solution parts of it here:

    The winner will work on some side project. Still work.
Not a solution to the bus-factor of people but a good solution to the "we never get to work on tech debt / platform work because features" problem. This alone is awesome about this.

    Everybody, including product managers, gets one ticket every week, even if you don’t want it.
This, if done right, will result in Product Managers providing a vision and consistent answers to similar type questions. Thus the team can learn to anticipate their answers for minor things (which helps even in week where the PM isn't the winner) and in weeks in which he is on vacation (or wins again) the team isn't stuck waiting for a week for an important question that blocks development.

    Team should avoid delaying the work for a week. 
    Try to bring one of your colleagues to do the task with you or under your supervision.
This is what to do, when you need to break "rule 3" (which states you have to be completely unavailable). It's a soft rule and I think the point is actually to break it a lot in the beginning. The "under supervision" part means, you are teaching another team member part of what made you the one with the bad bus factor. As time goes on, having to break this rule will become less frequent (which is why they wanted everyone to write down when they have to break rule 3 if you ask me)

Re: Lucky Lotto, chaos engineering but for teams

#24

Earlier quoted context omitted.

I don't think this is a mechanism to reduce the bus factor, to me it seems like a mechanism to make people realize what the bus factor is for the team. The actual solutions were not described in the article but I guess that is very team specific.

Maybe you didn't read the whole article then. It totally describes how to do it. The bottom has a nice summary but I'll quote the solution parts of it here: The winner will work on some side project. Still work. Not a solution to the bus-factor of people but a good solution to the "we never get to work on tech debt / platform work because features" problem. This alone is awesome about this. Everybody, including produ…

Keeping aside the insulting nature of suggesting someone did not read the article, here is my response.

I like to differentiate between mechanism to make people realize a problem and actual solutions to the problem. Its very easy to say mentor someone to do your job but if that was doable and easy they would be already doing it. The problem is precisely that there is no real good way to do KTs. Forcing someone to solve the problem is one way to KT, but is that the most efficient way? I would rather gather data about what breaks down and come up with a more efficient KT mechanism.

Re: Lucky Lotto, chaos engineering but for teams

#25
post #4

I heard a good presentation about this. They did it for a team at Google. But it was daily, and you weren't allowed to tell anyone else. You just didn't respond to any requests for that day. But even worse, you could also be assigned the "liar" task. In which case you were supposed to reply to emails but give intentionally wrong information some of the time. But in that case you would tell people that you were the li…

> But it was daily, and you weren't allowed to tell anyone else. You just didn't respond to any requests for that day.

I'm 100% certain I've worked with people that did this. I never realized they were DR visionaries

Re: Lucky Lotto, chaos engineering but for teams

#26
Banks require a planned version of this: you have to take so many contiguous days off at least once a year. But it's an anti-fraud measure, as most of the frauds you can run internally require you to be there to juggle things, and you make the number of contiguous days long enough where such a scheme will come crashing down.

Re: Lucky Lotto, chaos engineering but for teams

#27
This is extremely clever, and something I've never even heard of before, bravo. The closest I've ever seen to this sort of practice in the wild is periodically shifting people around so that more than one person knows how a system works. But more often I've seen no attempts at this, and a mad scramble with KT meetings when someone gives their two weeks notice.

I'm expecting a similar mad scramble when I put in my two weeks at my current company (hopefully within the next two months, interviewing with various companies now).

Re: Lucky Lotto, chaos engineering but for teams

#28

Earlier quoted context omitted.

How are people afterwards. I refuse to use email at work anymore because of the constant phishing tests. Sick of the gotcha mentality.

I am genuinely fascinated how they managed to piss you off so much with phishing tests. (For me email is the backbone of all permanent office communication). Was the frequency too high (reducing the signal to noise ratio too much), or just the fact that they doubt your ability to fall for such a thing?

2-3 a month. Often spoofing other co workers I need to be cautious on all emails.

I use it now only to see if notifications came in from calendar or such. Even then it’s just looking at subject lines.

I then go straight to the app and check for actual message / event.

Re: Lucky Lotto, chaos engineering but for teams

#29
Could you imagine being part of this. Told the company was running DiRT testing or whatever, and then getting fired or punished for listening and following instructions?

Could you imagine afterwards being lectured to use common sense. Also, we have secret corporate policies you need to know about and follow. Resolve that catch-22. Repeat for a decade.

You'd be justified in never trusting them with your life or another loved ones again.

Post reply on HN