I'm the author of the post - would love any feedback / similar experiences / contrasting opinions!
This is just another way of saying "management is right, even when they're wrong, and you need to accept that".
Simply stating that you did as instructed is not a viable excuse for a human, that's not what they're paying you for. Computers can get away with it.
Getting paid for doing what someone tells you to do, is literally the definition of a job. What you're saying actually, is that it's not your job to do your job, it's your job to also do the managers/PO's job.
... But I've generally heard it most frequently from the tech lead and/or manager at the standup. It's easy to justify: "as the TL/M, my work is ill-defined, meeting-heavy, complex, externally-focused, and long-term! I'm not just building a feature! It's hard to describe!"
In my experience, this culture percolates with lightning speed: more junior folks immediately understand that to be senior and high-status is to give vague updates (often with a dramatic sigh and a self-deprecating joke about getting nothing done).
So it's good to exhort feature-building ICs to show incremental progress on that feature, but I think this article should have a heavier focus on the most senior folks at the standup.
Frequent checkins with detailed commit messages including markdown and graphviz diagrams which state intentions.
Switching the flow from a status meeting low detail reponse of "still working on X issue" to a regular feed of detailed information which serves not only as a development log, documentation, but it crystallizes the developer's planning and thought process because they have to describe what they are doing rather than just "fixing the issue" , or "building the thing".
Persistent chat has made daily stand up status calls redundant. Stakeholders can subscribe to channels which have rich detailed information about what is happening at any given moment. For larger groups a resource can curate the channels and provide a thoughtful summary in a higher level channel of different teams progress. Tools like Azure Dev Ops provide meaningful charts, tracking, and velocity, and the deeper conversations on chat linked to work items, wikis, and repo level filea serve to provide an accurate picture for anyone looking into the effort. Leads, and managers can identify trouble spots and adjust priorities or provide valuable insights. Regular demos can also be linked and serve as a historical record of the development direction.
When juxtaposed to manager, it usually means individual contributor - someone being managed rather than doing the management.
see: https://thelingspace.tumblr.com/post/114432905996/the-euphem...
> For early career engineers, it often happens because they lack practice working on teams. They train in school environments where they do classroom projects on their own, or work on long-term intern projects in a silo.
Serious engineering school would have student work together to ship projects.
[1] https://courses.csail.mit.edu/6.803/pdf/hubbard1899.pdf which is both historically apocryphal and only good advice when dealing with an impatient and incurious leader.