DEV Community

Cover image for Permission, responsibility, and empowerment
Ben Halpern
Ben Halpern

Posted on

Permission, responsibility, and empowerment

From this Week's Meme Monday

Now, like all comments in the thread, this is a shitpost β€” so I don't want to get too serious, but it's interesting food for thought.

Tornado vs. Bug

The difference between the tornado and a bug is that the tornado is something you literally can't do anything about β€” so if you live in an area that gets enough tornadoes, you might as well just mow your lawn as long as the tornado isn't moments from crushing your house.

However, in software, you can "fix" the tornado. That's why you probably shouldn't be mowing the lawn. You have agency over the bigger issue β€” or do you?

Agency and Responsibility in Team Software Development

This is one of the biggest problems in team software development (i.e., 99% of important software development). It's not always clear that you do have agency to fix the bug β€” and if you do have agency, it's not always clear that you have the responsibility.

Creating Systems for Clarity

So great, let's create systems to make sure that people know that they can and should fix the bug.

However, if we define "responsibility" the wrong way, it is either too many people's responsibility or too few. Too many, and everyone might look at each other thinking someone else will fix it. Too few, and now you've mostly disallowed agency. The select few people who can deal with it will.

Identifying this issue and finding balance is key.


If communication around "can" and "should" are worked out, then empowerment might still be a problem. I think empowerment is mostly about knowledge and wisdom transfer, through documentation, management, pairing, meetings, or anything in-between.

Final Thoughts

  • Getting all of this right is more of an ongoing practice than a one-time solution.
  • While it may be "leadership's" job to ultimately get some of this right, it can be your job to help ask the questions to get everyone on the right track here. Mostly, if people aren't in the right place, it's because they're busy. There's often a chance to raise a hand and see how you can help.
  • Getting this right everywhere can be daunting. Start small.

Top comments (2)

cloutierjo profile image

I think we have to split the tornado bug in two,:

the ef5 that has to be solved rigth now. This one need to have someone that clearly take the ownership of the issue (by themself or assigned by a team lead). As everyone usually agree this need to be fixed quickly it shouldn't get further than a daily meeting to share that someone is working on it. That person need to be clearly voiced (whether self assigned or not).i also think that person's should be empowered to request any help required.

On the other side, there is the ef1. Those should be logged in the issue tracker and prioritised in some way, when it get the turn to tackle them because it's the next task, there is no mowing the lawn to happen. There is one caveat here thought. If you do know that there is a bug and you have to work on related code, please do fix it at the same time. And that's were empowering the whole team is important. I believe every dev as the rights to fix issue and tech debt (ef0?) When they come across it. Blaming a team member for taking more time because they fixed something more than the required task is really going to prevent future software quality.

wrench1815 profile image
Hardeep Kumar

I swear the start of the post where you explained the meme felt like it was a cyno reference πŸ˜‚