Lucky Lotto, chaos engineering but for teams • Hacker News Board

Re: Lucky Lotto, chaos engineering but for teams

#11

Post by metters » Thu, Jul 01, 2021, 8:51 AM UTC

layoutIfNeeded wrote: post #9

insomniacity wrote: post #3

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.

Ummm, reducing the bus factor is probably the opposite of what you would want.

I guess he/she is using the alteration of the definition of the bus factor:

> There is a rare alternative definition for the bus factor, namely: the number of people who are indispensable for the project. In other words, it is the minimum number of people who are a single point of failure. If using this definition, then a high bus factor is considered a bad thing (since the loss of any person included destroys the project), and zero is considered the ideal bus factor.

Source: https://en.wikipedia.org/wiki/Bus_factor

Re: Lucky Lotto, chaos engineering but for teams

#12

Post by eru » Thu, Jul 01, 2021, 9:26 AM UTC

jedberg wrote: 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…

When at Google, we did the simpler version (of not replying) for our DiRT week exercises. DiRT stands for disaster recovery testing.

Re: Lucky Lotto, chaos engineering but for teams

#13

Post by eru » Thu, Jul 01, 2021, 9:27 AM UTC

Cthulhu_ wrote: post #8

insomniacity wrote: post #3

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.

The challenge there is that you need to hire and train more people than you have right now, and hiring is difficult. I mean probably not so much if you have a lot of money. I'm currently in a high bus factor job, I'm the only developer on the UI - our CTO can do some small jobs here and there, but nobody's touched or even looked at the new UI I'm building (Go + React). I want to be able to leave, but the way things a…

> I'm currently in a high bus factor job, [...]

That's actually a low bus factor, isn't it?

https://en.wikipedia.org/wiki/Bus_factor

Re: Lucky Lotto, chaos engineering but for teams

#14

Post by physicsgraph » Thu, Jul 01, 2021, 9:54 AM UTC

I have a different approach for create a similar outcome: everyone rotates projects on a periodic basis. The period of change is longer than a sprint duration so as to give people time to acclimate to the new-to-them project.

[0] https://graphthinking.blogspot.com/2021/06/periodic-rotation...

Re: Lucky Lotto, chaos engineering but for teams

#15

Post by ckdarby » Thu, Jul 01, 2021, 11:12 AM UTC

Cthulhu_ wrote: post #8

insomniacity wrote: post #3

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.

The challenge there is that you need to hire and train more people than you have right now, and hiring is difficult. I mean probably not so much if you have a lot of money. I'm currently in a high bus factor job, I'm the only developer on the UI - our CTO can do some small jobs here and there, but nobody's touched or even looked at the new UI I'm building (Go + React). I want to be able to leave, but the way things a…

They'll survive. It is common to overvalue yourself when leaving the company but the reality is the company will adapt just like it always has and if it doesn't it would have died even with you there from choices that didn't allow it to adapt.

Just accept the offer and move on. It is the best thing you can do for a company like this.

Re: Lucky Lotto, chaos engineering but for teams

#16

Post by toss1 » Thu, Jul 01, 2021, 11:42 AM UTC

Great idea, similar to what I understand is done in accounting. The idea is to force everyone in the actg dept to take regular vacations of several weeks, requiring others to cover their tasks. This is so that others can uncover financial sleight-of-hand to prevent embezzling (or at least structure it such that successful embezzling requires a larger conspiracy, increasing the likelihood of getting caught).

Re: Lucky Lotto, chaos engineering but for teams

#17

Post by treeman79 » Thu, Jul 01, 2021, 11:46 AM UTC

jedberg wrote: 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…

How are people afterwards.

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

Re: Lucky Lotto, chaos engineering but for teams

#18

Post by GuB-42 » Thu, Jul 01, 2021, 11:55 AM UTC

physicsgraph wrote: post #14

I have a different approach for create a similar outcome: everyone rotates projects on a periodic basis. The period of change is longer than a sprint duration so as to give people time to acclimate to the new-to-them project. [0] https://graphthinking.blogspot.com/2021/06/periodic-rotation...

Your approach is lawful, the one in the article is chaotic.

Your approach is planned, with well defined onboarding and offboarding and with a report in the end. Personally, I hate it just for the idea of having to write a report.

The article approach in unpredictable. At the last moment, you know you are not part of the team anymore, and all communications are cut. People have to take over even if you are in the middle of something. It also involves managers. I prefer this, if anything, just because there is no report to write except if things go wrong (i.e. you break the "no communication" rule).

The chaotic version of your solution would involve periodically drawing two team members, including managers and having them switch teams immediately. For each individual, the period of change would follow an average but be random. And no reports :)

Re: Lucky Lotto, chaos engineering but for teams

#19

Post by newswasboring » Thu, Jul 01, 2021, 12:14 PM UTC

treeman79 wrote: post #17

jedberg wrote: 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…

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?

Re: Lucky Lotto, chaos engineering but for teams

#20

Post by jweather » Thu, Jul 01, 2021, 1:13 PM UTC

layoutIfNeeded wrote: post #9

insomniacity wrote: post #3

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.

Ummm, reducing the bus factor is probably the opposite of what you would want.

Reducing the impact of the bus factor, then. Kind of like turning down the air conditioning... which way does the thermostat go?