This post was first published in its entirety on CoderHood as 5 Reason Why I Love Being Wrong. CoderHood is a blog dedicated to the human dimension of software engineering.
When I was programming 100% of my time, it was my job to write robust and maintainable code. My work needed to be well documented, designed with the proper level of abstraction and as bug-free and efficient as possible. I also had to come up with good ideas for how to resolve problems and create viable products.
As a developer, I had to be right a lot of the time. Being wrong when writing code resulted in bugs and other issues. Regardless of code reviews and testing, dumb ideas in software code have a way of costing an ever-increasing tax.
In my executive role, things are very different. It is an entirely different job. My primary responsibilities are to hire great people, create the best environment for them to thrive and be productive, make sure reality is well defined and make sure that we make good decisions.
In my job, it helps if I have good ideas, but it does not mean that I have to come up with the best ones. It just means that I have to make sure the best ideas surface to the top, regardless where they are coming from or who is coming up with them. I am entirely responsible for my team's results. I am not responsible for putting a thumbprint on everything my team does.
On Being Wrong
I don't deny it. Most of the time I have an opinion. It is part of my job to have informed opinions, but I don't expect them to be always right. I hire people way smarter than me to come up with better ideas than mine.
When having discussions with my teams, I don't mind being wrong. In fact, I like it. I could even go as far as to say that I love being wrong, at least in hindsight.
I don't try to be wrong; quite the opposite. I do my absolute best to be well informed, have good arguments and learn whatever I can to ensure that I am right as often as possible. If I were wrong every time I opened my mouth, eventually my team would lose confidence in my abilities, and that would make it impossible for me to lead.
Despite trying hard, I am wrong a lot. That is the joy and the burden of hiring smart people. They don't let the boss get away with BS, and that is awesome! I would not want it in any other way.
Most importantly, when I try to be right and I realize I am not and, as a result, the right decision is made, that's when I win. It might seem like an Alice in Wonderland upside-down logic, but let me explain what I mean by giving you five reasons.
#1 -- If I challenge a good idea with a bad one, the good one gets stronger
If somebody in my team has an opinion and I test it, if it is a good idea then it grows and becomes stronger. If it is a bad idea, then it dies or takes a different direction. Either way, we made progress.
To make progress, it almost doesn't matter if my challenge is right or wrong. For things that are important, it does matter that I don't let the first idea that sounds good take hold without some more in-depth scrutiny.
I am not advocating that you should challenge everything anybody says 100% of the time. That's just annoying, and sometimes you just need to trust people. Extremes are never a good thing. I am suggesting that, when something matters, it should get scrutinized even if it sounds good.
#2 -- When I am wrong, somebody else in my team is right
When I voice an opinion, I am convinced that it is right, unless I am playing devil's advocate, which sometimes I do. However, my job is not to be right; my job is to make sure the right decisions surface. Getting to the best idea is what counts. I do need to be careful to recognize when an idea is better than mine; but, as long as I listen and keep my eyes and ears open, that's usually not a problem.
I am not THE judge of ideas either. Everybody in my team is a judge of ideas. My job is to listen to the many angles, including mine, and choose the one that passes scrutiny and is on the right path to achieving the company's high-level goals.
When somebody proves my opinion to be wrong, we both made forward progress and everybody wins. It is crucial to abandon bad and distracting ideas for better ones, no matter who was the author. That is what leads to good decisions and outcomes. If I have a bad idea that helps someone come up with a better one, we made progress, and everyone wins, including me.
The worse thing that can happen is not being wrong. The worse thing that can happen is when nobody can come up with something that can survive scrutiny. If that happens, it is on me as I apparently haven't hired the right people or I haven't provided my people the right opportunities or environment to do what they need to do.
#3 -- When I am wrong, I learn
I don't deny it. Being right about something makes me feel good, and who doesn't like to feel good? I know I do. However, if I were right all the time, I wouldn't learn anything.
As long as the team ends up making the right decision, I much prefer to be wrong and learn, than to be right and stay stagnant. Stagnation is my definition of hell.
#4 -- When I am wrong, I grow
Whenever I am wrong, I learn something, but I also grow an inch. Realizing that I am wrong is a way to become more mature and resilient to the next challenge, and it thickens my skin. Next time in a similar situation I'll be able to apply what I learned and help the team make progress.
Now, again, I am not talking about extremes. Being wrong most of the time would eventually destroy me. There is a sweet spot and a healthy ratio when it comes to "growth by being wrong." I have learned that everything in life is a bell curve, and extremes are rarely healthy.
#5 -- When I am wrong, progress is being made
Imagine a totalitarian regime where the dictator must always be right by law. Nobody is allowed to question anything the dictator says, and everyone must defend his decisions no matter how outlandish they are.
Do you think that regime would be successful, even if the dictator is a genius? It is just impossible for one person to see reality from all points of view. Everyone has blind spots, bias and a limited understanding of reality. Different ideas and a constant search for the best ones is what enables progress and innovation.
As long as there is an open debate and the best ideas survive, progress is being made, regardless who had a good idea and who was wrong.
Some Final Thoughts
In the software industry, everything is the result of teamwork. Every once in a while you need a genius to plant a fantastic and revolutionary seed, but the plant will not grow unless it is cultivated by open dialog, collaboration and an "idea meritocracy" environment.
An idea meritocracy is a decision-making environment where the best ideas win. To create it, you must give an opportunity for people to put their thoughts on the table for everyone to see, have constructive disagreements, and have a protocol to get past any conflicts that remain. That protocol could be "the boss decides." It doesn't matter as long as a decision is made that has the best chance of being the right decision. No decision is the worst decision.
In an idea meritocracy, it doesn't matter who is right or wrong. It only matters that the best ideas survive and thrive.
Top comments (6)
Fantastic article, the win is always the teams but the failure is on the leader. Being wrong is alright if one is humble ego is the enemy.
Have you perchance read Extreme Ownership by jocko wilink?
Hi, thank you!
Yes, I did read that book and I find myself recommending it often. Great book that unfortunately many people in tech pass on because is written by a hardcore military guy.
Nice list of book recommendations! I've only read one of them. BUT, I've book marked that list!
Your synopsis of the Scrum book reminded me of my Faux Scrum experience. I think each of those... ummm... sub-optimal Scrum scenarios hits one-or-more of your failure points.
Two books not on your list that probably ought to be: The Goal and The Design of Everyday Things.
Haha, its easily my most recommended book as well. That aside this article was great and I'm saving it as a reference for the future.
You're not wrong ;-). There are in fact some solid arguments to ask for forgiveness rather than permission when it comes to decision making in software engineering. This comes up whenever you are faced with uncertainty, i.e. all the time. Given uncertainty, you can do two things: 1) wait for more facts to emerge and/or undertake work to reduce the uncertainty. 2) take decisive action based on what you know now.
Unless #1 can be achieved quickly, efficiently and cheaply #2 is often the better way to go because it gets you results faster (good or bad) and time spent waiting costs you in several ways that you can't compensate for by getting it right later. E.g. shipping a month late has real cost in the form of revenue not realized as well as expenses on e.g. your team and anything supporting and depending on it. Worst case you get it wrong and then adapt, which might still be faster. Finally, there is a notion of good enough. Not everything has to be perfect.
That doesn't mean you should blindly go with what your gut is telling you all the time but it does mean that being mindful that time spent debating and analyzing is not always worth it. What is worth spending time on is verifying whether you got things right or wrong after the fact. Because if you get it wrong, you still need to fix it. And to do that, you need to know you got it wrong. To know that you need fast feedback loops. Which is why CI and CD are not optional these days. They facilitate fast decision making and risk management associated with that. Getting something wrong and finding out a year later is a problem. Shipping something wrong and fixing it on the same day is much less of an issue and vastly reduces the scope and impact of any issues.
Finally, developing software is a team game. No matter what you do, get some buy in and be willing to compromise with others. The flip-side of going with your own opinions is that you sometimes have to rely on somebody else's opinion when that conflicts with your own opinions. Some of the most difficult decisions I've made were acknowledging other team members needed the space to do things I did not fully agree with. If that then goes wrong, it's just another problem you deal with as a team. You adapt and move on. Playing the blame game is generally not very productive. If things go right on the other hand, acknowledging that is actually a good thing. Simply expressing that, "hey I did not fully agree with this at the time but looks like you were right" can make all the difference when some time later you need that person's support on another opinion based decision.
I really liked this article a lot! I find that it is not uncommon in the software industry (and elsewhere) to see ego drive people's opinions rather than an earnest desire to find the right answer.