It's also easier to give forgiveness than permission, especially in an institutional context. Forgiveness after the fact doesn't imply approval of the act the way permission beforehand does.
One of the criticisms I've often heard of Arab managerial and military-command culture (at least in conventional organizations) is that it strongly disapproves of individual initiative; in such a case, asking permission might satiate the cultural drive for top-down micromanagement while still allowing subordinates to contribute their local knowledge to the decision-making process.
Hasn't initiative been a hallmark of a successful military for much of history? I've heard it put forth as a chief reason for the success of Romans (phyric wars), French (Napoleonic wars), Prussians (Franco Prussian war) and Germans (WW2) to win engagements against their extremely rigid enemies.
Indeed. Which is, according to some quite convincing arguments, one reason Arabs have not done too well in modern conventional wars. Especially when going up against e.g. the Israeli military, which takes junior-officer autonomy to an extreme even by Western standards.
See "The influence of Arab culture on Arab military effectiveness", Kenneth D. Pollack (https://dspace.mit.edu/handle/1721.1/11219). Pollack pulls up examples that don't even involve materially superior Western armies, such as conflicts against ill-equipped Iranian, Kurdish, or Sub-Saharan African forces.
An excerpt is below; what I can say from my understanding is that upper echelons of officers are deliberately understaffed, and superiors are encouraged to give general objectives (or sometimes even just areas of operation) to their subordinates rather than detailed orders; and much planning and communication is done peer-to-peer among officers of the same rank.
========
Among the many lessons that can be taken from the history of the Israeli Defense
Force (IDF) in combat, one key issue is the high degree of officer casualties, often
proportionally up to three times higher than enlisted casualty rates. Hence, leaders in the
IDF regard initiative as not just a point of pride, but an absolute necessity to overcome
leader casualties during battle. IDF Officer Candidates undergo training designed to force
them to develop initiative (some of these training techniques will be recommended in the
final chapter). In training, it is also emphasized that the commander will accomplish his
mission according to the general spirit of the command. Additionally, IDF standing
orders promote initiative (as well as aggressiveness an ' offensive spirit):
1. When orders can't get through, assume what the orders would be.
2. When in doubt, hit out. The short route to safety is the road to the enemy
hill.
The stat about 3x officers casualty rate is surprising, I would have imagined the enlisted would generally become cannon-fodder (for lack of a less demeaning word). I guess that's what makes the Israeli forces unique.
It's more common than you'd think actually. Another surprising one is the English army in WW1 where the officers mostly came from posh private schools, statistically they died in larger numbers than normal soldiers. It's intuitive to think it would be the reverse in that meat grinder.
Not so surprising. Same as how elite forces usually have higher casualty rates in wars - because they always go to where things are worst. No guarding a quiet front for the 101st Airborne or the Golani Brigade, and no hunkering down in a foxhole with a machine gun for the platoon lieutenant.
Yes, but they have permission to use initiative. Scope for initiative is expressly granted by superiors, with explicit bounds. And that freedom is expected to be used. It is part of the development of junior leaders in the military; they are given tests which can only be solved by lateral thinking.
That's not how I've seen "ask forgiveness" used in industry. Usually it's a self-confident maverick who goes off and does something that breaks the rules of organisation or process. I did it once; I thought I was doing the company a favour. Information Security came down on me like a ton of bricks, with good reason, and I nearly lost my job. There was no forgiveness. The Director ensured that it was well publicised and a lot of people learned from my hubris.
The phrase is a crock and should never enter your mind. If you're sure Your Way is best, ask for permission or get consensus. If you get neither, lodge your protest with your superiors and get on with something else. Then in a year's time perhaps people will look back and consider you a visionary, or a hot-headed fool...
Your experience serves as a valuable lesson that everyone should keep in mind. If you aren’t completely aware of the risks you’re taking you should be wary. Information security is something lot of folks are oblivious to in even the basic sense. So I completely understand how your situation happened and why you have an aversion to it. However, I still think there’s value in the phrase but it should be used judiciously. There are plenty of low/non-risk situations where the obstacles are entirely bureaucratic.
That said I think your cautionary tale is really valuable and your uncompromising view toward the phrase actually serves to emphasize how serious everyone should take it. If I were you I wouldn’t change a thing. Actions can have real and sometimes dangerous consequences.
We should always try to understand what we’re putting at risk (as much as we can) so at the very least we can weigh the unknown risks even when asking permission. If you can’t even list the risks off mentally that’s probably a good sign that you should stick to asking permission.
I think this was based on corporate policy and maybe due to the field you're in. It's also symptomatic of a rigid corporate structure that prevents employee initiative without the expressive permission of executives. If you're a large institution, especially a bank, and they have a lot of oversight & compliance concerns, then that explains your hesitation, if you don't have a lot of compliance concerns & regulatory issues, then this was a red-tape situation which was not warranted in your organization and very likely can lead to the end of a large company when flexibility is not possible. Companies like facebook internally with regard to features would not grow as it has, and to some degree even companies like google would not be where they are today either. To my understanding, many organizations grow beyond expectations when they don't have all the red-tape that other companies do. Valve for instance, they have a flat management structure and they're people innovate like crazy, and they hire people who are actively innovative, which often require initiative / independent thinkers.
In retrospect, it seems likely that no amount of officer genius could have won the Civil War for the South, but without it, they would have been completely crushed.
Perhaps the entirety of the European continent (or most of the world re: Germany) fighting back meant the war was essentially unwinnable no matter what, but perhaps the successes they did have were due to the process they used.
Right, but if we're going to wank poetic about the success of Auftragstaktik it's worth remembering that throwing people at the problem was repeatedly and conclusively even more successful. Should we draw deep business practice conclusions from either of those? The whole thing seems a bit silly.
Success is based on many factors, and if you're evaluating military cultures and command styles you have to control for those variables. In individual battles or campaigns with equal forces and materiel, German and Napoleonic and Israeli tactics have been very successful, it's just not enough to outweight any disparity in forces.
I do agree that trying to draw business practice conclusions from the very different military setting. This includes the quote of the OP.
Well they over extended themselves eventually, that doesn't mean they didn't dominate the battlefield early on. The Germany was very successful in the Franco Prussian war.
I could have used the US as an example too, as well as Russia by the end of world war 2, they went on to have a bit too loose of a command structure with their nuclear arsenal.
I feel like that's part of the strategy though. Arguing that the strategy was sound but they just overextended themselves seems facetious; didn't the strategy cause them to overextend themselves? Therefore, wouldn't it be fair to argue the strategy was doomed from the start?
I don't know that I agree with any of this argument trying to relate business practices to military practices -- civilians and soldiers have some fundamental differences -- just trying to imagine it philosophically.
In this context 'initiative' means explicitly not the generals, but on all lower levels, extending as low level as reasonably possible - though often not to the individual soldier level, but to the smallest unit (given that time/era/technology/tactics) that can be effective on it's own and is expected to stay together at almost all times.
In WW2 that generally was up until the squad level, with a focus on NCOs (non-officers leading ~10 men) taking initiative; in earlier times infantry required a bit larger formations to be able to fight efficiently, so initiative of relativerly lower-ranking officers.
Generally, junior officers or higher-ranking NCOs. Some people are too narrowly focused to understand the big picture; upper management is too focused on the big picture to micromanage. It's up to middle management to both have a grasp of bot the overall goals of the organization, and their specific organizational unit's capabilities and tasks.
I think this is more an American thing and I don't see much of it here in Norway (arguably another western country). A lone ranger will not find much sympathy even if the solution works.
Not only does it apply in a company setting but if you were to build something on your property without permission from neighbours / government you will have to tear it down and face the fines even if in the end no one have an actual problem with it.
Most even vaguely urbanized areas in the US have this, but it's a typically a municipal-level (county or city) thing, so yes, there are sizable chunks of the US that have no zoning or building codes, but they're out in the boonies and typically in areas where people live on large parcels, so there are fewer problems with neighbors complaining, since they might not even be able to tell from their own property. That doesn't mean you can build a factory or nuclear plant necessarily, since those kinds of things will typically require state- or federal-level permits, but it does mean you can put up a fence or a pole barn on your own land without asking anyone's permission.
It is, and it's what I'd be most familiar with. A lot of this stuff is driven by central government, but implemented and enforced at a local level. It'd be harmonised throughout the state.
It would mostly tie in with European environmental regulations too.
That's not to say these regulations are flauted from time to time, or if you were out of site on your own estate you could do what you want. But there have been cases of people being told to demolish their houses.
Here's an example [0] where it should be clear why planning laws are needed ...
That seems more like an example of how the "planning laws" are a nuisance and totally out of step with reality. If there were really some harm in the house being there, surely somebody should have challenged it before 10 years. What harm is the court redressing in ordering it torn down?
I think in my culture back home (Pakistan/India), asking for permission is really just to show respect and usually easy to obtain.
For example, here in the US teenagers usually tell their parents that they are going out. In my culture, teenagers usually ask their parents if they can go out.
And I cannot remember ever been denied when I was teenager. I think if I had simply told my parents that I was going out, they would have stopped me to ask more question or even stopped me from going out.
I think what we're talking about here is "Power Distance Index" [0], one of Oersteds most well know dimensions, covered in Malcom Gladwell's "Outliers".
It's the degree to which people in a society capitulate to power and to which those in power are aloof to their subordinates.
There are some very interesting patterns in that measurement indeed.
In my fairly brief working life in Japan (5 years at a school), it's not uncommon to do things without permission out of respect for your supervisor. That seems strange, but if you know that you must do something, but that your supervisor must say "no", then doing it helps the supervisor save face. They can yell at you publicly for doing the"wrong thing" and then nobody can criticise them. You've been yelled at and if you look sorry (it helps to cry a little bit), then everybody will forget about it and nobody will blame you after that.
Weird dances like that are one of the reasons why it's difficult for foreigners to fit in :-)
>Weird dances like that are one of the reasons why it's difficult for foreigners to fit in :-)
Western cultures have them too but they are so ingrained you don't notice them. This video highlights some of the more interesting ones (e.g. refusing to accept an apology being offensive): https://www.youtube.com/watch?v=pfO9gL28pAs
Yeah, that's very true. It's an interesting talk as well. One of the examples is highly codified in Japan. If you offer someone something, they must refuse. Then you must offer it again. Then they must accept it. Any variation on that leads to one of the parties being really upset :-).
One of the cool things about this is that regifting is completely accepted in Japan. Because you must accept what's being offered, it is considered normal to make a gift of it to someone else if you don't actually want it. This is one of the things that I trip over often. Quite frequently if someone offers me some food, I'll think, "Oh I have a lot of food in the house. I can't eat that." But you have to be thinking, "Who can I give that to". It's weird, but I also like it because people are constantly giving gifts (to the point where it's rare that I don't receive something almost ever week).
> This video highlights some of the more interesting ones (e.g. refusing to accept an apology being offensive)
I didn't catch that. He only offered a somewhat contrived example of it being rude to "take back" an apology (which is, of course, not a thing) after being told it "wasn't owed".
His thesis was, AFAICT, that this is an example of empty gestures, that we don't really mean it.
However, that falls flat with the apology example. An apology that is actually sincere isn't something that can be taken back, so it could only be empty if it were insincere, and in his anecdote, he did not even imply insincincerity.
He talks about the words not making sense when analyzes, which I assume is in reference to the fact that "you don't owe me an apology" sounds like a rejection of the apology, but, it isn't. If it's truthful and can be interpreted literally, then no offense was taken in the first place. If it's untruthful, then offense was taken but the apology was accepted (and presumably the insincerety was a lie told to spare further bad feelings). Either way, no offense remained on the part of the apology recipient.
None of that was empty gesture, and there was only one opportunity for lying to spare someone's feelings (though this was not called out in the video).
The rest was about Japan and the old Soviet bloc.
I think you need to come up with a better example of a "weird dance" in Western culture, preferably with more observers than just the (usually two) participants.
It's also that asking for permission allows the manager to "preventively" re-arrange the project/effort/whatever you want permission for, and thus leads to failure.
You have to dig deeper and ask what makes asking for permission difficult.
In an institutional context when we ask for permission from higher ups, especially publicly, we put them on the spot to clarify some rule or make a pronouncement which rules will be enforced and which won't. Sometimes you have to break rules, or perversely are even expected to, just to get things done. Asking permission means the boss has to tell you that you cannot break the rule officially, even though they know the rule has to be broken for the task to be accomplished. So not only do they deny the permission, they also resent you for forcing them to make the pronouncement and preventing anyone in the near future from accomplishing the task at hand efficiently. In other words even as they respond with "No, Peter, you cannot bypass filling out 10 TPS reports just to fix this bug" in their head they are thinking "Why the fuck didn't you just do it. Why did you have to ask me about it in front of everyone..."
Large power structures usually have rules you cannot break, you can break if you want to, and perversely enough, you should or are expected to break. Winning or losing the politics game often comes down to simply understanding which rules belong to each set.
Sometimes the asking is not the hard part, communication channels might be open, but decision making is always put on the business perspective which might be a little shortsighted on some regards.
Case in point, years ago we used CVS for version control. I had a strong feeling that if I asked to research how could we make the switch to git, it would be allowed but relegated to the back of the backlog, which usually means never to be done. So I did it without asking permission in between tasks, and when I proposed we switch to git I already presented our many dozens of repositories in a git server with the full history preserved. I didn't even need to ask forgiveness.
A lot of things in orgs usually boiling down to someone championing things and just getting it done.
Managers are very wary of comming any resources to ground breaking things since they are unproven. I’ve experienced this multiple times. If you feel strongly about something, just go do it!
In my experience, the person you're asking for permission is a middle manager, who will almost certainly see your request as more power for them and less power for you, aka office politics. The minute they give you what you want, you don't need them any more, which is less power for them, so why would they do it? Professionalism? pfft!
Are you misusing the term “middle management” to mean the bottom-level managers? Or are you saying that most requests for permission are going 3 levels up?
Most requests for permission are probably going to direct managers at the bottom because that’s who most employees report to. I can’t imagine taking every request to my director. He’d ask me why I’m wasting his time and tell me to do my job.
And this then allows for consequences to be enforced not as a result of breaking the rules but as the result of something that would never be tolerated being made into a rule. For example, being more likely to punish people of a certain gender who breaks some arbitrary rule that needs to be broken for work to be done (though not being so much more likely to do so that they could convince a judge). This is why I think the appropriate response in these cases is that everyone should seek permission, regardless of the extent work slows down, and that firing people for doing so should be see as a violation of discrimination at work (because while it is not directly discriminating against protected classes, it enables a rule enforcement system that makes it trivial to discriminate against protected classes).
The description you gave is of a dysfunctional organization.
If it's expected that a rule is to be broken to get a task done, the risk of the backfiring will be borne by the rule breaker. If i am am employee, i will not risk breaking any rule that i have not gotten in writing from somebody higher up that they're OK'ing.
Or, i will have to be paid more for taking on the risk.
> The description you gave is of a dysfunctional organization.
True but irrelevant. In my experience organizations are just like people in that every single one of them is dysfunctional in some capacity. You find ways to work around the dysfunction when it can't be fixed and life goes on.
At risk of using management lingo, there's a big difference between one-way-door (decisions which are hard to undo) and two-way-door decisions (decisions which can be easily undone).
Asking for permission (or asking anything), in a complex domain is difficult and always carries a cost.
In two-way-door decisions, forgiveness IS easier. But an incorrect, one-way-door decision is hard to "forgive" ("accountability" and the like).
Well-run companies (e.g. Amazon) understand this very well and have processes to only require permission only in one-way-door decisions.
This is such a terrific point. Let's think of forgiveness and permission approaches as useful tools that work best in context, that do not have moral characteristics on their own. I wish this were at the top because it should be the context for every other top level post I've read.
I had never heard the phrases "one-way door" and "two-way door" in decision making until yesterday, and now this is the 2nd time I've seen it. The person who mentioned it to me yesterday works at Amazon. Funny coincidence...
I'm curious about how one decides whether a decision even is one-way or two-way? I can think of some contrived examples (demolishing a building is one-way, deciding where to get lunch today is two-way) but what about more complex and realistic examples? Is it that the cost to reverse that decision is so high that it's effectively a one-way choice? And can you make a one-way idea into a two-way idea in some scenarios?
I think it's more of a guiding principle rather than a steadfast rule. Like I would think "releasing code to production" is a one-way door. Even though it can be undone, it can have pretty bad consequences and breaks existing protocols. On the other hand "researching a new topic" cannot be technically undone, but it is a two-way door because there is not any harm if it goes wrong and you're working in the best interest of your team.
I think it's the difference between getting on a plane (you have no option to get off) and getting on a bus (you can get off and take the other bus back at any stop)
I have seen this abused. A team member does whatever she thinks is best, and the rest now have to tag along because to communicate to all stakeholders that it was not a team decision and needs to be revisited is too costly.
That can be seen by some management as "getting things done". And quite often that person feels vindicated when her solution works.
But that person is not able to realize the cost of the mistrust of the team and detachment of the job nor to think about the possibility that the other solution not only have worked, but it will have been way better.
At my job, I have to arbitrate between team members and teams. I will flag anyone that decides to "ask for forgiveness instead of permission" and notify their manager. I don't like to work with people that think that they are so good that don't need to present their arguments like the rest.
So when going for forgiveness instead of permission, it is wise to think:
a) If your way is so good, you should be able to get what you want with arguments.
b) If you force everyone else to follow your way without their consent, you are not a leader you are just abusing the system.
c) That it works does not mean that was the best option.
d) That other people can also have done the same does not mean that they are worse than you, it may be that they see a bigger picture that you can't see.
It is still possible to go for it. But you need to be accountable for the consequences.
Not disagreeing, but some points from a different perspective:
a) Arguments don’t work because team doesn’t listen and/or doesn’t want to change because they wish to stay in their comfort zone.
b) The responsible manager is incompetent and/or does not understand the things he/she’s responsible for and/or is a micromanager which kills any spontaneous action.
c) Those who see a bigger picture do not care to or cannot explain it and/or keep it a secret.
d) Sometimes the best option is to just do it (and improve it later) instead of going through a slow and energy consuming process of gathering consent etc.
> a) Arguments don’t work because team doesn’t listen and/or doesn’t want to change because they wish to stay in their comfort zone.
It is a problem if there is no communication. To bypass all formality only hides the real problem is not solving it. It is not easy to know who is right. That is part of my job when one person is in a fight with the rest of the team my job is to listen to everybody and help to get a decision thru. I have seen all combinations, the team is right the lone ranger wrong, the lone ranger is right and the team is wrong, all are right and one path needs to be decided, all are wrong and I help them to find a different solution.
> c) Those who see a bigger picture do not care to or cannot explain it and/or keep it a secret.
Again this happens and it is a big problem that needs to be addressed. To hide it doing things rogue stile only perpetuates the problem. Sometimes is better to get everything to a halt until information is shared than to tag along for years of painful fights.
> e) Software architects
Yes. I am one. And my main problem is the arrogance of other architects, not the managers, product owners or developers in the teams. :P
You're right that the root cause needs to be fixed. My points are within an assumed context of a dysfunctional environment where the status quo is either actively maintained or simply neglected, and the person bypassing formality is only doing so because there are no other options available.
As greedo mentions in another reply to my points, you really can't have "lone rangers" on a team who do this without a valid excuse.
The point about architects was somewhat joking; of course there are good ones (such as yourself judging from your comments), but in my experience most of them are at best a useless burden and at worst an utterly destructive influence on teams.
I can tell that you are an architect from they way that you like to use the terms "right" and "wrong".
There is no right and wrong. There are only opinions and stylistic preference. There are solutions that are better and there are ones that are worse. But when you black box it and look at it from the outside, it either works or it doesn't.
Everything is a spectrum, but there are also clear parts of the spectrum that contains death, and clear parts of the spectrum that are better than the others.
Works is not an acceptable standard. Imagine if we built bridges with the criteria that “well I crossed the river on it, so it works”. What tonnage can it support, how many years can it stay viable, does it fail gracefully if we drive something heavier than intended over it, what amount of wind can it take... none of those things are captured by “it works”.
Similarly for code. If your answer is “well something changed, so we need to refactor” or “well that wasn’t in the requirements so we can’t do that” then your solution didn’t work in the first place, because works implies scalability, extensibility, reliability etc.
Those are not style or opinion. Making anything “work” in the now is trivial. Building things that are not fragile to change and time is engineering.
Just to address "d" in your list. Consensus is hugely important in team environments. If you're an indie dev, do what makes you happy (and profitable). But if you're in a team, be a team member.
My team just had an coworker leave for another team. This coworker was very smart, very hardworking, and very dedicated. But he continually chafed against any sort of documentation or communication. He also chafed against any established standards or policies; pretty much did what he wanted, and was never really called on the mat for these issues.
He got away with this because he was a "rockstar." He could solve some pretty hairy problems fairly quickly. But explaining these fixes to others was difficult for him, and many of his solutions were MacGyver-esqe. He had come from a small shop where he wore many hats; we're a large enterprise with lots of teams. This means that communication is probably the most vital skill for team success.
Since he didn't share or document his changes and fixes, the remaining team members are now left trying to divine what he did. While I blame him for a lot of this behavior, I primarily blame his manager who continually tolerated it. Ironically, this manager is shocked and confused as to why he lost his rockstar.
Skill and talent are at odds with process heaviness. Oftentimes I think it's a "pick one" type of scenario. Do you want critical thinkers who just "get it" when it comes to complex technical matters? Or do you want process rigor?
Someone will say "false dichotomy", to which I say, "maybe".
Process heaviness is not a goal. The secret is to be as close to the minimally viable as is safe.
Undocumented code and decisions are just a more slowly accumulating cost, it is no less costly than bad or failing code.
This is a reason I love having outspoken and extroverted devs. The guys who love to talk so much that they will explain in extreme detail and at length.
I was reading through an old bug yesterday, and the guy who had done some work in that area had left a 5 paragraph explanation of what had gone wrong, what he thought may have caused it and some things he was planning on doing. Having that written down was invaluable when I got to the thing a year later.
Process rigour is not the goal. Communicating what is strange and different is. If you have guys who do that naturally, great. If not, you need some process.
> This is a reason I love having outspoken and extroverted devs. The guys who love to talk so much that they will explain in extreme detail and at length.
In my experience, the devs that talk the most, know the least about how things actually work. They churn off trying to explain something and are either subtly or blatantly wrong, and you've got to reel them in before they get down the rabbit hole and misrepresent reality too badly. It can be catastrophic if they are interfacing with management or customers.
It seems to be a manifestation of the classic "baffle them with bullshit" strategy for dealing with ignorance or incompetence.
If you follow a consistent process, that can often make you look like you are a "rockstar". I find many people are so random, and don't approach their work in any kind of structured or analytical way, that doing things takes them much longer than it ought to. At the end of the day, rolling up your sleeves and actually doing some work goes a startlingly long ways. And most of all, test your fricking code yourself, at least run it, anything - I've lost track of the number of times that people just check shit in that would be blindingly obviously broken if they had even tried using the feature that they supposedly worked on.
I wouldn't say that it's either/or with respect to the person, so much as two types of activities/skills that interfere with each other.
Coming up with innovative solutions to complex technical problems requires you to be in the weeds, and think non-linearly (e.g. using intuition); while communication requires abstraction to (preferably) only the most important elements, and linear composition of the ideas into speech or text.
None of these are a license to forge ahead anyway. All of these problems have their own solution that should be addressed, and most definitely not by just doing what you want anyway.
Yes, I think that it's likely that a dysfunctional institution would be unable to prevent you from doing that, and it's likely the reason why you're a part of it.
An alternative perspective: If you think you work in an institution that CAN and DOES prevent that (e.g the engineers are NOT in control), then how quickly can you respond to real emergencies?
You can make such actions visible (and hold people accountable after the fact), but blocking engineers from taking action is a no-no!
Sometimes you don't have the luxury of waiting until there's a consensus. In some teams there may never be a consensus and the whole "but if we had one it would be far better!" is a myth.
That's not an excuse to just go ahead from the start and say "eh, finding a consensus is too hard, I will just do it", but it is a reason to accept that at some point everything has been said, just not by everyone. And then a decision has to be made or you will talk forever.
> It is still possible to go for it. But you need to be accountable for the consequences.
This works in both directions: Are they also accountable for the success or is it a team success then? I see this pattern of not being able to get any decisions made, then hope that someone makes a decision and when it pans out "aren't we a great team? yes, yes, we are" and if not "They decided to just do it, it's their fault" and so on - you either share the wins and losses or you share neither.
That's the nature of a proverb. It's a concise unit of packaged wisdom. It's useful to have in your mental arsenal, like a function. Often it's useful because it contradicts the default wisdom.
Applied to the wrong thing in the wrong way, or on the wrong day (there are no rules)... it's wrong. This (ironically) makes proverbs and religion a bad mix.
Don't argue with the devil. Measure twice, cut once. Grab the bull by the balls. Great company at a fair price, not fair company at a great price. Show must go on. Show, don't tell. It's how you use it that matters. Who cares what colour the cat is. Quality over quantity. There but for the grace of...
If you like your statements airtight, you don't like proverbs. Airtight statements require too many words. We can find exceptions to all these rules.
EDIT/PS: reading over what I wrote, proverbs are interesting. proverb meta analysis required.
I think the relationship of power is important here. Reaching consensus among peers is not the same thing as asking for permission from an entity of a superior position of power.
This point is so good, and so subtle, I'll try to expand on it.
In tech teams the saying that "the best idea always win" is commonly believed. But the more experienced know that first and foremost groups are social and there are certain folks within the group who throw out an idea and everyone is willing to give it a shot. Whereas someone else in the group with less authority or social status or persuasiveness may have presented the same idea first only hears everyone saying "we're too busy", or poking holes in it not to make it stronger but to avoid doing it altogether.
How does this relate back to forgiveness over permission. Because with forgiveness the person is humbling themselves to the superior or group and falling back in line. That's more psychologically pleasing as the superior or group gets to reassert their will over a person again. Permission (especially if its not related to something they were assigned to do) can come across as diverting off course and pulling peoples will towards theirs, more so if the request requires action on their part.
Often the outcomes play out as much on power and us as social beings as we are rational.
> Permission (especially if its not related to something they were assigned to do) can come across as diverting off course and pulling peoples will towards theirs, more so if the request requires action on their part.
That's so true. I feel like most of the time asking for permission also comes with request to take responsibility for your actions and help. You ask for permission, they have to trust and help you. Too much to ask.
Honestly, I've been living for 25 years and I'm not sure I've EVER seen anybody give permission in this sense to anybody. If it happens, it's something different. Either the person giving permission doesn't care or the person asking for permission really notifying in the form of asking permission. Or somebody didn't have time or energy to think properly. Or was deceived. So on. I don't know, maybe I'm taking in too far. But in any case asking for permission is weak and rude coming from position of lesser authority, and nice otherwise.
Also I should note that this authority dynamic changes with rapid pace from context to context. Everything affects it: one moment you are supposed to be meek subordinate programmer and the other you're expected to be highly qualified professional with key domain knowledge. I belive there can even be dozens conflicting beliefs, each with different strength. Those are in short memory, then there are thousands more withing short reach, and millions possible depending on what happens in the next few seconds.
It means you're are not doomed and can navigate your way out of many difficult social situations and get what you want anyway, regardless of your social status. Most likely your status is fine. Most likely all this dynamics can be circumvented with a few jokes and uplifting remarks.
I quite strongly disagree. Just like picture is worth a thousand words, working code (prototype) is worth a thousand words too.
If I decide to go out and code a prototype without asking anyone anything, where is the harm in that? You can criticize it after it is done. You could have done the same thing. And you can always throw it out.
And in my view, this precisely is "leading by doing". Linus Torvalds didn't seek consensus before he wrote Git.
In another response, you write, arrogant people are the biggest problem. I don't think doing something on your own is arrogant at all.
And I think, "being accountable for consequences" is exactly the "forgiveness" part. Although I am not a fan of hierarchical decision making systems.
Wouldn't coding up a prototype be more in line with asking for permission? You code up the prototype to demonstrate your idea then ask your team if you can proceed with it. I would say that's a solid, proactive way to get your ideas across.
Depends on your working environment. At my current position, if I code up a prototype during work hours, I'm subverting our EPMO, since it's not an approved project. I've had great success doing various prototypes like this, but I am not waiting for permission to do them.
Bringing those prototypes to production is another matter. In any organization, there are processes that need to be followed to onboard a new application, platform, pattern, etc. If those aren't followed, the implementation won't be nearly as effective—especially long-term.
In some work environments, you are encouraged to get 40 hours a week, regardless of whether those 40 hours are necessarily put towards what are perceived as the "highest value" endeavors. So if you are blocked on everything else, why not take the remaining time and put it towards things you personally believe to be beneficial to the project? It is certainly better than sitting on your thumbs or asking people who are already busy what they think you should be doing.
Is this work in lieu of your regular tasks? If not, clearly you don't have enough to do. If so, that's grounds for dismissal. Unless, you got permission...
Our manager doesn't have a clue how systems work, so it's up to us to find the best way. I know the various areas we need to develop to push the system forward and it is up to me to find the best way to do it. If I learn something new that makes me rethink something, then I am more than welcome to revisit it and try out some new things. If it ends up with a better system then we all benefit. At the end of the day the work that needs to get done does get done.
Obviously I do have to use my judgement to allocate time appropriately. If there is a customer screaming at accounts because they were overcharged or whatever, then it is quite obvious I need to resolve that issue rather than work on a new way to style our buttons, but for the majority of the time it is up to me.
I do also spend quite a lot of my own time working on various things where it is a bit ambiguous as to whether it is 'proper' work or not. I enjoy the work I do because I don't feel like I am working in a sweat shop..
Maybe I'm just lucky to have always found a job where management trusts the developers.
Yes! I would be really surprised if an organisation didn't expect that to happen!
When solving pretty much any problem that I don't have an existing cookie-cutter solution for, I do some prototyping as part of the process of figuring out how it works. Sometimes I do this for arbitrary things that are irritating me, or that I think might be worth looking at.
Nobody is sitting over my shoulder looking at everything I do and I'd be right out the door if that was ever the case. I'd expect professional software engineers to spend at least a bit of their time working on this sort of stuff!
> When solving pretty much any problem that I don't have an existing cookie-cutter solution for, I do some prototyping as part of the process of figuring out how it works. Sometimes I do this for arbitrary things that are irritating me, or that I think might be worth looking at.
Well, of course this is how normal development works. This is the work I am talking about that would _not_ get done because the OP was working on a prototype to solve some _other_ problem.
> I quite strongly disagree. Just like picture is worth a thousand words, working code (prototype) is worth a thousand words too.
Working code is the easiest part. No one every throws it out and we are doomed to maintain the shitty prototype code for years. I find for internal software / consulting: "working code, ends arguments" but for enterprise software it is exactly the opposite.
It's idiosyncratic code that doesn't scale to a team developing it. It's has no tests and no thought to broader usage. There is no documentation. It fails apart after you put load on it, want HA, load-balancing, disaster recovery. Almost all code works at the small scale. It's so hard to prove to even mid-range developers why an architecture that "works" doesn't really work.
When you mix developers coming from the opposite spectrum it is disastrous.
You're implying that a prototype is a form of communication, which I strongly agree with.
I think the key thing here is to ask "What is the impact on other people if I just do the thing?"
In the case of building the prototype, its either "Well, now they need to spend time looking at the prototype", which would be the case no matter what communication medium you used or its "Well now JS spent 4 days doing that instead of what was on the roadmap. On the other hand, we have a prototype of X" which is a bit of a gamble and depends on what people were depending on you for.
> If I decide to go out and code a prototype without asking anyone anything, where is the harm in that? You can criticize it after it is done. You could have done the same thing. And you can always throw it out.
I don't understand this point. Are you suggesting coding a prototype on your own time? Otherwise if everyone in a team is free to choose to code prototypes who gets the actual work done?
I am often that getting things done guy, and have definitely incurred my share of debt in terms of mistrust or ill will from some folks.
That said, doing that is a calculation and is done to achieve the organizations mission. That may be restore a customer out of service (sorry, we’ll do it tomorrow, busy) or hit a milestone that matters on time (we’d love to, but expediting some change process is a lot of work).
Unfortunately, in these situations I’m empowered to make tactical changes, but not to make more valuable strategic change. From my perspective process and controls are there to make things go faster, not as a weapon to make sure folks leave at 4. The trains need to run.
I agree with you on the downsides of distributed decision making, but I think it is just a matter of tradeoffs.
Involving more people in a decision is usually going to result in better decisions, as it will benefit from more viewpoints, experiences, and critical review.
The tradeoff of group decision making is that it is expensive and slow. Even just a single hour meeting with 8 people is a whole man day of work.
On the other hand, distributed decision making (where individuals or smaller groups make decisions) is faster and cheaper, though on average probably produces less optimal decisions.
Whether centralized or distributed decision making is optimal depends entirely on factors like how much better the centralized decision is than the distributed one, at what cost that improvement comes, and the cost of later correcting a sub-optimal decision.
In other words, the real world is complicated. Soothing bromides like "It's Easier To Ask Forgiveness Than To Get Permission" or whatever its opposite is don't have very much value.
In your example, I read it as the other members of the team not being quite as enlightened as she is, because they 'mistrust' instead of recognizing her soft leadership. It sounds like you believe she bears responsibility for that. I disagree. Accountability is different, and people like you're describing are still accountable. I take risks occasionally which are against the consensus and implicate the whole team. There's zero chance I wouldn't be held extremely accountable if it didn't pan out, and that is as it should be.
> d) That other people can also have done the same does not mean that they are worse than you, it may be that they see a bigger picture that you can't see.
I'm confused why you seem to be so sure that in the anecdote you shared, this isn't exactly what was going on. Could it be you have some unconscious bias against the person who took that action, leading you to see them as a rogue cowboy instead of a wise leader?
> Could it be you have some unconscious bias against the person who took that action, leading you to see them as a rogue cowboy instead of a wise leader?
The rest of the team was pissed off. A leader is followed, a rogue cowboy leaves everybody else behind and without the information that they need to do their jobs.
But I agree that it is difficult to say if it is one or the other from the outside. That is why it is so important for management to be present and to have direct communication with all the development team. "Lazy" management tends to trust whoever screams the loudest instead of expending the time to fully understand the situation and listening to everyone involved.
You are right. With just my description, it is not possible for anyone to know if it was one or the other. And in fact, it was more grey that I have described. Taking into account all the information I gathered, I still believe that it occurred as I described.
I think there are two nuances missing here: First, it's easier to ask forgiveness -- this is a descriptive statement, it doesn't say better. Second, this is predicated on getting forgiveness. If what you do isn't relatively easy to forgive, you lose a lot, eg. getting fired or otherwise formally sanctioned. It's certainly neither easier, nor better.
Finding consensus with too many people is the #1 reason I see that big companies have productivity issues. Oh, you have a great idea? Why don't we run it through 5 layers of management and 20 committees that always adjourn before finding a decision.
That's why IMHO you need very small teams with a lot of freedom to decide. Then this small team can find consensus much more quickly. The most effective teams I've worked in were 2-4 people.
> Ah, the developer who's 10x because their work slows down everyone else 10 times.
You are right. People that think of themselves as 10x developers are the ones that do that and will slow down everybody else.
Really productive developers help others and speed up all the company.
I have worked with some people that one can call "10x developers", even that I don't agree with the term. They were good, they were friendly and willing to help the business and their fellow developers.
And they ask for permission and share their ideas with everybody. Their product owner was also amazing and they had a great synergy. Back then I was a manager. And my job was to make sure that things did not change.
Sometimes the key thing is to make a choice, any choice is better than paralysis. This is often the case for military action during war for example, which is why it's usual for countries to have an executive military leadership which makes decisions immediately and is answerable to a ponderous legislature only after the fact. Most large organisations will face at least a few decisions in this category.
A corporate entity should have someone who has authority to do so, is willing to make those decisions, and accepts responsibility for their consequences even when bad. In principle this is the CEO role.
But much more often the right choice is essential, paralysis is better than the wrong choice, at least for a while, so we can afford to dither while we get the choice right. Of course if you're sure you're right this is frustrating - why wait for others to see your POV. But I have very little trust in anybody who hasn't noticed that they're often wrong. Such a person is inevitably short-sighted and their judgement untrustworthy, whereas those who know they're sometimes wrong should be patient to find out if this is one of those times.
Knowing whether you're facing a "any choice is better than no choice" situation is much easier than knowing the right answer, and I think "easier to ask forgiveness" is about people who take this approach when they know that permission is an option and choose not to take it. We should try to make permission easier, and forgiveness harder to avoid rewarding this undesirable behaviour.
Finally though sometimes choice is an illusion. It is not worth anybody's effort to give or deny permission for the inevitable, and we shouldn't praise the "decision" to accede to it. Recognising that something is inevitable and thus not subject to choice is trickier, and you can waste a lot of time discussing whether to do A or B when everybody in the discussions knows actually C will happen and the choice won't matter. Learn to let it go.
In an individual contributor where the risk and responsibility falls on you it may be expedient to go by instinct and gut feel. But the moment the there is a team the most important ability to get things done is consensus.
This can also be ego and attention seeking behavior masquerading as trying to 'get things done'. It seems to be driven more by the need to stand out than accomplish anything and puts everyone in peril for individual glory.
Casual references to 10X have no credibility without performance metrics. 10xers will have to earn the trust of the team and will automatically have it with a track record like Linux Torvalds on Linux or Ussain Bolt on 100m or its just hubris and posturing that will damage team productivity.
If you are the type of person who is comfortable going in an independent direction in a group effort, you need to be able to assess the skills of those around you objectively, and you need to be able to ask good 'meet in the middle' questions when your objectivity needs re-evaluation.
A team member may do what is best for one instance you observe versus the thousands of other times you ignore them following instructions in spite of the fact that they may potentially have valuable information that could be very useful for the team as a whole.
>It is still possible to go for it. But you need to be accountable for the consequences.
We all do. Whether it's forgiveness or permission it's still the same problem when you work on a team.
> I will flag anyone that decides to "ask for forgiveness instead of permission" and notify their manager.
I don't know your dynamic and I'm not pretending to. But it's pretty easy for me to say "aren't you doing exactly the same thing you are calling out?" except from a managerial perspective, instead of whatever you consider 'ground zero' to be for business decisions.
> I have seen this abused.
I'm sure you have, and I'm not doubting that either, and no, that's not sarcasm. I'm sure your experience is relevant, but it's important to weight your entire set of a priori information / observations / inferences and assumptions with a 'maybe that's all wrong?' perspective too, at least in my opinion.
> And quite often that person feels vindicated when her solution works.
Try to exist in a world where you force yourself to assume everyone is just smarter than you, because you just assume they all have more information and greater awareness in their heads than you do. People wind up judging themselves more carefully, and people wind up taking note of their errors more carefully, without it having to be explicitly pointed out to their detriment and embarrassment (IMO)
Vindicated might be just another word for "thank god I finally did something unique and correct"
Your last line is instructive. Often the biggest failing of people who abuse this adage is they fail to complete the process -- they don't actually ask for forgiveness and reconcile an urgent action with the needs of the people around them they stomped on. Without that, it turns into one long "I do what I want" temper tantrum, which is just awful in a team context.
I've noticed this type of comment a lot on HN lately. An innocuous comment which features the tiniest sliver of an attack surface, in this case use of the pronoun "she" in an anecdote, is used as a launchpad for a completely unrelated implication or outright accusation of prejudice or ignorance.
When I read the grandparent comment and saw the (uncommon) use of the female pronoun in the story describing a negative action, I instantly thought of this type of response. I'll admit it, I even had the impulse to make a throwaway and troll and say something like the parent comment just to see the reaction. (I figured it would be swiftly downvoted/greyed).
Despite my own impulse to troll, I truly can't tell if this comment, and others like it which are not hard to find here, are performance art of the reductio ad absurdum kind, a sort of Andy Kaufman-esque "triggered SJW" act, or if this ascribing of every phenomenon to some type of systemic inequity no matter how farcical is a real part of the zeitgeist now.
I'll admit my bias: I'm tired of oversensitivity and bucketing everything into these overly broad categories of discrimination. I like to be able to use whatever (third-person) pronouns I want in my stories, etc. However, I have always thought that the "triggered overreeacting SJW" archetype was mainly a boogeyman created by immature people at the opposite of the spectrum, the type who frequent r/theDonald or breitbart or what have you.
After seeing these types of comments here so consistently, however, I cannot be sure!
I tend to find that the weird behaviour of finding a tiny point in somebody’s post and using it to launch into some hypothetical about someone’s behaviour/attitude/mindspace is common on HN - it just jumps out a bit more when the hypothetical is regarding gender-related behaviour because that’s something we all know a bit about and often have strong opinions on.
I don't get it. Why did you just stand still while this was happening? This never happened to me because every time someone started to do things without consensus I forced an agreement. You can only blame yourself if you just let these things happen. Writing software doesn't happen in a blink of an eye you know.
As far as work goes, I think one reason for this saying is that getting permission requires a higher degree of good communication. Once the deed is done, you can show it to explain it's value. Getting permission involves conveying your vision to people you may not know well who may not have time or inclination to really understand it.
For some of the other examples, such as marrying someone, if you go ahead and get married without asking, it signals a higher mutual commitment. In some sense, it more strongly suggests you love each other and are not merely social climbing.
I think an article about the logic and practicalities behind this could be fascinating.
With regards to an organizational/hierarchical environment:
Asking for permission puts the responsibility of the decision on the person being asked, which makes everything slower and more conservative.
Just doing it and rationalizing it afterward tends to be more efficient, and helps to captures upside sooner rather than wasting time worrying about the downsides.
Your boss always has exposure to the downside. They may take it out on you emotionally (if they're a jerk), and throw you under the bus socially (again, a jerk), but they deal with the consequences in reality because the worst they can do to you is fire you. That's how hierarchies work.
I’d consider being fired a poor outcome, so I’m not sure I’m getting your point. After a manager fires a “bad performer” to look good, what further consequences are they exposed to?
You think the manager's problems are over if they fire the bad performer? First of all, it's usually pretty difficult and expensive to fire anybody (which also involves onboarding and training a replacement). It reflects very poorly on the manager, so it's not done lightly.
Moreover, after the report has been fired, there's probably still a mess to clean up. Obviously it's not the report who needs to take care of it. It's whoever is responsible for that area, meaning the manager or whoever they can assign to that task.
I'm not saying there are no consequences for an individual contributor who makes a mistake. I'm just pointing out that, at the end of the day, a manager is responsible for the actions of their reports. That's the whole point of their job.
Can say in $dayjob, if I need permission for something it will take 6 months and a lot of red-tape which ties up multiple man months itself ( 99% of it on my team :( ).
If I can get by without permission and instead ask forgiveness, the total time spend on meta-work is significantly less, and ironically we do a better job because we don't want to do something unsanctioned that goes wrong.
I can see why this phrase caught on, I'm surprised there's no reference from before 1842, since this feels like one of those pre-industrial slogans.. Something you'd find more related to police or a parent than an institution of work.
While this quote rings true most of the time, it's important to discern whether this mindset is merely enabling mischief or allowing for an acceptable level of disobedience.
Many monumental breakthroughs were accomplished by disregarding permission, and rebellious attributes are attributed to people like Stephen Wolfram[0] and Albert Einstein. The MIT Media Lab even has an award for disobedience [1].
This mindset, though, can manifest into an unhealthy obsession with breaking the rules. An uncontrolled expectation to "ask forgiveness" can lead to murky moral territories. Where do you draw the line between accepting rebelliousness and enforcing the law?
I feel like the Dunning-Kruger effect plays a big part in the problem. Many people feel an illusory confidence in their capacity to understand a problem domain, whether they are in the role of the rebellious person or the law enforcer. Consensus with group wisdom outside of that hierarchical dynamic seems like one of the best protections against foolish rebellions or foolish rigidity, but that still leaves the problem case of what to do when the larger group wisdom is not correct. That's going to be the rarer case by definition considering how badly people tend to be at rating their own knowledge, but we also depend on those rare, capable individuals to overturn established wisdom. Or as put more succinctly by George Bernard Shaw,
"The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
Many of the comments relate this adage to situations where the rules explicitly prohibit some behaviour. I always assumed it is meant for situations where the rules are not settled yet or unclear. If I ask in such a situation for permission someone may forbid it. If I do it anyway I brake not only a rule but show that I do not accept my superiors authority. It would have been better to act in uncertainty about the rules. The result of my actions could vindicate my behaviour and help clarify the rules for the future. In the few situations were I offend someone I could still plead to ignorance.
I have found myself saying this in my mobile apps business.
Oftentimes, I will contact someone associated with the community for a product I am building and ask them if they want to help promote the product once it's out. They take this as some sort of partnership where I have to get their permission to publish my products or go in the direction they want to go, just because they might help me out.
And usually these companies are slower moving than I am, so doing the back-and-forth and getting feedback would take forever. With mobile apps, you have no idea if the thing will ever take off, and I have found it is best to just launch the thing and see what happens.
I'm not sure what some of these people think. I'm an independent businessman. I have the right to do whatever I want with my own products, and yes, I can choose to launch something whenever I damn well please. If you like it, go ahead and promote it. If you don't, don't. I honestly don't care.
So I take this saying more as "Doing anything at all will always be perceived as offensive to someone. You might as well do it and let them get offended."
And I know that soundbite lacks nuance and could easily be taken to mean something else, but then it wouldn't be a cool soundbite either. Obviously don't murder, rape, etc, and do take others into consideration when you are working on a team and you need their help longterm.
But I think the essence of the saying is that nobody is purely innocent and anything worth doing will probably ruffle some feathers. If you're overly cautious, you won't ever accomplish anything significant.
I was convinced this statement was also in the "Zen of Python" (PEP 20 [0]), but it's "only" in the official glossary [1]
> EAFP
> Easier to ask for forgiveness than permission. This common Python coding style assumes the
existence of valid keys or attributes and catches exceptions if the assumption proves false.
This clean and fast style is characterized by the presence of many try and except statements.
The technique contrasts with the LBYL style common to many other languages such as C.
edit: Sorry to bring programming to the table again, the 'philosophical' side is also interesting of course!
On a related note I've found it's easier to get your way with e.g. your manager if you say "I will do this!" rather than "Can I do this?"
This probably have to do with that in the second case you ask your manager to make a decision, causing them cognitive load. In the first case you already made that decision for them.
The first time I read this quote is in Peter Hessler's Country Driving: A Journey Through China from Farm to Factory.
He use it to summarize Chinese reform and opening. You cannot get any permission from goverment, but you can try it first. If something bad happens, ask forgiveness. It maybe the core reason of Chinese speed.
Sometimes your methods ask for permission. Every parameter is validated at the top of the function and errors are thrown if any parameter is wrong, e.g. null parameter checks. Generally this happens inversely to the amount of trust in the caller. A public web service call would have everything strictly validated.
Sometimes your methods ask for forgiveness. For sake of argument, they accept a bunch of pointers as parameters and blindly start dereferencing them without any null checks. This is done because it is a small implementation and the caller is completely trusted and is known as fact they would never be null. Those checks are redundant and a performance cost.
It's really a judgement call to known when to get permission and when to ask forgiveness.
I live my life by this quote. The Swedish version even rhymes and sound charming. It's a great mindset for trying new things and exploring new ideas, which would have been blocked by bureaucracy if approval were needed.
Not related to the article's content but, this link just flashes between black and white once it's loaded for me (iOS Firefox). This might be one of the strangest broken websites I've seen.
Moses was a genius and accumulating and wielding power. His playbook wasn't "take initiative then hope for the best", it was "take initiative then destroy lives and careers until you get your way."
Sometimes. Not all the time. As a way to avoid decision making paralysis in a public safety or military context I agree. In business we're not saving lives or taking them.
Ah, but also not all permission asking is the same.
Sometimes it's best to ask someone local and knowledgeable for unofficial permission and just do it than to run up and down the full command chain and paperwork. (a paper trail makes this impossible so do not leave one - if you need forgiveness later this option is still open then)
When I was young and inexperienced team leader, my boss at the time told me this. It may sound silly now, but then it was an eye opener and it empowered me to make decisions (including financial ones) more freely and with confidence - within some limit (of cost, potential damage, etc.) dictated by my common sense.
I'm a bit ambivalent on the issue, because if the quote is any good, it should stand on its own without appeal to any authority or writer.
But then we have the quotes that are quite banale in nature, but where the use of said quotes have been taken as validation by extremists, bolstering them in their rather dangerous belief, that secretly everyone agrees with then, and thus the ends justifies the means.
For now I brandish unattributed quotes with reckless abandon in settings where I know everyone, but try to do some basic research in public settings, not because attribution is important, but because others might.
Though for me the quick quips of quotes is a lens which can be used to shine some light on some aspect of our lives and world, it's as much a folly to rely on them as anything else. They capture is a single snapshot of an almost infinitely complex world and are as such almost always exactly as wrong as they are right, although in unusually interesting ways.
Please do remember that she was Rear Admiral Grace T Hopper and her grandfather was an Admiral as well--I suspect that she gained this phrase from the military mindset. Catch 22 comes awfully close sometimes, and Weller was writing that about World War II.
I wish she were more remembered for her backward clocks and the fact that she would let you have it if your answer was "Because that's the way we've always done it."
And, while she may not have originated the word "bug" for a computer problem, she was probably the first to document an actual insect causing a problem in a computer:
I'm not necessarily a big fan of the "Ask forgiveness rather than permission" route as it only really works when the result either direction doesn't really impact anybody further than the person carrying out the action.
I currently have to step over a half-dozen bicycles every morning because some venture capital funded companies decided permission was just too difficult, and I hope they don't get forgiven and have to pay really expensive fines for not obtaining permission.
I think the outcome where the bicycles exist and the company pays a fine is way better than the outcome where they ask permission and no one gets to use the bicycles.
I'm pretty confident that social pressure or technology can solve the littering issue, too, leaving forgiveness approach with no drawbacks at all. I would be happy to step over the bicycles, seeing it as a sign of an actual innovation in society that people are really using and benefiting from.
After looking at the Quote Investigator post, I was idly wondering if this quote that you mentioned might have been misattributed to Churchill, but apparently it's correctly attributed to him.
