> I just want likable people who will execute on my ideas (or the ideas I’m simply passing on from higher management), or with light discussion, even if the execution isn’t perfect.
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.
Startup or not, you're not always being paid to think, even if you're capable of it. It's super annoying to work with people who only want to push back when it's not part of the mandate - just like it's annoying to work with people who don't think for themselves when it's expected. Knowing what the job is is and important skill no matter where you work, if somebody can't do that it's a big problem.
I've worked in both sorts of companies. The constant questioning may work well at smaller scale but kills productivity at larger scales. Putting aside that it inevitably becomes a political exercise as much as a technical one (because the different technical solutions almost always reflect competing priorities), it also requires perfect sharing of information across the organization, which does not scale.
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.
> 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.
I think the problem isn't constantly questioning! The major problem is many times, the ideas was top down, without a basic research or thought about possible RoI, wants to be discussed more because the team that will implement wants to know better and avoid mistakes, such behaviors always causes friction!
> 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.
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.
Bruh we are slave to the machine. Most of us want to get in, get our paycheck, let the boss feel smart, and go back to our actual lives. Programmers tend to overinflate the influence of their job in their personal lives.
I try to do a good job at everything I do. Some things to a larger extent than others (being a spouse/parent gets more effort than being a developer), but I still _try_ to do a good job on the smaller things too.
I acknowledge that there are plenty of workplaces where “Make the boss feel smart” is unfortunately necessary, but going into a job with this attitude contributes directly to the environment the OP derides.
That sounds lovely riiight up until you’re in a position where one of your reports gets very inconveniently standoffish when they’re tasked with something that has been pre-determined, has been decided for complex workflow management , political, legal, etc reasons.
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.
> That sounds lovely riiight up until you’re in a position where one of your reports gets very inconveniently standoffish when they’re tasked with something that has been pre-determined, has been decided for complex workflow management , political, legal, etc reasons.
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.
Yeah, I agree with you, but sometimes higher management wants to implement anything without questions and multiple times the ideas taken more time to deliver! It's very toxic to work like that.
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.