I submitted the following talk to two conferences:

How to change things at work: A guide to employee activism

Your company is doing something wrong. You’re shipping broken software, everyone is unproductive and unhappy, and nobody seems to be doing anything about it.

As a mere employee, how do you change this?

I haven’t had much luck at this in the past, but I’d like to have more luck in the future, and I’d like to help others have more luck than I did. So I’ve been doing what any sensible nerd does when confronted with a difficult problem: Reading the literature and thinking a lot.

I’d like to tell you a bit about what I’ve thought and read, some of the things that I’ve done wrong, and how I think we can all do it better.

I then promptly had a panic attack over it. I am approximately the worst (ok, say lower 40%) qualified person to talk about this, but the problem is that near as I can tell nobody else is doing it.

Then I kicked myself.

One of the major points I want to make in this talk is that trying to change things as an individual will basically get you nowhere. The first step of trying to change things is to try to find people who want to change them with you.

So, uh,  why on earth am I trying to solve this problem by myself rather than with other people?

Lets do that then. I’ve created a slack team for discussing these issues: makingworkbetter.slack.com.

The major topic of discussion is trying to figure out concrete steps that you can use to improve your work environment in whatever way you see fit, that do not require you to have a managerial mandate to make changes. However adjacent subjects are very much welcome too, and there are channels for more general discussion.

Also, this is very much not just for developers. That’s where my background lies, but I want this to be a discussion for people from every walk of life, regardless of whether you’re a developer or not, or even of if you work in technology at all! Everyone is welcome.

Instructions for sign up at the end, but read this first:

Code of Conduct

This community is an inclusive space, and everyone in it is expected to abide by a code of conduct.

Firstly, Chatham House Rule applies: Participants are free to use the information received, but neither the identity nor the affiliation of the speakers, nor that of any other participant, may be revealed.

But beyond that, you are expected to behave in an appropriate manner for the space. At the high level, appropriate behaviour is:

1. Kind
2. Respectful
3. Helpful

While it is impossible to enumerate everything that is unkind, disrespectful or unhelpful, here are some specific things that are definitely against the code of conduct:

1. -isms and -phobias (e.g. racism, sexism, transphobia and homophobia) are unkind, disrespectful and unhelpful. Just don’t.
2. Being part of a broken system is not a moral failing. Help people fix their systems, don’t blame them for it.
3. It’s OK not to know things. Everybody was a beginner once, nobody should be made to feel bad for it.
4. It’s OK not to want to know something. If you think someone’s question is fundamentally flawed, you should still ask permission before explaining what they should actually be asking.
5. Note that “I was just joking” is not a valid defence.

Additionally we have a no part time assholes rule. If your behaviour outside this community makes people uncomfortable in it, you may be banned even if your behaviour within the community has been exemplary.

If you have any problems with anyone violating these rules, feel free to point them out to the person in question if you wish to but also please let me (drmaciver) know by private message on slack.

Moderation response will depend on the behaviour. Mild violations will just get a warning and a request to change, but severe violations or patterns of behaviour will be banned.

Joining

We’re using Slackin to automatically issue invites. Go to this page to request an invitation to join.

I use a stochastic time tracking system to track, among other things, the amount of time I spend reading non-fiction (defined as “Any book, essay or paper which is neither fictional nor about a fictional work”.  Comments, social media, documentation and contracts are explicitly excluded). I thought it might be interesting to actually note down what I’m reading when it pings. I thought the results were interesting, so I’m going to share them here.

Warning: This is literally a random sampling, weighted only by time. These are only recommendations in that they’re the things that I found worth spending long enough to get a ping on, but that has high variability – some of these I only really read for 5 minutes but that happened to be when tagtime pinged.

Also, note: I changed the units from 0.5 hours to 0.4 hours yesterday, so some of these are funny multiples compared to others.

