3 ms·
> A squeaky wheel gets the grease but a raised nail gets the hammer. You're right about this. Indian work culture tends toward rigid hierarchical structures,
by primitivesuave 6y ago
> A squeaky wheel gets the grease but a raised nail gets the hammer.
You're right about this. Indian work culture tends toward rigid hierarchical structures, and expects employees to be much more deferent to authority than you would find in a typical Silicon Valley startup. However, even after bringing our startup culture out there (unlimited PTO, stock options, choose your own hours, don't call me "sir"), I still find this test-taking mentality to be what dominates an engineer's decision making.
Because of this, I know to be extremely specific on exact deliverables and tickets. The "rockstar developer" who can think deeply about the end user's needs is an extremely rare thing to find out there. The dominant mentality among developers is to expect a detailed specification that can be treated as the exact boundary of the problem.
To give a concrete example - I recently got quite frustrated when a simple CRUD feature shipped without a delete button, since the specification failed to explicitly mention where the button should go. Out of 30 developers and a full QA team, not one person thought critically about the specification or tried using the app from a user's perspective.
- skybrian 6y agoI wonder if making a game out of it would help? Suppose you intentionally introduce a specification error and challenge them to find it?
- blueblisters 6y agoYeah and also I don't think introducing unlimited PTOs and stock options is the same as tasking people to take responsibility for architecting a product. The likely reason is that India still lacks talent in mid to upper-level engineering leadership roles that can make user-centric decisions and groom entry-level talent.
- stevegalla 6y ago> not one person thought critically about the specification or tried using the app from a user’s perspective. I come from a manufacturing background and have moved into software. In manufacturing, if there actually are issues with the specification, you raise those through engineering change notices. If you start changing the spec on your own, that’s a big time no. Do you have a formal process for spec changes or are you expecting the team to raise these issues independently and unprompted? If someone has actually raised concerns with you about the spec or offered up changes, how did you respond to those? I work with people who always say, “why doesn’t anyone challenge me on my ideas?” This happens at the end of a meeting where these people will have shot down everyone else and their ideas. In reality they want “yes people” who tell them there is no disagreement because their idea is best. I’m not saying this is you, but they may have been through these experiences and might need permission or direct instruction to show them speaking up is valued.