By nature, I don’t like to be mean to people, or make someone feel bad. That predisposes me not to write blog posts that call someone out on something that they are doing wrong.
That being said, there are some things (actions or behaviors) that need to be described so that others can avoid making mistakes that could cause serious harm to their careers.
In a past position I witnessed a terrible dynamic between a founder and their development manager. The founder would go to the development manager with a feature request. The development manager would agree that the feature was a good one, but would raise concerns and highlight problems with the founder’s desired method of implementing the feature.
They would go back and forth for a while, and then the founder would say something to the effect of “I’m the boss, this is my company, do it my way”.
Which is of course the founder’s prerogative even if it’s the wrong decision.
The development manager would go off and build, or have built, the feature using the founder’s methodology. Subsequent to the feature going live, the very problems that the development manager had warned about would begin to surface, and the product would begin to suffer.
I’m not privy to the full history between the development manager and founder. I have some suspicions as to the cause of this dynamic, but I don’t know for sure what led to the subsequent behavior. In my opinion, the correct action to take would be to go back to the founder and say something like:
“We’re seeing problem ‘x’, which is the result of the decision to do ‘y’ while designing this feature. What do you want us to do next?”
or maybe:
“The system is breaking down because of ‘q’. I think we need to do ‘r’.”
Rather than doing that, the development manager would confirm to themselves that the problem was arising because of the issues that they had warned the founder about, and then the development manager would go off and ‘fix’ the code by stripping out the founder’s design and coding it the way that the development manager had wanted to write it all along.
The pros to that course of action:
The development manager avoided a fight with the founder.
The technical problems were solved.
The cons:
The founder became convinced that he could ignore the advice of the development manager who was the actual domain expert when it came to developing software. Rather than making a decision to over-ride the domain expert and then feeling the pain from making a bad decision, the founder became convinced that there was no need to listen to subordinates who disagreed with the founder.
In effect, the founder was always right and everyone else was always wrong. The founder would be cautioned against something, do it, and then as nearly as the founder could tell there were never any consequences for having ignored the domain experts in the company.
The issues that the domain experts cautioned the founder about never materialized, which meant that the founder either had to lose faith in the domain experts, assume that the founder was somehow infallible, or some do some combination of the two.
Secondary effects of this decision by the development manager included:
Lengthened development cycles (things were essentially being built twice).
Insufficient focus on technical debt (other problems that the founder had been warned against never materialized, therefore there was no reason to worry about big data problems or other technical debt).
My takeaway from watching this dynamic over an extended period of time is that you should always let people–especially people above you–feel the pain of their decisions.
I think that human beings who are drawing a paycheck have a moral obligation to warn our managers when we see a decision being made that will have negative consequences. How far you go on something like that is a judgement call based on your personal circumstances. The companies that most need someone to stand up and take a strong position against a bad decision are usually the companies that will make an employee suffer the worst consequences for taking that kind of position.
Depending on your role, seniority, and the consequences of the bad decisions being made, you may or may not want to get out of that company as soon as it becomes evident that the bad decision is going to be made in spite of your warnings.
If you stick around though, it is vital that you let people feel the pain from that bad decision. If you don’t, you’re undercutting your credibility and signing yourself up for more of the same.