Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 542 posts at DZone. You can read more from them at their website. View Full User Profile

Ask for Forgiveness, not for Permission

  • submit to reddit

I gave a presentation at our ThoughtWorks Brazil office in Porto Alegre last way on some of the things that I've learned while working at ThoughtWorks and the first point I made was that it was better to 'ask for forgiveness, not for permission'.

This was something that was taught to me a few years ago and the idea behind this is that if there's some idea we want to try out it makes much more sense to start trying it now and then we can always apologise later on if someone has a problem with us doing that.

This is in preference to an approach where we ask whether we can try out an idea and get told no straight away i.e. we should look to be proactive.

It's really easy to say no to something when you don't really no what it is you're being asked and it seems to be the default answer a lot of the time.

An example of something where this rule may apply would be if we wanted to try writing some tests with a different language/framework to see whether it improves the way we're doing things.

We don't really know whether the new approach is going to be better than the current one so it makes sense to spend a bit of time playing around with it so that we can find out.

Later on in the talk I suggested that on some decisions it makes sense to gather data and then let the client decide what they want to do.

An example of this happened on a project I worked on a couple of years ago where the value of writing functional/unit tests was being questioned.

My colleague Kristan Vingrys came up with a matrix which showed the risks of not testing various features and then let the client decide whether they wanted to take that risk. Alex wrote more about this at the time.

After I mentioned this Caio pointed out that this idea seemed to contradict the idea of asking for forgiveness and not permission and at the time I couldn't really think of a good answer to why I didn't feel the situations were exactly the same.

A week on I think that the difference is that the 'ask for forgiveness' approach applies mainly for new situations where we haven't agreed as a team what we should do and people don't have enough information yet to know whether we should or should not do what is being proposed.

The idea of gathering data and letting the client decide applies more when a decision has been made or suggested and we want to try and influence that decision.

It doesn't make sense to just do what we want in this situation if it explicitly goes against what the client wants but equally we don't want to do something which goes against what we believe is the best approach without at least pointing that out.



Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jilles Van Gurp replied on Sun, 2010/06/06 - 6:26am

It all depends on whether you believe the client is right. I've been in situations where this got kind of murky (i.e. customer was an idiot). In that situation, you either do something you don't believe in (which is what the customer thinks he wants) or you trust your gut feeling. If you can't trust your gut feelings, that is ultimately frustrating and in case they prove right even more so (because you failed to act on them).

You get cynical and you don't do the best job you possibly could. So going with your gut feelings is probably the right thing to do. However, they might still be wrong and gut feelings alone are not very convincing to others. So, gathering data to back up what you want to do is essential for getting people on board, which is what you ultimately need. It's the pragmatic thing to do when you need more people on board than just yourself. 

Ultimately it is all about being able to (in the end) do the right thing or letting the situation spin out of control. Of course this can only go so far. At some point you have to decide if there's still any basis for trust between you and the customer. If there isn't and they flat out want nothing to do with your gut feelings, walking away becomes the overwhelming gut feeling. See above.

Senthil Balakrishnan replied on Sun, 2010/06/06 - 11:03am

"The idea of gathering data and letting the client decide applies more when a decision has been made or suggested and we want to try and influence that decision.

You are right in any experiment gathering data is of highest importance, but not all the time client knows what they want. Rather all they care about is the end result.

This also means lot of openess, but giving overwhelming information where customers can contribute little is not a great use of time. I would rather use customer's time in making business stories, clarifications and business deicision and take control on the technical decision making.



Ronald Miura replied on Sun, 2010/06/06 - 2:19pm

This is just like patterns, principles, and famous people's quotes are used most of the time. People just use them to justify or prove an opinion they already had.

These opinions may be very valid and professional, of course. But what makes an expert make a decision is not a quote from someone, but a (hopefully knowledge and experience-backed) gut feeling. The quote is just to justify this decision to others.

The same way, 'ask for forgiveness, not permission' is just a excuse to do whatever you want. If you are good, you're probably right, or won't be terribly wrong, and people will praise (if it works) or not punish you (if it doesn't). But, if you just *think* you are good, you may screw things up terribly, and not only be fired, but sued (or someone may hire assassins to kill your whole family, who knows...).

Anyway, I'm pretty sure everyone who will follow this advice are experienced developers, so... Great article! Thanks! :D

Gilbert Herschberger replied on Sun, 2010/06/06 - 9:47pm

If I hear that one more time, I'll scream. (Hear me screaming.)

I knew a certain supervisor who said this again and again. He spent the entire software budget of US$1.2M on specifications. He said, "What they don't know won't hurt them." He was wrong. Boy, was he wrong. What they didn't know put them out of business.

Management actually knew the risks and decided to put off a rewrite for another year. He diverted funds without permission away from software maintenance. He justified his action with a wink and a quip, "Ask for forgiveness, not permission". Against company policy, he disregarded the needs of existing customers in order to attract new (and imaginary) customers. He ran the flagship software product into the ground.

He pushed management into a corner. They reluctantly agreed to a rewrite. Now with permission in hand, he produced zero (0) lines of working code. He had spent a lot of time describing what the software would do when he built it; but he never built it. He never built anything. He checked out my code and committed it as if it were his own.

Management was very impressed with him--until I showed them what he did.

The recently out-of-work vice president of the company took me to lunch a year later and explained, "There were fifteen people in the room. Fourteen of them wanted to rewrite the application from scratch. You were the only one that told me no. I didn't know what else to do. So I went with the majority. Now I know you were right."

Yes, I appreciate him saying so.

When I no longer have the trust of my employer, nothing good can come from my continuing to work for them. I resign.

When you "ask forgiveness, not permission," you are taking risk upon yourself. But it should not be your risk. It should be your company's risk. Think about it. Why should you take the risk and someone else get the reward? Instead of working on what you were hired to do, you are working on something else. That can get you fired. If you want to experiment to gather more data and can't get permission, ask yourself, "Why not?" Selling others on an idea is a big part of building software. Do a better job of pitching an idea. Get paid to build a proof of concept. Look for the right opportunity to show what you can do.

If you must proceed, do it on your own time. Do it on your own equipment. Who knows? Your idea may become the next Twitter.

Michael Eric replied on Wed, 2012/09/26 - 3:46pm

Having never engaged Thoughtworks on a project before, I can tell you now that I will never do so, thanks to this article. Well done!

I'm now led to believe that you'd rather do what you want and waste your CLIENT's money to scratch an itch. Amazingly unprofessional. Let's all go to the movies and charge the client too!


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.