Mr. Beck,

First let me say that I appreciate your contributions to this discipline.

I'm not sure I am following your premise/argument. So, work on whatever you want and implement it in whatever way tickles your fancy?

How does autonomous task/autonomous implementation jive with TDD? Am I truly free to choose what to work on (business priorities be damned) and free to implement in any manner of my choosing, say using a new cloud service I just read about in a new language and framework that interests me? What if I implement without tests, or source control?

This seems to be a recipe for people to find the easiest tasks to work on and cowboy up a solution.

That would be the "belligerent asshole" interpretation, one that I applied for the first 10 years of my career.

As an engineer, I often have intuitions about what I should work on. I'm saying those intuitions are valuable. Exercising my intuition improves my ability to choose priorities. I am still responsible for results, which is why I am not saying, "Do whatever you want. Nobody can tell you what to do." Someone is paying your salary for reason and at the end of the day you'd better be able to justify your salary or it will stop (again, voice of experience here).

As a manager, I need to accept that I will have intuitions about what to do next but that people who report to me will also have intuitions and theirs may not match mine. I need to choose carefully when to insist on my priorities because a) I can easily be wrong and b) specifying too much evaporates motivation. I generally get the best results by communicating what clearly, but leaving wiggle room.

If you think that engineers, given their druthers, pick the easiest things to do, then you talk to different engineers than I do.