• 2 stochastic hours reading Crossing the Chasm
• 1.5 stochastic hour reading Finite Markov Chains and Algorithmic Applications
• 0.8 stochastic hours reading the problem of subjective facts
• 0.8 stochastic hours reading militant anti fascism
• 0.5 stochastic hours reading The Immortality Upgrade (it’s about Mormon Transhumanists)
• 0.5 stochastic hours reading What “viable search competition” really looks like
• 0.5 stochastic hours reading performance measurement and management for engineers
• 0.5 stochastic hours reading democratic authority: a philosophical framework
• 0.5 stochastic hours reading Peter Hintjens’ last hack
• 0.5 stochastic hours reading Slate Star Codex’s review of Albion’s seed
• 0.5 stochastic hours rereading the credibility code
• 0.5 stochastic hour reading what it’s really like to test games for a living

So that’s 5.3 stochastic hours reading books and 3.8 reading essays/blog posts/whatever.

Note: I haven’t tried this. I currently work in a team of one, which makes this a bit hard, but I’ve done a lot of group estimating in the past, I expect to do it again, and I frequently talk to people who do do this sort of thing.

This is a technique that I think would improve people’s ability to realistically come up with a set of tasks which can be achieved in a sprint or other work period.

Premise

• You have a period of work (a sprint) and a set of tasks. You are trying to decide what tasks to schedule for this sprint.
• You have some group of people responsible for estimation and some stakeholders in a room.
• The stakeholders can decide what should get done as long as the estimators think that’s a reasonable amount of work.
• There may or may not be overlap between estimators and stakeholders – it works the same either way.
• You have some unit of estimation (it doesn’t matter what) and a predetermined maximum amount you expect to get done in a sprint. Deciding on this is out of the scope of this game.

The Game

You will need:

• Your tasks nicely laid out in some space on a table
• A lot of cards with numbers on them, corresponding to your estimation units. You’ll want enough that nobody is going to run out of any number.

The game is played as follows:

1. For each task you have to estimate, each person puts a card face down on the task. It’s important that this is not seen so that everyone’s estimate is independent. I think this is probably the most useful part of this game and the one I’d like everyone to try even if you don’t try the rest.
2. Once everyone has estimated every task, shuffle each deck and put it back on its task face up. Make sure you can’t see any card except for the top card.
3. For each task, the  top card of the deck associated with that task is now your estimate for it. Come up with a set of tasks that fits within your budget given those estimates. Remove all other tasks.
4. Now remove the top card from each deck. The new face up card is your new estimate for that task. Remove tasks of your choice until your new total estimate also comes under the total (this may not require you to make any changes). Note: You may not bring in cards you have previously rejected to “top up” any spare points.
5. Repeat the previous two steps 10 times. If you run out of cards (you should, because if you have 10 estimators in the room that’s a very expensive meeting!) reshuffle the decks for each task and start over.
6. Whatever tasks you have left at the end is your plan for the sprint.

What is this trying to achieve?

Basically there are a couple ideas in here:

1. A group of people will tend to do probability matching for the size of a task, so the distribution of card draws is a pretty good predictive distribution for the size of a given task. This is particularly true with the blind draws as people have less social pressure to conform to the group idea of what the correct answer is.
2. Each draw of the cards is then a simulation where you are asking the question “Will we succeed at achieving our goal?”. We always reduce our goal, so the answer is always yes for each simulation run.
3. A smooth Bayesian estimate with a \(\beta(1, 1)\) prior gives the estimated probability of us achieving our goal after N steps as \(\frac{1}{1 + N}\), so after 10 steps we’ll have brought the chances (assuming a correct model) down to < 10%, which seems good enough for an estimation process.

Possible risks:

1. There’s some vulnerability to bad actors overestimating or underestimating tasks without the accountability of public knowledge. It’s reasonably visible when this is happening, but not who is doing it. I recommend trusting your coworkers until this is obviously a problem – vulnerability to bad actors is better than good actors not being able to get correct answers.
2. The simulation is far from perfect, due to a) The fact that people won’t probability match accurately and b) It doesn’t account for correlation very well (although shuffling helps reduce correlation).
3. It’s a bit fiddly and people will get annoyed. On the other hand, it’s a lot less annoying than the sort of arguments that usually happen in these meetings.

Conclusion

This is a bit of a half baked idea, but I think it could work. It has a lot of useful debiasing features built into it, and despite its relative complexity I think it might actually speed up the process by reducing the amount of arguing and deliberation, while still speeding up the result.

Anyway, I have no capability to try this myself, but if you do, let me know! I’d love to hear how it goes.