That sounds horrible. I want people working under/with me that will question the work, that will try to figure out if it's the right work. It is common for decisions "from higher management" to be made without a real in-depth knowledge of how the system(s) work. When that happens, there may be a (possibly radically) better approach that can be taken.
Software developers are generally paid a lot of money. Not taking advantage of their experience and problem solving ability sounds like a waste of money.
Especially in any sales driven organization, I've seen it cause issues with infra teams questioning the need for certain features. Meanwhile, the answer is that the features are necessary because someone is willing to pay $$$ for them.
Just because someone is willing to pay for them doesn't mean they're worth doing. It could be that adding a feature makes other features harder to add or support. So sure, it might get you a win today, but it will cost you in the long run. And someone needs to be making sure the question being answered isn't "do we want a win today", it's "do we want the win today at the cost of a larger loss tomorrow" (when that's the case). And the sales team and higher managers don't see that. So it's the developer's job to make sure the questions are asked.
Sure, sometimes the answer is that yes, the feature is needed today, and it's worth the pain later caused by it. But if someone doesn't ask about the pain, it can't be considered into the decision.
Sounds great in moderation, but becomes horrible as soon as you get a guy who spends more time arguing than doing.
There’s a reason that “disagree and commit” is a common teaching. It’s fine to question and propose alternatives, but when people see everything as an opportunity to debate and fight it becomes a problem. A big one.
It sounds like how 95% of everything works. In reality of course there is a spectrum between visionary entrepreneurs and mindless drones and some critical thinking is generally welcome. But it seems like startup founders have a very strong belief in their own ideas even when everyone else seems to disagree (that is why they are/were startup founders) and that honestly just sounds so exhausting in a corporate setting.
I am a big believer in developers working with sufficient context, but the reality is that when an org gets to a certain size, everyone can’t have full visibility over everything.
Sometimes the ‘business analysis’ involved in determining how to address a particular need can be painful, intense, political, disruptive, etc. A burden that I want to and should shoulder for my team. Sometimes you’ve just gotta divide and conquer with some things. And that means that sometimes developers need to start with the puzzle already partially solved.
Again, this can all sound completely unreasonable, right up until the point when you’re first faced with this situation. Framing it as “you’re not being paid to think! conform, swine!” is too cynical. Rather, sometimes, it’s impractical or flat out undesirable for everyone to do everything. Sometimes you’re better off focusing on a certain type of thinking / work.
There is a very big difference between
1. I expect my worker to do as their told and not question it.
and
2. I expect my worker to use their analytic ability to make sure our plans are reasonable, and let me know when they're not. But sometimes, even knowing the issues they point out, I have to tell them to move forward with it anyways, because <factors>. And the need to be able to understand that sometimes we don't make the decisions.
A developer that can't help understand the various possible choices to be made is... less useful.
A developer that can't understand that they don't always get to make the final call is... less useful.
Blindly follow orders isnt really on most startup folks’ list of things to do.
The really funny thing I'm thinking about here is when I bring people onto a project I'm leading: I give them an intro to the project, all of the components at play, the needs of the project... and then introduce them to something they could work on and the general gist of what needs to be done.
For some people that's enough to take it and run (and check in with feedback, minimal viable product, look for "does this sound good?" kinda stuff).
For others it really feels like they need to be spoonfed an entire spec down to block diagrams, flowcharts, sequence diagrams, etc. And I've worked with teams that wanted that before we even assigned any software engineers to the project. Meanwhile I'm trying to get SOMETHING on a computer so we can start looking for the bugs that take a long time to manifest themselves. (and "that's not what we were expecting it to do!" from the systems team lol)
Anyway, I can say that's not necessarily a big enterprise vs startup thing. It's more of a team vs team thing.
IDK about startups.
It suddenly made it clear how each person worked that I couldn't see in the office
You can see this from the advice given to people looking to game interviews. Also from the lack of interview success for those who don't game interviews.
“Some people try to pretend to be a lone visionary genius who is wildly productive but also is an asshole to coworkers/authority. Other people don’t care that much about such ‘lone genius’ narratives and are much more interested in just doing what their boss tells them they must to earn a paycheck.”
Seems like a false dichotomy to me but I believe that’s what they’re trying to communicate.