Comment by d0gsg0w00f
1 year ago
I did not get that from TFA. I interpreted it as "know your customers and communicate with them". This applies to everything in life. It's especially relevant in big companies because it's easy to forget that you are forgettable.
I mean, if by "customers" you mean "the important people at your company".
> Concretely, that means that a project is shipped when the important people at your company believe it is shipped. If you deploy your system, but your manager or VP or CEO is very unhappy with it, you did not ship.
> If you ship something users hate and makes no money, but your leadership team is happy, you still shipped. You can feel any way you like about that, but it’s true. If you don’t like it, you should probably go work for companies that really care how happy their users are.
> I mean, if by "customers" you mean "the important people at your company".
I think that's exactly OP's (and TFA's) point: If you're working in most medium sized to large sized companies, just look at your org chart. Your manager, their manager, their manager's manager, and so on up to the CEO: Those are your customers. They are the ones that decide your comp, they are the ones that set your priorities and goals, they are the ones who are ultimately accountable when you fail or succeed. Your job is to deliver what they want. It's definitely a hard pill to swallow if you still have that idealistic view that you're working for end users.
You're not wrong. I think the issue people have with the post is that it disguises, to exaggerate a little, bootlicking with shipping. The recommendations are good for the reasons you mentioned, but job security or compensation maximisation are not the same as "how to ship things". If that happens to be the thing you do, it's a means to an end (to demonstrate you do your job well) but that's not the goal of shipping things by itself
But then, definition discrepancies are the origin of at least half the disagreements