Miles' Thoughts

In agile product management, the primary focus is on iterating quickly in order to provide incremental value through product enhancements. This is based on the assumption that it is difficult to know if an idea will actually provide increased value, so it is best to try something, measure the results, and adjust accordingly in quick succession. This method was developed as an alternative to the "waterfall" approach in which groups often failed trying to solve for everything at once since it is difficult to understand the full scope of any problem from the onset (i.e. you don't know what you don't know). Within the software world, this often manifests itself in practices aimed at delivering incremental functionality as quickly as possible, where teams are evaluated on velocity above all else. In many domains, that works incredibly well. However, there is a nuance which I feel is too often overlooked in that business automation software, particularly that which support

Roses are red, violets are blue, so I was taught in school, but what's it to you? I noticed something about myself recently, which I imagine might not be quite so unique to me: whenever someone asks me a question and it's clear by the way that they ask it that I'm expected to have an answer (often, a solution to their problem), I'm able to come up with an answer. Those answers come in many forms and some are much more useful than others, but I seem to always have some sort of answer. When my younger brother asks for advice about his career, or someone who I coach at work asks what the appropriate next step is on a project, or a consulting client asks for my recommendation on how to optimize a workflow, I'm full of answers. But are they the "right" answers? In these situations, it seems that the expectation creates both pressure to perform and is simultaneously empowering, creating a space to create something. That's poorly worded, I know, which is