Asking for permission
Asking for permission
Join the DZone community and get the full member experience.Join For Free
Discover how quick and easy it is to secure secrets, so you can get back to doing what you love. Try Conjur, a free open source security service for developers.
The decision of whether or not to ask permission comes up a lot in Ops. I’m sure you’ve heard that sometimes it’s better to ask for forgiveness than to ask for permission. As with most things in life, try to put yourself in the other folk’s shoes and ask yourself how pissed you would be if nobody asked your permission. If you are a Honey Badger, skip this step.
Asking permission to make a change, as an example
When it comes to major changes I always communicate the change but I don’t always directly ask for permission – it depends a lot on how much I feel like getting feedback. Sometimes I know what I need to change is the right thing to do and I just want to know if there are gotchas, other times I want to solicit feedback and know if others think there’s a better way.
Two ways of asking that question:
“Hey all, I am planning to shutdown systems a,b & c today. They’ve been removed from service for a week. Let me know if there are any problems this will cause. I’ll be shutting these down at 2pm MDT”
“Hey all, I would like to shutdown systems a,b & c – is this ok? I want to make sure everyone agrees with this before I move forward. I’ll bring it up during stand-up as well”
What’s the difference?
The first is saying “I’m doing this, let me know if I’m going to stumble in the process”. It’s not so much asking permission as asking for advice. The second is saying “I’m not going to do this until we all agree”. I generally prefer the first approach when I can get away with it – but often I will use that after I’ve asked about the change using the 2nd approach. It’s important to make others feel like they have an opportunity to say “hang on, I have a question” and provide input – but in some teams it’s also important to not allow habitual questioners to derail something that needs to get done.
On the other hand, don’t just start using the first approach because you always get questions. If you are getting legitimate questions it may be because what you are doing isn’t being communicated well enough or there isn’t consensus on the team about what you are doing. Respect other folks opinions & make sure they have an opportunity to be heard.
The exception, facilitation
When you are diving a meeting the power is a bit different and so is your need to ask permission. When you are driving a meeting, and in particular if you are asking for a team to participate, you need to ask permission. I run a lot of post-mortem type meetings in my current work and in that capacity I’m constantly asking these sorts of questions:
- Does everyone agree that this is an action we should take?
- Do we agree with the timeline in this post-mortem, are we missing anything?
- Is everyone comfortable that we’ve captured all the actions from this event?
And the list goes on… When you are driving any meeting you have a lot of power over the outcome of the meeting, and so you need to weight decisions more toward the team and less toward yourself. As soon as you say “I think we should do…” it becomes much harder for someone else in the room to stand up and say “I disagree”. Despite that, some people still do.
The other exception, ownership
I don’t usually ask “Is everyone ok if I own this?”. If I want to take responsibility for something and own it’s completion I say something like “If nobody else is already working on this I’ll take it, let me know if you are interested in helping”. Ownership doesn’t have to mean you are going to do all the work, but that you are taking responsibility for it getting done. I haven’t found many cases where folks are unwilling to allow someone to own getting something done, but I have found plenty of cases where people want to have input into how it gets done.
So, go forth, ask permission where appropriate, and ship it.
Opinions expressed by DZone contributors are their own.