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.
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.