As Disney takes Star Wars mania to new levels, I find it increasingly difficult to remain the odd guy who’s never seen a movie or knows much about the series. In truth, it’s impossible to fully evade this cultural phenomenon, and indeed one of my favorite project/task management techniques comes from a timeless phrase by master Yoda:
Do, or do not; there is no try.
I’m a big fan of David Allen’s Getting Things Done and Michael Linenberger’s Manage Your Now methods. Crisply stating the next action for an open loop is a simple but powerful way to ensure progress. And taking a page from Yoda, I’ve made it a point to never use “try” when I’m writing down a next action or committing to something in general.
Whenever I’m tempted to write “try” in an email or task note, I pause and ask myself, “what would it take to delete’try’ here?” Am I thinking I can get more done today than I actually can? Do I need to enlist support from someone else before I can commit to this? Do I have to train or read more on a particular topic before I can act on it?
I must emphasize this is not about verbalization – it’s just a useful way to uncover hidden dependencies or break down tasks that stems from a particular way of wording them. I have nothing against the word “try”, or the concept of trying itself; exploring, experimenting, and setting stretch goals are all good things, in the right context. More often than not, though, when planning work I’ve found “try” is more of a crutch or oversimplification that you’d do well to remove as early as possible. If you say “I’ll try to get this done by Friday”, I’m not advocating you blindly remove ‘try to’ – it came to your mind for a reason! Take the chance to deep dive that reason and come up with a better commitment, even if it’s later or ends up requiring more work than you thought (which you’ll want to know as early as possible anyway).
By paying close attention to the subtle clues your word choices hide, you can improve your planning and management skills. And while it means next to nothing to me, you know what my parting line has to be here, so: may the force be with you!
Much of today’s task management issues stem from using the email inbox as a task management system. Thus far, solutions have revolved around re-educating ourselves on inbox management. Now, a couple startups (and at least one large email player) are actually rethinking the way our inbox works. As they carefully tread new ground, task management laypeople will benefit immediately, while productivity experts will initially struggle with this new paradigm.
If you enjoy working with micro-managers, you can skip the rest of this post.
OK. Now that I have your attention, let me offer a suggestion for dealing with the micro-managers in your environment by approaching them with a genuine intention to help with –not correct– this trait. Help them deal with the impact it has on their time, as opposed of making it about the way they control their duties.
Traffic was rather heavy as I was driving home from work today. At some point, I noticed the lane to my right was clear, whereas a few feet ahead my lane was jammed. I started changing lanes, but then the car ahead of me (which was fully stopped) attempted to do the same. As I had more room, I stepped a bit firmer on the gas, hoping the other car noticed and let me pass to its right. It worked.
As I pulled away from the jam, I pondered my rather trivial feat. Unconsciously, I had performed a flawed risk/reward analysis: for the perceived benefit of pulling into my driveway a few seconds earlier, I had risked entering a car crash — even a fender bender is annoying enough as to deny any real or perceived time benefits.
Obvious, right? Yet we do it all the time with much more critical things. I’m not talking about flawed probability percentages or delusional rewards — though those are serious problems in their own right; I’m talking about risks and rewards that are not really exchangeable in terms of units or dimensions. Thus, for the prospect of a won argument, we risk a long-term relationship. For the reward of making it to production a couple days earlier, we risk data integrity, customer satisfaction and architectural quality. For the sake of familiarity and transferred responsibility, we enter unacceptable risk as we plan and execute projects using known-flawed waterfall methodologies, with vendors that should know better.
There doesn’t seem to be much written about this, and it makes a lot of sense: risk-reward analysis originates in the financial industry, where the one ruthless unit for all measures is money. We are supposed to do that as well (make a business case or somehow else monetize much of our IT project decisions), but all too often we lack method, discipline, or both — and yet we plow ahead based on questionable proxies for actual business risk and value.
Next time I carry out a risk-reward analysis, I’ll try to make sure that both ends are measured in the same units. I hope you do too!
Over the years, I’ve had the privilege of being part of a few teams: development teams, architecture teams, management teams. I’ve also been privileged to manage a few teams of my own. In my experience, I’ve seen that staff meetings tend to fall within two distinct styles or “colors”, and of course there’s room for many intermediate shades as well. In this post, I outline the styles and make the case for my favorite meeting color.
As an IT leader, I often find myself walking a thin line: I am the company’s voice before the employees, and the employees’ voice before the company. This extends to mediating between internal parties and vendors, auditors, consultants and other external entities as well. While not an absolute situation (and certainly not at my current workplace), it is often the case that higher leadership pushes an IT management model that is ultimately a fallacy. Curiously enough, other parties’ retort is also deeply flawed. Both are rooted in good intentions, but tangle up in a vicious circle that does more harm than good, even though no one overtly intends it. In a sense, a lot of IT leadership and management efforts are spent bridging these two fallacies. Continue reading