Breaks aren’t simply for doing nothing, they are time for figuring out what to do between the work. They are rolling solutions over and over again in your mind before going forward with them. Time is what solves your problem and helps with your work. If you don’t have the time between your work to get things done all you’re doing is grinding from one thing to the next with no thought in between. Take…
The hard work, the problems you can’t solve, don’t get easier, they get familiar. We get better at solving them because we are familiar with all the constraints, context, and, constructs that surround them. Change any one of those components and the problem didn’t become harder again, it became unfamiliar. Step away from working on that problem for a few months and then go back to it, the problem itself isn’t harder, you’ve simply lost…
Imagine your team builds houses akin to how they write code. Some questions to ask; How long would it stand the test of time? What issues would appear immediately? What would work well? Would it align with what your users wanted? Would it ship completed? Would it be finished early or late? You can come up with more/less questions, the point of the exercise isn’t to take your team down a notch – the goal…
There is a narrow space between an end user and the person building the requirements where sheer Nirvana for what is being created exists. Where what the user needs is properly laid out and what the requirement writer is able to fashion into a meaningful delivery that looks to all of their additional/base requirements they have. It’s like the pot at the end of the rainbow. Or if you met Snuffleupagus. Or when two incongruent…
Have you ever asked yourself? Have you ever asked your team? Have you ever set the expectations of your team for what you expect of them and what hear what they expect of you? Until you do, you’ll never know just what your meetings are missing. But we never want to ask, it’s easier to complain.